[14:53] <rcj> sru folks, can I get a promotion for walinuxagent to wily-updates for bug #1559307?
[15:11] <rcj> infinity or arges ^
[15:12] <arges> rcj: i can handle
[15:12] <rcj> arges, thanks
[15:13] <rcj> much appreciated
[15:14] <arges> rcj: done
[17:03] <stgraber> ^ I rejected juju from the queue as it doesn't have an approved FFe, this doesn't mean that there is anything wrong (or right) about the upload itself
[18:29] <slangasek> so... how did we just get a new component mismatch for po-debconf, post-beta?
[18:30] <infinity> slangasek: *blink*
[18:30] <slangasek> or is this email lying to me?
[18:30] <infinity> slangasek: Oh, new perl modules.
[18:30] <infinity> slangasek: I thought you meant po-debconf itself.
[18:30] <slangasek> no, I mean po-debconf, which ought not to have changed recently, now has new deps?
[18:31] <infinity> Guessing one of its deps has new deps.
[18:31] <infinity> Or something.
[18:31] <infinity> Erm.  Nope.
[18:31] <infinity> Wat?
[18:32] <slangasek> libio-compress-perl is a direct Recommends of po-debconf and is in universe
[18:32] <infinity> Right.
[18:32] <slangasek> did cjwatson and xnox land germinate changes that confused c-m?
[18:32] <infinity> In wily, it only did libcompress-zlib-perl
[18:33] <infinity> But, as you say, it hasn't changed in ages in xenial.
[18:33] <slangasek> libcompress-zlib-perl is not a package it seems, but a virtual one
[18:33] <infinity> Oh!
[18:33] <slangasek> Reverse Provides:
[18:33] <infinity> Yes, same deps in both.
[18:33] <slangasek> libperl5.22 5.22.1-9 (= )
[18:33] <slangasek> libio-compress-perl 2.069-1 (= )
[18:33] <infinity> So maybe an alt resolution changed.
[18:34] <infinity> In wily, perl provides libcompress-zlib-perl
[18:35] <infinity> And libperl in xenial, as you say.
[18:35] <infinity> But also no new perl recently that moved that around.
[18:35] <infinity> So still a bit confused.
[18:37] <infinity> slangasek: It's probably resolvable by explicitly seeding libperl in the same place as perl, or something equally gross, but the timing of this certainly points to someone breaking germinate.
[18:37] <infinity> (given that none of the packages involved changed recently)
[18:39] <slangasek> infinity: well, but that germinate output comes from the copy running on ftp-master, which I wouldn't expect to change without mention :)
[18:42] <infinity> slangasek: Plot thickens.  It's only listed in armhf output.
[18:42] <slangasek> hmm!
[18:43] <infinity> http://paste.ubuntu.com/15554184/
[18:43] <infinity> slangasek: So, maybe something went out of sync or otherwise busticated on ARM.
[18:43] <infinity> Or something touch-specific.
[19:13] <infinity> slangasek: Are you digging further into the po-debconf WTFery, or did you want me to run with it (after I finish some IBM bits I've been working on)?
[19:14] <infinity> slangasek: Realised we may have both dropped it on the floor, thinking the other was dealing with it. :P
[19:17] <slangasek> infinity: it's still on my queue, but I've been flash-sponsoring php uploads and will now grab food; feel free to dig without me
[19:33]  * ogra_ notes that this channel looks more and more like a logfile
[19:33] <stgraber> that tends to happen during this part of the cycle, especially when doing mass rebuilds after a freeze :)
[19:33] <slangasek> so does my inbox :P
[19:34] <ogra_> haha
[20:58] <cjwatson> slangasek: Nothing's changed in germinate as yet.
[20:58] <slangasek> cjwatson: yep, thanks :)
[21:00] <xnox> slangasek, i'm pretty sure i have not addressed cjwatson's comments hence nothing was merged nor deployed yet.
[21:01] <LocutusOfBorg> pretty please accept cmake 3.5ubuntu2 from unapproved
[21:01] <LocutusOfBorg> the ubuntu1 in -release that has just landed is broken
[21:01] <LocutusOfBorg> and the block for migration has been removed too much in advance :s
[21:02] <LocutusOfBorg> (because ubuntu2 went in that queue)
[21:02] <cjwatson> xnox: Also the LP side must be implemented and deployed before deploying germinate.
[21:03] <cjwatson> xnox: (Otherwise we'll break a ton of builds.)
[21:03] <cjwatson> xnox: (Or at least incite AAs to do so.)
[21:04] <LocutusOfBorg> yay the first bug because of that landing https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1563548
[21:04] <ubot5`> Launchpad bug 1563548 in cmake (Ubuntu) "CMake 3.5's pkg-config support broken" [High,New]
[21:04] <xnox> cjwatson, my understanding is that germinate changes can land, it's just we may not flip the "no-follow-build-depends" feature in the seeds until lp is ready.
[21:05] <xnox> cjwatson, speaking of lp - should i be providing patch for that too?
[21:05] <slangasek> LocutusOfBorg: reviewing.
[21:05] <LocutusOfBorg> thanks slangasek
[21:06] <slangasek> LocutusOfBorg: I am singularly unimpressed with FFes for core build components, past beta freeze
[21:06] <LocutusOfBorg> actually as you can see it wasn't intended to land, the block migration has been removed with an assumption of "package auto accepted" probably
[21:06] <cjwatson> xnox: Ah, true, we could land it without the seed feature flag once you fix those bits.
[21:06] <slangasek> it shouldn't have been uploaded if it wasn't intended to land
[21:07] <slangasek> it's a *build* system
[21:07] <LocutusOfBorg> slangasek, a good archive rebuild has been done, and Debian had that cmake too since some time
[21:07] <slangasek> we build in -proposed
[21:07] <LocutusOfBorg> slangasek, I mean ubuntu2 should have been gone in -release
[21:07] <cjwatson> xnox: I suspect neither of us has much more time to spare than the other, and I can probably do an LP change more quickly, but we'll see
[21:07] <LocutusOfBorg> ubuntu1 was migration-blocked
[21:07] <LocutusOfBorg> but removing the block without the ubuntu2 accepted in proposed triggered the migration
[21:07] <infinity> LocutusOfBorg: The block was removed by a human, not a computer.
[21:08] <infinity> (It was pitti)
[21:08]  * LocutusOfBorg is not real part of this issue, he is just trying to help, nothing more
[21:08]  * LocutusOfBorg has some knoledge on the particular patch due to previous merges, and helped in fixing the fixable, and he will help more if new issues arises
[21:08] <slangasek> infinity: you see that on a blocking bug?
[21:09] <infinity> slangasek: https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1534263
[21:09] <ubot5`> Launchpad bug 1534263 in cmake (Ubuntu) "[FFe] [merge request] Import cmake-3.5 series to Ubuntu Xenial 16.04LTS" [High,Fix released]
[21:09] <xnox> cjwatson, i wonder if things will be resolved differently with universe enabled.... due to e.g. "a | b" build-depends, where "a" is in universe =/
[21:09] <cjwatson> xnox: Almost surely.
[21:09] <slangasek> infinity: thanks
[21:10] <cjwatson> xnox: We can hope that the consequences are minor ...
[21:10] <xnox> i wonder if it is statically analyzable, surely we don't have that many "a | b" build-depends.... one can hope.
[21:10] <cjwatson> (I think they probably will be, but perhaps somebody should try to work out how to simulate the resolver for everything)
[21:11] <infinity> We intentionally use a|b to pick a preferred b due to the ogre model.
[21:11] <infinity> But I don't know how often we do it.
[21:12] <infinity> And, really, we should just stop doing it that way.  But "just stop that" is a hard thing to do with 4 weeks to go.
[21:13] <infinity> cjwatson: I suspect it's a lot less prevalent these days, since the Debian release team has been pushing people for binNMUability for transitions.
[21:13] <infinity> cjwatson: We used to take heavy advantage of a|b due to deps like "libfoo2 | libfoo-dev", so we could rev libfoo before Debian.
[21:13] <xnox> only 256 with a '|' in build-depends
[21:13] <infinity> But Debian has been changing that for years, so transitions can be hands-off.
[21:13] <xnox> in main
[21:14] <infinity> xnox: That might almost be analyzable.
[21:14] <cjwatson> I think a lot of those will be non-existent-in-Ubuntu | existent-in-Ubuntu or vice versa.
[21:14] <infinity> Hopefully they all are. :P
[21:14] <cjwatson> With that it might be possible to get it down to a list short enough to check by hand.
[21:14] <cjwatson> Which is probably quicker than trying to write an analyser if it's that sort of length.
[21:15] <infinity> As I said, historically, it was "in-universe | in-main" to force forking from Debian.
[21:15] <infinity> I'd like to think 99% of those are gone.
[21:15] <infinity> Well, more subtly, "in-universe | provided-in-main"
[21:16] <cjwatson> FWIW my plan was to (ab)use the newish DistroSeries.publishing_options column to add a new flag for this.
[21:16] <cjwatson> I wish I'd thought of this and just called it options or something, but anyway.
[21:16] <cjwatson> Yeah, gotta check Provides for the existence checks, definitely.
[21:18] <infinity> Oh man, I just had an evil thought.
[21:18] <infinity> cjwatson: This concern is purely about build-dep resolution in sbuild, not about germinate, right?
[21:18] <infinity> cjwatson: Cause I could totally just pin main a tiny bit higher than universe, and it might DTRT. :P
[21:18] <infinity> (Though, maybe not... apt might not be that smart)
[21:18] <infinity> Actually, I'm sure it's not.
[21:18] <infinity> Pinning is just for versions of the same package, now that I think of the code.
[21:19] <infinity> Drat.
[21:19] <infinity> No evil for me.
[21:19] <cjwatson> Yeah, I doubt that would help.
[21:19] <infinity> BUT I WANT EVIL.
[21:20] <xnox> looking most of things are mostly harmless
[21:20] <xnox> gazzilion of libperl-foo-dev | perl (>= new enough), or vice versa
[21:21] <xnox> a bunch of libfooN-dev | libfoo-dev
[21:21] <cjwatson> I'd suggest doing the initial filtering automatically.
[21:22] <cjwatson> Grab all Package entries and all Provides (remembering to comma-split) from Packages on all architectures, use that as the existence filter.
[21:22] <infinity> xnox: We use "libfooN-dev | libfoo-dev" to force transitions early sometimes.
[21:22] <xnox> bison | byacc,
[21:22] <mwhudson> hm i guess i should fix the one of those in golang-1.6 at some point
[21:23] <infinity> But if they all resolve fine in xenial today, we can deal with the fallout for 16.10.
[21:23] <xnox> mawk | awk, is popular too.
[21:23] <xnox> sometimes with gawk
[21:23] <infinity> mawk | awk is a no-op, given awk is Essential.
[21:23] <infinity> gawk, however, is not.
[21:26] <xnox> autopoint | gettext (<< 0.18-1), autopoint | cvs -> looks weird
[21:27] <xnox> why "gawk | awk" or "mawk | awk" make any difference?
[21:27] <xnox> i'm pretty sure neither generate runtime, or built-using dep =)
[21:27] <xnox> hence it's irrelevant in the no-follow-build-depends world as to which one was used to build stuff.
[21:28] <cjwatson> It sure is relevant if one of them runs code correctly and the other doesn't.
[21:28] <xnox> unless things FTBFS with wrong awk ofcourse.
[21:28] <slangasek> I build-depend on awk exclusively for use of libawkpic.a
[21:28] <cjwatson> Which has been known to happen.
[21:28] <xnox> cjwatson, oh really =/ sigh
[21:29]  * xnox assumes maintainers that declared " | awk" have tested other awk implementations.....
[21:29] <cjwatson> However, mawk vs. gawk is not relevant to the question of main vs. universe, since both are in main.
[21:29] <slangasek> I'm also working on a cross between awk and lua called skwa
[21:29] <cjwatson> So if it's resolved correctly today it should still be resolved correctly after no-follow-build-depends.
[21:30] <xnox> slangasek, nice, does it have guile bindings?
[21:31] <slangasek> xnox: no, my interpreter is guileless