| * slangasek afks for a bit | 00:07 | |
| * skaet takes dog for walk, back in about 30 min.... | 00:14 | |
| skaet | ubuntu desktop, alternate 20111007 posted | 01:03 |
|---|---|---|
| skaet | kubuntu alternate 20111007 posted | 01:03 |
| skaet | ScottK, ^ (desktop should be available soon) | 01:04 |
| ScottK | OK. | 01:04 |
| skaet | xubuntu alternate 20111007 posted | 01:04 |
| skaet | wubi posted | 01:04 |
| infinity | skaet: eglibc on ARM is publishing right now, should be able to spin preinstalled images in 30-45mins. | 01:13 |
| skaet | infinity, good to hear. :) looks like we should have most of them available for europe then, when they wake up. :) | 01:14 |
| infinity | Here's hoping. | 01:14 |
| * skaet crosses fingers | 01:14 | |
| * infinity is tempted to make another livecd-rootfs change before building ARM images.. | 01:23 | |
| infinity | skaet: Would you be grumpy if I delayed ARM by another publisher cycle? :P | 01:27 |
| infinity | skaet: Just need one livecd-rootfs upload to get some unwanted cruft off our packages. | 01:29 |
| skaet | infinity, I'll defer to you for the ARM ones. You'll be the one staying up late for them ;) | 01:30 |
| infinity | I'm okay with that. :P | 01:31 |
| infinity | Upload in the queue in ~2 minutes, then. | 01:33 |
| infinity | If someone can get it reviewed/accepted before :40 or :45, should be good to go. :) | 01:33 |
| infinity | (3 line diff) | 01:33 |
| slangasek | infinity: mind the contents generation | 01:34 |
| slangasek | (next hour is Dead Time for the publisher, unless you stab cron) | 01:34 |
| infinity | slangasek: Hrm? | 01:34 |
| infinity | Oh, feh. Is it that time of day? | 01:34 |
| slangasek | and the hour after that, since contents generation traditionally takes 2h :P | 01:34 |
| infinity | Actually. I'm going to reject. | 01:34 |
| infinity | On the basis of wanting to fix a typo in the changelog to look less stupid. | 01:35 |
| slangasek | wait, no, apparently I'm timeshifted | 01:35 |
| slangasek | or can't read big-endian cron syntax | 01:35 |
| slangasek | so you actually have 2 hours :) | 01:35 |
| infinity | \o/ | 01:36 |
| infinity | Perfect. | 01:36 |
| infinity | slangasek: Review for me at :40 when it lands (again) | 01:36 |
| infinity | (please) | 01:37 |
| * infinity wonders how this diff generation business can take this long. | 01:42 | |
| * skaet notes its like a watching a pot of water boil, always takes longer when you're watching ;) | 01:42 | |
| infinity | skaet: That depends on how warm your face is. | 01:43 |
| skaet | lol | 01:43 |
| infinity | I think the queue diffy thingee has given up the will to live. | 01:48 |
| infinity | http://paste.ubuntu.com/703708/ <-- The diff. | 01:49 |
| infinity | Hahaha. | 01:49 |
| infinity | And it lands in the queue right after I paste it. | 01:49 |
| infinity | Whatever. | 01:49 |
| infinity | slangasek: Review teh queue for me, silver plates. | 01:49 |
| skaet | ScottK, kubuntu desktop 20111007 landed | 01:56 |
| infinity | skaet, ScottK: Or you? :) | 01:57 |
| * ScottK looks again. | 01:58 | |
| ScottK | infinity: Accepted. | 01:59 |
| infinity | Danke. | 01:59 |
| * infinity puts the publisher on manual, since he's going to miss it by 2 or 3 minutes. | 01:59 | |
| skaet | lubuntu 20111007 posted | 02:01 |
| skaet | ubuntu-studio 20111007 posted | 02:01 |
| infinity | Or maybe I won't. | 02:01 |
| slangasek | infinity: sorry, was @dinner | 02:08 |
| infinity | slangasek: S'all good. | 02:09 |
| skaet | mythbuntu 20111007 | 02:11 |
| skaet | posted. ;) | 02:11 |
| skaet | xubuntu desktop 20111007 posted | 02:12 |
| infinity | skaet: Alright. preinstalled should be good to go. You want to add it to your queue, or have me do them? | 02:37 |
| skaet | infinity, please add it to your queue, I'll be calling it a night in about an hour. | 02:37 |
| infinity | Mmkay. | 02:38 |
| infinity | I will be too. :P | 02:38 |
| infinity | I'll just leave the builds running in a screen session, though. | 02:38 |
| skaet | post the order on the pad, and ask jibel or pitti to post when they get up. | 02:38 |
| infinity | I'll just use pitti's loop of doom. | 02:39 |
| infinity | Or, will, if the pad responds. | 02:39 |
| skaet | kubuntu mobile won't be needed, double check for that. | 02:39 |
| skaet | http://pad.ubuntu.com/ubuntu-release | 02:40 |
| skaet | ubuntu-uk pad goes wonky for me about this time of night, so I moved it. | 02:41 |
| infinity | Yeah, I saw the forward. | 02:41 |
| infinity | And loop started. | 02:42 |
| skaet | its in the release channel title now too. But I was using old links myself earlier. | 02:42 |
| infinity | With no kubuntu-mobile. | 02:42 |
| skaet | :) | 02:42 |
| infinity | I could go for a case of Penfold's Grange right now. | 02:44 |
| infinity | Maybe we should dig up a bottle or three for next Thursday. | 02:44 |
| skaet | +1 | 02:46 |
| skaet | mmmm.... Grange. | 02:46 |
| skaet | infinity, looks like ubuntu-server nova 2011.3-0ubuntu6 produced an uninstallable binary for i386, amd64. worth posting? | 03:07 |
| skaet | or not. | 03:07 |
| infinity | Hrm? | 03:07 |
| skaet | report.html for it. | 03:07 |
| infinity | nova-compute-xen | 03:07 |
| skaet | yup | 03:07 |
| infinity | Well done, server team. | 03:07 |
| infinity | That's not on the CD though. | 03:08 |
| infinity | Or is it? | 03:08 |
| infinity | Ugh, it is now. | 03:08 |
| infinity | Yeah, they've screwed up and need promotions. | 03:08 |
| skaet | is the image worth testing for other issues, or does that need to get sorted first/ | 03:09 |
| skaet | ? | 03:09 |
| infinity | Nah, it's still worth publishing to test. | 03:10 |
| infinity | Just means that one metapackage is worthless. | 03:10 |
| infinity | E: Package 'xen-linux-system' has no installation candidate | 03:10 |
| infinity | Go team! | 03:10 |
| infinity | Daviey: nova-compute-xen : Depends: xen-linux-system but it is not installable | 03:10 |
| infinity | Daviey: You might want to look into that. :P | 03:11 |
| skaet | thanks. just about to do the same. ;) | 03:11 |
| slangasek | skaet: what's the timeline from here to images that are candidates for release? | 03:11 |
| infinity | slangasek: We'll find no bugs and the only difference between these and release will be base-file, apport, and kerneloops. | 03:12 |
| infinity | base-files* | 03:12 |
| slangasek | skaet: wondering about landing a udev workaround for bug #818177 to make the server team happy, and maybe a libpciaccess fix for bug #864123 to make the desktop team happy | 03:12 |
| ubot4 | Launchpad bug 818177 in udev (Ubuntu Precise) (and 6 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 9) (heat: 68)" [High,Triaged] https://launchpad.net/bugs/818177 | 03:12 |
| ubot4 | Launchpad bug 864123 in libpciaccess (Ubuntu) "libpciaccess0:386 is uninstallable on amd64 (affects: 4) (heat: 20)" [Undecided,Confirmed] https://launchpad.net/bugs/864123 | 03:12 |
| skaet | slangasek, testing tomorrow, pitti kicks off the candidates on sunday night. we should have the candidate images on monday. | 03:12 |
| slangasek | (this is the udev bug that was discussed with Daviey earlier today; I'm ok with being told no) | 03:13 |
| infinity | slangasek: What are the odds of the workaround causing more problems than it fixes? | 03:14 |
| skaet | slangasek, pondering.... | 03:14 |
| infinity | slangasek: Cause, post-Monday, we pretty much have to live with anything that isn't a showstopper... | 03:14 |
| ScottK | Sigh. I missed a small problem with the postfix package I accepted two days ago. | 03:14 |
| ScottK | Missing debian/copyright. | 03:15 |
| slangasek | infinity: the workaround is "kill it harder in the initramfs" | 03:15 |
| ScottK | I think we'll need to fix that. | 03:15 |
| infinity | ScottK: ... | 03:15 |
| infinity | ScottK: Yes. | 03:15 |
| slangasek | infinity: so, ah, approximately no risk of making it worse | 03:15 |
| skaet | ScottK, ack. | 03:15 |
| infinity | slangasek: And it was already being killed? Just a larger knife and a gun now? | 03:15 |
| infinity | slangasek: That seems reasonable to me. | 03:15 |
| slangasek | yes | 03:15 |
| slangasek | udevadm control --exit ; pkill udevd | 03:15 |
| slangasek | so using both the new and the old methods to make sure it dies | 03:15 |
| slangasek | both are racy | 03:15 |
| infinity | But differently racy! | 03:16 |
| slangasek | yes | 03:16 |
| infinity | Which is what you're counting on? :) | 03:16 |
| slangasek | so by combining the two, we've turned the race into a gauntlet | 03:16 |
| slangasek | yes, exactly | 03:16 |
| infinity | Seems fair to me. | 03:16 |
| infinity | And very low risk. | 03:16 |
| infinity | We have to rebuild once or twice anyway, and this doesn't change the viability of current images. | 03:16 |
| infinity | (ie: we don't need to respin RIGHT NOW if you upload it) | 03:16 |
| infinity | So, +1 from me. | 03:17 |
| skaet | slangasek, what are the chances of side effects? | 03:17 |
| infinity | skaet: The only real side effect of this is it working slightly better. Or just as badly as always. | 03:17 |
| skaet | infinity for the udev one I assume you're talking about. or both? | 03:18 |
| infinity | skaet: The udev one. | 03:18 |
| infinity | slangasek: libpciaccess is multiarching it? :/ | 03:18 |
| infinity | slangasek: (Though for a good cause, it would seem) | 03:18 |
| slangasek | infinity: correct; it's multiarched in Debian already and I'm prodding people about testing the revdeps if they want to have a shot at it | 03:19 |
| infinity | Yeah. That one's a bit shakier (though I like the proposed outcome) | 03:19 |
| infinity | But I'm all for the udev thing. | 03:19 |
| infinity | skaet: Your call, there's my two bits. | 03:20 |
| slangasek | skaet: side effects from the udev change in question are really zero... the only possibility of adding the 'pkill' call are that the processes don't die in time, in which case we still see the bug, or they do, in which case the bug is gone | 03:20 |
| skaet | infinity, slangasek, ok, +1 on the udev one. | 03:20 |
| slangasek | ok | 03:20 |
| skaet | slangasek, on the libpciaccess one, if they satisfy you on the revdeps am thinking it would be good to have. What's the impact of 0 day SRU vs. including it? | 03:23 |
| slangasek | good question | 03:23 |
| slangasek | I was mostly thinking that if we're going to make the change at all it should be pre-release because it doesn't fit the SRU criteria | 03:24 |
| infinity | Inclusion should only matter if anything on the CD tries to install libgl1-mesa-dri:i386... | 03:24 |
| slangasek | but by that logic it doesn't fit the final freeze criteria either | 03:24 |
| slangasek | right, and that won't happen | 03:24 |
| slangasek | so the net effect for users is the same whether we do SRU or late freeze exception | 03:24 |
| infinity | (Arguably a bug that flash won't attempt to) | 03:24 |
| slangasek | infinity: flash is also happily not on the CD :) | 03:25 |
| slangasek | and yes, it is a bug that flash doesn't pull it in | 03:25 |
| infinity | slangasek: There's a checkbox to install it... Which of course then comes from the archive... Which means a 0day SRU is fine. | 03:25 |
| slangasek | yep | 03:25 |
| infinity | Thinking these things through in print is embarassing. | 03:25 |
| slangasek | (hmm, a checkbox to install it? Really?) | 03:25 |
| * infinity shrugs. | 03:25 | |
| infinity | Isn't the extras thing a question? I dunno. haven't installed an x86 desktop in a long time. | 03:26 |
| infinity | It can't possibly be silently done. | 03:26 |
| infinity | Net access + some other condision = restricted-extras | 03:26 |
| infinity | condition. | 03:26 |
| slangasek | ah, ok | 03:26 |
| infinity | I should quit with the fingers. | 03:26 |
| ScottK | It is a check that's not checked by default. | 03:27 |
| infinity | ^ | 03:27 |
| slangasek | right | 03:27 |
| slangasek | one I've never personally clicked ;) | 03:27 |
| infinity | Heh. | 03:27 |
| ScottK | (The not checked by default thing went to the TB) | 03:28 |
| infinity | Anyhow. I'm with you on the spirit of the thing that somehow breaking freeze is less distasteful than pretending a feature change is a sane SRU. | 03:28 |
| infinity | If we can get it well-testing before Sunday. | 03:28 |
| infinity | ScottK: And was unanimously voted on, I hear. | 03:28 |
| ScottK | Yes. | 03:28 |
| infinity | ScottK: So maybe we're not hopeless. | 03:28 |
| ScottK | Almost no discussion needed. | 03:28 |
| ScottK | Nope. | 03:28 |
| skaet | slangasek, if they can satisfy you its sane and low risk, and everything is ready to go in tomorrow, I'll go along. I don't want it bumping up against Sunday though. | 03:32 |
| slangasek | skaet, infinity: build tests for libpciaccess will certainly be done tonight (see #ubuntu-devel); risk of runtime regression is negligible since everything that uses it does so via ELF dependencies and the ld.so multiarch support is by this point well tested; and I can get the code review done tonight or tomorrow morning. No risk of running into Sunday. | 03:34 |
| skaet | slangasek, ok then. | 03:35 |
| infinity | slangasek: Sounds reasonable. Definitely nothing that tries to cleverly dlopen it or such madness? | 03:35 |
| slangasek | infinity: not unless it also fails to declare its dependency on it at the same time | 03:35 |
| infinity | slangasek: Check. | 03:35 |
| slangasek | it's linked by things that are themselves dlopened, but that's not a problem either | 03:35 |
| infinity | That's a bug I'm willing to expose. :) | 03:36 |
| infinity | (the dependency one, should it exist somewhere) | 03:36 |
| slangasek | anyway, libpciaccess is rather specialized :) | 03:36 |
| slangasek | Description: Generic PCI access library *for X* | 03:36 |
| infinity | Like that would stop anyone from being evil. | 03:37 |
| infinity | But yeah, it sounds low-risk if some rudimentary testing can be done. | 03:37 |
| infinity | Make sure file lists are sane, blah blah. | 03:37 |
| skaet | ubuntu server 20111007 posted ( with known 'xen-linux-system' has no installation candidate) | 03:39 |
| skaet | ubuntu dvd, kubuntu dvd, lubuntu desktop 20111007 posted | 03:48 |
| ScottK | skaet: Server will need the fixed postfix too. | 03:52 |
| skaet | ScottK, noted in the pad for rebuilds. | 03:53 |
| ScottK | Need to release quickly before Canonical gets a cease and desist on distributing tzdata ... | 03:56 |
| * skaet afraid to ask... | 04:04 | |
| infinity | ScottK: Seriously. | 04:06 |
| ScottK | http://yro.slashdot.org/story/11/10/06/1743226/civil-suit-filed-involving-the-time-zone-database | 04:07 |
| infinity | skaet: http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html | 04:07 |
| infinity | D'oh. | 04:07 |
| infinity | I paste too slowly. | 04:07 |
| infinity | But I don't paste slashdot, so point to me. | 04:07 |
| ScottK | postfix taken care of. | 04:15 |
| skaet | edubuntu dvd 20111007 posted | 04:16 |
| skaet | stgraber ^ | 04:16 |
| skaet | ScottK, infinity, urk. Thanks for the links though. | 04:21 |
| skaet | chinese ubuntu finished too. ok, that's it for me, pumpkin time. | 04:26 |
| skaet | pad is updated, good night all. | 04:30 |
| slangasek | the suit in question is total crap under US case law; I don't know why the plaintiffs haven't already been thrown out on their ears | 04:45 |
| ScottK | So was SCO. That only took 8 years. | 04:45 |
| ScottK | pitti: postfix SRU uploaded for you to have a look at. | 04:46 |
| slangasek | ScottK: the SCO case a) had deep pockets, b) had much less clear facts to work with | 04:47 |
| ScottK | True. | 04:48 |
| slangasek | a lot harder to navigate the question of "did you mean to transfer the IP rights" than "are there any protected IP rights here" :) | 04:48 |
| nigelb | slangasek: That's comforting :) | 04:49 |
| nigelb | It is worrying to see tzdata disappear :( | 04:49 |
| slangasek | it's inconvenient; I don't find it worrying | 04:50 |
| pitti | Good morning | 04:55 |
| infinity | Morning Martin. | 04:56 |
| infinity | pitti: I have preinstalled images spinning according to the order in the pad, if you want to post them as they pop. | 04:56 |
| infinity | pitti: core and server should be done/finishing, ubuntu's building. | 04:56 |
| pitti | infinity: sure; will do | 04:56 |
| slangasek | infinity, skaet: libpciaccess passes muster; synced (which I believe will bypass the queue) | 04:57 |
| pitti | infinity: do we already want to build/post desktop/alternates, or wait with that until Monday? | 04:57 |
| infinity | slangasek: If you synced it the ftpmaster way, it will, yes. | 04:57 |
| infinity | pitti: skaet's been building and posting. | 04:57 |
| pitti | infinity: as for the x86 linuxy stuff, ogasawara said she uploaded a new linux-meta | 04:57 |
| infinity | pitti: This should get us a nice round of testing over the weekend, then we can spin RCish images Sunday/Monday. | 04:58 |
| pitti | but seems the new meta didn't help much | 04:58 |
| infinity | pitti: Well, the meta matches up with everything. | 04:58 |
| infinity | pitti: It's just a question of components right now. What belongs where? | 04:58 |
| infinity | pitti: If everything up for demotion is demoted, it should all Just Work. | 04:58 |
| infinity | pitti: I believe. | 04:58 |
| pitti | infinity: anything else than "all binaries of linux are in main" are a real PITA | 04:58 |
| infinity | pitti: (Or, some stuff needs seeding and promoted) | 04:59 |
| pitti | as we get ten kernels a week in SRUs, and they bypass NEW | 04:59 |
| pitti | so I think I'll just seed the extra -meta binaries instead | 04:59 |
| infinity | pitti: Yeah, I dunno. I still think that any time a binary is promoted to main, the source and all other binaries should be too, but I lost that argument long ago. | 04:59 |
| infinity | I think it's bizarre to claim we support the source but not the binaries. | 05:00 |
| pitti | infinity: well, sometimes a binary pulls in something into main which we don't want; these cases are justified IMHO | 05:00 |
| infinity | pitti: That's rare, though. | 05:00 |
| slangasek | not rare enough | 05:00 |
| infinity | pitti: But I concede that point, I suppose. | 05:00 |
| infinity | Well, it has to be doing it via a dependency that isn't also a build-dependency. | 05:01 |
| infinity | Which is vaguely rare. | 05:01 |
| infinity | But yes, perhaps not rare enough. | 05:01 |
| infinity | pitti: All the armel uninstallables from britney are arch:all packages that depend on !arm packages. Not much we can do about that, so I declare britney for arm good. | 05:03 |
| infinity | (Well, we could fix it by making those arch:all packages be arch-specific, but a bit late) | 05:03 |
| infinity | pitti: The only other suspect thing is openoffice.org-gcj depending on non-existant libreoffice-gcj on all arches, might actually be worth an openoffice.org upload just to remove that metapackage and have apt be slightly less confused. | 05:04 |
| ScottK | infinity: You know how long that takes to build on arm, right? | 05:05 |
| infinity | ScottK: About 20 seconds? | 05:05 |
| infinity | ScottK: It's an empty package. | 05:05 |
| infinity | ScottK: openoffice.org is just a bunch of metapackages depending on libreoffice stuff. | 05:06 |
| ScottK | Oh. | 05:06 |
| ScottK | Right. | 05:06 |
| ScottK | Nevermind me. | 05:06 |
| pitti | infinity: yeah, agreed | 05:10 |
| pitti | bug 869459 looks reasonable to me, I'd go ahead with this; infinity, ScottK, any opinion on this (not sure if it was discussed already), or should I just go ahead and take the blame? | 05:14 |
| ubot4 | Launchpad bug 869459 in clutter-gst (Ubuntu) "FFe: Sync clutter-gst 1.4.2-1 (main) from Debian unstable (main) (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/869459 | 05:14 |
| ScottK | I'll share the blame if you'll also accept my postfix sru ... | 05:15 |
| ScottK | (I'd say go ahead.) | 05:16 |
| pitti | at least it promises to finally work on arm | 05:16 |
| infinity | Promises aren't everything. | 05:17 |
| slangasek | ^^ ignore, taken care of | 05:27 |
| * pitti starts building new langpacks, export finished | 05:33 | |
| ScottK | I'm glad I didn't wait much longer on the backports I just accepted. | 05:35 |
| pitti | ScottK: oh, full backports for postfix, not just upstream updates? | 05:40 |
| ScottK | I think it's actually lower risk and easier maintenance. | 05:42 |
| ScottK | The only significant change is the multi-instance support and since upstream has supported that since 2.6 it's really a long standing packaging bug we didn't support it. | 05:43 |
| ScottK | Most of the packaging diff is the addition of a copyright file for the source (all the binaries already had it). | 05:44 |
| pitti | I commented on bug 869411 | 05:48 |
| ubot4 | Launchpad bug 869411 in postfix (Ubuntu Natty) (and 1 other project) "SRU tracking bug for postfix 2.8.2 -> 2.8.5 for natty (affects: 1) (heat: 8)" [Wishlist,In progress] https://launchpad.net/bugs/869411 | 05:48 |
| pitti | ScottK: sorry, it seems we had a misunderstanding in the meeting then | 05:48 |
| pitti | I just assumed this is a mere upstream microrelease update, not a full backport including the packaging | 05:48 |
| pitti | as the former is the usual (and only) case for approved MREs | 05:49 |
| ScottK | OK. Then I've been doing the clamav updates wrong for a long time ... | 05:49 |
| ScottK | I can reduce this to just the upstream changes. | 05:49 |
| pitti | ok, thanks; I'll reject the current upload then | 05:50 |
| pitti | ScottK: especially bumping debhelper compat etc. will become more and more difficult the further back you go | 05:51 |
| pitti | if we would update hardy now, it wouldn't even work | 05:51 |
| ScottK | Right, but this will only go to natty as an SRU. | 05:51 |
| ScottK | It would work in backports. | 05:52 |
| ScottK | I don't anticipate asking for a major version exception like I did for clamav, so postfix 2.8 will never have to go back further than natty in -proposed/updates. | 05:53 |
| ScottK | I've already been backporting it to lucid. | 05:53 |
| ScottK | pitti: Reuploaded. | 06:04 |
| ScottK | BTW, for clamav there are cases where you have no choice to change the packaging or it won't work, so it is a bit different. | 06:04 |
| pitti | ScottK: right, understood | 06:05 |
| pitti | thanks, will review when the diff arrives | 06:05 |
| ScottK | I think I'm going to sleep then. | 06:05 |
| ScottK | Good night. | 06:05 |
| pitti | sleep well! | 06:08 |
| pitti | gnargh, LP timing out for LP builds | 06:09 |
| === jibel_ is now known as jibel | ||
| didrocks | pitti: just upoaded the one line for 3 bugs crash fix. I ran it out for an hour | 07:04 |
| pitti | didrocks: awesome, thanks | 07:04 |
| pitti | didrocks: so the others have more intrusive fixes where we can't be 100% sure? | 07:05 |
| didrocks | pitti: yeah, that's why I didn't include them, the gain/risk doesn't worth it | 07:05 |
| didrocks | can be a SRU, they aren't crashes (or crash with only one people experience, and the service then restarted) | 07:05 |
| didrocks | of course, it will work once I target oneiric and not precise… | 07:06 |
| pitti | lol | 07:07 |
| pitti | it's a bit of a nuisance, isn't it? | 07:07 |
| pitti | breaks people's habits | 07:07 |
| didrocks | indeed :-) | 07:07 |
| infinity | It broke me so badly that I started typing my passphrase in the suite field because I got a bit muddled. | 07:07 |
| infinity | (I only slept 3 hours last night, shut up) | 07:07 |
| didrocks | infinity: you never know, that can maybe works one day | 07:08 |
| didrocks | with verylongandnotstandinguprelease :-) | 07:08 |
| didrocks | pitti: the relevant commit is there: http://bazaar.launchpad.net/~ubuntu-desktop/unity/ubuntu/revision/591 | 07:08 |
| infinity | Speaking of uploads. | 07:09 |
| pitti | didrocks: ah, thanks; easier than trying to relate two debian-changes* monsters :) | 07:09 |
| didrocks | yeah, with the previous cherry-pick in particular… :) | 07:09 |
| infinity | pitti: I'm heading to bed, new openoffice.org in the queue in 50 seconds. | 07:09 |
| pitti | infinity: yay, will review | 07:09 |
| pitti | infinity: I bent LP timeouts to my will, new langpacks are being built | 07:09 |
| pitti | will upload once that's done and I gave them some good beating | 07:09 |
| pitti | infinity: sleep well | 07:09 |
| infinity | pitti: Not much to review. But if you notice a GPG passphrase anywhere in the diff, let me know. :P | 07:10 |
| pitti | *chuckle* | 07:11 |
| infinity | pitti: Once this builds, you should be able to remove oo.org-gcj. | 07:11 |
| infinity | pitti: And then the rest of the uninstallables are linux component issues, armel things we can't fix and one "hahaha, server team, lol wut?!" that I pinged Daviey about. | 07:12 |
| mvo | I just upload a new update-manger, the diff looks big, but its mostly just automatic importint of the oneiric base-installer to ensure that the kernel is correctly picked, that auto updating was disabled recently by accident | 08:26 |
| ev | for what it's worth, I can confirm the new wubi is in fact signed | 08:33 |
| ev | so what is the game plan for the RC images? Are those intended to land today or over the weekend? | 08:39 |
| pitti | ev: right now the plan is to trigger them on Sunday, so that on Monday morning we all have fresh images to test which are real RC | 08:40 |
| ev | pitti: cool, thanks | 08:40 |
| pitti | preparing/uploading langpacks right now, will accept apport/kerneloops on Sunday | 08:40 |
| infinity | (But don't let that stop you from vigorously testing the current builds over the weekend) | 08:40 |
| infinity | We expect RC to be very nearly identical. | 08:40 |
| pitti | yes, absolutely | 08:40 |
| ev | hm, I think I missed wiring up the wubi images to the simple tree on cdimage | 08:41 |
| ev | indeed | 08:41 |
| pitti | http://iso.qa.ubuntu.com/qatracker/ is there for everyone's testing pleasure | 08:41 |
| pitti | ok, langpacks are as good as they are going to be | 09:02 |
| pitti | cjwatson: can we temporarily disable the queuebot, to avoid getting 812 "new package" and 812 "removed" lines? | 09:02 |
| pitti | infinity: you don't happen to know where the queuebot runs at? | 09:06 |
| pitti | can't see it on people.c.c | 09:06 |
| pitti | */2 * * * *publish-queue -s oneiric -Q unapproved | 09:06 |
| pitti | oh, that might be it? | 09:06 |
| pitti | I guess it is; disabling for nor | 09:07 |
| pitti | now | 09:07 |
| cjwatson | slangasek: nothing on 745960 yet, probably going to have another crack at it today | 09:43 |
| cjwatson | infinity: syslinux-themes-*> maybe? if you want to change it, be my guest :) | 09:44 |
| cjwatson | pitti: the queuebot runs on chiark, you don't have access ;-) | 09:50 |
| cjwatson | pitti: I can stop the actual bot if you'd prefer | 09:50 |
| pitti | cjwatson: I just temporarily disabled publish-queue | 09:50 |
| pitti | it's back on now, all langpacks are in | 09:50 |
| cjwatson | ok | 09:50 |
| pitti | and seb just discovered that lightdm unfixed bug 849027 | 09:51 |
| ubot4 | Launchpad bug 849027 in lightdm (Ubuntu Oneiric) (and 2 other projects) "lightdm does not provide an equivalent to the gdm guest session AppArmor profile (affects: 3) (dups: 1) (heat: 274)" [Critical,Fix committed] https://launchpad.net/bugs/849027 | 09:51 |
| pitti | the merge to 1.0 upstream branch forgot half of the patch | 09:51 |
| pitti | I uploaded a new package which adds it back | 09:51 |
| pitti | tested it, works again | 09:52 |
| pitti | (it's in the queue now) | 09:52 |
| pitti | it restores the code to what we had last Friday, I didn't actually have to change the commit | 09:52 |
| pitti | (except for slightly unfuzzing a later patch) | 09:52 |
| cjwatson | pitti: bah, sorry I missed the TB meeting, I remembered about it earlier in the day and then completely forgot about it ... it would be nice to reevaluate the meeting time with the current board, it really doesn't work well for me | 09:55 |
| pitti | cjwatson: yeah, neither for me really, it's very late | 09:55 |
| pitti | cjwatson: added to the agenda for next time | 09:55 |
| cjwatson | thanks | 10:00 |
| pitti | cjwatson: do you have a minute to review lightdm? (unfortunately still no diff yet, LP is slow on Fridays apparently) | 10:23 |
| pitti | I'm available for interrogation on the patch | 10:23 |
| cjwatson | pitti: yep, moment | 10:33 |
| cjwatson | pitti: that's fine (compared with previous patch), accepted | 10:36 |
| pitti | cjwatson: thanks | 10:36 |
| pitti | meh, that was quite an unsuspected surprise | 10:36 |
| pitti | just after you think you've got everything in | 10:37 |
| sladen | skaet/robbiew: do we have enough information to populate https://wiki.ubuntu.com/PreciseReleaseSchedule yet? | 11:18 |
| pitti | sladen: there is https://wiki.ubuntu.com/PScheduleInterlock already | 12:04 |
| seb128 | pitti, ^ | 12:07 |
| pitti | yep, waiting for the diff to appear, to double check | 12:07 |
| seb128 | speaking about next, cycle: https://live.gnome.org/ThreePointThree#Schedule | 12:08 |
| seb128 | GNOME 3.4.1 tarballs should be on april 16 | 12:08 |
| seb128 | it would be nice if we have a schedule that allow to get .1 in Oneiric | 12:08 |
| pitti | seb128: last week I added the main 3.4 dates to the interlock page | 12:08 |
| pitti | seb128: ITYM precise? | 12:08 |
| seb128 | yes | 12:09 |
| seb128 | sorry my finger are not used to the next cycle yet :p | 12:09 |
| * cjwatson is currently trying to get a last-minute LP fix in for bug 572128 | 12:16 | |
| ubot4 | Launchpad bug 572128 in debmirror (Ubuntu) (and 1 other project) "Ubuntu Archive translations are missing Index metadata file (affects: 3) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/572128 | 12:16 |
| cjwatson | (FYI) | 12:16 |
| ogasawara | pitti: bug 869270, I've got a fix for it. I can upload, but would like approval from the release team first. | 13:06 |
| ubot4 | Launchpad bug 869270 in linux (Ubuntu Oneiric) (and 1 other project) "linux-image-extra's install claims unmet dependencies (affects: 1) (heat: 6)" [Medium,Fix committed] https://launchpad.net/bugs/869270 | 13:06 |
| ogasawara | pitti: the -extra's package is an elective install though, similar to lbm, so it is not release critical | 13:07 |
| pitti | ogasawara: that's the wrong (== 3.0.0) dependency? | 13:07 |
| ogasawara | pitti: correct, the dependency line was wrong | 13:07 |
| pitti | ogasawara: hm, but that's the "linux" source, I suppose | 13:08 |
| pitti | that would take quite a while to build | 13:08 |
| ogasawara | pitti: yep, arm takes the longest to build, around 12hrs | 13:09 |
| ogra_ | did someone talk to IS about the kernel and the panda builders ? | 13:10 |
| ogra_ | we have faster buildds that can be used with some manual fiddling | 13:10 |
| ogra_ | (by IS) | 13:10 |
| pitti | ogra_: so, it would barely fit, but leave us no margin at all for error (weekend and all that) | 13:11 |
| pitti | erm, ogasawara ^ | 13:11 |
| pitti | ogasawara: can we upload it to -proposed perhaps, and copy to final when it all built? | 13:11 |
| pitti | cjwatson: ^ how would that work for you? | 13:12 |
| ogasawara | pitti: I can do that if that's the consensus here | 13:12 |
| ogra_ | lamont, are you around ? could we fast-path that kernel upload manually into a panda so it builds a bit faster ? | 13:13 |
| pitti | with the detour via -proposed, 12 hours should even be enough | 13:13 |
| lamont | ogra_: you'll notice that all of the non-pandas are on manual | 13:13 |
| ogra_ | well, the panda should cut the time in half | 13:14 |
| ogra_ | lamont, oh, ok | 13:14 |
| lamont | would you like a little extra boost for the langpack builds, at the cost of idle amd64 builders? | 13:15 |
| pitti | lamont: it says ETA 33 minutes, so no extra hurry from my side | 13:15 |
| lamont | wfm | 13:16 |
| pitti | lamont: but nice to know that this is possible | 13:18 |
| pitti | lamont: OOI, how much effort it is to change their badge to be "I shall build i386 packages"? | 13:18 |
| lamont | 1) set to manual and get the buildd idle, because I don't trust the transition edge (wgrant would probably tell me he thoroughly tested this and it's fine, but I don't remember, so I play safe) | 13:20 |
| lamont | 2) builders/allspice/+edit <-- change architecture, uncheck manual, commit | 13:20 |
| lamont | N.B.: architectures with no builders do not get build records. that's why there's an lpia builder still... so don't ever take all of them | 13:21 |
| lamont | s/no/no ok/ | 13:21 |
| lamont | 3) remember what you hijacked so you can put it back later | 13:21 |
| lamont | 4) profit | 13:21 |
| lamont | sorry for the long path to profit, fiww | 13:21 |
| pitti | lamont: oh, nice; that doesn't even require superpowers, I could do that as well | 13:24 |
| lamont | it requires buildd-admin powers | 13:24 |
| pitti | lamont: perhaps I can try on one, for the exercise? | 13:25 |
| pitti | is that safe? | 13:25 |
| lamont | sure | 13:25 |
| pitti | lamont: yes, got them | 13:25 |
| lamont | allspice is love | 13:25 |
| pitti | oh, they are both on manual already | 13:25 |
| pitti | are you working on them right now? | 13:25 |
| lamont | fruits beat penguins any day | 13:25 |
| lamont | oh. | 13:25 |
| lamont | I started to, then didn't, but left them on manual. oops | 13:25 |
| pitti | ok, so taking allspice as guinea pig | 13:25 |
| lamont | so I cheated you out of the pleasure of doing step 1 | 13:26 |
| pitti | switched | 13:26 |
| pitti | https://launchpad.net/builders -> sweet | 13:26 |
| lamont | I'll throw crested back on auto then | 13:27 |
| pitti | lamont: not that I dare to try, but what would have happened if I set it to sparc? would the DC burst into flames? | 13:27 |
| pitti | or would it backfire and set _me_ on fire? | 13:27 |
| lamont | nah, but the builds would have failed in not-quite-spectacular ways | 13:27 |
| pitti | there, allspice building i386 | 13:27 |
| pitti | nice | 13:27 |
| lamont | since the sparc tarball isn't really compatible with chrooting into it on an x86 box | 13:27 |
| pitti | there have been occasions where this would have come in handy | 13:27 |
| pitti | lamont: thanks | 13:28 |
| pitti | yep, build finished | 13:28 |
| pitti | ok, just for the fun I'll leave that running for a while and switch back | 13:28 |
| lamont | though just for my sanity, if you bluetab me here or #is when you shuffle things, I'll have a clue when someone else asks me wtf is going on | 13:28 |
| pitti | yep, will do | 13:29 |
| pitti | I don't expect to actually use this very often | 13:29 |
| pitti | lamont: but I updated the description for that ("An amd64 builder (pitti temporarily hijacked to build i386)"), to at least leave some footmark | 13:30 |
| lamont | even better | 13:30 |
| lamont | I've been changing them to say what the builder is capable of in some cases | 13:30 |
| cjwatson | pitti: I'm not overjoyed about uninstallable packages in the release pocket, but I guess a zero-day is OK | 13:33 |
| pitti | cjwatson: I mean, we coudl copy -proposed into release, not -updates | 13:34 |
| pitti | cjwatson: the main thing that would look odd then is the changelog | 13:34 |
| pitti | lamont: that'd be my next question | 13:35 |
| pitti | lamont: we actually had cases when the three amd64 builders were busy building java, gcc, or whatnot, and we desperately needed an ubiquity | 13:35 |
| pitti | lamont: are some of the i386 buildds able to build amd64? | 13:35 |
| lamont | roseapple is likely | 13:35 |
| * lamont checks | 13:36 | |
| lamont | pitti: so yeah, roseapple. the others have 32-bit kernels | 13:36 |
| pitti | lamont: mind if I update the description to point out that? | 13:37 |
| lamont | feel fre | 13:37 |
| lamont | e | 13:37 |
| pitti | done | 13:38 |
| cjwatson | pitti: oh, sure, I'm fine with that too | 13:38 |
| pitti | ogasawara: so, let's go ahead with this | 13:38 |
| ogasawara | pitti: ack | 13:39 |
| pitti | gives us a nice exit hatch | 13:39 |
| sladen | pitti: bargin. I was mainly just after some milestone to put stuff against | 13:40 |
| lamont | pitti: allspice is ready to return to normalcy | 14:02 |
| skaet | slanden, schedule is up at https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule, have put a redirect from PreciseReleaseSchedule to there as well, as I suspect you won't be the last to ask ;) | 14:03 |
| ogasawara | pitti: ok, kernel uploaded, just needs approval. | 14:03 |
| skaet | pitti, ogasawara, just checking I've read the backscroll correctly - this is for 0-day SRU, not the release image? | 14:08 |
| ogasawara | skaet: if it finishes building in time to make the release, it'll be copied to the release pocket. Otherwise it'll go out as a 0-day. | 14:09 |
| skaet | ogasawara, can you summarize what its fixing for me? | 14:17 |
| * skaet needs to get more coffee it appears. :P | 14:18 | |
| ogasawara | skaet: yep, linux-image-extra fails to install because it claims it has an unmet dependency. The Depends: line in the control stub was wrong, so this patch fixes it. | 14:18 |
| skaet | ogasawara, depends line fix is the only change? | 14:20 |
| ogasawara | skaet: yep, it's the only change. | 14:20 |
| skaet | ogasawara, thanks, that makes me feel better about it. | 14:21 |
| ogasawara | skaet: indeed, no actual kernel code change. and the fact that it fails to install at the moment means we can't really break it any more than it is. | 14:22 |
| * skaet is trying to figure out if that last statement is meant as reassurance or warning... ;) | 14:22 | |
| pitti | skaet: goo dmorning | 14:32 |
| pitti | lamont: hm, wasn't here, but I just switched it back | 14:32 |
| pitti | skaet: it's to fix the remaining uninstallable packages | 14:33 |
| skaet | pitti, yup, less worried after the explanation, but it was a bit of a jolt to wake up to a kernel rebuild going on. | 14:43 |
| pitti | skaet: yeah, while the diff should be small, I'm not a fan of directly building it in release, so we figured out this trick | 14:44 |
| pitti | ugh, 3.3 MB diff | 14:45 |
| skaet | pitti, it seems worth remembering. ;) removes the risk. what 3.3MB diff?? BTW has there been any input from Daviey on whether they'll be wanting a rebuild of server. | 14:45 |
| pitti | skaet: just the usual noise of cleaned up abi files | 14:45 |
| pitti | skaet: I didn't notice a request from Daviey; Daviey, do you need one? | 14:46 |
| pitti | ogasawara: looks fine, thanks! accepted | 14:46 |
| skaet | pitti, http://pad.ubuntu.com/ubuntu-release | 14:46 |
| skaet | xen-linux-system issue with the last build, and picking up the udev change. | 14:47 |
| skaet | am wondering after we here from jibel if we should respin the desktop to make sure no weird interactions from desktop fixes that went in. | 14:48 |
| cjwatson | hm, so where is this udev workaround? I thought Steve had uploaded that | 14:57 |
| pitti | I think it went to a PPA | 14:57 |
| cjwatson | I don't see it in LP though | 14:57 |
| cjwatson | ah | 14:57 |
| pitti | the bug asks for testing it | 14:57 |
| cjwatson | right, https://launchpad.net/~vorlon/+archive/ppa/+packages | 14:58 |
| pitti | skaet, cjwatson, doko: I proposed merging debhelper and cdbs to https://wiki.ubuntu.com/P-SeriesOpening; how does that move from "proposed" to "set"? collecting votes from other release team members? | 15:36 |
| cjwatson | well I agree at least | 15:37 |
| doko | pitti, looks like violent agreement ... | 15:37 |
| skaet | pitti, let me ask some questions after the meeting. :) | 15:37 |
| Laney | sounds reasonable indeed | 15:38 |
| pitti | we already had some packages which needed a newer debhelper | 15:38 |
| pitti | and it's not really known to cause many regressions (at most FTBFS due to becoming stricter, but that's fine I think) | 15:39 |
| pitti | skaet: ^ FYI | 15:39 |
| pitti | skaet: yes, fine to discuss post-meeting | 15:39 |
| pitti | skaet: reading http://packages.debian.org/changelogs/pool/main/c/cdbs/current/changelog, we really want that for precise IMHO | 15:43 |
| cjwatson | yep, we've always done packaging toolchain early and it makes good software engineering sense to do so | 15:44 |
| cjwatson | (i.e. before autosyncing the bulk of packages) | 15:44 |
| pitti | I can commit to do the merges on Monday and have them ready | 15:46 |
| pitti | ooh, seems we have a trivial fix for bug 795475 | 15:46 |
| ubot4 | Launchpad bug 795475 in libimobiledevice (Ubuntu Precise) (and 3 other projects) "[iOS5 devices do not work] Unhandled lockdown error (-4) (affects: 4) (heat: 28)" [Medium,Confirmed] https://launchpad.net/bugs/795475 | 15:46 |
| pitti | how much do we love apple (for oneiric)? | 15:46 |
| pitti | http://cgit.sukimashita.com/libimobiledevice.git/commit/?id=f0487376671ffd6ac3fc121657f1fbd0acea3cb0 | 15:46 |
| doko | pitti: which "toolchain regression"? | 15:49 |
| pitti | doko: context? | 15:50 |
| pitti | doko: you mean for debhelper? | 15:50 |
| doko | <pitti> (if for nothing else than to test for toolchain regressions and the like) | 15:50 |
| pitti | there have been some cases, and there was some talk for e. g. disallowing brace expansion in .install files | 15:50 |
| pitti | doko: ah - well, the ones we don't know about :) | 15:50 |
| doko | well, ok. now I know that I can ignore this when you report this | 15:52 |
| pitti | doko: this just said "we should test the new kernel once it's built" | 15:53 |
| pitti | there is a nonzero chance that something breaks, even if it was just a dependeny fix | 15:53 |
| pitti | we had the weirdest things in SRUs already | 15:53 |
| cjwatson | I've fixed up the display name and such for https://launchpad.net/ubuntu/precise, and created milestones based on the current published release schedule | 16:09 |
| slangasek | cjwatson, pitti: the workaround probably isn't | 16:19 |
| slangasek | I've since had a closer look at udev code, and can't see any reason it would help us at all | 16:20 |
| skaet | cjwatson, thanks. | 16:23 |
| * skaet takes that off the list for london. | 16:23 | |
| pitti | skaet: I have a livecd-rootfs update for fixing the Chinese image overflow (pinged cjwatson to review the commit) | 16:32 |
| skaet | pitti, ack. mark it on the pad for respin, and I'll trigger it later then. | 16:35 |
| pitti | skaet: I learned that it needs an RT first | 16:35 |
| skaet | pitti, RT? not parsing that one. | 16:36 |
| * skaet must need more coffee | 16:36 | |
| pitti | skaet: request tracker ticket for IS, to install that new livecd-rootfs version once it's through unapproved ^ and in the archive | 16:37 |
| pitti | cjwatson: do you have a sec to review it? | 16:37 |
| pitti | (it's just that bzr change plus dch -r) | 16:37 |
| skaet | pitti, D'oh! of course. | 16:39 |
| * skaet must go get coffee | 16:39 | |
| pitti | lamont: once above livecd-rootfs is accepted, we need to roll it out to the builders; I prepared an RT to be sent once it's accepted, but we would need it today still (or tomorrow, but meh weekend); do you have the powers to fast-track this? | 16:42 |
| skaet | cjwatson, netboot images - Oct 6th ones good to post on the ISO tracker? | 16:47 |
| cjwatson | pitti: yes, link/number? | 16:47 |
| cjwatson | skaet: yes, although we ought to rebuild them if this kernel upload makes it in time | 16:48 |
| pitti | cjwatson: I was holding it back until it actually gets accepted | 16:48 |
| cjwatson | pitti: oh right, one moment | 16:48 |
| cjwatson | pitti: fine, accepted | 16:49 |
| skaet | cjwatson, ok will post, but mark for rebuiding based on when the kernel lands. | 16:49 |
| pitti | cjwatson: https://rt.admin.canonical.com/Ticket/Display.html?id=48375 | 16:51 |
| pitti | also added to pad now | 16:52 |
| pitti | skaet: ^ FYI, pad now has the links to the livecd-rootfs build page and RT | 16:52 |
| pitti | skaet, cjwatson: for coordination, I can test the new linux kernel on amd64 and i386 tomorrow morning, and copy it to oneiric if it's alright; ok? | 16:56 |
| skaet | pitti, that sounds fine by me. | 16:58 |
| skaet | pitti, I'll go ahead and rebuild the desktop this afternoon then, and post the images, so we can check that last nights fixes haven't caused any surprises. | 17:00 |
| slangasek | Daviey: we still don't have a useful workaround for udev; this is going to have to go to -updates | 17:00 |
| Daviey | slangasek: yeah, i wondered if the sleep 'fix' that seemed to hide the race for most scenarios might be a good release 'fix'? Then SRU a proper resolution? | 17:02 |
| skaet | pitti, if the linux image are good, does it make sense to do one more desktop build before Sunday with it in? | 17:02 |
| slangasek | Daviey: I don't know what sleep fix would hide any races, we're apparently already hitting the 60s timeout waiting for worker threads to die | 17:02 |
| pitti | skaet: I don't think it's worth the trouble really; they are identical except for the broken dependency, modulo tool chain issues (but the toolchain didn't change in some time) | 17:03 |
| Daviey | slangasek: Hmm, adam_g had a sleep patch (on the bug) would gave udev settle time, hiding the race. | 17:04 |
| Daviey | Isn't that doing the same thing that those debugging found, that exposing debug messages also slowed it down enough to hide the race? | 17:05 |
| skaet | pitti, ok then. Have all the fixes for the desktop images landed? If so, I'll start it now. | 17:05 |
| pitti | skaet: yes | 17:05 |
| slangasek | Daviey: adam_g has been debugging a different issue than hallyn and TREllis | 17:05 |
| === cody-somerville_ is now known as cody-somerville | ||
| slangasek | Daviey: Adam's bug is vgchange deadlock when udev dies; yes, a sleep would help that settle, but we haven't even been looking at that bug right now because I understood 818177 to be the higher priority | 17:06 |
| Daviey | slangasek: hallyn was reducing the impact with debug messages slowing it down aswell, right? | 17:07 |
| slangasek | Daviey: yes, but that could be a result of timing changes *internal* to udev | 17:07 |
| slangasek | to where a sleep in the main script isn't going to make a difference | 17:07 |
| Daviey | Is it awful to suggest adding the debug messages for release, and removing them as an SRU when we have a decent fix? | 17:08 |
| slangasek | if someone shows that a sleep helps, we can consider it, but even so we're too close to the cutoff to be uploading things that help some people if we don't understand why | 17:08 |
| slangasek | because it might regress other systems | 17:08 |
| Daviey | udev seems as solid as a wet paper bag :) | 17:09 |
| pitti | good night everyone! | 17:18 |
| Daviey | nn pitti | 17:19 |
| slangasek | night, pitti | 17:19 |
| cjwatson | Do we have consensus on syncing from testing for precise? I should get an LP branch landed for that if sos | 17:31 |
| cjwatson | *so | 17:32 |
| jbicha | https://wiki.ubuntu.com/LTS says we sync from testing :) | 17:33 |
| cjwatson | jbicha: yes, but we normally re-discuss that each time | 17:33 |
| cjwatson | I think it's a good idea, I just want to check | 17:33 |
| slangasek | cjwatson: I interpreted the mails as a consensus | 17:33 |
| cjwatson | I've clearly lost the mail trail - what was the subject? | 17:34 |
| cjwatson | (just want to have a reference for the LP bug) | 17:35 |
| slangasek | oh man, now I have to extract an actual reference | 17:35 |
| slangasek | skaet: do you remember where this was discussed? | 17:36 |
| jbicha | https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2011-September/012945.html | 17:36 |
| cjwatson | oh, ue-leads maybe? Subject: 'P' series prep - planning for LTS | 17:36 |
| cjwatson | ah, public thread, much better | 17:36 |
| cjwatson | and I even replied | 17:37 |
| slangasek | :) | 17:39 |
| stgraber | skaet: just so you know, we seem to have a pretty serious upgrade problem with Edubuntu. Poked mvo about it (update-manager deciding not to upgrade edubuntu-desktop) | 18:28 |
| stgraber | it seems to be a package dependency resolution problem when both switch from gnome 2.x to gnome 3.x and also depending on gnome-session-fallback, I'm sure mvo is a lot better at parsing apt.log than I'm so hopefully we'll have a fix soon | 18:29 |
| skaet | stgraber, thanks for the head's up. slangasek ^^ FYI. | 18:29 |
| slangasek | stgraber: are we expecting to need to get the fix onto the CD? | 18:37 |
| stgraber | slangasek: not sure yet, I'd think it should be fixable through a 0-day SRU for edubuntu-meta, though then I'd probably prefer to have it on the DVD anyway. That'd only affect Edubuntu DVDs though. | 18:38 |
| slangasek | stgraber: right | 18:38 |
| slangasek | mostly wondering if you expected to need it fixed in update-manager | 18:38 |
| stgraber | well, if we need it fixed in update-manager, that's going to be in Natty's, not Oneiric's or in the .tar.gz it downloads when starting the upgrade | 18:39 |
| stgraber | so I don't expect this to need to respin anything other than potentially Edubuntu | 18:39 |
| slangasek | right, ok | 18:40 |
| lamont | pitti: livecd-rootfs gets caught at the start of BuildLiveCD when it does a dist-upgrade. | 18:51 |
| lamont | or are you talking about a new BuildLiveCD? | 18:51 |
| Daviey | cjwatson: bug 870212, no chance for release - right? | 18:59 |
| ubot4 | Launchpad bug 870212 in debian-installer (Ubuntu) "no network d-i install does not continue after failing network setup (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/870212 | 18:59 |
| Daviey | pondering adding a Release Notes target, once you confirm. | 18:59 |
| ScottK | skaet: Sorry I missed the meeting. Kubuntu is in pretty good shape except for the ongoing kdepim pain. Upstream sent out a strong recommendation to apply a fix for a data corruption issue, so I think it's important to get on the ISO. | 19:01 |
| ScottK | Given that, I'm going to look at post 4.7.2 fixes to see what it makes sense to cherrypick. | 19:01 |
| skaet | ScottK, ack. | 19:02 |
| ScottK | I'll have it in the can well before the final spin on Monday. | 19:02 |
| skaet | inifinity, what's the status with the arm images? not seeing any on the iso tracker. | 19:06 |
| skaet | hmm.... seem to be built from the dailies. Adding. | 19:11 |
| stgraber | skaet, slangasek: mvo tracked down the problem to gnome-panel, he should have a potential fix tested a bit later today. So we'll need to have a new gnome-panel uploaded in Oneiric. Package seems to only be shipped by Edubuntu (source has been demoted to universe) | 19:13 |
| infinity | lamont: http://launchpadlibrarian.net/82233919/livecd-rootfs_2.42_2.43.diff.gz is a BuildLiveCD fix, so I assume that's what he meant, yes. | 19:15 |
| lamont | infinity: yeah - RT with the script attached is the ideal answer for that | 19:15 |
| infinity | I thought he filed an RT? | 19:15 |
| infinity | Ahh, he did, but wasn't specific. | 19:16 |
| slangasek | stgraber: aha - sounds doable, thanks | 19:16 |
| infinity | https://rt.admin.canonical.com/Ticket/Display.html?id=48375 | 19:16 |
| infinity | lamont: ^-- He just failed to mention BuildLiveCD anywhere in the ticket. :P | 19:16 |
| infinity | lamont: RT#48375 updated. | 19:19 |
| skaet | stgraber, limited scope at this point is good. glad mvo figured it out. | 19:21 |
| * mvo is on it | 19:21 | |
| infinity | skaet: Yeah, they all built. pitti was meant to add them as they popped, I guess he got sidetracked. :) | 19:23 |
| skaet | ubuntu desktop 20111007 omap, omap4, mx5, ac100 posted. | 19:24 |
| skaet | GrueMaster, ogra_ ^^ | 19:26 |
| * infinity rsyncs for some testing. | 19:26 | |
| skaet | kubuntu desktop 20111007 omap, omap4 posted | 19:26 |
| skaet | ScottK, ^ | 19:27 |
| GrueMaster | skaet: Are these somehow different from what was already posted for 20111007 daily? | 19:28 |
| skaet | GrueMaster, nope they're the same | 19:28 |
| skaet | just posting them to the iso tracker. | 19:28 |
| GrueMaster | ok. I l already have them then. | 19:29 |
| GrueMaster | Ah. | 19:29 |
| skaet | goodness | 19:29 |
| ScottK | OK. | 19:31 |
| infinity | Daviey: Is something being done about nova-compute-xen's uninstallability? | 19:33 |
| infinity | Daviey: (Or maybe it's intentional, but I don't see what provides "xen-linux-system"...) | 19:34 |
| * infinity likes a world where the armel build of linux finishes first. | 19:40 | |
| Daviey | infinity: i assumed it was showing because it's deps were in universe. | 19:41 |
| Daviey | It should be gone now... but you raise a good point. | 19:41 |
| infinity | Daviey: xen-linux-system doesn't exist at all... | 19:41 |
| infinity | Daviey: I suspect it's something Debian-specific that we don't provide? | 19:42 |
| infinity | (And maybe we should?) | 19:42 |
| Daviey | it wouldn't be that, it was added by a Ubuntu developer | 19:42 |
| Daviey | and not in debina either | 19:43 |
| Daviey | debian* | 19:43 |
| infinity | Daviey: Well, a quick google for it shows that such a package exists in Debian. | 19:43 |
| infinity | http://packages.debian.org/sid/xen-linux-system-3.0.0-1-686-pae for instance. | 19:44 |
| cjwatson | Daviey: that's distinctly not ideal and I suspect a regression in the IPv6 branch. I'll see what I can do | 19:44 |
| Daviey | *awesome* https://answers.launchpad.net/nova/+question/172828 | 19:44 |
| cjwatson | (but my daughter needs attention just now) | 19:44 |
| Daviey | cjwatson: thanks, as there is a workaround - and those installing with no network are a small set, i'm not going to cry about it. | 19:44 |
| cjwatson | it's the sort of thing I tend to regret not fixing before release | 19:45 |
| Daviey | sure | 19:45 |
| cjwatson | preseeders get really unhappy with me | 19:45 |
| infinity | Daviey: I'm not sure if dropping the dep (as in the whiteboard) is the right answer, or if we should be providing the metapackages like Debian, but dropping the dep sure it easier. :P | 19:45 |
| infinity | s/it/is/ | 19:45 |
| Daviey | well yes | 19:46 |
| Daviey | infinity: I think the theory being that you need to do some manual foo. | 19:47 |
| infinity | Daviey: ? | 19:48 |
| Daviey | infinity: I'm not sure just installing xen is enough, even in linux 3.0. | 19:50 |
| Daviey | i'm digging | 19:51 |
| infinity | Daviey: Eh? Installing a dom0-capable kernel and the hypervisor (minus a bug where the grub entry was wrong, but that's supposedly fixed now) was all it took back in hardy. Surely, we haven't made things worse? | 19:51 |
| infinity | Well, and a reboot. | 19:51 |
| infinity | And, sure, having a package installed doesn't guarantee you've rebooted. We had that same problem in hardy with some xen-foo deps. | 19:51 |
| infinity | But it's still a good hint. | 19:52 |
| Daviey | xen hasn't been presetn since then. :) | 19:53 |
| infinity | Daviey: Yes, I know. I'm just hoping it's as-good-or-better than the hardy support was. :P | 19:53 |
| infinity | Daviey: Either way. Dropping the dep is fine too. Depending on kernels has always been a lose-lose game for any package. | 19:53 |
| infinity | Daviey: Because, as stated, you can't actually guarantee it's booted just because it's installed. | 19:54 |
| infinity | Daviey: Packages that REALLY care (like libc) do preinst checks, but that seems stupidly heavy-handed for nova-compute-*, which could just fail to run when installed. | 19:54 |
| infinity | (Though it would be nice if you can verify that it fails to run in a sensible and informative way for P, if it doesn't already in O) | 19:55 |
| Daviey | infinity: I really don't care for O TBH. | 19:59 |
| Daviey | If that is the only bug the xen package has, i am a happy bunny | 19:59 |
| Daviey | (HINT, it's not been tested) | 19:59 |
| infinity | And it won't be tested if it can't be installed. :P | 20:00 |
| infinity | So at least dropping the dep is sane. | 20:00 |
| Daviey | I don't yet have enough info to rush something. | 20:02 |
| slangasek | doh, at least one regression reported as a result of adding vesafb fallback support to the initramfs (bug #869119) | 20:03 |
| ubot4 | Launchpad bug 869119 in initramfs-tools (Ubuntu Oneiric) (and 1 other project) "screen goes blank before showing password prompt (inteldrmfb, cryptsetup) (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/869119 | 20:03 |
| Daviey | might want, xen-hypervisor-4.1-amd64 | xen-hypervisor-4.1-i386 | 20:03 |
| slangasek | not a blocker, but doh | 20:03 |
| infinity | Daviey: Possibly, but as pointed out, depending on kernels is a lose-lose battle (and hypervisors are kernels in this context, as you can't guarantee you've booted to it just because it's installed) | 20:04 |
| infinity | Daviey: So, (for P), having no dep but having it fail verbosely with "this isn't a Xen dom0, doofus" might be appropriate. | 20:05 |
| Daviey | no, this is a firefight fix - for P we should set the reboot-required flag at least | 20:05 |
| infinity | Daviey: Even a reboot-reuquired guarantees nothing, if they boot to a different GRUB entry. | 20:05 |
| skaet | ubuntu alternate 20111007.1 posted. | 20:06 |
| Daviey | infinity: yeah, i agree.. i've given this more consideration that i care to for O :) | 20:06 |
| infinity | Daviey: Like I said, for O, I think just making it installable (ie: by dropping the dep) is probably enough to get it tested. | 20:08 |
| infinity | Daviey: Rethinking for P is totally out of scope for this week, unless you find yourself bored. :P | 20:08 |
| Daviey | infinity: Well xen-hypervisor-4.1-{amd64|i386} seems like a good middleground, no? | 20:09 |
| infinity | Daviey: If that's the dep on amd64, and cleverly reverse on i386, it's probably vaguely sane. | 20:11 |
| infinity | reversed* | 20:11 |
| Daviey | anyone deploying a virtualhost on i386 needs their head looking at :) | 20:11 |
| infinity | Not inclined to disagree. | 20:12 |
| Daviey | still cannot be installed on armel, unless you want to fix - https://launchpad.net/ubuntu/+source/xen/4.1.1-2ubuntu4/+build/2826607 :) | 20:12 |
| infinity | Yeah, I've heard rumours of upstream work for xen on PPC and ARM. I don't much care this week. ;) | 20:13 |
| jdstrand | skaet: sorry for not being around for the release meeting. I saw micahg responded, and he is correct, nothing really left for us for oneiric besides security updates after its released :) | 20:22 |
| skaet | jdstrand, no worries. micahg handled it. :) | 20:22 |
| * skaet removed worry about last minute security update from her list. ;) | 20:23 | |
| infinity | Well, they can be uploading to security right now anyway. :) | 20:24 |
| infinity | And images are always insecure a week after release. :P | 20:24 |
| skaet | :) | 20:26 |
| jdstrand | heh | 20:29 |
| jdstrand | true, we can just start going to oneiric-security and not worry anyone :) | 20:29 |
| jdstrand | though, tbh, I think the image builders would pull from there | 20:29 |
| jdstrand | anyhoo, we aren't doing that for the moment | 20:30 |
| skaet | Daviey, did you just approve ssh-import-id? | 20:51 |
| Daviey | skaet: I can't trigger an approve on anything | 20:52 |
| Daviey | not ~ubuntu-archive | 20:52 |
| Daviey | <-- | 20:52 |
| skaet | Daviey, understood. ok, wondering who approved it then? | 20:53 |
| Daviey | skaet: might be a good idea to push for better auditing next cycle. :) | 20:55 |
| infinity | skaet: I did. | 20:55 |
| skaet | Daviey: +1 on that. | 20:55 |
| infinity | skaet: It seemed straightforward enough. | 20:55 |
| infinity | And no possibility for negative impact. | 20:55 |
| Daviey | I Confirmed the bug which was raised regarding it. | 20:56 |
| skaet | infinity just a bit surprised to see it go through. | 20:56 |
| Daviey | It broke at least one app, not having it | 20:56 |
| skaet | if no negative impact, and unbreaks something yeah understood. | 20:57 |
| jibel | bug 870281 | 21:04 |
| ubot4 | Launchpad bug 870281 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crash when user choose to install additional software: http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_10.3.183.10.orig.tar.gz doesn't exist (affects: 4) (dups: 3) (heat: 30)" [High,Confirmed] https://launchpad.net/bugs/870281 | 21:04 |
| skaet | slangasek, ^ | 21:12 |
| skaet | known? | 21:12 |
| infinity | mdeslaur: ^ | 21:12 |
| infinity | As far as I know, mdeslaur was planning a new upload of flashplugin-nonfree. | 21:13 |
| infinity | Maybe. | 21:13 |
| slangasek | skaet: yes, flashplugin-nonfree needs updated every time there's a new upstream version; mdeslaur indicated he would handle it | 21:16 |
| slangasek | assigned to him | 21:16 |
| skaet | slangasek, thanks! | 21:16 |
| Daviey | flashplugin-nonfree really needs a better mechanism IMO. | 21:19 |
| stgraber | 21:16 <mvo> hm, this needs a little bit more work but its getting late, I will have to poke at it tomorrow morning | 21:20 |
| stgraber | 21:17 <mvo> I think the solution will be to add a explict breaks against the version of the rdepends of libpanel-applet-3-0 | 21:20 |
| stgraber | 21:17 <mvo> but I need to go to sleep | 21:20 |
| stgraber | 21:17 * mvo waves until tomorrow | 21:20 |
| stgraber | skaet: ^ so you know | 21:20 |
| skaet | Thanks stgraber. slangasek, please keep a lookout for it while I'm traveling. | 21:21 |
| * Daviey thought next week would be mostly sitting by a pool drinking sangria.. starting to look like we'll have to work. | 21:22 | |
| stgraber | I'll poke mvo tomorrow morning about it just before I leave to Montreal for the gnome summit (and then catch my flight to London in the afternoon) | 21:22 |
| stgraber | if the fix gets uploaded tomorrow morning, I should have some time to test the upgrades from the airport | 21:23 |
| skaet | thanks stgraber! | 21:25 |
| skaet | 20111007.1 WUBI posted | 21:28 |
| slangasek | Daviey: the "better mechanism" is to distribute the content in packages instead of having to download the content from elsewhere at package install time; but we can't do this in the Ubuntu archive because we can't redistribute the code on the mirrors. <shrug> | 21:31 |
| slangasek | so the only thing for it is to keep close tabs on the upstream versions and update the package each time there's a new release | 21:32 |
| Daviey | slangasek: Yeah, previously it was broken for a month IIRC. | 21:32 |
| slangasek | well, if no one's tending it the alternative to "broken for a month" is "installable but known-insecure for a month" anyway :) | 21:33 |
| Daviey | or pulling it out, and relying on -partner archive... not sure how that would sit with some people though | 21:34 |
| slangasek | now that we have a 64-bit version, it's worth thinking about | 21:34 |
| slangasek | but not during release week :) | 21:34 |
| Daviey | no, P-Series. sure. | 21:35 |
| skaet | indeed. | 21:38 |
| * skaet --> errand, biab | 21:39 | |
| * infinity runs off to eat turkeys. | 22:41 | |
| ScottK | infinity: Please accept my kdepim* uploads (or anyone else who's around). | 22:49 |
| wgrant | lamont, pitti: No need to go manual. | 22:50 |
| wgrant | You can just flip the arch while it's building, as it only affects the next dispatch selection query. | 22:50 |
| slangasek | are we still waiting before accepting apport/kerneloops? | 22:54 |
| infinity | slangasek: Not going to accept them until we spin "real RC" images. | 23:01 |
| infinity | slangasek: Which, by all accounts, is Sunday night, ish. | 23:01 |
| infinity | slangasek: (The same time we do base-files) | 23:02 |
| slangasek | infinity: you mean until *it's time to* spin them? | 23:02 |
| slangasek | ah | 23:02 |
| slangasek | ok | 23:02 |
| infinity | Well, yes, when it's time, not after. :P | 23:02 |
| slangasek | :) | 23:02 |
| infinity | slangasek: Can you review ScottK... You seem to be on it. :) | 23:02 |
| slangasek | :) | 23:03 |
| infinity | slangasek: Also, that kernel built everywhere. You might want to confirm with skaet, but I think the plan was to ignore the fact that the changelog says -proposed and copy it into the release pocket before the next round of rebuilds. :P | 23:18 |
| infinity | (scrollback was a bit muddled on what the actual concensus was) | 23:18 |
| slangasek | skaet: ^^ can you confirm that you want these linux kernels copied to the release pocket? | 23:26 |
| ScottK | slangasek: Thanks. | 23:41 |
| slangasek | sure | 23:42 |
| cjwatson | netcfg fixes the problem Daviey reported earlier; that's a recent regression, I think the bug means that systems may not get a proper hostname set, and I really don't want to deal with the consequences of that | 23:48 |
| cjwatson | it's a quick build, and if we're having a new kernel then we need a new d-i anyway, so we have an easy window for this | 23:48 |
| cjwatson | base-files uploaded too for when we want to go RC | 23:49 |
| * slangasek takes a look at netcfg | 23:57 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!