[00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [amd64] (yakkety-proposed) [16.04.3-0ubuntu1]
[00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [armhf] (yakkety-proposed) [16.04.3-0ubuntu1]
[00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [powerpc] (yakkety-proposed) [16.04.3-0ubuntu1]
[00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [s390x] (yakkety-proposed) [16.04.3-0ubuntu1]
[00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [arm64] (yakkety-proposed) [16.04.3-0ubuntu1]
[00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [ppc64el] (yakkety-proposed) [16.04.3-0ubuntu1]
[00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [i386] (yakkety-proposed) [16.04.3-0ubuntu1]
[00:06] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (yakkety-proposed) [2:9.0.0-0ubuntu1]
[00:08] -queuebot:#ubuntu-release- Unapproved: ubiquity (yakkety-proposed/main) [16.10.12 => 16.10.13] (core)
[00:10] -queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.21.2 => 1.21.3] (core) (sync)
[00:10] -queuebot:#ubuntu-release- Unapproved: shim (yakkety-proposed/main) [0.9+1465500757.14a5905.is.0.8-0ubuntu2 => 0.9+1465500757.14a5905.is.0.8-0ubuntu3] (core) (sync)
[00:12] <doko_> I retried the libreoffice autopkg test triggered by gcc-6, but this looks unrelated to gcc-6. Please could you override it?
[00:12] <doko_> pitti: ^^^
[00:13] -queuebot:#ubuntu-release- Unapproved: accepted foomatic-db [sync] (yakkety-proposed) [20161005-1]
[00:19] <slangasek> cyphermox: the above shim been tested for the MokManager case?
[00:20] <cyphermox> err, no, woops
[00:20]  * doko_ curses all these new kde binaries just a few days before release ...
[00:20] <slangasek> cyphermox: can you test that, so we know for sure before round-tripping all the way to the release? :)
[00:21] <cyphermox> yeah
[00:21] <cyphermox> it's trivial to test
[00:23] <tsimonq2> doko_: it all comes down to lack of developers and Qt 5.6.1 being such a mess
[00:23]  * cyphermox goes offline for a bit to test this
[00:23] <tsimonq2> doko_: now that we have another Kubuntu Developer (congrats clivejo!) things will get easier
[00:24] <tsimonq2> doko_: but yes, we're cursing them too :P
[00:24]  * tsimonq2 has Kubuntu hat on
[00:27] <doko_> syq_: please see the update to #835851. can you do this backport?
[00:27] <doko_> oops, wrong channel
[00:28]  * doko_ is revealing the super secret Ubuntu mips port ...
[00:29] <nacc> *finally*
[00:29] <sarnold> .. maybe we can get ubnt to run on ubuntu? :)
[00:29] -queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (yakkety-proposed) [1:3.0.0-0ubuntu1]
[00:36] -queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (yakkety-proposed/universe) [16.10.2 => 16.10.3] (xubuntu)
[00:37] <bluesabre> pitti, the above corrects the backlight slowness in xubuntu
[00:44] <valorie> doko_: I'll take the curses if we get a working packageset for release
[00:45] <valorie> the calendar is never our friend, unfortunately
[00:45]  * valorie puts on the flame-proof underwear
[00:48] -queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (yakkety-proposed) [3.0.0-0ubuntu1]
[00:48] -queuebot:#ubuntu-release- Unapproved: accepted glance [source] (yakkety-proposed) [2:13.0.0-0ubuntu1]
[00:50] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (yakkety-proposed) [16.10.8]
[00:50] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (yakkety-proposed) [16.10.3]
[00:52] -queuebot:#ubuntu-release- Unapproved: accepted designate [source] (yakkety-proposed) [1:3.0.0-0ubuntu1]
[00:55] <tsimonq2> hmmmm I wonder what machines actually run mips...
[00:59] <cyphermox> slangasek: now it is tested, mokmanager loads succesfully, and of course the booting works, etc.
[00:59] -queuebot:#ubuntu-release- Unapproved: accepted python-tooz [source] (yakkety-proposed) [1.43.0-0ubuntu1]
[01:14] -queuebot:#ubuntu-release- New binary: kdepim-addons [amd64] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset)
[01:14] -queuebot:#ubuntu-release- New binary: kdepim-addons [ppc64el] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset)
[01:15] <cyphermox> oh my, we'll probably have the signed new shim tomorrow.
[01:16] -queuebot:#ubuntu-release- New binary: kdepim-addons [i386] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset)
[01:16] <slangasek> cyphermox: still better than the alternative :)
[01:16] -queuebot:#ubuntu-release- New: accepted kdepim-addons [amd64] (yakkety-proposed) [16.04.3-1ubuntu1]
[01:16] -queuebot:#ubuntu-release- New: accepted kdepim-addons [ppc64el] (yakkety-proposed) [16.04.3-1ubuntu1]
[01:16] -queuebot:#ubuntu-release- New: accepted kdepim-addons [i386] (yakkety-proposed) [16.04.3-1ubuntu1]
[01:16] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (yakkety-proposed) [3:10.0.0-0ubuntu1]
[01:16] <cyphermox> slangasek: having the new tomorrow signed on shim?
[01:17] <slangasek> no, that's the converse
[01:17] -queuebot:#ubuntu-release- New binary: kdepim-addons [s390x] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset)
[01:17] -queuebot:#ubuntu-release- Unapproved: accepted akonadi [source] (yakkety-proposed) [4:16.04.3-0ubuntu2]
[01:17] -queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (yakkety-proposed) [1:6.2.1-0ubuntu1]
[01:17] -queuebot:#ubuntu-release- Unapproved: accepted manila [source] (yakkety-proposed) [1:3.0.0-0ubuntu1]
[01:17] -queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (yakkety-proposed) [2:9.0.0-0ubuntu1]
[01:17] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (yakkety-proposed) [2:9.0.0-0ubuntu1]
[01:18] -queuebot:#ubuntu-release- Unapproved: accepted heat [source] (yakkety-proposed) [1:7.0.0-0ubuntu1]
[01:18] -queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (yakkety-proposed) [1:9.0.0-0ubuntu1]
[01:18] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.0~rc2-0ubuntu3]
[01:18] <slangasek> the alternative is shim.efi -> /etc/alternatives/shim.efi -> /usr/share/.rootkitz/nsa.efi
[01:18] -queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (yakkety-proposed) [2:10.0.0-0ubuntu1]
[01:18] -queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (yakkety-proposed) [2:9.0.0-0ubuntu1]
[01:18] -queuebot:#ubuntu-release- New binary: kdepim-addons [powerpc] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset)
[01:18] <slangasek> ah, someone batch-accepting?
[01:18] <cyphermox> shh, can't tell people.
[01:18] <cyphermox> (about the nsa.efi file, i mean)
[01:24] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.16+16.10ubuntu1]
[01:25] <slangasek> infinity: were those your accepts above? any reason raspi2 not also accepted?
[01:26] <slangasek> seems snapdragon went in and raspi2 not, though they have the same rationale from apw
[01:30] <infinity> slangasek: snapdragon was a simple review, raspi2 needs a bit more time, but it's happening tonight too.
[01:31] <infinity> slangasek: (the former was a copy forward of an SRU, the latter is a last-minute rebase from 4.4 to 4.8...)
[01:35] <slangasek> ok
[01:36] -queuebot:#ubuntu-release- Unapproved: accepted policykit-1 [source] (yakkety-proposed) [0.105-16git1]
[01:39] -queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (yakkety-proposed) [0.9+1465500757.14a5905.is.0.8-0ubuntu3]
[01:40] <tsimonq2> cyphermox: shred -n<PHONE_NUMBER> -z nsa.efi && debuild -S -sa && dput ../*source.changes
[01:40] <tsimonq2> lol
[01:42] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [sync] (yakkety-proposed) [1.21.3]
[01:43] <slangasek> infinity: ^^ that should /not/ need a new d-i upload to pick up for the images, since AFAIK the bits we put on the CD do not include MokManager and the actual shim binary used for CD boot is unchanged
[01:44] <infinity> slangasek: Kay.  We may need a new d-i for other reasons later anyway, but won't do one for that.
[01:47] -queuebot:#ubuntu-release- New: accepted kdepim-addons [powerpc] (yakkety-proposed) [16.04.3-1ubuntu1]
[01:47] -queuebot:#ubuntu-release- New: accepted kdepim-addons [s390x] (yakkety-proposed) [16.04.3-1ubuntu1]
[01:57] <cyphermox> oh, indeed it wouldn't
[01:57] <cyphermox> that's good I guess
[02:02] -queuebot:#ubuntu-release- Unapproved: xubuntu-docs (yakkety-proposed/universe) [16.04.4 => 16.10] (xubuntu)
[02:05] <bluesabre> ^ Finally got our yakkety docs uploaded
[02:20] <cyphermox> g'night
[02:20] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (yakkety-proposed) [16.10.13]
[02:20] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-docs [source] (yakkety-proposed) [16.10]
[02:36] <santa_> slangasek: are you still up?
[04:23] -queuebot:#ubuntu-release- Unapproved: gnome-photos (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (desktop-extra, ubuntugnome)
[04:49] <slangasek> santa_: certainly ;)
[04:50] <valorie> slangasek, the man who never sleeps
[04:51] <slangasek> well not at 10pm anyway
[04:52] <valorie> ah, that's my tz too
[04:59] <slangasek> infinity: why does binutils autopkgtest run now take 2-3x as long on amd64, beginning with the latest glibc upload?
[05:03] <santa_> slangasek: I wanted to ask you about our next steps with kde packages, we are now in the final freeze, aren't we?
[05:03] <pitti> doko_: will have a look
[05:03] <pitti> bluesabre: hm, the polkit change already should fix the backlight?
[05:03] <slangasek> pitti: I just sorted gcc-6 hinting
[05:03] <slangasek> santa_: next steps are, do whatever it takes to get these packages into a releasable state
[05:04] <slangasek> santa_: I just retried the akonadi arm64 build, hopefully that was a random failure rather than a bug
[05:04] <santa_> slangasek: allright, so we will continue to work on autopkgtest failures to get the things accepted by britney, right?
[05:04] <slangasek> santa_: yes
[05:05] <santa_> slangasek: excellent, I have a fix for kwin, if you are willing to sponsor I will prepare a dsc
[05:05] <slangasek> santa_: please post the link, and if I don't get to it before I drop off, someone in a more European timezone can
[05:06] <santa_> allright
[05:06] <santa_> slangasek: regarding akonadi I think it's a race condition when building with -j4, I dind't have time to do a proper research of that, but I think a rebuild will fix it
[05:08] <slangasek> santa_: ah, so a missing dependency declaration somewhere for a generated header
[05:09] <slangasek> santa_: kpimtextedit's autopkgtest also appears racy
[05:09] <slangasek> at least on i386
[05:09] <santa_> slangasek: the akonadi thing - I think it's a problem in the cmake stuff
[05:09] <pitti> slangasek: your snapd/ppc64el hint doesn't work; I'll have a look, maybe britney stumbles over the +
[05:09] <santa_> probable the cmake file for the tests needs adjusting
[05:10] <slangasek> pitti: the previous hint worked, I *just* updated the version for the new snapd
[05:10] <santa_> that header is generated automatically by something
[05:10] <pitti> slangasek: oh, missed the UTC-7, ok :)
[05:10] <santa_> but I think it's not completely guaranteed that that something happens before the buid of the test
[05:11] <santa_> slangasek: regarding th current state given by the status page, there are some things stuck on plasma-framework, for instance http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kdeclarative
[05:11] <santa_> so pressing the update button would help I think
[05:11] <Mirv> hi! I didn't get e-mail about this rejection, could someone fetch the reason? https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=qtbase - just interested if deemed unsuitable for SRU or something wrong in the preparation
[05:12] <slangasek> Mirv: the reason isn't stored anywhere
[05:13] <Mirv> ok, I did search all my mailbox and trash though. and not also the rejecter is stored?
[05:13] <slangasek> Mirv: AFAIK it is not
[05:13] <Mirv> ok, let's see if someone notices and remebers then
[05:15] <Mirv> I can see that maybe the code change feels a bit too big with regression potential somewhere despite the unit tests
[05:16] <slangasek> santa_: I've retried the plasma-framework tests, but they failed pretty consistently across amd64/i386/ppc64el while passing on armhf; this may require harder hinting, pitti should be able to help with that later if it remains an issue
[05:16] <pitti> Mirv: in practice, I think only me, i_nfinity, s_langasek, L_aney, and a_pw review unapproved (and you just ruled out two); shouldn't be too hard to find out
[05:16] <pitti> hm, juju's tests have been failing for a while :(
[05:17] <slangasek> pitti: for xenial, bdmurray and rbasak were certainly doing some SRU processing this week
[05:17] <pitti> oh, was that SRU, sorry
[05:17] <slangasek> yeah
[05:18] <pitti> Mirv: oh, that actually could have been me
[05:18] <pitti> I remember that I rejected one sync where the origin PPA already got removed
[05:19] <pitti> so there was no way to review teh package, and I'm not even sure if that actually works (syncing from a removed PPA)
[05:19] <pitti> ah, we have a hint for juju-core too :(
[05:20] <Mirv> pitti: no, the PPA is still there https://bileto.ubuntu.com/#/ticket/1964
[05:21] <Mirv> pitti: oh, robru! why does he say he finalized it by mistake, even though the silo is actually there.
[05:21] <pitti> Mirv: check the queue item -- clicking on sync leads to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/1964-deletedppa
[05:21] <Mirv> but that robru's comment was actually days later regardless
[05:21] <pitti> Mirv: hm, odd -- that's not what the +queue page leads to
[05:21] <Mirv> pitti: oh.. so robru deleted the PPA then restored it and rebuilt the binary. right, and the "When" in queue is actually when I uploaded, not when rejected
[05:22] <pitti> Mirv: ok, that makes sense
[05:22] <pitti> so you just need to re-sync I figure
[05:22] <robru> Mirv: same binary. I bincopied it before the ppa was fully removed
[05:23] <Mirv> robru: oh, ok. but it seems the PPA has different internal id despite the same name so the sync wasn't functional anymore.
[05:23] <robru> Mirv: interesting to learn that upload queues follow the ppa entity rather than just going by name, which matched
[05:23] <robru> Yeah
[05:24] <robru> Mirv: sorry again, i was testing code that prevents finalizing queued uploads and it failed, doh
[05:24] <Mirv> ok, now it's in the queue again, let's see about its true fate later :)
[05:24] -queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (xenial-proposed/main) [5.5.1+dfsg-16ubuntu7.1 => 5.5.1+dfsg-16ubuntu7.2] (kubuntu, qt5, ubuntu-desktop) (sync)
[05:24] <Mirv> robru: hah! :) no worries.
[05:25] <slangasek> santa_: akonadi/arm64 looks better this time
[05:27] <santa_> slangasek: great, here's the proposed fix for kwin http://gpul.grupos.udc.es/sponsor/kwin_5.7.5-0ubuntu2.dsc
[05:28] <valorie> \o/
[05:28] <santa_> I had to disable 1 test, just one. I tried so hard but I couldn't figure out a proper environment to get it built
[05:29] <santa_> I checked upstream code 5.8 but it seems the tests changed so much, so I guess we will drop the patch disabling that test for the next version
[05:30] <slangasek> santa_: how has this change been tested ? I would not expect 'xvfb-run -a kwin' + 'xvfb-run -a dbus-launch' to put the processes on the same X server
[05:32] <santa_> slangasek: trial/error with adt-run
[05:32] <slangasek> hmm
[05:33] <santa_> I tried various things and got less and less tests failing
[05:33] <slangasek> I don't think the 'xvfb-run -a kwin &' bit does anything for you
[05:33] <slangasek> that should spawn a completely separate X server than what's used for dh_auto_test
[05:34] <santa_> maybe it's unneed, I can recheck
[05:34] <slangasek> and, I would be concerned about the possibility that on the autopkgtest testbed, this would lead to test timeouts because of dangling processes left behind
[05:35] <slangasek> (so, it wouldn't be harmless)
[05:37] <pitti> the testbeds don't care about dangling processes, just the buildds do
[05:38] <pitti> but starting two different xvfb-runs indeed doesn't make sense
[05:39] <slangasek> pitti: if they don't care, then I can upload this as-is and let santa_ fix the extra process at leisure
[05:39] -queuebot:#ubuntu-release- Unapproved: apparmor (xenial-proposed/main) [2.10.95-0ubuntu2.4 => 2.10.95-0ubuntu2.5] (core)
[05:39] <santa_> I'm testing without the kwin exec btw
[05:40] -queuebot:#ubuntu-release- Unapproved: kwin (yakkety-proposed/universe) [4:5.7.5-0ubuntu1 => 4:5.7.5-0ubuntu2] (kubuntu)
[05:42] <santa_> slangasek: another case, I mentioned earlier in this channel that libkscreen autopkgtest is working properly here locally http://gpul.grupos.udc.es/things/libkscreen_5.7.5-0ubuntu1_adt.log
[05:42] <santa_> any idea about this one?
[05:43] <pitti> santa_: do you actually test with a qemu testbed?
[05:44] <pitti> the "cannot connect to wayland" and "segfault" errors don't sound particularly specific to the scalingstack test env
[05:44] <santa_> pitti: I'm using lxc
[05:44] <santa_> but I can test with qemu too
[05:45]  * pitti runs it here for fun too
[05:45] <slangasek> santa_: where should the wayland server come from within the tests?
[05:46] <slangasek> maybe the tests work for you in lxc because you have a wayland server running already and the socket is exposed in the container?
[05:46] <slangasek> but, for instance, xvfb-run won't provide you a wayland server - so my guess is the wayland tests need to be run separately or not at all (depending on whether there's a reliable wayland equivalent to xvfb-run)
[05:47] -queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (yakkety-proposed) [4:5.7.5-0ubuntu2]
[05:49] <santa_> slangasek: I'm using an lxc container created with adt-build-lxc, so I doubt I already have a wayland server running there
[05:49] <slangasek> but you may have one in the host which shows through? or, there may be one started within the container but it relies on getting access to real graphics hardware
[05:51] <santa_> I doubt it, but as I said I can re-test anything with qemu
[05:51] <santa_> I stoped using it because there was a concrete package I coudn't get working
[05:51] <santa_> no because of the package but because qemu timeouted or something like that
[05:53] <pitti> libkscreen also works here in qemu; so some kind of race condition
[05:53] <santa_> so, push the retry button?
[05:55] <pitti> it fails consistently on the infra, that won't work
[05:55] <santa_> ugh
[05:55] <santa_> so override it?
[06:01] <pitti> for now, I'd say yes, bump the override
[06:02] <pitti> done
[06:02]  * pitti bumps kwin too
[06:05] <slangasek> pitti: why does the neutron/s390x failure get an ignore?  openstack is expected to work on s390x, and it seems like the test works /most/ of the time
[06:07] <pitti> it stopped working reliably in August already
[06:07] <pitti> and now fails consistnetly
[06:08] <pitti> I mean, I can unbump the version and leave that one stuck, but I don't think that's going to suddenly raise an interest now :/
[06:08] <pitti> (and it also regularly blocks a lot of rdeps)
[06:09] <slangasek> pitti: "fails consistently" for the past 5 runs, but magically worked between 20-9 and 5-10 :)
[06:10] <slangasek> pitti: I think we need some forcing factor here to make sure those tests are cared for; maybe a critical bug against the openstack packages when this happens
[06:11] <pitti> ok; IRC pings aren't forceful enough I guess :)
[06:11] <pitti> I'll file a bug
[06:14] <pitti> bug 1631260
[06:16] <infinity> slangasek: re: binutils autopkgtest, I have no idea, but having a very hard time seeing how glibc would have changed anything there.
[06:16] <infinity> slangasek: So, I call coincidence.
[06:16] <slangasek> ok, what else does it coincide with? :)
[06:16] <pitti> what's wrong with binutils?
[06:16] <infinity> Changes in scalingstack.
[06:17] <slangasek> were there changes in SS?
[06:17] <infinity> There were.  But generally for the better.
[06:17] <slangasek> pitti: its testsuite started taking 2-3x longer
[06:17] <slangasek> infinity: ok
[06:17] <pitti> slangasek: not really - time stamp difference in<EMAIL_ADDRESS>is 3:30 hours
[06:18] <pitti> slangasek: I figure it was retried two or three times due to intermittent cloud failures
[06:18] <slangasek> ah
[06:18] <pitti> a worker auto-retries up to three times on such "tmpfail" issues, then it commits suicide
[06:18] <pitti> and these three retries add up to the total test time; that's a bit confusing
[06:18] <infinity> Little bit.
[06:18] <infinity> Yeah.
[06:18] <pitti> it's useful for /running (to spot when tests running), but not for the final result
[06:19] <infinity> THe duration should be of the last test, not the total run.
[06:19] <pitti> "when tests loop")
[06:20] <infinity> I want an s390x laptop.
[06:20] <pitti> filed bug 1631262
[06:20] <infinity> And a shawarma.
[06:21] <infinity> One of those two things will happen in the next half hour.
[06:21] <pitti> xnox wanted to have an s390x phone in yesterday's meeting -- so how hard can a laptop be then
[06:23] <infinity> Well, I figure I can cut off a leg and replace it with a lithium-ion prosthetic, and then carry a refrigerating unit on my back.
[06:24] <slangasek> infinity: iprutils runs 3 daemons out of the box; is that a sensible thing to pull into standard?
[06:25] <infinity> slangasek: It does?  It didn't used to.  Maybe I live in the past.
[06:25] <pitti> urgh, priority-mismatches is a pool of sadness
[06:25] <infinity> slangasek: If the daemons are useful/sane to have on IPR controllers and gracefully don't start in the absence of same, that might be alright.
[06:26] <infinity> pitti: Yeah, that was my next stop.
[06:26] <slangasek> infinity: iprupdate, iprdump, iprinit; all are started as part of multi-user.target; I see no sensible disabling
[06:26] <infinity> pitti: All those py3 modules are curious.
[06:26] <pitti> darn, and we were so close to kicking perl
[06:26] <infinity> perl has been in standard off and on forever.
[06:27] <infinity> I wonder why it fell out.
[06:27] <pitti> infinity: I actually investigated the lp3lib thing somewhere, hang on
[06:27] <pitti> that was for a new corner-case feature in software-properties or release-upgrader or so
[06:27] <infinity> Oh, ick.
[06:27] <slangasek> infinity: confirmed that they're all running after install on diamond, but it looks like that might actually have ipr so isn't a good test case for auto-disabling
[06:28] <infinity> Yeah, a VM would be a better test.
[06:28] <infinity> slangasek: But I'm also curious about why we need them running at all.  Unless the upstream changed drastically, I always used to use iprutils without a daemon to query/config/update controllers.
[06:29] <infinity> Maybe Colin just enabled them because upstream ships unit files, so why not?
[06:31] <infinity> slangasek: But, yeah, I don't think I'd be happy with them running on non-IPR systems.  Less opinionated on what's correct for IPR bare metal.
[06:31]  * infinity -> shawarma.
[06:32] <pitti> infinity: found the culprit: http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz
[06:32] <slangasek> infinity: have updated the MIR bug; includes a reference to Red Hat fixing their package to not auto-start unless ipr is present.  Maybe that's been upstreamed and we can take that
[06:33] <pitti> I wish update-manager could just do that one or two REST calls with urllib, instead of pulling that whole stack ..
[06:33] <slangasek> infinity: can I leave this to you to figure out from here?
[06:33] <infinity> pitti: Ugh.  I don't think that's a valuable enough feature to pull lplib into standard, personally.
[06:34] <infinity> slangasek: I can look after I food.
[06:36] <slangasek> infinity: ok.  also, it looks perfectly feasible to me to make lsvpd drop its dep on iprconfig, as it should continue functioning in the absence of iprconfig
[06:36] <infinity> slangasek: Perhaps the better short-term solution.
[06:39] <slangasek> infinity: cough https://bugs.launchpad.net/ubuntu/+source/lsvpd/+bug/1537116
[06:42] <infinity> slangasek: Well, that's a special bug log.
[07:35] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [sync] (yakkety-proposed) [<IP_ADDRESS>2.14]
[07:35] -queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [sync] (yakkety-proposed) [4.8.0-1012.14]
[07:46] -queuebot:#ubuntu-release- Unapproved: accepted gnome-photos [source] (yakkety-proposed) [3.22.1-0ubuntu1]
[07:50] -queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.0~rc2-0ubuntu3 => 2:14.0.0-0ubuntu1] (openstack, ubuntu-server)
[07:53] -queuebot:#ubuntu-release- Unapproved: ceilometer (yakkety-proposed/main) [1:7.0.0~rc3-0ubuntu1 => 1:7.0.0-0ubuntu1] (openstack, ubuntu-server)
[08:24] <jamespage> please could someone reject the nova upload above - I'd like to put in a autopkgtest fix as well to try sort out the current failures
[08:25] <apw> jamespage, done
[08:26] <jamespage> apw, ta
[08:26] <jamespage> xnox had a nice suggestion so trying that
[08:26] -queuebot:#ubuntu-release- Unapproved: rejected nova [source] (yakkety-proposed) [2:14.0.0-0ubuntu1]
[08:27] <Laney> he's a useful chap to have around
[08:27]  * jamespage twiddles thumbs whilst fresh yakkety downloads
[08:27] <jamespage> gotta love adsl
[08:29] <apw> he has the giggle factor :)
[08:31] <Laney> hearing it in my head right now
[08:38]  * infinity hands Laney some aspirin.
[08:43] <apw> sorry that was my fault
[08:43] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.7 (yakkety-proposed/universe) [1:3.7.1-2ubuntu2 => 1:3.7.1-3ubuntu2] (no packageset)
[08:44] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.7 [source] (yakkety-proposed) [1:3.7.1-3ubuntu2]
[08:48] <Laney> let's all have a moment of calm to remember the joy that xnox brings to our lives
[08:55] <jamespage> urgh
[08:56] <jamespage> this looks look a pkg ordering resolution issue
[08:56] <jamespage> nice circular between nova-compute -> nova-compute-kvm -> nova-compute-libvirt -> nova-compute
[09:00] <jamespage> resulting in nova's membership of libvirt being configured after the daemon is started
[09:00] <jamespage> yukity yuk
[09:02] <xnox> Laney, shall i upload gnupg2 for yakkety? enable-ssh-support seems to be broken =/
[09:03] <Laney> sure, if you've got a fix
[09:03] <Laney> Reference a bug so it can be punted if necessary
[09:05] -queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.0~rc2-0ubuntu3 => 2:14.0.0-0ubuntu1] (openstack, ubuntu-server)
[09:05]  * xnox dist-upgrades to latest upload to reverify
[09:07] <jamespage> apw, OK ^^ is better I think - there is a niggle in the dep order for nova-compute-* things - the test changes make things configure in the right order, but it probably needs more thinking next cycle
[09:08] <acheronuk> can failing tests of kdeclarative be retried? they seem to be failing against plasma-framework/5.24.0-0ubuntu1 while we now have 5.26
[09:11] <jamespage> https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1631304
[09:11] <jamespage> for reference
[09:13] <acheronuk> same for kxmlgui. tests are failing against plasma-framework/5.24 when there is 5.26 there
[09:13] <xnox> jamespage, win! \o/
[09:13] <jamespage> xnox, one of those beggining of time type bugs methinks
[09:28] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.7 (yakkety-proposed/universe) [1:3.7.1-3ubuntu2 => 1:3.7.1-3ubuntu3] (no packageset)
[09:28] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.7 [source] (yakkety-proposed) [1:3.7.1-3ubuntu3]
[09:32] -queuebot:#ubuntu-release- Unapproved: network-manager-openvpn (yakkety-proposed/main) [1.1.93-1ubuntu1 => 1.2.6-2ubuntu1] (no packageset)
[09:37] <smb> Hm... shouldn't http://changelogs.ubuntu.com/meta-release contain yakkety by now?
[09:38] <smb> Just trying to test Xenial to Yakkety release upgrades and "do-release-upgrade -d" acts as there is nothing new
[09:43] <Odd_Bloke> smb: Changing /etc/update-manager/release-upgrades to have Prompt=normal fixed that for me.
[09:45] <smb> Odd_Bloke, hm it does. But its odd. I thought "-d" was supposed to override things
[09:46] <Odd_Bloke> smb: ¯\_(ツ)_/¯
[09:47] <smb> indeed
[09:50] <xnox> smb, after every LTS release, upgrade-manager reverts to "show me LTS only" and thus -d would work to do xenial -> 18.04 LTS (when in devel)
[09:51] <xnox> there is gui option to toggle the tickbox too in software sources.
[09:51] <xnox> clearly, smb, does not read OMG!Ubuntu =)
[09:51] <smb> xnox, ok... well if you got a gui (server)
[09:52] <xnox> horum
[09:52] <xnox> it is a conf file, no idea if there is non text-editor options =/
[09:57] <smb> xnox, I can perfectly change it as soon as I know its supposed to work like that. Apparently I do not read omg!ubuntu nor did I do that many dist-upgrade tests for a hey-its-a-lts+1-crack-release releases. :-P
[09:57] <Ukikie> Also upgrades to LTSes reset that var to 'lts'
[10:24] <xnox> bug 1631320
[10:25] -queuebot:#ubuntu-release- Unapproved: gnupg2 (yakkety-proposed/main) [2.1.15-1ubuntu5 => 2.1.15-1ubuntu6] (core)
[10:25] <xnox> Laney, ^
[10:32] <Laney> xnox: looks right
[10:33] <Laney> xnox: I think it was always like this
[10:33] <Laney> at least the internets seems to document using XDG_RUNTIME_DIR
[10:34] <xnox> Laney, xenial desktop with upstart user session uses /home/xnox/.gnupg/S.gpg-agent.ssh
[10:34] <Laney> for gpg2?
[10:34] <xnox> but i think what happened there is that xenial's gpg-agent honoured preset environmental variable (you want it there - you get it there)
[10:35] <xnox> that's 2.1.11 agent
[10:35] <xnox> and 2.2 agent is more opinionated - you shall use /this/ socket.
[10:38] <Laney> anyways :)
[10:38] -queuebot:#ubuntu-release- Unapproved: accepted gnupg2 [source] (yakkety-proposed) [2.1.15-1ubuntu6]
[11:20] -queuebot:#ubuntu-release- Unapproved: accepted cpustat [source] (xenial-proposed) [0.01.25-1ubuntu0]
[11:38] <Laney> xnox: I guess you should fix gpg-agent.conf too
[11:38] <Laney> (upstart)
[11:46] <pitti> xnox: does this still actually need the env var at all?
[11:47] <pitti> xnox: I thought with either XDG_RUNTIME_DIR or GNUPGHOME the path is alwasy the same anyway, so that we can stop having these silly "poke a constant well-known value in to the session env early"
[11:47] <pitti> and this also works on VT/ssh logins after all, where none of this runs
[11:48] <pitti> I realize we still need to export those for legacy software which expoects them, but they hsould at least point to the canonical location
[11:57] <xnox> pitti, nothing to do with GPG agent, has to do everything with SSH_AGENT variables.
[11:57] <xnox> this is a corner case i use gpg-agent as an SSH agent.
[11:58] <xnox> pitti, possibly need fixing. on xenial with gpg-agent 2.1 things work with $GNUPGHOME for the enable-ssh-support.
[11:59] <xnox> but i do not care about gpg-agent ssh integration in yakkety with upstart user session. As far as I understand, e.g. on touch, people can't really use gpg ssh-agent... =/
[11:59] <xnox> or maybe they can.
[11:59] <xnox> but i'm not sure why they would. it's no different to using ssh-agent given no support for smartcards.
[11:59] <Laney> it's not just touch
[11:59] <Laney> other flavours use upstart
[12:00] <Laney> I think you should fix the path there too
[12:04] <jamespage> pitti, hey - are you aware of any changes to the way udev manages perms on devices?  I'm triaging a yakkety specific issue with ceph - basically the ceph/ceph user/group is not being applied via the udev rules afaict
[12:04] <jamespage> bug 1631328 for context
[12:12] <xnox> Laney, huh? we do have systemd user session everywhere unconditionally as far as I understand. becuase pam logind starts that.
[12:13] <xnox> (in addition to upstart user session, at times)
[12:14] <Laney> xnox: gpg-agent.service is started by graphical-session-pre.target.wants/
[12:14] <xnox> however i don't see gpg-agent started for TTY1 session, and I don't see gpg-agent tty updated upon seat switches.
[12:15]  * xnox guesses elmo / smb / smoser will kill me if systemd starts spawning gpg-agent left-right-and-center upon tty logins =)
[12:19]  * smb misses a bit of context but in my world systemd or anything else would just blow up because the keyring won't be there ...
[12:23] <jamespage> hmm yeah - it appears that the ceph udev rules don't get automatically picked up by udev without a reload?
[12:25] <caribou> Release Team : LocutusOfBorg has uploaded a fix for llvm-toolchain-3.7 to fix a powerpc FTBS
[12:25] <caribou> the same fix apply to llvm-toolchain-3.6 which impacts clamav (its only dependency)
[12:25] <xnox> jamespage, one does need to re-trigger devices to apply newly created rules, that are added after udev spotted a device.
[12:26] <caribou> debian has just dropped use of llvm for clamav until it can be used with llvm-3.8 so either we do the same for clamav and remove LLVM-36
[12:26] <jamespage> xnox, yeah just baffled as to why udev is not applying the perms but just spotted something
[12:26] <xnox> udev is silly
[12:28] <jamespage> xnox, see last comment in that bug
[12:29] <acheronuk> can failing tests of kdeclarative be retried? they seem to be failing against plasma-framework/5.24.0-0ubuntu1 while we now have 5.26
[12:29] <acheronuk>  same for kxmlgui. tests are failing against plasma-framework/5.24 when there is 5.26 there
[12:30] <apw> acheronuk, is plasma-framework/5.26 in -proposed ?
[12:30] <acheronuk> apw: yes
[12:31] -queuebot:#ubuntu-release- Unapproved: supertux (yakkety-proposed/universe) [0.4.0-1 => 0.5.0-1] (no packageset) (sync)
[12:31] -queuebot:#ubuntu-release- Unapproved: accepted supertux [sync] (yakkety-proposed) [0.5.0-1]
[12:31] -queuebot:#ubuntu-release- Unapproved: magnum (yakkety-proposed/universe) [3.0.0-1 => 3.1.1-0] (no packageset) (sync)
[12:32] <apw> acheronuk, ok by default each package is tested only with -release pocket packages, it has to be requested manually, trying to find out how :)
[12:32] -queuebot:#ubuntu-release- Unapproved: accepted magnum [sync] (yakkety-proposed) [3.1.1-0]
[12:33] <Laney> apw: retry-autopkgtest-regressions --all-proposed will give you the command
[12:34] <acheronuk> apw: sorry. I am fairly new to this side of the release/migration process. I can just see it they were got to move, a lot else might then get unstuck in response
[12:40] -queuebot:#ubuntu-release- Unapproved: im-config (xenial-proposed/main) [0.29-1ubuntu12 => 0.29-1ubuntu12.2] (input-methods, kubuntu, ubuntu-desktop)
[12:41] <apw> Laney, ahh nice
[12:41]  * apw tries to run the appropriate tests again
[12:41] <Laney> apw: (or add others as --trigger to just pick those ones)
[12:41] <Laney> all-proposed is probably easier for KDE stuff though :P
[12:43] <apw> acheronuk, if we are lucky submitted
[12:46] <acheronuk> apw: thank you :) if that doesn't resolve it, I'll ask some other kubuntu team members to look again later
[12:52] <cyphermox> morning!
[12:53] <pitti> hey cyphermox, how are you?
[13:02] -queuebot:#ubuntu-release- Unapproved: ceph (yakkety-proposed/main) [10.2.3-0ubuntu1 => 10.2.3-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
[13:09] <cyphermox> bad
[13:10] <cyphermox> pitti: everytime I do small plumbing repairs I remember why I went in IT
[13:12] -queuebot:#ubuntu-release- Unapproved: sahara (yakkety-proposed/universe) [1:5.0.0~rc1-1 => 1:5.0.0-1] (openstack) (sync)
[13:12] -queuebot:#ubuntu-release- Unapproved: zaqar (yakkety-proposed/universe) [3.0.0~b2-1 => 3.0.0-1] (no packageset) (sync)
[13:13] -queuebot:#ubuntu-release- Unapproved: accepted zaqar [sync] (yakkety-proposed) [3.0.0-1]
[13:16] <Mirv> please be aware of https://bileto.ubuntu.com/#/ticket/2054 (qtbase, workaround from upstream to fix also the different crash on exits, iso-tracker bug) and https://bileto.ubuntu.com/#/ticket/2055 (arm64 QML problem, the fix that is alternative to going back to 4.2 kernel on builders, but the patch may affect other 64-bit platforms too). I'm trying to get QA look into those but the silos are ready
[13:16] <Mirv> build wise.
[13:17] <jamespage> could a release team member review my ceph upload - its blocking most of our OpenStack testing on yakkety today so would be nice to get clear
[13:18] -queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu8 => 2.1.0-1ubuntu9] (ubuntu-server, virt)
[13:19] -queuebot:#ubuntu-release- Unapproved: pandas (yakkety-proposed/universe) [0.17.1-3ubuntu2 => 0.18.1-1] (no packageset) (sync)
[13:19] -queuebot:#ubuntu-release- Unapproved: accepted pandas [sync] (yakkety-proposed) [0.18.1-1]
[13:19] -queuebot:#ubuntu-release- Unapproved: fwts (yakkety-proposed/universe) [16.09.00-0ubuntu3 => 16.09.00-0ubuntu4] (no packageset)
[13:21] -queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.4 => 1.3.1-1ubuntu10.5] (ubuntu-server, virt)
[13:21] -queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (yakkety-proposed) [16.09.00-0ubuntu4]
[13:22] -queuebot:#ubuntu-release- Unapproved: xen (yakkety-proposed/main) [4.7.0-0ubuntu1 => 4.7.0-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
[13:29] <cjwatson> infinity: Could you test tip of https://anonscm.debian.org/cgit/collab-maint/iprutils.git to see if (a) daemons still come up on systems with ipr and (b) daemons don't come up on systems without ipr?
[13:29] -queuebot:#ubuntu-release- Unapproved: mistral (yakkety-proposed/universe) [3.0.0~rc1-1 => 3.0.0-1] (no packageset) (sync)
[13:30] -queuebot:#ubuntu-release- Unapproved: accepted mistral [sync] (yakkety-proposed) [3.0.0-1]
[13:35] -queuebot:#ubuntu-release- Unapproved: ironic-inspector (yakkety-proposed/universe) [3.2.0-2 => 4.2.0-1] (no packageset) (sync)
[13:35] -queuebot:#ubuntu-release- Unapproved: accepted ironic-inspector [sync] (yakkety-proposed) [4.2.0-1]
[13:36] -queuebot:#ubuntu-release- Unapproved: murano (yakkety-proposed/universe) [1:3.0.0~rc1-1 => 1:3.0.0-1] (openstack) (sync)
[13:42] -queuebot:#ubuntu-release- Unapproved: murano-agent (yakkety-proposed/universe) [1:3.0.0~rc1-1 => 1:3.0.0-1] (no packageset) (sync)
[13:44] -queuebot:#ubuntu-release- Unapproved: accepted murano-agent [sync] (yakkety-proposed) [1:3.0.0-1]
[13:46] <acheronuk> apw: retry seems to have done it ofr kdeclarative if I am not misreading :) can you try for kxmlgui if not done already? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kxmlgui
[13:47] <acheronuk> seems to be a final blocker ^^
[13:53] <apw> acheronuk, looking
[13:54] <apw> acheronuk, submitted
[14:09] <ahoneybun> acheronuk: final package?
[14:09] -queuebot:#ubuntu-release- New sync: neutron-dynamic-routing (yakkety-proposed/primary) [2:9.0.0~rc2-1]
[14:11] <caribou> someone has an opinion on the LLVM-3.6 .vs. clamav upload ?
[14:23] <pitti> cyphermox: urgh, got disconnected, just got scrollback -- household repairs?
[14:24] <pitti> cyphermox: and now your kitchen is a swamp?
[14:24] <cyphermox> no, not that much
[14:25] <pitti> no wonder IRC had been so quiet in the last hour
[14:25] <cyphermox> it's barely leaking a drop here and there around the handles, but *any* leakage annoys me, because it's clearly a failure
[14:25] <pitti> and patching plumbing isn't as easy as in our profession :)
[14:28]  * pitti does a mass-retry with all-proposed for KDEish stuff, let's see what sticks
[14:37] -queuebot:#ubuntu-release- Unapproved: chromium-browser (yakkety-proposed/universe) [51.0.2704.79-0ubuntu2~cm1 => 53.0.2785.143-0ubuntu1.1307] (ubuntu-desktop)
[14:53] <ahoneybun> thanks pitti
[15:03] <jderose> infinity: fyi, oem-config-gtk isn't installed after doing an OEM install from today's desktop daily. i recall this happening now and then, but i can't remember what you said causes this
[15:15] <slangasek> cyphermox: trade you a leaky faucet for groundwater seepage in our lower level ;)
[15:15] <cyphermox> sucks to be you!
[15:16] <jderose> slangasek: ouch, that sounds rough. where abouts do you live?
[15:16] <cyphermox> slangasek: is lower level meaning basement, or ground level?
[15:17] <slangasek> cyphermox: the front is below grade, the back is above grade, so it's a basement when it gives us problems like this
[15:17] <cyphermox> because to me that sounds like "omg, need to fix the foundation, will cost upwards of 10k, I want to die now"
[15:17] <slangasek> jderose: Portland
[15:18] <slangasek> (the bit with high water table and lots of rain)
[15:18] <davmor2> cyphermox: hey dude shim and mok working today \o/  Haven't tried on hardware will do that shortly
[15:18] <cyphermox> davmor2: ack, thanks!
[15:18] <jderose> slangasek: nice. i lived in portland for about 4 years. loved the summers, but eventually decided i personally need more sun, so moved back to colorado :)
[15:18] <slangasek> jderose: :-)
[15:20] -queuebot:#ubuntu-release- Unapproved: libsmbios (yakkety-proposed/universe) [2.3.0-0ubuntu1 => 2.3.1-0ubuntu1] (no packageset)
[15:21] -queuebot:#ubuntu-release- Unapproved: accepted libsmbios [source] (yakkety-proposed) [2.3.1-0ubuntu1]
[15:23] <caribou> slangasek: seen my prior comment about LLVM-3.6 & clamav ?
[15:23] -queuebot:#ubuntu-release- Unapproved: libsmbios (xenial-proposed/universe) [2.3.0-0ubuntu1 => 2.3.0-0ubuntu1.1] (no packageset)
[15:23] <caribou> tl;dr : will upload a fix for LLVM3.6 FTBS on powerpc, then we'll drop LLVM3.6 in Z
[15:24] <caribou> unless the release team has something against it
[15:24] <slangasek> caribou: you're asking about whether to patch llvm-3.6 or drop the llvm usage from clamav?
[15:24] <caribou> slangasek: patch  3.6 as it's been done for 3.7 yesterday
[15:25] <slangasek> caribou: fixing a build failure is non-controversial
[15:25] <caribou> slangasek: i know, but you were talking about dropping 3.6 altogether during the meeting,
[15:26] <caribou> Debian has dropped it in the latest clamav pkg (yesterday) until upstream get support for LLVM 3.8
[15:26] <slangasek> caribou: well, the question was "why does clamav have its own version".  If the answer is "because it's not ported yet to 3.8 and this is non-trivial", that answers that question
[15:27] <slangasek> I don't know what dropping llvm support costs us in functionality in clamav; I'm not asking to drop functionality from the package
[15:27] -queuebot:#ubuntu-release- Unapproved: lsvpd (yakkety-proposed/main) [1.7.7-1 => 1.7.7-1ubuntu1] (no packageset)
[15:27] <caribou> slangasek: ok, good then; I'll push the 3.6 fix to unblock everything & will take care of the rest during Z
[15:27] <LocutusOfBorg> I probably will kick llvm-3.6 out of Debian in two days or so
[15:27] <LocutusOfBorg> please kick it out from Ubuntu if possible
[15:27] <slangasek> we already have llvm-3.6 in main in xenial, it's not like dropping it before yakkety release gains us anything in terms of support length
[15:27] <slangasek> dropping it for z will suffice
[15:27] -queuebot:#ubuntu-release- Unapproved: accepted lsvpd [source] (yakkety-proposed) [1.7.7-1ubuntu1]
[15:27] <caribou> slangasek: thanks!
[15:28] <LocutusOfBorg> makes sense, unfortunately 3.7 seems to be failing to build on amd6
[15:28] <caribou> LocutusOfBorg: if you're ok, I'll upload the powerPC fix monday morning (hate friday's uploads)
[15:28] <LocutusOfBorg> caribou, I would prefer uploading right now :(
[15:28] <LocutusOfBorg> I can bother other core-devs in case something breaks
[15:29] <caribou> LocutusOfBorg: fine with me then src pkg is ready
[15:29] <caribou> LocutusOfBorg: just doing last minute check & I will upload
[15:29] <LocutusOfBorg> I hate having fixes for toolchain the week of release
[15:29] <LocutusOfBorg> :)
[15:33] <nacc> LocutusOfBorg: i'll be around (and am core-dev now)
[15:39] <LocutusOfBorg> thanks
[15:40] <LocutusOfBorg> BTW as soon as this one is over http://debomatic-amd64.debian.net/distribution#unstable/llvm-toolchain-3.6/3.6.2-4/buildlog
[15:40] <LocutusOfBorg> I'll upload it on Debian, and ask to sync it
[15:41] <LocutusOfBorg> I took the delta
[15:44] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.6 (yakkety-proposed/main) [1:3.6.2-3ubuntu3 => 1:3.6.2-3ubuntu4] (kubuntu, ubuntu-desktop, ubuntu-server)
[15:44] <caribou> LocutusOfBorg: ^^
[15:53] <LocutusOfBorg> thanks
[16:03] <pitti> apw: I made an interesting observation in bug 1626436
[16:05] <pitti> I wonder if there's some way to ignore uevents to test this theory
[16:07] <pitti> sorry, this is #u-devel matter, have this channel in the wrong window
[16:10] <rcj> yakkety 20161007 live cd on Lenovo x230 and external monitors does not boot to X.  without external monitor I get X but attaching the monitor leads to a 'hall of mirrors' effect outside a certain region of the screen.  Just a heads up, I'm taking more of a look.  Right now have bug #1631349 open
[16:17] <acheronuk> pitti: can kxmlgui test on plasma-framework be re-run with 'retry-autopkgtest-regressions --all-proposed' or whatever the command is? it's failing on plasma-framework 5.24 when we have 5.26 available
[16:18] <acheronuk> apw kindly tried that with kdeclarative earlier and it seemed to help
[16:20] <acheronuk> ^^^ or @ slangasek or anyone available who has sec. thank you
[16:22] <slangasek> acheronuk: pitti mentioned 2 hours ago in here that he was doing a "mass-retry with all-proposed for KDEish stuff", maybe this is already done?
[16:25] <acheronuk> slangasek: damn. I though I had refreshed the excuses page, but clearly not. now listing both 5.24 & 5.26 and still 'not considered' for some reason http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kxmlgui
[16:26]  * acheronuk clearly needs more caffination
[16:29] <acheronuk> slangasek: when I follow the not considered due to dependencies on other things, mostly they seem to lead back after a few levels to that kxmlgui
[16:35] <slangasek> acheronuk: there appears to be a plasma-framework/ppc64el test still running
[16:38] <acheronuk> slangasek: my view shows that as regression for 5.24 and absent on that arch for 5.26. neither 'running'
[16:38] <acheronuk> don't know if you can see something I can't or somewhere I am not looking
[16:46] -queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.8-14-g94fd35e-0ubuntu1 => 0.7.8-15-g6e45ffb-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
[16:57] <slangasek> acheronuk: http://autopkgtest.ubuntu.com/running
[16:58] <acheronuk> slangasek: cheers. I am still finding my way around this stuff
[17:04] <acheronuk> slangasek: that ppc64el test shows no output on that page? is that right? sorry to be a pain :/
[17:06] <acheronuk> I now with I could learn what's what on this at a slightly calmer time!
[17:06] <acheronuk> *now wish
[17:11] <slangasek> acheronuk: there are several stanzas, it's a bit hard to scan that page to spot the right one but the test I was looking at was Release: yakkety Architecture: ppc64el Requester: pitti Triggers: ['mesa/12.0.3-1ubuntu2', 'kxmlgui/5.26.0-0ubuntu1'] All-proposed: 1
[17:13] <acheronuk> slangasek: yes, I think I found it ok. it's now vanished off that page
[17:14]  * smoser comes to grovel
[17:14] <smoser> ah. there it is.
[17:14] <smoser> Odd_Bloke, noticed an error in the previous upload for cloud-init... it did not actually fixt he issue it reported to
[17:14] <smoser> his fix he tested and i uploaded.
[17:18] <jderose> cyphermox: any recent ubiquity changes you can think of that might result in oem-config-gtk not being installed after doing an oem install?
[17:18] <slangasek> smoser: accepted
[17:18] <LocutusOfBorg> please accept llvm
[17:19] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.8-15-g6e45ffb-0ubuntu1]
[17:20] <slangasek> LocutusOfBorg: done
[17:21] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.6 [source] (yakkety-proposed) [1:3.6.2-3ubuntu4]
[17:21] <LocutusOfBorg> thanks
[17:24] -queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (yakkety-proposed) [1:7.0.0-0ubuntu1]
[17:25] -queuebot:#ubuntu-release- Unapproved: ubuntu-themes (yakkety-proposed/main) [16.10+16.10.20161005-0ubuntu1 => 16.10+16.10.20161007-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
[17:48] -queuebot:#ubuntu-release- Unapproved: nautilus (yakkety-proposed/main) [1:3.20.3-1ubuntu2 => 1:3.20.3-1ubuntu3] (ubuntu-desktop)
[17:52] -queuebot:#ubuntu-release- Unapproved: oxide-qt (yakkety-proposed/main) [1.17.7-0ubuntu1 => 1.17.9-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages)
[17:53] <tyhicks> Hello - I've just sponsored a yakkety oxide-qt upload, on behalf of chrisccoulson, which fixes a number of security issues (see bug #1631448)
[17:53] <tyhicks> we'd prefer that it be part of the yakkety release but we can always release it to yakkety-security after the release if it is going to cause too much trouble
[18:37] <slangasek> jamespage: I'm curious about the change in nova autopkgtests; armhf and s390x both have always run their tests in containers, and don't appear to be /fundamentally/ broken on those archs as they've passed intermittently
[18:51] -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (yakkety-proposed/main) [1.371 => 1.372] (core)
[18:55] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.0-0ubuntu1]
[18:55] -queuebot:#ubuntu-release- New: accepted neutron-dynamic-routing [sync] (yakkety-proposed) [2:9.0.0~rc2-1]
[19:03] -queuebot:#ubuntu-release- New binary: neutron-dynamic-routing [amd64] (yakkety-proposed/universe) [2:9.0.0~rc2-1] (no packageset)
[19:13] <slangasek> jamespage: I think this ceph upload is wrong; udev rules db is auto-reloaded via inotify, and per the manpage a --reload doesn't change perms on existing devices - I believe you want udevadm trigger --subsystem-match=block --action=change which is the convention used elsewhere
[19:14] <slangasek> jamespage: (rejected, but happy to discuss)
[19:14] -queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (yakkety-proposed) [10.2.3-0ubuntu2]
[19:22] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (yakkety-proposed) [2.1.0-1ubuntu9]
[19:23] -queuebot:#ubuntu-release- Unapproved: accepted xen [source] (yakkety-proposed) [4.7.0-0ubuntu2]
[19:26] <pitti> acheronuk: seems it landed in the meantime
[19:27] <acheronuk> pitti: indeed. thank you
[19:27] <pitti> meh, there is just no pleasing this nova/armhf test
[19:28] <pitti> libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
[19:29] <pitti> oh, thanks jamespage, seems your recent upload addresses that
[19:29] <pitti> jamespage: although that sounds more like forgetting to add some user to some group? it works fine on s390x
[19:30] <pitti> or rather, "works sometimes" -- there's some race conditino in the startup check
[19:32] -queuebot:#ubuntu-release- Unapproved: accepted murano [sync] (yakkety-proposed) [1:3.0.0-1]
[19:39] <jamespage> slangasek, the problem we've seen is that the udev rules get setup without the user/group ownership rules being correctly configured
[19:39] <jamespage> so when a disk is added, it does not get configured correctly, resulting in a failed bootstrap of the osd unit
[19:39] <slangasek> jamespage: right, I just read a bit of the bug log... looknig more deeply now
[19:40] <jamespage> udev reads via inotify, but the user/group is not setup at that point so we end up with ineffect a broken set of udev rules without the reload
[19:40] <jamespage> potentially not setup
[19:40] <jamespage> pitti, I think the nova thing is a bit of a victim of Restart=Always
[19:41] <jamespage> slangasek, pitti: I think it would be possible to drop the container check for nova
[19:41] <jamespage> the other changes in the upload should fix the test consistently across archs
[19:43] <slangasek> jamespage: another option for ordering would be to create the user/group in preinst, which would be before udev rules are unpacked :)
[19:43] <slangasek> semantically, there's lots of precedent for that
[19:43] <pitti> meh, I have not the slightest idea why perl/rename are on http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt -- they just depend on each other, but nothing depends on them
[19:44] <slangasek> jamespage: but where are your user/group created?
[19:44] <jamespage> slangasek, ceph-common postinst
[19:44] <slangasek> ok
[19:44] <jamespage> the user/group is requires more generally than for the udev rules
[19:45] <pitti> preinst is a bit ugly, though -- you need a Pre-Depends: adduser then
[19:45] <slangasek> jamespage: in which case, ceph-osd Pre-Depends: ceph-common would have this same effect
[19:45] <pitti> that sounds better indeed
[19:45] <slangasek> pitti: but is it better to just always do things in the right order, rather than doing them once and then having to fix up a second time?
[19:46] <jamespage> pitti, context on the other nova test changes - https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1631304
[20:16] -queuebot:#ubuntu-release- Unapproved: sahara (yakkety-proposed/universe) [1:5.0.0~rc1-1 => 1:5.0.0-1] (openstack) (sync)
[20:41] -queuebot:#ubuntu-release- Unapproved: accepted neutron-dynamic-routing [sync] (yakkety-proposed) [2:9.0.0-1]
[20:45] -queuebot:#ubuntu-release- New binary: neutron-dynamic-routing [amd64] (yakkety-proposed/universe) [2:9.0.0-1] (no packageset)
[21:13] <infinity> jderose: That usually meant the versions are out of sync.
[21:19] <rcj> slangasek, infinity: If I find a critical issue with the yakkety daily desktop livecd (no X if external display attached) is there anything else I can do to get eyes on it other than filing the bug and marking it @ http://iso.qa.ubuntu.com/qatracker/milestones/360/builds/132831/testcases/1497/results
[21:25] <slangasek> rcj: contact the desktop team, but they're EU-centric so a bit EOW right now; so maybe an email to ubuntu-desktop?
[21:25] <rcj> slangasek, thanks
[21:31] <stokachu> slangasek: when will the archive be frozen?
[21:32] <infinity> stokachu: Yesterday.
[21:32] <stokachu> infinity: when will it be unfrozen (typically)
[21:32] <infinity> stokachu: After we open ZZ.  So, no less than a week, possibly more, it fluctuates.
[21:32] <stokachu> infinity: thanks
[21:33] <slangasek> stokachu: what is it you're actually trying to do, that you're asking about the freeze?
[21:34] <stokachu> slangasek: well we were trying to get juju rc3 into yakkety as rc2 was failing adt tests because of lxd api changes
[21:34] <stokachu> looks like they'll have to wait until the archive opens again and go from there
[21:35] <infinity> stokachu: Is rc3 bugfixes over rc2?
[21:35] <stokachu> infinity: yea
[21:35] <infinity> stokachu: If so, they should be uploading, and we'll review and see if we want to let it in.
[21:35] <infinity> stokachu: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-October/001195.html
[21:35] <stokachu> ok ill work with them to try and get that done
[21:36] <infinity> stokachu: See point 2.
[21:36] <stokachu> infinity: perfect thanks
[21:48] <slangasek> infinity: chromium-browser hits ubuntukylin; any concerns about pulling in the (security) upload currently in the queue before mastering their image?
[21:48] <infinity> slangasek: Nope.
[21:49] <infinity> slangasek: I'll be uncronning and doing a full set for everyone later tonight so we can get some weekend testing to make us cry on Monday.
[21:49] <infinity> slangasek: So if you want to squeeze it in before that, go for it.
[21:51] -queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (yakkety-proposed) [53.0.2785.143-0ubuntu1.1307]
[21:57] <infinity> slangasek: Oh, and I don't think I'm going to bother britney-blocking until Monday, since these weekend images are purely for testing, I have zero confidence or intent for them to be the final images.
[21:58] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-themes [sync] (yakkety-proposed) [16.10+16.10.20161007-0ubuntu1]
[21:59] <slangasek> infinity: ok. there was at least one upload in the unapproved queue that I think should not be accepted into release but could be a candidate for SRU (network-manager-openvpn); how do you want that handled?
[22:00] <infinity> slangasek: A new upstream?  Fun.
[22:00] <infinity> Though, I suppose a reasonably "small" diff for a new upstream release.
[22:00] <slangasek> infinity: yes, /could/ be a candidate for SRU - I haven't dug too deeply, just deeply enough to know I don't like it for release
[22:00] -queuebot:#ubuntu-release- New: accepted neutron-dynamic-routing [amd64] (yakkety-proposed) [2:9.0.0-1]
[22:00] -queuebot:#ubuntu-release- New: accepted neutron-dynamic-routing [amd64] (yakkety-proposed) [2:9.0.0~rc2-1]
[22:01] <infinity> slangasek: Well, feel free to make a call about if you absolutely think it's an SRU candidate.  If so, paperwork, and accept, and an individual block (or block-proposed on the bug) would be fine.
[22:01] <infinity> slangasek: And if we later re-review it and decide that, no, maybe we can stuff it in release afterall, easy to flip that switch.
[22:02] <infinity> If you filter out all the po and autotools vomit, it's not actually a huge diff.
[22:02] <infinity> With solid enough justification and a test plan, it might be suitable for release.
[22:02] <infinity> Maybe.
[22:03] <infinity> Oh, and a file move or two.  We need a diff that tracks that somehow.
[22:03] <infinity> Which implies a patch that could read that format.
[22:03] <infinity> So that'll never happen.
[22:03] <slangasek> infinity: ok. for the moment I'll add the block hint and handwave the rest.
[22:04] <jbicha> yeah, openvpn was stuck in the sponsoring queue for a week, but that's not really y'all's fault
[22:06] <acheronuk> slangasek: britney-blocking = no more migration from proposed-release I assume?
[22:07] <slangasek> acheronuk: it means only things manually reviewed and accepted migrate
[22:07] <acheronuk> slangasek: thanks
[22:12] <slangasek> acheronuk: seems akonadi tests pass now but only on amd64? with timeouts on ppc64el and armhf
[22:12] <acheronuk> santa_: ^^^^
[22:13] <acheronuk> slangasek: ok. thanks.
[22:15] <santa_> I take note I will be back to work soon
[22:17] -queuebot:#ubuntu-release- Unapproved: clearlooks-phenix-theme (yakkety-proposed/universe) [6.0.3+git20161006-1 => 7.0-1] (no packageset) (sync)
[22:17] <acheronuk> santa_: appreciate that very much. next time it won't be so bad, and we should be able to help more
[22:17] -queuebot:#ubuntu-release- Unapproved: accepted clearlooks-phenix-theme [sync] (yakkety-proposed) [7.0-1]
[22:20] -queuebot:#ubuntu-release- Unapproved: isenkram (yakkety-proposed/universe) [0.27 => 0.28] (no packageset) (sync)
[22:20] -queuebot:#ubuntu-release- Unapproved: accepted isenkram [sync] (yakkety-proposed) [0.28]
[22:23] <slangasek> TypeError: cannot astype a datetimelike from [datetime64[ns]] to [bool]
[22:23] <slangasek> I'll take "errors I am not going to bother trying to debug" for $400, Alex
[22:25] <sarnold> boolean time
[22:27] <slangasek> acheronuk, santa_: kdepim-runtime has a reproducible, cross-architecture autopkgtest failure; I don't know if this is bad code or bad test; maybe it's already on your todo list
[22:29] <santa_> slangasek: probably bad test, yes it's under the radar
[22:30] <acheronuk> santa_: under?
[22:31] <infinity> Stealth test.
[22:31] <santa_> acheronuk: IN. sorry
[22:32] <acheronuk> ok :)
[22:33] <slangasek> hahaha love the kdepim autopkgtest
[22:34] <slangasek> acheronuk, santa_: badpkg: debian/tests/testsuite does not exist
[22:35] <slangasek> (after a 1.5h rebuild on the autopkgtest testbed, since 'Restrictions: build-needed' is also set)
[22:35] <acheronuk> whut?
[22:37] <slangasek> acheronuk: http://autopkgtest.ubuntu.com/packages/k/kdepim/yakkety/amd64 debian/tests/control was added but debian/tests/testsuite is not there
[22:37] <slangasek> in kdepim
[22:38] <slangasek> so that wastes a lot of build time for a test that doesn't exist
[22:38] <slangasek> (to be fair, autopkgtest ought to detect this itself earlier, /before/ it spends time building)
[22:38]  * acheronuk looks for a brick wall to bang head against
[22:46] <slangasek> acheronuk, santa_: and ktp-call-ui depends on kde-telepathy-declarative, a binary package previously built from ktp-common-internals that was removed after vivid
[22:51] -queuebot:#ubuntu-release- Unapproved: rejected sahara [sync] (yakkety-proposed) [1:5.0.0-1]
[22:51] <acheronuk> slangasek: so that http://paste.ubuntu.com/23291142/
[22:52] <slangasek> acheronuk: ok, so ktp-call-ui needs updated to reference that new name?
[22:55] <acheronuk> slangasek: possibly. It's nearly midnight here and my ability to investigate is somewhat... erm... degraded
[22:56] <slangasek> ok :)
[22:56] <acheronuk> it is noted though :)
[22:58] -queuebot:#ubuntu-release- Unapproved: kcoreaddons (yakkety-proposed/universe) [5.26.0-0ubuntu1 => 5.26.0-0ubuntu2] (kubuntu)
[23:00] <clivejo> infinity: ^^ thats the security update
[23:10] -queuebot:#ubuntu-release- Unapproved: accepted kcoreaddons [source] (yakkety-proposed) [5.26.0-0ubuntu2]
[23:11] <infinity> clivejo: ^^ that's me accepting it
[23:12] <valorie> yay!
[23:13] <clivejo> infinity: thanks :)
[23:14] <infinity> And this is me going to find a pizza.
[23:14]  * infinity -> pizza.
[23:14] <sarnold> mmmm pizza
[23:14] <clivejo> mmmmm pizza
[23:14] <clivejo> ah sarnold, are you Seth?
[23:14] <sarnold> clivejo: I'm _a_ Seth anyway
[23:14] <slangasek> vv infinity reappearing after pizza
[23:15] <clivejo> the one who commented on LP 1630700 ?
[23:15]  * acheronuk suffer pizza envy
[23:15] <acheronuk> suffers
[23:15] -queuebot:#ubuntu-release- Unapproved: update-notifier (yakkety-proposed/main) [3.174 => 3.175] (ubuntu-desktop, ubuntu-server)
[23:16] <clivejo> acheronuk: me too, but it is 00:15 and if I ate pizza now Id suffer all night!
[23:16] <bdmurray_> slangasek: that's the update-notifier we talked about
[23:18] <sarnold> clivejo: yes :)
[23:19] -queuebot:#ubuntu-release- Unapproved: accepted sahara [sync] (yakkety-proposed) [1:5.0.0-1]
[23:19] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (yakkety-proposed) [1.372]
[23:19] <Ukikie> clivejo: He's got his gecos set correctly and everything too.  (/who sarnold)
[23:22] <santa_> slangasek: working on kdepim-runtime and ktp-call-ui. so another topic while the code builds: I tested kwin without that kwin call in the testsuite, do you remember? well, aparently it need it, without it I got this: http://gpul.grupos.udc.es/things/kwin_5.7.5_modified_adt.log
[23:22] <santa_> * it needs it
[23:23] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (yakkety-proposed) [3.175]
[23:24] <slangasek> santa_: hmm. I think that's probably a bad test then, but that's for another time
[23:26] <santa_> yeah, we laredy have a lot piling up, but I think we will get everything in time
[23:26] <santa_> I'm officially living in my own timezone by the way
[23:37] <slangasek> infinity: have gotten around finally to look at oxide-qt; looks like this may take up to 7h to build, but we should still take it sooner rather than later, so accepting for opportunistic inclusion in images or diversion to SRU queue
[23:37] -queuebot:#ubuntu-release- Unapproved: accepted oxide-qt [source] (yakkety-proposed) [1.17.9-0ubuntu1]
[23:48] <tyhicks> thanks and sorry about the late upload


[16:54] <hobgoblin> IAmNotThatGuy: you know that you can find tutorials which would be useful as wiki's and add them to the page
[16:54] <hobgoblin> https://help.ubuntu.com/community/Pages%20For%20Import
[16:54] <hobgoblin> if you want a copy of the generic PM to send people then just ask
[17:10] <hobgoblin> IAmNotThatGuy: did you get those?
[17:23] <IAmNotThatGuy> hobgoblin, No
[17:24] <hobgoblin> IAmNotThatGuy: yay for logs - http://irclogs.ubuntu.com/2012/05/30/%23ubuntu-wiki.html
[17:26] <IAmNotThatGuy> Will look at the tutorials hobgoblin. Today I read about Wake-on-LAN tutorial in forums
[17:26] <IAmNotThatGuy> check it if it is worthy enough
[17:26] <hobgoblin> thanks
[17:27] <IAmNotThatGuy> I have read lots of posts from bodhi. Many tutorials are much useful
[17:28] <hobgoblin> many are wiki'd already :)
[17:28] <IAmNotThatGuy> okies
[17:28] <hobgoblin> IAmNotThatGuy: there is an index of current wiki's if you didn't know
[17:28] <IAmNotThatGuy> he us the library of tutorials ;D
[17:29] <hobgoblin> https://help.ubuntu.com/community/TitleIndex
[17:29] <hobgoblin> yea
[17:29]  * IAmNotThatGuy saves the page
[17:31] <IAmNotThatGuy> hobgoblin, do you know what 内核/编译 means? :P coz I dont know ;D
[17:31] <hobgoblin> no idea at all
[17:31] <IAmNotThatGuy> Kernel / compile
[17:31] <IAmNotThatGuy> YAY. Google translate rockz ;D
[17:32] <hobgoblin> lubuntu mailing list name perhaps?
[17:32] <IAmNotThatGuy> lol no :P


[00:00] <nizarus> don't be lazy to ask duckduckgo when you have an error message :)
[00:10] <perphil> good advice
[00:19] <perphil> feel asleep, nice talk nizarus, good morning
[00:22] <nizarus> good night perphil :)
[07:37] <pieter2627> morning, sorry for missing meeting last night
[08:06] <nlsthzn> irony that I missed both the ZA and this meeting by such small margins
[08:06]  * nlsthzn needs to start paying attention
[08:06] <craigbrash> all of us :(
[18:20] <inetpro> good evening
[18:27] <Kilos> hmm...
[20:29] <perphil> hi elacheche
[23:38] <Guest96658> hello
[23:38] <Guest96658> :)


[05:17] <Kilos> o/
[07:29] <psydroid> \o
[09:39] <Kilos> superfly  hi there is https://bin.snyman.info broken or removed. I was hoping to find my curry recipe lol. too old now I forget everything
[09:40] <Kilos> inetpro  fix it
[20:44] <superfly> Kilos: oh, sorry, I had to stop that server. I'll restart it later tonight.


[07:04] <dholbach> good morning!
[19:46] <bdmurray> nigelb: How do you think bug 325581 should be treated?  Subscriber Jeremy or subscribe reviewers?
[19:46] <ubot4> Launchpad bug 325581 in xserver-xorg-input-evdev (Ubuntu) (and 1 other project) "kensington pocket mouse model #72237 USB 0d62:1000 not working under 8.10 (affects: 1) (heat: 17)" [High,Confirmed] https://launchpad.net/bugs/325581
[23:03] <nigelb> bdmurray: I'm  not sure yet, I'd probably ask bryce
[23:03] <nigelb> bdmurray: leann's comments though seems to indicate kernel patch for xserver
[23:05] <nigelb> bdmurray: but in those cases, I'd vote us to be subscribed rather than jfo
[23:07] <bdmurray> nigelb: so the reviewers team and we can adjust accordingly?
[23:08] <nigelb> yeah


[02:05] <blackboxsw> smoser: I think I have it
[02:05] <blackboxsw> will send out a MR shortly
[02:09] <powersj> ahosmanmsft region needs to be "West US 2"
[02:09] <powersj> annnd he isn't here
[02:17] <smoser> blackboxsw: ... ?
[02:24] <blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/373291
[02:24] <blackboxsw> smoser:
[02:24] <blackboxsw> ^
[02:24] <blackboxsw> ok gotta head out
[02:44] <blackboxsw> Good points smoser. Will address in flight.
[02:45] <blackboxsw> Have good flights folks. Thanks for a great cloud init summit.
[02:46] <blackboxsw> Flights/travel
[06:58] <amansi26> smoser: Can you please point me the location where I can find the discussion on this error: stages.py[ERROR]: Unable to render networking. Network config is likely broken: No available network renderers found. Searched through list: ['eni', 'sysconfig', 'netplan']


[00:44] <InHisName> I bought a NetGear 600 dual band a year ago and was told that DD-WRT works nicely on it.  The factory software is working so great, I just haven't bothered to try it out yet.  So, ChinnoDog, if you get it running, tell me how you like it.
[01:02] <ChinnoDog> stock_firmware--
[01:02] <ChinnoDog> I need that L7 filtering!
[02:21] <ChinnoDog> It didn't matter. The router won't power on.
[02:22] <ChinnoDog> The router is a refurb but only the power supply is DOA. Unfortunately I do not have a power supply that can put out the necessary 2A to run it. :-( I tested it with a 1A power supply to confirm that was the only problem.
[09:58] <JonathanD> Morning.
[10:14] <rmg51> Morning
[10:15] <JonathanD> Howdy rmg51
[10:15] <rmg51> Howdy JonathanD
[10:16] <JonathanD> How are ya?
[10:17] <rmg51> good so far
[10:18] <rmg51> getting ready to go for a walk
[10:26] <JonathanD> Walks are good
[10:26] <JonathanD> Trying to decide myself if I'm going to run today.
[10:26] <JonathanD> Theres a 5k next week I may enter... not sure yet :)
[10:26] <rmg51> go for it
[10:26] <rmg51> I've never been a runner
[10:51] <JonathanD> Sorry.
[12:04] <waltman> Did you do that?
[12:07] <JonathanD> Half of freenode runs through the holodeck, you know.
[12:08] <waltman> And the holodeck runs on batch scripts!
[12:09] <waltman> And AppleScript
[12:10] <jedijf> AppleSci the new API
[12:10] <jedijf> i should tweet that
[12:11] <waltman> jedijf: At Wegmans yesterday I saw somthing called South Philly Jewish Rye. Is that you?
[12:12] <jedijf> no that's solomon
[12:12] <jedijf> they sold out of mine friday, did you see any JJ Cassone branded kaiser or heroes
[12:13] <waltman> Good thing I didn't buy it then :)
[12:13] <jedijf> south philly rye was Jerry Gluck's(rip) brand
[12:13] <jedijf> Jeff solomon bought that distribution - bread is from Kaplans and 3rd and brown
[12:13] <waltman> oh, Kaplans!
[12:14] <jedijf> Jeff aslo owns kaplans
[12:14] <waltman> Kaplans is the Jewish rye I grew up with!
[12:14] <JonathanD> Kaplans sounds a lot like kalman...
[12:14] <jedijf> the other was gold palace - on rockland street in onley
[12:14] <waltman> My mom grew up like 2 blocks from there.
[12:15] <jedijf> remember that brand - it was a bakery in the middle of a block in olney - crazy
[12:15] <waltman> Her family's church is St. Anges, a small Slovak church right around the corner
[12:15] <waltman> Agnes
[12:19] <jedijf> they have another order in so they're hooked - you'll see pechters rye on the shelves all the time
[12:20] <waltman> So you're JJ Cassone?
[12:42] <jedijf> waltman: yeah, that's my Italian line
[12:43] <jedijf> we became partners in 2004
[12:45] <jedijf> jj was serving wawas in central and south jersey - wawa told jj that if they were present in phila market they would give them that business - we partnered up for that, then wawa went frozen about 3 years ago now
[12:47] <jedijf> wawa business was crazy good - easy - great volume - great payers
[12:47] <jedijf> we did 53 wawas - 110k a week, paid in 10 days -
[12:48] <jedijf> 3 basics items - classics - shorties - and minis
[13:06] <waltman> nice


[01:39] <penguin42> I wonder what the right thing to do with bug 671837 is
[01:39] <ubot2> Launchpad bug 671837 in xorg-server (Ubuntu) "Xorg crashes due to known bug in Xinerama code (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/671837
[01:40] <penguin42> it references an upstream mailing list (not a bug report though) and points to a patch
[01:45] <penguin42> hmm bed
[08:49] <cjae> may I describe a problem and someone tell me how to best describe it for a bug report
[08:50] <cjae> I have images of the issue as well
[15:12] <nemo> Trying to draw a little attention to my somewhat humerous yet rather damaging bug.
[15:12] <nemo> bug #661494
[15:12] <ubot2> Launchpad bug 661494 in x11-apps (Ubuntu) "Request to limit xinit writes to .xsession-errors to some reasonable value, such as 10 megs (affects: 1) (heat: 157)" [Undecided,New] https://launchpad.net/bugs/661494
[15:12] <nemo> wondering if I could get one of the good folk of this channel to look it over, maybe, dunno, say whether the idea has merit
[15:16]  * penguin42 looks
[15:16] <penguin42> hehe, 373G that might be a record
[15:17] <yofel> indeed, at least I haven't yet seen another report with a file >100GiB yet
[15:18] <penguin42> nemo: So I've seen the same thing happen many times - I used to admin a ~100 person network with peoples ~ on NFS, and filling up /home due to .xsession-errors was a common screw up
[15:19] <nemo> penguin42: but. yeah. why on earth isn't this piped to head or a rolling log appender?
[15:19] <nemo> seems like a trivial fix
[15:19] <nemo> penguin42: if the log really overshot, say, 10 megs, it probably shouldn't be growing more anyway
[15:19] <nemo> it isn't like the information in it is critical
[15:20] <nemo> or 20 megs or 40. whatever
[15:20] <nemo> ... or a percentage of the disc that $HOME is on...
[15:20] <nemo> or /home :)
[15:21] <kklimonda_> nemo: if it seems like a trivial fix and still it isn't fixed then it probably isn' trivial after all ;)
[15:22] <nemo> kklimonda_: quite possibly, but then it should be easy to shoot down the trivial fix :)
[15:22] <nemo> hm
[15:22] <nemo> I guess I could make some headway by, oh, trying head -c on my local system
[15:22] <kklimonda_> nemo: I do remember that at some point it was limited - after some time no new messages were logged. And it was terrible ;)
[15:22] <nemo> kklimonda_: depends on what it was limited to
[15:22] <nemo> in a normal session, it'll never get more than a few megs
[15:22] <nemo> but if the limit is set high, then if it hits it, you're probably glad it did
[15:23] <nemo> as I would have been
[15:23] <nemo> but. ok. lemme test my trivial solution w/ a ceiling of, oh, 50 megs
[15:30] <nemo> kklimonda_: a rolling log app would avoid the halting errors prob of course, since it could just keep .xsession-errors and .xession-errors.1.gz etc w/ a few copies
[15:30] <kklimonda_> nemo: sure but X would have to support it
[15:30] <nemo> why?
[15:30] <nemo> this is outside of X
[15:30] <kklimonda_> nemo: well, actually the application that does log it there
[15:30] <nemo> unless you mean as a dependancy in ubuntu
[15:30] <nemo> exec >"$ERRFILE" 2>&1
[15:30] <nemo> vs
[15:31] <nemo> exec 2>&1 | head -c 5000000 > "$ERRFILE"
[15:31] <nemo> or
[15:31] <nemo> exec 2>&1 | rollinglogfile "$ERRFILE"
[15:31] <yofel> Xsession is only run once right?
[15:31] <kklimonda_> $ rollinglogfile
[15:31] <kklimonda_> rollinglogfile: command not found
[15:31] <kklimonda_> :P
[15:31] <nemo> kklimonda_: smartass
[15:32] <nemo> kklimonda_: I'm sure they exist, and not just as generic logging mechanisms
[15:32] <nemo> worse to worse, could use one of those
[15:32] <kklimonda_> probably, someone should investigate :)
[15:32] <nemo> well. I'm trying head -c 50000000 right now :)
[15:33] <nemo> if *that* works it'd already be a lot less evil to users
[15:34] <nemo> kklimonda_: hm. there's some truncation code in there now, but looks like it is just called on starting a new exec
[15:34] <yofel> well, /etc/X11/Xsession has a DoS protection currently... but the way it's done it's pointless if it gets run just once (line 77ff in maverick)
[15:34] <nemo> doesn't limit the existing session
[15:34] <nemo> yofel: yeah. reading that
[15:35] <nemo> yofel: and is much more aggressive than me. limits to only 500000
[15:35] <yofel> right
[15:35] <nemo> so clearly 5 megs or 50 megs is a generous sanity
[15:35] <nemo> limit
[15:37] <penguin42> nemo: doing a log rotate type of thing might work
[15:38] <nemo> head -c 5000000 seems to be working fine too :)
[15:38] <nemo> I'll put it on all my systems
[15:38] <nemo> but
[15:38] <nemo> it'd be nice to not have to merge it
[15:39] <nemo> oh well. just trying to get some visibility. and yes, 373 gigs is extreme
[15:39] <nemo> what is alarming is how easily it happened
[15:40] <nemo> and the result basically shut down the system for that user
[15:40] <penguin42> nemo: Yeh it only takes one app to go nuts
[15:40] <nemo> penguin42: hell. someone could possibly do it w/ a web browser. plugins and such sometimes write to err
[15:40] <nemo> I could DOS an ubuntu user remotely
[15:40] <nemo> if I was clever
[15:41] <nemo> and I got them to hang out on my page long enough
[15:41] <penguin42> nemo: There are some related problems 1) It's difficult to tell what actually wrote into the log and 2) No one really takes care to clean apps up so they don't normally
[15:41] <nemo> I think webgl still does a bit of error spam in some situations, that would avoid even needing to load a plugin :)
[15:41] <kklimonda_> well, "a bit of error spam" isn't bad
[15:41] <nemo> penguin42: well. those are more usability. I'd just like to not have it kill my systems by accident ;)
[15:42] <kklimonda_> the Oracle Installer is an extreme case
[15:42] <penguin42> kklimonda_: I've seen lots of other things do similar
[15:42] <kklimonda_> penguin42: oh? that's the only app I've seen doing that :)
[15:42] <kklimonda_> some do spam a lot
[15:42] <kklimonda_> but not nearly enough
[15:43] <kklimonda_> for it to be a concern (enter fail) ;)
[15:43] <nemo> well
[15:43] <nemo> let me check what gets written in firefox on plugin / webgl activation
[15:43] <nemo> I bet I could whip up a page that is malicious
[15:43] <nemo> w/o it using too much CPU
[15:43] <yofel> nemo: can you give me the *exact* syntax of exec you want to use? (the one with head)
[15:43] <nemo> hell. noscript writes to stderr
[15:44] <nemo> yofel: can show you what I'm testing in my VM right now, sure
[15:44] <kklimonda_> nemo: but that would require you to have a malicious intent.
[15:44] <nemo> kklimonda_: yes. but remote malicious intent
[15:44] <nemo> just as bad as local accidental :)
[15:44] <nemo> and insidious since oomkill won't pick it up and it'd persist
[15:46] <nemo> yofel: exec 2>&1 | head -c 50000000 >>"$ERRFILE"
[15:46] <nemo> yofel: the other truncation code will still work fine on restart.
[15:47] <nemo> .xession-errors still seemed to be written to normally
[15:48] <nemo> yofel: cleverer code might do a fraction of disc, but 50 megs isn't that much in this day and age.  anyone really short on space might want to use /dev/null anyway :-p
[15:49] <yofel> hm, right, this does work, but with head the limit should be like 50MiB, some apps do put a lot of messages in there, and they rarely fail at the beginning
[15:49] <nemo> yofel: that *is* 50 megs
[15:49] <nemo> admittedly not 50MiB ;)
[15:49] <yofel> err, right, too many zeroes :P
[15:49] <nemo> but. yeah 2 orders of magnitude more than the truncation
[15:51] <yofel> the truncation code uses tail which is the right thing to use, but I agree that head with a sane limit would be ok to use. Won't protect against everything, but against most failures I guess
[15:52] <nemo> easier than hooking up a rolling appender :-p
[15:52] <nemo> could do that as a "later"
[22:05] <CarlFK> http://dpaste.de/mGIK/  *** buffer overflow detected ***: tftp terminated[22:06] <CarlFK> whats the shell command to post the bug report to lp?
[22:52] <yofel> CarlFK: run 'sudo service apport start force_start=1' - crash it again and file the crash report in /var/crash with ubuntu-bug (if it hopefully catches the crash)
[22:53] <CarlFK> got it already. but thanks
[22:53] <yofel> np, sorry for being late
[22:53] <CarlFK> while I got you, question bout https://wiki.ubuntu.com/DebuggingProgramCrash
[22:53] <CarlFK> echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list
[22:53] <CarlFK> why not use  apt-add-repository "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse
[22:54] <yofel> backwards compatibility I think. As far as I know hardy doesn't have add-apt-repository
[22:54] <CarlFK> k
[22:55] <CarlFK> and is there a way to do that in a preseed file that doesn't hardcode "natty"?
[22:55] <CarlFK> d-i apt-setup/local0/repository string http://ddebs.ubuntu.com natty main restricted universe multiverse
[22:55] <yofel> CarlFK: it uses '$(lsb_release -cs)' which will insert natty only if you run it on natty
[22:55] <CarlFK> preseed file
[22:56] <CarlFK> really an installer question than a -debug
[22:56] <yofel> I don't know about preseed files I fear
[22:57] <CarlFK> no prob
[22:57] <yofel> maybe ask in #ubuntu-installer if it's d-i specific
[23:03] <drizzle> Can someone wishlist https://bugs.launchpad.net/ubuntu/+source/glade-3/+bug/672313 please
[23:03] <ubot2> Launchpad bug 672313 in glade-3 (Ubuntu) "Maximized window not remembered (affects: 1) (heat: 6)" [Undecided,Opinion]


[00:24] <saiarcot895> Is it possible to get a FFe for the addition of an Apport package hook?
[00:30] <TheMuso> @pilot in
[00:30] <TheMuso> saiarcot895: You would have to file a bug to find out.
[00:31] <saiarcot895> TheMuso: will do
[01:35] <venux> Alright.  So I'm trying to develop a theme for it, right, and I want the background color to be a specific shade of blue, and I can't find out how to set that in the mytheme.awn-theme file.  I've checked other themes and they use some sort of 16 digit hexidecimal color code.  In web design, I've only ever heard of and used 6 digit hex color codes, so I'm not too sure how to generate a 16 digit color
[01:36] <venux> the above is in regards to avant window navigator themes btw
[01:36] <venux> was wondering if anyone here has had experience with awn themes?
[01:40] <sarnold> sixteen digits of hex is eight bytes of color data; that'd be 16 bits of color data per RGB and probably opacity... zounds. that's a lot of color. :)
[01:40] <sarnold> maybe it's sixteen bits per cymk? you know, just in case you want to interact via an offset printing press? :)
[02:18] <venux> ty, i thought it had something to do with the opacity as well... welll... ill figure out how to generate some of them...  trial and error i guess.
[03:14] <xnox> dobey: https://launchpad.net/ubuntu/+source/paste/<IP_ADDRESS>-6ubuntu1 in saucy-proposed now
[04:34] <TheMuso> @pilot out
[06:38] <dholbach> good morning
[06:40] <sladen> guten morgen
[08:31] <happyaron> dholbach: I pushed the change according to Jack_Yu's comment
[08:31] <dholbach> happyaron, I'll take a look in a bit
[08:32] <happyaron> thx
[08:32] <dholbach> happyaron, what about the libchewing bug in the sponsoring queue?
[08:32] <dholbach> should it be uploaded? is it too late?
[08:33] <happyaron> dholbach: it can be uploaded, but all package depends on it may need a rebuild. I think no API change but no ABI guarantee.
[08:34] <dholbach> hum
[08:34] <dholbach> how did they resolve it in Debian?
[08:35] <happyaron> dholbach: I think it was coordinated that updates to other packages were happen right after libchewing's update.
[08:35] <happyaron> but we missed that point in Ubuntu
[08:35] <dholbach> so I'd be happy to sponsor it, if it's something we want
[08:36] <dholbach> but I'm not quite sure what to do :)
[08:36] <happyaron> is it difficult to do things like binNMU?
[08:39] <happyaron> dholbach: maybe I can do some testing this eve, and give feedback then
[08:40] <dholbach> cool
[08:40] <happyaron> actually I'm on a national holiday, but all right, :)
[08:41] <dholbach> enjoy your day off!
[09:10] <dholbach> happyaron, d/copyright would need to be updated according to the source file changes - some files' headers also still seem to say "version 2"
[09:16] <happyaron> dholbach: I think those gpl-2+ files are already marked in d/copyright
[09:17] <dholbach> sorry, my bad
[09:17] <dholbach> let me double check everything
[09:17] <happyaron> :)
[09:17] <dholbach> you're right
[09:18] <dholbach> happyaron, I'll add the bug number to the changelog entry
[09:18] <dholbach> apart from that ready to go
[09:19] <dholbach> uploaded
[09:19] <happyaron> thanks
[09:20] <dholbach> anytime
[12:26] <pitti> Good morning
[15:20] <ogra> slomo, could you take a peek at https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/1224665 and leave a comment if you find the time ?
[16:03] <dobey> how long between a whoopsie crash report being submitted, and it appearing on errors.ubuntu.com?
[18:28] <xnox> doko: Can you pull this patch into debian & ubuntu ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850#c9
[18:28] <xnox> it fixes abi-compliance checker on debian/ubuntu
[18:28] <dobey> pitti, jibel: do you know how i can get a local adt run of a test using the qemu vm stuff, to not delete the temporary directory where the real tree is built for tests that have a build-needed restriction, when i pass -k?
[18:28] <xnox> into 4.8
[18:37] <dobey> or anyone else maybe? ^^
[18:38] <pitti> dobey: no, not really; but what you perhaps could do is to ssh in after you start your test, and then SIGSTOP adt at a convenient point, or cp -r the temp test tree someplace else?
[18:46] <pitti> dobey: or you circumvent adt-run completely and just build your tree there and run debian/tests/whatever directly
[18:49] <dobey> pitti: how do you make debuild not cleanup after the build?
[18:49] <dobey> although local won't really help
[18:49] <cjwatson> debuild never cleans up after the build
[18:49] <cjwatson> other tools around it might ...
[18:49] <pitti> dobey: dpkg-buildpackage/debuild don't do that "copy entire tree to $TMPDIR" stuff, that's adt-run
[18:49] <cjwatson> well, not unless you use -tc
[18:50] <pitti> dobey: dpkg-buildpackage -us -uc -b && sudo debian/tests/whatever should do what you want
[18:50] <dobey> problem is that dh_install is failing in the vm during the build started by adt-run
[18:50] <pitti> dobey: or even just "fakeroot debian/rules build" to skip the dh_* bits
[18:50] <dobey> pitti: yeah, that won't help because it's not where things are breaking :(
[18:50] <pitti> dobey: oh, you mean the package build is breaking, not the tests?
[18:50] <dobey> yes
[18:51] <dobey> well, the package builds fine locally and with pbuilder (and in a PPA or in the archives)
[18:51] <pitti> dobey: I bet that this is reproducible with "fakeroot debian/rules build"
[18:51] <pitti> dobey: there's often packages which make assumptions about dpkg-buildpackage's environment (such as various $DEB_*)
[18:51] <pitti> dobey: but adt-run doesn't use dpkg-buildpackage, it just calls debian/rules build
[18:52] <pitti> arguably that's Debian policy, but then again I'm rather convinced that this shold be obsoleted
[18:52] <pitti> fixing lots of packages for these corner cases is just tedious
[18:53] <dobey> dh_install: libu1db1 missing files (usr/lib/*/libu1db.so.1*), aborting
[18:54] <pitti> dobey: yep, I bet the package behaves differently because debian/rules expects $DEB_HOST_MULTIARCH but doesn't set it by itself
[18:55] <pitti> DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
[18:55] <pitti> dobey: ^ try adding that to the top
[18:56] <dobey> huh. i wonder why other packages that do the same thing aren't failing. or is DEB_HOST_MULTIARCH always set to something in the jenkins adt instances?
[18:57] <pitti> dobey: no, but dpkg-buildpackage sets it
[18:57] <pitti> dobey: other packages did fail in adt-run for the same reason
[18:58] <dobey> pitti: the jenkins adt-run uses dpkg-buildpackage instaed of fakeroot debian/rules build?
[18:58] <pitti> dobey: no, the other way around (and nothing to do with jenkins, that's just adt-run)
[18:58] <pitti> most people check with dpkg-buildpackage only (and frankly I think that shold be the one and only interface), but adt-run directly calls debian/rules build as I said
[18:59] <pitti> so in adt-run, your debian/rules won't have $DEB_HOST_MULTIARCH set
[18:59] <pitti> which causes the library to not get configured/installed for multiarch
[19:00] <dobey> pitti: i mean, there is another package which has pretty much the exact same rules file using $DEB_HOST_MULTIARCH, and the autopkgtests are passing just fine for it when it builds the tree. it doesn't fail with the missing library file
[19:00] <dobey> pitti: so i don't understand why it doesn't also fail
[19:00] <pitti> dobey: well, that depends on the package..
[19:01] <dobey> anyway, adding the bit to the rules file does fix it
[19:02] <dobey> pitti: thanks
[19:02] <pitti> yw
[19:24] <dobey> pitti, jibel: just uploaded a u1db that includes autopkgtest config that wasn't there before, if there's anything you need to poke to enable it. thanks
[19:29] <pitti> dobey: no, should be automatic; thanks
[19:37] <doko> xnox, waiting until the arm64 build is done
[19:37] <xnox> doko: ok.
[19:37] <xnox> doko: i'd love for that patch to make it into saucy =)
[21:16] <slomo_> ogra: if this is proposed for upstream integration, sure
[21:39] <xnox> wgrant: doko: can you please retry https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/4986109 it should be fine now, with fixed paste.
[21:39] <pitti> xnox, wgrant: ^ retried
[21:40] <xnox> pitti: thanks! didn't know you have access =)
[21:40] <pitti> (sounds like sleep time for both of them)
[21:40] <pitti> "Start 2013-09-22"
[21:40] <pitti> xnox: how eager are you to verify? i. e. is that fine, or shall I bump score?
[21:41] <xnox> pitti: i know it's fine, verified locally. I just don't want people to see it on ftbfs-rebuild list and try to investigate, that's all.
[21:41] <pitti> ah, good point
[21:41] <pitti> xnox: will build in 8 mins now
[21:42] <xnox> cool.
[23:25] <smoser> hey...
[23:25] <smoser> could a archive admin help me out please?
[23:25] <smoser> https://launchpad.net/ubuntu/saucy/+queue?queue_state=0&queue_text=uvtool
[23:27] <smoser> thats for FFE bug 1218508


[07:35] <doko> jbailey: pong (but afk today)
[07:38] <jbailey> doko: Heya, just heading to bed. =)
[07:38] <jbailey> doko: Wanted to talk with you about Jim Meyering's email.
[07:38] <jbailey> But waaaay too tired atm.
[07:39] <doko> jbailey: didn't see one. will be back tonight; I was uncautious to join a 130km cycling tour today
[07:39] <jbailey> doko: Ahah, good luck. =)
[07:12] <lamont> infinity: you should _so_ use infinity^2 as your alternate nick. :-)


