[02:20] I don't think the whoopsie failure in the Chinese edition build is a regression, or, if it is, it's a regression due to something subtle like configuration order moving around (which does indeed seem to have happened). I've filed the root cause as bug 978502. [02:20] Launchpad bug 978502 in whoopsie-daisy "whoopsie.postinst crashes silently if /var/crash is missing" [High,New] https://launchpad.net/bugs/978502 [02:20] I'd fix it myself but the branch is set up so that only ev can write to it. [02:21] Good thing the archive is still authoritative? ;) [02:21] I think it's probably not that urgent. [02:23] If it causes more build failures overnight, I'll kick them in the morning. [02:26] doko_: Do you have any suggestions for things to try for bug 941676? I can reproduce it easily enough on davis. [02:26] Launchpad bug 941676 in ppl "ppl ftbfs in precise on powerpc" [Medium,Confirmed] https://launchpad.net/bugs/941676 [02:28] cjwatson: Could it be temporarily worked around with s/-g/-gstabs/ on PPC? That sometimes lowers memory abuse enough to squeak by. [02:28] cjwatson: (Not that that addresses the underlying issue) [02:28] I'll try that. -O0 seems to help too. [02:29] -O1, jury's still out, but it's at well over a gig and rising. [02:30] There are probably multiple problems since in the current failure log on LP the OOM is at link time, not at compile time. [02:31] gstabs could still magically solve al of those. [02:31] But it's a bit disconcerting. [02:31] And odd that it's only on the one package... [02:31] say, bug 978456, qemu-common .deb has been released, but a user is unable to get it through apt-get update of qemu-kvm? [02:31] Launchpad bug 978456 in qemu-kvm "Unavailable dependency for qemu-kvm 1.0+noroms-0ubuntu12 " [Undecided,Incomplete] https://launchpad.net/bugs/978456 [02:33] The error he's seeing from apt would be nice. [02:34] hm, it does show ' [02:34] E: Unable to correct problems, you have held broken packages.' [02:34] Oh, I didn't even see that in the original. [02:35] yeah i glossed over it the first time [02:35] is there a way to get the list of broken packages? [02:36] If he actually has something held, "dpkg -l | grep ^h" will show it, but apt overloads that word, and it can just mean that something's being held back due to resolver issues. [02:37] I can confirm, however, that the archive is fine (his mirror might not be). [02:37] But my local mirror finds the latest _all.deb just dandily, and lets me install qemu. [02:37] ditto [02:37] ok i'll just point out that line to him - thanks [02:37] Anyhow, he didn't give policy output for the arch all package, only the arch any. [02:38] Would be a good place to start. [02:38] I'm fairly sure it's just transient mirror lag. [02:40] what do you mean by policy output for the arch all package? [02:40] He showed the output of "apt-cache policy qemu-kvm", but not "apt-cache policy qemu-common". [02:40] qemu-common? [02:41] ok [02:41] thanks [02:41] amd64 and i386 were published 4 (four!) hours apart, I'm positive it was archive/mirror skew. [02:42] You can probably just copy and paste my above line and close the bug. :P [02:43] infinity: :) that'd be fun, but i'd just replied. hopefully he'll close it out in the morning. [02:52] cjwatson: Oh, I was thinking of adding a supported-upgrades seed to platform.*, that would carry transitional packages that match the criteria of "used to be in main in the last LTS" and "still depend on things in main now". [02:52] cjwatson: Start said file blank on each post-LTS release, and let it collect cruft between LTS and LTS. [02:53] cjwatson: (Things like the openoffice.org transitional packages belong there until Q, for instance, but I'm sure there are dozens more) [02:53] infinity: i thought they were caught at opportunities when merging "Keep until Foo release". [02:54] Daviey: Things get demoted all the time, though I appreciate the theory. :P [02:54] Daviey: But the upshot of having it in its own seed it also that the cruft is easily found post-LTS-release. [02:54] Instead of having it sprinkled all over. [02:55] Empty seed, watch component-mismatches list 150 binaries, profit. [02:56] Where are the question-marks? [02:56] astraljava: *blink* [02:57] http://knowyourmeme.com/memes/profit [02:57] See, "where are the underpants" would have made more sense. [02:57] Yeah but I know where they are. Lots of 'em. [03:02] infinity: makes some kind of sense, yeah. They're scattered all over the place right now. [03:20] i just uploaded tgt, would appredciate a review. i believe everything is fairly straight foreward [03:20] http://paste.ubuntu.com/924272/ [03:26] smoser: Accepted. [03:34] pitti: why was libreoffice not uploaded to -proposed? [03:35] pitti: precise-proposed I mean :) [03:36] would avoid questions like bug 978499 [03:36] Launchpad bug 978499 in libreoffice "AMD64 build of libreoffice 3.5.2-2ubuntu1 missing libreoffice-common" [Undecided,Invalid] https://launchpad.net/bugs/978499 [03:39] micahg: But libreoffice builds so quickly, what are the chances of a skew of more than one cyc... Oh. [03:40] infinity: ;) [03:45] * micahg thinks he should start using -proposed for chromium [03:46] Does chromium have any/all skew? [03:46] infinity: yes, the l10n package [03:46] Recommends: chromium-browser-l10n [03:46] It's not versioned. [03:47] Oh, it is in the other direction. [03:47] right :) [03:47] Then yeah, probably should. [03:48] infinity: k, uploaded lbm and linux-meta. If I could get you to approve them in the queue that would be much appreciated :) [03:48] Except that it also depends on half the world (as does libreoffice), so you really have to watch what else is in proposed. [03:48] At least, until we get something britney-like going. [03:49] infinity: they're only ABI bumps and nothing else [03:49] ogasawara: I dunno. Can I trust you? [03:49] infinity: probably not, but I'll buy you a beer [03:49] ogasawara: Sold. [03:49] infinity: yes, but I think everything it uses has proper symbols files, so it should be irrelevant [03:49] hehe [03:50] micahg: Eh? [03:50] well, almost everything [03:50] micahg: How do "proper symbols files" relate? [03:50] infinity: properly versioned dependencies [03:50] micahg: If you build against libfooX 1.3 with symbols and shlibs that demand >= 1.3, and only 1.2 is in q-release, when we copy your package, boom. [03:50] micahg: That's the danger without britney. [03:51] micahg: The archive currently has no method except human intervention to prevent that sort of oops. [03:51] infinity: yes, sorry, I forgot the second part, most of the depends are from lucid :) [03:51] micahg: Nothing's changed in your dependencies' shlibs since lucid? [03:51] but yes, library transitions would affect it [03:51] (I don't believe you) [03:52] This isn't about transitions, but minor ABI additions. [03:52] One added symbol to a library in proposed that we reject, and everything build against it is garbage. [03:52] s/build/built/ [03:52] well, in that case, versioned depends are wrong anyways [03:53] No.. Versioned deps are right. [03:53] But soyuz makes no attempt to check them. [03:53] Pocket copies have no safety net. [03:53] We just take bits from A, and shove them in B. [03:54] no, I mean if ABI additions break the binaries, they should depend on that version :) [03:54] ... [03:54] *unused ABI additions [03:54] They would. [03:54] Ergo, uninstallable packages. [04:18] What's the actual date when the first release candidates are built? I acknowledge that it might still change, but the planned one at this time? [04:21] astraljava, 19th is when release candidate window starts. we get the last translations earlier that week. [04:22] skaet: Ok, I somehow had an earlier date in mind, then looked at the release schedule, and was puzzled. Thanks for confirming! [04:24] astraljava, ideally we'd like any image after the 12th to potentially be releasable, but we'll be picking up those last sets of translation. [04:24] skaet: Understood. I'm asking because I'm writing to our mailing lists for assistance in ISO testing, so some hard facts won't hurt. :) Thanks for the info! [05:11] ^ the plymouth one includes a couple of useful fixes === doko_ is now known as doko [06:14] micahg: libo> we absolutely should have sent it to -proposed indeed; failure on the human end, I'm afraid :/ === rsalveti` is now known as rsalveti [08:26] do bugfix releases need to go through here first before uploading? [08:27] no [08:28] just upload, it'll show up in the queue and someone from -release will look at the diff [08:28] ok, thanks [08:28] right [08:30] flushing precise-proposed into precise now [08:34] I haven't copied linux-lowlatency yet, since linux-meta-lowlatency still needs to come [08:51] pitti, please have a look at the openjdk-6 upload [09:03] accepted whoopsie-daisy [09:06] i uploaded sssd 1.8.2 bugfix release to the queue [09:06] it should be moved to main for precise, dunno why that hasn't been done yet [09:06] the MIR is bug 903752 [09:06] Launchpad bug 903752 in tevent "[MIR] sssd" [Undecided,Confirmed] https://launchpad.net/bugs/903752 [09:07] I'll add the apparmor profile in another upload, shouldn't be too hard to create [09:12] * cjwatson scores up git to get autopoint (hence world) installable again on armel and powerpc [10:42] * pitti reviews some more packages; but I can't do gvfs, as I uploaded that myself [10:43] * Riddell looks at gvfs [10:44] pitti: gvfs looks good [10:45] doko: currently reviewing openjdk-6; new fonts-ipafont-mincho build dep is in universe [10:46] doko: dropping debian/patches/6897553.patch is intended? the changelog doesn't mention it [10:46] and gcc-lto.diff [10:46] stgraber, Riddell: thanks [10:46] stgraber: I got there first! [10:47] Riddell: hehe :) [10:48] ooh our poor buildds [11:01] pitti: yes, 6897553.patch is included upstream, gcc-lto.diff was just an experimental patch, I'll write a MIR for the fonts package, should be harmless [11:01] doko: ack [11:06] pitti: now bug 978813 [11:06] Launchpad bug 978813 in fonts-ipafont "[MIR] fonts-ipafont used by the OpenJDK fontconfig" [Undecided,New] https://launchpad.net/bugs/978813 [11:14] respinning Ubuntu desktop (x86), preinstalled Wubi images, Edubuntu DVD, and Lubuntu desktop, to deal with whoopsie-induced build failures [11:32] tjaalton: re sshd and main> it needs to be seeded somewhere, then it'll show up on a list of things for an archive admin to fix [11:32] tjaalton: s/sshd/sssd/ [11:34] jdstrand: oh [11:35] seeded or depended upon [11:35] * jdstrand nods [11:36] or recommended. [11:36] options, options.. :) [11:42] so I guess sssd should go in the 'supported' seed [11:43] oh it's split.. [12:00] looks like the structure has changed a lot since intrepid, which is what the wikipage shows [12:10] Is it too late to upload gnutls26 and puppet security updates? [13:21] wgrant: Is there something wrong with diff generation? strigi was uploaded an hour ago, but still doesn't have a diff. [13:24] * ogra_ hugs the approver [14:15] the samba4 package in debian has been updated for a security bug fix, but the upload contains two other bugfixes as well [14:15] is there any chance I can just sync that, or should I prepare a new upload that just includes the security fix? [14:16] jelmer: bug fixes are good to have [14:19] Riddell: even if they're not strictly critical? [14:22] * cjwatson wonders if he's nearing the end of the installer translation sync yet [14:37] jelmer: I'm afraid I'm behind on the release team e-mails so I'm not sure exactly what is being accepted but I don't think it's critical only yet [14:39] Riddell: I'll check - thanks! [15:14] Looks like we need to do a quick sword transition due to a missed ABI break. Only three rdepends. Can someone due the binary new after I do the sync? [15:15] I'm still doing a test rebuild, just to make sure. [15:15] (only three packages) [15:17] yes [15:20] OK. Thanks. [15:21] liferea upload restores indicator support broken by late liferea precise upload ^ [15:24] mdeslaur: right, I remember seeing that bug, I'll take a look once the diff has been generated by LP [15:26] right, looks sane [15:27] can an archive-admin let liferea through please? [15:27] I wonder why LP doesn't generate a strigi diff [15:27] cjwatson, https://bugs.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/977568 [15:27] Launchpad bug 977568 in xubuntu-meta "Xubuntu nightly ISOs are missing the PAE kernel" [Undecided,New] [15:30] knome: 10mins [15:30] cjwatson, np, i'm afk too -> [15:30] stgraber: done [15:31] pitti: thanks [15:31] cjwatson: i18n day :) [15:31] pitti, the ipa-fonts package is now promoted [15:32] doko: ack [15:38] pitti: yeah, non-langpack freeze tomorrow [15:39] as is final freeze.... [16:00] cjwatson: The sword sync is accepted. Due to the huge armel and powerpc backlog, it might be worth rescoring it to get it built soon. I've also uploaded the reverse-build-depends with a versioned build-dep on libsword-dev so they can be accepted anytime without fear of misbuild. [16:11] ScottK: I see somebody's rescored them already [16:11] Ah. Excellent. [16:12] slangasek, oh, i finally found the pvr driver binaries, seems the source went to restricted but the binaries are in universe [16:13] http://ports.ubuntu.com/pool/universe/p/pvr-omap4/ ... [16:13] intrestingly they dont seem to be in any Packages file [16:15] I think I'm finished with installer translation updates now [16:16] except for maybe another one to ubiquity [16:16] cjwatson: will the powerpc builds be in the 'extra' push daily iso builds tomorrow? [16:16] I don't know what you mean by extra push, but daily builds take whatever's in the archive at the time [16:17] cjwatson: I was told earlier that it was planned to do a suite of regression checks from tomorrows isos? [16:17] ogra_: I disagree with the "not in any packages files"... [16:17] pvr-omap4 | 1.7.10.0.1.21-0ubuntu1 | precise/restricted | source [16:17] pvr-omap4 | 1.7.10.0.1.21-0ubuntu1 | precise/universe | armhf [16:17] pvr-omap4-dbg | 1.7.10.0.1.21-0ubuntu1 | precise/universe | armhf [16:17] pvr-omap4-dev | 1.7.10.0.1.21-0ubuntu1 | precise/universe | armhf [16:17] well, daily builds take whatever's in the archive at the time [16:18] cjwatson: okies, thanks [16:18] infinity, well, apt-cache search doesnt find it here on a brandnew armhf chroot [16:18] root@localhost:/root/compiz-0.9.7.6# apt-cache madison pvr-omap4 [16:18] N: Unable to locate package pvr-omap4 [16:19] ogra_: A fresh chroot that doesn't have universe? :P [16:19] GAH ! [16:19] it has multiverse and restricted in the sources.list though :P [16:22] ah, now my madison agrees with yours [16:22] ^ that glib upload a gdbus patch which is non "trivial" but comes from upstream git and fix a bug which can be seen as a security issue (a bit borderline, it's allows at least to disconnect dbus client by sending some messages on the bus) [16:22] i.e would be good to have it in precise [16:22] ogra_: rmadison is your friend. [16:23] i know ... but she doesnt like me if i dont feed her the right config :P [16:23] I've used proposed to avoid issues like bug #978124 [16:23] Launchpad bug 978124 in glib2.0 "upgrading to 12.04 beta2 not completed due to problem with packet skype:386" [Undecided,Invalid] https://launchpad.net/bugs/978124 === chrisccoulson is now known as sebI28 === sebI28 is now known as chrisccoulson [16:28] php5 in 'core' just feels wrong (not questioning it, my reaction). === bladernr_ is now known as bladernr_afk [16:36] ogra_: right, I changed the override for the binaries, so that should take effect soon-ish [16:36] slangasek, thx [16:38] Rejected my xiphos upload because we'll probably sync the newer one from Debian instead. [16:48] cjwatson: All the sword binaries are done now. [16:48] yep, was just looking [16:49] will punt the rdeps through later [16:49] have to go out now [16:49] (or you can punt them through whenever) [16:51] I'll take care of them. Thanks. [16:57] ^^^ was me. [17:28] * ScottK did calligra [17:28] (I did the others) [17:37] infinity, was wanting to talk about the openjdk-6 before it got approved (it was on the pad) [17:37] skaet: Oh, erk. Didn't check the pad. [17:37] (Am I the only one who finds looking in yet another place before checking the queue to be cumbersome?) [17:38] no; but it is the agreed procedure, there needs to be some way to coordinate [17:39] slangasek: Not claiming I'm above the law here, just that I forgot to look. :P [17:42] * skaet would like a way to signal a block for discussion on a package, right on the queue itself ideally, but we don't have that capability, let alone logging. :P [17:42] infinity: then "no" :) [17:44] skaet: We can reject. [17:44] skaet: It's not ideal, as it sends a grumpy email, but... It takes things out of the queue. [17:45] skaet: And the grumpy email would have led doko to come argue his case. ;) [17:46] infinity, not sure that's the right semantics, though. [17:46] ? [17:46] and we still need a way of signaling that discussion is needed before somethings go through. [17:46] (See? He pops up like a groundhog when you mention him) [17:46] :) [17:53] ScottK: hmm no strigi in unapproved [17:53] Riddell: Odd. I see it on https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text= [17:54] oh typo [17:56] * infinity giggles at dirspec's "diff". [17:56] More RC->release progressions should be like that (just bumping the version number). [17:56] skaet: so what was the question regarding openjdk, since it's no longer shown on the pad? [17:56] (better to have that discussion now than not at all) [17:58] slangasek, its in the history, but basically neither of the bugs associated with it seemed critical, and there seemed to be a lot of changes that I'm not sure we really need. [17:58] at this late state [17:58] I have yet to find this history button on the etherpad [17:58] http://pad.ubuntu.com/ep/pad/view/ubuntu-frozen-archive/latest [17:58] The bugs-must-be-RC thing doesn't come into effect until (checks) tomorrow. [17:59] Perhaps that's part of why I didn't think to coordinate my review with the pad and others. [17:59] skaet: thanks [17:59] infinity, yes, but swallowing a system change like openjdk this late before final freeze is risky for regression potential [18:00] skaet: fwiw, I think the "also, should be -proposed" should be grounds for immediate reject, since it requires a reupload no matter what [18:02] slangasek, fair enough, I'll be more vigorous on the REJECT for those ones. We still need an effective way of communicating "hold it" for discussion. [18:02] yes, I agree [18:02] I'll watch the pad more carefully. [18:02] but I'm afraid it's not realistic to expect it to be 100% effective [18:03] so we should take other precautions as well IMHO :) [18:03] But I do still think that if you think it shouldn't be accepted, the answer is rejecting. [18:03] We can always fish it out of rejected and accept it if further discussion proves the rejecter was wrong. [18:04] * ScottK is looking at calligra again. [18:04] ... if the diff ever shows up. [18:04] I think the appservers are on holidays. I've been diffing the old skool way. [18:05] slangasek, feel free to elaborate on the other precautions... ;) [18:05] infinity: If you want a break for a lol: https://bugs.php.net/bug.php?id=54547 [18:05] skaet: just the above - be liberal in what we reject :) [18:07] ScottK: That's just a side-effect of loose typing. [18:08] Charles Manson was also a side effect of insanity. [18:08] ScottK: (funny, sure, but I chalk bugs like that up to users not understanding) [18:08] Isn't the point of php not to have to understand? [18:09] Maybe. [18:09] Outsource all your security issues to upstream. [18:09] the checking for INT_MAX overflow with a float was winnar though [18:09] why do we have php in main, again? [18:09] slangasek, partman-auto has me a bit worried, given all the things that are being pulled in. Who's reviewing it? [18:10] slangasek: Yes, *that* one's special. [18:10] skaet: well, let me have a look [18:10] I can look. [18:11] infinity: also, I think in PHP's case that's better described as promiscuous typing [18:11] Looks mostly like translations, and arches/subarches we don't ship. [18:11] Adjust default partition sizes for Ubuntu. [18:12] skaet: that's the documentation of the remaining changes relative to Debian, not a list of things changed in this version [18:13] though, it does appear we're pulling in some changes to default sizes from upstream [18:14] We are, yes. [18:14] cjwatson, infinity: this partman-auto upstream pull introduces some changes to recipes for armhf, and some changes to minimum sizes for various recipes; how tested are these? [18:15] + * Bump minimum root partition size to 900MiB in the home [18:15] + recipe. [18:15] + This will allow installing the standard task and leave room for [18:15] + and extra kernel package in later life of the machine [18:15] + Closes: #528914 [18:15] + * Adapt minimum sizes for /var and / in the multi recipe: [18:15] We had no partman-auto recipes for armhf before, so I'm not sure adding them hurts. :P [18:15] + /var must cope with about 150MiB downloads and has 125MiB data [18:15] + for the standard task install [18:15] + / has about 150MiB installed and should cope with an [18:15] + extra kernel at least [18:15] + * Adapt minimum size for / in the atomic recipe, to 900MiB [18:15] + Same rationale than above. [18:15] infinity: isn't there an arch-indep fallback? [18:16] i.e., I'm not sure adding them *doesn't* hurt, which is the relevant criterion at the moment :) [18:16] Oh, perhaps. [18:16] GrueMaster: Opinion? You're probably one of the 2 people that uses partman-auto on armhf. [18:17] Not since pre-Beta 2. [18:17] slangasek: The default minimums for the generic cases don't sound like a big deal to me, but it is perhaps a bit late. [18:17] so the above changelog (from version 94) gives the rationale for the bumps to the minimum sizes... the rationale is sound, and it's unlikely that Ubuntu's requirements are smaller than Debian's, but I'd like cjwatson's thoughts [18:19] infinity: mahmoh and pgraner would be the people to talk about partman-auto on arm. [18:22] skaet: BTW, speaking of scary last-minute uploads that will make you hate me, there's a very real possibility that I may have to upload every compiler in the archive over the weekend. [18:22] skaet: When you've recovered from the heart attack that last line induced, we can chat about it. ;) [18:25] infinity - please give me the why's please... [18:25] infinity, skaet: honestly not needed. can be done post-release as well [18:25] doko: Ugh. Please no. [18:26] skaet: bikeshedding about the ELF linker path to be used in the armhf port [18:26] (upstream bikeshedding) [18:26] doko: For two reasons. A) it requires a manual bootstrap, and B) it means people might build third-party binaries with our released compiler that produce incorrect headers. [18:26] will it require the kernels be updated as well? [18:26] no [18:27] infinity, why a manual bootstrap? [18:27] and if the kernel team tries to argue otherwise, tell them no ;) [18:27] doko: Moving the PI needs a glibc/gcc bootstrap loop to fix. [18:27] Turns out I've done this a few times in the last year. [18:27] slangasek: I've just had that argument with apw in private. ;) [18:28] (It's not exactly a difficult bootstrap, but it's not just "change the source and upload" either) [18:28] still don't see why this needs to be a manual bootstrap. get a symlink into libc6, then build gcc. [18:29] Then glibc. [18:29] So, two glibc uploads. [18:29] Which is a bootstrap. Or, you can do it properly as a bootstrap, and then upload once. [18:30] well, put it into a low cost package like gcc-defaults first, or base files, then you'll have only one glibc upload [18:30] *sigh* [18:30] Like I said, it's not a complicated bootstrap, but it's a bootstrap. [18:30] It involves doing non-standard things to get from A to B. [18:30] Either way. [18:31] If we can avoid it, I don't want to ship a compiler that produces "incorrect" binaries. [18:31] however, the preferred approach is still to get upstream to agree with us about correctness :P [18:31] instead of letting obstinate bikeshedding prevail [18:31] Yeah, but I don't see it happening, following the thread. [18:31] How large is the change? anything else being dragged in? [18:32] People seem much fonder of /lib/ld-uniqueid.so.3 [18:32] skaet: No, that's it. [18:32] skaet: It's 1-line, if I just change that path, a bit more if I pull in upstream's revised linker patch (which can wait until Q, if it makes people nervous). [18:33] (By "a bit more", I mean "5 or 6 lines") [18:33] Tiny either way, and only ARM. [18:34] infinity, is there any reason tehy won't just chose another random name after you change it? [18:34] infinity, if its only arm and 1 line, why can't we do it now before final freeze, and do a zero change rebuild of the kenrel. [18:34] apw: the theory is that the outcome of this call is an upstream commit [18:35] so if they change it again locally, we just accuse them of contributing upstream [18:35] skaet: because we don't *know* what the one line will be [18:35] this is a standardization question [18:35] not a technical-bugfix question [18:36] slangasek, understood. thanks. [18:38] infinity, wait until it's decided ... [18:39] doko: I thought that bit was obvious. [18:42] Is there any way the unity-team/staging PPA could be taught not to build for powerpc. I'm reasonably certain they don't care about the arch and builds from that PPA are regularly blocking archive builds. [18:43] no; it's part and parcel of having a non-virtualized PPA [18:48] infinity, would want to know more about the contents of the revised linker patch. Default should be for Q for that one, unless someone comes up with compelling reason why we can't live with what we have for now. Possibly consider as part of a 12.04.1 plans. [18:49] skaet: Nah, what we have is fine, it just misses some weird corner cases. [18:49] infinity, would it be possible to time the compiler change to go in as part of week 1 upload and synch up to the kernel changes going in then? [18:49] well, it means 12.04 is not binary-compatible with other distributions, or with 12.10 [18:49] (Not changing patches also means it's literally a 1-line fix to every compiler in the archive, which is much easier to swallow) [18:49] oh, or if you just mean the bigger upstream fix, yeah [18:50] Yeah, sorry, I just meant the larger patch. [18:50] skaet: I really don't want our release compiler to produce incompatible binaries with the world. [18:50] skaet: If we have to, we have to, depending on how things work out time-wise. [18:51] ohh, then I'll have another fix for an ICE too [18:51] skaet: But I'll also point out here that if a no-change rebuild of a compiler is too scary 1.5 weeks before release, then we can't really ever update it post-release, where it will get way less testing. :P [18:51] doko: Trying to slide patches in with this won't help. ;) [18:55] infinity, if its just a rebuild of the compiler with that one line change, concern level drops a bit. Just don't like releasing with a kernel that isn't matching our compiler (although I understand it shouldn't matter in theory). [18:56] we really should stop hedging about this kernel sync non-problem [18:56] if making this change has any impact on the kernel, that's a serious kernel bug [18:57] Or a serious toolchain bug. [18:57] and would cause problems after release as well [18:57] Either way, the bug doesn't exist. [18:59] slangasek: there's a flag on the PPAs that can be set to stop them from building on powerpc if the unity team doesn't need it [18:59] micahg: really? [18:59] slangasek: yes [18:59] is that new? [18:59] Yeah. [18:59] infinity, so we're waiting on an discussion in progress right now or something else? If it doesn't resolve this weekend, what's the fall back? [18:59] mmk [19:00] skaet: The fall back is "do nothing". [19:00] micahg: who has access to set that bit? [19:00] right, but apparently the unity team did opt in to build on powerpc [19:00] slangasek: webops [19:00] ah [19:00] skaet: (And fix it in updates, and suck up the fact that we shipped a broken compiler) [19:00] ScottK: ^^ so the unity team think they want powerpc, I guess you'd have to argue the case to the ppa owner [19:00] skaet: But lots of us have a vested interest in this being solved on Friday. [19:00] * skaet nods [19:04] * infinity is tempted to build a gcc/glibc pair for every linker path that's been so far proposed, and just upload the right one after the meeting on Friday. [19:05] Alternately, I could not think about it until Friday, and go do other useful things. [19:05] Which sounds less stressful. [19:07] dobey, can you give some background on that nice big set of ubuntuone-* packages that have just landed in the unapproved -release queue? [19:08] skaet: If they're like the one I approved earlier, they're just version bumps to a final and pretty release number. [19:09] skaet: final release of ubuntuone projects to align with ubuntu final freeze [19:09] infinity: some of them have a few changes [19:09] * infinity is reviewing. [19:09] dobey: Yeah, I'm accepting the ones without changes first, and reviewing the rest. ;) [19:10] infinity: makes sense. i uploaded the ones without changes first :) [19:11] and now, only 2 more to get uploaded [19:11] skaet: I've been informed that ppisati has a fix for bug 963512? Was curious if a ti-omap4 upload would be approved at this point in time? [19:11] Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed] https://launchpad.net/bugs/963512 [19:11] skaet: just want to set his expectations for how to proceed... [19:12] dobey / skaet: Kay, change-free u1 uploads accepted, will review the rest shortly when the appservers catch up with diff requests. [19:12] it's a kernel package that exists solely to support omap4; if video doesn't work on it, I'd say that's rather important to fix [19:12] ogasawara, skaet: ^^ [19:12] slangasek: current workaround was just to back out the changes which broke it, but he's got a proper fix now [19:12] ogasawara, queue it up. If there's a quiet window, we'll pick it up. [19:12] skaet: I assume, he should upload to -proposed [19:12] skaet: ? [19:13] ogasawara: so the kernel currently in precise is not broken? [19:13] ogasawara, yes, definitely to -proposed [19:13]