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