[00:11] Officially EODs, will unofficially be around to fiddle with images and check on the queue. :P [01:34] slangasek, ugh on the eglibc. [01:35] third time's the charm for respins? [01:38] * skaet crosses fingers. [01:42] are the isos hosted somewhere? [01:44] CareBear\ path to them is on the iso tracker [01:45] basically on cdimage.ubuntu.com [01:46] there are a few :) [01:49] CareBear\, yup. [01:50] :) [03:57] * skaet --> zzz [04:29] Good morning [04:29] pitti: Can you prove that? [04:29] hm; grey and rainy outside, and still a bit tired [04:29] BUT! [04:30] http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html [04:30] beer-y! [04:30] q. e. d. [04:30] And who doesn't like beer on their cornflakes? [04:30] * pitti should update the script to add a bowl of fruit before 1200 UTC [04:30] or a Yoghurt shake [04:50] pitti: I'm tempted to do one last mass-give-back to see if anything in universe FTBFS magically shakes out. [04:50] pitti: Any objections? [04:50] I'm all for that [04:51] otherwise all those shiny buildds will just freeze to death, give them some work out :) [04:51] ;) [04:51] infinity: how many builds are we talking about? powerpc might not be able to catch up with all of them [04:51] ah well, it's all opportunistic anyway [04:52] PPC can catch up fine. :P [04:52] 91 builds on PPC, most of which will probably fail/dep-wait in the first few minutes. [04:52] * micahg will be doing Mozilla uploads over the weekend :) [04:53] but I think it'll be fine as well [04:53] micahg: Those will all be main, so they'll beat the universe give-backs. [04:54] infinity: oh, yeah, and in a security PPA :) [04:54] (Well, maybe not chromium, but you have friends who can fix that) [04:54] Oh, in the PPA, even better. [04:55] I'm kinda wildly shocked that i386 and amd64 FTBFS is so low (well, sorry, "not-built", not the same as FTBFS from rebuild tests, which is higher) [04:56] infinity: +1 maintenance has helped :) [05:02] That and we really aggressively pruned old crap in Lucid. It makes it easier now. [05:02] Everything in the archive with binaries has built at least once in the last two years. [05:02] Speaking or pruning, removing libembperl-perl. [05:03] Considering removing gnat-4.4, but it has r-bdeps. [05:03] You've got a few days to fix that. [05:03] * micahg is wondering about ldc which is unbuildable [05:03] has rdeps [05:04] can someone go pruning again removing stuff removed from Debian? [05:05] I'm sure we can, not sure I'm doing it at 11pm. [05:05] But we still have a week to make sure universe is perfect and shiny. [05:05] Hey look, something shook out! [05:06] Shame it failed on i386. :P [05:06] But, progress... [05:07] You know, the archive would be in much better shape if we just dropped Haskell, Ada, and D. [05:09] cnd: Upon further reflection (and reviewing the diff a few times), I accepted your xorg-server into -proposed, meaning it's a likely "respin opportunity" candidate. Given that, can you make sure it gets some solid testing once binaries poop out the other end? [05:13] fixes rebuild dep-wait ^^ [05:13] pitti: I'm thinking update-notifier wants accepting, but I'll leave it to you as a desktoppy fellow who cares. ;) [05:14] pitti: (Also, because I'm thinking you can explain why it needs to import 5GB of po files) [05:17] infinity: because LP again took the diff against the pre-last version, not against 0.119ubuntu8 [05:18] * pitti checks the real diff [05:18] pitti: Oh. That was only the 5-line change from Brian? [05:18] pitti: That would be much more readable. :P [05:18] pitti: (We need to fix that) [05:18] I'm double-checking [05:18] yes, just the "missing gettext" part [05:19] Context not found: "ubuntu/precice-proposed" [05:19] 2012-04-20 05:19:00 ERROR Error encountered -- aborting current transaction [05:19] err, what? [05:19] $ q -Q unapproved -s precice-proposed fetch update-notifier [05:19] ...? [05:19] * pitti looks harder [05:19] No can spell. [05:19] preciCe? [05:19] *blush* [05:20] so, the gettext fix plus autoconf noise [05:20] I'm not entirely sure whether the latter is justified [05:20] it looks like Brian didn't have gnome-common installed [05:21] There needs to be a law against using different versions of autotools in stable releases (and in the weeks leading up to). [05:21] infinity: I think I'd prefer reuploading this with gnome-common installed, and fake-sponsor it for Brian [05:21] If the noise is actually a problem in this case, go ahead and re-upload. :) [05:21] * infinity nods. [05:21] I can't tell for sure that it is a problem, but I'd rather avoid it [05:22] Yeah, that's fair. [05:22] When I do stable updates, I actually go out of my way to make sure autojunk gets replicated the same as the previous version. [05:22] Just out of paranoia. [05:22] Or OCD. [05:22] Probably more the latter. [05:23] (This is a surprising challenge when doing stable updates of apt, as mvo seems to randomly switch autoconf versions more than most people switch their underwear) [05:23] http://paste.ubuntu.com/937864/ - now how is that [05:24] pitti: ZOMG readable. [05:24] pitti: And Brian's patch is "obviously correct". [05:25] pitti: Does u-n have arch skew? [05:25] pitti: If not, while you're sponsoring, jam it into release. :P [05:25] hardly [05:25] pitti: We already know we're rebuilding for eglibc, at least. [05:25] I can reupload [05:25] Just edit the Distribution line in .changes and reupload. [05:26] done [05:26] so you now have two, pick the one you prefer :) [05:26] Hahaha. [05:26] Brian's going to be so confused. [05:26] infinity: eglibc? nice [05:26] I left a comment for him in the bug [05:26] infinity: kernel 3.3 would be nice, too! [05:27] pitti: We (and be "we", I mean vorlon, but I'm not naming any (real) names) may have messed up the daemon restart logic, and ended up killing kdm on upgrades. [05:27] pitti: kubuntu upgrade testers are unimpressed. [05:28] * pitti does bug 985940 and gets rid of another FTBFS [05:28] Launchpad bug 985940 in libpgjava "FFE exception for Precise: libpgjava" [Undecided,Triaged] https://launchpad.net/bugs/985940 [05:30] * micahg just filed bug 986017 to rid another rebuild FTBFS [05:30] Launchpad bug 986017 in ruby-sequel "FFe: Sync ruby-sequel 3.33.0-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986017 [05:33] wait, what, are my eyes deceiving me? I see a 3rd PPC build [05:33] *buildd [05:33] micahg: You do. [05:34] \o/ [05:35] infinity: do you want to give back the rebuild as well? [05:35] Not really. [05:35] Mostly cause I don't have a script to do that, and I don't speak lplib well enough to do it by hand. [05:36] Another thing I need to fix, now that the world's moving/moved to the LP API. [05:36] 3rd buildd> ooh! [05:36] infinity: ok, maybe when cjwatson arises [05:37] Also, for parallel builds, sulfur should be about twice as fast as the others. [05:37] So, aim your compilers and web browsers and office suites there. :P [05:37] orly? so libreoffice should be down to ~10hrs [05:37] firefox won't parellelize ATM, but nice to know there's a chance for improvement [05:38] although I have 4 builds at a time for it [05:38] The other buildds are dual 2GHz G5s with 3G of RAM, sulfur's a quad 2GHz POWER5 with 4G of RAM. [05:38] So, nearly identical for serial builds. [05:39] so, if I ever get firefox to parallelize again, that means we can probably build an update in ~12 hours [05:39] (We were going to make sulfur the livefs builder, but after testing it against royal, it came out almost identical, so I figured the two more cores made more sense for package builds) [05:39] indeed [05:40] we do have a lot of packages that can parallelize and more being added all the time [05:40] *nod* [05:40] I think you can kind of blame us for that. [05:40] We forced the issue a while ago when I just 5-bladesed parallel building into the buildd network and watched the world burn. :P [05:41] Patches made it back to Debian remarkably quickly back then, as I recall. [05:41] (The number of people who thought it was appropriate to -jN debian/rules without testing it in any meaningful way was remarkable) [05:42] * micahg likes dh --parellel [06:24] * infinity raises his brow. [06:24] ^-- What was that about? [06:26] infinity: sorry for the spam; doing kernel SRU training with RAOF [06:26] Ahh. [06:26] I just fixed copy-proposed-kernel.py to use the async method [06:26] we did the real SRU copyign with the old script still, which uses syncPackage() and thus doesn't hit +queue [06:26] async sync just sounds odd. :P [06:34] infinity: ok to accept u-notifier? [06:34] yay, the LP diff is correct this time [06:35] pitti: What update-notifier? [06:35] that very :) [06:49] mvo: Mornin'. [06:50] mvo: Thanks for the quick apt fix. You're my hero. [06:51] infinity: your welcome, thanks for your report about it, that was right in time [06:51] I probably should have found it earlier, but who reads build logs, right? :/ [06:51] Would have been embarrassing to trip over after release, if elmo decided to upgrade cocoplum. :P [06:52] * mvo nods [06:52] oh yes :) [06:52] (At least, I'm assuming it would die in the same way on a "real" archive) [06:52] it would, I'm pretty sure [06:52] Unless file lists take it through a safer codepath. [06:53] mvo: Do you still touch upstream apt, or have you backed away completely? [06:53] mvo: Your (fairly critical) FD fix, and my (pretty much just cosmetic) FD fix should both get into Debian. [06:54] mvo: I think I may have even linked the Debian bug in the changelog for mine. If I was awake when I did it. [06:54] Ahh, yeah, I did. [06:58] infinity: yeah, I will merge it into debian too [06:58] mvo: *hug* [07:05] infinity: well, once bzr finishes upgrading my branch to whatever is the latest format that is not compatible with the one used in my other branch :/ [07:07] mvo: Hahaha. [07:15] Waiting on gnupg (28932) to finish generating a key. [07:15] * infinity taps his foot. [07:44] pitti: can you please promote chromium in lucid to -updates and -security? [07:47] micahg: on it [07:47] micahg: ^ looks right? [07:47] pitti: yes [07:48] pitti: thanks [08:25] pitti: chromium in natty-proposed is ready as well [08:46] micahg: done [08:47] doko_: Good morning. :P [08:47] pitti: thanks [08:47] infinity, did I wake you up? ;P [08:47] infinity: FYI, jibel tested the python upgrade, working fine [08:47] pitti: With the above upload? [08:47] I'll review/accept into -proposed as soon as it gets diffy [08:47] infinity, yes [08:48] and then we can see for 0-day SRU or folding it into release, depending on whether we'll respin [08:48] doko_: So, what do you (with a community hat on, I guess?) want to do about the FTBFS compilers in universe? [08:48] infinity, which ones? [08:48] doko_: thanks for the fix! [08:49] doko_: gnat-4.6 has been FTBFS on armel since (accidentally?) turned on sf/hf multilib. [08:49] doko_: gnat-4.4 is FTBFS on all arches. I'd happily remove it, but it has reverse build-deps. [08:49] pitti: my gdb upload is still pending? [08:50] infinity, if gnat-4.4 has reverse-deps, then these should be removed, or built with 4.6 [08:50] doko_: someone blocked it on https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus [08:50] infinity: I'll try to poke at gnat-4.4 rdeps over the weekend if you or doko don't beat me to it [08:50] pitti: even for -proposed? [08:50] micahg: Consider the lock yours, I'm on airplanes. [08:51] doko_: So, micahg just took 4.4 off our hands. Fixing 4.6/armel would be nice, though, since it used to work. :/ [08:51] pitti, ahh, I think it was slangasek. but the changes are bug fixes only [08:51] doko_: I gave a quick pass at disabling sf/hf multilibs, but I clearly didn't grok the packaging well enough on the first pass. [08:51] micahg, it doesn't make sense to "fix" 4.4, better try to remove it [08:51] infinity: I can't promise due to the large number of other things I'm balancing on my plate [08:51] doko_: yes, I plan to get the rdeps upgraded to 4.6 versions from Debian :) [08:52] less risky in an SRU, of course, but as the bug neither has a test case (or something that's actually broken), nor a regression test plan, it won't be easy to get it to -updates [08:56] hmm, can we re-enable the upgrade entries on the tracker? [08:57] oh, I guess it'd make sense to wait for python though === doko_ is now known as doko [09:02] doko: My initial stab at fixing gnat-4.6 was http://paste.ubuntu.com/937997/ but it appeared to have no effect, so I suspect I'm missing a bigger picture. ;) [09:03] infinity, I'll have a look [09:04] micahg, libgtkada can't be built with 4.6? [09:08] doko: I already filed the removal for libgtkada2 [09:09] doko: libgtkada2 was superseded by libgtkada, just to be confusing. [09:09] ahh, ok [09:10] libgtkada is already built with gnat-4.6 FWIW [09:10] micahg: Whose baby is reverse-depends(1) (or the web service it uses)? [09:10] adconrad@cthulhu:~$ reverse-depends libgtkada2 [09:10] reverse-depends: Error: Unknown package [09:11] infinity: tumbleweed wrote it I think, it's hosted on ubuntuwire [09:11] As opposed to checkrdepends, which gets it right. [09:11] infinity: you need src: [09:11] yeah, requires more flags than checkrdepends [09:11] Oh. --help doesn't say that. :P [09:11] * micahg would love a current version of that :) [09:12] infinity: polyorb removal: http://packages.qa.debian.org/p/polyorb/news/20120305T100750Z.html [09:13] micahg: Nuked. [09:15] * infinity removes narval from that same mailing list post. [09:15] Oh, nevermind. Already gone. [09:15] yeah, we did that a while ago [09:15] infinity: patches welcome :) [09:16] tumbleweed: This is just a documentation issue, apparently. [09:17] tumbleweed: Or, it's an I can't read issue. [09:17] probably needs to say "binary package" so that it's more obvious what the problem is [09:17] tumbleweed: src is there in help, just cleverly hidden in the middle of my terminal. [09:17] ah [09:18] But yeah, a more informative error wouldn't hurt. [09:18] source packages probably should have been the default, it's all I use it for :/ [09:18] It could also use a slightly more machine-friendly output format. [09:18] there's an option for that [09:19] Oh, -l [09:19] * infinity tries. [09:19] That's more pleasant. [09:19] infinity: ok, filed 3 FFe, ghcl I think we can just remove with gnat-4.4, all that's left is apq* which I'm testing now [09:20] tumbleweed: Okay, then once we get over my inability to read, I think my only remaining complaint is that I need to run it twice. [09:21] tumbleweed: Since I can't seem to get it to give me both rdeps and rbdeps together. [09:21] But maybe that's by design. [09:22] yeah, I wish that would be fixed as well :0 [09:23] micahg: ghdl, you mean? [09:23] yes :) [09:23] That actually sounds remotely useful. [09:23] Shame it's unmaintained. :/ [09:23] indeed, but we can backport it if it ever gets fixed and people want it [09:24] micahg: Bugs for the FFes? I'm too lazy to go hunting. [09:24] give me a minute, filing 2 more [09:25] I accept verbal FFe requests. Especially for universe. [09:27] bug #986073, #986077, #986086, #986094, #986095 [09:27] Launchpad bug 986073 in opentoken "FFe: Sync opentoken 4.0b-3 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986073 [09:27] Launchpad bug 986077 in gnade "FFe: Sync gnade 1.6.2-9 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986077 [09:27] Launchpad bug 986086 in libaunit "FFe: Sync libaunit 1.03-7 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986086 [09:27] Launchpad bug 986094 in apq "FFe: Sync apq 3.2.0-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986094 [09:27] Launchpad bug 986095 in apq-postgresql "FFe: Sync apq-postgresql 3.2.0-2 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986095 [09:27] and we're almost done :) [09:27] infinity: that sounds pretty solvable :) [09:29] micahg: The first three didn't need exceptions. [09:29] infinity: new binaries need an FFe :) [09:29] or so I've been told [09:29] micahg: Just debian revision bumps with bugfixes (build-deps) [09:30] Oh, meh. They squirt out new binaries? [09:30] Whatever. :P [09:30] yes, hence the paperwork :) [09:30] * infinity syncs. [09:30] * micahg could sync them :) [09:30] True. [09:30] Do 'em all. [09:31] I'll assume you've commented appropriately [09:31] do you want any of them in -proposed? [09:31] micahg: release is fine. But if that last one doesn't have properly versioned build-deps, make sure to stagger the uploads. [09:32] ok [09:32] deps are properly versioned [09:33] Then sync away and close your bugs. ;) [09:34] done and done [09:35] Oh dear, this is unpleasant: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/985852 [09:35] Launchpad bug 985852 in apt "libapt-pkg regression: infinite loop on processing certain Pre-Depends" [High,In progress] [09:35] infinity: once those publish, here's the removal: Bug #986096 [09:35] Launchpad bug 986096 in gnat-4.4 "Please remove gnat-4.4 and its reverse dependencies from precise" [Wishlist,Confirmed] https://launchpad.net/bugs/986096 [09:35] that was a very productive half hour :) [09:36] although sleep was on the schedule :) [09:36] mvo: Do you know if that infinite loop affects us (ie: do we have an ORed Pre-deps), or is it SRUable? [09:36] micahg: Sleep's overrated. [09:36] I have a court date tomorrow, I'm trying to get as much work in as I can. :P [09:36] So I can show up wild-eyed. [09:36] It'll be great. [09:37] infinity: oops, forgot one, hold off on removal :) [09:37] micahg: I'm not removing until the rdep list is clear anyway. :P [09:37] micahg: I *do* check these things. [09:40] *blink* [09:40] You don't have enough RAM to build PyPy. [09:40] It's known to require >= 1400 MiB on 32 bit archs. [09:40] Why does it need *physical* RAM? Or is the Debian maintainer just a doofus? [09:41] Ask him. The doofus is in here. [09:41] tumbleweed: Hey, doofus. [09:41] tumbleweed: See above. ;) [09:41] infinity: it'll take a week to build [09:41] probably more [09:42] the GC walks across all the memory quite often [09:42] infinity: bug #986105 [09:42] Launchpad bug 986105 in topal "FFe: Sync topal 75-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986105 [09:42] infinity: I think its SRUable and also needs a release-upgrader-apt upload for the lucid->precise upgrade [09:42] infinity: I prepeared that but want to give it a testrun in jenkins first [09:43] mvo: If you think it's worth a release-upgrade-apt build, then I think it should be in release, not an SRU. :P [09:43] while the regression risk is tiny, I'm worried about $anything at this point :/ [09:43] tumbleweed: But I assume it's no that evil at runtime, right? [09:43] infinity: but let me do a quick analysis [09:43] no [09:44] infinity: teh build process is "import everything into memory, perform type analysis, optimise, write C". Uses an insane amount of RAM [09:44] tumbleweed: A week-long build doesn't really hurt my feelings (though, obviously a bit late for precise) unless you upload the package every 2 days.. [09:45] infinity: in the archive it seems to be pretty much only debconf, default-jre and udev | makedev [09:45] mvo: That's a longer list than 0. [09:45] mvo: That settles it for me, we want it fixed, IMO. [09:45] (And not in an SRU) [09:46] * infinity gets to reviewing. [09:47] infinity: ok, I think I agree, probably I'm in too much of a OMG-stable mode currently [09:47] mvo: No, that's the right mode to be in. [09:47] mvo: But I don't want to take a chance on this asploding upgrades. [09:48] mvo: The MaxLoopCount guard probably could have been avoided for a targetted fix, though... [09:48] mvo: (Since I assume you also fixed the loop?) [09:48] can someone approve the last gnat-4.4 rdep FFe from me above? [09:49] micahg: Oh, looking. [09:49] micahg: Seems slightly more featureful than the other syncs, but it's for the greater good. :P [09:50] infinity: I was being nice to the debian buildds. LP has less tiny-memory architectures [09:50] infinity: indeed, thanks [09:50] tumbleweed: Yeah. I should spin it up on a Panda and see how it fares. If it's alright, you can guard your guard in an lsb_release check for Ubuntu. [09:51] infinity: sure [09:54] infinity: ok, going to sleep now, I'll check when I get up to make sure all the stuff that was supposed to build did, thanks for your help [09:55] micahg: Thanks for looking. ;) [09:55] infinity: right, I can do a upload to final without the MaxLoopCount, I would like to SRU it though later as its IMO useful, the unknown is how high this count needs to be [09:56] mvo: Oh, I agree that the option's useful. And the implementation even seems reasonable reviewable. I just want tiny for fixes. ;) [09:56] * micahg still can't believe we're shipping 4 versions of vala in the archive... [09:57] micahg: How many in main? [09:57] 2 last I checked [09:57] :/ [09:57] I remember the good old days, pitti and I used to be draconian about duplication in main. [09:59] arguably vala is a duplication in itself [09:59] mvo: Oh ick, and I've seen that modifier bug before. I didn't spend enough time looking at it to realise what was happening. [09:59] infinity: btw, building pypy on a low-memory machine is almost certainly going to timeout sbuild. It's already timing out on a bunch of decent buildds in Debian (if sbuild was line-buffered, I think it'd be OK, but it isn't) [10:01] tumbleweed: you could always grab the change that fta added to chromium that outputs something every 5 minutes [10:01] urgh :) [10:01] GCC has a similar hack. [10:02] Also, I take it back, I'm not spinning this up on my Panda, since my Panda needs to be in my suitcase in ~1.5 days. [10:02] Silly me. [10:02] tumbleweed: Remind me that I cared about this, and we'll look at it for Q? [10:03] :) [10:04] tumbleweed: I'll test on a QuickStart too (which is what the Debian/armhf builders are), and if it's good on both, you can just turn it on there too. [10:04] But yeah, it might need a logping hack or something if it's going to take days to do its thing. [10:05] I believe it was GCC on m68k that drove doko to write that awful hack in the first place. :P [10:05] micahg: actually, I don't think that's even an option, as it does legitimately timeout too. [10:05] infinity: https://launchpad.net/~ubuntu-cruft-busters! [10:06] * micahg applies [10:06] Ditto. [10:06] Even if it is owned by NCommander. ;? [10:06] ;) [10:06] TYPING HARD. [10:07] infinity: if we need an approbation, we can use the yada removal :) [10:08] tumbleweed: Wait... [10:08] tumbleweed: Is the ascii art how it keeps the build alive? ;) [10:09] yes. But the ascii art is based on events, not time [10:09] Oh, and those events can really be hours apart? [10:09] Shame. [10:09] 4k worth of dots can be hours apart [10:09] Ahh. [10:09] That's a solvable problem. [10:10] in my measuring, each line is always a lot less than that on a capable buildd [10:10] Watching this is kinda soothing. [10:10] it's colour if you do it by hand :P [10:10] Oooo. [10:13] mvo: Okay, I've read this a few times, in both directions, uphill both ways, in the snow. [10:13] mvo: I'm inclined to accept it as-is. The two bugs are both worth fixing, and the MaxLoopCount looks safe and sane. [10:15] mvo: When do we get a matching release-upgrader-apt? [10:18] infinity: the release-upgrader-apt is uploaded to a PPA once the testing there is done I move that to lucid-proposed [10:18] mvo: Mmkay. [11:21] ^ your mass give back? [11:22] oh, yes, I was going to look at a mass give-back for the test rebuild [11:23] * cjwatson fires up lp-shell [11:23] cjwatson: infinity did that this morning apparently [11:23] he did that for the main archive, not the test rebuild [11:23] there's stuff in scrollback abou tit [11:24] pitti, cjwatson, infinity: I'd like to fix bug 981037 for precise. 0-day sru? [11:24] Launchpad bug 981037 in openjdk-6 "The javac executable doesn't produce full paths for files on error" [Undecided,New] https://launchpad.net/bugs/981037 [11:25] doko: yeah, normal SRU seems fine; this isn't release critical for final certainly? [11:26] pitti, I'd like to build it in -proposed, so that jibel can test it. no, not for final [11:26] sure [11:30] cjwatson: fyi, the test-openssl.py qrt failures were because I needed to specify -tls1 to s_client. I think what is happening is s_server is defaulting to -tls1 and s_client is not [11:30] cjwatson: I'm going to not worry about it at this point [11:31] ah, that makes sense, I hadn't got round to looking at that yet [11:32] come on, Launchpad, I'm only asking you to load 1472 objects [11:32] ah, there we go [11:33] I guess I want to give back only source packages without newer versions in the main archive [11:48] >>> len(builds_not_superseded) [11:48] 496 [11:48] that looks about right [11:48] >>> for b in builds_not_superseded: [11:48] ... b.retry() [11:49] builders are filling up now [11:49] time for our new shiny builders to earn their money! [11:49] or electrons [11:50] * cjwatson ♥ launchpadlib [11:50] i386 8 26 jobs (43 minutes) [11:50] buildds with go-faster stripes! === greyback is now known as greyback|lunch === greyback|lunch is now known as greyback [13:10] gah, just spotted a security flaw in apt-setup for extras.ubuntu.com handling [13:10] we need a new ubiquity to sync up with console-setup anyway, so can I upload this? it's just adding predownloaded Release/Release.gpg files so that the initial update is forced secure [13:13] sounds good [13:17] cjwatson: While you're in there, add a nice comment block for security? ;) [13:17] too late, sorry [13:17] file a bug :) [13:17] Oh, indeed. [13:17] Curses, queuebot. [13:18] I don't care deeply enough to file a bug. [13:18] I always wipe my sources.list anyway. :P [13:18] pitti, openjdk-6 uploaded [13:18] Just felt odd that it's the only one without comments. [13:23] apt-setup looks good [13:23] actually, why don't we have the .gpg too? [13:23] we do [13:24] it might not show up in the diff since it's a binary file [13:24] oh right, diff and binary, sorry [13:24] * stgraber needs to add some visual way of spotting binary files in mc's diff viewer... [13:45] stgraber: babeltrace has no bug refs, no open bug, and looks very intrusive; was that discussed before? [13:45] It would sure have been nice if GLU ES had been packaged by somebody [13:46] pitti: we're trying to get on the full lttng 2.x stack that includes babeltrace 1.0, we were previously on a development snapshot, I now pushed the RC and we're expecting the final in the next few days [13:47] pitti: lttng is fully self contained at this point, nothing depends on it and it's not seeded [13:47] stgraber: ok, I assume you tested with the new lttng-* packages and on precise? [13:48] pitti: yes, upstream develops on Ubuntu and have daily builds. I built them locally on my machine and am running with them [13:48]