=== maclin1 is now known as maclin
=== stokachu_ is now known as stokachu
=== maclin1 is now known as maclin
[04:16] <Mirv> so did you get any analysis on what's blocking the transitions still? the update_output.txt hint sections do not seem any clearer to me today.
[04:50] <slangasek> Mirv: a new pillow synced in (courtesy of doko's Debian upload) that has set things back for the moment and prevents seeing what else might be blocking
[05:00] <Mirv> ok thanks slangasek for the pointer
[06:47] <Mirv> and new glibc is causing a 1000 package queue to each architecture
[06:50] <acheronuk> as a result of glibc https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830912
[06:50] <ubot5> Debian bug 830912 in fakeroot "fakeroot complains about missing acl_* symbols" [Normal,Open]
[06:51] <acheronuk> so 100's of repetitions of
[06:51] <acheronuk> dlsym(acl_get_file): /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so: undefined symbol: acl_get_file
[06:51] <acheronuk> dlsym(acl_set_fd): /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so: undefined symbol: acl_set_fd
[06:51] <acheronuk> in buildlogs
[06:51] <xnox> so we need to fix fakeroot it seems
[06:52] <xnox> why does it not link with libacl ?!
[07:00] <Mirv> I wonder if non-glibc autopkgtests could be prioritized, otherwise another day will be wasted in not-transitioning
[07:00] <Mirv> I'd also have my own landings causing thousands of autopkgtests triggered, but I'm pending on landing them to give a chance for the migrations..
[07:00] <Mirv> but I guess I need to start new landings on top of earlier non-landed landings because I'd also need to do some OTA updates
[07:00] <Mirv> (non-landed to yakkety)
[07:06] <xnox> Mirv, yeah and we have a lot of customers wanting new glibc and only a week before feature freeze. It's not like glibc is un-important update either.
[07:06] <Mirv> xnox: yay! :)
[07:07] <Mirv> it was three weeks until feature freeze when I started hoping for Qt release pocket migration :)
[07:07] <Mirv> hopefully autopkgtests would become more scaling at some point
=== dbarth_ is now known as dbarth
[08:05] <oSoMoN> dear release team, could I please get some feedback on https://launchpad.net/bugs/1600176 ?
[08:05] <ubot5> Launchpad bug 1600176 in webbrowser-app (Ubuntu) "[SRU] webbrowser-app bug fixes" [High,New]
[08:30] <jamespage> cpaelzer, ok dpdk and ovs all uploaded an built
[08:34] <cpaelzer> jamespage: yeah, but sadly they block in update excuses
[08:34] <cpaelzer> jamespage: I already started a local adt to debug my test
[08:35] <cpaelzer> jamespage: some of the tools changed names, I hope it is that simple - but at the same time I have to finish something for smoser before I leave
[08:35] <cpaelzer> jamespage: I'll give you a ping once I had a deeper look into the failing dep8 test
[08:40] <cpaelzer> jamespage: also for obvious reasons the dependen ovs 2.5 tests fail - do we need to do something special to mark those two uploads as belonging together?
[08:56] <LocutusOfBorg> cjwatson, this might be a good moment to make haskell migrate :)
[08:56] <LocutusOfBorg> not sure what is missing
[08:57] <LocutusOfBorg> autopkgtest for haskell-hoogle: i386: Test in progress
[08:57] <LocutusOfBorg> this is "in progress" since some days, meh
[09:04] <LocutusOfBorg> everything "not considered" brings to that test
[09:36] <ogra_> can someone please bump the score for https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/2796
[09:36] <ogra_> (arm builds are a pain recently :/ )
[10:51] <cpaelzer> jamespage: I found and fixed the issue in the dpdk dep8 test
[10:51] <cpaelzer> jamespage: I run it through a full adt once more now, but for prepping - does that already have to be a 16.07-0ubuntu2 to avoid collisions?
[10:52] <jamespage> cpaelzer, yes
[11:00] <cpaelzer> jamespage: the git repo is already updated at the same location with an 16.07-0ubuntu2, so is the deb_dpdk packaging repo to stay in sync. But I'll give you a ping once it passed the full adt just to be 100% sure and avoid another reupload
[11:31] <cpaelzer> jamespage: ok, all three dep8 tests passed on the new version
[12:05] <dbarth> bdmurray: hey again, the packages for the SRU ref. by https://bugs.launchpad.net/gnome-control-center-signon/+bug/1565772 are now in the UNAPPROVED queue
[12:05] <ubot5> Launchpad bug 1565772 in gnome-control-center-signon (Ubuntu Xenial) "[SRU] Allow plugins to decide which username to set on new accounts" [Critical,Confirmed]
[12:07] <dbarth> CI says you have manual controls to move them to -proposed for the verification to start
[14:54] <bdmurray> dbarth: that's correct, I'll try and have a look today.
[14:54] <dbarth> bdmurray: thanks
[17:53] <infinity> slangasek: ^-- Simple review.  As suggested, only addition, not removal, but I *suspect* snapd might be the only consumer (as they're the ones who added it), so maybe UBUNTU_CODENAME can go away in yakkety soon.  We might need to keep it in xenial forever (or have snapd declare a >= dep on base-files, ick)
[17:54] <infinity> Oh, err, other way, I guess base-files would need a << Breaks on snapd once it's fixed.
[17:54] <infinity> Double-ick.
[17:54] <infinity> So probably easier to just keep both in xenial.
[18:33] <slangasek> infinity: accepted
[18:59] <infinity> slangasek: Ta.
[20:53] <bdmurray> infinity: it occured to me that maybe the meta-release file should point to old-release.ubuntu.com instead of archive.ubuntu.com for the UpgradeTool lines for unsupported releases...
[21:00] <infinity> bdmurray: That seems quite plausibly true.
[21:00] <infinity> bdmurray: Though, that needs to happen after the backup happens.
[21:04] <bdmurray> infinity: What backup?
[21:04] <infinity> bdmurray: The backup to old-releases...
[21:05] <infinity> bdmurray: ie: wily isn't there yet, which I'll get sorted soon.
[21:05] <bdmurray> infinity: Sure, so it might be a two step process. Set Supported to 0 then, update UpgradeTool sometime
[21:06]  * infinity nods.
[21:07] <bdmurray> Okay, I'll fix it for the old-old releases then.
[22:53] <wxl> slangasek: thanks for getting the lxqt images spun up. will those appear on the testing tracker at all? or at least be made available to appear on the tracker?
[22:53] <slangasek> wxl: the changes I made didn't get them added to the tracker, that needs to be done separately
[22:53] <wxl> slangasek: who would i contact about that?
[22:54] <slangasek> wxl: well.  I could do it, but not at the moment :)  please follow up to the email thread
[22:56] <wxl> slangasek: k thx :)
[23:06] <Ukikie> Speaking of cdimage merge proposals...