[00:39] <slangasek> jbicha: did you see my follow-up question to you in https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1715030/comments/6 ?
[00:39] <ubot5> Ubuntu bug 1715030 in mozplugger (Ubuntu) "Please remove firefox from artful on ppc64el" [Undecided,Incomplete]
[01:08] <jbicha> slangasek: I think Chris already answered that for mozplugger. I believe mozplugger is a plugin and Flash is the only plugin allowed in Firefox now
[01:10] <jbicha> I think it's broken in Debian now too
[01:11] <jbicha> maybe it does something in Epiphany…
=== maclin1 is now known as maclin
[02:29] <tsimonq2> Can someone please remove kdeplasma-addons from zesty-proposed? I accidentally messed up the upload.
[02:29] <tsimonq2> I think acheronuk said something on the weekend, idk.
[02:30] <tsimonq2> More details are on bug 1715219, I'll upload a fixed version very shortly after it's removed.
[02:30] <ubot5> bug 1715219 in kdeplasma-addons (Ubuntu Zesty) "Missing dependency" [High,In progress] https://launchpad.net/bugs/1715219
[03:07] <slangasek> jbicha: ah, I suppose it does count as a plugin, doesn't it - thanks for pointing out the obvious, I'll remove + blacklist now
[03:08] <slangasek> jbicha: any chance you want to file a bug on it in Debian, then?
[03:10] <slangasek> tsimonq2: why does it need removed?  you can just mark the SRU bug verification-failed, and upload the fixed package at earliest opportunity
[03:11] <tsimonq2> slangasek: oh
[03:11] <tsimonq2> Fair
[03:11] <tsimonq2> I'll do that then
[03:11] <tsimonq2> Thanks slangasek
[03:47] -queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (zesty-proposed/universe) [4:5.9.5-0ubuntu0.2 => 4:5.9.5-0ubuntu0.3] (kubuntu)
[03:53] <slangasek> acheronuk: kcrash 5.38.0-0ubuntu1, still fails its autopkgtests?
[04:02] -queuebot:#ubuntu-release- New sync: node-babylon (artful-proposed/primary) [6.18.0-1]
[04:02] -queuebot:#ubuntu-release- New: accepted node-babylon [sync] (artful-proposed) [6.18.0-1]
[05:17] -queuebot:#ubuntu-release- New sync: node-pretty-ms (artful-proposed/primary) [3.0.0-1]
[05:20] -queuebot:#ubuntu-release- New sync: node-rollup-plugin-replace (artful-proposed/primary) [2.0.0-1]
[05:21] -queuebot:#ubuntu-release- New: accepted node-pretty-ms [sync] (artful-proposed) [3.0.0-1]
[05:21] -queuebot:#ubuntu-release- New: accepted node-rollup-plugin-replace [sync] (artful-proposed) [2.0.0-1]
[05:23] -queuebot:#ubuntu-release- New binary: node-rollup-plugin-replace [amd64] (artful-proposed/none) [2.0.0-1] (no packageset)
[05:23] -queuebot:#ubuntu-release- New sync: node-rollup (artful-proposed/primary) [0.47.4-3]
[05:24] -queuebot:#ubuntu-release- New: accepted node-rollup [sync] (artful-proposed) [0.47.4-3]
[05:24] -queuebot:#ubuntu-release- New binary: node-pretty-ms [amd64] (artful-proposed/none) [3.0.0-1] (no packageset)
[05:24] -queuebot:#ubuntu-release- New: accepted node-pretty-ms [amd64] (artful-proposed) [3.0.0-1]
[05:24] -queuebot:#ubuntu-release- New: accepted node-rollup-plugin-replace [amd64] (artful-proposed) [2.0.0-1]
[05:40] <LocutusOfBorg> slangasek, I know it https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ca-certificates-java&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious&repeatmerged=yes
[05:41] <LocutusOfBorg> pick one :) they are all the same, openjdk depending on ca-certificate-java, that depends on openjdk
[05:41] <LocutusOfBorg> depending on which is configured before, there is a failure or not
[05:41] <LocutusOfBorg> don't really know how to fix it
[05:45] <slangasek> ugh
[05:46] <slangasek> LocutusOfBorg: if it's genuinely a circular dependency between two packages that both have maintainer scripts, either one should figure out how to not require a maintainer script, or the binary packages should just be merged
[06:12] <LocutusOfBorg> slangasek, doko is the maintainer, not me :)
[06:12] <LocutusOfBorg> I'm just trapped by that bug too :/
[06:13] <LocutusOfBorg> not sure why only armhf spots that bug, maybe slowl architecture, but interesting this happens in Debian too
[06:13] <LocutusOfBorg> and makes things sad
[06:15] -queuebot:#ubuntu-release- New sync: amp (artful-proposed/primary) [0.6-2]
[06:23] -queuebot:#ubuntu-release- Unapproved: vlan (trusty-proposed/main) [1.9-3ubuntu10.4 => 1.9-3ubuntu10.5] (core)
[06:23] -queuebot:#ubuntu-release- Unapproved: vlan (xenial-proposed/main) [1.9-3.2ubuntu1.16.04.3 => 1.9-3.2ubuntu1.16.04.4] (core)
[06:24] -queuebot:#ubuntu-release- Unapproved: vlan (zesty-proposed/main) [1.9-3.2ubuntu2.17.04.2 => 1.9-3.2ubuntu2.17.04.3] (core)
[06:53] <doko> slangasek, tdaitx: this started after "cleaning up the openjdk packaging", I suspect this has something to do with the architecture identification changing with the hotspot implementation
[06:53] <acheronuk> slangasek: kcrash 5.38 fails the same way 5.37 in release started to before any of 5.38 was uploaded: https://autopkgtest.ubuntu.com/packages/kcrash/artful/amd64
[06:53] <doko> I know why I didn't want to touch this area ...
[06:55] <acheronuk> slangasek: so kcrash looks like a regression in release rather than a new issue in 5.38. I would also note the test passes fine locally
[07:02] -queuebot:#ubuntu-release- New sync: node-irregular-plurals (artful-proposed/primary) [1.2.0-2]
[07:03] -queuebot:#ubuntu-release- New: accepted node-irregular-plurals [sync] (artful-proposed) [1.2.0-2]
[07:06] -queuebot:#ubuntu-release- New binary: node-irregular-plurals [amd64] (artful-proposed/none) [1.2.0-2] (no packageset)
[07:06] -queuebot:#ubuntu-release- New binary: node-plur [amd64] (artful-proposed/none) [2.1.2-2] (no packageset)
[07:08] -queuebot:#ubuntu-release- New binary: ruby-psych [amd64] (artful-proposed/universe) [2.2.4-6build1] (no packageset)
[07:08] <LocutusOfBorg> doko, ^^ I successfully bootstrapped it, if you accept I'll wait to migrate and revert
[07:08] <slangasek> acheronuk: yes, it is the same crash as in release; but it's the uploader's responsibility to resolve this and make the package releasable.  If you can't reproduce it locally, why not disable the test?
[07:08] <LocutusOfBorg> after jruby is built
[07:10] -queuebot:#ubuntu-release- New: accepted node-irregular-plurals [amd64] (artful-proposed) [1.2.0-2]
[07:10] -queuebot:#ubuntu-release- New: accepted node-plur [amd64] (artful-proposed) [2.1.2-2]
[07:10] <acheronuk> slangasek: I was considering disabling it, but was having a last try at working out an alternative.
[07:10] <slangasek> ok
[07:10] <acheronuk> same with kdelibs4support
[07:12] -queuebot:#ubuntu-release- New sync: node-parse-ms (artful-proposed/primary) [1.0.1-2]
[07:12] -queuebot:#ubuntu-release- New: accepted node-parse-ms [sync] (artful-proposed) [1.0.1-2]
[07:16] -queuebot:#ubuntu-release- New binary: node-parse-ms [amd64] (artful-proposed/none) [1.0.1-2] (no packageset)
[07:17] -queuebot:#ubuntu-release- New: accepted node-parse-ms [amd64] (artful-proposed) [1.0.1-2]
[07:20] <doko> slangasek: python-defaults and python3-defaults autopkg tests still seem to be priotized. is this correct? if yes, can we lower the priority again?
[07:22] <slangasek> doko: they're still in the low priority "huge" queue; they are ahead of anything else in that low priority queue (so for example, twisted, atlas, openblas).  which packages' tests should take priority right now?
[07:23] <doko> slangasek: openblas atlas, maybe twisted
[07:24] <slangasek> ok, let's see
[07:25] <slangasek> oh; and we definitely shouldn't continue running tests for a version of python3-defaults that's superseded in -proposed :/
[07:30] <slangasek> doko: ok, python3-defaults tests dumped (except those currently running), now to re-queue them
[07:32] <doko> \o/
[07:38] <slangasek> hmm, not sure if the API changes have been deployed to let me dump these into the huge queue instead of the regular queue
[07:42] <slangasek> alrighty, requeued by the non-api method
[08:03] <Laney> slangasek: not yet, I'm told soon
[08:04] <LocutusOfBorg> please accept ruby-psych
[08:05] <apw> slangasek, i don't think i finished those branches, damn
[08:05] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (zesty-proposed) [0.12.4~17.04.1]
[08:07] <sil2100> smb: hm, no ubuntu-fan for xenial yet?
[08:07] <smb> sil2100, that is because its not uploaded yet... probably could... and there might be a task asking apw to sponsor
[08:08]  * apw looks up ... could be indeed
[08:09] <smb> apw, or maybe not. cannot see anything
[08:09] <smb> probably fell through some cracks
[08:15] <smb> apw, I prepared a new card now for looking at the source pkg I prepared. once that looks good to you I'd push the tree and you could upload it
[08:21] -queuebot:#ubuntu-release- New: accepted amp [sync] (artful-proposed) [0.6-2]
[08:21] -queuebot:#ubuntu-release- New: accepted ruby-psych [amd64] (artful-proposed) [2.2.4-6build1]
[08:23] -queuebot:#ubuntu-release- New binary: amp [i386] (artful-proposed/none) [0.6-2] (no packageset)
[08:23] -queuebot:#ubuntu-release- New binary: amp [ppc64el] (artful-proposed/none) [0.6-2] (no packageset)
[08:25] -queuebot:#ubuntu-release- New binary: amp [amd64] (artful-proposed/none) [0.6-2] (no packageset)
[08:25] -queuebot:#ubuntu-release- New binary: amp [s390x] (artful-proposed/none) [0.6-2] (no packageset)
[08:26] -queuebot:#ubuntu-release- New binary: amp [armhf] (artful-proposed/none) [0.6-2] (no packageset)
[08:27] <jibel> hi, is there anything missing to release gnome-software 3.20.5-0ubuntu0.16.04.6 to xenial-updates?
[08:27] -queuebot:#ubuntu-release- New binary: amp [arm64] (artful-proposed/none) [0.6-2] (no packageset)
[08:33] -queuebot:#ubuntu-release- New: accepted amp [amd64] (artful-proposed) [0.6-2]
[08:33] -queuebot:#ubuntu-release- New: accepted amp [armhf] (artful-proposed) [0.6-2]
[08:33] -queuebot:#ubuntu-release- New: accepted amp [ppc64el] (artful-proposed) [0.6-2]
[08:33] -queuebot:#ubuntu-release- New: accepted amp [arm64] (artful-proposed) [0.6-2]
[08:33] -queuebot:#ubuntu-release- New: accepted amp [s390x] (artful-proposed) [0.6-2]
[08:33] -queuebot:#ubuntu-release- New: accepted amp [i386] (artful-proposed) [0.6-2]
[08:42] -queuebot:#ubuntu-release- New binary: tortoisehg [amd64] (artful-proposed/universe) [4.3.1-1] (no packageset)
[08:46] -queuebot:#ubuntu-release- New: accepted tortoisehg [amd64] (artful-proposed) [4.3.1-1]
[10:12] <LocutusOfBorg> why are ubuntu chroots still mentioning perl 5.24? aren't them regenerated from time to time?
[10:16] <cjwatson> both of these things can be true :-)
[10:17] <cjwatson> infinity: ^-
[10:21] <LocutusOfBorg> 123 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
[10:21] <LocutusOfBorg> installing them everytime for every build is really time consuming, and polluting logs :)
[10:25] <cjwatson> some day we'll do the rainbows-and-unicorns project of building buildd chroots as livefs builds in LP and then it'll be much easier to refresh regularly
[10:36] -queuebot:#ubuntu-release- New sync: elvish (artful-proposed/primary) [0.10.1-1]
[10:44] -queuebot:#ubuntu-release- New: accepted elvish [sync] (artful-proposed) [0.10.1-1]
[10:59] -queuebot:#ubuntu-release- New binary: python-pygal [amd64] (artful-proposed/universe) [2.4.0-1] (no packageset)
[11:03] <doko> Laney: did you override the autopkgtest for gvfs/1.34.0-0ubuntu1 in the recent past? like
[11:03] <doko> # the remaining failures aren't glib's fault
[11:03] <doko> force-skiptest glib2.0/2.53.6-1ubuntu2
[11:03] <doko> now blocks other packages too
[11:04] <LocutusOfBorg> this should unblock pytest-catchlog unbuildability/brokeness ^^ and meh, I want the python3 package too :)
[11:04] <Laney> http://autopkgtest.ubuntu.com/packages/g/gvfs/artful/i386
[11:05] <Laney> that version of glib ran against a different gvfs, and it passed
[11:07] <doko> but how did gvfs migrate then?
[11:07] <Laney> it passed its own tests
[11:11] -queuebot:#ubuntu-release- New: accepted python-pygal [amd64] (artful-proposed) [2.4.0-1]
[11:16] <doko> slangasek: since about an hour, publisher runs seem to be at usual speeds now. again, it's a feeling, but it was slow including this morning
[11:23] <apw> doko, most of the runs since 4am my time have been about the 40-50m mark, one was 1:10
[11:32] <doko> apw: it was was others observed as well yesterday, in that binaries accepted only appeared one run later as usual
[12:03] -queuebot:#ubuntu-release- New binary: elvish [s390x] (artful-proposed/universe) [0.10.1-1] (no packageset)
[12:08] -queuebot:#ubuntu-release- New binary: elvish [amd64] (artful-proposed/universe) [0.10.1-1] (no packageset)
[12:08] -queuebot:#ubuntu-release- New binary: elvish [ppc64el] (artful-proposed/universe) [0.10.1-1] (no packageset)
[12:09] -queuebot:#ubuntu-release- New binary: elvish [arm64] (artful-proposed/universe) [0.10.1-1] (no packageset)
[12:09] -queuebot:#ubuntu-release- New binary: elvish [i386] (artful-proposed/universe) [0.10.1-1] (no packageset)
[12:09] -queuebot:#ubuntu-release- New binary: elvish [armhf] (artful-proposed/universe) [0.10.1-1] (no packageset)
[12:13] -queuebot:#ubuntu-release- New: accepted elvish [amd64] (artful-proposed) [0.10.1-1]
[12:13] -queuebot:#ubuntu-release- New: accepted elvish [armhf] (artful-proposed) [0.10.1-1]
[12:13] -queuebot:#ubuntu-release- New: accepted elvish [ppc64el] (artful-proposed) [0.10.1-1]
[12:13] -queuebot:#ubuntu-release- New: accepted elvish [arm64] (artful-proposed) [0.10.1-1]
[12:13] -queuebot:#ubuntu-release- New: accepted elvish [s390x] (artful-proposed) [0.10.1-1]
[12:13] -queuebot:#ubuntu-release- New: accepted elvish [i386] (artful-proposed) [0.10.1-1]
[13:03] <infinity> cjwatson: That particular unicorn is on my TODO.
[13:03] <infinity> cjwatson: Though I do also enjoy that chroot upgrades catch fun package bugs more often than one would expect.
[13:07] <gaughen> aw, I forgot that my chat highlights on unicorn :-)
[13:11] <LocutusOfBorg> infinity, do you have examples of such failures during chroot updates?
[13:12] <LocutusOfBorg> of course I wouldn't do a chroot update the day that there is a new perl out, or a new debhelper or dpkg
[13:12] <LocutusOfBorg> I just recreated my pbuilder chroot, and they decreased from 250MB to 100MB
[13:13] <infinity> LocutusOfBorg: Well, most recently was python3-defaults (though that was caught in proposed, so would have been caught even with more frequent updates), but we've had many in the past where an upgrade from a few months ago to today broke, but not from yesterday to today.
[13:13] <infinity> LocutusOfBorg: Not saying that's a valid reason for the chroots being stale, just a cute side-effect.
[13:14] <LocutusOfBorg> debian does them weekly IIRC
[13:14] <LocutusOfBorg> and I agree that they might be painful
[13:14] <LocutusOfBorg> but installing 100MB of packages at each build is... slow
[13:15] <infinity> Not terribly.
[13:15] <LocutusOfBorg> and now we are past freeze, so they should be some stability
[13:15] <infinity> Not compared to build-deps for most packages.
[13:15] <infinity> But you're not telling me anything I don't know, either. :P
[13:15] <LocutusOfBorg> :)
[13:16] <LocutusOfBorg> well, they are poisoning the logs, I do meld them when I find regressions, and that upgrade at the begin takes a lot of place
[13:16] <infinity> Honestly, the only person who usually has a resonable argument for chroot staleness is doko, who wants the old build-essential kicked out when gcc bumps versions, so people with undeclared build-deps on old-gcc will FTBFS.
[13:16] <infinity> "poisoning the logs" is a bit strong.
[13:17] <infinity> It's some extra bits at the top.
[13:17] <LocutusOfBorg> I hope you got the right meaning
[13:17] <LocutusOfBorg> what is annoying is that "(Reading database ... 30%
[13:17] <LocutusOfBorg> (Reading database ... 35%
[13:17] <LocutusOfBorg> "
[13:17] <cjwatson> That's just an apt bug IMO; it shouldn't say that when stdout isn't a terminal.
[13:17] <infinity> Yes, that's an annoying apt "feature" that showed up a year or two ago.
[13:17] <infinity> juliank and I had a chat about it once and why it is the way it is.
[13:17] <cjwatson> I fixed a similar thing in debconf a couple of months ago.
[13:18] <LocutusOfBorg> just to be clear to what I mean, look at https://launchpadlibrarian.net/337787137/buildlog_ubuntu-artful-amd64.libpng1.6_1.6.32-2_BUILDING.txt.gz
[13:18] <infinity> I think there's some switch I can mangle to turn that off (at the loss of some other functionality that I probably don't care about), I should look into that.
[13:18] <infinity> LocutusOfBorg: We know what you mean.
[13:18] <LocutusOfBorg> 1837 useless lines before the builds starts
[13:18] <LocutusOfBorg> and 1276 for the actual build :)
[13:19] <LocutusOfBorg> that would be awesome!
[13:19] <cjwatson> (Actually, sorry, "Reading database" is dpkg, not apt.)
[13:19] <LocutusOfBorg> why debian is not adding that lines?
[13:19] <doko> infinity: well, saving 10-15 seconds for every build adds ... but now that all the updates are in place, please could you regenerate these?
[13:19] <infinity> cjwatson: It's dpkg, but it's dpkg doing so because apt has started telling dpkg it has a controlling terminal when it doesn't.
[13:19] <cjwatson> Oh right, yeah.
[13:19] <doko> LocutusOfBorg: because they don't upgrade the chroot
[13:19] <infinity> doko: Yeah, updates are happening soon.
[13:20] <cjwatson> doko: That doesn't actually explain the lack of "Reading database" when installing build-deps.
[13:21] <LocutusOfBorg> because the second one is inside sbuild?
[13:21] <doko> ahh, these ...
[13:22] <cjwatson> I think the answer is that Debian has a more recent version of sbuild that sets DPkg::Use-Pty=false.
[13:22] <cjwatson> Dpkg, rather
[13:22] <infinity> cjwatson: Is that in the new sbuild?
[13:23] <infinity> cjwatson: If so, I'll put it in the chroot configs, so we get it for upgrades too.
[13:23] <infinity> (And don't need a new sbuild)
[13:23] <cjwatson> infinity: Yes, added in 0.69.0.  Can we please cherry-pick the sbuild fix instead?
[13:23] <infinity> cjwatson: Well, we can cherrypick the sbuild fix too if you want, but the upgrades happen outside sbuild.
[13:23] <cjwatson> I don't like stuff being done in chroot configs when it could be done somewhere more visible.
[13:23] <cjwatson> True, but we could put that in launchpad-buildd.
[13:24] <infinity> *shrug*
[13:24] <infinity> Then we should move all the chroot configs into lp-buildd.
[13:24] <infinity> Which then makes the chroots less reproducible for people using them outside lp-buildd.
[13:24] <cjwatson> I don't think it would be terrible to duplicate configs, necessarily ...
[13:25] <cjwatson> Dpkg::Use-Pty=false was apparently added as part of the huge sbuild refactoring to decouple chroot access
[13:26] <cjwatson> 668e86dbfe5d14defe54926cf58dec2dc39d876f
[13:26] <infinity> chroot-autobuild$ cat etc/apt/apt.conf.d/99buildd
[13:26] <infinity> APT::Get::AllowUnauthenticated "1";
[13:26] <infinity> APT::Install-Recommends "0";
[13:26] <infinity> DPkg::Options {"--force-unsafe-io";};
[13:26] <infinity> That's our current "special" congfig.
[13:26] <infinity> Oh, and can I ditch the top one now?
[13:26] <infinity> I think I can.
[13:26] <infinity> You inject the keys now.
[13:26] <cjwatson> Uh, well
[13:26] <cjwatson> It's not totally reliable in all cases
[13:26] <cjwatson> Yet
[13:26] <infinity> Oh. :/
[13:26] <infinity> That's discouraging.
[13:27] <cjwatson> I mean it should be, mostly, but there are cases like local development setups where I don't think it entirely works right yet.
[13:27] <cjwatson> I'd definitely like to get there.
[13:28] <infinity> Anyhow, I can add Use-Pty to that, and we can also make lp-buildd write out 99buildd, overwriting whatever the chroot defaults are, if you like.
[13:28] <infinity> Though, that's problematic if we need to special-case it per target.
[13:28] <infinity> (ie: if that didn't exist in trusty's apt)
[13:29] <cjwatson> apt doesn't care about nonexistent config keys
[13:29] <infinity> No?  That's handy.
[13:30] <juliank> It's also confusing that we don't care about them. I'd rather have warnings for unknown keys eventually.
[13:30] <cjwatson> Special-casing per target is easy in launchpad-buildd, anyway.
[13:30] <infinity> juliank: Then I need an APT::Config-Warn=false key. ;)
[13:30] <cjwatson> Wouldn't be the first time.
[13:31] <infinity> cjwatson: Yeah, we've done it in the past.  I don't like it, though.
[13:31] <infinity> I mean, when I can help it.
[13:31] <cjwatson> I would like it more if we had cdimage-style version comparison
[13:31] <infinity> Yes, and I don't want to cargo-cult that around either.
[13:32] <infinity> As useful as it is.
[13:32] <juliank> Currently there is strictly typed config backend stuff, but it's only turned on in tests (see configure-index or whats it called for the config config format)
[13:32] <cjwatson> It would certainly have to be done a bit differently in order to avoid having to upgrade launchpad-buildd for every new series.
[13:33] <cjwatson> Could use distro-info, I suppose, but I kind of want to minimise buildd's dependencies on that kind of thing.
[13:33] <infinity> cjwatson: Well, buildd-manager, being connected to the actual LP DB, has a real view of all the series, and their order of appearance, it could pass a dict.
[13:33] <cjwatson> This is true.
[13:33] <cjwatson> We already send flags for some things.
[13:33] <cjwatson> (Though I wouldn't want to do this in the same way; this kind of thing doesn't need proper columns in the DB.)
[13:34] <infinity> cjwatson: Or, if we're okay with magic numbers, it could just pass DIST_SEQ=19 and we know that 19==trusty, and do our comparisons on integers.
[13:34] <infinity> (19 isn't trusty, but I'm too lazy to count)
[13:34] <cjwatson> I'm not OK with magic numbers for this. :-)
[13:34] <cjwatson> 19 is trusty if you're 0-based
[13:34] <infinity> Closer than I thought.
[13:34] <infinity> And no, I don't dig magic numbers.
[13:35] <infinity> But an indexed array of series is a tiny amount of data lost in the noise, if we really wanted to have that on the buildds for $reasons.
[13:35] <LocutusOfBorg> thanks, really thanks for caring and trying to fix it :) kudos to all of you for this!
[13:39] <cjwatson> The other thing about buildd setup is that I'm trying to move things gradually towards the point where it's easier to run a test build locally via actual launchpad-buildd code.
[13:39] <cjwatson> You can do it today, but it's still a fair bit of setup.
[13:40] <cjwatson> So I don't want to make it *too* dependent on buildd-manager information for correct functioning.
[13:40] <infinity> Fair.
[13:41] <infinity> Point's moot right now anyway, as the one reason we envisioned needing version comparisons isn't an issue.
[13:41] <infinity> But something to think about for the next time we think we care.
[14:40] <doko> python-twisted-core/amd64 unsatisfiable Depends: python-automat (>= 0.6.0)
[14:40] <doko> python3-twisted/amd64 unsatisfiable Depends: python3-automat (>= 0.6.0)
[14:41] <doko> why? this dependency was good enough to run all it's tests ...
[14:43] <cjwatson> doko: main vs. universe
[14:44] <cjwatson> doko: it's in c-m-proposed
[14:44] <doko> ahh, and it still sees 0.5 in release/universe
[14:45] <doko> so this should go away, and then the autopkg tests run again \o/
[15:00] <doko> now looking at the virtualbox autopkg test failure ... did anybody look at those before?
[15:25] <LocutusOfBorg> doko, ping me for vbox
[15:26] <LocutusOfBorg> Running module version sanity check.
[15:26] <LocutusOfBorg> Error! Module version 5.1.28_Ubuntu for vboxvideo.ko
[15:26] <LocutusOfBorg> is not newer than what is already found in kernel 4.13.0-11-generic (5.1.28_Ubuntu).
[15:26] <LocutusOfBorg> apw, ^^ please ignore it
[15:26] <LocutusOfBorg> the kernel has already the module builtin, so the dkms one can't be installed
[15:26] <LocutusOfBorg> this is a bug that is in dkms, that should ignore and not error out when the module is already available and provided
[15:27] <LocutusOfBorg> anyhow, ignoring is fine
[15:27] <LocutusOfBorg> (that test works when virtualbox has an higher version than the kernel one, and fails when kernel folks merge the version)
[16:48] -queuebot:#ubuntu-release- Unapproved: maas (trusty-proposed/main) [1.9.5+bzr4599-0ubuntu1~14.04.1 => 1.9.5+bzr4599-0ubuntu1~14.04.2] (ubuntu-server)
[18:03] -queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (zesty-proposed) [2.2.6-6~ubuntu17.04.1]
[18:04] -queuebot:#ubuntu-release- Unapproved: aodh (zesty-proposed/main) [4.0.1-0ubuntu0.17.04.1 => 4.0.2-0ubuntu1] (openstack, ubuntu-server)
[18:05] -queuebot:#ubuntu-release- Unapproved: ceilometer (zesty-proposed/main) [1:8.0.2-0ubuntu0.17.04.1 => 1:8.1.1-0ubuntu1] (openstack, ubuntu-server)
[18:06] -queuebot:#ubuntu-release- Unapproved: cinder (zesty-proposed/main) [2:10.0.4-0ubuntu1 => 2:10.0.6-0ubuntu1] (openstack, ubuntu-server)
[18:07] -queuebot:#ubuntu-release- Unapproved: accepted partitionmanager [source] (zesty-proposed) [3.0.0-1ubuntu0.1]
[18:07] -queuebot:#ubuntu-release- Unapproved: heat (zesty-proposed/main) [1:8.0.2-0ubuntu1 => 1:8.0.4-0ubuntu1] (openstack, ubuntu-server)
[18:08] -queuebot:#ubuntu-release- Unapproved: keystone (zesty-proposed/main) [2:11.0.2-0ubuntu1 => 2:11.0.3-0ubuntu1] (openstack, ubuntu-server)
[18:16] -queuebot:#ubuntu-release- Unapproved: accepted partitionmanager [source] (xenial-proposed) [1.2.1-0ubuntu1.1]
[18:19] -queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (zesty-proposed) [4:5.9.5-0ubuntu0.3]
[18:23] -queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (zesty-proposed) [1.9-3.2ubuntu2.17.04.3]
[18:25] -queuebot:#ubuntu-release- Unapproved: neutron-fwaas (zesty-proposed/main) [1:10.0.1-0ubuntu1 => 1:10.1.0-0ubuntu1] (openstack, ubuntu-server)
[18:27] -queuebot:#ubuntu-release- Unapproved: sahara (zesty-proposed/universe) [1:6.0.0-0ubuntu1 => 1:6.0.2-0ubuntu1] (openstack)
[18:27] -queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (xenial-proposed) [1.9-3.2ubuntu1.16.04.4]
[18:28] -queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (trusty-proposed) [1.9-3ubuntu10.5]
[18:28] -queuebot:#ubuntu-release- Unapproved: nova (zesty-proposed/main) [2:15.0.6-0ubuntu1.1 => 2:15.0.7-0ubuntu1] (openstack, ubuntu-server)
[18:30] <stgraber> can I get a quick review of https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1718342 ? nothing crazy in there and would love to upload before the sprint
[18:30] <ubot5> Ubuntu bug 1718342 in lxd (Ubuntu) "[FFe] LXD 2.18" [Undecided,New]
[19:04] -queuebot:#ubuntu-release- New: rejected calc-stats [source] (artful-proposed) [1.2-0ubuntu1]
[19:08] <doko> finally \o/
[19:16] -queuebot:#ubuntu-release- New source: calc-stats (artful-proposed/primary) [1.3-0ubuntu1]
[19:17] -queuebot:#ubuntu-release- Unapproved: neutron (zesty-proposed/main) [2:10.0.2-0ubuntu1.1 => 2:10.0.3-0ubuntu1] (openstack, ubuntu-server)
[19:22] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (trusty-proposed) [1.2.2-0ubuntu13.1.23]
[19:24] -queuebot:#ubuntu-release- Unapproved: rejected maas [source] (trusty-proposed) [1.9.5+bzr4599-0ubuntu1~14.04.2]
[19:31] -queuebot:#ubuntu-release- New binary: gnome-getting-started-docs [amd64] (artful-proposed/main) [3.26.0-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
[19:40] -queuebot:#ubuntu-release- New binary: gnome-user-docs [amd64] (artful-proposed/main) [3.26.0-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
[19:40] -queuebot:#ubuntu-release- Unapproved: accepted maas [source] (trusty-proposed) [1.9.5+bzr4599-0ubuntu1~14.04.2]
[19:40] <slangasek> stgraber: looking
[19:41] <slangasek> stgraber: btw, can you explain why introspecting docker/run/systemd/resolve/resolv.conf and grepping out fe80 is a "better" way to handle detecting DNS?
[19:41] <slangasek> /run/systemd/resolve/resolv.conf seems like an implementation detail to me rather than a public interface; and I don't know why fe80 is showing up here in the first place
[19:43] <stgraber> slangasek: so the reason why I did it that way is because fe80 was showing up in systemd-resolve --status but it was rather annoying to filter out
[19:44] <stgraber> slangasek: as --status is meant to be user readable with fancy formatting and stuff. The underlying file OTOH can be trivially parsed to drop the odd fe80 and then look for a "real" DNS server
[19:44] <slangasek> stgraber: right, not being able to just grep -v the line because of multiple nameservers on the line would be annoying, I can see that.  But why is the fe80 there to begin with?
[19:44] <slangasek> the tests clearly passed just one revision earlier, and I've never seen this fe80 before
[19:46] <stgraber> slangasek: my guess is that it has to do with netplan recently re-enabling IPv6 (which is a good thing)
[19:46] <stgraber> slangasek: the docker test failure showing up lines up pretty well with that nplan upload
[19:46] <stgraber> I'm still confused as to why resolved would ever consider/show a link-local address for a dns server though
[19:47] <slangasek> stgraber: well, see parallel discussion in #ubuntu-devel where a LL ipv4 address is exactly what you expect to see in some clouds :)  But I don't know where the ipv6 one is coming from...
[19:48] <slangasek> I was wondering what lxd had changed to start advertising this into containers - but I guess not
[19:49] <stgraber> slangasek: LXD didn't change, but nplan until a couple of days ago would turn off IPv6 entirely on all interfaces it manages
[19:49] <stgraber> slangasek: which is likely why mwhudson didn't see the fe80 craziness when he added that code to the docker.io adt
[19:49] <stgraber> slangasek: then cyphermox fixed the nplan issue, re-enabling IPv6 on nplan managed interfaces by default (for SLAAC), causing this thing to show up
[19:50] <slangasek> sure
[19:50] <slangasek> but when you say "fe80 craziness"
[19:50] <stgraber> slangasek: my guess is that something (most likely networkd) is parsing the RA and extracing the RDNSS field, which dnsmasq most likely populates with both link-local and global IPv6 addresses of the DNS server
[19:50] <slangasek> this is a container, launched via lxd
[19:51] <slangasek> so... there shouldn't be any "craziness" there that's not of lxd's doing? :)
[19:51] <slangasek> ah, dnsmasq
[19:51] <slangasek> ok
[19:51] <stgraber> none of that is new, but in the past we didn't have networkd extracting that stuff and the switch to networkd happened at the same time as nplan turned off ipv6
[19:52] <slangasek> stgraber: ok, but then you still have the situation that fe80 is showing up in the list but is not working for DNS resolution (else you would not have needed to grep it out)
[19:52] <slangasek> is the problem that this is recorded as link local without corresponding interface routing info?
[19:52] <slangasek> is this a systemd bug?
[19:55] <stgraber> let me re-check an older log, I may have an idea of what's actually happening (and it may not be a systemd bug after all)
[19:55] <slangasek> ok
[19:56] <stgraber> hmm, "temporary failure resolving", ok, so my theory that DNS was functional but DHCPv4 wasn't, causing a missing IPv4 route to ftpmaster.internal, is wrong.
[19:57] <stgraber> so yes, it does look like we somehow hit a case where systemd-networkd had received a DNS server for the interface through a RA but is unable to send DNS requests to it
[19:57] <stgraber> which would point at a systemd-resolved bug
[19:58] <slangasek> stgraber: would you mind opening a bug report on systemd then, so we can discuss it next week w/ xnox?
[19:58] <stgraber> http://paste.ubuntu.com/25588197/ that confirms that the dnsmasq side of things is fine, DNS resolves through all 3 addresses
[19:59] <stgraber> yeah, I'll file a systemd bug
[20:00] <slangasek> ta
[20:02] <stgraber> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1718771
[20:02] <ubot5> Ubuntu bug 1718771 in systemd (Ubuntu) "Incorrect handling of link-local IPv6 DNS servers" [Undecided,New]
[20:07] <slangasek> LocutusOfBorg: where are these virtualbox autopkgtests triggered from?  no Testsuite in debian/control, no debian/tests
[20:16] <stgraber> slangasek: I hope this resolved thing didn't distract you from the LXD 2.18 FFe ;)
[20:18] <slangasek> stgraber: no moreso than the half dozen other things I'm trying to juggle ;-)
[20:18] <stgraber> :)
[20:20] <slangasek> stgraber: it'll be a little while longer, I think perhaps you would like me to have breakfast before I review an FFe
[20:21] -queuebot:#ubuntu-release- New source: calc-stats (artful-proposed/primary) [1.4-0ubuntu1]
[20:21] <stgraber> slangasek: that's some pretty late breakfast, isn't it called lunch at this point? :)
[20:31] <LocutusOfBorg> slangasek, please ask apw and look at discussion on #-devel :)
[20:31] <LocutusOfBorg> not sure who and how are triggered
[20:32] <dpb1> hi guys -- would love some release-team ffe approval on this one: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1658469
[20:32] <ubot5> Ubuntu bug 1658469 in apache2 (Ubuntu) "[FFe] mod_http2 is not available in Apache" [Low,Triaged]
[20:34] <slangasek> stgraber: it's still breakfast if it's the first meal.  also, eggs ;)  anyway, while I'm doing that, would you like to trade and review LP: #1567597 ?
[20:34] <ubot5> Launchpad bug 1567597 in Snappy "[FFe] implement 'complain mode' in seccomp for developer mode with snaps" [Medium,Confirmed] https://launchpad.net/bugs/1567597
[20:34] <apw> slangasek: virtual box is dkms, so autodep8
[20:35] <stgraber> slangasek: yeah, I can take that one
[20:35] <nacc> cyphermox: i also updated the corresponding MIR back to new: LP: #1687454
[20:35] <ubot5> Launchpad bug 1687454 in nghttp2 (Ubuntu) "[MIR] nghttp2" [Undecided,New] https://launchpad.net/bugs/1687454
[20:35] <slangasek> apw: where does that autodep8 live?
[20:36] <slangasek> undiscoverable triggers offend me
[20:36] <apw> the autodep8 script is in dkms, triggered direct in Britney I assume
[20:37] <apw> the virtual box specific failure is because of the kernel containing those drivers too
[20:37] <apw> and lob had a suggestion to change versioning in kernel
[20:37] <apw> to make them not clash and trigger that issue
[20:40] <slangasek> ok, and virtualbox gets triggered because it has autodep8 via dkms (in britney2, yes), and depends on python3.6
[20:41] <slangasek> if we're going to hard-code it in britney, we could at least refine it to not retrigger the tests when $random_binary_package that causes us to be triggered is not the dkms package. :P
[20:41] <slangasek> otherwise, I'd certainly prefer having this declared in debian/control
[20:46] <slangasek> dpb1: the MIR bug does not show as approved
[20:47] <slangasek> dpb1: also, process-wise, using for an FFe a bug that's already in a 'triaged' state can theoretically cause it to fall under the radar
[20:48] <slangasek> dpb1: I've acked the overall design, but it blocks on MIR team signoff still
[21:00] <jbicha> anyone besides Laney want to review some UIFe's? LP: #1717946 LP: #1718083 LP: #1715869 LP: #1713712
[21:00] <ubot5> Launchpad bug 1717946 in ubuntu-meta (Ubuntu) "UIFe: Drop xterm and xdiagnose from default install" [Undecided,Confirmed] https://launchpad.net/bugs/1717946
[21:00] <ubot5> Launchpad bug 1718083 in gnome-control-center (Ubuntu) "UIFe: Add Additional Printer Settings button" [Undecided,New] https://launchpad.net/bugs/1718083
[21:00] <ubot5> Launchpad bug 1715869 in gnome-control-center (Ubuntu) "UIFe: It should say 'Position on screen' not 'Screen position' in Dock panel in 3.25.x" [Low,New] https://launchpad.net/bugs/1715869
[21:00] <ubot5> Launchpad bug 1713712 in gnome-shell-extension-ubuntu-dock (Ubuntu) "[UIFe, FFe] Provide Unity Launcher API" [Medium,New] https://launchpad.net/bugs/1713712
[21:54] <slangasek> apw: replied to your comment on LP: #1714968 at sil2100's request
[21:55] <ubot5> Launchpad bug 1714968 in Ubuntu "[needs-packaging] [FFE] Please include uvp-monitor in Ubuntu" [Wishlist,New] https://launchpad.net/bugs/1714968
[21:57] <apw> slangasek: thanks will look it over again with that in mind tommorrow
[23:31] <slangasek> batch requeuing of failed autopkgtests now
[23:32] <slangasek> (those referenced from britney - so only a few dozen per arch)
[23:36] <slangasek> looks like all the weirdness with cups driver autopkgtests timing out is resolved
[23:38] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-133.182] (core, kernel)
[23:38] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-36.40~16.04.1] (kernel)