[00:05] <infinity> xnox: If this boost merge is yours, why does it ScottK's name in the changelog? :P
[00:07] <infinity> xnox: Err, nevermind, I was looking at the changelog after patching with --dry-run.  I'm not awake.
[00:07] <infinity> La la la
[00:23]  * micahg pokes infinity with the -v stick
[00:38] <cjohnston> cjwatson: fwiw, on the 31st we will delete the quantal db and the graphs will be started over, so you probably don't need to worry about the trend line for now
[01:18] <cjwatson> cjohnston: ack, it was just a temporary tweak really
[01:24] <cjohnston> thats fine.. just letting you know
[01:38] <vibhav> Good Morning
[03:18] <scientes> who has the link to the unity hello world app
[03:18] <scientes> i remember it being in python
[03:19] <micahg> scientes: https://launchpad.net/hello-unity
[04:08] <pitti> Good morning
[05:51] <roshan> Hello, I was compiling a kernel in Ubuntu 12.04 as specified in one of the Ubuntu help pages.
[05:52] <roshan> A particular section says to enale "A particular section on the tutorial askes me to enable "Kernel module loader" , but I couldn't find any
[05:52] <roshan> Where could I find that ?
[06:37] <larsduesing> good morning, is here anybody who is sort of firm with apport-hooks?
[06:38] <pitti> larsduesing: I should be :)
[06:39] <vibhav> heh, pitti is being humble
[06:39] <larsduesing> Ah :)
[06:39] <larsduesing> hi pitti :)
[06:39] <larsduesing> arghs, we had pastebin here?
[06:41] <larsduesing> pitti: would you please have a look at that: http://pastebin.com/Y8D9u5yY
[06:42] <vibhav> larsduesing: Which package is this hook for?
[06:42] <larsduesing> the last two lines - how can I find out, if the specified reports are actually made, so that I only start masking for available reports?
[06:42] <larsduesing> aiccu
[06:42] <pitti> larsduesing: (looking in a bit, still reviewing an SRU)
[06:42] <larsduesing> oh, sorry, take your time :)
[06:46] <pitti> larsduesing: what do you mean with "if the reports are actually made"?
[06:48] <larsduesing> the first report is only made, if a dpkg install fails
[06:48] <vibhav> Is it fine to SRU "Wishlist" bugs?
[06:49] <dholbach> good morning
[06:50] <larsduesing> good morning dholbach
[06:50] <pitti> larsduesing: I'm afraid I still don't understand the problem
[06:50] <pitti> larsduesing: you can /msg me in German if that helps
[06:50] <dholbach> hi larsduesing
[06:51] <pitti> hey dholbach, wie gehts?
[06:52] <vibhav> hi
[06:52] <vibhav> dholbach: Is it fine to SRU "Wishlist" bugs?
[06:52] <dholbach> pitti, hey hey - alles gut und bei Dir?
[06:52] <dholbach> vibhav, no
[06:52] <dholbach> vibhav, either they are important or they're not SRUs :)
[06:52] <vibhav> oh ok
[06:52] <dholbach> https://wiki.ubuntu.com/StableReleaseUpdates has some decision making help
[06:57] <pitti> dholbach: prima, danke!
[07:46] <larsduesing> https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-apport-fix <- so I should use "Propose for merging" now, shouldn't I?
[07:57] <alkisg> Any good tools for writing man pages? Is docbook + po4a a good choice, in order to have them translatable in launchpad etc?
[08:18] <vibhav> Could anybody nominate https://bugs.launchpad.net/ubuntu/+source/glom/+bug/736913 for maverick?
[08:19] <vibhav> oh wait, maverick's EOL
[08:20] <vibhav> Could somebody nominate it for natty?
[08:22] <Daviey> vibhav: Can you explain the impact?  It feels like a 'won't fix' for Natty IMO.
[08:23] <pitti> yes, I agree; this is absolutely unimportant for natty now
[08:32] <vibhav> Daviey: Ill agree with you then
[08:35] <dupondje> Some question about virt-manager. Are all the current deps needed? Cause I don't know why I should need bridge-utils and ebtables for example if I just want to admin a remote server.
[08:42] <seb128> bdmurray, hey, those "Missing SRU information" bot comments, what do you check for?
[08:42] <henrix> pitti: hi, any chances of having a look at kernel linux-ec2 2.6.32-345.48?
[08:43] <henrix> pitti: we need to upload a new version into proposed, but this one is on our way
[08:53] <pitti> henrix: I'll try; please note that I formally left the SRU team
[08:54] <henrix> pitti: oh, sorry. didn't knew that. any idea about who shall i bother next time? :)
[08:56] <pitti> henrix: RAOF and SpamapS do regular SRUs
[08:56] <henrix> pitti: ack, thanks.
[08:57] <onosendi> I'm using mate with marco as my WM. How would I go about getting the geometry of a window when it is closed? It's x, y, w, h, etc?
[09:00] <pitti> henrix: promoted
[09:01] <henrix> pitti: great, thanks
[09:10] <larsduesing> btw, dumb question: does anybody use any other urgency as "low" in changelogs (maybe except security ones?)
[09:11] <larsduesing> and if yes: when it is advisable to do so?
[09:12] <pitti> larsduesing: the urgency is entirely ignored in ubuntu; it should be kept as "low" in general
[09:13] <Daviey> cjwatson: I assume you saw mjg59's EFI related blog post?
[09:16] <larsduesing> ok, thanks pitti
[09:17] <larsduesing> btw, pitti: branch is done: https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-apport-fix/+merge/107351 (maybe it should be even a "security" fix, because of possible information disclosure...)
[09:26] <seb128> diwic, hey
[09:39] <diwic> seb128, pong
[09:39] <seb128> diwic, hey, how are you?
[09:40] <diwic> seb128, I'm okay, how are you?
[09:40] <seb128> diwic, asac reported bug #1004384 and I can confirm it with a bt device, could you advice on whetever pulseaudio debug infos would be useful for it?
[09:40] <seb128> diwic, I'm good thanks
[09:40] <diwic> seb128, hey, I fixed that an hour ago, as I found it myself :-)
[09:41] <seb128> asac, ^
[09:41] <diwic> I think so at least, judging from the title only
[09:41] <seb128> diwic, great!
[09:41] <asac> diwic: have the patch?
[09:41] <asac> i can tryu ... hav ethe built tree here
[09:41] <asac> debdiff preferrred
[09:42] <diwic> seb128, I spent much of yesterday rewriting the profile get/set stuff, tested it some more this morning, that's when I found the bug
[09:42] <cjwatson> Daviey: have now ... if only I had time to do something useful about it
[09:43] <cjwatson> pitti: the urgency isn't *entirely* ignored, it has a tiny effect on build scoring - but yeah, not much :)
[09:43] <Daviey> cjwatson: yeah :(
[09:44] <seb128> diwic, do you have a patch,diff somewhere we could try?
[09:45] <diwic> seb128, asac, now pushed to http://bazaar.launchpad.net/~diwic/+junk/soundnua-lp984637/revision/33
[09:45] <seb128> diwic, thanks
[09:45] <diwic> seb128, note that r32 of that branch is my profile rewrite, which might need more testing before releasing, so just take the r33 patch
[09:46] <cjwatson> Need more installer team people who care about Macs
[09:46] <cjwatson> And have any time at all
[09:46] <diwic> seb128, at least that makes input look like output codewise, and it fixes the crash, so assuming it's the right thing to do, might wanna double-check with cjcurran when he comes back
[09:52] <xnox> cjwatson: i have an old intel 32bit macbook, but it can't run Lion and up.
[09:57] <seb128> diwic, could you add the diff to the bug report? that will be needed to SRU it, I will look to that
[09:57] <seb128> diwic, thanks!
[09:57] <seb128> asac, let me know if you try the patch
[10:00] <pitti> cjwatson: oh, I didn't know that; thanks!
[10:02] <diwic> seb128, what type of diff would you like
[10:03] <seb128> diwic, standard unified diff over the current precise version (i.e over ronoc's vcs)
[10:03] <seb128> diwic, i.e something we can apply with patch to our current package
[10:13] <diwic> seb128, asac debdiff for precise-proposed added to bug
[10:24] <Daviey> lool: https://launchpad.net/ubuntu/+source/btrfs-tools/0.19+20100601-3ubuntu2 still seems to be a delta with Debian... is this really warranted ?
[10:25] <cjwatson> Daviey: xnox is working on that
[10:25] <cjwatson> (the merge I mean)
[10:26] <xnox> Daviey: I did a merge it's sitting in the sponsor's queue. The delta is still warranted
[10:26] <xnox> see the merge bug discussions.
[10:26] <xnox> between me and other contributors.
[10:26] <Daviey> ah, neat
[10:27] <xnox> Daviey: there is also mdadm and e2fsprogs bugfix/merge in the queue if you are up for it =))))
[10:28] <Daviey> xnox: i see you asked slangasek for a review... i wouldn't want to step on his toes or anything :P
[10:29] <xnox> Daviey: I'm sure slangasek wouldn't mind if somebody else does review/upload
[10:29] <asac> seb128: diwic: ack. crash is gone
[10:29] <seb128> asac, things work as well?
[10:29] <seb128> asac, i.e can you configure your bluetooth?
[10:29] <asac> seb128: yes, i can select it and it seems it uses the bluetooth input afterwards ... let me try a few more things
[10:29] <xnox> Daviey: btrfs-tools is on this list http://qa.ubuntuwire.org/oldmerges/
[10:32] <asac> seb128: all good ... all input and output channels work ... and i can use bluetooth and switch between high fidelity and telephony profile
[10:33] <asac> seb128: i tried the patch though by manually moving the return;
[10:33] <asac> i have no input of the complete branch
[10:33] <seb128> asac, diwic: thanks, I will test build it there and get it SRUed
[10:33] <asac> rock
[10:33] <asac> :)
[10:33] <asac> i have a good one with debug symbols now :)
[11:14] <pitti> tseliot: hey Alberto, how are you?
[11:14] <tseliot> pitti: hey Martin, fine thanks, you?
[11:14] <pitti> tseliot: you said you had a hybrid nvidia system, right? i. e. right now "ubuntu-drivers list" should show the nvidia drivers, but we are supposed to hide them, right?
[11:14] <pitti> tseliot: I'm great, thanks! Looking forward to the long weekend (Monday is national holiday)
[11:15] <tseliot> pitti: yes, I have a hybrid system here. Well, we shouldn't always hide them
[11:15] <pitti> that's at least what the current jockey handler does
[11:16] <pitti> if "intel" is loaded by X.org, it doesn't offer the nivida driver
[11:16] <tseliot> pitti: lucky you (no nationaly holday here)
[11:16] <pitti> I'm going to add that special-case to u-d-common
[11:16] <tseliot> pitti: right, let keep doing that for now. There's a special case we need to cover but it can wait
[11:32] <Daviey> xnox: comment added
[11:33] <xnox> Daviey: thanks
[11:34] <Daviey> xnox: if you are happy with my comment, i'll just upload it here.. no need to bother fixing in bzr
[11:34] <pitti> tseliot: are you currently using the intel or nvidia driver in X.org?
[11:34] <pitti> tseliot: I pushed this to git now with a test case, but if you could pull, build, and double-check "ubuntu-drivers debug", that'd be nice
[11:35] <xnox> Daviey: yes please upload. I don't like leading slashes either... and it was not me who introduced the link =))) I will comment on the bug report to the other contributor.
[11:35] <tseliot> pitti: the nvidia driver but only because I can select the graphics card from the BIOS. Not all laptops have this feature
[11:35] <pitti> tseliot: runnign "PYTHONPATH ./ubuntu-drivers debug" will do fine
[11:35] <tseliot> pitti: sure
[11:35] <pitti> tseliot: ah, cool
[11:35] <xnox> Daviey: yes, please upload! it will unblock a couple of workitems for the btrfs spec ;-)
[11:35] <pitti> tseliot: so in your current setup it should still show the nvidia driver
[11:36] <tseliot> pitti: would this work in precise?
[11:37] <pitti> tseliot: it should
[11:37] <pitti> tseliot: the tests currently fail, I'll fix that
[11:38] <tseliot> pitti: ok, as the laptop has precise on it
[11:38] <Daviey> xnox: uploaded
[11:38]  * xnox 0/
[11:40] <xnox> Daviey: last time I have checked CEPHs mailing list w.r.t. btrfs I saw loads of people with bug reports & errors/warnings from btrfs as well as degraded performance after some time
[11:41] <pitti> tseliot: erk, git skills failure; really pushed now, with test case fix
[11:41] <tseliot> pitti: unmet build deps: python-aptdaemon.test (>= 0.43+bzr810-0ubuntu2~) gir1.2-packagekitglib-1.0
[11:41] <tseliot> pitti: I should probably upgrade to quantal
[11:41] <pitti> tseliot: that's fine
[11:41] <xnox> Daviey: do you have interest in btrfs for particular workloads/services?
[11:41] <pitti> tseliot: just run it out of the source tree
[11:41] <pitti> tseliot: PYTHONPATH ./ubuntu-drivers debug
[11:41] <tseliot> pitti: ah, ok
[11:43] <Daviey> xnox: tentative :)
[11:44] <lool> Daviey: the delta that you point at was required to have btrfs work ok with upstart + mountall
[11:45] <lool> Daviey: Back then I was playing with ARM btrfs images, and was getting at least one of the two bugs fixed in this upload; the other one had enough comments supporting the proposed fix that warranted the patch to be included IIRC
[11:46] <lool> Daviey: maybe upstream/the Debian package have been changed similarly in the mean time though
[11:46] <xnox> Daviey: there were not many folks from server/cloud at the https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-btrfs-requirements
[11:46] <pitti> tseliot: so it should list nvidia if you are on nvidia, and hide it if you are on intel
[11:46] <xnox> Daviey: any comments about btrfs in Ubuntu are welcome
[11:47] <pitti> tseliot: the test cases reproduce this fairly well, so I'm rather sure it's going to work, but oh well, theory and practice ... :-)
[11:47] <tseliot> pitti: it seems to work. Let me get you the output
[11:49] <tseliot> pitti: here you go: http://paste.ubuntu.com/1006259/
[11:50] <tseliot> very nice, BTW
[11:51] <Daviey> xnox: wilco
[11:51]  * xnox ?
[11:51]  * xnox Wilco is an American alternative rock band based in Chicago, Illinois. 
[11:52] <Daviey> will comply. :)
[11:52] <xnox> ah =) ok.
[11:52] <pitti> tseliot: ok, that's with nivida?
[11:52] <tseliot> pitti: yep
[11:52] <pitti> tseliot: good, thanks
[11:52] <pitti> I'll upload that and then wave good bye
[11:53] <tseliot> pitti: we have two more cases: 1) intel on and nvidia off; 2) both intel and nvidia on
[11:53] <pitti> tseliot: I thought 2) wasn't possible with current X
[11:54] <tseliot> pitti: well, both cards can be on but only one card can drive the display
[11:54] <tseliot> pitti: i.e. only one driver can be used
[11:55]  * tseliot -> lunch
[11:55] <pitti> splendid
[11:55] <tseliot> ;)
[11:55] <pitti> tseliot: so, see you next Tuesday, and enjoy the weekend!
[11:55] <tseliot> pitti: thanks, you too!
[11:55] <pitti> tseliot: I'll add apport hook (with u-drivers debug) etc. next week
[11:55] <tseliot> great :)
[11:55] <asac> diwic: noticed something odd ... i have two microphone input devices (webcam + built in) ... i need to set both explicitely to mute to really mute the input level in the sound preference area
[12:01] <diwic> asac, uhm, can you tell me what you did in more detail?
[12:01] <diwic> asac, how were you recording e g?
[12:02] <asac> diwic: i am not recording ... i am just looking at the control center. what i see is this:
[12:02] <asac> i make noise and the input indicator goes up (shows signal)
[12:02] <asac> i check the "mute" box
[12:02] <asac> still signal on noise
[12:03] <asac> i go to the other input device and check the mute box and signal is gone
[12:03] <asac> diwic: makes sense?
[12:04] <diwic> asac, right, sounds like the input level is taking its input from the wrong card essentially
[12:04] <asac> diwic: more background: i have a thinkpad in a dock; a built-in mic, a usb webcam mic and a bluetooth mic
[12:04] <asac> diwic: this problem seems to only affect the built in and usb mic
[12:04] <asac> diwic: well, but it feels it takes it from both, because it doesnt matter which card i mute
[12:04] <diwic> asac, can you verify which mic it seems to take its input from
[12:04] <diwic> asac, by poking on the actual mic
[12:04] <asac> diwic: no... as i said: doesnt matter in which order
[12:04] <asac> ok
[12:04] <asac> i can try
[12:05] <asac> one sec
[12:05] <asac> diwic: yeah. always from the usb mic
[12:06] <asac> diwic: but if i have both mute checkboxes selected it gets disabled :)
[12:06] <asac> thats the fun part
[12:07] <asac> maybe something caused by dock rerouting magic?
[12:08] <diwic> asac, so if you have the usb mic selected it takes the signal from the usb mic, but muting *only* the usb mic would not mute the signal?
[12:09] <asac> diwic: restarting fixed it i think :/
[12:09] <diwic> asac, ok, let cjcurran know if it's reproducable
[12:10] <asac> yeah. how weird :)
[12:12] <mr_pouit> cjwatson: quantal/i386 daily builds for Xubuntu fail because cdrom/non-pae/initrd.gz doesn't exist (the non-pae kernel was dropped I think). Could you do some magic again please? (do you prefer that I file a bug report?) Thanks. ;-)
[12:13] <cjwatson> mr_pouit: Oh yes, I can just fix that now
[12:13] <cjwatson> Thought I'd caught everything, evidently not
[12:16] <cjwatson> mr_pouit: done
[12:16] <mr_pouit> cjwatson: awesome, thanks!
[13:21] <bdmurray> seb128: the bug matches my expectations now although I expanded the test case section a bit
[13:22] <seb128> bdmurray, thanks
[13:24] <seb128> SpamapS, hey, is there any chance you could do some SRU reviews today? ;-)
[13:25] <psusi> cjwatson: there are a few bug reports that I think are caused by a size increase in the grub2 core image that makes it too large to fit in 62 sectors when including raid and lvm modules.  Is this just a too bad, you need more room, in which case it bears mentioning in the release notes?
[13:28] <zul> mterry: ping dwarves builds fine now
[13:28] <mterry> zul, was just about to look at it
[13:29] <cjwatson> psusi: Sometimes it's fixable, it depends ... I generally think it's a bug although not necessarily a straightforward one
[13:30] <cjwatson> Although I'd advise people to put their first partition at 1MiB rather than at sector 63 these days; much more efficient on modern disks, and no less efficient on disks since about oh 1985 or something
[13:30] <cjwatson> Of course I realise it's tedious to move partitions
[13:30] <psusi> cjwatson: indeed... but it seems some people are upgrading old setups from 10.04 and still have partitions starting at sector 63
[13:31] <psusi> cjwatson: it seems that the image with both raid and lvm built in is now something like 200 bytes too large to fit in that space
[13:34] <cjwatson> This is probably fixable but I'm afraid I don't have time for the next month or two
[13:48] <apw> jodh, is there a simple way to tell from upstart --verbose output which thing we are waiting on
[13:48] <apw> jodh, for a han
[13:48] <apw> jodh, for a hanging boot
[13:48] <jodh> apw: try http://upstart.ubuntu.com/cookbook/#establish-blocking-job
[13:50] <jodh> apw: can you send me a log when booting with --debug ?
[13:50] <apw> jodh, the end user is talking to us on #ubuntu-kernel now
[13:54] <apw> jodh, http://sprunge.us/iGaU
[13:56] <apw> jodh, for me i think its wiating on mountall ... perhaps mismatched UUID
[14:00] <tjaalton> is it ok to add build-depends on a SRU release, to fix obvious omissions in the packaging? :)
[14:00] <seb128> tjaalton, yes
[14:01] <seb128> tjaalton, well adding build-depends is ok, turning on feature which were not is subject at review and rational
[14:01] <tjaalton> seb128: yeah, of course. minor features but something that should've been enabled.. and have been on other distros
[14:02] <seb128> tjaalton, well, the fact that they should doesn't change that they didn't get tested so it's not a trivial wave in change
[14:03] <tjaalton> seb128: it'll get tested before the push
[14:04] <seb128> tjaalton, right, well anyway I was just saying, adding build-depends is not something against the rules ... are those build-depends in the same pocket btw?
[14:04] <tjaalton> seb128: the package is in universe, so no problem there
[14:05] <tjaalton> package which is being sru'd
[14:05] <seb128> ok
[14:17] <stgraber> mvo: hey there, I was talking with jibel about getting automated upgrade testing up and running for Quantal. What's still required to get do-release-upgrade happy?
[14:18] <mvo> stgraber: the release-upgrader is currently defnct due to the py3 porting in trunk once that is resolved there is nothing blocking it
[14:20] <stgraber> mvo: ok. Who's doing the py3 port?
[14:21] <cjwatson> That would be me
[14:21] <SpamapS> seb128: I did some w/ bdmurray who is training to be an SRU team member yesterday. Between he and I, and slangasek, we didn't get your SRU's reviewed?
[14:21] <cjwatson> I'll try to get that sorted out - mvo, is there an easy way I can reproduce the problems?
[14:21] <mvo> stgraber: I meant to look at it this week, but couldn't quite find the time
[14:21] <mvo> cjwatson: yeah, cd DistUpgrade; sudo ./dist-uprade.py will fail
[14:23] <cjwatson> OK, thanks
[14:24] <bdmurray> SpamapS: we did review one of his and he's updated it now and it looks good to me
[14:26] <SpamapS> bdmurray: bug #?
[14:26] <apw> cjwatson, i just installed a kernel and extras together and got an unexpected result: http://paste.ubuntu.com/1006472/ see the last line there
[14:27] <cjwatson> apw: Looks like a bug in your postinst
[14:28] <bdmurray> SpamapS: bug 980317 for gnome-control-center
[14:28] <cjwatson> apw: Though actually, maybe not, try 'sudo dpkg --configure -a'
[14:28] <cjwatson> Might just be a pending trigger
[14:28] <apw> nothing happened
[14:29] <cjwatson> case "$DPKG_MAINTSCRIPT_PACKAGE" in
[14:29] <cjwatson> linux-image-*)
[14:29] <cjwatson> hm, so maybe update-initramfs needs to exclude linux-image-extra-* from that since that behaves differently
[14:30] <cjwatson> I don't suppose I can convince you to not call it something matching linux-image-*? :-P
[14:30] <apw> cjwatson, yeah i was seeing the same lines ...
[14:30] <apw> cjwatson, well i guess we can call it anything you like :)
[14:30] <cjwatson> If it didn't match that wildcard you wouldn't have a probem
[14:30] <cjwatson> *problem
[14:30] <SpamapS> bdmurray: so, +1 to accept that upload?
[14:31] <apw> cjwatson, so either we change the name or fix the trigger ... ok thanks
[14:31] <apw> cjwatson, its possible we should be calling the hooks later anyhow as we carry half of the kernel
[14:32] <bdmurray> SpamapS: yes
[14:32] <SpamapS> bdmurray: I concur. Pulling lever... you want to run sru-accept?
[14:33] <bdmurray> SpamapS: yes will do
[14:33] <cjwatson> apw: Maybe, though I'd have thought the ordinary trigger would be sufficient
[14:34] <apw> cjwatson, well let me think, iirc the generic trigger is unperameterised and triggers a rebuild of the running kerenl initramfs, and this is specificall not for the running one in the majority of cases
[14:35] <SpamapS> bdmurray: did you notice bug 1004384 was also still missing SRU headers?
[14:35] <cjwatson> Oh, true, you want a specific version here
[14:35] <cjwatson> So maybe you might as well just use your initramfs hook and then it would all be well
[14:35] <cjwatson> Since indeed the trigger won't do the right thing
[14:36] <SpamapS> bdmurray: I accepted anyway, but that one probably needs impact/regpotential/etc. as well
[14:36] <SpamapS> seb128: ^^
[14:36] <apw> cjwatson, ok will work on that, i presume i just need to run the kernel postint.d hooks as normal
[14:36] <SpamapS> I think its probably time we sent an email out to ubuntu-devel about SRU headers
[14:36] <SpamapS> too many people are uploading without following that bit of the process.
[14:37]  * SpamapS goes to make pbreakfast
[14:37] <SpamapS> pbreakfast - a clean chrooted breakfast
[14:39] <cjwatson> apw: I think so
[14:41] <apw> cjwatson, i suppose this will mean we will rebuild the initramfs twice for every kernel which isn't ideal
[14:41] <apw> cjwatson, i suspect to avoid that properly we will want to have the initramfs trigger perameterisable
[14:41] <cjwatson> Yeah, I'm having a slightly difficult time thinking about how to avoid that
[14:42] <cjwatson> Well, it's technically possible; we could queue up the initramfs versions to rebuild in a file in /var and have the trigger process that
[14:42] <cjwatson> That kind of thing is the usual way to pass data through the trigger interface
[14:42] <apw> cjwatson, would it be reasonable to generate a list somewhere and ... yeah that
[14:43] <apw> cjwatson, ok so for now i will bodge it to make it do both and take an action to make it perameterisable; where is appropraite in /var, is there a defined spot ?
[14:43] <cjwatson> I wonder if there are things that currently assume that some kind of initramfs exists immediately after the kernel is configured
[14:43] <cjwatson> Hopefully not ...
[14:43] <cjwatson> /var/lib/initramfs-tools/ I guess
[14:43] <apw> ok ... thanks ... sigh why is nothing every easy
[14:43] <cjwatson> It should be per-package in any event
[14:46] <apw> cjwatson, i suspect if we delay initramfs build to the end, then grub configure will have to be as well, so there is in initramfs for it to link to
[14:46] <apw> there is bound to be untold fallout ...
[14:46] <apw> but anyhow i can do the framekworks and we can iterate on the issue
[14:48] <cjwatson> apw: Mm, that's a bit scary
[14:48] <cjwatson> apw: The trigger could put an empty initramfs in place, maybe
[14:48] <cjwatson> Just so there's *something*
[14:48] <apw> cjwatson, yep ... thats what i am thinking ... yeah that might work, ick
[15:02] <seb128> SpamapS, bdmurray: hey, some GNOME ones are sitting in the queue for some days, no hurry but they are mostly trivial ones and fix reported bugs ... if they are stalled because the "paperwork" is insuffisant to your taste please state it on the bugs rather than just keeping them sitting in the queue ;-)
[15:33] <seb128> cjwatson, slangasek: is there a way to turn off multiarch for dh compat 9 level packages?
[15:33] <slangasek> seb128: pass -- --libdir
[15:33] <slangasek> to dh_auto_configure
[15:33] <seb128> tkamppeter, ^ or that
[15:34] <slangasek> why are you turning it off, though? :)
[15:34] <seb128> slangasek, I suggested to downgrade compat to 8 but I figured there would be a better way :p
[15:34] <seb128> slangasek, because it's a cups driver and cups is not multiarched
[15:34] <slangasek> ah
[15:34] <slangasek> good reason :)
[15:34] <seb128> slangasek, i.e it doesn't look in the multiarch dir
[15:35] <slangasek> yeah, this is probably a case where it doesn't make sense to ever multiarch
[15:35] <slangasek> also, it's probably --libexecdir wanted here, not --libdir, right?
[15:35] <slangasek> (helper executables - not DSOs)
[15:37] <seb128> right
[15:37] <seb128> slangasek, thanks
[15:37] <slangasek> I've actually wondered if pointing --libexecdir at the multiarch dir by default was a mistake... too late now to change it for compat 9 though :/
[15:43] <seb128> bdmurray, why is your bot randomly going through bugs and deleting some of the apt log files?
[15:44] <bdmurray> seb128: its not random and its because of an update-manager cve
[15:46] <seb128> bdmurray, ok, thanks, I was rather curious of the reason ;-)
[15:47] <bdmurray> seb128: sure, no problem
[15:47] <tkamppeter> slangasek, seb128, I have already tried "dh_auto_configure -- --libexecdir=/usr/lib", "dh_auto_configure -- --libdir=/usr/lib", "dh_auto_configure --libdir", "dh_auto_configure --libexecdir", all to no avail.
[15:48] <slangasek> tkamppeter: can you link me the package?
[15:48] <cjwatson> The third and fourth of those are unambiguously wrong
[15:49] <cjwatson> (I don't have an answer for you, but you might as well not waste your time on options that definitely won't work)
[15:59] <cr3> Is there a recommended PPA that might contain more python3 packages for Precise, like python3-openssl if such a thing exists?
[15:59] <SpamapS> seb128: we actually have been stating in the bugs when the paperwork is insufficient. ;) There have been well over 100 packages uploaded to precise-proposed in the last 2 days.. so please just be patient.
[16:00] <seb128> SpamapS, 85 of those being kde-l10n ones? ;-)
[16:00] <SpamapS> seb128: probably :)
[16:01] <seb128> SpamapS, but yeah, sure no hurry, though I blame a bit KDE for swamping the queue like that :p
[16:05] <SpamapS> seb128: agreed, KDE always seems to make a lot of work. Anyway, make sure you have all your impact/testcase/regression potential filled out, and we'll get through your bugs faster. :)
[16:05] <seb128> SpamapS, noted, thanks for the work!
[16:17] <tkamppeter> slangasek, it is ptouch-driver. Simply "apt-get source" it. Then try to add an override_dh_auto_configure to it.
[16:25] <cjwatson> infinity,cyphermox: Debian seems to have merged the wpasupplicant and hostapd source packages into a single wpa source package.  You two have outstanding Ubuntu modifications to the prior source packages; do you think one or both of you could merge those into the new one?
[16:26] <cjwatson> It's showing up for auto-sync, which I'm holding off on due to the Ubuntu changes.
[16:26] <cyphermox> cjwatson: sure.
[16:27] <roshan> Hello
[16:27] <cjwatson> cyphermox: thanks
[16:27] <cyphermox> infinity: I'll take your hostapd changes as well
[16:28] <cjwatson> slangasek: You're TIL for autoconf; do you think you could merge it, which will allow me to process the autoconf-nonfree removal?
[16:28] <roshan> I would like to build a custom Ubuntu from the minimal Ubuntu vrsion.
[16:28] <roshan> I plan to use the 11.10 version
[16:28] <roshan> My question is, how to I dd the basic necessary packages like networking, desktop, apt-get , and all the basic stuff ?
[16:29] <roshan> *add
[16:32] <sladen> roshan: look up "Ubuntu Customisation Kit"
[16:33] <roshan> thank you. Let me check that
[16:34] <infinity> cyphermox: Sure, it was a small change.  Thanks.
[16:34]  * infinity wasn't even aware those were from the same upstream, though it makes some sense.
[16:34] <roshan> Does UCK support command line ?
[16:35] <gyotoit22> http://www.reddit.com/r/nsfwhot/comments/u0upg/young_teen_brutal_fucked_by_two_big_cocks/
[16:37] <cjwatson> apologies for that intrusion
[16:37] <cyphermox> infinity: wouldn't the migration /lib/init/rw -> /run migration check work as well with just adding || true?
[16:38] <cyphermox> I mean, so that postinst doesn't bomb if it's trying to move a file to the same destination as it already was
[16:39] <infinity> cyphermox: Possibly, I don't remember the original code (or my modifications, for that matter).  I don't usually like to mask over errors in symlink/directory issues with || true, though, as there are corner cases that will give you nested directories and such that you really weren't expecting.
[16:40] <infinity> cyphermox: This may not have had one of those cases.  Like I said, I don't remember. :P
[16:40] <cyphermox> well, anyway I see this would probably avoid error messages anyway
[16:40] <cyphermox> gah, I'm repeating words today repeating
[16:40] <infinity> Heh.
[16:41] <infinity> (Heh.)
[16:42] <cr3> barry: if I'm wondering whether I can rely on some python3 package being available in quantal, like python-gst for example, where should I look for an answer instead of pinging you each time? :)
[16:43] <tumbleweed> xnox: so, what's happening with boost-source1.49?
[16:43] <xnox> tumbleweed: I am working on it. Didn't finish it yesterday evening.
[16:43] <xnox> tumbleweed: and I wanted to unbreak the rest of boost.
[16:44] <tumbleweed> cool. vtk is currently broken and waiting on boost to be unbroken first :)
[16:44] <xnox> tumbleweed: I am "in charge" of boost1.49 transition =) and I hope to get it finished before alpha1. Note some of the build-failures are due to gcc4.7 and affect debian as well.
[16:44] <xnox> tumbleweed: awesome =) I bet everyone loves broken vtk =)
[16:44] <tumbleweed> naah, that's it's steady state
[16:44]  * xnox "we will not break quantal" meh =)
[16:45] <barry> cr3: if you know the python 2 version of the package, just search for python3-<whatever>
[16:48] <roshan> Does Ubuntu Customiation kit allows us to change the look of the Ubuntu ?
[16:48] <cr3> barry: of course but, if it's not there now, is there a roadmap for quantal?
[16:50] <sladen> roshan: you can change anything you want in Ubuntu.  The amount of customisation you'll get  depends on the amount of effort you're able/prepared to put into it
[16:50] <barry> cr3: only if it's required for the desktop cd.  if not, work isn't scheduled, but i am always happy to review ports
[16:50] <roshan> okay
[16:52] <infinity> cr3 / barry: In the case of python-gst it's on the desktop CD (apt-cache show python-gst0.10 | grep ^Task), so that answers your question.
[16:53] <barry> infinity, cr3 it's in the spreadsheet: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AiT4gOXSkmapdFA1anRkWERsaXgtWnllUG9QWXhDVWc&pli=1#gid=0
[16:53] <infinity> (That too)
[16:53] <cr3> barry, infinity: awesome, thanks folks!
[16:53] <barry> infinity, cr3 the suggestion though is to port anything on the desktop to pygi and get rid of the gst dependency :)
[16:53] <xnox> barry: and no, the tracker update is not trigger from the spreadsheet (yet)
[16:54] <ScottK> xnox: Does that mean you're working on boost-mpi-source1.49?
[16:54]  * xnox as you probably figured, due to commits from you
[16:54] <barry> xnox: that's okay, i figured out how to update the tracker :)
[16:54] <xnox> ScottK: unless you really want to =)
[16:54] <ScottK> xnox: No.  I'm glad you're doing it.  I took a first stab at it, it didn't work, and I've not had time to get back to it.
[16:54] <xnox> barry: now that I have access to people.c.c I will set up a cron job there.
[16:55] <ScottK> xnox: I have done the split before though, so if you have questions, I'm glad to assist if needed.
[16:55] <xnox> ScottK: ...thanks =)
[16:55] <barry> xnox: aweome, thanks
[16:55] <cr3> barry: I'll try to rewrite scripts depending on gst to use pygi instead of just migrating them to python3, thanks for the heads up
[16:55] <xnox> ScottK: ok, thank you.
[16:55]  * xnox is this the time when timezones meet
[16:56] <barry> cr3: fantastic.  i'm always happy to review
[16:56] <cr3> barry: I'm equally unfamiliar with both, so should be the same amount of work :)
[16:59] <infinity> barry: How does pygi relate to gst?  Or is it just that you can use pygi to talk to anything with gi bindings, thus elminating the need to have python bindings for every library?
[17:01] <dobey> infinity: the latter sort of
[17:02] <barry> i am not a pygi expert ;)
[17:02] <dobey> though i don't think gst is really usable from gi yet. though maybe gst 1.0 fixes that
[17:02] <dobey> hi barry
[17:09] <slangasek> cjwatson: yep, will do... sorry, I'd so far only looked at the list that launchpad's +localpackagediffs was showing my name for, and that list is... small
[17:10] <barry> dobey: hi
[17:11] <dobey> barry: so i am at the brink of having python-oauth 1.0.1 working on python3
[17:12] <dobey> barry: at least, it does work, except for 1 tiny problem which may be some insanity in the base http server stuff changing in 3
[17:12] <slangasek> tkamppeter: this works for me:
[17:12] <slangasek> override_dh_auto_configure:
[17:12] <slangasek>         dh_auto_configure -- --libdir=/usr/lib
[17:13] <ScottK> dobey: By definition, if it's different in Python 3, the insanity was in Python, not Python 3.  You've got it backwards.
[17:13] <ScottK> ;-)
[17:14] <dobey> ScottK: my standards dictate that if it's python, it is insanity, regardless of version. ;)
[17:14] <dobey> also, python-oauth is a pretty good example of things to not do in python
[17:14] <ScottK> Fair enough, but you'll make barry sad.
[17:15] <dobey> on the contrary, i think making python-oauth work in python3 will make barry quite happy :)
[17:15] <ScottK> True.
[17:17] <cjwatson> If you want to print Unicode text to sys.stdout, the insanity required is merely different in Python 3 :-/
[17:17] <cjwatson> (And not as bad, I'll grant)
[17:18] <cjwatson> sys.stdout = io.TextIOWrapper(sys.stdout.detach(), encoding="UTF-8", line_buffering=True)  # is the least awful approach I've found that's safe against LC_ALL=C, although not exactly pleasant
[17:21] <dobey> barry: are you in the debian python module maintainers team?
[17:21] <slangasek> cjwatson: heh, can that be documented somewhere?
[17:21] <slangasek> because that's going to come in handy in the future I'm sure :)
[17:27] <ScottK> dobey: He is.
[17:27] <cjwatson> barry: ^- perhaps you could document that on Python/3, or some alternative that's more right
[17:27] <dobey> ScottK: thanks
[17:28] <cjwatson> this is basically what you need if you have something that might ever run in LC_ALL=C (i.e. the default locale) and processes non-ASCII text
[17:28] <cjwatson> well, at least in a pipeline-based way
[17:28] <cjwatson> if it opens files and writes to those it's fine; Python makes an illogical distinction here
[17:28] <barry> cjwatson: good idea
[17:29] <barry> dobey: re python-oauth - that's fantastic, can i take a look at a branch?
[17:30] <dobey> barry: i'm working on getting a branch pushed
[17:30] <cjwatson> Oh, wait, that's not true about files
[17:30] <cjwatson> But at least with files you can open with an explicit encoding straight off
[17:31] <cjwatson> Still a bit of a gotcha though; I wonder if we need to do more explicit encoding= :-/
[17:31] <dobey> barry: do i need to do all the dh_overrride and python%-foo stuff to make python2 and 3 installs work, or does --with python2,python3 handle that automagically?
[17:31] <cjwatson> (Which is evil in its own way, though)
[17:31] <cjwatson> In ubiquity I perpetrated a hack that forces the locale to C.UTF-8 on startup if it's C; but that won't be appropriate for all applications
[17:32] <barry> dobey: for now, you'll need the overrides for py3, since dh doesn't handle that automatically
[17:32] <dobey> ok
[17:32] <barry> dobey: http://wiki.debian.org/Python/LibraryStyleGuide
[17:33] <tumbleweed> --with doesn't ever affect dh_auto_* AFAIK
[17:34] <barry> cjwatson: maybe you should subscribe to https://wiki.ubuntu.com/Python/3 ?
[17:35] <dobey> barry: yep, i'm looking at that. :)
[17:35] <cjwatson> Sure, done
[18:00] <dobey> dpkg-deb: building package `python-oauth' in `../python-oauth_1.0.1-4_all.deb'.
[18:00] <dobey> dpkg-deb: building package `python3-oauth' in `../python3-oauth_1.0.1-4_all.deb'
[18:00] <dobey> barry: ^^ :) pushing the branch now
[18:01] <barry> dobey: awesome.  so the main development branch will be the ubuntu branch?
[18:01] <barry> (dobey: that's fine, as long as vcs-bzr is up-to-date i think)
[18:02] <dobey> barry: oh no, i just made a patch
[18:02] <barry> dobey: k
[18:02] <dobey> barry: was hoping it would just be uploaded into debian that way :)
[18:03] <barry> dobey: how are you getting it into debian?  bug report?
[18:03] <dobey> barry: of course, this is completely untested in the Real World (TM) so far.
[18:03] <dobey> barry: i haven't filed a bug yet, but was hoping you could upload it there
[18:03] <dobey> barry: anyway, it's at lp:~dobey/ubuntu/quantal/python-oauth/python3-packages
[18:03] <barry> dobey: actually, i'm not a dd.  i can upload to ubuntu though
[18:04] <tumbleweed> it's usually best to give ports to upstreams first
[18:04] <dobey> oh, ScottK lied then :)
[18:04] <barry> tumbleweed: upstream is long abandoned
[18:04] <tumbleweed> ah
[18:04] <dobey> and i am not trying to become the upstream
[18:04] <barry> no no, me neither :)
[18:05] <barry> i'll test it and file a debian bug
[18:05] <ScottK> dobey: No.  I didn't.  Being a member of DPMT doesn't imply being a DD.  You can even join yoursef.
[18:05] <dobey> oh
[18:05] <ScottK> barry not being a DD is a bug in the system that he should, however, fix.
[18:05] <barry> ScottK: i am apparently "in the queue" for an am, but i think the queue is deep
[18:06] <ScottK> barry: If it's in DPMT, you can just commit to svn.
[18:06] <dobey> having a team that maintains a package, but for which people in taht team can't upload to, seems silly
[18:06] <barry> ScottK: good point, i'll check that
[18:06] <ScottK> barry: OK.  That's good to know.
[18:06] <dobey> ah, well if can commit to the svn that's a start i guess
[18:07] <ScottK> dobey: Having people work as a team and having them all be able to commit to the VCS aids sponsorship and getting stuff done.
[18:07] <dobey> now i wonder if i didn't totally break python-oauth with that patch
[18:09] <barry> dobey, ScottK http://anonscm.debian.org/viewvc/python-modules/packages/python-oauth/
[18:10] <ScottK> You might want to email TANIGUCHI Takaki as well.
[18:10] <dobey> oh, fail
[18:11] <dobey> ah, of course. i'm an idiot
[18:16] <dobey> barry: forgot the install files. but just pushed them to the branch
[18:17] <slangasek> tkamppeter: did that override_dh_auto_configure rule help?
[18:22] <tkamppeter> slangasek, yes, that works, thank you very much.
[18:34] <dobey> barry: looks like at least 1 test fails in ubuntu-sso-client as a result of my patch to python-oauth
[18:37] <apw> can someone remind me where an installed package's postrm is on disk on the machine?
[18:38] <dobey> apw: in /var/lib/dpkg somehwere
[18:43] <dobey> barry: hrmm, but this may actually be a bug in ubuntu-sso-client. the test has a unicode char in the url's path
[18:45] <barry> dobey: nice
[18:47] <tkamppeter> slangasek, fixed ptouch-driver uploaded to Q and also uploaded for P-proposed.
[18:51] <slangasek> tkamppeter: excellent :)
[19:00] <dobey> barry: hrmm. though it looks like after fixing that test, it still fails in the oauth signing, even though the URL looks correct outside of oauth.py. so will have to look at that some more
[19:00] <barry> dobey: cool, no worries
[19:41] <mterry> mvo, hello!  What does "update-manager --no-update" do?  I see where it affects the code (calling "self.list.update(self.cache)" or not), but I don't understand what affect that ends up having
[19:57] <vsingh165> anyone here familiar with bug #822993? https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/822993
[19:57] <vsingh165> I'm a new developer and still figuring this out.
[19:58] <vsingh165> basically, there's a button in nautilus file properties that allows you to apply a folder's permissions to its contents.  but the button does absolutely nothing
[19:58] <vsingh165> it was originally found in 11.10, but I've verified that it still happens in 12.04
[20:14] <mterry> mpt, on the software updates spec (https://wiki.ubuntu.com/SoftwareUpdates), most of the mockups have the ubuntu logo.  But the last two mockups use a package icon.  Is that intentional?
[20:14] <mpt> mterry, I'm planning to change the others to match those last two
[20:14] <mterry> mpt, OK, so all should have package icons
[20:14] <mpt> (the application icon, not a package icon per se)
[20:15] <mterry> mpt, sure
[20:15] <mpt> thanks for checking :-)
[21:43] <ahasenack> hi, can someone please review and if all good upload landscape-client to quantal? This is the bug, and I attached a branch to it based on the current quantal branch (ubuntu:landscape-client):
[21:43] <ahasenack> https://bugs.launchpad.net/landscape-client/+bug/1004678
[21:44] <ahasenack> thanks
[21:44]  * ahasenack bbl, walk the dog
[22:17] <andreas__> back
[22:18] <ahasenack> back :)
[23:25] <bkerensa> cyphermox: Any more advice to resolve Bug #972063
[23:52] <infinity> NCommander: Uhm, dude.  debian/rules clean? :P
[23:53] <infinity> NCommander: Your flash-kernel diff includes debian/flash-kernel (and then on the next upload, you patched the contents of said directory!)
[23:54] <cjwatson> Don't you have to work pretty hard to do that?  dpkg-buildpackage -S runs clean.
[23:54] <cjwatson> (Also, *always* read the debdiff before uploading.)