[01:02] <Daviey> * Please can someone accept libvirt, thanks *
[01:03] <highvoltage>  /win 32
[01:04] <infinity>  /linux
[01:04] <infinity> Daviey: You've gone over it with combs of various fine-toothiness?
[01:05] <Daviey> infinity: yes, it was discussed earlier. :)
[01:06] <Daviey> There is a Ubuntu grown patch which is smaller to resolve the same issue, but the consensus was upstream cherry pick.
[01:06] <Daviey> (and is passes the qa-regression-testsuite)
[01:07] <Daviey> and oddly, seems to work :)
[01:07] <infinity> Weird.
[01:07] <Daviey> infinity: thanks
[01:37] <ScottK> infinity: Thanks.
[03:23] <ScottK> That one ^^^ should fix pulse/skype integration.
[03:38] <infinity> ScottK: Wait, is that why Skype keeps freezing up on my system?
[03:39] <ScottK> Not sure.  I mostly know it fixes phonon not finding pulse.
[03:40] <ScottK> Thanks.
[03:40] <infinity> The patch feels incorrect to me, but it does what it says on the tin.
[03:41] <infinity> (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] <infinity> micahg: When that version defines an API, it gets interesting.
[03:47] <infinity> micahg: Which is the case with Skype.
[03:47] <infinity> Or, rather, how Skype was using pulseaudio.
[03:47] <infinity> From what I can tell.
[03:47] <infinity> And others, I'd assume.
[03:48] <micahg> 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] <infinity> Probably.
[03:48] <infinity> But if you're used to checking for major.minor.patchlevel, you might do it wrong. :P
[03:48] <infinity> And fixing everything that does that is harder than just keeping a consistent scheme.
[03:49] <micahg> yes, if you're checking for an exact match, that's probably wrong, we've seen this before (kernel)
[03:49] <infinity> Oh, I know.
[03:50] <infinity> I just want dpkg --compare-versions in the standard libc. :P
[03:57] <SpamapS> Has anyone tried a debootstrap of oneiric in the last 3 hours?
[03:57] <SpamapS> We're getting a corrupt Packages.gz problem
[03:58]  * ScottK debstraps a chroot from inside a chroot to see what happens.
[03:59] <ScottK> deb/deboot
[04:12] <SpamapS> might have cleared up
[04:21] <ScottK> deboostrap inside a chroot is apparently like crossing the streams.
[04:21] <ScottK> boo/boot.
[04:33] <infinity> SpamapS: What was the actual error message?
[04:35]  * infinity sees no issues on an hour-old mirror.
[06:29] <pitti> 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] <pitti> so let's not worry about this for oneiric then
[06:32] <micahg> hi pitti, I will hopefully have a chromium upload for oneiric shortly , do I need buy in again from lubuntu and mythbuntu?
[06:33] <pitti> micahg: as for potentially breaking their daily build, or what for?
[06:33] <micahg> pitti: for potentially breaking their RC?
[06:34] <pitti> I missed how that worked previously; but I guess can't hurt to ping them
[06:34] <pitti> micahg: does it build an arch:all package with strict dependencies?
[06:34] <micahg> I was supposed to update for beta 2, but it never happened
[06:34] <pitti> so that a late amd64 build would break installability?
[06:35] <micahg> yes
[06:35]  * micahg will run a test i386 build after amd64 finishes
[07:55] <pitti> infinity: ^ this is a looong story; are you interested in hearing it, or just want me to review?
[07:56] <pitti> (4 people, 2 hours of discussion, an etherpad, and two merge proposals)
[07:57] <pitti> but now we at least all have a shared understanding what lightdm did wrong, and what needs to happen
[08:03] <pitti> infinity: accepting, I'll take the bullets
[08:43] <micahg> pitti: will it make much of a difference if I upload chromium now or in ~8 hrs?
[08:58] <pitti> micahg: how long does it build? but in general, the earlier the better
[08:59] <micahg> pitti: i386 3hrs, amd64 1hr, armel 24
[09:01] <pitti> micahg: oh, then please "now"
[09:05] <micahg> pitti: ok
[09:32] <micahg> pitti: can you review chromium as soon as it gets in, I'd like to go to sleep soon :)
[09:34] <pitti> micahg: thanks, accepting
[09:37] <pitti> Laney: why do we need the dbus-sharp sync? it doesn't seem to change anything compared to our version in oneiric?
[09:37] <micahg> pitti: thanks, I'll check for any issues in the morning my time, have a good day
[09:38] <pitti> micahg: sleep well, thansk!
[09:41] <Laney> 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] <pitti> ^ that's from me, review appreciated
[10:19] <pitti> seb128: would you mind peer-reviewing http://launchpadlibrarian.net/82012196/gnome-menus_3.2.0-0ubuntu1_3.2.0-0ubuntu2.diff.gz ?
[10:19] <seb128> pitti, can do
[10:19] <seb128> pitti, do you think bug #864174 should be rc?
[10:19] <ubot4> 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] <seb128> not sure how often it happens, or how
[10:21] <pitti> seb128: I think this can be SRUed, as it's pretty much an upgrade matter
[10:21] <pitti> seb128: but if we can get a fix nowish, fine for me to get it in
[10:21] <pitti> I think I switched between gdm and lightdm quite a bit, but /e/X/d-d-m seems alright for mne
[10:22] <pitti> this doesn't look very straightforward to me, or is there a known case where "lightdm" gets written there?
[10:23] <seb128> pitti, gnome-menus> ack from me
[10:23] <pitti> seb128: thanks, accepting
[10:23] <seb128> 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] <pitti> seb128: yes, no doubt about the importance
[10:24] <seb128> ie. bug #856810 is similar
[10:24] <ubot4> 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] <pitti> seb128: I just think that fixing it in an SRU will be fine, as it doesn't affect a clean install
[10:24] <seb128> ok
[10:24] <pitti> that doesn't mean that we are not allowed to fix it for release :)
[10:24] <pitti> just that it's not a blocker
[10:26] <seb128> pitti, right, well I mentioned it there just in case r-t wants to "track" it
[10:27] <mvo> fwiw the update-notifier one is not critical, that is equally fine for -update IMO too
[10:27] <mvo> the software-center one would be nice because at least the "empty whats new" field will be a bad first run experience
[10:54] <pitti> mvo: u-n> oh, uh -- wouldn't it be easier to just ignore the auto-open key?
[10:54] <pitti> that seems quite a large and rather untested change to me at this point (also for SRU)
[11:56] <pitti> 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] <mvo> 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] <tumbleweed> 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] <tumbleweed> or if that's a reasonable expectation, then it's a bug in phonon not being multiarched
[13:18] <stgraber> good morning
[13:18] <stgraber> can I get a respin of Edubuntu to pick up the new ubiquity please?
[13:18] <Laney> argh, our new overlord!
[13:19] <stgraber> ;)
[13:20] <nigelb> Congrats stgraber :)
[13:21] <stgraber> thanks nigelb
[13:28] <ScottK> tumbleweed: I have a vague recollection about this and I think the phonon developers said pyside was making unreasonable assumptions.
[13:28] <ScottK> I thought it was fixed though.
[13:31] <tumbleweed> ScottK: the fix was broken (sorry barry), see the bug the upload closes
[13:31] <tumbleweed> and it's not pyside making that assumption, but cmake-data
[13:34] <ScottK> I see.
[14:20] <stgraber> cjwatson, infinity, pitti, skaet: Can one of you trigger a respin of Edubuntu?
[14:20] <pitti> sure
[14:20] <stgraber> thanks
[14:20] <pitti> stgraber: running
[14:42] <pitti> 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] <skaet> pitti,  ack.
[15:53] <ScottK> Sigh.  Alternates grew 8MB overnight.
[16:51] <cjwatson> pitti: I just NEWed some language packs and realised they seem inconsistent again
[16:52] <cjwatson> 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] <GrueMaster> skaet: Are we not doing an RC release this week?  Or is this just another daily test week?
[17:10] <skaet> 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] <GrueMaster> Ah, ok.
[17:11] <ogra_> 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] <skaet> ogra_, as soon as the langpacks land was the plan with pitti.
[17:15] <ogra_> skaet, oh, and we need to talk about an EOL message for lucid armel :)
[17:15] <ogra_> (happy to do that after release though)
[17:16] <GrueMaster> Yes.  Kill it please.  I'll even bring a Titanium Spork to UDS if necessary.
[17:50] <kenvandine> doko, i just uploaded the ido ftbfs on armel fix
[17:50] <kenvandine> i didn't get to do an armel build on it, but it works on amd64 and should build on armel too
[17:58] <skaet> ogra_, after release +1.
[18:29] <doko> 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] <doko> please test build on kakadu
[18:29] <kenvandine> doko, ok... i'll look
[18:29] <kenvandine> ok, never tried that before :)
[18:32] <infinity> kenvandine: Or test build on scheat, it's much faster. :P
[18:41] <kenvandine> infinity, wow kakadu is slow... i figured ido is quick to build so who cares if it is an extra couple minutes
[19:00] <kenvandine> doko, uploaded again, fixed the last failure
[19:11] <doko> kenvandine, looks fine, but I can't approve. infinity: ^^^
[19:11] <kenvandine> great
[19:19] <ScottK> So I guess we can update devscripts, ubuntu-dev-tools, etc now: http://www.markshuttleworth.com/archives/784
[19:23] <slangasek> at last :)
[19:34] <tumbleweed> ScottK: thankfully we've been trying to use distro-info for all of that. /me pokes bdrung
[19:45] <ScottK> I think debootstrap doesn't use that.
[19:45] <tumbleweed> yeah, devscripts needs a patch too
[19:47] <micahg> ooh, maybe deboostrap should be patched to use distro-info at build time :)
[19:47] <ScottK> Normally we get debootstrap unmodified from Debian.
[19:47] <ScottK> (they have Ubuntu releases in theirs)
[19:48] <ScottK> I don't think we should mess with that.
[19:48] <micahg> debian could probably benefit as well as they have distro-info
[19:50] <micahg> or at least be willing to take a patch
[19:50] <ScottK> I guess you know what to do with that idea ....
[19:54] <infinity> slangasek: Care to give that a quick once-over for me? --^
[19:54] <slangasek> lookin
[19:58] <slangasek> infinity: --swap-file-size argument is relative to the root?
[19:58] <slangasek> (tested?)
[19:58] <infinity> slangasek: Yeahp.  Ends up using chroot/$LB_SWAP_FILE_PATH
[19:58]  * slangasek nods
[19:58] <slangasek> accepted
[19:59] <infinity> And I assume you mean s/size/path/ ;)
[19:59] <slangasek> yes :)
[20:06] <infinity> slangasek: I don't want to touch xdiagnose with a 20-foot pole, I suspect it's more up your alley.
[20:06] <slangasek> oh, is it?
[20:07] <infinity> Well, it does sketchy upstart things, which you've become intimate with lately. :P
[20:07] <infinity> (And that's totally my excuse for not reviewing the rest of the diff)
[20:10]  * slangasek chuckles
[20:10] <skaet> block post has been made,  we have a name for P now.  :)
[20:10] <skaet> http://www.markshuttleworth.com/archives/784
[20:11] <skaet> s/block/blog/
[20:11] <charlie-tca> pronouncable and spellable, too!
[20:12] <slangasek> 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] <slangasek> yes, p-a-n-g-o-l-i-n, pronounged "panguin"
[20:13] <charlie-tca> huh?
[20:14] <skaet> http://www.merriam-webster.com/cgi-bin/audio.pl?pangol02.wav=pangolin
[20:14] <skaet> slangasek, ^ I think the "l" is pronounced. ;)
[20:15] <slangasek> skaet: depends on the accent!  I'm pretty sure I heard "penguin" ;)
[20:15] <skaet> slangasek,  lol,  :)
[20:16]  * charlie-tca was thinking this was finally an easy name :)
[20:16] <tumbleweed> yeah, the l should be pronounced
[20:16] <charlie-tca> obviously, locale specific ;)
[20:37]  * ScottK will look at python3-defaults.
[20:38] <ScottK> 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] <cjwatson> 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?
[21:16] <Daviey> ScottK: looking, sorry for the delay - on really bad ()[Dbut free[C wifi
[21:17] <ScottK> Daviey: Thanks.
[21:22] <infinity> Daviey: Seems "sane" to me, for some value of "sane" that includes "upstream has some very, very, very bad programmers".
[21:22] <infinity> Daviey: But their ugly code appears to do what it says it should. :P
[21:23] <infinity> 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] <cjwatson> I'll miss being able to do this ;-)
[21:26] <infinity> cjwatson: "this" being fake syncing, or syncing from cocoplum?
[21:27] <Daviey> infi	gah! :)
[21:27] <tumbleweed> if we could get lp to harvest packages from incoming.debian.org, native syncing could be fast too...
[21:28] <ScottK> We can't even get LP to keep up with what's in the actual Debian archive.
[21:28] <tumbleweed> yeah, that could be faster
[21:29] <cjwatson> 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] <infinity> cjwatson: I'm sure that we can get incoming scanning as a feature at some point.  Maybe.
[21:30] <infinity> 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] <cjwatson> I could've fakesynced as an alternative, so not critical.
[21:32] <infinity> cjwatson: Though, doing it properly means having the full Debian keyring handy, since incoming offers no signed Sources.gz.
[21:33] <cjwatson> Indeed, and keeping that in sync, and and and
[21:47] <kirkland> umm, i just just accidently uploaded byobu to oneiric
[21:48] <kirkland> 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] <kirkland> 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] <kirkland> sorry
[21:49] <kirkland> lots and lots of apologies
[21:49] <NCommander> 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] <infinity> NCommander: Do we know why it was excluded?
[21:50] <infinity> kirkland: Rejected, and removed byobu from oneiric entirely for good measure.
[21:50] <kirkland> infinity: :-D
[21:50] <NCommander> 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] <slangasek> kirkland: fwiw, AAs do have access to the unapproved queue for rejects
[21:51] <slangasek> (just not permission to accept stuff from it unless they're also wearing a release team hat :)
[21:51] <infinity> ipmitool: i386 amd64 ia64 powerpc                                     # i386 specific
[21:51]  * infinity likes how that comment fails to match the arch line.
[21:52] <NCommander> infinity: yeah, I saw that :-/, no comment.
[21:53] <infinity> NCommander: So, there's a claim that we'll be seeing IPMI BMCs on ARM, and this might actually work?
[21:53] <infinity> NCommander: If so, sure.  Upload, but not until I've fixed P-a-s.
[21:53] <NCommander> infinity: yeah.
[21:54] <kirkland> slangasek: thanks -- i realized that after i asked
[21:54] <infinity> (And make sure you've done a local test build)
[21:54] <NCommander> 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] <infinity> I already added both, yes. :P
[21:55] <infinity> Though we have a massive armhf patch landing later anyway.
[21:55] <NCommander> infinity: thatwas fast :-)
[21:56] <infinity> Not sure which machine creates build records these days.
[21:56] <infinity> 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] <infinity> (You can upload now, I just won't accept for "a while".
[21:57] <infinity> )
[22:05] <NCommander> infinity: upload away
[22:05] <NCommander> infinity: thanks for your help
[22:19] <cjwatson> infinity: I think it's cesium
[22:19] <ScottK> Daviey: Conclusions on memcached?
[22:20] <infinity> cjwatson: cesium dispatches builds, it's unclear to me what creates them.  I *think* it's done by cocoplum on accept.
[22:23] <Daviey> ScottK: I dropped off it as infinity had it in hand.
[22:23] <infinity> Daviey: ahh, all I saw was garble from you. :)
[22:23] <infinity> But yes, I've reviewed it.
[22:23] <infinity> I'll poke it through.
[22:24] <Daviey> Sorry, laggy connection is hurting.
[22:25] <infinity> Daviey: S'all good.
[22:26] <utlemming> skaet: are you around
[22:26]  * infinity looks at the 9MB ubuntu-docs diff and sighs.
[22:26] <skaet> utlemming, yup.  what's up?
[22:27] <utlemming> skaet: for our RC tomorrow, do we want to spin up some RC Cloud Images or just rely on the regular daily?
[22:29] <cjwatson> 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] <utlemming> sounds good to me
[22:30] <skaet> utlemming,   what cjwatson says.
[22:31] <skaet> :)
[22:33] <cjwatson> I'd appreciate review of localechooser; part of my last work item for the Qin images
[22:34] <cjwatson> (still testing the other part)
[23:13] <bdrung> tumbleweed, ScottK: distro-info updated (will be synced tomorrow)
[23:19] <tumbleweed> bdrung: I updated devscripts git, but the ubuntu upload needs a core-dev. I assume some of these also need SRUs
[23:20] <bdrung> yes
[23:20] <bdrung> tumbleweed: i could sponsor you ;)
[23:20] <bdrung> tumbleweed: can we get a list of packages that needs a modification?
[23:22] <tumbleweed> 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] <bdrung> tumbleweed: i hope that i will have time to modify devscripts to use distro-info
[23:24] <cjwatson> I've done debootstrap (for precise, not for distro-info)
[23:27] <bdrung> cjwatson: "ubuntu-distro-info -a | grep -v gutsy" should do the trick for you
[23:27] <cjwatson> not now
[23:28] <cjwatson> there's a list of other ones in https://wiki.ubuntu.com/NewReleaseCycleProcess
[23:28] <cjwatson> anyway, debootstrap can't depend on distro-info
[23:28] <cjwatson> it'll have to continue being bumped by hand
[23:32] <tumbleweed> bdrung: yeah, I left that for you. devscripts: http://paste.ubuntu.com/703067/
[23:32] <slangasek> cjwatson: maybe it could use it at build time, though?
[23:33] <cjwatson> I suppose that would be possible
[23:33] <bdrung> 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] <ubot4> 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] <cjwatson> ooh, progress
[23:50] <slangasek> and that is an Ubuntu-specific udev rule in lvm2
[23:56] <cjwatson> the watershed one?
[23:56] <slangasek> /lib/udev/rules.d/85-lvm2.rules in toto is Ubuntu-specific, yes
[23:56] <cjwatson> that dates from UDS-Seville; I recall that there was a very detailed blueprint, if that helps
[23:57] <slangasek> I'm not saying it's wrong that we have it... just that we're on our own for fixing it ;)
[23:57] <cjwatson> yeah
[23:57] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/udev-lvm
[23:59] <infinity> Mountain View is in Seville now? :)