[00:26]  * slangasek reruns colord/armhf autopkgtest w/ new valgrind
[08:15] <didrocks> sil2100: hey, glib2.0 is stuck in proposed due to the flaky nplan autopkgtests which almost never succeed: http://autopkgtest.ubuntu.com/packages/n/nplan/artful/amd64. It seems that people are just override them for now, mind handling glib2? (unsure if you can ;))
[08:47] <sil2100> didrocks: I don't think I can, looks like you'll need to poke someone from the release team (probably) ;p
[08:49] <Laney> there's a new glib2.0 to merge btw :-)
[08:49] <didrocks> I may handle the merge, but maybe let's get that one in first?
[08:50] <doko> Laney: do we have a status about the failing glibc and perl autopkg tests?
[08:51] <Laney> what kind of status?
[08:52] <Ukikie> Unfortunatly the new glib2.0 does't fix all the mounts on the desktop. :/
[08:53] <doko> who looked at which failing tests, don't want to duplicate work
[08:58] <Laney> no status maintained by me - usually I would think the uploader would track its migration
[09:01] <Laney> probably at some point we declare bankruptcy on the tests and use a force-skiptest to get it in
[09:01] <Laney> ideally once the uploader has analysed all the failures
[09:03] <acheronuk> I'm looking at the kscreenlocker one. so far with gblic from proposed and/or a kscreenlocker build againsta that, I have no real world kscreenlocker error on my hardware or a VM
[09:04] <acheronuk> but I have emailed the upstream KDE maintainer to try to get his opinion
[09:08] <Laney> didrocks: hinted it
[09:09] <doko> Laney: http://autopkgtest.ubuntu.com/packages/p/profnet/artful/amd64  looks like this was overridden the last time that glibc migrated? so maybe mark that as always fail?
[09:10] <didrocks> Laney: thanks! will handle the merge later on then ;)
[09:14] <LocutusOfBorg> would be nice to wait for autopkgtests to slow down before merging new stuff :)
[09:14] <Laney> KDE :(
[09:15] <Laney> doko: looks like the new profnet in proposed is better maybe
[09:15] <Laney> tried against that one
[13:29] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-10.11] (core, kernel)
[13:58] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20170808.1-0ubuntu0.14.04.1 => 1:20170912.1-0ubuntu0.14.04.1] (no packageset)
[13:58] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (zesty-proposed/partner) [1:20170808.1-0ubuntu0.17.04.1 => 1:20170912.1-0ubuntu0.17.04.1] (no packageset)
[13:58] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20170808.1-0ubuntu0.16.04.1 => 1:20170912.1-0ubuntu0.16.04.1] (no packageset)
[14:11] <flocculant> hi release team - not sure how this has happened but I'll not be able to fix the issue - we have an item in our daily set (Xubuntu Core) which I set up once a cycle currently just so we have somewhere to report tests. It's currently set at rebuilding for some reason. Can you unset that please - it never ever builds as our normal desktop iso's do anyway :)
[14:19] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20170912.1-0ubuntu0.14.04.1]
[14:19] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20170912.1-0ubuntu0.16.04.1]
[14:20] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (zesty-proposed) [1:20170912.1-0ubuntu0.17.04.1]
[14:28] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-10.11]
[15:09] <Laney> acheronuk_: Can you please give me a list of tests that you requested all-proposed runs on so that I can drop the original requests?
[15:09] <Laney> Having duplicate several hour runs is pretty abusve to the infrastrucure IMO
[15:09] <Laney> <insert weekly complaint about KDE tests>
[15:10] <acheronuk_> only ones that failed. I did not duplicate any as far as I know
[15:12] <Laney> run, fail, run again?
[15:16] <acheronuk_> run triggered by britney, fail as FW stack is not finished building so test deps not satifiable or other reason, wait until the whole stack is build, then run against all proposed as that is what is required for framworks
[15:19] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/k/kcalc/20170911_191157_35f35@/log.gz
[15:19] <Laney> autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from proposed
[15:19] <Laney> still failed
[15:20] <acheronuk_> that was not me retrying
[15:21] <acheronuk_> and the reason that failed against all-propose with the pinning, is because the frameworks stack was still building
[15:21] <Laney> You don't need to retry with all-proposed=1 because it falls back automatically if necessary
[15:23] <acheronuk_> I do as I need the rest for frameworks to test against. the temporaily unsatifiable test deps halfway through tha stack build is a seperate issue
[15:25] <Laney> If you need a complete stack then that should be expressed using package dependencies
[15:25] <Laney> If you retry using all-proposed=1, you can make things pass tests and then they may migrate.
[15:26] <Laney> Then users might get an untested situation on their machines
[15:26]  * Laney is writing an emai
[15:26] <Laney> l
[16:34] <acheronuk> Laney: ack and understood on that email. sorry for the bad timing with the current tests
[18:17] <LocutusOfBorg> sigh perl, there are CVE fixes in the -8 upload in Debian :(
[18:36] <slangasek> casync autopkgtest regression is a real bug in the casync code; one-liner fix
[19:25] <slangasek> infinity, doko: cryfs regresses with glibc 2.26 because it wants to use CHAR_WIDTH as a variable name and that's now a glibc define.  Is this a standard define, and is this an expected behavior change?
[19:37] <infinity> slangasek: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a292f45acdf0a35266e4f1dd1e51b95ca5325d2a certainly seems deliberate, yes.
[19:38] <slangasek> ok
[19:38] <slangasek> badtest'ing
[19:54] <infinity> const unsigned CHAR_WIDTH = 1;
[19:54] <infinity> Because "1" was too hard to type.
[19:59] <infinity> slangasek: Looks like more recent versions have done s/CHAR_WIDTH/CHAR_SIZE/g
[19:59] <infinity> slangasek: I'll just upload a cherrypick of that.
[20:03] <infinity> https://github.com/fmtlib/fmt/commit/abbefd71666055daac9e14e78262620f9e845850
[20:10] <slangasek> infinity: k
[20:15] <infinity> And by cherrypick, I mean backport, because apparently they decided to change their brace style.  Weird.
[20:27] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.15 => 2.408.16] (desktop-core)
[20:37] -queuebot:#ubuntu-release- Unapproved: gdebi (trusty-proposed/main) [0.9.5.3ubuntu2 => 0.9.5.3ubuntu3] (ubuntu-desktop)
[21:01] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.15 => 2.408.16] (desktop-core)
[21:05]  * tsimonq2 scratches head, no rejection but it's on there twice? ^^^^^
[21:05] <tsimonq2> *shrug*
[21:06] <infinity> tsimonq2: People sometimes get impatient and upload more than once.
[21:07] <infinity> Or, in slangasek's case, they upload two different things and I assume plan to self-reject the first. :P
[21:08] <slangasek> infinity: it's being discussed with bdmurray
[21:08] <slangasek> and I'm going to self-reject *both* of them, so take that
[21:08] <infinity> Heh.
[21:08] <infinity> slangasek: https://launchpad.net/ubuntu/+source/cryfs/0.9.7-1ubuntu1 <-- Should address the previous conversation.
[21:08] <slangasek> righty-o
[21:09] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.16]
[21:09] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.16]
[21:18] <juliank> um, I think apt 1.4.6~17.04.1 should finally be accepted into zesty-updates, it's spent 47 days in -proposed now
[21:18] <tsimonq2> infinity: :P
[21:18] <juliank> there's the usual sbuild autopkgtest failures but we also saw those with postfix/3.1.4-4ubuntu1
[21:18] <tsimonq2> infinity: ok, cool, I was just curious for the sake of future reference
[21:19] <juliank> and randomly before
[21:20] <juliank> paired with unattended-upgrades of course
[21:20] <juliank> (42 days old)
[21:21] <juliank> Hmm, do we have no unattended-upgrades with --no-download in zesty-proposed, did we miss that?
[21:21]  * juliank is confused
[21:22] <juliank> hmm no, 2.3 is in proposed, but pending-sru.html lists 2.2
[21:22] <juliank> oops, wrong column
[21:24] <slangasek> juliank: I do not ignore autopkgtest regressions as reported by proposed-migration, but I do accept MPs against lp:~ubuntu-sru/britney/hints-ubuntu-zesty :)
[21:24] <slangasek> aka: if the sbuild autopkgtest is bad and you can demonstrate this, we should hint it as bad for everyone, not just ignore it for this current SRU
[21:24] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.15 => 2.408.16] (desktop-core)
[21:25] <juliank> slangasek: It only fails occasionally
[21:26] <juliank> It's kind of odd
[21:26] <slangasek> juliank: then we can still badtest it as 'flaky', or you can retry it until it succeeds
[21:26] <slangasek> juliank: also, there is an sbuild SRU currently in zesty-proposed which purports to fix this
[21:27] <slangasek> so another option is 1) do the SRU verification for the linked bugs, 2) release sbuild SRU, 3) retry apt-triggered autopkgtest
[21:27] <juliank> slangasek: Or we retrigger with apt/1.4.6~17.04.1 and sbuild/0.71.0-2ubuntu2?
[21:29] <slangasek> that too, but that's more manual and the sbuild SRU should get verified+released regardless
[21:29] <juliank> slangasek: bug 1566590 has neither a zesty tag nor an SRU bug description
[21:29] <juliank> but is listed on pending-sru
[21:29] <juliank> But it's not in the changelog
[21:30] <slangasek> yeah, I was reaching that conclusion
[21:30] <slangasek> so I'll happily ignore that one
[21:30] <slangasek> and the verification for LP: 1686064 appears to be "did the autopkgtests pass?"
[21:30] <juliank> slangasek: So, since the test passed, the bug can be marked as verified
[21:31] <juliank> yeah
[21:31] <slangasek> ok, released
[21:35] <juliank> slangasek: While you're around, do you have an opinion on the apt 1.4.7 (or well, the upcoming 1.4.8) "sync" from stretch? syncpackage would be optimal, but does not create a diff; syncpackage --no-lp probably does because I'd upload a changes myself. I could also edit the changelog and s/stretch/zesty/, but that's sort of boring extra work for no gain.
[21:35] <juliank> If it's synced changelog still says stretch rather than zesty, but oh well, as long as it lands in the right place...
[21:36] <juliank> (I modified syncpackage a bit to keep the original .dsc signature too, so the files have the same hashes)
[21:38] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.16]
[21:40] <slangasek> juliank: well, reviewing SRUs without a queue diff is a nuisance, and likely slows down the processing.  But there's no policy against it
[21:41] <juliank> slangasek: Right, but if I do --no-lp and upload the changes myself, I'd think there would be a diff. The major question is if somebody would hate changelog mentioning stretch instead of zesty, really.
[21:42] <slangasek> I don't know
[21:42] <slangasek> for me, it wouldn't even register as part of SRU processing
[21:42] <infinity> juliank: I have no issues with a byte-identical sync, but indeed, manually uploading the source instead of doing a copyPackage() LP sync would give us a diff.
[21:44] <slangasek> RAOF: hi there, would you mind releasing the apparmor xenial SRU today?  I've got the autopkgtest regressions sorted
[21:56] <RAOF> sure
[22:00] <slangasek> RAOF: ta
[23:26] <bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updater-more-emails/+merge/330628