[00:26] <soreau> I still can't seem to get natty's partitioner running from a live session. I tried the mini.iso this time from usb and it still stops working when going to load the partitioner
[00:33] <TheMuso> soreau: Is this with the latest daily build?
[00:33] <soreau> TheMuso: yes
[00:34] <TheMuso> soreau: Ok have you checked the logs in /var/log/installer to see what might be going on?
[00:34] <soreau> no
[00:34] <soreau> It seems this is busybox shell for mini.iso
[00:35] <TheMuso> soreau: Well either from the mini.iso or a live CD, you should grab the logs in /var/log/installer and file a bug with those logs attached.
[00:37] <soreau> TheMuso: Ok
[01:12] <soreau> TheMuso: I'm here in the live session now, here is everything from /var/log/installer debug: http://sprunge.us/VGLF version: http://sprunge.us/GbBa
[01:13] <TheMuso> soreau: Please file a bug with that information attached.
[01:13] <soreau> TheMuso: Where?
[01:13] <TheMuso> soreau: You can do so by running "ubuntu-bug ubiquity" in the live session.
[01:13] <soreau> ok
[01:21] <soreau> TheMuso: 726908 filed
[01:21] <TheMuso> soreau: Thanks, I won't be the one who attends to it, but I just wanted to make sure it was filed in the first place. :)
[01:22] <soreau> Yea, I hope this isnt a real bug. Others have said it's broken until they fix it
[02:14] <skaet_> slangasek, there was a typo in the mail. (a couple actually... :P)  freeze was today at 2/28 2300 UTC.
[02:17] <slangasek> skaet_: ok :)
[02:17] <slangasek> that's good, means I'm not in trouble for uploading dpkg ;)
[02:18] <skaet_> heh, as long as it works in the  builds tomorrow ;)
[02:20] <Keybuk> slangasek: I could upload dpkg again if you like ;-)
[02:20] <slangasek> Keybuk: cool, then I can blame all the bugs on you
[02:20] <slangasek> and I get multiarch support
[02:20] <slangasek> win-win!
[02:22] <Keybuk> it's not like I can be fired
[02:22] <Keybuk> or that it would affect my next performance review in any way
[02:22] <Keybuk> being a community contributor has numerous advantages
[02:25] <lifeless> Keybuk: how much ubuntu time are you getting in your new job?
[02:26] <psusi> cjwatson, if you are still up, no, that change to partman-auto did not fix things... though there may be a new clue.. it now hangs while the target partition is still mounted.  It didn't do that before.
[02:26] <Keybuk> lifeless: none
[02:26] <Keybuk> however not working from home means I have rather less "job time" in my life ;-)
[02:27] <lifeless> Keybuk: cool
[02:27] <psusi> Keybuk, still not had a chance to review my ureadahead patches then eh? ;)
[02:27] <lifeless> Keybuk: for some reason i thought you were going to get upstart time (or are you, just not ubuntu time) ?
[02:28] <Keybuk> lifeless: correct; upstart time, not ubuntu time
[02:28] <Keybuk> psusi: I told you who you need to speak to about those ;-)
[02:29] <psusi> Keybuk, you also write plymouth didn't you?  I started using uswsusp the other day and noticed that it has support for some other splash systems, but not plymouth... thought it might be nice to add that if I find time... and wondered why it isn't part of a default Ubuntu install
[02:29] <Keybuk> psusi: I deny any accusations you might make
[02:29]  * Keybuk points wildly at cjwatson
[02:29] <Keybuk> HE TOUCHED IT LAST
[02:29] <psusi> ohh, you are working full time now on upstart?
[02:29] <psusi> lol
[02:29] <Keybuk> psusi: not currently, upstart is my 20% time project
[02:29] <psusi> Keybuk, you're still upstream maintainer of ureadahead according to lp ;)
[02:30] <Keybuk> psusi: am I? are you sure "canonical-scott" isn't?
[02:30] <Keybuk> canonical-scott died
[02:30] <Keybuk> there was a funeral and everything
[02:31] <psusi> Keybuk, says Scott James Remnant ;)
[02:31] <psusi> lol
[02:31] <Keybuk> psusi: it says "Scott James Remnant (Canonical)"
[02:31] <psusi> https://wiki.ubuntu.com/ScottJamesRemnant
[02:31] <psusi> ;)
[02:31] <Keybuk> haha
[02:32] <Keybuk> well, that can't possibly be me
[02:32] <Keybuk> I'm not a Canonical Ltd employee
[02:32] <psusi> maybe you are and just don't know it, hehe...
[02:32] <Keybuk> heh, we haven't bought them yet ;-)
[02:33] <psusi> ahh, I know what I can bug you about now... go fix the google phone ;)
[02:33] <Keybuk> hehe
[02:33]  * Keybuk loses all your e-mail
[02:33] <psusi> and a tablet while you're at it.. the new samsung galaxy tab has no usb
[02:33] <psusi> hehe
[02:33] <Keybuk> anyway, clearly I've reached a BAD POINT in the day, and I'm going to go home
[02:34] <Keybuk> bash: /tmp/stateful_update: /bin/sh: bad interpreter: Permission denied
[02:34] <Keybuk> ERROR  : Stateful update was not successful.
[02:34] <Keybuk> ^ BAD
[02:34]  * psusi stares blankly
[02:34] <StevenK> Keybuk: /tmp/stateful_update doesn't have +x ?
[02:35] <Keybuk> no I think /bin/sh has lost its +x
[02:35] <psusi> trying to execute something in /tmp?  this will end in tears
[02:35] <StevenK> Oooh, he's right. Doesn't /tmp have noexec?
[02:35] <Keybuk> StevenK: not on Chrome OS
[02:35]  * StevenK goes to wash
[02:36] <psusi> so chrome os is using upstart eh?
[02:36] <Keybuk> yes... obviously
[02:36] <Keybuk> anyway, dinner *gone*
[02:37]  * psusi kicks the stinking radeon driver for running it up to 83 C again
[03:05] <slangasek> Keybuk: who are you kidding, making the release team miserable has never impacted performance reviews :P
[04:05] <ion> slangasek: Woot! dpkg multiarch! Will i fry my desktop box if i migrate from i386 to amd64 with the current versions of dpkg, apt et al?
[04:05] <slangasek> you will fry it without hope of repair
[04:05] <slangasek> fyi :)
[04:06] <ion> hehe
[05:41] <Hock> test
[05:44] <Hock> if I fix a reported bug, how do I get the changes accepted?
[05:44] <micahg> Hock: https://wiki.ubuntu.com/SponsorshipProcess
[05:46] <Hock> micahg: thanks. even a simple debconf postinst scipt change require sponsorship?
[05:47] <micahg> Hock: sponsorship is a means to get your fix uploaded, if you just want to attach a patch to a bug, it will eventually be reviewed, but there's no guarantee when, the sponsorship queue is reviewed regularly
[05:48] <micahg> Hock: which package?
[05:49] <Hock> micahg: yes, i realise now that no one really have the time to look at attached patch especially of low importance. its for lirc
[05:50] <Hock> micahg: if the right process is not follow
[05:50] <Hock> micahg: I have seen in forum/mailing list that patch dont ever get update sometime
[05:50] <micahg> Hock: patches of all importance are welcome
[05:51] <Hock> micahg: thanks for the link. it look simple enough to follow. :) I will try it.
[05:51] <micahg> Hock: yes, that's why I was mentioning the difference between the sponsorship queue and just attaching a patch to a bug, we have over 2k patches that need review vs about 40 items in the sponsorship queue
[05:51] <micahg> Hock: feel free to ask if you run into issues
[05:52] <Hock> micahg: i have another fix for lric that involve adding a new remote that affect upstream. can i use the same process?
[05:52] <micahg> Hock: you can propose it, depending on the fix, they might ask it to go through upstream review first
[05:53] <Hock> micahg: ok. I will try out the sponsorship and get a hang of it first
[05:55] <Hock> micahg: the thing i find about the difficulty of patches going in is that it too complicated. there is one particular fixed of a pvr in v4l2 which many have been using
[05:55] <Hock> micahg: but it never get into upstream even after many follow-up
[05:57] <Hock> micahg: i am using gmail account. What should i be entering for system mail name?
[05:57] <micahg> Hock: well, sometimes we take patches ahead of upstream, it depends on the specific upstream
[05:58] <micahg> Hock: system mail name?
[05:58] <Hock> micahg: sudo apt-get install bzr bzr-builddeb
[05:59] <Hock> micahg: as part of the postfix configuration
[06:00] <micahg> Hock: that's for a local mail server
[06:00] <Hock> micahg: yes. but i am not sure if its important for the sponsorship
[06:00] <micahg> Hock: it's not
[06:00] <Hock> micahg: anyway. i just dump the hostname in
[06:12] <soreau> Would the fact that one of my drives is GPT contribute to the partitioner failing to start?
[06:13] <Hock> micahg: if this the correct branch? bzr branch lp:ubuntu/lirc lirc
[06:19]  * micahg checks if the branch is up to date
[06:20] <micahg> Hock: yes, that looks correct
[06:20] <Hock> micahg: would doing that get patch in natty or maverick?
[06:21] <micahg> Hock: natty
[06:21] <micahg> Hock: to update maverick you need a stable release update: https://wiki.ubuntu.com/StableReleaseUpdates
[06:22] <Hock> micahg: i see. thanks.
[06:24] <Hock> micahg: do I then need to be on natty to use bzr?
[06:24] <Hock> micahg: currently running it on maverick
[06:24] <micahg> Hock: nope
[06:25] <Hock> micahg: pardon all the noob questions. have always wanted to help out but find it difficult to do so
[06:26] <micahg> Hock: feel free to ask as many questions as you like
[06:34] <soreau> This kinda sucks having natty running live in several different ways and not have the ability to install
[06:48] <TheMuso> soreau: No I don't think so.
[06:49] <soreau> TheMuso: It's always handled GPT fine in the past so I think I will wait a few more weeks and try again
[07:16] <pitti> slangasek: too late now anyway, so I guess it's decided :)
[07:17] <slangasek> pitti: yep!  and it didn't break the world too badly
[07:17] <slangasek> debootstrap almost works again

