[00:59] <slangasek> stgraber: ^^ perhaps open-vm-tools is something you'd like to give a second opinion on
[01:00] <slangasek> infinity: aptdaemon, at-spi2-core: removed from 'core', and moved to a different packageset instead?
[01:02] <slangasek> infinity: is there a good way to get boost-defaults included into the core packageset?
[01:24] <slangasek> infinity: have seeded a few things; feel pretty good about what's left, modulo the boost-defaults question... and oh, maybe we want to make openjdk-8 stay in core. want to rerun that report against current seeds?
[01:31] <slangasek> infinity, pitti: I've also taken care now of seeding the various static -dev packages that should get Built-Using'ed (with comment in the seed)
[01:45] <slangasek> pitti: fwiw I don't see any reason to keep eperl in main, it seems to be just a specialized perl interpreter
[01:54] <slangasek> doko, wgrant: why is nux on the FTBFS list if it only ftbfs on s390x and it's not built there? http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html
[01:55] <wgrant> slangasek: "not built there"?
[01:56] <wgrant> The rebuild test pages don't consider whether it built in the primary archive.
[01:56] <wgrant> If it's in the arch list it'll build.
[01:57] <slangasek> wgrant: ok.  makes it a bit harder to drive the list to 0 then
[01:57] <slangasek> (i.e., less useful to drive it to 0 and harder to see which bits actually matter)
[02:40] <infinity> slangasek: Don't recall the algorithm, but core happens when something is >> n packagesets (n might be 2).
[02:41] <infinity> slangasek: So at-spi and aptdaemon probably fell out because they used to be in more due to build-deps.
[02:44] <Kamilion> I just tried to create a new ext4 partition with gnome-disks and it segfaulted after creating the partition but before formatting it. Anyone else seen this behavior?
[02:47] <infinity> slangasek: And are you cleaning up your c-m fallout from seed changes?  (I don't want to clash and hit the double-override bug)
[03:47] <slangasek> infinity: yes I did clean up the c-m fallout, I think
[03:47] <slangasek> infinity: ah, there's another round of it; I can do that now if you didn't already
[03:52] <slangasek> infinity: right, those are cleaned up now; after the next c-m run everything should be Not Me
[03:55] <pitti> slangasek: ah, cheers
[03:55]  * pitti ughs at http://autopkgtest.ubuntu.com/running.shtml, glibc and a full round of KDE, that'll take ages
[03:55] <pitti> I guesss we have to cut short the glibc tests
[03:58] <slangasek> oh right, kde, that's why update_excuses jumped up by 120
[03:59] <pitti> slangasek: nvidia-graphics-drivers-361-updates on c-m> that source can be removed, did you do that or demote?
[03:59] <pitti> ah, /me should just check himself
[04:00] <pitti> infinity removed it, perfect
[04:00] <pitti> I guess I'll let some more glibc tests run, and once there's a sufficient amount of green and the reds get checked, I'll hint it in and flush the test queues
[04:07] <slangasek> pitti: seems to me that there's no need to cut the queue short until that's actually a blocker for rolling images?
[04:08] <slangasek> which according to infinity's mail isn't until "late Friday or early Saturday"
[04:08] <pitti> slangasek: well, we basically can't land anything else right now
[04:08] <pitti> and https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 has some stuff which looks like it desperately wants to go in
[04:08] <slangasek> hmm
[04:08] <pitti> I estimate the current backlog to be ~ 2 days
[04:08] <slangasek> how long does it take to complete a full glibc autopkgtest run?
[04:08] <slangasek> ok
[04:09] <pitti> KDE takes awfully long
[04:09] <pitti> and of course glibc includes all those too, plus the rest of the archive
[04:09] <slangasek> right, shouldn't be allowed to go too long then
[04:10] <slangasek> how long is the backlog on the quickest arch? (which I think is s390x still?)
[04:10] <slangasek> (can we at least get green for one arch before flushing?)
[04:10] <pitti> s390x is insanely fast, I guess half a day or so
[04:10] <pitti> yes, that's what I did last time
[04:10] <slangasek> ok, cool
[04:13] <pitti> i. e. I could remove glibc from the amd64/i386/armhf queues, keep s390x, and thus let KDE start on these arches
[04:13] <pitti> then it should more or less settle by itself
[04:13] <infinity> pitti: amd64/i386 share a scalingstack pool, I assume, yes?
[04:14] <pitti> yes
[04:14] <infinity> pitti: So, just kill i386 and leave amd64?
[04:14] <pitti> works too, but i386 is much further ahead
[04:14] <infinity> Or vice versa. :P
[04:14] <pitti> 405 (i386) vs. 1050 (amd64)
[04:14] <pitti> just because britney requests i386 before amd64
[04:14] <pitti> infinity: yep, sounds good
[04:15] <infinity> To be fair, nothing in that upload should regress on x86 anyway.
[04:15] <infinity> But still nice to see *some* coverage.
[04:16] <infinity> From a source perspective, that upload can't possibly break on armhf, so if there have been enough tests to qualify as a "yeah, not miscompiled crap" smoketest, you can whack armhf.
[04:17] <pitti> infinity: yes, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glibc has a hundred or so armhf: pass
[04:18] <infinity> pitti: Righto, so flushing armhf glibc tests seems like it'd be fine.
[04:18] <infinity> I mostly want good coverage on x86 because that's 99% of our userbase, and s390x because it actually had relevant and moderately scary commits.
[04:22] <pitti> infinity: how about ppc64el?
[04:22] <pitti> (couple hundred passes, only a few regressions which look unrelated)
[04:23] <pitti> I mean in terms of arch specific change scariness
[04:24] <pitti> "Fix HTM on powerpc/ppc64/ppc64el"
[04:25] <infinity> slangasek: Oh, son of a.  I knew I was forgetting something.  We didn't address Till's lsb ld.so woes.  I'm thinking maybe just resurrecting lsb-core might be less crazy than adding the links to glibc this late.
[04:26] <infinity> pitti: That was only relevant to 2.22
[04:27] <infinity> pitti: (As in, it was a backport to 2.22 from 2.23, so we already had the commit)
[04:27] <infinity> pitti: So, yeah, I don't think ppc64el needs more than smoketest coverage.
[04:28] <pitti> ack, thanks; queues look more reasonable now (I slaughtered some other tests, I'll put them back once the queue settles down)
[04:28] <pitti> infinity: wrt. unapproved review, how much do you want to do this yourself now?
[04:28] <infinity> pitti: Always happy for help.
[04:28] <pitti> infinity: I suppose today is still pretty much "if it looks sane, let it in", as we'll rebuild everything?
[04:29] <infinity> pitti: I don't think we need to gate it down to a single tracking point/person until after langpacks are in, since no image can be "final" before that. :P
[04:29] <infinity> pitti: And since you're the langpack man, you know exactly when that is.
[04:29] <pitti> yes, that was my thought
[04:30] <pitti> infinity: I asked wgrant to start an export now, and our BBQ is cancelled due to bad weather so I can do the package builds/review/upload tomorrow afternoon
[04:30] <infinity> pitti: That sucks.  (The BBQ, not the langpacks)
[04:31] <infinity> pitti: OOI, do we have any testing for langpacks, other than your spot-check?
[04:31] <pitti> well, there's always the next weekend
[04:31] <infinity> pitti: Seems like it would be trivial to write a generic autopkgtest that did a few useful things.
[04:31] <pitti> infinity: not really, we just auto-upload everything to the devel series once a week and then have people complain
[04:31] <pitti> which isn't very often, but we do see some issues every now and then
[04:32] <pitti> like, evolution changes its domain every release, and templates need to be approved in LP, etc.
[04:32] <infinity> Not that we can test for poor translations or anything, but we can test for functionality.
[04:32] <pitti> but nothing substantial in terms of buliding them
[04:32] <pitti> aside from the bug that sil2100 fixed last week
[04:34] <Logan> the amount of spam on rcbugs is killing me
[04:45] <pitti> ok, the rest is of the kind "why on earth are you uploading a 300 kB change after final freeze" kind
[04:47] <infinity> setuptools was (barely) before freeze.
[04:48] <infinity> And u-r-u has an obvious reason for the massive delta.
[04:48] <pitti> right, currently reviewing that
[04:48] <infinity> Though it might need a refresh after slangasek fiddled with the archive again. :P
[04:48] <infinity> open-vm-tools, I dunno WTF that Steve guy is thinking.
[04:49]  * infinity looks at LP: #1558198
[04:49] <ubot5`> Launchpad bug 1558198 in open-vm-tools (Ubuntu) "[FFE] sync open-vm-tools from Debian for Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1558198
[04:49] <pitti> u-r-u looks fine, accepted
[04:50] <infinity> pitti: setuptools has an FFe filed, if you want to go have opinions about it.
[04:51] <infinity> https://bugs.launchpad.net/ubuntu/+source/python-setuptools/+bug/1570587
[04:51] <ubot5`> Launchpad bug 1570587 in python-setuptools (Ubuntu) "[FFe] Please update to bugfix release 20.7" [Undecided,New]
[04:51] <pitti> I'll do this later on
[04:52] <pitti> need to delve into the next upload of "scary openssl patches" again
[04:52] <pitti> better sooner than later
[04:52] <pitti> although that one should mostly be an effective no-op and just cleaning up patches
[05:17] <pitti> slangasek: still some leftovers on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, are you on this or should I move some stuff around?
[07:36] <pitti> infinity: http://autopkgtest.ubuntu.com/packages/s/stress-ng/xenial/s390x/ regressed with a segfault in mmapfork
[07:36] <pitti> infinity: not sure if that's a glitch (I'll retry), but so far this test has been fairly stable
[07:36] <pitti> (no cking yet)
[07:37] <pitti> could that be relevant?
[07:42] <infinity> pitti: If it fails again, can you run that one on all arches?
[07:46] <pitti> infinity: yes, will do; queue is almost done with setuptools and openssl, except on armhf
[07:47] <infinity> pitti: Erk.  glibc just migrated...?
[07:47] <pitti> meh, it did? I hoped I removed the override fast enough, after I saw that stress-ng thing
[07:47] <infinity> Should wait for tests relating to glibc 2.23-0ubuntu3, but forced by pitti
[07:47] <infinity> Valid candidate
[07:47] <infinity> And it copied.  I have the email.
[07:48] <pitti> ok, sorry about that the
[07:48] <pitti> n
[07:48] <infinity> Oh well.  We can investigate the stress-ng and I can upload a new one if it's an actual regression.
[07:48] <pitti> spotted the stress-ng regression a few mins too late, the otehr regressions looked unrelated
[07:48] <infinity> It's obviously not widespread if it is a regression.
[07:49] <pitti> no, there are many hundred passes
[08:02] <pitti> infinity: http://autopkgtest.ubuntu.com/packages/s/stress-ng/xenial/s390x/ retry worked, and pass on x86 too
[08:02] <pitti> phew
[08:07]  * LocutusOfBorg hopes that now fpc will be installable on powerpc with the new glibc
[08:37] <Laney> Trevinho: Can you tell me what we should do for the 'minimal' hud & friends fix please?
[08:44] <pitti> oh nice, the full langpack export is ready
[08:57] <flexiondotorg> Laney, can you remind me of the correct syntax to request unblocks please?
[09:08] <Laney> flexiondotorg: I don't think there's a block on atm
[09:09] <Laney> you're just waiting for queue review
[09:09] <pitti> langpack flood coming in, brace for impact
[09:09]  * Laney ducks and covers
[09:10] <pitti> argh again -- dput from britney takes awfully long, like last time; so this dput business will take some two hours, easy for buildds to keep up with
[09:10] <Laney> s/britney/snakefruit/?
[09:10] <pitti> yes, that
[09:11] <pitti> (britney is my ssh alias)
[09:11] <Laney> hmm
[09:11] <Laney> did IS look into that?
[09:12] <pitti> I didn't file an RT so far
[09:12] <pitti> Laney: as I'll leave in about an hour, do you mind running this in the background:
[09:12] <pitti> while queue -s xenial-proposed -Q unapproved -E accept language-pack-; do sleep 300; done
[09:17] <Laney> pitti: okay
[09:17] <Laney> doing
[09:18] <pitti> Laney: cheers; it did the first batch
[09:18] <Laney> nod
[09:21] <LocutusOfBorg> doko, python-numpy merge?
[09:43] <xnox> infinity, shiny, i see new kernel.
[09:45] <flexiondotorg> Laney, what does "you're just waiting for queue review" mean?
[09:45] <Laney> flexiondotorg: didn't you see this before?
[09:45] <flexiondotorg> And how does that relate the infinity email from last night about Final Freeze being in place?
[09:45] <Laney> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
[09:46] <flexiondotorg> So I'm familiar with the new queue.
[09:47] <flexiondotorg> Will seeded uploads make it to the release pocket automatically at the moment or will they require manual intervention.
[09:47] <flexiondotorg> Laney, that ^^^ is what I'm not clear on.
[09:48] <Laney> That's the unapproved queue, and uploads are held there. This freeze has been on for a few weeks already. People are proactively reviewing it.
[09:49] <Laney> You only need "unblock" when there is a freeze at proposed-migration, which there is not currently
[09:55] <flexiondotorg> Laney, Thanks for the clarification.
[10:42] <ogra_> can some archive admin push https://launchpad.net/ubuntu/+source/linux-meta-snapdragon/4.4.0.1009.1 and https://launchpad.net/ubuntu/+source/linux-snapdragon/4.4.0-1009.9 from proposed to the archive ?
[10:50] <xnox> ogra_, as per http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html no clever admin is needed.
[10:50] <xnox> ogra_, all proposed->release are automatic
[10:50] <xnox> Invalidated by dependency
[10:50] <xnox> Not touching package as requested in bug 1567379 on Thu Apr 7 11:36:21 2016
[10:50] <ubot5`> bug 1567379 in Kernel Development Workflow "linux-snapdragon: 4.4.0-1011.11 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1567379
[10:51] <xnox> ogra_, so ping rtg to remove the block-proposed tag from that bug report, if all the testing and kernel upload procedure has been done correctly.
[10:59] <ogra_> xnox, yep, will do, thanks
[11:11] <Trevinho> Laney: well, if you agree with I can open a different bug (which I should have done anyway) about the fact that window actions aren't accessibile from HUD and we just merge HUD and BAMF... While we leave the keybinding stuff for some (even later?) decision
[11:14] <Laney> Trevinho: Okay, so just taking those two is enough?
[11:15] <Trevinho> Laney: yep... But I also removed from silo the offending MPs
[11:15] <Trevinho> Laney: so silo could be kept with other unity and compiz fixes
[11:15] <Laney> Trevinho: Then please rebuild and re-publish those two if they are fix only
[11:15] <Trevinho> Laney: ok
[11:16] <Laney> thanks!
[11:16] <Laney> I'm going to reply
[11:16] <Trevinho> Laney: well, there's even a dependency change in BAMF, but on libdbusmenu which is already well used around.
[11:16] <Laney> if someone wants to force it through then we have a process for that
[11:25] <rbasak> Incoming security update for MySQL 5.7. The microrelease update is available from upstream, though not the full announcement. Only the pre-announcement: http://www.oracle.com/technetwork/topics/security/cpuapr2016-2881694.html
[11:25] <rbasak> We'll have a bug to track this in Ubuntu shortly.
[11:25] <rbasak> I can upload the update now if that's desirable?
[11:25] <rbasak> I also have a NEWS file to add (missed in previous upload) which I presume won't be an issue. No other packaging changes.
[11:27] <rbasak> bug 1570808
[11:27] <ubot5`> bug 1570808 in mysql-5.7 (Ubuntu) "Security fixes from the April 2016 CPU" [Undecided,New] https://launchpad.net/bugs/1570808
[11:55] <barry> pitti: i definitely want to try to get dirtbike 0.3-2 and python-pip 8.1.1-2 into 16.04 but syncpackage has been saying they haven't been picked up by LP yet since yesterday afternoon
[11:56] <cjwatson> barry: dak has been broken
[11:56] <barry> cjwatson: gosh, again?
[11:56] <cjwatson> I can only assume they have no tests for the pdiff code, because it apparently keeps breaking
[11:57] <barry> cjwatson: yeah, at like the worst possible times for us ;)
[11:57] <cjwatson> anyway, not an LP problem, we'd be importing stuff if it was published enough on the Debian side to import
[11:57] <barry> cjwatson: is there any other acceptable work around?
[12:01] <ogra_> there is rtg !
[12:01] <rtg> ogra_, indeed
[12:02] <ogra_> rtg, i was wondering about bug 1567379 ... there are hacks in livecd-rootfs that work around the missing -meta which i'd like to drop asap ... but that requires the meta to be in the archive
[12:02] <ubot5`> bug 1567379 in Kernel Development Workflow "linux-snapdragon: 4.4.0-1011.11 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1567379
[12:03] <rtg> ogra_, lemme see where that is. I thought it all should have been promoted by now.
[12:04] <ogra_> rtg, we also still miss the firemware package i think
[12:04] <ogra_> without it no WLAN (which is the only interface on that board)
[12:04] <rtg> ogra_, yup
[12:11] <cjwatson> barry: well, I'm still crossing fingers for dak to be fixed soon.  If it really has to be today then I guess a fakesync would be acceptable, though I normally deplore those where unnecessary
[12:12] <zequence> Getting really close to release. Any chance to get our stuff merged into ubiquity and ubiquiti-slideshow-ubuntu? Very small changes, but important for us. Sorry we are so late with this.
[12:12] <zequence> Bug 1569005
[12:12] <ubot5`> bug 1569005 in ubiquity-slideshow-ubuntu (Ubuntu) "New ubiquity slideshow for Ubuntu Studio [UI Freeze Exception]" [Undecided,New] https://launchpad.net/bugs/1569005
[12:12] <zequence> Bug 1568981
[12:12] <ubot5`> bug 1568981 in ubiquity (Ubuntu) "new Ubuntu Studio wallpaper for ubiquity installer [UI FREEZE EXCEPTION]" [Undecided,New] https://launchpad.net/bugs/1568981
[12:19] <LocutusOfBorg> pretty please virtualbox, with serious fixes for xorg 1.18
[12:20] <LocutusOfBorg> on guest, as well as the guest-additions-iso package
[12:27] <barry> cjwatson: thanks, i'll keep trying
[12:28] <sil2100> Hello release team! livecd-rootfs doesn't seem to be seeded anywhere, where we need the new version to unblock ubuntu-touch xenial builds again (hash-mismatches)
[12:28] <sil2100> Could someone poke it in from the unapproved queue?
[12:28] <Laney> We're looking frequently, no need to ping :P
[12:29] <sil2100> ACK ;)
[12:29] <sil2100> Thanks!
[12:46] <Laney> Trevinho: ^- that's for you
[12:46] <Laney> thanks, queue accepter!
[12:46] <Trevinho> Laney: thanks a lot
[12:47] <Laney> Trevinho: I'm going to unblock bamf and hud now, let me know when unity and compiz are ready
[12:47] <Laney> please
[12:47] <Trevinho> Laney: silo is building instead
[12:47] <Trevinho> Laney: oh, wait.. as I've triggered a rebuild for fixing changelog bigs
[12:47] <Trevinho> bugs*
[12:47] <Laney> oh for those too?
[12:47] <Trevinho> yes
[12:47] <Trevinho> as it's a different bug
[12:47] <Laney> ok
[12:48] <Laney> then I'm going to get lunch, let me know when published to xenial-proposed
[12:48] <Trevinho> Laney: just waiting for hud to finish building in arm https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059/+packages
[12:48] <Trevinho> Laney: ok, it should be matter of minutes but take your time
[12:48] <Laney> you can get sil2100 or someone to do that for you
[12:49] <Trevinho> Laney: oh, actually it finished building it seems
[12:56] <sil2100> What's up?
[12:56] <Trevinho> sil2100: this needs love https://requests.ci-train.ubuntu.com/#/ticket/1251 :)
[12:58] <sil2100> Trevinho: did you fix the changelog issues as per what the silo is reporting?
[13:14] <Trevinho> sil2100: yes, I had to force rebuild. But it's fine I'm overriding that, since these have not been really released.
[13:14] <Trevinho> sil2100: they were blocked in proposed, so we want those changelog entries not to be really there.
[13:14] <sil2100> Oh, ok
[13:15] <sil2100> Trevinho: so you would like to re-release the silo as it is right now, yes?
[13:15] <Trevinho> sil2100: yep
[13:15] <sil2100> Ok, on it
[13:25] <sil2100> Trevinho: published
[13:40] <flexiondotorg> I'm in search of a sponsor for this - https://bugs.launchpad.net/ubuntu/+source/mate-menu/+bug/1570554
[13:40] <ubot5`> Launchpad bug 1570554 in mate-menu (Ubuntu) "Sync mate-menu 5.7.1-1 (universe) from Debian unstable (main)" [Undecided,New]
[13:40] <flexiondotorg> Can anyone help with that?
[13:47] <rbasak> flexiondotorg: are you sure bug 1568170 is suitable for a final freeze upload?
[13:47] <ubot5`> bug 1568170 in ubuntu-mate "add software boutique to advanced mate menu" [Medium,Fix committed] https://launchpad.net/bugs/1568170
[13:52] <bzoltan> hello folks, I have a package what I need in Xenial - https://requests.ci-train.ubuntu.com/#/ticket/1274 This does not bring new binaries and does not impact functionality. it is needed for the  application development as it provides the correct templates for the IDE. The LTS-Wily-Xenial SDK IDE is built from the xenial release of this package.
[13:53] <flexiondotorg> rbasak, I am.
[13:53] <flexiondotorg> rbasak, That feature was added in an earlier release but has a logic error.
[13:54] <flexiondotorg> It was someone reporting the idea of adding it that alerted me to the fact it wasn't working.
[13:55] <rbasak> OK. Well as it's you I'm happy to leave that between you and the release team.
[13:55] <rbasak> I'm happy to sync but https://launchpad.net/debian/+source/mate-menu doesn't show it there yet.
[13:55]  * rbasak wonders if he needs to wait or do some kind of fakesync or something.
[13:55] <cjwatson> dak has been broken.  If it's today-urgent, do a fakesync
[13:55] <flexiondotorg> I heard dinstall was broken yesterday.
[13:56] <flexiondotorg> But I saw it turn up hear - https://packages.debian.org/source/sid/mate-menu
[13:56] <flexiondotorg> So thought all was fine now.
[13:57] <cjwatson> $ curl -Is http://ftp.debian.org/debian/dists/sid/InRelease | grep ^Last-Modified:
[13:57] <cjwatson> Last-Modified: Fri, 15 Apr 2016 09:17:45 GMT
[13:57] <cjwatson> might actually work in a few hours then
[13:58] <rbasak> Better to wait or do a fakesync?
[13:59] <barry> i'm going to wait until later in my day to sync the couple i need.  if it doesn't come back by near my eod, i plan on fake syncing them
[13:59] <rbasak> flexiondotorg: btw, for next time, I don't believe "(LP:#1560332)" in debian/changelog works. You want a space there: "(LP: #1560332)" for automatic stuff to pick it up. Though you can just close the LP bugs manually once the fixes have landed.
[13:59] <ubot5`> Launchpad bug 1560332 in ubuntu-mate "MATE Menu - Advanced menu, preferences regression 16.04 beta 1" [Medium,Fix committed] https://launchpad.net/bugs/1560332
[13:59] <flexiondotorg> rbasak, That is the Debian Developer doing that when they upload.
[13:59] <flexiondotorg> I'll feed that back.
[13:59] <cjwatson> Uh.  https://packages.debian.org/source/sid/mate-menu matches https://launchpad.net/debian/+source/mate-menu
[14:00] <cjwatson> Both show 5.7.0-1, not 5.7.1-1
[14:00] <cjwatson> http://ftp.debian.org/debian/dists/sid/main/source/Sources.xz has 5.7.1-1, though
[14:00] <flexiondotorg> http://incoming.debian.org/debian-buildd/pool/main/m/mate-menu/
[14:01] <rbasak> https://tracker.debian.org/pkg/mate-menu seems to see 5.7.1-1 and I was able to dget from http://httpredir.debian.org/debian/pool/main/m/mate-menu/mate-menu_5.7.1-1.dsc
[14:01] <rbasak> So perhaps just publication delay?
[14:01] <rbasak> (and or pts/packages.d.o update delay)
[14:01] <cjwatson> There'll have been a significant publication delay due to dak breakage.
[14:02] <cjwatson> The next LP sync will be in a bit over two hours.
[14:02] <cjwatson> So we'll see ...
[14:05] <rbasak> flexiondotorg: ping me a bit later if I forget if you like?
[14:13] <flexiondotorg> rbasak, Thanks.
[14:49] <jamespage> infinity, pitti: some further information on https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1563714
[14:49] <ubot5`> Launchpad bug 1563714 in ceph (Ubuntu) "[FFe] Ceph Jewel stable release" [Undecided,Confirmed]
[14:49] <jamespage> discussed with sage  -  jewel release is likely to be wednesday, but I can't turnaround the packaging refresh and testing quick enough so I think a SRU when that's done is the best way forward...
[15:08] <flexiondotorg> The X2Go team ask me to file an FFe for X2Go client.
[15:08] <flexiondotorg> Can I get a release team ack?
[15:08] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/x2goclient/+bug/1569310
[15:08] <ubot5`> Launchpad bug 1569310 in x2goclient (Ubuntu) "FFe: Sync x2goclient 4.0.5.1-1 (universe) from Debian unstable (main)" [Undecided,New]
[15:49] <cjwatson> infinity: so, the libnss change; I have a feeling that we'll need to cherry-pick Aurelien's changes to d-i to use mklibs-copy everywhere and to drop libc* from build/pkg-lists/exclude.  What do you think?
[15:49] <cjwatson> infinity: (and your change to d-i to drop those udebs of course)
[15:52] <LocutusOfBorg> pretty please can anybody accept virtualbox?
[15:57] <cjwatson> infinity: I've uploaded fixes for everything else using libnss-*-udeb, modulo waiting for openssh to be syncable from unstable
[16:04] <LocutusOfBorg> infinity, please can you accept virtualbox?
[16:05] <LocutusOfBorg> we really need this one, to comply with xorg rootless on guests
[16:05] <LocutusOfBorg> I hoped on a new release before the freeze, but I can only have a patch for now
[16:20] <cjwatson> dak must be working again now, because Debian imports are; they're up to libg<something> now.
[16:20] <cjwatson> rbasak: ^-
[16:20] <cjwatson> Ah, you wanted mate-menu didn't you.
[16:20]  * cjwatson taps fingers
[16:23] <flexiondotorg> cjwatson, Thanks for checking. I just looked.
[16:23] <Odd_Bloke> infinity: FYI, we're hoping to get open-vm-tools in to the archive before we start spinning images; upstream have committed to supporting 10.0.7 (the version in -proposed) but not 10.0.0.
[16:24] <Odd_Bloke> infinity: (Where the "we" spinning images is all of us, because it's in the server ISOs as well as cloud images :)
[16:24] <cjwatson> rbasak,flexiondotorg: mate-menu 5.7.1-1 is there now
[16:25] <rbasak> cjwatson: thanks!
[16:26] <flexiondotorg> cjwatson, rbasak Thanks!
[16:26] <Odd_Bloke> infinity: Oh, I see you've seen that; rcj is doing some extra validation this morning (he's validated it once, but then Steve showed us how to do a better merge and he's re-testing the new version).
[16:27] <rbasak> flexiondotorg: ^^ synced
[16:29] <infinity> cjwatson: Yes, I was intending to take the mklibs-copy change.  Dependency changes shouldn't be necessary, I'd have thought, since libc-udeb provides nss-udeb*
[16:30] <cjwatson> infinity: Oh, so it does, I swear it didn't when I looked.  Still, they won't hurt.
[16:31] <cjwatson> infinity: The pkg-lists changes may be necessary to stop d-i FTBFSing after NBS cleanup (or maybe not, not certain).
[16:32] <infinity> cjwatson: The pkg-lists changes shouldn't be necessary either, but I'll do them to be more correct.
[16:33] <cjwatson> barry: ^- in case you didn't notice, Debian imports are back
[16:39] <flexiondotorg> rbasak, Thanks for taking care of that. I really appreciate it.
[16:40] <stokachu> hmm i uploaded juju-core-1_1.15.5 last night but i never got a email and i dont see it in the queue
[16:40] <stokachu> 1.25.5*
[16:40] <stokachu> is there any record of that version being uploaded and if it was rejected?
[16:41] <stokachu> was uploaded the same time as juju 2.0 beta4
[16:41] <marco-parillo> Odd_Bloke: Would that include open-vm-tools-desktop also?
[16:42] <rbasak> flexiondotorg: np, but note that the release team still need to review it since it's seeded
[16:42] <rbasak> flexiondotorg: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1
[16:42] <Odd_Bloke> marco-parillo: That would also include -desktop, yes.
[16:42] <flexiondotorg> rbasak, Noted.
[16:42] <ogra_`> stokachu, https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=juju (no idea why it is in rejected)
[16:43] <stokachu> hmm 1.25.5 is not there
[16:43] <stokachu> odd i didnt get any error emails or anything
[16:43] <stokachu> https://www.irccloud.com/pastebin/Ivr79tLk/
[16:43] <cjwatson> stokachu: one moment
[16:44] <stokachu> thanks
[16:44] <flexiondotorg> infinity, Can I request that mate-menu get a review please?
[16:45] <cjwatson> 2016-04-15 00:12:31 INFO    Failed to parse changes file '/srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20160415-001123-006217/ubuntu/juju-core-1_1.25.5-0ubuntu1_source.changes': GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20160415-001123-006217/ubuntu/juju-core-1_1.25.5-0ubuntu1_source.changes failed: Verification failed 3 times: ["(7, 9, u'No public key')", "(7,
[16:45] <cjwatson>  9, u'No public key')", "(7, 9, u'No ...
[16:45] <cjwatson> ... public key')"]
[16:45] <cjwatson> stokachu: ^- must have been a keyserver failure of some kind, please try reuploading
[16:46] <stokachu> cjwatson: ok thanks ill try now
[16:47] <cjwatson> unsatisfying failure, that, since that usually means "unsigned" but you've shown evidence that that wasn't the case
[16:47] <cjwatson> but I have no more telemetry on it
[16:47] <stokachu> it looks like it went through this time
[16:49] <infinity> cjwatson: Bah, again?
[16:50] <infinity> cjwatson: How many times (and with what interval) does it retry the keyserver?
[16:50] <infinity> cjwatson: This seems to have gotten decidedly more unreliable recently (or, it's just happening to whinier people recently, like me)
[16:50] <rbasak> infinity: opinion on bug 1570808 please? Worth getting into the release pocket?
[16:50] <ubot5`> bug 1570808 in mysql-5.7 (Ubuntu) "Security fixes from the April 2016 CPU" [Undecided,New] https://launchpad.net/bugs/1570808
[16:52] <infinity> rbasak: Probably valuable to at least evaluate getting .12 in, can you put it together and shove a diff somewhere?
[16:52] <rbasak> infinity: ack
[16:52] <infinity> rbasak: If it's too daunting to consider sanely QAing it before release, you can shunt it to the security team for a post-release security update.
[16:52] <cjwatson> infinity: three times, but zero interval.  I'm not sure whether the reliability has changed particularly, I've always been a bit suspicious of this
[16:53] <infinity> cjwatson: It's entirely possible it's always been this reliable and it's just happening to more vocal people lately.  Randomness is random.
[16:53] <rbasak> infinity: QA for MySQL (upstream code, not packaging) consists of build tests and dep8. I'm confident in upstream and the test coverage. We have yet to find a regression in that.
[16:53] <rbasak> infinity: would you be happy with that?
[16:53] <infinity> rbasak: Probably, but I'd like to see the diff anyway.
[16:53] <rbasak> OK
[16:56] <infinity> cjwatson: Is there a proxy or something masking the difference between "no key found to match your query" and "keyserver is busted", or is that process just blatantly ignoring the difference?
[16:57] <infinity> cjwatson: (Or is our keyserver actually failing in such a subtle way that it's returning "no key" when it's actually sad?)
[16:59] <infinity> cjwatson: I suppose on the roadmap for "make launchpad stop assuming all networks and services are 100% reliable", one could also argue that working off local keyring exports wouldn't be stupid (though introduces an unfortunate delay between making changes and seeing them).
[17:01] <cjwatson> infinity: I'm not sure what the problem is.  The first step would have to be more verbose logging.
[17:04] <infinity> cjwatson: Righto.  Well, I'm sure you have tons more important things to tackle, but some day this would be nice to understand.
[17:07] <cjwatson> infinity: Yep, so my current project is auto-uploading snaps to the store, then after that Mark asked for github bug linking a while back and we probably ought to keep him happy :-), but after that things are looking promising for being able to tackle some of the chunkier bits of backlog.
[17:09] <rbasak> cjwatson: github bug linking> ah, the server team were going to ask you for that. I guess we don't need to then? :)
[17:09] <rbasak> (there is a bug on it I believe)
[17:09] <infinity> cjwatson: Bug linking in Malone, or URLification of some github: #123 string?
[17:09] <cjwatson> rbasak: Indeed
[17:09] <cjwatson> infinity: the former
[17:09] <cjwatson> like debbugs references and such
[17:10] <rbasak> bug 848666 is it
[17:10] <ubot5`> bug 848666 in Launchpad itself "Support GitHub issues as external bugtracker" [Low,Triaged] https://launchpad.net/bugs/848666
[17:10] <cjwatson> yes, I know
[17:10] <rbasak> jgrimm: ^^
[17:10] <rbasak> Cool, thanks :)
[17:10] <infinity> cjwatson: Aww, kay.  If it was the latter, I was going to ask for proper support for genchanges bug parsing in the URLification code so we can link Debian bugs in changelogs. :P
[17:10] <jgrimm> rbasak, nice
[17:10] <infinity> But since you're not mucking around in that code, nevermind.
[17:11] <cjwatson> infinity: yes, I see you filed https://bugs.launchpad.net/launchpad/+bug/1481471 on that
[17:11] <ubot5`> Launchpad bug 1481471 in Launchpad itself "Please linkify Debian bug closures on parsed changelogs" [Low,Triaged]
[17:12] <cjwatson> infinity: remind me at the release sprint
[17:14] <rbasak> infinity: got a fix for apache2 that we think is fine for a 0-day. Do you want it in the queue or should I wait before uploading next week?
[17:16] <infinity> rbasak: In the queue.
[17:26] <infinity> doko: What's with the change to debian/control.powerpc.in ?
[17:26] <doko> infinity, unused file
[17:27] <infinity> doko: Okay, so biarch bits aren't being dropped from powerpc-cross?
[17:27] <doko> no
[17:27] <infinity> doko: Excellent.  Thanks.
[17:28] <doko> infinity, btw, I'm building a gccgo-6 6.0.1 in my ppa, release candidate 1. no go/libgo or libgcc changes. will wait for the test results before asking for FFe ...
[17:32]  * infinity goes to see if Tim Horton's produces a coffee with the approximate volume of a small child.
[17:36] <Odd_Bloke> #JustCanadianThings
[17:53] <cyphermox> infinity: there used to be the SuperTim, for the barrel-sized coffees, but I'm not sure they still do that
[17:53] <cyphermox> I still have a container for it ;)
[17:59] <wxl> infinity: hey with the delay of the rc, we're still planning on a normal final release date, correct?
[17:59] <rcj> Odd_Bloke, infinity: open-vm-tools in -proposed looks good.  Test results in bug #1558198.  Hoping to get this out of -proposed before image builds start as Odd_Bloke was saying earlier.
[17:59] <ubot5`> bug 1558198 in open-vm-tools (Ubuntu) "[FFE] sync open-vm-tools from Debian for Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1558198
[18:00] <infinity> wxl: What delay?
[18:00] <infinity> wxl: This is exactly how it's gone for several cycles.
[18:01] <wxl> infinity: well, RC was supposed to be released yesterday?
[18:01] <infinity> wxl: release candidates start "after final freeze", but it's never been immediately after.
[18:01] <wxl> infinity: k, thx
[18:02] <infinity> wxl: None of that should stop people from testing dailies, though.  Find bugs now and we can fix them before release.  Don't test until something is an "RC", and well, it's not much of an RC.
[18:03] <nacc> infinity: i think it's a confusion due to the releaseschedule page -- i've seen a few similar queries in #ubuntu since yesterday
[18:03] <nacc> https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule indicates April 14th is "the" ("a"?) ReleaseCandidate
[18:04] <infinity> nacc: Clicking the link helps.
[18:04] <infinity> nacc: We don't release "a release candidate".
[18:04] <wxl> nacc: it's confusing because none of the rc's for other milestones are put on the schedule
[18:04] <nacc> infinity: yes, but why put something on the schedule that doesn't exist?
[18:04] <wxl> and it does exist
[18:05] <wxl> it's just not released in the same way as the actual milestones
[18:05] <infinity> I could rename it "release week", I suppose.
[18:05]  * infinity shrugs.
[18:05] <nacc> yeah, i guess it's a varied difference of "it" :)
[18:05] <wxl> i like that, infinity
[18:05] <wxl> because i've had this argument with several people over time
[18:05] <nacc> infinity: it may not matter, i was just trying to figure out if there was a good answer to give ... will just point to the text there
[18:05] <wxl> i thought at some point we DID stop calling it an RC but i guess not
[18:06] <wxl> i mean by that notion every daily image is an rc
[18:06] <wxl> release week implies a sustained effort towards getting all the last minute showstoppers taken care of immediately
[18:06] <wxl> and implies an impending deadline
[18:17] <cjwatson> every daily image isn't an rc because there isn't generally a possibility that we might stop and call it done at that point
[18:17] <cjwatson> but during release week there is such a possibility, getting less theoretical as the week goes on
[18:17] <wxl> that's entirely logical
[18:18] <wxl> but i think at least some folks seem to think rc is a milestone
[18:18] <cjwatson> the reason we don't release a separate RC as such any more is that we used to have a thing that was actually labelled "Release Candidate" on the image itself, which could therefore never be an actual candidate for release since we were always going to have to at minimum rebuild it to get rid of the "candidate" label
[18:18] <wxl> maybe this is because some other projects consider rc a release
[18:18] <wxl> ?
[18:19] <wxl> i don't think the idea of "release week" necessarily violates what the intention of the rc is, right, cjwatson ?
[18:19] <cjwatson> people think all sorts of things, I don't think we necessarily need to worry about some of them being wrong; especially since people treating "RC" as a milestone is basically a good thing, better than them aiming for release
[18:19] <infinity> Could we bikeshed about this when we're not all busy doing the actual work involved in release week? :P
[18:19] <cjwatson> I'm not going to obsess about correcting everyone who gets it wrong
[18:19] <wxl> yuuup :)
[18:56] <infinity> Laney: What's with the uploader path leakage in gnome-software/data/featured.ini?
[18:57] <infinity> Laney: Kinda gross, kinda noisy, and curious if it also affects the built binaries?
[18:58] <infinity> Laney: (for example)
[18:58] <infinity> -background=url('/home/laney/jhbuild/install/share/gnome-software/featured-polari.svg') 70% 80% / 120% auto no-repeat, #43a570
[18:58] <infinity> +background=url('/home/william/Code/jhbuild/install/share/gnome-software/featured-polari.svg') 70% 80% / 120% auto no-repeat, #43a570
[18:58] <infinity>  stroke=#4e9a06
[19:00] <Odd_Bloke> infinity: Sorry to keep bugging you about open-vm-tools, but we aren't sure who else to bug (^_^); what needs to happen for us to unblock it in to the archive?
[19:01] <Odd_Bloke> infinity: (I tried bugging slangasek which worked yesterday, but he's OOO today :p)
[19:02] <infinity> Odd_Bloke: Nothing.  It'll migrate in the next run.
[19:05] <Odd_Bloke> infinity: <3
[19:07] <cyphermox> infinity: freetype ^ will still need a no-change rebuild of grub2, and then grub2-signed of course
[19:10] <infinity> pitti: Two langpacks seem to have gone AWOL?
[19:11] <infinity> pitti: gnome-bs-base and gnome-sk didn't get updated with gnome-bs and gnome-sk-base, looks like.
[19:12] <flexiondotorg> Can someone review mate-menu please.
[19:12] <infinity> flexiondotorg: We'll get there.
[19:12] <flexiondotorg> Roger.
[19:15] <infinity> jdstrand: appnames can start with [a-z0-9] but use upper case from the second char on?
[19:15] <infinity> jdstrand: Why the restriction on the first char?
[19:15] <infinity> jdstrand: Or is that a bug in your patch (and test)?
[19:17] <jdstrand> infinity: it's a cheap test, but after discovering bug #1571048, why don't you hold off on that. it will have a super small patch too and I can refine the appname test
[19:17] <ubot5`> bug 1571048 in ubuntu-core-launcher (Ubuntu) "ubuntu-core-launcher querying udev for wrong name" [High,In progress] https://launchpad.net/bugs/1571048
[19:17] <infinity> jdstrand: The test (network-manager.NetworkManager) sort of implies that UpperCase is only allowed after the first '.', which the regex doesn't enforce.  If it's allowed before the first '.', I'm not sure why it wouldn't be allowed in the first char.
[19:18] <infinity> jdstrand: Perhaps a comment block above the regex that desribes the spec it's meant to be implementing wouldn't go amiss. ;)
[19:18] <jdstrand> sure
[19:19] <jdstrand> feel free to reject that one since I'll have another in a few minutes
[19:19] <infinity> jdstrand: Just did.
[19:22] <infinity> jdstrand: If this is Java-style vendor namespaces, I'd assume the regex should perhaps express uppercase is allowed after the *last* period, or in the entire name in the absense of periods.
[19:23] <jdstrand> it isn't that
[19:23] <jdstrand> I'll document it
[19:23] <infinity> jdstrand: ie: net.company.MyCoolApp or company.MyCoolApp but not Company.MyCoolApp
[19:23] <infinity> jdstrand: Okay.  Document away. :)
[19:24] <jdstrand> it is sorta that, but anyhoo, I'll document
[19:24] <infinity> (In the above example, I'd assume a bare 'MyCoolApp' without namespace would also be okay)
[19:58] <seb128> infinity, seems like the gnome-software issue is something to look at but it's nothing due to the update so shouldn't block it imho
[19:59] <seb128> if you want somebody to look at it now better to ping attente though, it's friday evening for Laney
[19:59] <infinity> seb128: No, indeed, it's exposing a (potential) existing bug, not adding one.
[19:59] <infinity> seb128: It's not blocking the review, was just a "WTF" I noticed in passing.
[20:00] <seb128> k, since you didn't accept the update I was unsure if that made you skip it waiting for a reply
[20:02] <slangasek> infinity: yes, I prefer resurrecting lsb-core to touching glibc again.
[20:03] <infinity> slangasek: Oh, fresh packageset run after your fiddling: http://lucifer.0c3.net/~adconrad/packageset-changes-new.txt
[20:04] <slangasek> infinity: also, if you're sorting lsb-core, do you want to trade that to Till for fixing his outstanding MIR?  (Do we really need two separate braille renderers being pulled in by default from cups?)
[20:04] <slangasek> infinity: cool. anything on there that bothers you?
[20:04] <slangasek> I'd suggest it should go out to ubuntu-devel for review
[20:05] <infinity> slangasek: Hard to say, given the unreadable mess of the format.  Haven't had a chance to read it all yet.
[20:06] <slangasek> k
[20:06] <infinity> slangasek: As for Till's MIR, you mean https://bugs.launchpad.net/ubuntu/+source/liblouisutdml/+bug/1564058 ?
[20:06] <ubot5`> Launchpad bug 1564058 in liblouisutdml (Ubuntu) "[MIR] liblouisutdml" [Undecided,Incomplete]
[20:07] <slangasek> infinity: yes
[21:12] <LocutusOfBorg> still no accepted virtualbox :'(
[21:13] <infinity> LocutusOfBorg: Oh, I was waiting for you to pop up.
[21:14] <infinity> LocutusOfBorg: Any meaningful reason (the control tweak doesn't seem to matter) to take your -3build1 upload rather than just syncing -3?
[21:14] <infinity> LocutusOfBorg: -3build1 is a lie anyway, since it contains a change from Debian. :P
[21:15] <Ukikie> IIRC, at the time it was in incoming/
[21:28] <LocutusOfBorg> infinity, broken dak
[21:28] <LocutusOfBorg> was the reason
[21:28] <LocutusOfBorg> if you reject I can sync from experimental
[21:28] <LocutusOfBorg> and I don't know how much time I have for it
[21:29] <LocutusOfBorg> ok sync request done
[21:37] <LocutusOfBorg> <3
[21:37] <LocutusOfBorg> I still hope to have a 5.0.18 in time for xenial
[21:38] <LocutusOfBorg> this version is something in the middle
[21:51] <mgz_> I have an autopkgtest problem. the ubuntu run fails, but my local version does not. is there a way to rerun the tests with more debug stuff without actually making a new package and uploading it just to do that?
[21:52] <infinity> No, but you can run it locally the same way it's being run remotely...
[21:53] <mgz_> I did, as far as I was able
[21:53] <mgz_> I guess I can try and get a big enough machine for the qemu virt server instead
[21:54] <infinity> 2016-04-15 07:59:47 ERROR cmd supercommand.go:448 Get https://10.0.8.1:8443/1.0/profiles: Forbidden
[21:54] <infinity> That seems like something that shouldn't be too hard to reproduce...
[21:54] <mgz_> yup. passes on a canonistack vm, works in manual testing.
[21:55] <mgz_> didn't get any good ideas from the lxd team.
[21:55] <mgz_> it's almost certainly something small and dumb, but I have no idea what.
[21:59] <flexiondotorg> infinity, Thanks!
[22:06] <flexiondotorg> infinity, The X2Go team asked me to file this FFe on their behalf. Any chance of an ack?
[22:06] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/x2goclient/+bug/1569310
[22:06] <ubot5`> Launchpad bug 1569310 in x2goclient (Ubuntu) "FFe: Sync x2goclient 4.0.5.1-1 (universe) from Debian unstable (main)" [Undecided,New]
[22:06] <flexiondotorg> It is not need to the images, but they'd like it in the official archive because translations are fixed.
[22:10] <mgz_> infinity: if I have a test packaging change that might help but I'm not certain, will you accept the package?
[22:10] <infinity> flexiondotorg: ^
[22:11] <infinity> mgz_: Maybe?
[22:11] <flexiondotorg> infinity, Thanks.
[22:11] <infinity> mgz_: Would be nicer if you knew it fixed it. :P
[22:11] <seb128> ^ the theme update there has small calendar app/widget fixes and one changeset that updates some suru icon which is touch specific (so should be fine/not impact on any desktop env)
[22:12] <flexiondotorg> infinity, And if I'm not being too cheeky (which I know I am) this is the last from me.
[22:12] <flexiondotorg> https://bugs.launchpad.net/bugs/1570874
[22:12] <ubot5`> Launchpad bug 1570874 in engrampa (Ubuntu) "Sync engrampa 1.12.0-2 (universe) from Debian unstable (main)" [Undecided,New]
[22:12] <flexiondotorg> Bug fix for working with p7zip.
[22:13] <flexiondotorg> I'll let the X2Go guys know, they'll be very pleased :-)
[22:15] <mgz_> infinity: well, I need to find someone to upload it too, so I guess getting anything done is just maybe
[22:52]  * infinity lunches.
[23:27] <flocculant> infinity: ummm
[23:27] <flocculant> just triple checked
[23:30] <flocculant> built a usb with 'disks' went straight to desktop - no try/choose window - no idea if accessibility is working or an option at that point
[23:31] <Kamilion> oh, awesome, thanks for getting x2go sorted, flexiondotorg