[05:19] <infinity> rsalveti: Hah.  Damnit, I literally just did that identical merge and it got rejected two minutes after yours was accepted. :)
[05:20] <rsalveti> infinity: :-)
[05:20] <infinity> rsalveti: (Though, I missed the extra-comma fix in build-deps, so yours was better anyway)
[05:20] <rsalveti> thanks for fixing it anyway
[05:20] <infinity> So, I guess not identical.  One char off. :P
[07:59] <cjwatson> apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/saucy_uninst.txt much prettier :-)
[07:59] <cjwatson> (though still need to sort out linux-ppc)
[08:03] <apw> cjwatson, ^5 indeed, that is much better
[08:04] <apw> cjwatson, if you have a patch for linux-ppc we can get that in with luck before he rebases
[08:08] <cjwatson> apw: Do you happen to have a git remote URL to hand for it?
[08:09] <apw> cjwatson, https://github.com/benmcollins/ubuntu-saucy-powerpc.git and i should be able to commit it
[08:15] <cjwatson> Righto
[09:43] <infinity> cjwatson: So, curiously, those kernel fixes highlighted exactly why we need to be at 0 uninstallables.
[09:43] <infinity> cjwatson: Britney quite happily traded fixing 6 broken udebs for breaking 1 d-i, and slid it right in. :P
[09:46] <apw> i wonder if d-i should be a special, as too expensive to break
[09:47] <infinity> Nah.
[09:47] <infinity> It'll be fine now.
[09:47] <infinity> This was a one-time event.
[09:47] <infinity> Though, I think britney might actually have a config option for "never let these packages break".
[09:47] <infinity> I vaguely recall seeing something like that in passing.
[09:47] <cjwatson> Heh
[09:48] <cjwatson> infinity: You fixing d-i?
[09:48] <apw> given we make CDs out of the results, and those are 'today' it might make some sense
[09:48] <infinity> cjwatson: Already done hours ago after I noticed the oops.
[09:49] <cjwatson> apw: like infinity, I'm not too bothered as this ceases to be a problem once we abolish things it can trade
[09:49] <infinity> apw: When I remove ti-omap4 (I should do that tomorrow), I can finish up the seed changes I left half done, and can spread the d-i love around to the kernel team too (well, you and Tim).
[09:49] <apw> cjwatson, yeah i can see that makes a lot of sense
[09:49] <apw> and i am all for making it so
[09:50] <jamespage> stgraber, ^^ revised horizon that does tidyup as well
[09:51]  * jamespage goes to look at test cases for balloons
[09:51] <cjwatson> I'm not aware of a "never let this package break" option FWIW
[09:51] <cjwatson> (presumably this will happen once more as we fix linux-ppc)
[09:51] <infinity> cjwatson: Yeah, I think I was confusing it with b1's noremove.d stuff.
[09:52] <infinity> I'm not fussed about PPC breaking for a day if I don't notice it right away.
[09:52] <infinity> It not automatically tested by people who whine 20 minutes after a broken ISO happens.
[09:52] <infinity> s/It/It's/
[09:53] <cjwatson> orig: 396+0: i-69:a-33:a-29:p-36:a-229
[09:53] <cjwatson> easy: 341+0: i-35:a-22:a-19:p-36:a-229
[09:54] <cjwatson> is a nice thing to see though
[09:54] <infinity> Shame about that last a.
[09:56] <jamespage> balloons, plars: so the only tests cases we don't have covered with automated tests are: maas-*, Install (Default + crypted LVM), iscsi-*, rescue-mode, Install (No Network Connection), Install (JeOS on ESX)
[09:57] <cjwatson> Manual rescue testing did actually show up a fairly important bug in the final beta cycle
[09:58] <jamespage> cjwatson, good
[09:58] <jamespage> cjwatson, I actually still think there is merit in getting a person to run the tests at least once a cycle
[09:59] <infinity> Manual testing definitely has a place.  We've even managed to convince people who make decisions that this is true.
[09:59] <infinity> So, yay.
[09:59] <jamespage> cjwatson, picks up stuff that automated testing does not because its not exactly the same
[09:59] <infinity> (But the more automated tests you can ALSO have, the better)
[10:00] <jamespage> infinity, agreed - generally less nasty surprises when you do some manual testing!¬
[10:00] <cjwatson> As I said to balloons, the right answer is for routine stuff to be covered automatically so that manual testing can be creative and find things we missed
[10:01] <cjwatson> I think that's all the KDE changes through to the release pocket now
[10:02] <cjwatson> (once again I had to chase up some build failures due to poor ordering)
[10:08] <infinity> Hrm.  openclipart's build log seems to be full of a lot of "path/to/foo.png is already optimized." ... That might be a prime candidate for a NO_WHATEVER_MANGLE.
[10:09] <cjwatson> infinity: Not at all by coincidence I'm test-building such a thing right now
[10:09] <infinity> Hah.  Same trigger/annoyance for you?  "Say, why is that buildd still on O, when the others are on P?"
[10:10] <infinity> OH LOOK, CLIPART.
[10:10] <cjwatson> Just taking a while since it's hyoooooooooooooge
[10:10] <cjwatson> Right
[10:10] <cjwatson> Also it's taken twice as long as the last primary-archive build of the same version did, for some reason
[10:10] <cjwatson> Dunno if optipng has got even slower or what
[10:10] <infinity> I wouldn't be surprised.
[10:11] <infinity> I'd also love to see if we can figure out a safe way to parallelize the PNG opt part of pkgbinarymangler.
[10:11] <infinity> Given that all our buildds are multi-core.
[10:11] <infinity> And some excessively so.
[10:11] <apw> infinity, png things, surley that is the definition of paralelisable
[10:12] <infinity> Well, the easiest way it just to call it N times for N cores, but the way pkgbinarymangler is written doesn't allow for that all that pleasantly.
[10:13] <cjwatson> Could just use parallel(1)?
[10:18] <infinity> cjwatson: Could do.  Could probably do it in pure shell with wait without too much trouble, actually.
[10:18] <xnox> (gnu parallel from universe can preserve ordering and buffer stdout/stderr if that's important, it's in universe though.)
[10:18] <infinity> xnox: That's what Colin suggested, yes.
[10:19] <infinity> I'm slightly less concerned about confusing output.  Sort of par for the course for -j builds already anyway.
[10:19] <xnox> infinity: well there is moreutils & gnu variants of parallel(1)
[10:20] <infinity> xnox: Both of which are in universe, so meh. ;)
[10:20] <infinity> (But I'd rather not be pulling even more packages into the default chroots for something that can easily be done in shell)
[10:20] <xnox> oh, i see. I somehow thought moreutils is in main.
[10:20] <apw> yeah we just need a loop with a wait in it
[10:21] <cjwatson> Using either of moreutils or parallel is a bit problematic here, unfortunately
[10:21] <cjwatson> What if a package build-depends on the other ...
[10:21] <infinity> I think my concern last time was about double-parallelisation, so we'd get 24x24 optipngs going on sagari, but pkgbinarymangler already disables --parallel for dh_builddeb to avoid races in the symlink code.
[10:22] <cjwatson> There are some pure-shell gizmos in snakefruit:/home/ubuntu-archive/bin/archive-reports for running N commands at a time that you could use
[10:22] <cjwatson> Perha
[10:22] <infinity> cjwatson: Yeah, I have a simple gizmo in the livefs build log mirror too.
[10:22] <cjwatson> ps
[10:23] <cjwatson> Not remotely as clever as GNU parallel of course
[10:23] <infinity> cjwatson: (Which I think I cargo-culted from build-livefs...)
[10:23] <cjwatson> http://paste.ubuntu.com/6183271/
[10:24] <cjwatson> That's amenable to being used in a for loop of the type found in pkgstripfiles
[10:24] <cjwatson> infinity: That one just runs them all at once, rather than having control over how many it runs
[10:25] <infinity> Well, controlling how many isn't rocket surgery.
[10:25] <infinity> You can either chunk your input, or use counters.
[10:25] <cjwatson> Sure
[10:26] <infinity> Waaait.
[10:26] <infinity> xargs can do this?
[10:26] <cjwatson> I may well have to cancel the openclipart2 build in order that launchpad-buildd can be upgraded, which is my other motivation
[10:26] <infinity> Combining -n and -P
[10:26] <cjwatson> Oh, yeah, forgot about -P
[10:26] <cjwatson> I searched for "parallel" in xargs(1) and came up with nothing :-P
[10:26] <infinity> -n 1 -P $(nproc), done.
[10:27] <infinity> xargs is too clever.
[10:27] <cjwatson> Still, it might be easier to do the wait thing because that would let you use shell functions and avoid having to create a separate script
[10:27] <cjwatson> Since we're doing both optipng and advpng in here (and some other bits) and probably want to parallelise the lot
[10:28] <cjwatson> Some care needed with the md5sums mangling too
[10:28] <cjwatson> That obviously can't be parallelised, at least not without doing it completely differently
[10:28] <infinity> Having another script doesn't hurt my feelings.  And locking md5sums isn't hard.
[10:28] <cjwatson> I'd batch that up and do the whole thing at the end, rather than locking.
[10:29] <cjwatson> Write out all the new md5sums to a separate file and have a perl script to merge them back at the end
[10:29] <infinity> pkgpngmangle should be its own script anyway, stripfiles isn't where it belongs.
[10:29] <cjwatson> (Come to think of it, with a huge package, that might be quite slow in itself right now)
[10:30] <infinity> A quick sed on even a huge MD5SUMS file shouldn't be too bad.  But batching it all up and doing it in one quick perl script would probably be faster.
[10:30] <infinity> Even accounting for the split second it takes to start perl.
[10:31] <cjwatson> md5sums for openclipart2-png is 13194 lines, 1.3MB or so.  Writing out 1.3MB 13194 times is not completely ideal to have to do, even if it doesn't dominate
[10:31] <cjwatson> Sure, it's a quick sed, but multiplied by the number of PNGs
[10:31]  * infinity nods.
[10:34] <pstolowski> stgraber: ping
[10:35] <infinity> Of course, if I rewrote it in perl and called it from dpkg-deb, I'd have threading and output buffering available to me too.  And could just buffer the md5s and write them all out at the end, without futzing with multiple processed and temp files.
[10:35] <infinity> This escalated quickly from a 2-line hack to a rewrite.
[10:35] <infinity> Maybe I should do it in Go!
[10:35]  * apw withdraws infinity's coffee supply
[10:37] <infinity> apw: I think my suggestion was so offensive that it actually knocked Colin off the Internet.
[10:38] <infinity> Oh, actually, as much as my "hey, I can rewrite this in perl!!" thing sounds fun, there's zero reason the md5sum part needs to be in the loop.
[10:38] <apw> infinity, hehe ... very likely
[10:38] <infinity> I could just take the file list, xargs optipng, then md5 the lot and do one big sed/perl/whatever.
[10:39] <apw> ^^ that is from smb, this is a resync with debian to reduce our delta ... testing looks good and we have rebuilt all of its rdepends as well; infinity aware
[10:39] <infinity> ^-- I'm reviewing that Xen, nobody else needs to worry about it, I have context with apw and smb already.
[10:45] <cjwatson> infinity: I don't know quite what the hell's wrong with my connection at the moment, even beyond the usual
[10:46] <cjwatson> It didn't even drop properly, it just didn't catch up enough for irssi to acknowledge
[10:47] <infinity> cjwatson: Some day, you'll get real internets.
[10:47] <cjwatson> Some day my prince will come
[10:47] <apw> not a chance he is in the wrong country, in a bit which has no technology companies, no reason to ... oh wait
[10:47] <rbasak> ^ uvtool was me. Minor bugfix I fixed in "upstream" trunk first.
[10:48] <rbasak> Oooh, thanks!
[10:48] <cjwatson> apw: I showed you http://cjwatson.dreamwidth.org/2827.html, right?
[10:48] <cjwatson> rbasak: Was probably automatic.  https://lists.ubuntu.com/archives/ubuntu-release/2013-September/002605.html
[10:49] <rbasak> Ah. I see, thanks. I should read ubuntu-release.
[10:49]  * rbasak subscrubes
[10:49] <infinity> Subscrube sounds dirty, for some reason.
[10:49] <cjwatson> Ear of the beholder.
[10:50] <apw> cjwatson, perhaps the reason you don't have it is because even bt cannot find it
[10:50] <infinity> cjwatson: Background/rationale for that ltsp change?
[10:51] <infinity> Oh, possibly because we don't have kbd-chooser at all.
[10:53] <cjwatson> Exactly
[10:53] <cjwatson> It was in saucy_uninst as a result
[11:02] <apw> cjwatson, were you doing a patch for linux-ppc, or can i assume it is basically the same as that for master
[11:03] <cjwatson> apw: Just preparing it now as a matter of fast
[11:03] <cjwatson> *fact
[11:04] <apw> cjwatson, cool i am about to abuse the a machine for a test build and it can do both at once
[11:05] <cjwatson> apw: https://lists.ubuntu.com/archives/kernel-team/2013-October/033068.html
[11:05] <apw> cjwatson, thanks, will sort
[11:05] <cjwatson> block-modules Provides: nbd-modules had been done in master a while back, but not ppc
[11:06] <cjwatson> (2735470d39cade45bf2d2c1f80fea55cb94733b3)
[11:08] <infinity> apw: "the a machine"? :)
[11:10] <infinity> apw: Have you handed off saucy/lowlatency to zequence yet, or is there one or two rebases still in your court?
[11:10] <apw> infinity, you know how my grasp of english is... tenuious at best ... spelling less so
[11:11] <apw> infinity, in theory i am in the process, but he is off sick anyhow, and so htis one i am doing
[11:11] <apw> (in the process of handing it off)
[11:11] <infinity> Kay.
[11:11] <infinity> We probably need to have a talk sometime about doing -signed for lowlatency.
[11:11] <apw> i need to make sure the tools bits are right anyhow, so it is helpful if i do it, and indeed it is done and building now
[11:12] <apw> yep, that isn't hard to do, the core bits are the same in the package so it should be a matter of turning it on
[11:12] <apw> and making a -signed for it of course
[11:16] <zequence-work> infinity: Yes, for the LTS, we probably want that
[11:17] <zequence-work> apw: Ah, nice. I have yet to investigate what that all is about
[11:18] <infinity> I'd still like to see lowlatency magically build out of master, but I'm not holding my breath.
[11:18] <infinity> I had hoped tickless would save us all, but it appears not quite ready for prime time.
[11:36] <sil2100> Hi release team! Can I get some eyeballs from the SRU team to check https://bugs.launchpad.net/unity/+bug/1043627 ?
[11:36] <ubot2> Launchpad bug 1043627 in nux (Ubuntu Raring) "[SRU] Add XIM Support to Nux" [Undecided,Confirmed]
[11:36] <sil2100> It's already waiting over few months now ;)
[12:51] <infinity> cjwatson: Thanks for making remove-package take multiple '-a'
[12:51] <cjwatson> YW
[12:51] <infinity> (Just used it when whacking old ac100-tarball-installer binaries)
[12:51] <cjwatson> Been annoying me for a while
[12:51] <cjwatson> Ah, thanks, that was on my todo
[12:54] <infinity> seb128: Have you noticed or looked at the EDS autopkgtest failure that's preventing it from migrating?
[12:56] <seb128> infinity, yes, I was just looking at that, I know what it is, going to upload a fix in the next half an hour
[12:58] <infinity> seb128: Awesome, thanks.
[12:58] <seb128> infinity, yw
[12:59] <infinity> seb128: Just wanted to make sure it wasn't going unnoticed.  Some people don't tend to pay attention to migration issues.
[12:59] <infinity> (And then there's the part where one in a billion people can decipher Jenkins output...)
[12:59] <seb128> infinity, I got a nice email from jenkins telling me ;-)
[13:00] <seb128> well, jenkins is not easy to browse, but I could confirm the issue here
[13:37] <doko> another gcc-4.8 upload coming ... please let this build first before accepting things like lo
[13:38] <cjwatson> Is it needed specifically for libreoffice?
[13:39] <doko> no, just a fix for a wrong-code regression in 4.8 on armhf
[13:40] <cjwatson> doko: I mean, is it just that you want to make sure libreoffice isn't occupying all builders?  (Which it wouldn't be anyway)
[13:40] <cjwatson> Or do you want to make sure that libreoffice is built with the new compiler?
[13:41] <doko> yes, the latter, although I'm still trying to understand the impact of this issue (what kind of things could be misbuilt)
[13:43] <seb128> infinity, e-d-s ^
[13:44] <infinity> seb128: Danke.
[14:01] <infinity> doko: When can I expect that gcc-4.8?
[14:02] <infinity> doko: (Should I reserve sagari for you, or is it a few hours away?)
[14:05] <pstolowski> stgraber: ping
[14:09] <doko> infinity, 30min, waiting for a test build
[14:10] <infinity> doko: Kay, I'll keep sagari for you, then.
[14:41] <pstolowski> Riddell: ping
[14:42] <Riddell> hi pstolowski
[14:42] <pstolowski> Riddell: hi! can I bring this bug https://bugs.launchpad.net/unity-lens-applications/+bug/1231556 to your / release team attention? just got doc+translators ack
[14:42] <ubot2> Launchpad bug 1231556 in Unity Home Scope "[UIFFe] Inconsistency between Dash plugins category name and filters" [High,In progress]
[14:43]  * stgraber does some queue review now
[14:43] <stgraber> pstolowski: pong
[14:43] <pstolowski> stgraber: hey! just talking to Riddell about ^
[14:45] <rsalveti> stgraber: mind checking hybris ^? bugfix to unblock the autopilot mediaplayer related test cases
[14:45] <Riddell> pstolowski: find with me if translations and docs people are fine
[14:46] <pstolowski> Riddell: can you +1 it?
[14:46] <Riddell> pstolowski: commented on bug
[14:46] <pstolowski> Riddell: ta!
[14:48] <pitti> any opinion about "upgrade" vs "backport 4 patches" for bug 1234219?
[14:48] <ubot2> Launchpad bug 1234219 in ofono-phonesim (Ubuntu) "Does not accept calls to 05123xx -- FFE: update to 1.19" [Undecided,New] https://launchpad.net/bugs/1234219
[14:53] <stgraber> jamespage: sorry for the delay, horizon accepted, thanks for the fix!
[14:53] <jamespage> stgraber, ta
[14:54] <stgraber> diff from 319.49-0ubuntu2 to 319.60-0ubuntu1 (105.3 MiB) <- I wonder if we had much large diffs than that ;)
[14:59] <rsalveti> thanks!
[15:02] <infinity> stgraber: What was that diff for?
[15:02] <infinity> Doesn't seem excessive at all...
[15:06] <stgraber> nvidia binary driver
[15:06] <stgraber> basically replacing 50MB worth of binary blobs by another 50MB :)
[15:07] <stgraber> I really love it when upstreams have very detailed and easy to read changelogs! /me accepts libx11 (as long as the diff is, it actually seems to be bugfix only and gets rid of a bunch of patches)
[16:29] <doko> infinity, gcc-4.8 uploaded and set ross to manual
[16:30] <infinity> doko: Will look as soon as I get a diff from the queue.  Thanks.
[18:54] <infinity> smoser: Bah, I thought you said maas was going to depend on ubuntu-cloudimage-keyring ... It started depending on ubuntu-cloud-keyring, but not the other.
[18:55] <smoser> infinity, CRAP
[18:55] <smoser> roaksoax, ^
[18:55] <smoser> suck.
[18:56] <infinity> roaksoax: While we're at it, you need to file a few more MIRs for new maas dependencies.
[18:57] <infinity> roaksoax: Oh, I guess just curtin.
[19:16] <smoser> infinity, bug 1220434 is there.
[19:16] <ubot2> Launchpad bug 1220434 in curtin (Ubuntu) "[MIR] curtin" [Undecided,New] https://launchpad.net/bugs/1220434
[19:22] <infinity> smoser: Weird, c-m isn't picking that up.
[19:23] <infinity> Oh, you didn't sub ubuntu-mir.
[19:26] <roaksoax> smoser: so what is it? ubuntu-cloudimage-keyring or ubuntu-cloud-keyring?
[19:27] <smoser> ubuntu-cloudimage-keyring
[19:34] <roaksoax> smoser: ok, i'll make a new upload. Could you also propose the packaging fix for the upstart job so It can land now?
[19:35] <smoser> roaksoax, i'm looking at it.
[19:35] <roaksoax> smoser: k!
[21:00] <infinity> smoser: Out of curiosity, what is ubuntu-cloud-keyring, and why isn't that also in main?
[21:02] <stgraber> infinity: isn't that the cloud archive keyring?
[21:02] <infinity> stgraber: One would assume, yes.
[21:02] <infinity> (Why that and the cloudimage keyring aren't just one keyring, I'm not sure...)
[21:03] <infinity> Like we have our FTP and CD keys both in ubuntu-keyring.
[21:03] <stgraber> because the cloud archive isn't enabled by default and some people may not want to trust it by default?
[21:03] <infinity> Oh, I guess cloud images don't actually use the cloud archive, unlike cdimage/ftpmaster being paired.
[21:03] <infinity> Fair enough.
[21:03] <stgraber> ftp and cd keys make sense because our official medias contain a pool that's signed by the CD key, so an installed system needs to trust both keys to work properly
[21:04] <stgraber> not the case with the cloud stuff
[21:04]  * infinity nods.
[21:05] <smoser> infinity, the cloud images keyring doesn't actually sign packages.
[21:05] <smoser> at all
[21:05] <smoser> just data
[21:05] <smoser> the cloud archive keyring (ubuntu-cloud-keyring) signs packages
[21:08] <infinity> smoser: Check.
[21:27] <apw> these linux-ppc and linux-lowlatency uploads are derivative rebases to latest master source version to bring all to the same underlying version
[22:06] <cjwatson> infinity: ^- pretty please stop britney from doing bad things for too long by accepting that d-i
[22:06] <infinity> cjwatson: I'll accept it when it can be built. :P
[22:08] <cjwatson> Oh, is the publisher taking a while?
[22:09] <infinity> cjwatson: The kernels aren't built...
[22:09] <cjwatson> Oh, I can't read
[22:09] <cjwatson> Read that as binaries
[22:33] <infinity> cjwatson: That linux-ppc should be done in ~20m, I'm guessing.  I'll stay up long enough to see it publish, push d-i, and bump seeds.
[22:33] <infinity> cjwatson: (ie: feel free to piss off, since it's all late and stuff over there)
[22:35] <cjwatson> Yeah, might do in a bit