[15:22] <enyc> superm1, tgm4883: ping =)
[15:23] <superm1> yep i'm around what's up?
[15:24] <enyc> superm1: ""if needbe i create a bug...   Please remind me  of the exact approach for bugs in this context..  I don't want to accidentally post bug against mythtv ubuntu version rather than mythbuntu PPA etc
[15:25] <enyc> superm1: i was trying ot ask tgm4883
[15:25] <superm1> what's the bug about ?
[15:25] <enyc> superm1: packaging related, not code
[15:25] <superm1> i'd just make a git pull request
[15:25] <superm1> and send it to me and dekarl
[15:25] <enyc> superm1: i.e. fix the bug that breaks ipv6 connection to database, fix the bug ...... etc...
[15:25] <superm1> on github
[15:25] <superm1> one of us would get it
[15:25] <enyc> superm1: what which how where why when humm   not really familiar with doing
[15:26] <enyc> superm1: i've discovered the whys and wherefores of all sorts of complexity wrt 'svn' at placement...
[15:26] <superm1> svn?
[15:27] <superm1> basic steps:
[15:27] <enyc> superm1: subversion ;p
[15:27] <superm1> 1) open a github account if you don't have
[15:27] <superm1> 2) fork https://github.com/mythtv/packaging
[15:27] <superm1> 3) checkout that branch from your fork
[15:27] <superm1> 4) make changes, git add the files you changed, git commit them
[15:27] <superm1> 5) git push to your branch at github
[15:28] <superm1> 6) use the U/I at github to file a pull request
[15:28] <enyc> I like command lines =) but hey... =)
[15:28] <superm1> hopefully we get notifications at github, but i'm not sure - so just send me the URL here in case
[15:28] <superm1> you'll get attribution for all the changes then
[15:28] <enyc> ok, there are various, different, changes that fix various, different, problems...  should all these be sumbitted as one or  what?
[15:29] <superm1> separate for each fix
[15:29] <superm1> do it against the master branch first
[15:29] <enyc> as separate _branch_ ?   separate _git add_+_git commit_ ??
[15:29] <superm1> if they're applicable to other branches those should be against the approrpiate branches too
[15:29] <superm1> git add $FILE
[15:29] <enyc> I'm not familiar with the various branches you refer to
[15:29] <superm1> # git commit
[15:29] <enyc> I (thought) this was 'one stream' we just fix our mythtv 0.27 packaging....
[15:29] <superm1> so when you check out that packaging branch - that's the "master" packaging, eg 0.28 or trunk
[15:30] <enyc> oh i see
[15:30] <superm1> we fix stuff there, and then backport to older branches
[15:30] <superm1> after you fix it in master, you can locally do a "git checkout fixes/0.27"
[15:30] <superm1> and then you are working on the fixes/0.27 branch
[15:30] <superm1> do the same set of fixes, or even cherry pick the sha-1 if that makes it easier
[15:30] <enyc> so you want me to checkout the 0.28 packaging, make changes there, git add git commit  in that context
[15:30] <superm1> Yes
[15:31] <superm1> once you're all said and done, i think you run:
[15:31] <superm1> # git push -a
[15:31] <enyc> hangon:  you will backport  or i should attempt to commit the same to both 0.28 and 0.27 ??
[15:31] <superm1> or something similar and it will push all your branches up
[15:31] <superm1> either way
[15:31] <enyc> understood
[15:35] <enyc> I need to do a little more testing at weekend, wheezy-i386 box and various things =)...
[15:36] <enyc> Need to figure out the update-rc.d or whatever postinst to make init script work
[15:36] <enyc> also need to figure out the  root:adm  vs syslog:adm  logfiles difference
[15:36] <enyc> otherwise, it largely seems that our packaging
[15:37] <enyc> can build/run on wheezy and trusty
[15:37] <enyc> AIUI you don't yet have a systemd init script, which would be a useful addition
[17:18] <superm1> yeah i've made a lot of changes over the previous year to make it usefulish on debian
[17:18] <superm1> but there probably will need to be a couple of places that you check if it's debian or ubuntu and set permissions or certain scripts etc
[17:18] <superm1> in terms of making init script work, dh_installinit is supposed to do that
[22:13] <enyc> superm1: hrrm... what mechanism do you use to check debian or ubuntu ??
[22:13] <superm1> enyc: lsb_release
[22:13] <superm1> or cat /etc/lsb-release
[22:14] <enyc> superm1: kk
[22:15] <enyc> superm1: any ideas on this weirdness... only applies to 0.27[well, not 0.25, not tried 0.28] on arm[el,hf,rpi]  on wheezy   [trusty-armhf works]   :  http://www.mythtvtalk.com/linker-issue-16751/
[22:17] <superm1> mmm not really sure on that
[22:17] <enyc> fwiw I'm going to try running the  marilatt/deb-multimedia  build on my arm chroots and see what happens =)
[22:18] <enyc> there may be some little fix in their debian diffs/patches / rules to compile =)
[22:58] <enyc> ooooh they fail in a different way ;p
[22:58] <enyc> Cannot open POTFILES.in.temp for writing at /usr/share/intltool-debian/intltool-update line 615.


