[00:10] infinity: I seem to remember you saying that some compilers seemed to be generating non-armhf binaries on armhf; were you aware of fpc being in that category? (dozzaqueux build failure) [00:20] cjwatson: Yes, it's a glibc bug I'm trying to hunt down. [00:20] cjwatson: Lazy compilers (like fpc) don't regenerate the eabi ELF headers, but rather trust that crt*.o are correct and blindly link them, and crt*.o are no longer being generated with correct eabi headers. [00:21] There was a massive refactoring of how crt*.o are generated in 2.16, just need to hunt down how that broke. [00:21] (It does affect things built with GGC, as it generates the correct bits itself) [00:23] s/does/doesn't/ [00:32] Right, thanks. === Ursinha-afk is now known as Ursinha [01:09] cjwatson: Tomorrow's a day off for me, so I may do some upstream hunting of said glibc bug, given that I have no grand plans. [01:40] someone's been busy processing SRUs. thanks! [01:47] Just trying to compensate a little for the pile I've been adding for SB [02:32] =) [02:32] * xnox ponders how to make enigmail add hard << thunderbird dependency, such that britney stops thunderbird migrating without a matching/updated enigmail. [02:40] xnox: It used to have one, and it was removed, to be fair. :P [02:40] xnox: But that was a loooong time ago. [02:41] xnox: Back when extensions could stay compatible for years, all the needed was a manifest that wasn't over specific. [02:41] s/the/they/ [02:41] * xnox grumbles [02:42] Anyhow, it's not hard to add it back. [02:42] You'll probably want to talk to Chris or Micah, and make sure it's committed to the right bits for them to not lose it again. [02:43] well there is a new upstream point release... [02:43] Yeah, those shouldn't be breaking compat for extensions anyway... [02:43] Well, didn't use to. :/ [02:44] The New World Order may play more fast and loose with ABI. [02:44] I dunno. [02:49] the diff is big in the point release, it vaguely suggests api changes. [02:51] * xnox goes to have my second sleep [06:40] * infinity glares at erlang-jiffy's continued failure on PPC. [06:55] Grr, and it doesn't fail on my local PPC machine. That's disconcerting. [07:39] Aaand, this is because perl is segfaulting only on ppc64 kernels, which I don't run locally. [07:39] I think it might be bedtime, rather than caring about that. === mmrazik is now known as mmrazik|lunch [10:57] cjwatson: xnox: I could not see raring desktop & server images for today and yesterday. Is it due to any known reasons? [11:01] psivaa: For desktop, I'm not desperately convinced that all the livefs builders are working properly for raring yet - I'm not seeing any logs from other than amd64 or powerpc. I don't know whether that's the root cause though. [11:01] Hm, maybe that's not it [11:01] The logs seem incomplete [11:02] Oh, here, stuck builds [11:02] Looks like celbalrai had a sad [11:02] I'll chase it up [11:02] cjwatson: thanks, out of curiosity is http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/raring/ the place to look for jobs? [11:03] or is there any other place for me to see live logs ? [11:03] livefs-build-logs/raring/ubuntu/ is earlier in the process [11:03] But it's not totally helpful here because of the exact way it all got stuck [11:03] I had to look at the process list on nusakan [11:04] ahh ack, get it. thanks [11:11] cjwatson: do we have any kind of nagios-like monitoring to check the timestamps of the logs & check for hung processes? [11:12] e.g. such that a query "why images are not built on day X" can be answered automatically. [11:12] No [11:12] =/ [11:12] But I would rather make it not hang this way, than entrench the problem by monitoring for it [11:13] ack. [11:13] A single dead builder shouldn't snarl up the whole system [12:03] * ogra-cb_ would still appreciate if someone could let linux-nexus7 out of NEW === mmrazik|lunch is now known as mmrazik [13:48] cjwatson: is it intended to only have /casper/vmlinuz.efi.signed on the desktop cd? and no /casper/vmlinuz ? my non-sb & non-uefi VM fails to boot =) [13:48] That's intended, but the breakage isn't [13:48] ack. [13:48] Let me fix that quickly [13:49] Hmm, there were problems with 8.3 limitations [13:49] Argh [13:50] I'll have to change ubiquity to make this work, I think [13:51] hmm???? the iso doesn't boot, so I don't get ubiquity yet.... [13:51] It's complicated [13:51] Yes I know, but trust me :) [13:51] =)))) [13:52] ok. I'm guessing if "8.3 limitations" and "Argh" are mentioned it's all that ugly.... =)))) [13:55] is this where i'd come to ask whether an SRU actually made it to -updates for precise? (to confirm something) [13:55] or should i be asking elsewhere [13:55] xnox: Basically the answer is probably to call it vmlinuz.efi instead so that isolinux can be told to boot from it, but if I do that then I have to change everything that expects to be working with .efi.signed [13:55] TheLordOfTime: http://people.canonical.com/~ubuntu-archive/pending-sru.html [13:55] TheLordOfTime: Or rmadison [13:56] cjwatson, rmadison works only when you're on an Ubuntu system. I'm not. and its not a pending SRU, its one that i was informed was already complete. [13:56] cjwatson: ack and sigh. [13:56] * TheLordOfTime wants to confirm that [13:56] TheLordOfTime: It works fine on Debian too if you give it the right URL [13:56] TheLordOfTime: And, uh, you apparently miss my point [13:56] cjwatson, again, implies you're on Linux or Debian [13:56] * TheLordOfTime sighs [13:57] whatever, i'll just go check via the code system [13:57] TheLordOfTime: http://pad.lv/u/$pkgname [13:57] TheLordOfTime: If it's in -proposed and not -updates, it'll be listed on that page; if not, it won't [13:57] TheLordOfTime: Or check https://launchpad.net/ubuntu/+source/PACKAGE/+publishinghistory [13:57] TheLordOfTime: and in that url see the publishing history / full changelog. [14:11] hi! we've one bamf cherry-pick in precise SRU queue, and we'd like to get it handled into precise-proposed since we'd already have the next SRU brewing after it... [14:14] * Mirv carefully highlights infinity to point to the above ^ as per vanguard list in wiki [14:15] it's been in the queue for a week, and then it should spend another week at least in proposed [14:43] Mirv: Sorry for the delay. Accepted now. [14:56] thanks! [15:49] xnox: signed kernel> should, I *think*, all be fixed tomorrow [15:50] cjwatson: ack. I will verify ;-) Thank you. [15:50] cjwatson: are you doing this fix for 12.04.2 as well?! [15:51] or not affected? [15:51] Not affected yet, but I probably will backport it. [15:52] Once we know it all works. [15:52] For 12.04.2 we want to ship only the signed kernel on the image, which is what provoked this breakage. [15:52] The precise backport of SB support is only partly complete as yet; I'm waiting on some more SRU queue processing. [16:52] can I copy up brasero from q-updates to r-proposed? [16:53] Sure, if there are no changes from quantal to raring, and if you can get it to not time out (there are some problems in this area at the moment) [17:10] heh, I'm guessing the timeouts are to do with binaries somehow (initially forgot -b and it didn't time out in several runs, but now reliably does with -b) [17:11] Yes [17:24] (self-rejected to replace it with a fix from raring) === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik [20:19] * cjwatson sets up raring milestones as agreed at UDS (I think) [20:20] persia: You have a work item on foundations-r-schedule which is annotated as "must be done within a week of UDS" [20:46] cjwatson: For flavours doing traditional Alpha/Betas (Kubuntu is one), we were hoping to get the traditional milestones too. [20:47] Hm, messy, but OK, let me see [20:50] Thanks. [20:50] ScottK: ddone [20:50] *done [20:50] Excellent. [22:02] * ScottK gives up on trying to run remove-package from an airplane. [22:04] If you try to clean up quantal-proposed, don't remove culmus and gdebi. I got that far before the latency was too high. [23:19] ^ thanks [23:19] NP. [23:52] is britney EOD ? last update 17:17 [23:54] It's crashing. [23:55] =(