[00:25] <ScottK> cjwatson: Since I don't know C++, there's no risk of me laughing.  Anyone else that wants to complain can write a 'better' patch.  I'll try and test it later tonight or tomorrow.  Thanks.
[02:33] <lamont> SpamapS: actually, I just cargo-culted the solution that was used in bind9 :)
[02:34] <lamont> that'll be in -2
[04:14] <pitti_> Good morning
[05:24] <mwhudson> hm, i guess upstart sends signals to the entire process group of a process started by 'exec ...' when you say "service $name stop"?
[05:33]  * mwhudson finds the setsid program
[07:53] <tkamppeter> pitti, ping
[08:03] <pitti> tkamppeter: pong
[08:13] <Sweetshark> moin!
[09:30] <seb128> @pilot in
[09:36] <fasta> I get mtrr: type mismatch for e0000000, 10000000 old: write-back new: write-combining.
[09:36] <fasta> I also set some option in make menuconfig which should work around that.
[09:36] <fasta> Except, it doesn't.
[09:36] <fasta> Does anyone know how to fix that?
[09:39] <tkamppeter> pitti, the CUPS repo is updated to use /var/cache/cups/ppd-updates to manage the updates now. Can you upload it to Debian and Ubuntu? Thanks.
[09:40] <pitti> tkamppeter: thanks; got your mail, will do ASAP
[10:07] <seb128> cjwatson, hi, could you have a look to https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/ifupdown/oneiric-201108091411/+merge/71877 when you have a moment? It seems that got dropped from the vcs when you did the merge on debian, should that be reapplied is or is deprecated in some way?
[10:08] <cjwatson> ok, I'll have a look, thanks
[10:09] <cjwatson> looks fine, I'll remerge
[10:16] <seb128> cjwatson, thank you!
[10:23] <pitti> james_w: is it possible to unbreak ubuntu:gvfs? it's out of date
[10:32] <pitti> tkamppeter: uploaded
[11:07] <seb128> slangasek, mvo:
[11:07] <seb128> lp:ubuntu/upstart
[11:07] <seb128> Most recent Ubuntu version: 1.3-0ubuntu6
[11:07] <seb128> Packaging branch version: 1.3-0ubuntu4
[11:07] <seb128> Packaging branch status: OUT-OF-DATE
[11:08] <seb128> just pointing it because I was reviewed https://code.launchpad.net/~jamesodhunt/ubuntu/oneiric/upstart/fixes-for-user-sessions/+merge/69125 from the sponsoring queue which got uploaded but the vcs is somewhat outdated
[11:22] <pitti> apw: hey Andy, how are you?
[11:22] <pitti> apw: do you have an opinion about bug 812394?
[11:22] <pitti> apw: I'm still fairly convinced that hibernation failures are mostly not correlated to the particular board/video card you are using, but much rather to partitioning/swap space/attached USB devices/memleaks/etc.
[11:23] <pitti> apw: do you know if there is some actual evidence that hibernation failures _are_ specific to a particular platform, and thus would benefit from a whitelist?
[11:36] <doko> cjwatson, slangasek: shouldn't the klibc symlink be part of multiarch-compat too?
[11:37] <cjwatson> uh, I'm not really sure what the goal of multiarch-compat is but I think libklibc-dev should be self-contained
[11:37] <cjwatson> if possible
[11:38] <cjwatson> siretart: can I apply http://lists.libav.org/pipermail/libav-devel/2011-August/009825.html in Ubuntu?
[11:38] <cjwatson> siretart: I noticed it while porting xvidcap
[11:45] <fasta> Is there anyone anywhere who understands mtrr in detail?
[11:47] <fasta> I have the latest BIOS, latest kernel and still I get an error message I get mtrr: type mismatch for e0000000, 10000000 old: write-back new: write-combining.
[11:47] <fasta> There are soms posts on the ubuntu forums which say they have a 'work around', but generally people on the forums don't really know what they are talking about... so.
[11:48] <fasta> Also, this is from 2006: http://ubuntuforums.org/showthread.php?t=115104
[11:48] <fasta> I'd hoped that such an issue would have been fixed in 2011.
[11:51] <siretart> cjwatson: in principle yes. usually, the build system experts respond quite quickly, and I'd prefer to backport patches from trunk, so I'd personally wait until tomorrow or so.
[12:00] <cjwatson> siretart: ok, thanks
[12:18] <apw> pitti, i am unsure if i have that information.  cirtainly suspend is normally broken cause of driver suspend failures (ie specific h/w not suspending) or bios problems when resuming
[12:19] <apw> pitti, for hibernate i would expect a large amount if not being able to hibernate are caused by the driver suspend issues
[12:19] <pitti> apw: that's right, but that shoudn't affect hibernation?
[12:19] <pitti> does hibernation suspend the hw?
[12:48] <seb128> @pilot out
[13:13] <OdyX> tkamppeter: pong.
[13:18] <aram> hi. I need some help with building a package (never used source packages before). basically I want to build python2.7 with an additional patch. I did an apt-get source python2.7 and I have rebuilt it with pbuilder (to test the tools).
[13:19] <aram> but I don't understand where should I put my patch and how to make the .deb package compile using an additional compile option.
[13:19] <aram> I see a lot of patches in the debian subdirectory, but those seem to have a different purpose.
[13:20] <aram> so what's the next step after apt-get source? applying the patch manually to the source (not as a debian patch)?
[13:21] <azeem_> aram: why do you think the patches in the debian subdirectory serve a different purpose?
[13:22] <azeem_> or rather, what's the purpose of your patch?
[13:22] <aram> this patch brings dtrace support to python.
[13:22] <aram> the patches in the debian subdirectory seem patches of patches.
[13:22] <aram> at least the ones I looked at.
[13:22] <azeem_> patches of patches?
[13:23] <azeem_> did you look at the diff.gz?
[13:23] <aram> yes, at diff.gz
[13:23] <azeem_> or the unpacked source?
[13:23] <aram> no, diff.gz
[13:23] <azeem_> well, then sure, a patch inside the .diff.gz would look like a patch of patch
[13:23] <azeem_> as the .diff.gz is a patch in itself
[13:24] <ahasenack> hey guys, is this a new/old way of distributing a debian source package? https://launchpad.net/ubuntu/+source/python-venusian/0.9-1 I don't see a diff, but a "debian" tarball which has the debian/* contents
[13:24] <azeem_> ahasenack: that's the new way
[13:24] <StevenK> ahasenack: It's a new way
[13:24] <azeem_> (dpkg-source -v3)
[13:24] <ahasenack> oh
[13:24] <aram> azeem_: okay, thanks, that seem right. so, after I make sure my patch works, I just put it in that subdirectory?
[13:25] <ahasenack> ok, thanks
[13:25] <ahasenack> StevenK: does it work in lucid?
[13:25] <ahasenack> this format
[13:25] <azeem_> aram: depending on the patch system, you might have to register it somewhere
[13:25] <ahasenack> I guess so, because dpkg-source -x worked just fine for me when I gave it that package
[13:25] <mterry> james_w, can you kick deja-dup's DD branch?  it's pretty out of date
[13:26] <aram> this patch also makes a new --with-dtrace compile time option that needs to be on.
[13:26] <aram> I guess I need to specify that somewhere.
[13:26] <jtaylor> aram python2.7 uses quilt to patch
[13:26] <azeem_> aram: in debian/rules usually
[13:27] <cjwatson> ahasenack: it should work back to intrepid (but not hardy)
[13:27] <ahasenack> cjwatson: cool, thanks
[13:27] <jtaylor> quilt import your-patch should be fine if it does not conflict with the rest of the patches
[13:27] <cjwatson> I tend to use quilt new and quilt fold
[13:27] <cjwatson> but ymmv
[13:28] <aram> so what do I start from, the directory that apt-get source generated (this contains the debian subdirectory) or a vanilla unpack of orig.tar.gz? (I guess the directory from apt-get source, but I want to be sure.)
[13:29] <cjwatson> the former
[13:29] <cjwatson> otherwise you have to redo all the packaging work yourself which will be a big pile of no fun with a cherry on top
[13:30] <aram> yeah, that makes sense.
[13:31] <aram> one I'm done with this I'd also have to package dtrace for Linux else this would be useless.
[13:32] <aram> the thing with dtrace for linux is that it needs to be recompiled every time with a kernel update (just like nvidia drivers, I guess).
[13:32] <cjwatson> dkms is probably your friend
[13:35] <aram> aah, one more thing I don't understand. the source directory generated by apt-get source contains the vanilla source or it already has applied the patches in debian subdir?
[13:35] <azeem_> aram: dpkg-source should tell you during unpack
[13:35] <azeem_> for v3 source packages, the default is to apply the patches
[13:37] <aram> ok, it applied the patches.
[13:39] <jtaylor> its a v1 source so they are not applied, also it uses a quite interesting method to generate the quilt series, see line 1011 of debian/rules
[13:41] <cjwatson> line 1011 of debian/rules> bad sign in itself
[13:42] <cjwatson> although python2.7 may have a good excuse :-)
[13:42] <cjwatson> but usually it means "you might have to be pretty familiar with Debian packaging to go anywhere near this"
[13:43] <azeem_> it's better than "see line 1011 of automake.mk in cdbs"
[13:43] <james_w> mterry, it looks like there's a filename in the tree that bzr can't handle. That seems odd as it's hosted in bzr isn't it?
[13:45] <mterry> james_w, upstream is yeah
[13:47] <james_w> mterry, that's odd then. Is there anything in the source package that could cause this? Perhaps a non-ascii filename used in testing that found its way in to the source package at some point?
[13:48] <mterry> james_w, no, I don't think so...  maybe...  I think soyez used to make deja-dup.pot files with accents
[13:48] <mterry> or not soyez, but the build process
[13:48] <james_w> that could be it then
[13:49] <james_w> anyway, this isn't something that I can fix right now I don't think
[13:51] <james_w> https://bugs.launchpad.net/udd/+bug/831189
[14:00] <smoser> @pilot in
[14:04] <kirkland> any idea why firefox is acting up in oneiric (been that way for 4 days now);  goes grey/dark for  60s at a time
[14:05] <davmor2> kirkland: run top normally that means excessive memory / cpu usage
[14:07] <soren> davmor2: By firefox? Impossible! </sarcasm>
[14:07] <Laney> doko: can you please get your ghc changes to Debian? I'm a bit disappointed because we were going to be able to sync it next time (and that patch looks like it will make the merge annoying)
[14:08] <davmor2> soren: :D
[14:09] <doko> Laney, yes, I can do this, but we'll have a delta with --as-needed anyway
[14:10] <RoAkSoAx> kirkland: that's probably compiz's fault
[14:10] <Laney> indeed, but as long as it's manageable I can live with that
[14:10] <doko> I did want to wait until ld defaults to --no-add-needed
[14:10] <Laney> is that likely to happen soon?
[14:10] <doko> yes
[14:10] <Laney> if before P opens then I can live with waiting, too
[14:11] <doko> hopefully this week
[14:11] <Laney> ok
[14:18] <smoser> stgraber, around ?
[14:19] <stgraber> smoser: yep
[14:19]  * kirkland goes to u2d
[14:19] <smoser> could you please take a quick look at https://code.launchpad.net/~vanvugt/ubuntu/natty/bcmwl/fix-793890/+merge/67294 ?
[14:20] <smoser> it really seems ready to go to me.  you NAK'd it last time but I think its ready.
[14:22] <stgraber> smoser: I guess it'd be fine if you take lp:ubuntu/natty/bcmwl, manually copy the changes from his branch, fix the version number and push that
[14:22] <stgraber> it'll be a mess if you just merge it to -proposed and push it
[14:22] <smoser> stgraber, well you should push to -proposed
[14:22] <smoser> or just upload and let the importer handle it
[14:22] <stgraber> as it'll re-create a tag for a release that as far as Launchpad is aware "never existed"
[14:23] <smoser> stgraber, regarding tag in -proposed, if the importer fails, then it is really a bug in the importer as this is a very real world case.
[14:23] <stgraber> so the importer will either fail or just overwrite anything in the branch. I guess I'll push that on wednesday when I'm piloting
[14:24] <stgraber> smoser: well, IIRC in this specific case, the -proposed branch shouldn't exist, so you shouldn't be able to merge anything
[14:24] <smoser> the -poroposed *should* exist
[14:24] <smoser> as it there *was* such a version.
[14:24] <smoser> and the importer correctly found it, merged it, then it was removed from -proposed.
[14:24] <smoser> and never made it to -updates.
[14:25] <stgraber> yeah, and in such case, I'd expect the branch to be removed by the importer, which apparently isn't the case
[14:25] <smoser> well the only thing bad about it is the tag.
[14:25] <smoser> the rest would be fine.
[14:26] <stgraber> so now if we want the importer to be happy with the branch we should either just push it and let the importer destroy the branch and create it again or drop the old commit and push the new one instead (making sure to update the tag and everything)
[14:26] <stgraber> but yeah, I'm happy to have a look at it on Wednesday
[14:29] <smoser> mdeslaur, https://code.launchpad.net/~psusi/ubuntu/natty/gnome-power-manager/fix-duplicate-battery/+merge/67466 should be marked "merged" ?
[14:31] <mdeslaur> smoser: yes, but I don't have permissions to do so
[14:31] <smoser> hm.. me neither.
[14:31] <smoser> thanks.
[14:32] <mdeslaur> smoser: np
[14:52] <doko> pitti, bryceh: any chance to look at the xvfb issues?
[15:18] <kirkland> RoAkSoAx: hmm, i moved to unity2d, same problem in firefox
[15:22] <RoAkSoAx> kirkland: that's weird then, I used to see that all the time when compiz enabled for some weird effect for ages now
[15:27] <RoAkSoAx> cjwatson: howdy! I'm wondering if there's an issue with the mini ISO'
[15:28] <RoAkSoAx> cjwatson: howdy! I'm wondering if there's an issue with the mini ISO's since I'm trying to PXE boot and complains that cannot find kernel modules for kernel 3.0.0-5 in the archive
[15:30] <cjwatson> RoAkSoAx: what URL are you using?
[15:31] <ahasenack> can I use substvars to set a Build-Depends field in debian/control?
[15:32] <cjwatson> ahasenack: no
[15:32] <ahasenack> just checking before I debug further
[15:32] <OdyX> ahasenack: the Build-Depends field is read before any debian/rules processing, so no.
[15:32] <ahasenack> ah ;(
[15:32] <ahasenack> that would explain it
[15:32] <kirkland> RoAkSoAx: i've move to chromium for a bit, seems slightly less crappy
[15:32] <OdyX> (you could do some control{,.in} dance, but it's often not error-prone)
[15:32] <ahasenack> I was trying to get build-depends set correctly depending on the ubuntu release
[15:32] <ahasenack> I guess I will have to play with "|" a bit then, see if it works
[15:33] <cjwatson> there often isn't a particularly good way to do that - sometimes | works but you may just have to have slightly different source packages
[15:40] <RoAkSoAx> kirkland: it is
[15:40] <RoAkSoAx> cjwatson: I'm importing a mini ISO into cobbler
[15:40] <kirkland> RoAkSoAx: could you get powernap building again in the ppas?
[15:40] <RoAkSoAx> cjwatson: but have manually grabbed the initrd.gz and linux from http://archive.ubuntu.com/ubuntu/dists/oneiric/main/installer-i386/current/images/netboot/ubuntu-installer/i386/
[15:40] <RoAkSoAx> kirkland: yeah I didn't know it was failing and it is due to the change to dh_python2 I believe
[15:41] <kirkland> RoAkSoAx: hmm, okay, could you get that fixed up?
[15:41] <kirkland> RoAkSoAx: i wanted to try the new powernap on my lucid servers here at home
[15:41] <RoAkSoAx> kirkland: will sure though, I think we'll have to keep a different branch for the packaging for maverick/lucid
[15:43] <kirkland> RoAkSoAx: or, can't you just pocket copy the deps into the archive?
[15:43] <kirkland> RoAkSoAx: or do we have to use dh_python2?
[15:46] <fasta> I get init: udev-fallback-graphics main process (777) terminated with status 1
[15:46] <ahasenack> how can I build-depends for dh_python2, just the python version?
[15:46] <RoAkSoAx> kirkland: for oneiric+ dh_python2 is the way to go
[15:47] <fasta> What does that mean exactlly?
[15:47] <fasta> exactly*
[15:47] <RoAkSoAx> kirkland: preferably natty as well but dont worry I'll get that fixed ;)
[15:49] <SpamapS> lamont: excellent. :)
[15:51] <kirkland> RoAkSoAx: coolio
[15:51] <kirkland> RoAkSoAx: thanks!
[15:52] <cjwatson> RoAkSoAx: sounds like you've got an obsolete copy
[15:52] <kirkland> RoAkSoAx: i think the easiest would be to get the right python stuff copied to the powernap archive
[15:52] <cjwatson> RoAkSoAx: the current images there are built against 3.0.0-9
[15:52] <cjwatson> ahasenack: http://wiki.debian.org/Python/TransitionToDHPython2 should help
[15:53] <RoAkSoAx> cjwatson: yeah that's why I was wondering if the ubuntu mini iso's are being built against an older linux kernel version, as I have downloaded it today, set my PXE server here, and still its complaining about it
[15:55] <cjwatson> RoAkSoAx: no, they're built against current, maybe you have a "transparent" web proxy in the way
[15:57] <RoAkSoAx> cjwatson: I do, though I have cleaned the cache and still get the errors. will try without though it and will let you know
[15:57] <cjwatson> RoAkSoAx: I'm pretty certain this isn't an archive problem
[15:58] <RoAkSoAx> cjwatson: ok cool, will verify without using the proxy, thanks ;)
[16:35] <cnd> @pilot in
[16:58] <directhex> pitti, for submitting new info to media-player-info, is it better to create a new entry for the hp pre 3, or add its usb id to the existing entry for the original palm pre?
[17:21] <cnd> who do I ask about lp:ubuntu/gvfs not being up to date?
[17:21] <cnd> I know I've asked this before, but I can't remember...
[17:24] <jtaylor> there was an update 6 hours ago
[17:24] <jtaylor> 1.9.3 not new enough?
[17:25] <cnd> jtaylor: hmmm, that's not what I see at https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/gvfs/oneiric
[17:25] <cnd> the top revision I see is156. By Sebastien Bacher on 2011-04-15
[17:25] <cnd> releasing version 1.8.0-0ubuntu2
[17:26] <jtaylor> oh the branch, no idea about that
[17:27] <cnd> ok
[17:32] <seb128> could a buildd admin bump the build scores for https://launchpad.net/~unity-team/+archive/compiz-testing/+builds?build_state=pending ?
[17:35] <smoser> could someone file bug 831512 against the right package ? I'm not sure what the right package would be.
[17:35] <smoser> seb128, i'm assuming you know, and you just spoke here, so unlucky for you.
[17:35] <slangasek> SpamapS: can you look at the lp:ubuntu/upstart branch which seems to be missing some of your changes?  (cf seb128's comments above)
[17:36] <slangasek> doko: I'm not aware of any reason multiarch-compat needs klibc symlinks?
[17:37] <seb128> smoser, overlay-scrollbar?
[17:37] <smoser> um... maybe ? look at screenshot . i'm not even cluefull enough to know the term "overlay scrollbar"
[17:37] <doko> slangasek, that was for the rootskel build failure in the test rebuild
[17:38] <SpamapS> slangasek: it got all weird because of the missing upstream.. I think we can import-dsc safely now.
[17:39] <slangasek> doko: I thought we had already fixed the code in klibc's compiler wrapper to do the right thing for multiarch, though
[17:41] <seb128> doko, could you bump the builds on https://launchpad.net/~unity-team/+archive/compiz-testing/+builds?build_state=pending ?
[17:43] <doko> seb128, done
[17:43] <seb128> doko, thanks
[17:43] <slangasek> SpamapS: please do then :)
[17:46] <stgraber> ScottK: hey! If you have a sec, can you look at http://paste.ubuntu.com/672611/ ? It's the buildlog for iTalc, I'm not too sure what's the problem there :) (as it's qt-related I figured you may know what's going on there)
[17:47] <jelmer> cyphermox: ping
[17:47] <ScottK> stgraber: Not looking in the multiarch paths?
[17:48] <cyphermox> jelmer: pong
[17:48] <ScottK> It found the headers and stuff so it's at least partly working.
[17:49] <stgraber> ScottK: hmm, that could be the problem indeed. I assumed it was having a problem finding the headers but it's indeed more likely it's failing to find the library itself
[17:49] <jelmer> cyphermox: I've updated the evolution-mapi MP. Do you think you'll have time to sponsor an upload, or is it a better idea to subscribe ~ubuntu-sponsors?
[17:50] <ScottK> stgraber: The error is "checking Qt4 libraries... configure: error: *** Couldn't find any Qt4 libraries".
[17:50] <cyphermox> I can certainly look at it, just give me a minute to finish up with a patch
[17:51] <SpamapS> slangasek: on it shortly
[17:51] <stgraber> ScottK: indeed, maybe I should consider trusting configure's output a bit more in the future :)
[17:52] <ScottK> Well a certain amount of caution is in order ...
[18:03] <apw> pitti, just pushed up a branch to fix a udev bug, bug #831516 -- would poke the latest uploader but i don't know their nick
[18:03] <cjwatson> cnd: https://bugs.launchpad.net/udd
[18:04] <cjwatson> slangasek: klibc> we do now, I just fixed it
[18:04] <slangasek> oh
[18:04] <slangasek> ok then
[18:04] <slangasek> coulda sworn that was found and fixed last cycle though
[18:04] <cnd> cjwatson: if it's in regard to gvfs not being updated in bzr, I've found the issue and am chatting on #launchpad
[18:05] <cnd> thanks
[18:05] <cjwatson> cnd: ok, but in future that's AFAIK the canonical place to ask
[18:05] <cjwatson> slangasek: it broke mid-oneiric
[18:05] <cnd> cjwatson: ahh, ok
[18:05] <cjwatson> cnd: (I could be wrong, #launchpad may know better than I)
[18:13] <elmo> does anyone know offhand what causes /dev/.static/dev to get mounted?
[18:23] <slangasek> elmo: nothing, in oneiric... and I forget :)
[18:25] <infinity> adconrad@loki:/usr/share/initramfs-tools$ rgrep static *
[18:25] <infinity> scripts/init-bottom/udev:mkdir -m 0700 -p /dev/.static/dev
[18:25] <infinity> scripts/init-bottom/udev:mount -n -o bind ${rootmnt}/dev /dev/.static/dev
[18:25] <infinity> ^-- From a hardy machine.
[18:25] <infinity> elmo: ^
[18:25] <elmo> yeah, i just found that
[18:25] <infinity> Figured you might.
[18:25] <elmo> I'm seeing it get created only on lucid based xen guests and can't figure out why
[18:26] <infinity> One would assume that the final mount -o move is failing for some reason.
[18:26] <infinity> Not that that's helpful.
[18:26] <infinity> But you could stuff strace into the initrd and try to step through it by hand.
[18:26] <infinity> (ick)
[18:29] <infinity> Actually, wait.  /dev/.static/dev is populated on this hardy machine too, it just doesn't show as mounted...
[18:29] <infinity> Maybe it's just cosmetic?
[18:30] <elmo> infinity: oh, yeah, sorry, it is mostly cosmetic, but it's freaking some puppet probe-for-filesystems stuff out we have
[18:30] <elmo> i could just fix the puppet, but I'm curious as to why this is only happening on these particular hosts, as I suspect it has something to do with how they were created
[18:30] <infinity> Potentially, yeah.
[18:39] <siretart> ScottK: sorry, I must have missed your hilight. do you refer to k3b? in any case, feel free to assign the bug to me and I'll have a look
[18:40] <cjwatson> siretart: I already sent ScottK a patch
[18:40] <ScottK> siretart: I do.  cjwatson took a stab at a patch that I'm waiting for someone to test.
[18:40] <siretart> ah, great!
[18:50] <seb128> could some buildds admin score up the builds on https://launchpad.net/~unity-team/+archive/compiz-testing/+builds ?
[18:50] <seb128> (those are candidate for landing in oneiric before the beta freeze that need testing)
[18:51] <infinity> seb128: On it.
[18:52] <seb128> infinity, thanks
[19:03] <hallyn> doko: so that FTBFS for qemu is due to undefined NULL.  Can I assume that's a toolchain breakage?
[19:05] <doko> hallyn, no, broken code, most likely missing header
[19:05] <doko> if it's C++
[19:05] <smoser> anyone interested in thinking about bug 829238 ?
[19:06] <smoser> short summary is that it seems we might want a 'udev-settle' in initramfs to fix/avoid some of the udev race conditions that we have seen.
[19:08] <smoser> slangasek, ^ ?
[19:09] <slangasek> smoser: udev-settle is probably the wrong tool for whatever you're doing
[19:09] <slangasek> I say this without having looked at the bug yet :)
[19:10] <smoser> i can accept that, and my initial suspicion was that in this case "sleep 1" == "udev-settle"
[19:11] <smoser> but i held hope that they'd come accross the actual fix for a number of race conditions i'd seen in udev dying or losing events
[19:12] <slangasek> smoser: I think this is a bug in udevd itself; since we kill via 'udevadm control --exit', I expect udevd to finish processing any events it's already seen before shutting down
[19:12] <slangasek> but I don't think I've grokked yet from the bug description what events are lost or why, or what these worker messages are about
[19:17] <slangasek> hallyn: which qemu FTBFS is this?  Bug #829492 is almost certainly a regression due to multiarchification of pulseaudio
[19:18] <hallyn> doko: right you are
[19:18] <hallyn> doko: and I see the upstream commit fixing it
[19:18] <smoser> slangasek, i put more references to other bugs where we've seen these messages.  Its definitely race condition.
[19:19] <hallyn> slangasek: hm, that might have unmasked the problem
[19:19] <hallyn> slangasek: thx, i'll take a look at that too
[19:19] <smoser> and people seem to think that all sorts of things "fix" the issue, but imho they do the same as 'sleep 1'
[19:19] <slangasek> smoser: right, for some hardware-dependent value of '1'
[19:19] <slangasek> which is why it's the wrong fix
[19:19] <smoser> right
[19:19] <smoser> well clearly sleep 1 is
[19:20] <smoser> but i was hoping that udev-settle might not have been so terrible
[19:20] <hallyn> slangasek: but i suspect the commit entitled "qemu-kvm: fix pulseaudio detection in configure" will help :)
[19:20] <smoser> but you seem to think it is.
[19:21] <slangasek> smoser: but even udevadm settle is wrong, because there's still a race condition between 'udevadm settle' returning, and calling 'udevadm control --exit', when a new event could come in from the kernel and get mis-handled
[19:21] <slangasek> hallyn: hmm, where is this commit?  The UDD branch for qemu-kvm seems to be out of date
[19:21] <smoser> thats reasonable, slangasek
[19:21] <smoser> so, yeah, control --exit needs fixing
[19:24] <hallyn> slangasek: that commit is in 0.15.0
[19:24] <slangasek> hallyn: ah, ok
[19:24] <hallyn> and yes, udd is out of date.  i've tried manually pushing an update, but it still didn't stay in sync
[19:24] <hallyn> slangasek: i'm hoping Daviey pushses my 0.15.0 merge tomorrow :)
[19:24] <hallyn> which would auto-fix this
[19:25] <slangasek> right, there's some bug in UDD affecting this branch, so it's not going to stay in sync on its own for the moment... if we mean to be using that branch, it's probably best to get it synced up, then set a Vcs-Bzr: lp:ubuntu/qemu-kvm as a warning to uploaders
[19:28] <hallyn> slangasek: i didn't know that was an option.  Sounds good.  (same is true with libvirt-bin)
[19:29] <slangasek> well, it's still possible some people will ignore the Vcs-* field and upload directly to the archive
[19:29] <slangasek> but the more we use the fields consistently, the less of a problem that is
[19:34] <ScottK> If there's no pending changes in the branch how is uploading the package wrong?
[19:36] <slangasek> well, that assumes people are looking at the branch before uploading, which is less likely to be the case if Vcs-Bzr isn't set
[19:36] <slangasek> if you've already grabbed the branch to see if there are pending changes, why not commit to the branch?
[19:38] <ScottK> Because I virtually never upload using the UDD stuff and I'd have to consult documentation on how to do it.  dput I am reasonably familiar with.
[19:39] <slangasek> hmm, ok
[19:39] <ScottK> Last I checked, doing stuff with the branch doesn't actually accomplish anything uploading doesn't.
[19:40] <slangasek> except provide richer change history, yes
[19:41] <ScottK> In the cases where the upload is complex enough to cover multiple commits.
[19:41] <ScottK> Agreed there.
[19:47] <falktx_> hey there
[19:47] <falktx_> I'm making a lightdm theme, but I just realized I have no idea how to change the default lightdm theme...
[21:06] <lifeless> barry: so is your lock package overlapping bzr's dir based locks ?
[21:06] <barry> lifeless: possibly.  mine probably predates it by a decade though :)
[21:19] <cnd> @pilot out