[00:33] doko, infinity: running into a strange error trying to merge busybox from Debian; they've turned on nfs mount support, but this causes a build failure: http://paste.ubuntu.com/958833/ [00:33] doko, infinity: this looks related to the glibc sunrpc split-out; any idea how this was working in Debian? [00:34] slangasek: You're sure that's not just an as-needed thing? [00:35] infinity: AFAICS nothing tries to pull in librpcsvc.a here [00:35] oh yes, I should've said, it's only the static build that fails [00:36] doko_: nice timing :) do you have any idea about this? http://paste.ubuntu.com/958833/ [00:36] (That's probably just his client bouncing) [00:36] yep [00:40] https://bugs.gentoo.org/show_bug.cgi?id=379481#c27 [00:40] infinity: Error: Could not parse XML returned by bugs.gentoo.org: HTTP Error 404: Not Found (http://bugs.gentoo.org/xml.cgi?id=379481) [00:40] ubot2: That was remarkably unhelpful. [00:40] infinity: Error: I am only a bot, please don't think I'm intelligent :) [00:42] slangasek: I think the answer might be "use 1.19.4" [00:42] mmk [00:43] still concerned that this worked in Debian but not Ubuntu [00:43] Debian is glibc 2.13 [00:43] But all accounts, this seems to have changed in 2.14 [00:43] oh, dur [00:43] yes [00:44] Oh, wait, the NFS mount fix is in 1.20.0 [00:44] But I'm betting it's fairly simple to backport. [00:45] yeah, for the moment I'll just disable NFS in the static build [00:45] it's a new feature we weren't missing before, so I'm not in a hurry for fixing just yet [00:46] http://git.busybox.net/busybox/commit/?h=1_20_stable&id=a86e02492d7700ce8cb4108f53646dfb025c2dff [00:47] And possibly: [00:47] http://git.busybox.net/busybox/commit/?h=1_20_stable&id=39b233182c0a13200be051b993da181a1db80a87 [00:48] Yeah, if those two backport with minimal fuss, that should do it. [00:48] And we're > 2.6.23 on hardy and later, so that seems sane for us. [00:49] yep [00:49] provided we think bypassing the system rpc headers is sane :) [00:54] Is anything busybox does sane? [00:54] * slangasek idly twiddles busybox to make it pick up hardening again [00:55] * infinity decides he's done with his "You're in a maze of registers, all alike" text adventure for the day, and goes to hunt sushi. [01:03] did the branch lifting the dpkg pre-depends requirement actually land? [01:06] ah, looks like it [01:10] micahg: Yeah, but probably won't be deployable for a day or two. [01:10] meh, I just sync'd something that depends on it :( [01:10] the way the queue looks though, that should actually work out just fine :-/ [01:11] Heh. [01:11] infinity: you wanna score down the builds for me? [01:11] micahg: Sure, which source? [01:11] infinity: coccinelle [01:12] * micahg thinks this is a first for him, having builds scored *down* [01:13] Not sure that made much difference in their queue positions, but they're definitely dead last now. :P [01:14] yeah, well, I expect more uploads over the next few days :), I don't need it done now, I just wanted it off my list :) [01:16] "Tokyo Cabinet is the successor of QDBM"... Who names these projects? [01:17] Not to be confused with Kyoto Cabinet, which is another DBMish thing [01:18] Ah, at least the Tokyo Cabinet homepage mentions Kyoto Cabinet. [01:18] I can't tell if you're pulling my leg or not. [01:18] srsly [01:18] http://fallabs.com/tokyocabinet/ [01:18] First paragraph [01:18] "BTW, do you know Kyoto Cabinet?" [01:18] ... [01:18] Yes [01:19] I thought for ages they were the same thing. [01:19] But they're actually distinct projects. [06:37] ogra_: fyi, looks like you didn't run sync-mirrors after fixing the md5sums this morning; done now [09:10] micahg: I wouldn't worry too much about it - a few retries at this point won't be the end of the world or anything [09:11] micahg: I synced quite a few that will probably fail for that reason; better to get them off *my* plate [09:11] hehe [09:14] wgrant: the pending QA looks kind of trivial, though; is there something else blocking deployments? [09:14] cjwatson: The QA before your thing is done [09:14] in fact I'm not really sure why both those revisions weren't no-qa [09:15] The QA after that (particularly 15180) is extremely non-trivial. [09:15] But we can deploy 15177 now [09:15] Assuming production doesn't decide to blow up again [09:15] oh, bah, when I said that the deployment report I had loaded only went up to 15179. [09:16] That's like so 16 minutes ago. [09:16] 15178 could be no-qa, I guess. [09:16] Let me just review the diff. [09:16] and 15179 is a test fix, isn't it? [09:17] Yes. [09:17] no-qa [09:17] er, as opposed to a testfix. [09:17] testfix, testfix. [09:18] Let's just go with 15177 [09:18] 15178 has already broken qastaging today :) [09:19] (meant to look at this hours ago, but the distractions just kept coming) === bulldog98_ is now known as bulldog98 [11:04] cjwatson: deploy is done [11:06] cool, thanks [11:14] Good, and a sample retry worked too. [11:17] Great. === peterm-ubuntu is now known as Peter_lunch === doko_ is now known as doko [13:19] cjwatson: should our package uploads for quantal be going through -proposed first and then be pocket copied? [13:20] cjwatson: ie. similar to our process at the end of Precise [13:23] ogasawara: right at the moment, there's so much skew from the initial auto-sync that it hardly matters [13:24] ogasawara: once that settles down a bit, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-April/000949.html still applies, I think [13:24] until such time as we have better tools [13:24] ack [14:15] Bah, whoever synced tex-common before tipa kinda broke the world. [14:16] * infinity goes about papering over this. [14:19] And texlive-base... And... Fun. [14:31] cjwatson: Oh, it was you! [14:31] cjwatson: So, uhm. New tex-common = Very Bad Thing. [14:32] cjwatson: I think we may have just been backed into a corner where we have to manually re-bootstrap the entire tex-* interdependency mess. [14:33] cjwatson: (Even backing it out would require a small "bootstrap", though slightly less painful) [14:33] Argh [14:33] Er, sorry :-( [14:33] So it just needs new tipa? Can we build that in a PPA and copy it? [14:33] Yeah, no, it needs way more. [14:33] Bugger [14:34] texlive-*, tex-*, it seems they all interdepend in nasty ways. [14:34] I thought it was an easy fix for an lmodern dep-wait [14:34] So how does it break? [14:35] Hrm, this chroot I've been playing in might be getting a bit too dirty to answer that. :P [14:35] infinity: maybe https://launchpad.net/~texlive-backports/+archive/ppa would help? [14:36] infinity: I mean is there some current-ish build that it breaks? [14:38] cjwatson: tipa is enough to fix tex-common on its own, but then the world explodes when you try to install other bits. I think. Like I said, my chroot's too dirty to give sane answers, let me start with a fresh one. :P [14:39] Oh, right, it's the "Breaks: texlive-common (<< 2010)" that blows up the world. [14:39] And it cascades from there. [14:39] Into all tex/texlive bits. [14:39] And since tex-common ultimately build-depends on itself (and on texlive), backing it out is about as painful as forging ahead. [14:39] So, I'll look at the latter. [14:40] We should forge ahead, yeah - the new tex-common was only three days away from reaching testing anyway [14:40] cjwatson: It was the kernel breaking that I noticed, but I'm sure there will be many others, as it breaks ghostscript and other oft-build-depped-on bits. [14:41] I think my PPA will give you a headstart [14:41] Hah, if Debian isn't careful, tex-common 3.10 will reach testing without texlive-base >= 2010 ... [14:41] jbicha_: It certainly would. [14:41] jbicha_: Are there any Architecture: any bits in there/ [14:41] ? [14:42] There are, yeah. [14:42] texlive-bin, etc. [14:42] Given the versions are all happy and sane, I'd be tempted to just copy the PPA wholesale, and then sync over it. [14:43] Or, I could just use it to quickly seed a bootstrap chroot. [14:43] Actually, thinking about it, britney ought to notice, so Debian should be OK [14:43] I trust jbicha enough to do that. :P [14:44] Probably better or else non-x86 ain't gonna work [14:45] Hrm, yeah, I should test this all on PPC or something to make sure whatever path I take ends well. [14:51] jbicha_: Should that PPA contain all the bits we need to transition to the New World Order? [14:51] jbicha_: (Using it as a list of what to sync...) === scot-work is now known as scott-work [15:03] Hrm. [15:25] Okay, re-staging jbicha's tex* backports in a de-virt PPA, so I can get all arches built. [15:25] We'll see where that gets me. === jbicha is now known as Guest90485 === Guest90485 is now known as jbicha_ [15:48] doko: Was openjdk/arm being fixed today? [15:59] hi, so a bunch of us discovered that X doesn't load in quantal unless we use libxfont 1.4.4-1 from precise [16:00] infinity, bank holiday ... [16:02] jbicha_: You didn't need X anyway, did you? [16:03] doko: This isn't a bank! [16:21] infinity: well my virtual terminals weren't working either and those *are* useful [16:27] jbicha_: Picky, picky. ;) [16:27] jbicha_: So, has anyone sorted out why libxfont no workie, or just that it sucks? [16:27] of course only fools are running quantal today... [16:28] I've no idea, I don't see a bug report in LP or Debian [16:28] Well, I'll go back to untangling the tex* mess and leave that to desktopish people to care. [16:43] ScottK: my amavisd-new merge pulled in new recommends on altermime and ripole that I didn't notice when merging; do you think these should be MIRed, or demoted to suggests? [16:45] slangasek, infinity did you sort out the busybox issue? [16:45] anyway, afk now [16:46] doko: yeah [16:46] I don't know them well enough to have an opinion on the packages themselves. In general if Alexander Wirt says it should be Recommends, it probably should. In fact, the bug report he was responding to asked for recommends of suggests and he picked recommends. [16:46] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665469 [16:46] Debian bug 665469 in amavisd-new "amavisd-new: should recommend/suggest altermime and ripole" [Normal,Fixed] [16:46] doko: at least, we understand why it broke in Ubuntu but not Debian and what upstream's proposed resolution is; for now I didn't feel like backporting so I just re-disabled nfs support in the static build [16:46] ScottK: ok [19:18] * infinity grumbles about 800MB source packages. [19:18] infinity: gah! what's 800MB? I though we killed ia32-libs :P [19:19] mdeslaur: texlive-extra [19:19] All the tex* stuff is huge. [19:19] wow [19:35] * infinity notes that his PPA says "2.8 GiB (100.00%) of 2.0 GiB" and wonders if he should be concerned by this. [19:36] they reject uploads after 100%, AFIK [19:36] so as long as it stays at 100% he's ok? :) [19:36] you've got one of those newfangled "lossy" PPAs :) [19:37] infinity: I spent all night uploading a tex package to my PPA only to get the reject notice after :( [19:37] so yes I'd be concerned :) [19:37] jbicha_: I intend to dump everytihng from the PPA once I'm done this anyway. :P [19:50] jbicha_: In the process of unmangling this mess, I'm going to upload your 2011.20120410-1ubuntu1~precise1 at 2011.20120410-1ubuntu1 with your name attached to it, if that's cool with you. [19:50] s/at/as/ [19:50] jbicha_: texlive-bin, that is. [19:51] that's fine [19:51] Kay. And re-merging texlive-extra at a higher version, and syncing the rest. [19:51] This should all be sorted in a couple of hours of churn. [19:52] And then we get our first mass-give-back of the cycle. :P [19:58] :) === joshuahoover1 is now known as joshuahoover [21:16] infinity: thanks for sorting that out [21:16] I bet you were bored this week anyway. ;-) [21:18] cjwatson: Heh. === yofel_ is now known as yofel === jbicha_ is now known as jbicha === yofel_ is now known as Guest77193 === SpamapS_ is now known as SpamapS === jbicha is now known as Guest96816 === elmo_ is now known as elmo === cjwatson_ is now known as cjwatson