[00:02] <superm1> jdong, be careful using su, it may open a console kit session, making an error popup whenever you try to shutdown using ck
[00:03] <superm1> ran into that problem with mythbackend, and ended up patching in support to natively drop permissions in the app instead
[00:03] <jdong> superm1: ouch. Fortunately this is just a topless server so I'
[00:03] <jdong> err
[00:03] <jdong> did I say that?
[00:03] <jdong> I mean headless.
[00:03] <jdong> same thing :)
[00:09] <cjwatson> superm1: su is the wrong tool for nearly any job anyway, so I'm sure it's no great loss
[00:09] <cjwatson> you certainly should never use it noninteractively, since it opens a PAM session
[00:09] <cjwatson> and its argument parsing is awful
[00:10] <cjwatson> man-db.postinst does a simple thing in perl; there are many options
[00:13] <G> slangasek: FYI, I just updated 571093 (libvirt bug) looks like the SRU patch isn't the latest, the libvirt guys modified it slightly before pushing it and found a couple of other memory leaks
[00:14] <slangasek> G: is the patch that's currently there free of regressions and an incremental improvement over the status quo?
[00:15] <slangasek> (we're not going to have time for further fixes to libvirt before 10.04.1, so the question is whether we can commit to the current package in good conscience, or if I need to roll it back and respin candidate images)
[00:16] <G> slangasek: I believe it is
[00:16] <G> slangasek: let me just check one thing though
[00:19] <G> slangasek: yep just double checked, I just noticed that we are in one case with the patch in proposed free'ing twice, but the function libvirt uses to free it, does check that it exists, so there shouldn't be a Null Pointer as a result
[00:21] <G> slangasek: so I don't see any regressions in the code
[00:22] <G> and the patch proposed, has been working for me for a while
[00:25] <slangasek> G: great, will promote to -updates then - thanks!
[00:26] <G> slangasek: no problem, it was a pain of a bug to try and reproduce :)
[00:29] <penguin42> G: Are you using libvirt on a maverick install and if so do you find you have to disable the apparmor profiles for it?
[00:29] <G> penguin42: ha, my maverick machine hasn't been updated for a while and I never got round to doing VM stuff on it, it's been on my TODO list for ages :)
[00:30] <G> gotta work out the phantom reboots first, I think some are Kernel some PSU :(
[00:30] <penguin42> G: OK, just wondered if it was just me; I have a pair of separte VM issues on maverick; apparmor and the SDL consoles broke a week or two
[00:30] <penguin42> ago
[00:30] <penguin42> hmm does 2.6.35 still have the alt-sysrq bug?
[00:31] <G> (and I couldn't get kdump etc working to try and report the panics)
[00:31] <penguin42> hmm no the forgetting about key up seems to have gone
[00:35] <G> penguin42: is there a bug number for the libvirt/apparmor/SDL thing?
[00:35] <penguin42> I've done the SDL one, not the apparmor one yet
[00:35] <G> I might start to throw Maverick on my other box
[00:35] <penguin42> G: bug 615077
[00:38] <G> penguin42: I'll give it a go sometime :)
[00:38] <penguin42> I'll try it again to see if it got fixed
[01:24] <mathiaz> cjwatson: when netbooting d-i, is there a way to specify to install from the cdrom (ie take packages from the cdrom)?
[01:32] <superm1> cjwatson, right, the reason the ck session was open was because of the pam.  so yeah good it's all sorted out now
[05:10] <pitti> Good morning
[05:10] <ajmitch> morning
[05:11] <ion> hi
[06:07] <rsalveti> pitti: do you know which process should be responsible for stopping ureadahead?
[06:08] <rsalveti> it seems that nobody is stopping ureadhead, it's paused waiting for sigterm (stop)
[06:08] <pitti> rsalveti: erm, I don't understand? it just exits by itself once it's done reading all the files
[06:08] <pitti> rsalveti: oh, you mean the collector?
[06:08] <ion> “stop on stopped rc”
[06:08] <rsalveti> pitti: yep, because it sets up the collector (debugfs) and then pause waiting for someone to stop it (send the sigterm)
[06:08] <pitti> the collector is stopped by /etc/init/ureadahead.conf, "pre-stop exec sleep 45"
[06:09] <rsalveti> then it'll generate the pack file
[06:09] <rsalveti> but I don't know who is responsible for stopping it
[06:09] <pitti> rsalveti: after those 45 secs, it gets stopped ("stopped rc" means all the rc*.d scripts ran)
[06:10] <rsalveti> hm, so some other script is still running
[06:12] <rsalveti> I just updated another machine to maverick and then I noticed this issue
[06:18] <rsalveti> pitti: the weird thing is that rc is at "stop/waiting" but ureadahead is still "start/running"
[06:19] <rsalveti> need to run upstart with debug to understand what's happening
[06:30] <pitti> slangasek: AFAICS we now have everything in -updates for 10.04.1, right?
[06:36] <slangasek> pitti: looks like it, though I see an openjdk security update was published to lucid-updates today
[06:36] <pitti> slangasek: do you want to include that on new respins?
[06:36] <pitti> there'll always be "that next update", after all
[06:36] <pitti> I hear a kernel update is coming soon, too
[06:37] <slangasek> pitti: no, I think we should go with it as-is; but I would have expected a freeze to be in effect on copies to lucid-updates at least until we took the point release snapshot
[06:37] <slangasek> (which I'll go ahead and do now)
[06:38] <pitti> oh, right
[06:38] <pitti> slangasek: does that run automatically from cron these days?
[06:38] <slangasek> the pocket copy?  I don't know
[06:41] <slangasek> pitti: snapshot taken; I've also manually added the openjdk-6 sources to the snapshot, so we should be covered to proceed
[06:41] <pitti> nice; so 10.04.1 is carved in stone now?
[06:42] <pitti> slangasek: can you please ping me when you want to lift the -proposed freeze?
[06:43] <slangasek> pitti: yes, I think 10.04.1 is locked in; everything is in -updates now that should be, if we do any further respins we can do them without -proposed, so please consider -proposed unfrozen
[06:44] <pitti> ah, nice; time to process the large backlog then :)
[07:57] <dholbach> good morning
[07:58] <ion> hi
[08:34] <bilalakhtar> 3
[08:35] <bilalakhtar> sorry typed 3 by mistake
[08:36] <ion> That’s unforgivable.
[08:38] <bilalakhtar> ion: jokes are not forgiveable on this channel
[08:39] <pitti> bilalakhtar: good bye, hello, good bye, hello again
[08:40] <bilalakhtar> pitti: I cannot help. services takes a long time to assign me my cloak
[08:40] <bilalakhtar> by that time irssi joins all the channels
[08:46] <bilalakhtar> When is M-o-M supposed to be up again?
[08:46] <bilalakhtar> manually merging until then
[08:50] <dholbach> hola seb128
[08:53] <seb128> hey dholbach
[09:50] <StevenK> cjwatson: In regards to bug 582183, would you like initialise-from-parent to also copy the archive permissions?
[09:58] <pitti> StevenK: oh, it doesn't already? I. e. right now ACLs need to be set up again for each new release?
[11:08] <ara> pitti, can I ask you a quick apport question?
[11:08] <pitti> ara: sure
[11:09] <ara> pitti, I am trying to add tags to a report (in an apport hook that I am writing)
[11:09] <ara> if I put report['Tags'] = 'tag1 tag2', then 'maverick' and arch are not added
[11:10] <pitti> ara: they are added before
[11:10] <ara> but if I use report.setdefault, then tag1 and tag2 are not added
[11:10] <pitti> ara: you need to use +=
[11:11] <pitti> report['Tags'] += ' tag1 tag2'
[11:11] <ara> pitti, ok, I tried that and debugging it (using python source_...) i got an exception, but I guess it works differently
[11:11] <pitti> ara: ah, in that case they aren't added by apport of course
[11:11] <bdrung> \o/ the sponsor request count for main is < 70
[11:11] <pitti> ara: add this so that it works in both cases:
[11:11] <pitti>     report.setdefault('Tags', '')
[11:11] <pitti> bdrung: good work!
[11:11] <dholbach> bdrung, woohoo!
[11:12] <ara> pitti, OK, will try that
[11:12] <ara> thanks a lot!
[11:13] <bdrung> pitti, dholbach : thanks. i will be on vacation soon. hopefully the number won't be higher when i come back
[11:13] <cjwatson> StevenK: yes please, would save me a deal of hassle
[11:14] <cjwatson> slangasek: yes, copies from -security to -updates are cronned; I shouldn't think that matters because builds happen from -security as well anyway, in other words the thing that arguably should have been frozen was security publications rather than copies to updates
[11:46] <ara> pitti, one more question, if the application crashes, and the package has an apport hook, will apport attach the information in the hook (apart from coredump)
[11:46] <ara> ?
[11:46] <pitti> ara: yes, that's the main point of those :)
[11:47] <pitti> ara: you can test that locally by starting the app, and killall -SEGV appname
[11:47] <pitti> then apport will come up, and you can click the "details" expander to see the repot
[11:47] <pitti> report
[11:47] <ara> pitti, thanks again, you rock :-)
[11:48] <pitti> ara: you too! :0
[11:48] <pitti> my shift key doesn't
[11:48] <ara> :D
[12:23] <wgrant> cjwatson: Do you want xz for 3.0 sources as well?
[12:25] <cjwatson> wgrant: I figured one thing at a time; that should be a separate bug
[12:25] <cjwatson> wgrant: I have a diff locally for data.tar.xz; was just looking for a *cough* pre-impl chat in #launchpad-reviews
[12:25] <wgrant> Yes, they do often tend to be "pre"-imp...
[12:26] <cjwatson> wgrant: though to give you a straight answer, .orig.tar.xz or whatever isn't an immediate priority for me; my motivation is in https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-spring-cleaning
[12:26] <wgrant> Ah, so just killing off existing lzma stuff?
[12:27] <cjwatson> right
[12:32] <Riddell> dholbach: you can wipe ~dholbach/tmp/sponsoring-list, all done
[12:32] <dholbach> Riddell, done, thanks a lot
[12:38] <Riddell> dholbach: who should I subscribe to bug 617787 to get it approved?
[13:14] <\sh> hmm...did anybody setup a squeeze sbuild chroot with mk-sbuild in the last days? it stops with "finish: apt-get command not found"
[13:22] <dholbach> Riddell, ubuntu-sponsors
[13:22] <soren> Hm... I have a build that failed in lucid-proposed, but worked excellently in my PPA. A debdiff between the two source packages only shows the different versions I used in debian/changelog and a different timestamp. It's a bit of a mystery.
[13:22] <soren> The build that works: https://edge.launchpad.net/~soren/+archive/nova/+build/1918475
[13:22] <soren> The build that failed: https://edge.launchpad.net/ubuntu/+source/user-mode-linux/2.6.32-1um-3ubuntu3.1/+build/1922058
[13:23] <soren> Everything is pretty much identical up until the build starts (the lucid-proposed build apparantly has lucid-proposed enabled which my ppa does not. Only difference seems to be an unrelated change in libc6).
[13:24] <soren> The build starts out running a "make oldconfig" on the kernel. The build log from the non-PPA buildd suggests that the kernel's build system thinks it's a 32-bit system, but it's not.
[13:24] <soren> Does anyone have any clues?
[13:25]  * soren is inclined to retry the build.
[13:27]  * soren saves the build log and retries the build
[13:27] <\sh> can someone approve lucid nomination for bug #533369 and eventually fix it ? :) thx
[13:32] <cjwatson> I've approved the nomination but have no time to do SRUs just now
[13:33] <\sh> cjwatson: thx :)
[13:33] <cnd> seb128, what do I need to do to start the ball rolling on MIRs for utouch stuff?
[13:34] <cnd> https://wiki.ubuntu.com/MainInclusionProcess?
[13:34] <seb128> cnd, write mir reports for those?
[13:35] <cnd> ok, I assume it's documented there
[13:35] <cnd> I asked before I google searched
[13:35] <zul> did 10.04.1 go out?
[13:35]  * cnd chastises himself
[13:35] <cnd> thanks seb128
[13:36] <seb128> cnd, right, that page describe what you need to do
[13:42] <\sh> cjwatson: if it helps you, I'll prepared an debdiff for the SRU (needs uploading to lucid-proposed)
[13:46] <Riddell> siretart: do you know what the status of bug 374900 is?  can it be closed?
[13:47] <cjwatson> \sh: I thought you were a core-dev - can't you upload it directly?
[13:47] <cjwatson> \sh: the debdiff isn't what takes the time for SRUs for me, it's the administration
[13:49] <\sh> cjwatson: I'm not :)
[13:49] <\sh> cjwatson: anymore :)
[13:52] <cnd> I made a bug report against the upstream project in lp, how can I move that to the ubuntu package project?
[13:52] <cnd> or is that possible?
[13:54] <soren> cnd: Click the "also affects distribution" link.
[13:55] <cnd> soren, ahh
[13:55] <cnd> thanks!
[13:55] <soren> cnd: Sure.
[14:04] <\sh> micahg: ping
[14:07] <cnd> seb128, does a packages build deps all need to be in main, or just binary package deps?
[14:07] <seb128> build-depends as well
[14:29] <siretart> Riddell: the TB has asked cjwatson to look into this. Collin, any news on that?
[14:37] <chrisccoulson> hi persia - do you mind if i hijack bug 522645, or did you plan to do any work on that?
[14:39] <persia> chrisccoulson, I never intended to work on it: I filed it because there were discussions as to whether it would be in main, and I thought they should be tracked in a bug.  You aren't hijacking it (or I would have been assigned)
[14:40] <chrisccoulson> persia - cool, thanks. i'll use your existing report then rather than starting a new one
[14:40] <persia> chrisccoulson, That's why it's there :)  Good luck.
[14:41] <cjwatson> siretart: none, sorry
[14:41] <cjwatson> (P.S. "Colin")
[14:41] <chrisccoulson> heh, thanks ;)
[14:55] <tgardner> how can I figure out where a Linaro kernel package lives? linux-image-2.6.35-1001-omap_2.6.35-1001.5_armel.deb is not in http://archive.ubuntu.com/ubuntu/pool/{main,universe}/l/linux or http://ports.ubuntu.com/ubuntu-ports/pool/{main,universe}/l/linux
[14:56] <ogra> linux-image-2.6.35-1001-omap_2.6.35-1001.5_armel.deb ?
[14:56] <ogra> that would conflict with the existing omap image, no ?
[14:56] <tgardner> ograthe ABI is different
[14:56] <tgardner> ogra: ^^
[14:57] <ogra> still very confusing
[14:57] <dholbach> https://edge.launchpad.net/ubuntu/maverick/+queue?queue_state=3&queue_text=linux-image-2.6.35-1001-omap
[14:57] <ogra> tgardner, cant you have a linaro in the name somewhere ?
[14:57] <tgardner> ogra: thats what I'm working on
[14:57] <ogra> ah
[14:57] <ara> persia, hi!
[14:58] <ogra> tgardner, is the package through the NEW qeueu already ?
[14:58] <ogra> (else you wont find it in the archive)
[14:58] <tgardner> dholbach, we pull the package from the archive to extract the ABI, so I need to know the URL
[14:59] <persia> ara, The document I'm sure you want to ask me about has been getting better every couple days, but still doesn't quite make sense to the uninitiated.
[14:59] <dholbach> tgardner, I'm afraid I don't know
[14:59] <tgardner> ogra: I think so. checking...
[14:59] <dholbach> tgardner, I just searched for it
[14:59] <ogra> the meta is at http://ports.ubuntu.com/ubuntu-ports/pool/universe/l/linux-linaro-meta/ but i dont see the actual package
[14:59] <ara> persia, OK, thanks for the update
[14:59] <ara> persia, anything I can help with?
[15:00] <dholbach> tgardner, does https://edge.launchpad.net/ubuntu/+source/linux-linaro help?
[15:00] <JFo> persia! hope I didn't miss your ping in the recent past. I know you said you wanted to talk with me after Platform.
[15:00] <persia> ara, Not right now, but I'll copy you on the next review round: I'm still processing notes from the last review (separation of policy & procedure, etc.)
[15:00] <tgardner> dholbach, I can see it via Launchpad, but I'm not finding the binary in the archive
[15:01] <persia> JFo, I think I didn't ping you, but I'll accept reverse pings :)
[15:01] <JFo> heh
[15:01] <dholbach> tgardner, ok
[15:02] <ogra> tgardner, http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-linaro/
[15:02] <ogra> there it is
[15:02] <tgardner> ogra: wtf? why did it go there
[15:03] <cjwatson> armel is all on ports
[15:03] <ogra> tgardner, someone accepted it into main and its armel
[15:03] <zyga> is anyone here using GMA500 on maverick?
[15:03] <tgardner> cjwatson, its not ports that I'm questioning, it linux-linaro
[15:03] <cjwatson> well that's just the source package name somebody gave it
[15:04] <ogra> Changed-By: John Rigby <john.rigby@linaro.org>
[15:04] <ogra> Maintainer: Ubuntu Kernel Team <kernel-team@lists.ubuntu.com>
[15:04] <ogra> Signed-By: Tim Gardner <tim.gardner@canonical.com>
[15:05] <ogra> tgardner, well, you apparently signed it :)
[15:05] <tgardner> cjwatson, ok, I get it now. it follows the source package name. guess I should have figured that out.
[15:14] <nigelb> bdrung: OMG, you're fast.
[15:15] <nigelb> I just saw a debdiff uploaded within 45 minutes of posting.
[15:15] <bdrung> nigelb: i am always fast :P
[15:15] <nigelb> Even before I could catch up with the mail trail ;)
[15:15] <nigelb> bdrung: Now I know :D
[15:16] <bdrung> nigelb: your debdiff for karmic needs a refresh and sponsor-patch should not pull a version from -backports
[15:17] <nigelb> bdrung: wait, It should \sh gave a new debdiff?
[15:18] <nigelb> ah, that was for lucid.
[15:18] <nigelb> ok, I'll try to get to it.
[15:42] <highvoltage> sabdfl: hi! any chance on choosing a name for 11.04 soon? it's getting to that part in the release cycle where people are writing maverick+1 a lot :)
[15:51] <\sh> nigelb: what?
[16:02] <\sh> bdrung: thanks for sponsoring
[16:06] <bdrung> \sh: yw
[16:48] <kirkland> pitti: ping
[17:01] <nigelb> \sh: um, sorry about the ping. It was about the debbootstrab bug for which you uploaded debdiff for sru.
[17:05] <soren> I'm still wondering about my user-mode-linux ftbfs in lucid-proposed. An identical build in my ppa worked flawlessly. Is there any reason whatsoever why an amd64 buildd would report a 32 bit personality?
[17:05] <cjwatson> *blink* cosmic rays?
[17:05] <cjwatson> not that I can think of, maybe check with lamont
[17:05] <soren> It did it twice.
[17:05] <soren> The only way I can get it to fail in a similar way for on my local box is by prefixing dpkg-buildpackage with linux32.
[17:06] <soren> lamont: Any clues at all?
[17:06] <soren> https://edge.launchpad.net/ubuntu/+source/user-mode-linux/2.6.32-1um-3ubuntu3.1/+build/1922058 <---- the build in question
[17:07] <chrisccoulson> soren - it's funny you should mention that, as i've just started getting loads of weird build failures on amd64 for all of the mozilla daily builds
[17:07] <soren> chrisccoulson: Fascinating.
[17:07] <chrisccoulson> things like this - http://launchpadlibrarian.net/53843956/buildlog_ubuntu-maverick-amd64.firefox_3.6.9~hg20100817r34534%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
[17:07] <soren> chrisccoulson: On all buildd's or just..
[17:07] <lamont> soren: interesting as all get out
[17:07] <chrisccoulson> soren - on everything, on all releases
[17:07] <lamont> in fact, i386 builds are frequently done on amd64 kernels, with linux32 in front of things
[17:07] <chrisccoulson> soren - https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+packages
[17:07] <soren> lamont: This is an amd64 build.
[17:07] <chrisccoulson> all todays builds failed :(
[17:08] <soren> chrisccoulson: Even in the PPA?
[17:08] <cjwatson> there was some chatter about repurposing some amd64 PPA buildds as i386; I smell a rat
[17:08] <chrisccoulson> soren - yeah, these are all PPA builds
[17:08] <soren> chrisccoulson: Ah, I see.
[17:08] <lamont> sh: gcc: not found
[17:08] <lamont> dpkg-architecture: warning: Couldn't determine gcc system type, falling back to default (native compilation)
[17:08] <lamont> I  don't like that much
[17:08] <cjwatson> that always happens, doesn't it?
[17:08] <elmo> yes, it does
[17:08] <soren> I thought so too. It didn't raise an eyebrow.
[17:08] <cjwatson> I thought that was an artifact of something being run outside the chroo
[17:08] <soren> Ok.
[17:08] <cjwatson> t
[17:08] <seb128> that's not new for sure
[17:09] <lamont> true
[17:09] <\sh> nigelb: I didn't do the karmic one...cause I didn't have a karmic sbuild right now
[17:09] <lamont> the machine clearly thinks it's amd64...
[17:10] <nigelb> \sh: I know.  bdrung has asked me to refresh it a bit :)
[17:10] <soren> Kernel build from 10 hours ago worked fine. My initial build that failed was from 6-7 hours ago. Did anything change roughly in that timeframe?
[17:11] <\sh> nigelb: cool...
[17:11]  * soren does an experiment
[17:11] <lamont> soren: I assume MCORE2 is 64-bit, yes?
[17:11] <\sh> now gone from office
[17:11] <bdrung> nigelb: i would have refreshed it, but sponsor-patch pulls the wrong version. i need to fix this first.
[17:11] <soren> lamont: It supports both.
[17:11] <chrisccoulson> cjwatson - checking target system type... i686-pc-linux-gnu
[17:11] <chrisccoulson> checking build system type... x86_64-pc-linux-gnu
[17:11] <chrisccoulson> :/
[17:11] <soren> err.. obviously.
[17:11] <nigelb> bdrung: heh, trying to fix one bug exposes another.  Normal :)
[17:12] <bdrung> nigelb: it's unrelated. it's the first package i touch that had a backport
[17:12] <soren> lamont: CONFIG_MCORE2 is set by the config. It chooses the config based on dpkg --print-architecture (which, incidentally perhaps, is unaffected by personality).
[17:13] <nigelb> bdrung: Ah, cool :)
[17:13] <lamont> well, and crested is amd64 with an amd64 chroot, so shouldn't matter
[17:14] <bdrung> nigelb: do you have the bug number at hand?
[17:15] <soren> lamont: Unless something accidentally runs it with linux32.
[17:16] <lamont> soren: the last thing I'm aware of that has even a remote chance of having affected it happened on crested 20 hours ago
[17:16] <soren> lamont: Can you bump the build score of this: https://edge.launchpad.net/~soren/+archive/ppa/+build/1922960 ?
[17:16] <lamont> and everywhere else about the same time
[17:16] <soren> lamont: It's a bit of an experiment.
[17:16] <soren> lamont: And what would that be?
[17:17] <lamont> Start in 1 minute (55555555)
[17:17] <lamont> lp-buildd upgraded
[17:17] <soren> Wow.
[17:17] <soren> I feel so special.
[17:17] <lamont> OTOH, changes were all elsewhere
[17:17] <lamont> string of 5's is my "special" value.
[17:20] <nigelb> bdrung: 533369
[17:20] <nigelb> bdrung: bug 533369
[17:20] <bdrung> nigelb: thx
[17:21] <soren> Aha!
[17:21] <soren> Linux promethium 2.6.24-27-xen #1 SMP Wed Mar 24 12:56:18 UTC 2010 i686 GNU/Linux
[17:21] <soren> from the amd64 build.
[17:21] <soren> (output of uname -a)
[17:21] <soren> lamont: ^
[17:21] <soren> i686 == bad
[17:21] <soren> :)
[17:22] <chrisccoulson> so, that will be why all my builds fail then ;)
[17:22] <soren> Indeed.
[17:22] <chrisccoulson> phew :)
[17:22]  * chrisccoulson wipes brow
[17:24] <lamont> neat
[17:25] <soren> Maybe the kernel got lucky, because it specifically passes an ARCH value.
[17:25] <soren> user-mode-linux's ARCH setting is "um", the SUBARCH is detected from uname -m.
[17:26]  * lamont yanks the rug out from under promethium, investigates
[17:26] <slangasek> cjwatson: well, it's rather a long window to freeze all security updates, and in the past I thought we did handle this as freezing -updates publishing only since the relevant question is whether we have the source to reproduce the images?  or maybe I've not accurately understood the purpose of the archive snapshot
[17:27] <cjwatson> slangasek: I may be wrong; I suspect there is room for process refinement ...
[17:27] <soren> lamont: I doubt it's specific to promethium. If you're just picking a random one for investigation, that's cool, but I'm seeing the same on crested and chrisccoulson had it happen on a bunch of different ones.
[17:27] <soren> lamont: just sayin'.
[17:28] <lamont> yeah - just picking a random known place
[17:28] <lamont> and I have my suspicion
[17:29] <hallyn> so i've got a bzr branch that i had proposed for merge, and the relevant commits were in fact merged into lucid-proposed.  But the tree is still listed as pending merge.  Shoudl I cancel the merge request, or leave that until it gets from lucid-proposed into lucid-updates?
[17:30] <soren> lamont: Lovely.
[17:30] <soren> chrisccoulson: Thanks for chiming in. I would have stared at this for hours thinking it was local to this package.
[17:31] <soren> chrisccoulson: Or days, even.
[17:31] <lamont> soren: so...  I've put all of amd64 on manual for a little bit while I do somemore investigating.
[17:31] <lamont> since all around, feh.
[17:31] <chrisccoulson> soren - heh, you're welcome ;)
[17:31]  * soren is stubborn with stuff like this
[17:31] <chrisccoulson> i probably also would have spent a long time looking at it if cjwatson didn't suggest what the issue might be ;)
[17:32] <soren> chrisccoulson: What? Cosmic rays? :D
[17:32] <cjwatson> we might need to look into the possibility that there have been misbuilds
[17:33] <lamont> cjwatson: verily
[17:34] <hallyn> rephrase:  does a merge proposal need to stay open for commits to propagate from lucid-propsoed to lucid-updates?  Or will that happen (barring regressions/objections) regardless?
[17:34] <cjwatson> the merge proposal doesn't need to stay open for that
[17:34] <hallyn> cjwatson: thanks
[17:35] <cjwatson> if it's been (effectively) merged into its target branch, you can mark it as merged
[17:38] <hallyn> cjwatson: don't see how to do that in the lp bzr page (need some special privs?) but i've deleted the proposal, so hopefully all's good
[17:38] <cjwatson> that should be fine
[17:39] <hallyn> (though then it always lists as 'supserseded' for merge...  weird)
[17:44] <mih1406> Hi, I am learning C++/Qt and want to switch to GTK
[17:45] <mih1406> What are the packages that I need as a C++/GTK developer?
[17:45] <SpamapS> hallyn: you can just change the status to "Merged", can't you?
[17:45] <mih1406> I do not want GTK+, I want GTKmm. But I do not know which packages I need?
[17:45] <cjwatson> mih1406: libgtkmm-2.4-dev is the primary one, and you'll probably want libgtkmm-2.4-doc too
[17:45] <cjwatson> (apt-cache search gtkmm)
[17:45] <hallyn> SpamapS: where?
[17:46] <mih1406> Is there a documentation for GTKmm packaged?
[17:47] <lamont> soren: version bump and re-upload your testpackage, give me the build record pls?
[17:47] <lamont> assuming it built successfully rather than failing, that is
[17:47] <soren> lamont: 2 seconds.
[17:47] <soren> lamont: https://edge.launchpad.net/ubuntu/+source/user-mode-linux/2.6.32-1um-3ubuntu3.1/+build/1922058
[17:48] <soren> lamont: Just rebuild that one.
[17:48] <cjwatson> mih1406: libgtkmm-2.4-doc
[17:48] <lamont> sure
[17:49] <soren> Heh. Launchpad has apparantly given up guessing when it'll build :)
[17:49] <lamont> 0 builders
[17:49] <soren> Ah, of course.
[17:50] <soren> lamont: That's not a PPA build, by the way. Don't know if you noticed or it matters at all.
[17:51] <mih1406> cjwatson: libgtkmm-2.4-dev requires many packages!!
[17:51] <lamont> aborted all the currnetly-running amd64 builds
[17:51] <mih1406> Are they important?
[17:51] <lamont> soren: yeah, no worries
[17:52] <mih1406> 57 packages!
[17:52] <cjwatson> mih1406: yes, they're part of the interface
[17:52] <cjwatson> mih1406: (how much time do you want to spend second-guessing dependencies, versus getting on with your work? :-) )
[17:53] <mih1406> "second-guessing" ??
[17:54] <soren> "questioning".
[17:54] <soren> Sort of.
[17:55] <mih1406> sorry for that
[18:00] <lamont> mih1406: 100+ packages for build-depends is not a rare situation.  just fyi
[18:04] <bilalakhtar> cjwatson: as for the meeting time problem, do you suggest earlier or later?
[18:05] <mih1406> I want to develop in C++ and GTKmm what are good tools for that?
[18:06]  * jdong would be tempted to suggest a waterproof laptop and large amounts of vodka
[18:07] <cjwatson> bilalakhtar: I plan to suggest both and see what people like
[18:07] <bilalakhtar> cjwatson: well, my opinion doesn;t count that much, but I would say, early
[18:08] <cjwatson> bilalakhtar: it will have to be something that the board members can consistently make
[18:09] <bilalakhtar> cjwatson: yup, it appears persia is in a very eastern time zone, so for persia it would also be 'early'
[18:09] <soren> lamont: Perhaps I should come up with a quicker test case :)
[18:09] <soren> lamont: There it goes.
[18:09] <soren> lamont: It works.
[18:09] <SpamapS> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel - "Open to all to subscribe, posting moderated for people who are not Ubuntu developers" ...
[18:09] <soren> lamont: It wouldn't have made it this far if it still failed.
[18:09] <SpamapS> Maybe its asking too much, but there seems to be no manpower behind said moderation.
[18:10] <lamont> cjwatson: 13 suspect builds, 12 if you ignore soren's lum build
[18:10] <SpamapS> Which, I know as an aspiring ubuntu developer, is fairly frustrating if you'd like to weigh in on anything. :-/
[18:10] <cjwatson> bilalakhtar: OTOH push it much earlier and it's painful for USians
[18:10] <cjwatson> or Americans in general
[18:10] <cjwatson> always difficult
[18:10] <bilalakhtar> cjwatson: yup
[18:10] <cjwatson> SpamapS: I just did a partial moderation pass ...
[18:10] <bilalakhtar> with a developer community that huge its difficult to find the right time
[18:11] <cjwatson> SpamapS: I wouldn't object to more help, it's me + ev right now
[18:11] <SpamapS> cjwatson: You've been amazing at moderation. But I think you have quite a few things that count as higher priority on your plate. :)
[18:11] <cjwatson> though I do think moderators should be core-dev
[18:12] <cjwatson> I don't think I can claim to be an amazing moderator, no
[18:12] <SpamapS> I'm not saying I expect instant moderation. But the lag time for emails I've sent to ubuntu-devel has been 7-10 days since subscribing in June.
[18:12] <lamont> soren: awesome.  time to go roll all the amd64 builders around
[18:13] <soren> lamont: Care to share the gory details?
[18:13] <cjwatson> bilalakhtar: we may just need to rotate or something
[18:13] <bilalakhtar> cjwatson: yup
[18:13] <bilalakhtar> bye, people
[18:13] <soren> cjwatson: I'm sure I've mentioned it before, but 4 in the morning is a better time for me than the current one.
[18:14] <SpamapS> cjwatson: I hate being a complainer when much of the work is in fact volunteer, so please feel free to tell me to stuff it and just concentrate on development. ;)
[18:14] <cjwatson> no, complaints are good reminders
[18:14] <lamont> soren: only under duress
[18:14] <soren> lamont: :)
[18:14] <soren> Oh, well, good times. It works now, I'm happy.
[18:15] <soren> lamont: Thanks for looking into it so quickly.
[18:15] <lamont> soren: at this point, the 12 affected builds (1) might not be completely accurate, and (2) all I have is build ids.. working on getting actual URLs/package/version/archive info for them
[18:15] <soren> lamont: How do you determine whether they're affected?
[18:16] <lamont> any amd64 build "first dispatched" since 20:00:00 UTC yesterday
[18:16] <soren> There's only 12 of those? Wow.
[18:17] <lamont> I think we looked at builds launched since then, and found that none had been not first dispatched since then, but started.
[18:17] <lamont> soren: 13 with you.
[18:17] <lamont> this is a happiness
[18:18] <lamont> or at least a lesser sadness
[18:18] <soren> Yeah, 12 builds are certainly a manageable set to have to rebuild.
[18:19] <soren> Of course, this is only counting ubuntu proper, right? Not PPA's?
[18:19] <lamont> all of lp, I believe
[18:19] <micahg> I have 30 builds amd64 builds that FTBFS last night
[18:19] <lamont> though I'm suspcious
[18:19] <lamont> so make that "yeah, that doesn't include ppa", i fear
[18:19] <cjwatson> micahg: we only really need to worry about the ones that succeeded
[18:19] <soren> I have had 10 in the last 20 hours, I'm sure.
[18:19] <cjwatson> the rest can be given back en masse
[18:20] <micahg> cjwatson: ah, ok
[18:20] <lamont> cjwatson: exactly.  the successes are the ones that worry me
[18:22] <lamont> yellow fixed, and back in the game.  now for some ppa fun
[18:22] <ari-tczew> cjwatson: ping for private message
[18:31] <bdrung> nigelb: done
[18:32]  * nigelb hugs bdrung :)
[18:34] <bdrung> nigelb: you're welcome.
[18:36] <bdrung> seb128: your glib 2.25.14-1ubuntu1 upload: "Resync on Debian". is it a sync or a merge?
[18:37] <seb128> bdrung, it's a "grab the diff for the other upload listed in the change and apply that to ubuntu and upload"
[18:37] <seb128> ie not bothering to merge again, just applying a debian revision
[18:37] <seb128> bdrung, why?
[18:38] <bdrung> seb128: sync means to me same version. then it's just a merge without stating the remaining changes
[18:38] <seb128> bdrung, it's not a merge, it's backporting a debian change
[18:39] <bdrung> looking at https://launchpad.net/ubuntu/+source/glib2.0/2.25.14-1ubuntu1/+build/1922843 - some package build will be broken for two days
[18:39] <seb128> ?
[18:39] <bdrung> seb128: aha, ok
[18:39] <bdrung> seb128: "Start 2010-08-19"
[18:39] <seb128> right, read backlog
[18:39] <seb128> I think amd64 builders are under work
[18:40] <bdrung> seb128: can you give me a time for the backlog?
[18:41] <bdrung> s/time/start time/
[18:41] <seb128> bdrung, 1:10 ago where lamont and soren and chrisccoulson were discussing
[18:44] <lamont> seb128: interestingly, that build wasn't listed as one of the affected - had you given it back before I finished that bit?
[18:45] <lamont> seb128: that is, more than 26 min ago?
[18:46] <seb128> lamont, I didn't give it back but uploaded like 2 hours ago
[18:47] <lamont> that would fit
[18:47] <lamont> does it need a push?
[18:47] <lamont> or just when it lands is fine?
[18:48] <bdrung> lamont: the build blocks https://launchpad.net/ubuntu/+source/qemu-kvm/0.12.5+noroms-0ubuntu2 build on amd64
[18:58] <pgraner> kirkland, ping
[19:01] <kirkland> pgraner: yo
[19:02] <pgraner> kirkland, getting weird screen error message after todays update on maverick
[19:03] <pgraner> kirkland, using byobu for login
[19:03] <kirkland> pgraner: what's the error message say?
[19:04] <pgraner> pgraner@lenovo-T410:~$ ssh emerald.local
[19:04] <pgraner> Cannot make directory '/var/run/screen': Permission denied
[19:04] <pgraner> pgraner@emerald:~$
[19:04] <kirkland> pgraner: maverick, or lucid on emerald?
[19:05] <pgraner> kirkland, sorry emerald is lucid
[19:05] <kirkland> pgraner: okay, right, there's a fix in lucid-proposed
[19:05] <kirkland> pgraner: init race condition caused that problem for you
[19:05] <pgraner> kirkland, ack
[19:06] <kirkland> pgraner: you should be able to fix it in the mean time with "sudo service screen-cleanup start"
[19:06] <pgraner> kirkland, ack, thanks
[19:06] <pgraner> kirkland, just wanted to make sure you saw it
[19:08] <kirkland> pgraner: yup, thanks, you want the existing bug number?
[19:08] <pgraner> kirkland, nope, its in a proposed update I'm golden
[19:10] <kirkland> pgraner: cool, yeah, thanks.
[19:10] <djzn> when is 10.04.1 be out today, is it still some hope for today?
[19:18] <djzn> cjwatson: does 10.04.1 get release today (ISOs)...?
[19:20] <cjwatson> djzn: don't know yet
[19:31] <sebner> Glib uploads are nasty, it seems it broke empathy :P
[19:31] <sabdfl> highvoltage: http://www.markshuttleworth.com/archives/478
[19:32] <smoser> pitti, i updated bug 582667. could you check it again for lucid-proposed ?
[19:35] <sebner> seb128: meh, GLib-GIO-ERROR **: Settings schema 'org.freedesktop.Telepathy.Logger' is not installed
[19:37] <highvoltage> sabdfl: awesome :)
[19:39] <bdrung> i get an oops when i retry to build eclipse on i386 (https://launchpad.net/ubuntu/+source/eclipse/3.5.2-5/+build/1844712/+retry)
[19:40] <highvoltage> http://www.weebls-stuff.com/songs/Narwhals/
[19:41] <tonyyarusso> narwhal...awesome.
[19:41] <seb128> sebner, context?
[19:41] <sebner> seb128: <sebner> Glib uploads are nasty, it seems it broke empathy :P
[19:41] <seb128> lamont, sorry I was away, when it lands is fine
[19:41] <micahg> bdrung: well, it's scheduled anyways
[19:42] <seb128> sebner, works fine there
[19:42] <sebner> seb128: do you have latest glib updates installed?
[19:42] <seb128> sebner, yes, I tested it before uploading
[19:42] <sebner> meh
[19:43] <sebner> seb128: any advice what I can do?
[19:43] <seb128> sebner, ls /usr/share/glib-2.0/schemas/
[19:44] <sebner> seb128: uhh, http://pastebin.com/7JG8idba
[19:45] <tonyyarusso> (Say, anyone know if 10.04.1 is still on track for today?)
[19:45] <seb128> sebner, seems rather a bug in the telepathy-logger update then
[19:46] <sebner> hmm
[19:46] <sebner> ah, you where the uploader there too, fine
[19:46] <tonyyarusso> On a related note, high five to robbiew for interim release managing, and Kate on the new job - I wasn't aware until just now that slangasek had left the position.
[19:46] <sebner> seb128: it's not installed. needs a stronger dependency?!
[19:47] <seb128> sebner, I'm checking now, I just synced this one on Debian
[19:47] <tonyyarusso> (What's Kate's nick?  Is this someone I'll recognize?)
[19:47] <robbiew> tonyyarusso: running into a wubi bug, but hopefully we can workaround it
[19:47] <seb128> sebner, empathy recommends telepathy-logger weird
[19:47] <seb128> sebner, I guess it should be a depends
[19:47] <sebner> seb128: wasn't there some mail that recommends is not installed by default anymore? Btw, installing it fixes the problem
[19:47] <tonyyarusso> robbiew: ah, okay.  If the list is down to one bug that's getting pretty darn close, so I'll take that.
[19:48]  * tonyyarusso needs to wipe and reinstall a couple of systems, figured he might as well do it with a .1 image
[19:48] <seb128> sebner, no, the email was from Keybuk and about recommends not being installed on the buildds
[19:48] <sebner> ah Ic
[19:48] <slangasek> tonyyarusso: candidate images are up, feel free to test them and give us feedback? :)
[19:49] <seb128> sebner, empathy must have been working in a buggy way for you before without telepathy-logger
[19:49] <seb128> sebner, ie you probably didn't have any logging on chat history
[19:49] <sebner> seb128: I definately had
[19:50] <tonyyarusso> slangasek: I could do that - where?
[19:50] <tonyyarusso> just under dailies or something else?
[19:51] <slangasek> tonyyarusso: http://cdimage.ubuntu.com/lucid/
[19:51] <slangasek> tonyyarusso: or http://cdimage.ubuntu.com/ubuntu-server/lucid, or ../kubuntu/..
[19:52] <tonyyarusso> right, 'k
[19:52] <sebner> seb128: anyways, working now. thanks for you help :)
[19:52] <seb128> sebner, your're welcome
[19:52] <seb128> sebner, I will change the recommends to a depends
[19:52] <sebner> fine
[19:52]  * sebner hugs seb128 :)
[19:53] <seb128> ;-)
[19:53] <seb128> I'm still wondering why the recommends didn't work
[19:54] <sebner> seb128: I'm even more wondering because in the morning it was still working, now the day is over, installed all updates and it didn't start
[19:54] <sebner> and there was no empathy update
[19:55] <seb128> well you should have got telepathy-logger installed way before
[19:55] <seb128> you probably didn't have logging for all this time
[19:56] <sebner> seb128: as I said, I definately had logging before since I use this feature from time to time, but yes, it seems telepathy-logger was never installed before on this system
[19:56] <seb128> sebner, well logging was working until empathy stopped doing it in favor of telepathy-logger
[19:57] <seb128> which has been done some weeks ago now
[19:57] <sebner> seb128: telepathy-logger seems to be pretty new anyways, first upload was in june/july
[19:57] <seb128> right
[20:03] <lamont> cjwatson: it appears that there were no successful amd64/lpia builds during the period in question.
[20:05] <lamont> cjwatson: or maybe I'm misparsing things
[20:06] <seb128> lamont, should I be concerned about all the build failures on amd64?
[20:06] <seb128> lamont, or will you retry those after the buildds issues are solved?
[20:07] <lamont> buildd issues are solved.  it would help my current effort if you told me a couple of the builds in question, but didn't retry them yet.
[20:08] <lamont> and I have an eye appt that I'll need to leave for in about 25 min
[20:08] <lamont> seb128: ^^
[20:08] <lamont> (and right now, I don't care if it's ppa or non-ppa examples of the issue, pass or fail)
[20:08] <seb128>  * Build Log: https://launchpad.net/ubuntu/+source/gtksourceview2/2.10.4-1/+build/1922335/+files/buildlog_ubuntu-maverick-amd64.gtksourceview2_2.10.4-1_FAILEDTOBUILD.txt.gz
[20:08] <seb128>  * Build Log: https://launchpad.net/ubuntu/+source/telepathy-logger/0.1.5-1/+build/1922341/+files/buildlog_ubuntu-maverick-amd64.telepathy-logger_0.1.5-1_FAILEDTOBUILD.txt.gz
[20:09] <seb128>  * Build Log: https://launchpad.net/ubuntu/+source/libgnomekbd/2.31.5-0ubuntu2/+build/1922643/+files/buildlog_ubuntu-maverick-amd64.libgnomekbd_2.31.5-0ubuntu2_FAILEDTOBUILD.txt.gz
[20:09] <seb128> lamont, ^ some recent failures
[20:09] <seb128> bah
[20:09] <seb128> those are on glib installability issues sorry
[20:10] <micahg> lamont: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/1921965/+files/buildlog_ubuntu-maverick-amd64.firefox_3.6.9%7Ehg20100817r34534%2Bnobinonly-0ubuntu1%7Eumd1_FAILEDTOBUILD.txt.gz
[20:10] <lamont> yeah - I was going to say... they seem to predate the issue...
[20:10] <lamont> micahg: ta
[20:11] <micahg> lamont: there are 29 more in that PPA :)
[20:11] <lamont> jsregexp.cpp:4730: Error: operand type mismatch for `call' <-- that seems a bonafide failure, no?
[20:12] <lamont> also predates the rollout yesterday
[20:12] <micahg> sorry, that must have been different, I know I saw some
[20:12] <micahg> that's after 20:00 UTC yesterday
[20:13] <micahg> lamont: here's one: http://launchpadlibrarian.net/53842834/buildlog_ubuntu-karmic-amd64.xulrunner-2.0_2.0~b4~hg20100817r50707%2Bnobinonly-0ubuntu1~umd1~karmic_FAILEDTOBUILD.txt.gz
[20:13] <lamont> same ppa though?
[20:13] <micahg> lamont: yeah
[20:14] <lamont> micahg: I need the buildid, not the librarian URL
[20:14] <micahg> oh, ok
[20:15] <micahg> lamont: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/1921926
[20:15] <lamont> thanks
[20:15] <lamont> and most interesting.
[20:20] <lamont> micahg: is it ok if we leave that PPA alone until I get done figuring things out?
[20:20] <micahg> lamont: how long is that, a new round is scheduled for 4:30 UTC, but I can ask for it to be delayed
[20:21] <lamont> oh, uploading new stuff doesn't matter
[20:21] <lamont> I'm just asking that you specifically do not retry those builds
[20:21] <micahg> lamont: k, but they'll probably be superceded tonight, that's why I ask
[20:21] <micahg> at least some of them
[20:21] <lamont> yeah - superseded is fine
[20:22] <lamont> the new upload will get a new build record, so not my worry
[20:22] <micahg> lamont: k, I'll not retry and tell the others :)
[20:22] <lamont> thanks
[20:32] <pandora> hi guys, is 10.04.1 being released today?
[21:18] <kirkland> pgraner: you should be able upgrade that machine's screen to lucid-proposed now, if you like
[21:34] <jdstrand> soren: hey, so I am pretty sure vmbuilder isn't going to play well with libvirt 0.8.3
[21:35] <jdstrand> soren: libvirt now requires that you specify the disk format for disks. if none is specified, libvirt defaults to raw
[21:37] <jdstrand> soren: which is fine for raw disks, but it looks like vmbuilder a) defaults to qcow2 and b) doesn't specify the disk format, so the domain won't start
[21:38] <jdstrand> soren: basically, you need to add something like this:
[21:38] <jdstrand>     <disk type='file' device='disk'>
[21:39] <jdstrand>       <driver name='qemu' type='qcow2'/>
[21:39] <jdstrand>         <source file='...
[21:39] <jdstrand> err... that last 'source' didn't need to be indented
[21:54] <jdstrand> soren: actually, it seems vmbuilder has more problems than that... I suggest giving it a thorough testing
[21:56] <tonyyarusso> slangasek, robbiew: lucid candidate for i386 alternate installed and is up and running fine for me btw.
[21:57] <robbiew> tonyyarusso: thnx...we have a few cornercase windows-related testcases left...wubi and migration assistant
[21:57] <robbiew> figured a standard install would be fine ;)
[21:57] <tonyyarusso> Well, it's actually not *entirely* standard - I have it running on VMware ESXi, and connecting to it via XDMCP with Xming.
[21:58] <tonyyarusso> but yeah, no wubi nonsense here.
[22:37] <soren> jdstrand: Yeah, it's in dire need of love. I'll apply some very soon. I actually have a good excuse to spend work time on it now, as it happens.
[22:38] <jdstrand> \o/
[22:42] <sladen> jdong: empty package which Conflicts with something essential like  base-files  ?
[23:45] <ebroder> Hmm...is it normal to get the low-res, low-color plymouth splash when I have nvidia-current installed? Before when I was using the free drivers, I got a full-res splash
[23:46] <ebroder> (I'm doing this on a live USB with a persistent store, though, so it's not exactly a typical setup)
[23:46] <ion> Yes
[23:47] <ebroder> Broken configuration in the initrd?
[23:47] <ion> Broken driver
[23:47] <ebroder> Got it
[23:47] <ebroder> Does one of the other nvidia drivers work better?
[23:48] <ion> That is, they have yet to bother to support KMS. None of the proprietary nvidia or fglrx drivers do.
[23:48] <ebroder> Ah, got it
[23:57] <jdong> A neat side effect also seems to be prolonged blinking black cursor while ureadahead does its thing, and then a blink of a logo then gdm :)
[23:59] <ion> That’s intentional. Not that i like it. I proposed printing a simple line of text such as “Loading Ubuntu” or just “Ubuntu” while waiting for ureadahead, but the powers that be said no. :-)