[01:04] <infinity> doko: hhvm now fails with http://paste.ubuntu.com/16058278/ which doesn't immediately seem pic/pie related...
[01:06]  * infinity tests something.
[01:07] <infinity> tyhicks: https://launchpad.net/ubuntu/+source/grub2/2.02~beta2-36ubuntu4 <-- All looks good now.
[01:07] <infinity> tyhicks: I'll accept -signed from the rejected queue when all my UEFI bits are in.
[01:08] <infinity> sbeattie: ^
[01:09] <sbeattie> infinity: thanks!
[01:47] <infinity> sbeattie: ^
[01:48] <sbeattie> thanks! /me does a happy dance
[03:36] <infinity> bdmurray: Ah-ha.  Took me a while to reproduce that dpkg bug.  It only hits when /bin/sh is bash (which is probably why we don't have a bazillion duplicates)
[03:36] <infinity> bdmurray: Verified now with my testcase that the proposed dpkg fixes it.
[03:40] <infinity> bdmurray: Fasstracked that dpkg update through, based on manual testing and autpkgtests looking clean.  You're clear for the ubuntu-release-upgrader update whenever.
[05:43] <slangasek> infinity: uhm? how did we get *any* reports of a bug that requires /bin/sh to be bash, and why would we consider that an SRUable bug instead of user error?
[08:08] <cpaelzer> I just realized that we are in SRU mode for xenial seeing the DPDK upload in unapproved and quickly added a proper SRU template for the bugs 1546565 , bug 1570466 and bug 1570195
[08:08] <ubot5> bug 1546565 in openvswitch-dpdk (Ubuntu) "Ownership/Permissions of vhost_user sockets for openvswitch-dpdk make them unusable by libvirt/qemu/kvm" [High,Triaged] https://launchpad.net/bugs/1546565
[08:08] <ubot5> bug 1570466 in dpdk (Ubuntu) "Adding/removing ports leaks memory in dpdk" [High,Triaged] https://launchpad.net/bugs/1570466
[08:08] <ubot5> bug 1570195 in linux (Ubuntu) "Net tools cause kernel soft lockup after DPDK touched VirtIO-pci devices" [Medium,Confirmed] https://launchpad.net/bugs/1570195
[08:08] <cpaelzer> sorry, next time the SRU template should be there before the upload
[08:09]  * cpaelzer is changing xenial upload mode to SRU ...
[08:48] <cking> hi there, thermald 1.4.3-5~14.04.3 is in trusty -proposed, but it contains a bug, can that be rejected for me?
[08:50] <smb> cking, I think what I meant was let  	1.4.3-5~14.04.4 in unapproved get rejected
[08:51] <cking> ah, please ignore my initial comment folks :-/
[08:52] <smb> Which is mostly because you said you did not include all the changes between 14.04.2 and 14.04.4 in the changelog of .4
[08:52] <cking> smb, ack
[09:02] <smb> apw, are you already with enough powers to reject cking 's older thermald  	1.4.3-5~14.04.4 from Trusty's unapproved queue?
[09:03] <apw> cking, you presumably do want this double thermald rejected ?
[09:03] <smb> apw, the 21 hours ago one
[09:03] <cking> the first one to be removed, leave the latest
[09:07] <cking> tbanks apw
=== seb128_ is now known as seb128
[09:54] <Odd_Bloke> Could someone migrate gce-utils 1.3.3-0ubuntu4 from yakkety partner-proposed to partner, please?
[10:12] <Odd_Bloke> Also, if a member of the SRU team could review the cloud-init waiting in https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text= it would be much appreciated. :)
[10:14] <pitti> doko: icu and rdepends are currently landing \o/
[10:15] <xnox> pitti, yeah, thanks
[10:16] <doko> ahh, I got emails ...
[10:29] <pitti> ah, yakkety got unfrozen? I just synced apt and that went straight through
[10:30] <pitti> hmm, https://launchpad.net/ubuntu/yakkety still says "frozen"
[10:31] <Laney> guess somebody is speed reviewing the queue...
[10:31] <apw> not me
[10:31] <pitti> there's tons of other and much less harmful stuff in there
[10:32] <pitti> (not that apt is known-broken, but I would have expected it to go in when we open)
[10:34] <mwhudson> someone is definitely reviewing things in the queue
[10:34] <mwhudson> i wonder who it is :-)
[10:34] <pitti> I did the xenial SRUs earlier on, but not yakkety
[10:41] <xnox> pitti, it would be nice for gcc-5 to migrate to yakkety to, such that people get the right compiler in release pocket, with pie enabled.
[10:41] <xnox> *too,
[10:43] <pitti> xnox: ok; linux will most probably fail anyway due to the timeout, and binutils/i386 passed against the previous ubuntu1
[10:43] <pitti> xnox: so if it's urgent, I can hint it in
[10:45] <doko> libpng demoted \o/
[10:46] <xnox> pitti, not urgent, as i guess infinity will be the one to open and say "we have pie, have fun"
[10:48] <ogra_> infinity, hmm, did you not release ubuntu-core tarballs for xenial ?
[10:48] <apw> that was rather instant approval too
[10:53] <doko> pitti, xnox: yes, gcc-5/gcc-6 would be good to have ...
[10:54] <pitti> doko: gcc-5 hinted; is there any urgency wrt. fast-tracking -6?
[10:55] <doko> hmm, no
[10:55] <apw> pitti, what does the separation of ADT testing into by package and by package version mean
[10:56] <doko> xnox: looking at boost-defaults failing autopkg tests ... are these all real?
[10:57] <pitti> apw: britney now suppresses the package version for excuse lines which all just have "in progress", as it's not easy to predict which version it is going to be (and it was often wrong, which is why I did that)
[10:57] <pitti> apw: in most cases that "unifies" lines properly, but this doesn't seem to work sometimes so that you get two lines
[10:57] <pitti> just a cosmetical issue
[10:57] <apw> pitti, so they are "currently undecided versions" that seems sensible enough
[11:01] <doko> xnox, ugh, this looks like a boost issue ... https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/c/compute/20160423_162855@/log.gz
[11:19] <ogra_> infinity, ignore that, found them
[11:41] <xnox> doko, horum weird yes.
[12:08] <LocutusOfBorg> [13:10:30] <LocutusOfBorg> hi, please accept crossguid, wrt libpng transition
[12:08] <LocutusOfBorg> [13:10:35] <LocutusOfBorg> (unblocking kodi)
[12:09] <LocutusOfBorg> thanks!
[12:47] <xnox> thanks to willy glibc security upload, we will have autopkgtest for yakkety in approximately never =)
[12:49] <Odd_Bloke> arges: o/  Do you have a couple of minutes to review https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text= and accept it?
[12:50] <arges> Odd_Bloke: cloud-init i see. ok
[12:51] <Odd_Bloke> arges: This is a backport of stuff that's already been SRU'd to wily/trusty; and smoser reviewed it before sponsoring the upload.
[12:57] <arges> Odd_Bloke: ok done
[12:57] <Odd_Bloke> arges: Thanks!
[14:01] <xnox> doko, after https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.7+dfsg-5ubuntu4 builds qt4 moc things that fail with BOOST_JOIN errors should be better.
[14:31] <marcoceppi> congrats all on a great release! I have some questions about getting a micro release of a tool into universe. charm 2.1.1 is in xenial and I'd like to submit 2.1.2 - is the first step to upload to yakkety then request an SRU?
[14:51] <slangasek> marcoceppi: does the project have a microrelease policy that fits with https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases ?  Are you going to be doing enough of these, and is the delta large enough, to make it less time-consuming for you to go through the MRE process instead of doing discrete SRU bugs for each of the changes included upstream?
[14:52] <slangasek> marcoceppi: we would certainly want it in yakkety before SRU to xenial, but in terms of first steps, I think the above is probably more relevant :)
[14:54] <slangasek> doko: libpng seems to have been pre-demoted, is that you?  any particular reason for a pre-demotion?
[14:56] <doko> slangasek, yeah, I see cairo is unhappy
[14:57] <slangasek> it's unhappy, so you demoted?
[14:57] <doko> re-promoted
[14:57] <slangasek> or you mean you demoted thinking everything was done and see cairo is still unhappy
[14:58] <slangasek> ok
[14:58] <doko> pitti, please override the cairo/libreoffice/s390x autopkg test. then cairo can migrate
[15:02] <slangasek> pitti's not the only one who can override that, you know ;)  but in this case it may not be worth it, the test should be done momentarily
[15:07] <infinity> slangasek: /bin/sh -> bash is only a "dpkg-reconfigure dash" away.  If you want to call that user error, we'd need to cripple that a bit, I think, or warn against it, or whatever.
[15:07] <infinity> slangasek: I've always considered it entirely valid for /bin/sh to be bash or dash.
[15:07] <infinity> slangasek: Either way, the dpkg bug was still a bug. :P
[15:07] <slangasek> infinity: I consider reconfiguring your system to use bash as /bin/sh to be foot-shooting and we should not support it.
[15:08] <infinity> slangasek: Oh, I'm also not sure if we ever forcefully switched people?
[15:09] <infinity> slangasek: Like, if you've upgraded since hoary...
[15:09] <ogra_> i think update-manager had code ...
[15:09] <ogra_> but that was plenty of releases ago
[15:10] <infinity> Either way, bad shell is bad shell.  I'm more confused by dash's behaviour there, to be honest.
[15:13] <doko> infinity, from my point of view we can open the archive
[15:13] <infinity> doko: \o/.
[15:13] <infinity> doko: Did you want to do the honors on the email?
[15:13] <doko> yep, already prepared
[15:13] <infinity> Check.
=== infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.4, Xenial 16.04 | Archive: open | Xenial Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
[15:14] <infinity> doko: Mail away.
[15:15] <cjwatson> Shall I enable auto-sync?
[15:15] <doko> please do
[15:15] <infinity> cjwatson: I'm going to create-missing-builds first.
[15:15] <infinity> cjwatson: Then I was going to turn on autosync.
[15:15] <infinity> After that churn's done retrying.
[15:16] <cjwatson> OK, leaving it off for now then.
[15:16] <cjwatson> Not that I think the order matters much; it can just all be slung into the pot.
[15:17] <infinity> It sort of matters from an upload order perspective.  If any of the autosyncs rely on any of these broken builds and they magically now succeed.
[15:17] <infinity> But yeah, the odds are low. :P
[15:17] <infinity> Anyhow, running now.
[15:22] <teward> infinity: hate to throw more onto your plate - nginx 1.10.0 is now out, evidenced by my yakkety upload for it, can we SRU that version string change for Xenial?  (https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1575212) ^
[15:22] <ubot5> Ubuntu bug 1575212 in nginx (Ubuntu Xenial) "[Xenial] [SRU] Update nginx to 1.10.0" [Wishlist,In progress]
[15:37] <infinity> teward: Diff looks clean, absolutely let's SRU that.
[15:40] <doko> what's the plan with the ci-train any yakkety?
[15:40] <teward> infinity: wonderful!  it's sitting in unapproved queue right now for xenial-proposed :)
[15:41] <infinity> robru: ^-- ci-train, is it yakketyful?
[15:41] <apw> infinity, wow that wasn't missing <sarcasm> tags, it really is empty
[15:42] <infinity> apw: Every once in a while, things go right. :)
[15:43] <infinity> And the 1.9.x -> 1.10 gamble appears to have paid off for nginx.
[15:43] <apw> teward, the changelog says there is a refreshed patch in there, but no delta for it
[15:43] <infinity> apw: I see it.
[15:43] <infinity> apw: Perhaps you're slightly blind?
[15:43] <teward> apw: http://launchpadlibrarian.net/256470908/nginx_1.9.15-0ubuntu1_1.10.0-0ubuntu0.16.04.1.diff.gz
[15:43] <slangasek> infinity, doko: robru is out right now.  there is a question of how it will be yakketified, I was just talking to sil2100 about that
[15:43] <teward> apw: find "debian/patches"
[15:44] <teward> apw: or, second-to-last change set in that patch
[15:44] <apw> <- emulating a bag of rocks ...
[15:44] <apw> thanks
[15:44] <slangasek> because we're now in a transitional period between vivid and xenial for the phone images, in addition to needing to land to devel
[15:44] <cjwatson> whee, all the builds
[15:45] <teward> infinity: indeed, the 1.9.x -> 1.10 gamble did pay off.  In this case, nothing to add between 1.9.15 and 1.10.0, i think that's why 1.10.0 was pushed a week?
[15:45] <infinity> slangasek: So, triple landings until we can kill vivid? :P
[15:45] <teward> infinity: glad to see it's there though :)
[15:45] <slangasek> infinity: I've insinuated that triple landings might be a horrible idea.  But we'll see what the phone team decides to do
[15:45] <slangasek> (my recommendation is dual landings for xenial+yakkety and force all projects to create a vivid branch)
[15:46] <infinity> slangasek: That might put pressure on to make the move to xenial faster, which I wouldn't be against.
[15:46] <infinity> slangasek: Perhaps intentionally making vivid landings a bit harder is the way to get movement.
[15:47] <bdmurray> infinity: I've verified that the ubuntu-release-upgrader in xenial-proposed won't allow upgrades with the old versions of apt or dpkg.  I think slangasek wants to verify bug 1572416 too though.
[15:47] <ubot5> bug 1572416 in ubuntu-release-upgrader (Ubuntu Xenial) "do-release-upgrade crashes in Greek locale" [High,In progress] https://launchpad.net/bugs/1572416
[15:47] <infinity> Why is it always greek?
[15:47] <seb128> slangasek, infinity, it's just means triple landing, just done with extra steps and more vcs
[15:47] <seb128> also they are wanting to move
[15:47] <infinity> Oh, cause it's an Alkis bug.
[15:48] <seb128> just didn't solve the gcc ABI break and how to deal with the store
[15:48] <seb128> well that + getting the image back in shape
[15:48] <seb128> but that is easy enough in principle
[15:48] <seb128> just work
[15:48] <slangasek> infinity: IMHO the best argument for splitting instead of doing triple landings is to make xenial landings /easier/, instead of requiring them to all maintain compatibility on the vivid branch
[15:48] <infinity> slangasek: Yes, also a fair argument.
[16:01] <slangasek> pitti: this channel also exists and gets used for sru discussions ;)
[16:02] <pitti> slangasek: *shrug* too many channels :)
[16:02] <slangasek> yeah, but infinity and bdmurray just discussed u-r-u above :)
[16:03] <bdmurray> slangasek: should we wait to test your fix? pitti thinks we should release it asap
[16:03] <pitti> well, I wasn't saying "right now", I just wanted to know the procedure
[16:03] <pitti> ISTR that in the past there was some extra magic for the u-r-u tarballs
[16:04] <pitti> but shortening the 7 day period seems adequate
[16:05] <bdmurray> The meta-release file may need to be modified to point at -updates.
[16:06] <bdmurray> pitti: so that could be the extra magic
[16:13] <mapreri> can i point an archive admin on the rm @ lp #1575255 ?  that thing is blocking libreoffice-dictionaries migration.
[16:13] <ubot5> Launchpad bug 1575255 in hunspell-sv (Ubuntu) "RM: hunspell-sv -- obsolate; replaced by hunspell-sv from libreoffice-dictionaries" [Undecided,New] https://launchpad.net/bugs/1575255
[16:16] <marcoceppi> slangasek: I don't have an autopackage, but it follows everything else. We're just having to constantly chase juju, and I expect we'll have 3-5 micro releases to push into a release every 6 months - maybe an MRE is the way to go
[16:56] <xnox> doko, [2] is left as an exercise for the reader? =)
[16:57] <slangasek> marcoceppi: ok, sounds reasonable.  We're going to want some documentation/discussion of /how/ this package meets those MRE requirements; can you post to ubuntu-release@ about it?
[17:00] <jcastro> marcoceppi: I am gathering those requirements now
[17:01] <jcastro> slangasek: we should have something to post to the list by eod
[17:01] <slangasek> cool
[17:01] <teward> infinity: to get the SRU moved, do we just have to get the nginx upload out of the unapproved queue for Xenial, to make it land?
[17:02] <infinity> teward: You have to exercise patience.
[17:02] <teward> infinity: ack
[17:02] <infinity> teward: But yes, I'll get it into -proposed.  Then you need to do some testing to say "yup, still not broken".  Then we can promote it.
[17:02] <teward> infinity: my apologies, i've got one of those 'limited patience' mindsets today :/
[17:02] <teward> infinity: ack
[17:02] <infinity> teward: And if there are autopkgtests that trigger, we'll look at those too.
[17:02] <teward> how fortunate i have multiple Xenial VPSes now to test with :p
[17:03] <teward> ack
[17:03] <infinity> teward: Given the exactly zero code changes, there's no specific things we need to test, except to test that it, indeed, still functions and passes whatever tests we already have.
[17:03] <teward> yup
[17:04] <infinity> teward: Well, I guess there's one code change.  You could test the version banner is correct. :P
[17:04] <infinity> teward: But if it's not, I'd be VERY surprised and confused. :)
[17:04] <teward> heheh, indeed.
[17:04] <teward> definitely, I'd be equally confused
[17:13] <mapreri> infinity: do you have some seconds to process an RM?
[17:14] <robru> infinity: slangasek oh i can yakify it in just a minute
[17:14] <infinity> mapreri: Maybe?
[17:14] <mapreri> infinity: that would be ♥! #1575255
[17:16] <robru> slangasek: what's the plan? dual silos should become yakkity+vivid?
[17:17] <infinity> mapreri: It's still seeded all over, will need to fix that first.  But I can sort that in a bit, since I have all the seeds here.
[17:18] <mapreri> ah, right, forgot to run seeded-in-ubuntu ...
[17:18] <slangasek> robru: no, not exactly.  You'll need to find out from sil2100 what the final decision has been
[17:18] <infinity> cyphermox: Why the whacky versioning on those klibc uploads?
[17:18] <mapreri> infinity: thanks for that!  (as fixing the seed for me would mean pinging people anyway) :)
[17:18] <cyphermox> infinity: is it that wacky?
[17:19] <infinity> cyphermox: Yeah.  Should be 2.0.4-8ubuntu1.1, 2.0.3-0ubuntu1.1, 2.0.3-0ubuntu1.0.1
[17:19] <infinity> cyphermox: Normally, anyway.
[17:19] <cyphermox> bah
[17:19] <cyphermox> reject them and I can reupload
[17:20] <infinity> cyphermox: -NubuntuN.$release tends to imply identical code backporty things.
[17:20] <mapreri> infinity: umh, `seeded-in-ubuntu myspell-sv-se` and `seeded-in-ubuntu hunspell-sv-se` return nothing here, though.
[17:20] <infinity> (Not that we have hard rules about this)
[17:20] <infinity> mapreri: seeded-in-ubuntu takes source arguments, not binary.
[17:20] <mapreri> meh.
[17:21] <cyphermox> infinity: it's the exact same patch/diff on different releases, which do have the same original code
[17:21] <infinity> mapreri: Or, I can bypass the tool with:
[17:21] <infinity> (base)adconrad@nosferatu:~/backup/adconrad/backup/adconrad/build/seeds$ rgrep myspell-sv-se | grep yakkety
[17:21] <infinity> ubuntu-gnome.yakkety/supported: * myspell-sv-se
[17:21] <infinity> ubuntukylin.yakkety/supported: * myspell-sv-se
[17:21] <infinity> ubuntu.yakkety/supported: * myspell-sv-se
[17:21] <infinity> edubuntu.yakkety/dvd-langsupport: * myspell-sv-se
[17:22] <mapreri> `seeded-in-ubuntu hunspell-sv` returns only ubuntu, ubuntu-gnome, ubuntukylin, no edubuntu.
[17:22] <infinity> cyphermox: I mean we tend to use that versioning when the upstream version is the same on all releases (firefox and tzdata come to mind).
[17:22] <mapreri> so fun.
[17:22] <infinity> mapreri: edubuntu is half dead/dying, the tool might be smarter than my seed checkout in that regard. :)
[17:22] <mapreri> :>
[17:23] <cyphermox> infinity: the upstream version on trusty and wily is the same
[17:23] <cyphermox> (well, so is the revision too)
[17:23] <infinity> cyphermox: Yeah, I know.  Meh.  I'm not super picky either way.  The security team would do that the way I said above, but they're also not the only source for version standardisation, as we have no real standard. :)
[17:23] <cyphermox> I may be again working with older doc, but I'm more or less following https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[17:24] <cyphermox> right
[17:24] <cyphermox> I don't care either way, I used this because it's a mental shortcut when I was preparing backports just before.
[17:24] <infinity> They don't even follow their own rules all the time. :)
[17:24] <cyphermox> hehe
[17:24] <infinity> (See recent glibc in proposed)
[17:25] <cyphermox> like I said, maybe that's old outdated doc
[17:25] <cyphermox> I had some trouble finding it again :)
[17:25] <infinity> cyphermox: I just wasted 5m bikeshedding something that doesn't matter, so I'm done.  We can take what you uploaded if you like it well enough.
[17:26] <cyphermox> ok
[17:27] <cyphermox> I'll prepare my next NM SRU as 1.2.0-0ubuntu1.16.04.0.1.just.to.mess.with.infinity.1
[17:27] <infinity> cyphermox: That would get rejected. :P
[17:27] <cyphermox> d'oh
[17:30] <sbeattie> Oh man, did I forget the git hash, the current discordian date, and my astrological sign in the *glibc upload versions?
[17:33] <infinity> sbeattie: Hah.  No, you used -NubuntuN.1 and -NubuntuN.0.1 versioning where the doc claims you should use .15.04 and .15.10 when versions are the same.
[17:33] <infinity> sbeattie: But I think that part of the doc is wrong and you were right. :P
[17:34] <slangasek> 0e725a8-prickle-prickle
[17:37] <infinity> https://en.wikipedia.org/wiki/Discordian_calendar#Implementations
[17:37] <infinity> Man, I never even noticed ddate was gone.
[17:37] <infinity> I guess I don't use it enough.
[17:38] <wxl> ddate is gone? :(
[17:38] <infinity> Well, it's in a new source now.
[17:38] <infinity> It was dropped from util-linux.
[17:38] <wxl> that's terrible
[17:38] <sbeattie> well, somebody (not naming names) had already done a round vivid/wily glibc updates, so I was just following suit, trying to stick to the existing pattern.
[17:38]  * wxl exercises the turkey curse on the maintainers
[17:39] <sbeattie> oh man, ddate out of util-linux? I guess it *has* been a while since I took the bit out of my mytt config to automatically add a ddate header.
[17:39] <sbeattie> s/mytt/mutt/
[17:44] <infinity> sbeattie: Never fear, "apt-get install ddate" returns sanity.
[17:45] <infinity> Now to put that in the minimal seed.
[17:47] <mapreri> "apt-get is dead.  long life apt."
[17:49] <infinity> I still type "dpkg-buildpackage -i -I -rfakeroot -uc -us -S" when I could probably just type "debuild -S", I don't think I'll ever switch from apt-get to apt.
[17:50] <wxl> too bad there's not a ddate implementation to cron. then there REALLY could have been some controversy
[17:50] <mapreri> o.O
[17:50] <mapreri> i don't even know off-hands what -i and -I do...
[17:50] <infinity> Set up default ignore patterns.
[17:51] <infinity> See -i and -I docs in dpkg-source(1)
[17:51] <mapreri> ya know, that's why i have a ~/.devscripts setting them for me (and i use debuild) :P
[17:53] <infinity> I think the -i and -I ignore patterns might now be default without specifying.  I know -rfakeroot has been the default for years (maybe a decade or so now)...
[17:53] <infinity> But retraining fingers is hard.
[18:43] <slangasek> infinity: what, dropped from util-linux and nobody made util-linux Pre-Depends: ddate for upgrades?!
[18:46] <infinity> slangasek: ikr?
[18:48]  * infinity thinks it might be Burger Time (the event, not the underrated video game), then finally time for autosync to return.
[19:06] <cyphermox> xnox: don't you still need to kill gpg-agent every time you remove and reconnect your yubikey?
[19:07] <xnox> cyphermox, no
[19:08] <xnox> cyphermox, but e.g. $ stop gpg-agent; start gpg-agent
[19:08] <xnox> can help if and when scdc daemon throws up on itself, afer e.g. suspend and resume
[19:10] <cyphermox> well, pcscd is masked here because it's always in the way
[19:10] <cyphermox> whenever it is running it tends to take over the card because it can also do straight smartcard
[19:11] <Logan> doko: do you think the increase in outstanding merges at the end of the Xenial development cycle (compared to previous ones) might be due to the death of UDD?
[19:11] <infinity> Logan: I'd say it's a combination of people not running "grep-merges" and people not wanting to make drastic changes in an LTS.
[19:12] <infinity> Logan: I don't see how UDD really factors in, given that it made most simple merges harder, not easier, IMO.
[19:13] <Logan> I had issues using grab-merge because it doesn't automatically unapply quilt patches
[19:14] <Logan> and it also didn't give me an easy way to merge from experimental instead of unstable
[19:14] <Logan> in any case, dgit integration can't come soon enough ;)
=== ochosi_ is now known as ochosi
[20:03] <infinity> Initial autosync in progress now.
[20:06] <Logan> \o/
[21:24] <cyphermox> slangasek: ^ efivar for mokutil, along with mokutils where appropriate...
[22:02] <doko> xnox, I wasn't given a link, and then I forgot :-/
[22:04] <doko> infinity, autosyncs not yet running?
[22:05] <infinity> doko: It's in progress.
[22:05] <infinity> doko: Hence the NEW trickling in.
[22:05] <doko> ahh
[22:05] <doko> just 500?
[22:06] <infinity> doko: 2824, but LP can't batch that many at once, so it's going in chunks.
[22:07] <xnox> doko, lemonade =) let the librarian breath =) no need to be all jay-z about it.
[22:08] <xnox> *breathe
[22:08]  * doko fethes a beer
[22:08] <doko> fetches even
[22:08] <xnox> there will be a forever of autopkgtests too...
[22:09] <infinity> Indeed.
[22:09] <infinity> I believe the last time I sent the archive opening email, I recommended that people chillax for a few days while autosync ate all the infra. :P
[22:09] <infinity> Om nom nom.
[22:09] <xnox> Laney, http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.60.html looks odd. why boost-defaults is red on s390x?
[22:10] <doko> xnox, why do you care? it migrated
[22:10] <xnox> doko, i suspect stale meta-data -> stale table results to see what else needs doing.
[22:26] <mapreri> infinity: have you got any chance at fixing up the seeds and remove hunspell-sv?  :)
[22:27] <infinity> mapreri: I'll get to it.
[22:27] <infinity> mapreri: I don't imagine it'll harm anyone to be there a few more hours. :P
[22:28] <mapreri> i'd say not, no :)
[22:28] <mapreri> also because the lo-dicts migration is blocked also on ubuntu-keyboard, which is stuck in proposed waiting for the autopkgtests queue to get over with it...
[22:29] <mapreri> opening the archive and turning on the auto-syncs has the effect of stalling autopkgtests, apparently :)
[22:49] <bdmurray> infinity: Bug 1572416 was verified so I think we are good to release ubuntu-release-upgrader
[22:49] <ubot5> bug 1572416 in ubuntu-release-upgrader (Ubuntu Xenial) "do-release-upgrade crashes in Greek locale" [High,In progress] https://launchpad.net/bugs/1572416
[22:49] <infinity> bdmurray: Mmkay.
[22:49] <infinity> bdmurray: The autopkgtests fail.
[22:50] <infinity> Which, apparently, they've been doing for a while, and no one cared.  Whee.
[22:50] <bdmurray> infinity: that isn't a new failure
[22:50] <infinity> bdmurray: Yeah, so I see.
[22:51] <infinity> Perhaps related to this?
[22:51] <infinity> (nosetests3:8783): Gtk-WARNING **: Locale not supported by C library.
[22:51] <infinity> 	Using the fallback 'C' locale.
[22:51] <infinity> ie: are you trying to use a UTF-8 locale without building it?
[22:52]  * infinity looks.
[22:55] <infinity> bdmurray: Just going to test this locally quickly, then release it.
[22:55] <bdmurray> infinity: okay, I'll update the meta-release file after that
[23:01] <infinity> bdmurray: Still mulling over if we should copy the apt from updates to security as well.
[23:01] <infinity> bdmurray: Otherwise, people trying to do-release-upgrade from security-only systems will just not be able to.
[23:02] <bdmurray> infinity: that'd be ironic when the release become EoL
[23:03] <infinity> bdmurray: Lemme do a quick scan of apt binaries to see if they'll need a rebuild in the security PPA or if they can be cleanly copied.
[23:10] <infinity> mdeslaur: I scanned all the apt/trusty-updates binary deps, and they're all satisfiable in trusty-security.  Mind if I copy it over, same rationale as dpkg (want to fix upgrade bugs for people running security-only)?
[23:13] <infinity> Dyslexic spam misread of the day:
[23:13] <infinity> 18197 N + Apr 26 Natural Life    (0.8K) Scientists Discover Cure to Candida
[23:13] <infinity> I read that as "Canadia".
[23:13] <teward> infinity: heh
[23:14] <bdmurray> infinity: what about wily's apt?
[23:15] <infinity> bdmurray: Oh, should be the same story, but I should also scan it.  Thanks.
[23:15]  * infinity gets downloady.
[23:18] <infinity> wily's is also safe to copy.
[23:18] <infinity> sbeattie, tyhicks, care to have an opinion, since mdeslaur seems to be selfishly away from his computer after hours?
[23:19] <infinity> bdmurray: FWIW, "LANG=C.UTF-8 xvfb-run nosetests3" fixes that one test failure.
[23:20] <infinity> bdmurray: But I agree, not a regression from the previous version, so we can just fix that in bzr and catch it next time.
[23:20] <bdmurray> infinity: hmm, thanks
[23:20] <infinity> bdmurray: I can't quite sort out what is trying to set an invalid locale, or where, but overriding it appears to work.
[23:21] <infinity> bdmurray: Though, if that's required to pass the tests, one might also argue it's required to be set early and always in the upgrader itself.
[23:21] <infinity> bdmurray: And, thus, not set to pass the tests.
[23:21] <sbeattie> infinity: I think that's okay, we don't want security-only upgrades to fail.
[23:22] <infinity> sbeattie: Ta.  Just wanted a +1 before I mess with your pocket.
[23:22] <infinity> Messing away now.
[23:24] <infinity> sbeattie: I'm still not convinced that there's anyone who actually runs security-only, but...
[23:25] <sbeattie> I've .... yet to meet that unicorn, either.
[23:25] <infinity> sbeattie: If I were to go back in time and do it all over, I'm not sure I'd give people the option.
[23:26] <teward> infinity: thanks for pushing that SRU up - testing completed.  :)
[23:26] <infinity> sbeattie: The original intent was to mirror how Debian does it, but Debian doesn't do the rebase-security-on-SRUs thing until after point releases, so we differ regardless.
[23:26] <teward> infinity: I run security-only, by only doing security updates on my servers in production through Landscape management
[23:26] <teward> (just sayin')
[23:26] <infinity> teward: Huh.  So, you're the one.
[23:27] <teward> infinity: i know several production systems at another workplace running security-only
[23:27] <teward> and seven clients with the same setup
[23:27] <infinity> teward: I have unattended-upgrades configured to only *automatically* pull security updates, but I do a manual pass for SRUs (reviewing via apt-listchanges) from time to time too.
[23:27] <teward> infinity: yeah i do that as well
[23:27] <teward> infinity: but that's once every quarter
[23:27] <teward> until then, everything's security-only, and Landscape-managed
[23:28] <infinity> sbeattie: Well, looks like we found him.
[23:28] <teward> :P
[23:28] <teward> but again, Landscape managed, once a quarter everything's snapshotted, and then "UPdate All The Things" gets clicked ;)
[23:29] <infinity> bdmurray: Yeah, the more I think about it, the more I think it's probably an u-r-u bug, not a test bug.
[23:29] <infinity> bdmurray: If it needs a UTF-8 locale to function sanely and we're not always setting it (though, I see we make an attempt to sometimes set it?), derp.
[23:30] <infinity> bdmurray: Unless the tests, being all unit-testy, just aren't invoking things in the same was as the actual applications do, and at runtime, it's *always* C.UTF-8, then it's a testsuite bug.
[23:30] <infinity> bdmurray: But worth a ponder.
[23:30] <infinity> s/same was/same way/
[23:31] <bdmurray> infinity: got it, thanks. You'll release u-r-u?
[23:32] <infinity> bdmurray: Check your mail.
[23:32] <infinity> bdmurray: All the right apts and dpkgs should be in place too.
[23:32] <infinity> bdmurray: Well, when the publisher catches up to my abuse.
[23:35] <infinity> bdmurray: You might want to grab dinner or a drink or go salsa dancing before updating meta-release.
[23:35] <infinity> bdmurray: The publisher is churning on a LOT of stuff from the autosync.
[23:36] <infinity> The downside of more and faster buildds is that we can dump half a distro on disk in a half hour period, apparently. :P
[23:36] <infinity> slangasek: Were you going to do any simple runtime tests to your command-not-found update before releasing it?
[23:37] <infinity> (ie: install it, type some not found commands, check output, make sure it doesn't vomit on its own DB, release)
[23:44] <slangasek> infinity: well I /wasn't/ going to, but I can take a hint
[23:49] <cjwatson> infinity: I can disable three-quarters of them if stuff is building too fast for you.
[23:49] <infinity> cjwatson: I can too. :P
[23:50] <cjwatson> infinity: Or, you know, on ppc64el we can just wait an hour and they'll disable themselves. :P
[23:50] <infinity> cjwatson: Hah.
[23:50] <infinity> cjwatson: I love that right when we're going to kill it and move it to scalingstack, the P7 powerpc builders have become rock solid.  It's like they can sense impending doom.
[23:51] <infinity> cjwatson: Modulo upgrade reboots, I haven't had a single one have a problem on lts-x (which is comforting).
[23:55] <cjwatson> infinity: For values of "right when" that include deploying a new scalingstack region, but yes.
[23:55] <infinity> cjwatson: Oh, the ppc64el thing seems to have already happened.
[23:55] <cjwatson> infinity: Yeah, two compute nodes appear to be sad.  See #is.
[23:56] <infinity> cjwatson: Is that sea of "cleaning" just two nodes?
[23:56] <cjwatson> infinity: You have to factor in ppc64el scalingstack's background unreliability as well.
[23:57] <infinity> cjwatson: Oh well, I look forward to powerpc's 9 POWER7 builders beating it.
[23:58] <infinity> Proving that 9 healthy middle-aged men can beat up 30 crippled 20-year-olds.  Or something.