[01:02] * Please can someone accept libvirt, thanks * [01:03] /win 32 [01:04] /linux [01:04] Daviey: You've gone over it with combs of various fine-toothiness? [01:05] infinity: yes, it was discussed earlier. :) [01:06] There is a Ubuntu grown patch which is smaller to resolve the same issue, but the consensus was upstream cherry pick. [01:06] (and is passes the qa-regression-testsuite) [01:07] and oddly, seems to work :) [01:07] Weird. [01:07] infinity: thanks [01:37] infinity: Thanks. [03:23] That one ^^^ should fix pulse/skype integration. [03:38] ScottK: Wait, is that why Skype keeps freezing up on my system? [03:39] Not sure. I mostly know it fixes phonon not finding pulse. [03:40] Thanks. [03:40] The patch feels incorrect to me, but it does what it says on the tin. [03:41] (It would make more sense, surely, to try to detect if there's only a two-part version, and only then spoof the 0? Unless Pulse upstream has decided to move to two-part versions indefinitely, I guess) [03:46] * micahg doesn't understand why software make versions dependent on mutiple parts of a version [03:47] micahg: When that version defines an API, it gets interesting. [03:47] micahg: Which is the case with Skype. [03:47] Or, rather, how Skype was using pulseaudio. [03:47] From what I can tell. [03:47] And others, I'd assume. [03:48] still, shouldn't the function that checks the version do a sane check regardless of how many points in the version? i.e. 1.0 > 0.9 or whatever [03:48] Probably. [03:48] But if you're used to checking for major.minor.patchlevel, you might do it wrong. :P [03:48] And fixing everything that does that is harder than just keeping a consistent scheme. [03:49] yes, if you're checking for an exact match, that's probably wrong, we've seen this before (kernel) [03:49] Oh, I know. [03:50] I just want dpkg --compare-versions in the standard libc. :P [03:57] Has anyone tried a debootstrap of oneiric in the last 3 hours? [03:57] We're getting a corrupt Packages.gz problem [03:58] * ScottK debstraps a chroot from inside a chroot to see what happens. [03:59] deb/deboot [04:12] might have cleared up [04:21] deboostrap inside a chroot is apparently like crossing the streams. [04:21] boo/boot. [04:33] SpamapS: What was the actual error message? [04:35] * infinity sees no issues on an hour-old mirror. === jj-afk is now known as jjohansen [06:29] infinity: mesa-utils> sorry, didn't see that it was from a universe source; in my obsolete world model it was built by mesa [06:29] so let's not worry about this for oneiric then [06:32] hi pitti, I will hopefully have a chromium upload for oneiric shortly , do I need buy in again from lubuntu and mythbuntu? [06:33] micahg: as for potentially breaking their daily build, or what for? [06:33] pitti: for potentially breaking their RC? [06:34] I missed how that worked previously; but I guess can't hurt to ping them [06:34] micahg: does it build an arch:all package with strict dependencies? [06:34] I was supposed to update for beta 2, but it never happened [06:34] so that a late amd64 build would break installability? [06:35] yes [06:35] * micahg will run a test i386 build after amd64 finishes === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [07:55] infinity: ^ this is a looong story; are you interested in hearing it, or just want me to review? [07:56] (4 people, 2 hours of discussion, an etherpad, and two merge proposals) [07:57] but now we at least all have a shared understanding what lightdm did wrong, and what needs to happen [08:03] infinity: accepting, I'll take the bullets [08:43] pitti: will it make much of a difference if I upload chromium now or in ~8 hrs? [08:58] micahg: how long does it build? but in general, the earlier the better [08:59] pitti: i386 3hrs, amd64 1hr, armel 24 [09:01] micahg: oh, then please "now" [09:05] pitti: ok [09:32] pitti: can you review chromium as soon as it gets in, I'd like to go to sleep soon :) [09:34] micahg: thanks, accepting [09:37] Laney: why do we need the dbus-sharp sync? it doesn't seem to change anything compared to our version in oneiric? [09:37] pitti: thanks, I'll check for any issues in the morning my time, have a good day [09:38] micahg: sleep well, thansk! [09:41] pitti: indeed, it was just to get the pkg back in sync. The world looked rather empty so I jumped in there. [10:05] * cjwatson will be out for a bit - taking K to physio [10:12] ^ that's from me, review appreciated [10:19] seb128: would you mind peer-reviewing http://launchpadlibrarian.net/82012196/gnome-menus_3.2.0-0ubuntu1_3.2.0-0ubuntu2.diff.gz ? [10:19] pitti, can do [10:19] pitti, do you think bug #864174 should be rc? [10:19] Launchpad bug 864174 in lightdm (Ubuntu Oneiric) (and 1 other project) "boot hangs waiting for lightdm after purging gdm (wrong default-display-manager) (affects: 3) (heat: 16)" [High,Confirmed] https://launchpad.net/bugs/864174 [10:19] not sure how often it happens, or how [10:21] seb128: I think this can be SRUed, as it's pretty much an upgrade matter [10:21] seb128: but if we can get a fix nowish, fine for me to get it in [10:21] I think I switched between gdm and lightdm quite a bit, but /e/X/d-d-m seems alright for mne [10:22] this doesn't look very straightforward to me, or is there a known case where "lightdm" gets written there? [10:23] pitti, gnome-menus> ack from me [10:23] seb128: thanks, accepting [10:23] pitti, no fix that I know about, I'm just concerned it might be a real issue, dobey hit it this week and his box was hanging on an empty screen (from an user perspective) [10:24] seb128: yes, no doubt about the importance [10:24] ie. bug #856810 is similar [10:24] Launchpad bug 856810 in netcfg (Ubuntu) (and 1 other project) "Boot hangs at "Booting system without full network configuration..." (affects: 14) (heat: 76)" [Undecided,Confirmed] https://launchpad.net/bugs/856810 [10:24] seb128: I just think that fixing it in an SRU will be fine, as it doesn't affect a clean install [10:24] ok [10:24] that doesn't mean that we are not allowed to fix it for release :) [10:24] just that it's not a blocker [10:26] pitti, right, well I mentioned it there just in case r-t wants to "track" it [10:27] fwiw the update-notifier one is not critical, that is equally fine for -update IMO too [10:27] the software-center one would be nice because at least the "empty whats new" field will be a bad first run experience [10:54] mvo: u-n> oh, uh -- wouldn't it be easier to just ignore the auto-open key? [10:54] that seems quite a large and rather untested change to me at this point (also for SRU) [11:56] jibel, cjwatson, skaet: FYI, current amd64 live oversizedness (just a tad) is due to the new langpack deltas from yesterday, and will be fixed on Friday when we get fresh ones [12:02] pitti: fair enough, could you please write that in the bug? I'm not sure what the unity-2 status is actually, but if the whitelist/blacklist is all sorted it may wait for P [12:44] ScottK: the pyside fix I uploaded is actually a bug in cmake-data (expecting all qt4 modules to live under QT_LIBRARY_DIR). I'm suprised it hasn't affected other Qt4 + cmake programs (or maybe it has, and we haven't noticed) [12:45] or if that's a reasonable expectation, then it's a bug in phonon not being multiarched [13:18] good morning [13:18] can I get a respin of Edubuntu to pick up the new ubiquity please? [13:18] argh, our new overlord! [13:19] ;) [13:20] Congrats stgraber :) [13:21] thanks nigelb [13:28] tumbleweed: I have a vague recollection about this and I think the phonon developers said pyside was making unreasonable assumptions. [13:28] I thought it was fixed though. [13:31] ScottK: the fix was broken (sorry barry), see the bug the upload closes [13:31] and it's not pyside making that assumption, but cmake-data [13:34] I see. [14:20] cjwatson, infinity, pitti, skaet: Can one of you trigger a respin of Edubuntu? [14:20] sure [14:20] thanks [14:20] stgraber: running [14:42] cjwatson, infinity: I'm uploading apport for disabling for final release; should be accepted together with kerneloops on Friday, I just wanted to get the upload out of the way (to be able to stash P fixes into bzr) [14:53] pitti, ack. [15:53] Sigh. Alternates grew 8MB overnight. [16:51] pitti: I just NEWed some language packs and realised they seem inconsistent again [16:52] pitti: language-pack-kde-ky but no language-pack-kde-ky-base; language-pack-kde-my but no language-pack-kde-my-base; language-pack-mhr-base but no language-pack-mhr; language-pack-gnome-mhr-base but no language-pack-gnome-mhr [17:10] skaet: Are we not doing an RC release this week? Or is this just another daily test week? [17:10] GrueMaster, we'll be spinning up a full set of ISO images tomorrow and populating the ISO tracker for everyone to do the testing, but won't be posting on the web site. [17:11] Ah, ok. [17:11] skaet, do you have an ETA ? we still have that banshee issue and i would like to have as much time as possible before we decide if we switch to RB or not (seed change + meta upload) [17:11] * GrueMaster goes back to the arm pit. [17:12] ogra_, as soon as the langpacks land was the plan with pitti. [17:15] skaet, oh, and we need to talk about an EOL message for lucid armel :) [17:15] (happy to do that after release though) [17:16] Yes. Kill it please. I'll even bring a Titanium Spork to UDS if necessary. [17:50] doko, i just uploaded the ido ftbfs on armel fix [17:50] i didn't get to do an armel build on it, but it works on amd64 and should build on armel too [17:58] ogra_, after release +1. [18:29] kenvandine, thanks, however it still ftbfs, see https://launchpadlibrarian.net/82046752/buildlog_ubuntu-oneiric-armel.ido_0.3.0-0ubuntu3_FAILEDTOBUILD.txt.gz [18:29] please test build on kakadu [18:29] doko, ok... i'll look [18:29] ok, never tried that before :) [18:32] kenvandine: Or test build on scheat, it's much faster. :P [18:41] infinity, wow kakadu is slow... i figured ido is quick to build so who cares if it is an extra couple minutes [19:00] doko, uploaded again, fixed the last failure [19:11] kenvandine, looks fine, but I can't approve. infinity: ^^^ [19:11] great [19:19] So I guess we can update devscripts, ubuntu-dev-tools, etc now: http://www.markshuttleworth.com/archives/784 [19:23] at last :) [19:34] ScottK: thankfully we've been trying to use distro-info for all of that. /me pokes bdrung [19:45] I think debootstrap doesn't use that. [19:45] yeah, devscripts needs a patch too [19:47] ooh, maybe deboostrap should be patched to use distro-info at build time :) [19:47] Normally we get debootstrap unmodified from Debian. [19:47] (they have Ubuntu releases in theirs) [19:48] I don't think we should mess with that. [19:48] debian could probably benefit as well as they have distro-info [19:50] or at least be willing to take a patch [19:50] I guess you know what to do with that idea .... [19:54] slangasek: Care to give that a quick once-over for me? --^ [19:54] lookin [19:58] infinity: --swap-file-size argument is relative to the root? [19:58] (tested?) [19:58] slangasek: Yeahp. Ends up using chroot/$LB_SWAP_FILE_PATH [19:58] * slangasek nods [19:58] accepted [19:59] And I assume you mean s/size/path/ ;) [19:59] yes :) [20:06] slangasek: I don't want to touch xdiagnose with a 20-foot pole, I suspect it's more up your alley. [20:06] oh, is it? [20:07] Well, it does sketchy upstart things, which you've become intimate with lately. :P [20:07] (And that's totally my excuse for not reviewing the rest of the diff) [20:10] * slangasek chuckles [20:10] block post has been made, we have a name for P now. :) [20:10] http://www.markshuttleworth.com/archives/784 [20:11] s/block/blog/ [20:11] pronouncable and spellable, too! [20:12] infinity: actually, I may have written that patch to the upstart job ;) you sure you don't want to review it after all? :) [20:12] yes, p-a-n-g-o-l-i-n, pronounged "panguin" [20:13] huh? [20:14] http://www.merriam-webster.com/cgi-bin/audio.pl?pangol02.wav=pangolin [20:14] slangasek, ^ I think the "l" is pronounced. ;) [20:15] skaet: depends on the accent! I'm pretty sure I heard "penguin" ;) [20:15] slangasek, lol, :) [20:16] * charlie-tca was thinking this was finally an easy name :) [20:16] yeah, the l should be pronounced [20:16] obviously, locale specific ;) [20:37] * ScottK will look at python3-defaults. [20:38] Daviey: ^^^ updating memcached looks like pure fixing goodness. There's a lot of noise in the diff, but once you get to the meat of the changes it's all good. http://code.google.com/p/memcached/wiki/ReleaseNotes146 and http://code.google.com/p/memcached/wiki/ReleaseNotes147 are the upstream changelogs. [21:00] I've uploaded debootstrap to unstable with the 'precise' symlink; I guess I should do a fast-track sync of that rather than waiting for LP to pick it up? === warp11 is now known as warp10 [21:16] ScottK: looking, sorry for the delay - on really bad ()[Dbut free[C wifi [21:17] Daviey: Thanks. [21:22] Daviey: Seems "sane" to me, for some value of "sane" that includes "upstream has some very, very, very bad programmers". [21:22] Daviey: But their ugly code appears to do what it says it should. :P [21:23] Daviey: But since you seem to still be looking at it and not noticing I've reviewed it, I'll wait until you're done. :) [21:24] * cjwatson fast-syncs debootstrap, since nobody's complained [21:25] I'll miss being able to do this ;-) [21:26] cjwatson: "this" being fake syncing, or syncing from cocoplum? [21:27] infi gah! :) [21:27] if we could get lp to harvest packages from incoming.debian.org, native syncing could be fast too... [21:28] We can't even get LP to keep up with what's in the actual Debian archive. [21:28] yeah, that could be faster [21:29] infinity: scp blahblah cocoplum:, then copy to ~lp_archive/syncs/ on cocoplum and dpkg-scansources . /dev/null >Debian_incoming_main_Sources; sync-source.py -b cjwatson -S incoming debootstrap [21:30] cjwatson: I'm sure that we can get incoming scanning as a feature at some point. Maybe. [21:30] cjwatson: (It might be another one to put on the list of "stuff that should be done before you take away our shells") [21:32] I could've fakesynced as an alternative, so not critical. [21:32] cjwatson: Though, doing it properly means having the full Debian keyring handy, since incoming offers no signed Sources.gz. [21:33] Indeed, and keeping that in sync, and and and [21:47] umm, i just just accidently uploaded byobu to oneiric [21:48] i meant to just upload to PPA, but I neglected to give the do-not-release-to-oneiric flag in my release script [21:49] it's relatively harmless (affects the experiment, non-main byobu-tmux bits) -- but it should probably be rejected at this point in the release [21:49] sorry [21:49] lots and lots of apologies [21:49] cjwatson: infinity: I've gotten a request to add impitool for armel. Any chance we can slip an upload in for it? (it only needs a change to the Architecture line to build, and possibly a P-a-s change) [21:49] NCommander: Do we know why it was excluded? [21:50] kirkland: Rejected, and removed byobu from oneiric entirely for good measure. [21:50] infinity: :-D [21:50] infinity: not sure. it requires a kernel module which I'm unsure is available for armel, but IMPI hardware is in the pipeline [21:51] kirkland: fwiw, AAs do have access to the unapproved queue for rejects [21:51] (just not permission to accept stuff from it unless they're also wearing a release team hat :) [21:51] ipmitool: i386 amd64 ia64 powerpc # i386 specific [21:51] * infinity likes how that comment fails to match the arch line. [21:52] infinity: yeah, I saw that :-/, no comment. [21:53] NCommander: So, there's a claim that we'll be seeing IPMI BMCs on ARM, and this might actually work? [21:53] NCommander: If so, sure. Upload, but not until I've fixed P-a-s. [21:53] infinity: yeah. [21:54] slangasek: thanks -- i realized that after i asked [21:54] (And make sure you've done a local test build) [21:54] infinity: already did the test build. Poke me when P-a-s is fixed (might as well add both armel and armhf so we don't need to smack this again in P-cycle) [21:55] I already added both, yes. :P [21:55] Though we have a massive armhf patch landing later anyway. [21:55] infinity: thatwas fast :-) [21:56] Not sure which machine creates build records these days. [21:56] If it's cocoplum, you're good to go. If not, wait 15 minutes for cron to update P-a-s elsewhere. :P [21:57] (You can upload now, I just won't accept for "a while". [21:57] ) [22:05] infinity: upload away [22:05] infinity: thanks for your help [22:19] infinity: I think it's cesium [22:19] Daviey: Conclusions on memcached? [22:20] cjwatson: cesium dispatches builds, it's unclear to me what creates them. I *think* it's done by cocoplum on accept. [22:23] ScottK: I dropped off it as infinity had it in hand. [22:23] Daviey: ahh, all I saw was garble from you. :) [22:23] But yes, I've reviewed it. [22:23] I'll poke it through. [22:24] Sorry, laggy connection is hurting. [22:25] Daviey: S'all good. [22:26] skaet: are you around [22:26] * infinity looks at the 9MB ubuntu-docs diff and sighs. [22:26] utlemming, yup. what's up? [22:27] skaet: for our RC tomorrow, do we want to spin up some RC Cloud Images or just rely on the regular daily? [22:29] for the other images I was just going to let the daily builds take care of it [22:29] * cjwatson doesn't see a need for unnecessary work :-) [22:30] sounds good to me [22:30] utlemming, what cjwatson says. [22:31] :) [22:33] I'd appreciate review of localechooser; part of my last work item for the Qin images [22:34] (still testing the other part) [23:13] tumbleweed, ScottK: distro-info updated (will be synced tomorrow) [23:19] bdrung: I updated devscripts git, but the ubuntu upload needs a core-dev. I assume some of these also need SRUs [23:20] yes [23:20] tumbleweed: i could sponsor you ;) [23:20] tumbleweed: can we get a list of packages that needs a modification? [23:22] I suppose I could whip up a patch. We mentioned debootstrap, devscripts, distro-info, and older ubuntu-dev-tools, can't think of anything else right now [23:23] tumbleweed: i hope that i will have time to modify devscripts to use distro-info [23:24] I've done debootstrap (for precise, not for distro-info) [23:27] cjwatson: "ubuntu-distro-info -a | grep -v gutsy" should do the trick for you [23:27] not now [23:28] there's a list of other ones in https://wiki.ubuntu.com/NewReleaseCycleProcess [23:28] anyway, debootstrap can't depend on distro-info [23:28] it'll have to continue being bumped by hand [23:32] bdrung: yeah, I left that for you. devscripts: http://paste.ubuntu.com/703067/ [23:32] cjwatson: maybe it could use it at build time, though? [23:33] I suppose that would be possible [23:33] tumbleweed: dch is the last item on the list to make that work on debian and ubuntu better [23:46] * slangasek blames LVM for bug #818177 \o/ [23:46] Launchpad bug 818177 in udev (Ubuntu Oneiric) (and 3 other projects) "boot failures caused by udev race (affects: 7) (heat: 54)" [High,Confirmed] https://launchpad.net/bugs/818177 [23:49] ooh, progress [23:50] and that is an Ubuntu-specific udev rule in lvm2 [23:56] the watershed one? [23:56] /lib/udev/rules.d/85-lvm2.rules in toto is Ubuntu-specific, yes [23:56] that dates from UDS-Seville; I recall that there was a very detailed blueprint, if that helps [23:57] I'm not saying it's wrong that we have it... just that we're on our own for fixing it ;) [23:57] yeah [23:57] https://blueprints.launchpad.net/ubuntu/+spec/udev-lvm [23:59] Mountain View is in Seville now? :)