[07:31] <Hock> micahg: thanks for your help. have managed to submit the patch via sponsership
[07:31] <micahg> Hock: great, thank you for your contribution to Ubuntu
[07:32] <Hock> micahg: looking forward to contribute more if i can
[07:34] <pitti> slangasek: I just got the livefs-base build failure, could this have anything to do with the new dpkg? rsyslog hasn't changed in 1.5 montsh
[07:34] <slangasek> pitti: yes, see above - "debootstrap almost works again" :)
[07:34] <slangasek> pitti: just waiting for the publisher now
[07:35] <pitti> slangasek: ah, I overlooked that in the log, sorry; just looked at the "Upgrading" stage
[07:35] <pitti> cool
[07:35] <slangasek> pitti: two packages broke with the change, python-central and ucf, which both poke around in /var/lib/dpkg/info directly; multiarch changes the dpkg db paths
[07:35] <slangasek> I've fixed and uploaded both, should finish publishing any minute now
[07:47] <didrocks> good morning
[08:01] <dholbach> good morning
[08:02] <pitti> Riddell: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has quite a few Qtish packages (qtmobility, telepathy-qt4, kubuntu-mobile-default-settings) which want to go to universe; is that intended?
[08:02]  * pitti hugs dholbach
[08:04]  * dholbach hugs pitti back
[08:23] <apw> pitti, is the retracer ok?  i have a bug filed 9 hours ago which is still not retraced: bug #726840
[08:25] <pitti> apw: I just restarted it, it crashed last  night
[08:25] <apw> pitti, thank you sir ... she is a fragile lady, we must remember to complement her more often
[08:26] <pitti> indeed..
[08:31] <pitti> Riddell: for bug 712061 , that merge was done; should this work now?
[09:16] <Riddell> pitti: bug 712061 is waiting on deployment to cocoplum
[09:46] <zyga> jdstrand, ping
[09:56] <\sh> what was the channel for canonical sysadmins?
[10:04] <zyga> \sh, #is
[10:04] <StevenK> That's not it, #canonical-sysadmins on this network
[10:05] <\sh> #canonical-sysadmin is more correct ;)
[10:05] <\sh> found it already on some gnome pages
[10:20] <amitk> is ubuntu-desktop still the meta package that'll ensure I've got everything equivalent to a fresh natty install?
[10:20] <pitti> amitk: mostly; it won't reinstall recommends which you uninstalled manually
[10:40] <smoser> anyone able to help explain http://uec-images.ubuntu.com/server/natty/20110301.3/log.stdout.stderr .
[10:41] <smoser> i'm seeing build errors on last night uec image builds.  the first errors mention lsb_release
[10:41] <pitti> smoser: pycentral failure due to new multiarch dpkg; shoudl have been fixed over night
[10:41] <smoser> and pycentral
[10:41] <smoser> ah.
[10:41] <smoser> ok.
[10:41] <pitti> smoser: can you trigger a rebuild? it should have been fixed for about 2 hours now
[10:42] <pitti> smoser: (I am rebuilding all 'regular' alternates/desktops for that ATM)
[10:42] <smoser> can, do. thank you pitti.
[10:44] <smoser> my other question... i think i'm in need of an archive admin to process bug 725127
[10:45] <smoser> kirkland, had thought he did, but it does not appear to have taken, there is no cloud-initramfs-rescuevol or cloud-initramfs-growroot in the archive.
[10:47] <techbreak> bzr branch lp:ubuntu/maverick .... shows Permission Denied (public key)
[10:48] <techbreak> what to do ?
[10:49] <pitti> techbreak: ubuntu/maverick/what?
[10:49] <Riddell> ogra: [Qt-announce] Qt 4.7.2 has now been released
[10:49] <techbreak> pitti, am I supposed to do more than that ?/ I just runned "bzr branch lp:ubuntu/maverick "
[10:50] <cjwatson> techbreak: you can't do that
[10:50] <cjwatson> you need to pick a specific package to branch
[10:50] <techbreak> cjwatson, oh oh
[10:50] <techbreak> cjwatson, for example ? pitti
[10:50] <pitti> techbreak: lp:ubuntu/maverick/coreutils
[10:51] <techbreak> pitti, oh i see :) thanks :)
[10:51] <techbreak> thanks cjwatson too :)
[10:51] <cjwatson> I sort of assumed that you already knew which package you were interested in :-)
[10:55] <techbreak> pitti, cjwatson , bzr branch lp:ubuntu/maverick/computer-janitor
[10:55] <techbreak> Permission denied (publickey).
[10:55] <techbreak> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[10:55] <smoser> pitti, i think i'm still seeing the error.
[10:55] <pitti> techbreak: did you upload your ssh key to launchpad?
[10:56] <techbreak> pitti, yes
[10:56] <pitti> techbreak: (also note that this is not the canonical branch of computer-janitor, as it's got a custom one -- see Vcs-Bzr: field)
[10:56] <pitti> techbreak: you could start wiht "debcheckout computer-janitor"
[10:56] <smoser> looks like python-central > 0.6.11 not in the archive yet
[10:56] <cjwatson> and did you run 'bzr launchpad-login YOUR-LP-USER-NAME'?
[10:56] <cjwatson> Get:1 http://gb.archive.ubuntu.com/ubuntu/ natty/main python-central all 0.6.15ubuntu5 [40.9 kB]
[10:56] <cjwatson> smoser: ^-
[10:57] <techbreak> cjwatson, yes i logged in
[10:57] <smoser> cjwatson, hm... yes.
[10:59] <smoser> http://paste.ubuntu.com/573880/
[11:00] <smoser> cjwatson, that log is what lead me to my obviously incorrect statement.
[11:01] <cjwatson> 2011-03-01 10:48:14,315 DEBUG   : I: Retrieving python-central
[11:01] <cjwatson> 2011-03-01 10:48:14,370 DEBUG   : W: Couldn't download package python-central
[11:01] <cjwatson> odd
[11:01] <smoser> yeah, thats the first time i've ever seen that.
[11:01] <cjwatson> that might be an "apt-get update and try again shortly" kind of thing
[11:01] <smoser> (this machine is sitting lan connected to the archive)
[11:03] <smoser> Riddell, are you able to archive admin for me ? bug 725127
[11:05] <cjwatson> oh whoops
[11:05] <cjwatson> multiarch dpkg makes d-i fail to build :-)
[11:06] <pitti> eek
[11:06] <genux> lo all, I was wondering for next week is there any parts of the of 11.04 that would require testing ? or is there going to be a testing phrase next week ?
[11:07] <pitti> genux: we actually just started testing a few hours ago, for alpha-3
[11:07] <pitti> http://iso.qa.ubuntu.com/qatracker/
[11:08] <genux> pitti : doh!!. I have next week off work and was going to test out 11.04. when is the next test ?
[11:08] <pitti> genux: we get new unity/compiz/etc releases every Thursday, so there'll still be plenty of testing :)
[11:08] <pitti> genux: but for the whole CD images/installation, next round will be for beta-1, March 31st
[11:09] <genux> cool :). is this a good place to "view" the development of ubuntu whilst I am at work ? to see what is happening etc.
[11:09] <genux> thanks pitti
[11:11] <cjwatson> slangasek: if I'm not much mistaken, the /var/lib/dpkg/info/$(dpkg --print-architecture) symlink will be missing for all new installs
[11:11] <cjwatson> slangasek: it's only installed on upgrade
[11:15] <genux> pitti: is the new release every Thursday, is that every Thursday throughout the year ? or for release cycles (aplha/beta)
[11:15] <pitti> genux: so far they happened every week throughout natty
[11:16] <pitti> and are supposed to continue to do so
[11:17] <genux> pitti: thanks, shall leave part of my partition to install :)
[11:20] <cjwatson> hm, brltty mismerge
[11:25] <smoser> debootstrap --verbose --download-only --arch=i386 natty ./out.d http://archive.ubuntu.com/ubuntu
[11:32] <techbreak> techbreak@techbreak:~/Computer/janitor$ bzr branch lp:computer-janitorPermission denied (publickey).
[11:32] <techbreak> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[11:39] <cjwatson> FYI I recommend not installing from current daily images
[11:40] <genux> cywaston : why is that ? I just download it.
[11:40] <cjwatson> genux: bug 727106
[11:41] <genux> cjwatson : thanks. shall download the other one :)
[11:41] <cjwatson> what other one?
[11:42] <genux> cjwaston: the aplha 2 ? kinder assuming that it will upgrade to the latest ?
[11:42] <cjwatson> alpha 2 will be fine
[11:42] <cjwatson> well, probably
[11:43] <genux> arh. k.
[11:43] <genux> shall give it a go :)
[11:46] <proti> cjwatson: bug 723482
[11:46] <proti> Manage to reproduce the problem in a Virtualbox VM.
[11:46] <proti> See comment #29.
[11:46] <proti> Happens only when upgrading from maverick.
[11:47] <cjwatson> ok, thanks, I will look at that today
[11:48] <cjwatson> that's exactly the kind of directions I need, thank you
[11:48] <genux> is it best to install from disk ? or upgrade from maverick ? for testing reasons.
[11:48] <genux> or just both.
[11:48] <cjwatson> genux: good testing requires a variety of scenarios
[11:49] <cjwatson> so it would be foolish of us to recommend one of those :)
[11:49] <genux> cjwatson: k ;). was not sure which one was at present the best solution to get up and running ? or which one was requiring more "attention" :)
[11:50] <proti> cjwatson: The problem is down to linux-image, grub-pc, mountall, libc6.
[11:50] <cjwatson> installing fresh from alpha-2 should be reasonably OK and is likely to be quicker than an upgrade
[11:53] <genux> cjwatson: I have a problem with my present setup in that I have to alter the pci memory allocation for the linux-image to work, (alter i386.c and re-compile) so will that effect the testing ? because I would be adding into the linux-image about 5 lines extra for it to work with my setup ?
[11:55] <proti> cjwatson: Problem lies in grub-pc.
[11:55] <cjwatson> genux: I'm sure it would be interesting, but I can't help you :)
[11:56] <cjwatson> proti: oh?  is that just by bisecting package versions?
[11:56] <proti> I took a snapshoot before. And upgraded packages one by one. Rebooted between each.
[11:57] <proti> Mountall ok.
[11:57] <proti> Then grub-pc.
[11:57] <proti> grub-pc=hang.
[11:57] <genux> cjwatson: nps.. I am happy to recompile the kernel, was just wondering if I said about any issues if it would be k to report them since I would be using a none standard ubuntu linux-image
[11:57] <cjwatson> proti: ok, thanks
[11:57] <pitti> cjwatson, ev: are the current strings in the initial ubiquity partitioner screen supposed to stay like that?
[11:57] <cjwatson> genux: that depends on the bug, I imagine
[11:57] <genux> cjwatson: k thanks :)
[11:57] <cjwatson> pitti: I defer to ev
[11:57] <kirkland> smoser: done
[11:59] <pitti> whee, the slideshow is back on amd64
[12:05] <davmor2> pitti: do you have time to run a quick test?
[12:06] <pitti> davmor2: of what? (currently doing amd64 desktop smoketest)
[12:06] <davmor2> pitti: import a cd in banshee.  It seems to of duped every track
[12:06] <davmor2> audio cd that is
[12:07] <pitti> davmor2: ok, it's not that quick, though (need to install banshee, and more importantly, I need to roam the flat to find an audio CD)
[12:09] <davmor2> pitti: nevermind then I'll ask someone else thanks though
[12:10] <pitti> davmor2: found one
[12:10] <pitti> "OpenMusic" CD from LInuxTag 2008, yummy ;)
[12:10] <ogra> Riddell, bah, now thats what i call timing
[12:10] <davmor2> pitti: why would you need to install banshee is it not the default anymore?
[12:11] <pitti> davmor2: it is, but I like RB more (and thus don't have mono installed)
[12:11] <davmor2> pitti: I just don't like banshee so will be installing RB on my full system
[12:11] <pitti> banshee is too slow and too crashy, and the album view confuses me
[12:12] <davmor2> pitti: oh yes,  the only thing I like is the miro built in till I found a flaw with that :)
[12:14] <pitti> davmor2: how do I even do this? I don't see the audio CD anywhere in banshee
[12:14] <davmor2> pitti: it appears at the bottom of the list eventually
[12:15] <davmor2> under last.fm
[12:15] <pitti> davmor2: aah, in "online media"
[12:15] <pitti> hard to see
[12:16] <davmor2> pitti: yes cause obviously a cd is online media
[12:17] <davmor2> pitti: click on the cd, and the option is displayed at the top to import it
[12:17] <pitti> right, running now
[12:19] <zyga> hi, is there an easy way to get pbuilder "offline" during the build process? So that I can make sure it will not work by accident (blame python setuptools) because it could download a missing dependency?
[12:21] <pitti> davmor2: so, as each song on this CD has a different artist, it now imports each song into a different album view
[12:21] <pitti> but I don't see duplication
[12:22] <davmor2> pitti: http://ubuntuone.com/p/fSj/ this is what I got
[12:23] <pitti> davmor2: I don't get that one then
[12:24] <davmor2> hmm I just noticed the time is ever so slightly different on each
[12:27] <cjwatson> slangasek: have you thought about how dpkg-reconfigure ought to work in a multiarch world?
[12:30] <geser> zyga: yes, but you have to patch pbuilder for it
[12:31] <zyga> geser, can it be done with hooks or is there some ppa with a patched pbuilder?
[12:31] <zyga> geser, it's more tricky than "no network" as it should be able to reach the archive first
[12:33] <geser> zyga: you need a small "sandbox" program from stgraber which needs to be chained before the dpkg-buildpackage call in one of the pbuilder shell scripts, I don't know of any patched pbuilder yet (I've patched my pbuilder manually)
[12:33] <debfx> zyga: you could try using iptables to filter network connections by process user id
[12:34] <geser> zyga: that one http://bazaar.launchpad.net/~arkose-devel/arkose/trunk/view/head:/arkose-raw-nonetwork.c
[12:36] <geser> zyga: compile it and put it into /usr/local/bin (or somewhere else)
[12:37] <geser> zyga: modify /usr/lib/pbuilder/pbuilder-buildpackage at line 128: put it between the "|" and the "$CHROOTEXEC"
[12:38] <geser> that should give you a pbuilder which can still use network to download build-dependencies, but not during build (network is available again in hooks)
[12:39] <zyga> thanks, I'll check it out
[12:40] <geser> I hope I remember correctly what I did (don't have access to my patched pbuilder right now to look it up)
[12:42] <bdrung> geser: i have added Daviey to core-dev
[12:44] <geser> bdrung: thanks, wanted to process it all today (was too late yesterday after the meeting)
[12:45] <bdrung> i leave the rest for you ;)
[12:46] <Daviey> geser, Thanks!
[13:45] <ev> pitti: stay like what?
[13:49] <jdstrand> smoser: re cloud-init-utils-- you still need help?
[14:07] <mterry_> Is anyone else getting 404s from us.archive.ubuntu.com?
[14:08] <pitti> mterry_: we have a broken master mirror (which might also be an archive server), perhaps that's the reason
[14:09] <mterry_> pitti, ah probs.  non-us archive server works fine
[14:21] <lool> jhunt: Hey there; I have an upstart job question: I'm starting multiple instances of a daemon which itself will start some command (a bit like inetd); currently, on stop only the daemon itselfs is killed, but not its subprocesses
[14:23] <lool> jhunt: I don't know how to stop this daemon properly, so I wouldn't mind if upstart ripped the whole tree of process; I tried stopping the daemon manually by sending a kill -HUP as the upstream init script is doing, and that only kills some sub-processes (e.g. it kills a configured netcat subprocess, but not a configured vim subprocess)
[14:32] <jhunt> lool: sounds like the sub-processes have forked twice/called setsid? upstart can only trace the "parent" daemon process (0-2 forks).
[14:32] <jhunt> lool: what is this daemon?
[14:33] <lool> jhunt: It's conmux; it's a perl script which starts processes
[14:33] <lool> and shares their input/output with multiple clients; a bit like screen
[14:35] <jhunt> lool: Surely if conmux is starting processes, *it* should be controlling them? Having just googled what it is, I'd say speak to apw :-)
[14:36] <lool> jhunt: hehe
[14:36] <lool> jhunt: Ok
[14:36] <lool> jhunt: upstart sends a SIGTERM by default, right?
[14:36] <apw> jhunt, yep it expects to beable to close their input and output and for that to make them go away mostly, and i think it then HUP's them
[14:36] <apw> but blimey its a long time since i wrote that!
[14:37] <lool> apw: with the netcat example, it will stay running if conmux gets killed; it needs an explicit kill -HUP to be able to kill netcat
[14:37] <apw> i guess it would die when the next input came in and it had nowhere to put it
[14:37] <apw> cirtainly it would not be unreasonable to hammer hard on the children
[14:38] <apw> if it does not do so already, not illogical to catch more signals in conmux itself if needed to pass them on
[14:38] <jhunt> lool: yes, it sends SIGTERM, waits 5 seconds, then if the pid is still there sends SIGKILL. This is now documented in the natty version of upstart ("man 5 init" search for "kill timeout").
[14:38] <lool> apw: I didn't find where conmux listens for SIGHUP
[14:38] <lool> jhunt: Thanks
[14:39] <apw> lool got a source tree with the version you are using ?
[14:39] <lool> jhunt: is there a way to send a HUP instead?
[14:39] <lool> apw: http://test.kernel.org/releases/0.12.0/
[14:39] <lool> apw: it's in the conmux subdir
[14:40] <jhunt> lool: not currently.
[14:40] <lool> apw: BTW, I only intend to package conmux, but this tarball contains much more; is there a direct distribution of conmux, perhaps with more up-to-date sources?
[14:41] <lool> jhunt: Ok; I was mostly hoping I could tell upstart to kill the whole process tree, but I agree it's kind of the job of the daemon
[14:41] <apw> lool nope, that is the place it 'lives' ...
[14:41] <lool> apw: I see there's a conmux/.version file with release version information, but that doesn't match the version of autotest; do you mind if I use the version of the autotest tarball to offer a conmux package?
[14:42] <lool> that is, the conmux .deb would be 0.12.0 even if conmux .version says something else
[14:42] <lool> It says: conmux 1 00 00 1000
[14:42] <lool> name major minor patch build; so 1.00.00 is its version
[14:43] <slangasek> cjwatson: missing symlink> right, I expected that to only be for compatibility with existing installs; it doesn't hurt anything to have it there for initial installs, at least for right now
[14:43] <slangasek> cjwatson: dpkg-reconfigure> not thought too hard about it, I expect buxy may have thought harder
[14:48] <apw> lool, yeah there was only one official release, that was a mechanism to get legal to sign off on it to let it out ... it had to be bounded and versioned
[14:48] <apw> lool, so it does not look like we do handle signals
[14:49] <apw> to do so one would likely want to use a class method on Payload to run the list of payloads and pass it on to them
[14:49] <lool> apw: As an upstream, could I tempt you to do that in some way?  :-)
[14:50] <apw> if we were to catch SIGHUP and then essentially call mux_close on all the payloads I think that would do it
[14:50] <apw> as that sends signals if we have a pid
[14:50] <apw> lool it'd have to be tommorow
[14:51] <lool> apw: Ok; I hve meetings until the end of the day, I might give it a try tonight and send you the patch, or if I don't I'd be happy if you tride
[14:51] <lool> tried
[14:52] <apw> lool as a first stab you might arrange for the DESTROY on the class Payload, to call $self->mux_close(...)
[14:53] <apw> you may need to generally 'catch' SIGHUP to do like 'exit' to maek the destructors work
[15:22] <proti> cjwatson: ping
[15:22] <cjwatson> proti: hi
[15:22] <proti> hi I got it all wrong
[15:22] <cjwatson> (please don't send contentless pings)
[15:23] <proti> sorry, the set of packages causing the hangs are : near alsa-utils
[15:24] <cjwatson> proti: it may be easiest for me to just try the upgrade here and debug directly, at this point.  I'm in the middle of that ...
[15:24] <proti> I means either linux-sound-base alsa-util libasound2 alsa-base
[15:25] <proti> cjwatson: How to debug this ?
[15:26] <cjwatson> I will figure it out when I get that far :)
[15:27] <proti> How far are you ?
[15:28] <cjwatson> doing the maverick-updates upgrade
[15:32] <proti> So, after natty upgrade, do apt-get install alsa-utils
[15:32] <proti> The package alsa-utils are causing the hang.
[15:36] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek day 2 starting in 25 minutes in #ubuntu-classroom
[15:48] <proti> cjwatson: /etc/init/alsa-restore.conf  is doing something wrong.
[15:51] <cjwatson> in principle it looks fine.  could be a knock-on failure.
[15:51] <cjwatson> I don't see why that should block anything else, either.
[15:52] <proti> (mounted MOUNTPOINT=/usr and mounted MOUNTPOINT=/var) is the only cause I can see.
[15:55] <cjwatson> but that should be fine.
[15:56] <cjwatson> that just means that job won't start until those conditions are true.
[15:56] <proti> How does upstart manage the *.conf files ? The fact is this file is the first in alphabetical order of the directory.
[15:56] <cjwatson> man 5 init
[15:56] <cjwatson> how did you determine that this file was doing something wrong?
[15:57] <proti> I renamed  it to alsa-restore.disabled and then the system came back to life.
[15:57] <cjwatson> let me look then please
[15:57] <cjwatson> waiting for the natty upgrade now
[15:59] <proti> np
[16:11] <barry> is security.ubuntu.com really slow for anyone else?  updates from that server are taking a really long time, but us.archive.ubuntu.com seems fine
[16:12] <jdstrand> barry: yes, it is known. it should start resolving itself soonish hopefully
[16:13] <barry> jdstrand: cool, thanks
[16:14] <apw> bryce_, i have some further updates for lpltk for your consideration: lp:~apw/arsenal/python-launchpadlib-toolkit-milestones-etal
[16:17] <proti> barry: I confirm.
[16:19] <barry> proti: thanks, see jdstrand's reply above
[16:19]  * proti saw that after hitting return key.
[16:36] <c2tarun> can anyone please help me with this error. http://paste.ubuntu.com/574005/
[16:48] <cjwatson> proti: reproduced; debugging ...
[16:56] <proti> cjwatson: go on. Not sure that 723482 is really related to mountall, neither alsa-utils.
[17:03] <psusi> seb128: you marked bug #247909 as triaged for gtk.  It seems that claws has been building just fine for several releases, and the claws target was marked fix released.  Do you know if there any reason for it to still be open on gtk?  I can't tell if it was a bug in gtk that claws worked around, or if it was a bug in claws and the gtk task is invalid.
[17:04] <seb128> psusi, the triaged was because someone send it to GNOME
[17:04] <seb128> check the status of the upstream bug
[17:04] <seb128> it's likely fine to close
[17:05] <psusi> expired... ok, I'll close it then
[17:16] <Riddell> NCommander: florence-applet .debs are empty, presumably that's a bug?
[17:17] <nigelb> 17:14 < hiemanshu> tazz: but you forget, lifemac is the sexiest person alive on earth
[17:17] <nigelb> ugh, sorry
[17:17] <nigelb> wrote paste
[17:18] <ogra> @pilot in
[17:19] <cjwatson> proti: my tests so far suggest that mountall is getting stuck in libudev somewhere; but I have to go away for a few hours now, so I'll resume debugging when I get back
[17:19] <proti> ok, maybe a dep problem.
[17:20] <proti> mountall executed before udev ??
[17:20] <cjwatson> no
[17:20] <cjwatson> I'll work on it in a few hours
[17:20] <cjwatson> I think that guessing is unlikely to be fruitful at this point
[17:20] <cjwatson> I have strace dumps to study, which are much better for directed debugging
[17:21] <ogra> cnd, looking at bug 702976, it isnt clear to me if you want the patch merged or not
[17:21] <cnd> ogra, I attached an entire new source package
[17:22] <cnd> that's what should be uploaded
[17:22] <cnd> the debdiff is informational
[17:22] <proti> Don't get me wrong, I did that first.
[17:22] <ogra> cnd, ok, will do
[17:22] <cnd> ogra, thanks!
[17:22] <proti> But stuck process and unreliable behavior proved to be hard to get a good track.
[17:23] <proti> So I went to the black box test to remove some deps.
[17:24] <proti> I'll be around if you need information.
[17:25] <Riddell> cnd: bug 725959 seems to be caused by the xinput patch
[17:25] <Riddell> debfx: ^^
[17:26] <cnd> Riddell, I'll take a look
[17:28] <Wubbbi> Hey guys. I have got a question. I am from the mageia project and maybe you could help me/us? Did you make the current pyxfce of xfce4.8 build? It only fails here. Do you have got a patch maybe?
[17:31] <Riddell> Wubbbi: remove with bug 329735
[17:32] <Bravewolf> security.ubuntu.com seems really overloaded and/or offline. is it supposed to be round-robin?
[17:32] <pitti> Bravewolf: it is, but it's still getting hammered by yesterday's security updates
[17:35] <Wubbbi> Riddell: that means? pyxfce depends on mcs?
[17:36] <Riddell> Wubbbi: I don't know, you'd need to ask an xfce packager, maybe people in #xubuntu know
[17:36] <Wubbbi> ok thx anyway
[17:38] <didrocks> ev: hey, just saw your update in the wiki
[17:38] <ev> oh?
[17:38] <didrocks> well wiki/lauchpad
[17:38] <didrocks> ev: so now ubiquity proposes nvidia driver?
[17:39] <ev> didrocks: yes.  I still need to make it change the text accordingly, but if you check the third-party software box on the prepare page it will call jockey-text -C in the target filesystem during install
[17:39] <didrocks> ev: excellent! thanks a lot for that :)
[17:39] <ev> but of course
[17:43] <Bravewolf> pitti: ok, thanks. still wondering however why "dig" shows me only two ip addresses for this server (91.189.92.166/7), and why the load is not distributed among the mirrors carring *-security
[17:44] <jdstrand> security.ubuntu.com is not mirrored
[17:44] <jdstrand> well, let me put it this way
[17:44] <jdstrand> sources.list has security.ubuntu.com, and mirrors are typically for archivel.ubuntu.com
[17:44] <jdstrand> what is supposed to happen is that -security updates are pocket copied to -updates
[17:45] <jdstrand> that didn't happen for openjdk and sun-java6
[17:46] <jdstrand> that has happened now, and all but karmic/openjdk is in archive.ubuntu.com, and therefore making their way to the mirrors
[17:46] <jdstrand> (karmic/openjdk is pending)
[17:52] <Bravewolf> jdstrand: take a look at na.mirror.garr.it/ubuntu. it has *-security (e.g. lucid-security)
[17:53] <Bravewolf> jdstrand: so apparently it seems that there are mirrors carring -security (and not security copied into updates)
[17:54] <jdstrand> Bravewolf: that is because the packages in lucid-security are pocket-copied to the -updates pocket
[17:54] <jdstrand> Bravewolf: but the distribution name is still lucid-security in the changelog
[17:55] <jdstrand> Bravewolf: and that pocket copy is what didn't happen for openjdk, so everyone downloaded from security.ubuntu.com, not all the mirrors
[18:01] <Bravewolf> jdstrand: mmmh... let me understand. what do you mean with pocket copy? because it seems that the content of -updates is different respect to -security in the GARR mirror
[18:02] <jdstrand> Bravewolf: ubuntu is split up into pockets: release, -security, -proposed, -updates and -backports
[18:02] <jdstrand> Bravewolf: the release pocket never changes after release
[18:03] <jdstrand> Bravewolf: if you look at sources.list you see things like:
[18:03] <jdstrand> deb http://archive.../ubuntu lucid
[18:03] <jdstrand> deb http://archive.../ubuntu lucid-security
[18:03] <jdstrand> deb http://archive.../ubuntu lucid-updates
[18:03] <jdstrand> all security updates go to -security
[18:04] <Bravewolf> jdstrand: right. no problems here
[18:04] <jdstrand> then all those updates are supposed to by copied to the -updates pocket
[18:04] <jdstrand> so everything in lucid-security should be in lucid-updates
[18:04] <jdstrand> (slight white lie that you'll see in a moment)
[18:05] <jdstrand> high impact bug fixes go through the SRU process
[18:05] <jdstrand> those are upload to -proposed first
[18:05] <jdstrand> after they are deemed to fix the bug and be safe, things from -proposed are copied to -updates
[18:06] <jdstrand> so the updates pocket typically has more than what is in -security
[18:07] <jdstrand> when you set up a mirror via the installer, update-manager, whatever, it is typically for only archive.ubuntu.com
[18:07] <jdstrand> eg, us.archive.ubuntu.com
[18:07] <jdstrand> but security.ubuntu.com is always in there
[18:07] <jdstrand> this is to make sure that if a mirror fails, the security update is still available
[18:08] <sebner> didrocks: Are you aware that compiz is quite crashy the last few days? If not I'll file a bug about it later :)
[18:08] <jdstrand> security.ubuntu.com only has -security (it may also have release, not sure, but doesn't matter)
[18:08] <jdstrand> it does not have -update though
[18:08] <Bravewolf> jdstrand: right. perfect. it's clear. what is not clear is the fact that na.mirror.garr.it/ubuntu has "-security", which in turn it is supposed not to be mirrored. and this mirror has openjdk updates
[18:08] <didrocks> sebner: compiz itself or the decorations?
[18:08] <jdstrand> so, if the pocket copy from -security to -updates doesn't happen, the mirrors don't get the package that is in security.ubuntu.com, and everyone downloads from security.u.c
[18:09] <geser> cjwatson: have you a minute to moderate my mails to u-d-a and the TB and do a quick check on the TB mails if you need any additional info (they are about PPU upload rights and a new package set)?
[18:09] <Bravewolf> jdstrand: by the way I learned that having "-updates" is supposed to be safe in the long term (everythinh reach -updates in the end)
[18:09] <jdstrand> Bravewolf: a mirror can mirror security.ubuntu.com. it is up to them. but there is no automation that I am aware of that changes security.ubuntu.com in sources.list to be something else
[18:09] <pitti> geser, cjwatson: will moderate
[18:10] <sebner> didrocks: THAT is a good question :D
[18:10] <jdstrand> Bravewolf: also, when the security team uploads a package, it uses something like 'lucid-security' as the distribution name
[18:10] <jdstrand> Bravewolf: so everything in the security pocket has '-security' in the distribution name
[18:11] <didrocks> sebner: when it crashes, can you still change the workspaces, for instance?
[18:11] <geser> pitti: thx
[18:11] <didrocks> sebner: and do you still see unity?
[18:11] <Bravewolf> jdstrand: yes, in fact I have security.u.c in my sources.list. The point is that since security.u.c is overloaded two guys in the italian channel suggested to me to use a mirror. And I objected that it's not safe to do that. then I came here to get more details
[18:11] <jdstrand> Bravewolf: but when we pocket copy, it is a bit for bit copy, therefore copying openjdk-6 for lucid-security to the lucid updates pocket means that openjdk-6 in -updates has 'lucid-updates' as the distribution name
[18:12] <jdstrand> Bravewolf: assuming you trust the mirror, it is no less safe than using that mirror for archive.ubuntu.com, assuming you realize you are always at the mercy of how quickly that mirror updates itself
[18:12] <sebner> didrocks: not using unity :( but docky is still usable IIRC which means the decorations?!
[18:13] <didrocks> sebner: yeah, so there are been some crashes recently, there were a compiz update yesterday, did you get it?
[18:13] <didrocks> sebner: there is still one known crasher, but feel free to report it with apport, it will be duplicated if needed
[18:15] <sebner> didrocks: just updated to compiz 1:0.9.4-0ubuntu3, let's see if this does some magic :)
[18:16] <didrocks> sebner: you have to logout/login then
[18:16] <sebner> I know :)
[18:16] <didrocks> sebner: to ensure running the new decorator :)
[18:16] <didrocks> sebner: keep me in touch!
[18:16] <sebner> sure
[18:16]  * sebner hugs didrocks :)
[18:16]  * didrocks hugs sebner back
[18:20] <jdstrand> err
[18:20] <jdstrand> Bravewolf: I typed to fast. I meant to say:
[18:21] <jdstrand> "but when we pocket copy, it is a bit for bit copy, therefore copying openjdk-6 for lucid-security to the lucid updates pocket means that openjdk-6 in -updates has 'lucid-security' as the distribution name
[18:21] <cnd> Riddell, when you want to provide test packages of qt with fixes for bug reporters to test, how do you do it?
[18:21] <cnd> qt has so many packages
[18:22] <cnd> for this xi 2.1 change, all you technically need is to update libqtcore4 and libqtgui4, but if you update them separately you're dpkg state gets broken
[18:22] <Riddell> cnd: I'd put them in a PPA
[18:24] <cnd> Riddell, ok, I'll try that
[18:33] <ogra> james_w, around ?`
[18:46] <james_w> hi ogra
[18:48] <ogra> james_w, so Daviey and i challenged UDD and were wondering what will happen now that both of us used different ways to sponsor a package
[18:49] <ogra> i applied a debdiff to a package and dput'ed it while at the same time Daviey committed the same debdiff to the UDD branch
[18:49] <ogra> which indeed results in differences now
[18:49] <maco> daviey needs to do "bzr mark-uploaded"
[18:49] <Daviey> (the problem is that they aren't the same debdiff)
[18:49] <maco> oh
[18:49] <ogra> right
[18:49] <ogra> its the same stuff but differently formatted
[18:49] <Daviey> bug #726405
[18:50] <anon^_^> any issues persisting with latest updates in update manager?
[18:50] <ogra> james_w, so the question we came up with was, surely one will overrule the other, but which (teh dput upload or the bzr merge)
[18:50] <micahg> if the UDD branch isn't tagged with the uploaded revision, the revision will overwrite
[18:50] <anon^_^> dummy files are listed for a kernel update, images aren't showing, so those updates are not selected by default
[18:51] <Daviey> I dputted, then pushed to the bzr branch once that was successful
[18:51] <james_w> ogra, the package in the archive wins
[18:51] <Daviey> ogra, dputted 10 mins or so before me
[18:51] <micahg> Daviey: should go in the other order
[18:51] <anon^_^> regarding 10.04 LTS
[18:51] <ogra> james_w, sure
[18:51] <Daviey> micahg, it was seconds between each other... In either case, the same situation would have happend
[18:51] <ogra> james_w, but how does the UDD branch look like now
[18:52] <james_w> ogra, what's the package?
[18:52] <Daviey> james_w, will the package-importer uncommit my push then?
[18:52] <ogra> will it revert Daviey's change or just be out of sync forever etc etc
[18:52] <ogra> james_w, kbarcode
[18:52] <Daviey> see the bug # above ^^
[18:54] <james_w> lp:ubuntu/kbarcode still has Daviey's change, and kbarcode is in the package importer's queue
[18:54] <ogra> i would expect the package in archive to rule and revert the bzr change
[18:55] <ogra> but then i dont know and am just guessing
[18:55]  * Daviey suspects the importer isn't that clever, but hopes he is wrong
[18:56] <ogra> it *should* be that clever :)
[18:58] <james_w> ogra, Daviey, the package importer just crashed, I'm getting it restarted then we can see how clever it is
[18:58] <ogra> LOL
[19:00] <Daviey> heh :D
[19:32] <Chipzz> james_w: that would be a lot funnier if it were the retracer ;)
[19:37] <pitti> does anyone have a main package ready for upload? I need a small and harmless one
[19:37] <pitti> (just changed live seeds, which requires a task update)
[19:38] <pitti> I could sync upower
[19:56] <psusi> pitti: do you think it would be worth fixing uswsusp to integrate with plymouth, and do you think it could be then added to the desktop see for natty+1?  it seems to make hibernation faster, and if it worked with plymouth instead of slplashy, would provide a better desktop experience
[19:58] <pitti> psusi: I don't know uswsusp at all, I'm afraid, so I can't tell how well it works; but sounds interesting indeed
[20:02] <bryce_> apw, thanks, good to see milestone support go in.  Merged and pushed
[20:05] <apw> bryce_, :)  thanks
[20:19] <cr3> hi folks, is there any particular reason why /var/lib/dpkg/info now has a subdirectory for the architecture?
[20:21] <cr3> as a follow up question, is there a proper way to get the path of the templates file for a given package programmatically, ideally using the debconf python package
[20:21] <ogra> cr3, multiarch \o/
[20:24] <cr3> ogra: and there was much rejoicing!
[20:26] <cr3> ogra: where is the arch taken from? I would expect it to be taken from the package but, in this particular case, the package has architecture: all. so, is it taken from the distro, ie dpkg --print-architecture?
[20:27] <james_w> Daviey, ogra: ok, it's been restarted now, and is chewing on kbarcode
[20:28]  * Daviey waits with hope
[20:28] <slangasek> architecture: all packages are treated as equivalent to the host arch for all intents and purposes
[20:28] <ogra> james_w, so what will it do ?
[20:28] <james_w> let's find out :-)
[20:28] <Daviey> lol
[20:29] <ogra> cr3, meet slangasek, the ,master of da multiarch ;)
[20:29] <cr3> ogra: awesome, I'm in the presence of the right person to do the right thing :)
[20:29] <ogra> *g*
[20:30] <slangasek> cr3: the proper way to get the templates file path is with 'dpkg-query --control-path $pkg templates'
[20:30] <cr3> slangasek: so, I have an install script in python that had /var/lib/dpkg/info hard coded in order to obtain the templates file for a given package. might there be an appropriate way to get that path short of /var/lib/dpkg/info/$(dpkg --print-architecture)/...?
[20:30] <cr3> slangasek: thanks, you answered quicker than I could ask the question more clearly :)
[20:30] <slangasek> ;)
[20:31] <slangasek> note that the current architecture subdirectories are probably not sticking around after all, per followup discussions with dpkg upstream today
[20:31] <slangasek> so definitely don't hardcode any architecture paths - but 'dpkg-query --control-path' is a stable interface
[20:35] <james_w> Daviey, ogra: it saw that the branch didn't match the upload, and when to uncommit in the branch, replace it with an import of the upload, and then propose a merge on Launchpad to include Daviey's changes in to the next upload
[20:35] <james_w> however, somewhere in the middle of that it hit a bzr bug :-(
[20:35] <Daviey> james_w, it all sounded so awesome :)
[20:35] <ogra> yeah
[20:35] <james_w> so it worked as designed, and would have noticed the problem and dealt with it appropriately, we just need to get that fix rolled out
[20:36]  * ogra comforts james_w 
[20:36] <Daviey> james_w, I am honestly impressed you planned for this scenario :)
[20:36] <james_w> it was going to happen one day :-)
[20:36] <Daviey> heh
[20:36]  * ogra expected such planning ... we have the most awesome people around ;)
[20:37] <james_w> https://code.launchpad.net/~spiv/bzr/repository-user-url-false-alarm-726584-2.3/+merge/51702 if you care
[20:37] <Daviey> james_w, so package-importer has access to the raw branches on bazaar.lp.net ?
[20:37] <james_w> so, I'll do it by hand for now so that we don't get confusion from that branch
[20:37] <james_w> yeah
[20:37] <Daviey> james_w, ahhhh!
[20:38] <Daviey> i just assumed it was a totally seperate entity with the same access as us
[20:39] <james_w> Daviey, well, it doesn't go behind the scenes or anything, but it has write access to all Ubuntu branches
[20:39] <Daviey> sometimes I wish i had uncommit access to branches :)
[20:40] <ogra> you do
[20:40] <ogra> you should use it, but we all do :)
[20:40] <Daviey> like the feeling of, 0.05msec after typing rm -rf /
[20:40] <ogra> err s/should/shouldnt/
[20:42] <Daviey> so we do!  I didn't know that
[20:45] <james_w> https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/kbarcode/collision/+merge/51809
[20:45] <Daviey> james_w, you create it by hand?
[20:45] <james_w> unfortunately I just beat the importer so Launchpad hasn't seen the new revision yet
[20:46] <james_w> yeah, I just did that by hand because of the bug
[20:47] <Daviey> james_w, /me Disapproves it :) ...   Out of interest, who should have been invited to review if it had of worked automagically?
[20:48] <james_w> Daviey, I think no-one currently actually, it should be ~ubuntu-dev
[20:48]  * james_w checks the code
[20:48] <maco> is there a way to tell launchpad "when a merge request is made for an ubuntu packaging branch, email me"?
[20:49] <maco> or is going to sponsor queue webpage the only way to find out?
[20:49] <Daviey> james_w, I wonder if directly inviting the latest uploader, and the uploader of the one that lost the race (me), makes sense to help people identify it?
[20:49] <james_w> Daviey, yeah. We don't have their LP accounts readily available at that point I don't think
[20:50] <james_w> we could get the uploader, but not the pusher, as I don't think LP stores that
[20:50] <micahg> maco: if it's a specific package, I think you can subscribe to the branch
[20:51] <james_w> we could do email address lookup as a heuristic
[20:51] <Daviey> james_w, Person.getByEmail() ?
[20:51] <ogra> but you would need the adress attached to your gpg key in LP
[20:51] <ogra> assuming you look for the signing person
[20:51] <james_w> Daviey, yeah, but that's not 100% is it?
[20:52] <james_w> Daviey, and the email address known to bzr isn't guaranteed to be known by LP either
[20:52] <Daviey> I guess not... esp if people don't use DEBEMAIL in commits
[20:52] <Daviey> james_w, best effort++
[20:52] <micahg> warning the uploader should be sufficient, if the uploader won't follow up, I think we have bigger issues
[20:53] <Daviey> james_w, launchpad *does* have a pretty good idea who uploaded (last entry in d/changelog) and the signer for a given archive package tho.
[20:53] <Daviey> I suspect you knew that. :)
[20:53] <james_w> yeah, and we can actually get that without email address lookup I think
[20:53] <Daviey> yup
[20:53] <james_w> I'm just doing the two minute thing right now, and leaving a comment for the improvements
[20:54] <james_w> I'll file a bug and see if someone on the bzr team can pick it up as well
[20:54] <Daviey> james_w, you are a hero!
[20:54] <ogra> he is, isnt he !!!
[20:56] <poolie> hi james_w
[20:56] <james_w> hi poolie
[20:56] <poolie> and all
[20:56] <maco> micahg: im subscribed in lp to packages i maintain in debian, but subscribing to all of universe seems....time consuming
[20:57] <james_w> https://code.launchpad.net/~james-w/udd/ubuntu-dev-review/+merge/51815
[20:57] <micahg> maco: yeah, that wouldn't be good
[20:57] <james_w> maco, there is the ubuntu-reviews mailing list
[20:57]  * poolie looks
[20:58] <ogra> maco, slacker !
[20:58] <james_w> https://lists.ubuntu.com/archives/ubuntu-reviews/2011-March/thread.html
[20:58] <james_w> which isn't exactly what it says on the tin, but will get mail about lots of merge proposals
[20:58] <james_w> for subscribing to universe that would be an LP change I think
[21:06] <ogra> @pilot out
[21:18] <poolie> james_w, maco, so the basic thing is you want a kind of subscription just to packages you recently touched?
[21:18] <james_w> poolie, I won't speak for maco, but that would be a useful thing to have
[21:18] <james_w> poolie, but I can see a use for e.g. subscribing to everything in a package set
[21:19] <poolie> maco, can you tell me more about what you'd want lp to do?
[21:20] <poolie> james_w, that patch looks fine of course, though i wonder if people will think it generates too much spam
[21:20] <james_w> poolie, email spam?
[21:20] <poolie> yes
[21:20] <poolie> but if you think it's a good incremental step that's ok with me
[21:20] <poolie> shall i file a bug for the full thing?
[21:20] <poolie> was maco talking specifically about mps from udd?
[21:23] <james_w> poolie, as noted in the merge proposal this should only generate new email to a catch-all mailing list, except if people have opted in to specific branches
[21:24] <james_w> so I don't think that will be a concern
[21:28] <cjwatson> gah, if libnih made stderr line-buffered at high debug levels or something, this would be a lot easier
[21:36] <poolie> isn't it by default? or does it replace the standard c behaviour?
[21:37] <cjwatson> hm, stderr is unbuffered by default, but I'm definitely not seeing that heere
[21:37] <cjwatson> *here
[21:39] <cjwatson> this is but a yak I'm shaving, so I don't want to focus on it too much
[21:45] <RoAkSoAx> sdsdf/win 3
[21:46] <maco> poolie: i dont know what mps means
[21:46] <maco> poolie: im talking about merge requests on launchpad for udd branches resulting in emails without manually subscribing to 15,000 packages
[21:47] <maco> poolie: recently touched would be handy, yeah, but i was just thinking about a "email me for merge requests on things i can upload" checkbox, though i dont really know if lp is aware of PPUs and such
[21:48] <poolie> i think it is
[21:48] <poolie> _can_ upload would be interesting
[21:48] <poolie> so core-dev would get mail about everything if they tick that box?
[21:49] <maco> or have a list of your can-uploads and a list of existing package sets and a "select all" button
[21:49] <maco> erm a list of package sets to which you have access, i mean
[21:49] <maco> so you can mass-subscribe to chunks
[21:50] <maco> or in core-dev's case, they could have as one of their options "main only" if they wanted
[21:52] <cjwatson> ah, there, nih debug output goes to stdout not stderr
[21:52] <cjwatson> that would explain the lack of buffering
[22:03] <chrisccoulson> seb128, were you still having menu issues in pidgin btw?
[22:11] <seb128> chrisccoulson, yes, corner case though
[22:12] <seb128> chrisccoulson, if you open the dialog which lists the accounts and try to enable one which doesn't have it pwd stored
[22:12] <seb128> you get a password dialog
[22:12] <seb128> then close it and or enter a pwd as you want
[22:13] <seb128> then go back to the buggy list
[22:13] <seb128> the account menu then only lists one menu entry