[10:13] <mamarley> soee: NVIDIA 370.23 is out. :)
[10:15]  * mamarley is, of course, working on the package.
[10:19] <soee> it is my job to announce it ;D
[10:22] <mamarley> Sometimes these new major releases can be tricky.  Especially with no changelog posted yet…
[10:24] <soee> hmmm
[10:24] <mamarley> I'm not saying this one is or isn't yet.  Just sometimes they can be.
[10:29] <soee> still it does not include much http://www.nvidia.com/download/driverResults.aspx/105855/en-us
[10:31] <mamarley> I don't see anything packaging-relevant in there.
[10:31]  * mamarley crosses fingers.
[10:34] <mamarley> Well, it packages cleanly.  That's a good sign.  Now for the guinea-pigging…
[10:35] <soee> -.-
[10:36] <mamarley> (I haven't uploaded it yet; I need to check if any kernel module patches are necessary.)
[10:52] <mamarley> soee: It appears to work. :) Now I just have to get the packaging ready for the rest of the Ubuntu releases, then I can upload.
[10:52] <soee> than i can test :)
[10:54] <mamarley> This driver also compiles against Linux 4.7 without a patch.
[10:54] <soee> \o\
[11:45] <ricotz> oh nice :)
[11:45] <ricotz> mamarley, make sure to base it on the current 367 ppa packaging
[11:46] <ricotz> and check if the 4.8 patch still applies
[11:52] <mamarley> ricotz: Already based on the PPA packaging, and do you mean the 4.7 patch?  We don't have a 4.8 patch yet.
[11:52] <mamarley> Regardless, the 4.7 patch is no longer necessary.
[11:52] <ricotz> if so, you didnt base it on the current packaging
[11:53] <mamarley> Oh, you must have uploaded something more recently that I didn't see.  Darn.
[11:53]  * mamarley starts over.
[11:53] <ricotz> updated it last week
[11:53] <ricotz> nvidia-graphics-drivers-367 - 367.35-0ubuntu2~gpu16.10.2 	(changes file) 	ricotz 	2016-08-11
[11:54]  * mamarley slaps himself around a bit with a large trout.
[11:55] <mamarley> I will let you know when I am ready again.  Sorry.
[11:57] <ricotz> mamarley, didn't you add the ppa yourself? you should have noticed by receiving this update
[12:46] <mamarley> ricotz: I do have that PPA enabled, but I also have my staging PPA enabled, which has 367.36.02 in it.  Therefore, I never saw the update.
[12:47] <mamarley> I didn't upload anything to the main PPA though, so no harm done.  I can just re-upload it in staging.
[12:56] <mamarley> The 4.8 patch is definitely still needed.
[13:00] <mamarley> This code uses "goto".  I have a bad feeling that I am about to be attacked by a velociraptor…
[13:54] <mamarley> ricotz: I have uploaded everything to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages.  It isn't published yet though.
[14:27] <ricotz> mamarley, thanks, will take a look later
[14:27] <ricotz> ... including a test-run
[16:57] <ricotz> mamarley, so, you forgot to tweak the 4.8 patch-number in dkms_nvidia.conf.in which must start with [0]
[16:57] <mamarley> Oh, sorry, I didn't realize that was required.  I will fix that.
[16:59] <ricotz> if dmks doesnt find a [0] (and so on) it skips patching
[17:00] <mamarley> ricotz: Should I leave the numbers for all the commented-out patches as they are?
[17:07] <ricotz> yes
[17:07] <ricotz> will be back in a few hours
[17:09] <mamarley> I apologize for the error.  The fixed packages are now uploaded.
[19:36] <mamarley> ricotz: soee states in another channel that he has tested 370.23 and that it works for him.  I have also tested it on two systems and not had a problem.
[19:38] <soee> http://i.imgur.com/QusGYfs.png yes
[20:13] <ricotz> mamarley, looks good