[00:07] <DBO> does anyone know when a good time to catch macslow might be?
[00:07] <directhex> when he's awake & on irc. that's a good start
[00:08] <DBO> thanks
[00:08] <beuno> DBO, he's in germany
[00:08] <DBO> mmmm, probably sleeping...
[00:08] <beuno> so mon-fri 9-17hs UTC aprox
[01:32] <RAOF> asac: I've just run across bug #331849; you were the last commenter on it.  It's the reason people are still hitting bug #331311.  Basically, notify-osd should be installing those icons in the hicolor theme, rather than them being shipped in Human.
[03:00] <abc2xyz> how to join the team?
[03:00] <RAOF> What team?
[03:01] <abc2xyz> i mean the developers
[03:01] <RAOF> By doing packaging work.
[03:01] <RAOF> !motu
[03:01] <RAOF> Is what you want to see.
[03:01] <RAOF> Also...
[03:01] <RAOF> !gettingstarted
[03:02] <abc2xyz> thanks :D
[06:08] <dholbach> good morning
[07:43] <pitti> Good morning
[07:44] <pitti> calc: 332578> good idea, will look at it
[07:44] <directhex> morning pitti
[07:45] <pitti> slangasek: could you please ack/nack bug 326989 ?
[08:19] <pitti> kirkland: oh, I just saw screen-profiles the first time, nice! however, is it really intended to always show that menu when you run "screen"?
[08:19] <pitti> kirkland: I'd expect it to come up only the first time
[08:20] <pitti> kirkland: also, F3/F4 don't work for me, do they for you?
[08:20] <pitti> kirkland: nicely done!
[08:21] <Koon> pitti: last time I checked, the menu came only once and F3/F4 were working properly
[08:22] <pitti> kirkland, Koon: hm, I have
[08:22] <pitti> -rw-r--r-- 1 martin martin 0 2009-02-23 09:18 .screenrc
[08:23] <pitti> maybe it isn't supposed to be empty? I'm fairly sure it only got created this morning
[08:23] <pitti> yes, confirmed, it's not in yesterday evening's backup
[08:28] <Koon> pitti: ah, *that* menu
[08:29] <Koon> pitti: it's a new one, and I agree it's a little painful
[08:29] <Koon> pitti: F3/F4 work here though, once you created a new tab with F2
[08:31] <pitti> Koon: hm, I only tried it under X, and still doesn't work for me
[08:31] <Koon> pitti: the 0-sized .screenrc is apparently normal
[08:37] <ara> pitti, kirkland: I experience the same. https://bugs.launchpad.net/ubuntu/+source/screen-profiles/+bug/333180
[08:56] <slangasek> didrocks: you uploaded a totem that build-depends on a gtk-doc-tools newer than what's in the archive; any plans to upload that too?
[08:57] <didrocks> slangasek: I requested a sync request and FFe
[08:57] <didrocks> let me find it
[08:58] <didrocks> slangasek: bug #331201
[08:59] <slangasek> didrocks: ah didn't notice that you needed sponsorship, ok
[08:59] <slangasek> thanks, I'll have a look at that
[09:01]  * slangasek reads the very bottom of the bug description and coughs, realizing he should have already known about this ;)
[09:02] <didrocks> slangasek: thanks a lot :)
[09:02] <didrocks> slangasek: yeah, I am just a MOTU, not a core-dev :)
[09:08] <ara> kirkland: another one on screen-profiles: https://bugs.launchpad.net/ubuntu/+source/screen-profiles/+bug/333180
[09:08] <ara> kirkland: I meant https://bugs.launchpad.net/ubuntu/+source/screen-profiles/+bug/333189
[09:20] <slangasek> a|wen: why is kile building a -dbg package in Ubuntu?  Is this a change pulled from the Debian svn tree?
[09:21] <a|wen> slangasek: we've upgraded to an svn snapshot of the kde4 version ... so right now we are ahead of debian in that sense
[09:22] <slangasek> a|wen: so why are we building a -dbg package?
[09:23] <a|wen> slangasek: for the same reason we are building kde*-dbg packages... is there any good reason not to build it?
[09:25] <slangasek> a|wen: because it should be redundant relative to our automatically-generated -dbgsym packages
[09:25] <slangasek> a|wen: which are stored in a dedicated archive, where they don't take up space on the mirrors
[09:26] <slangasek> a|wen: -dbg packages are tolerable as a lesser evil when they're synced from Debian; but I don't see any reason we should be creating new ones in Ubuntu
[09:27] <slangasek> so I'm inclined to reject these packages out of binary NEW
[09:27] <a|wen> slangasek: i see; as it is a kde4 app, i was mostly just looking at how the other kde4 applications was made
[09:28] <a|wen> slangasek: i think the package is already in the archive (the 0ubuntu1 version is there)
[09:28] <slangasek> the binaries aren't
[09:28] <slangasek> can you upload a -0ubuntu3 version dropping the -dbg package?
[09:29] <a|wen> slangasek: yeah, no problem
[09:29] <slangasek> ok, thanks :)
[09:30] <a|wen> i can't upload myself, but maybe you'll be keen on the debdiff?
[09:30] <slangasek> a|wen: sure
[09:38] <a|wen> slangasek: http://awen.dk/packages/kile/kile_2.1~svn20090217-0ubuntu3.debdiff
[09:39] <slangasek> a|wen: <yoink> :)
[09:41] <slangasek> a|wen: uploaded, thanks!
[09:42] <a|wen> slangasek: no problem; thx for spotting it and correcting me
[09:47] <geser> Keybuk: I'm here if you need me for some udev testing/debugging
[09:48]  * Ng is curious if there are any arguments against bug #157345 - and more importantly, who would be worth advocating it to
[09:51] <dholbach> Ng: tkamppeter?
[09:52] <Ng> dholbach: yeah I added a comment last night asking if he had any objections. It seems like it probably ought to have some input from team securitah
[09:53] <dholbach> maybe pitti knows about it too?
[09:53] <pitti> Ng: in fact I'd like to do that as well, but IMHO bug 314408 should be solved first
[09:54] <pitti> Ng: this would then comply to https://wiki.ubuntu.com/DefaultNetworkServices
[09:55] <Ng> that is exactly the kind of argument I was looking for :)
[09:55] <pitti> Ng: there's no principal blocker, other than finding the time to do it for GTK and Qt
[09:56] <Ng> pitti: I'll add appropriate commentary, thanks :)
[09:59] <didrocks> slangasek: thanks
[10:00] <pitti> Ng: cool, Qt upstream scheduled fixing for 4.6.0
[10:01] <Ng> pitti: given that we're post-FF, assuming a patch existed, would this be likely to make it for jaunty?
[10:01] <pitti> Ng: the gtk/qt patches fall under UIF
[10:02] <pitti> Ng: but the cups change itself is FF, of course; it'll probably be accepted if it lands by UIF, but not later
[10:02] <Ng> hmm, just over a week
[10:07] <bigon> http://launchpadlibrarian.net/22770218/buildlog_ubuntu-jaunty-i386.openerp-server_5.0.0-3-1_FAILEDTOBUILD.txt.gz << does anybody know where this FTBFS comes from?
[10:07] <Hobbsee> pitti: darn.  why does that immutable page have to have a typo on it?
[10:07] <cjwatson> DefaultNetworkServices? doesn't seem immutable - are you logged in/
[10:07] <cjwatson> ?
[10:07] <Hobbsee> er, apparently not
[10:08] <Hobbsee> hrm.  perhaps it isn't a typo either, but something i've never heard of
[10:08] <slangasek> bigon: appears to be an objection from pkgstriptranslations?
[10:08] <cjwatson> if you mean "DCHP", I've just corrected that
[10:08] <Hobbsee> cjwatson: yeah, that's hte one ;)
[10:09] <slangasek> bigon: which is pkgbinarymangler
[10:09] <cjwatson> pitti: perhaps at some point you could propose a diff to ubuntu-policy encompassing that specification?
[10:10] <pitti> cjwatson: added to my todo list
[10:12] <cjwatson> no rush, thanks
[10:18] <Silicium> hi there
[10:19] <Silicium> i have created a bootsplash with gimp, 16 indexed colors, and compiled into a shared object, but it wouldnt be loaded, the bootscreen is just black with a blinking cursor while booting...
[10:19] <pitti> Keybuk: wrt. https://bugs.edge.launchpad.net/ubuntu/+source/elisa/+bug/315704/comments/23, I tend to agree (both that it's better suited in universe, support-wise, and that the user experience would be better); do you still remember why you wanted it in main in the first place?
[10:19] <seb128> pitti: ask lool I think that was a mobile thing?
[10:20] <seb128> pitti: lool has been working on it previous cycle for sure
[10:20] <pitti> seb128: request came from Keybuk, lool helped a lot to implement it, though
[10:20] <seb128> ok
[10:20] <seb128> ignore me I was just mentionning it in case that was useful ;-)
[10:22] <pitti> seb128: merci
[10:22] <seb128> pitti: de rien ;-)
[10:23] <ogra> cjwatson, partman complains, but you can go on iirc
[10:23] <ogra> which means you die with oom on the slug
[10:24] <cjwatson> ogra: sure, I regard that as the user's fault :)
[10:24] <ogra> ok
[10:24] <cjwatson> it warned you; if you ignore it you get to keep both pieces
[10:24]  * ogra will do so too then, i'll m,ake sure its in the docs
[10:24] <ogra> -,
[10:31] <ogra> Keybuk, any idea about the weird behavior udev shows on my slug install ? http://paste.ubuntu.com/121199/
[10:33] <ogra> Keybuk, the uuid's that end up in /target/etc/fstab dont match anything in the system until i call udevadm trigger which then changes the complete set of uuids for the target partitions
[10:34] <ogra> beyond that the first uuid in the mkinitramfs error doesnt exist at all
[10:44] <Knives> join #ubuntu-offtopic
[11:11] <cjwatson> Keybuk: davmor2 has a problem with a fresh LVM installation that I speculate might be bug 332270. What's the easiest way for him to confirm that it's the same bug?
[11:21] <davmor2> cjwatson, Keybuk: Does this only effect certain disks or does it only effect certain type of partitioning?  Also removing quite and splash from the kernel line might give me more info wouldn't it?
[11:21] <Keybuk> davmor2: absolutely no idea
[11:21] <Keybuk> I still can't replicate it
[11:22] <Keybuk> pitti: -mobile wanted it in main
[11:22] <pitti> Keybuk: ah, thanks
[11:22] <pitti> lool: does that still hold? (elisa in main for mobile)
[11:23] <davmor2> Keybuk: I got it doing a LVM install test that I used the new d-i lvm resize feature on, at 20% of a 250gig hd
[11:24] <Keybuk> davmor2: got what?
[11:24] <davmor2> Keybuk: bug 332270 if it is that bug
[11:25] <Keybuk> davmor2: no, I mean what _happened_ when you got to 20%?
[11:25] <davmor2> Keybuk: no I used the resize feature and set it to use 20% of my 250g hd
[11:25] <Keybuk> and then what happened?
[11:26] <cjwatson> it's not *re*size, BTW, it's setting the initial size
[11:26] <davmor2> cjwatson: sorry :)
[11:26] <davmor2> Keybuk: it wouldn't reboot
[11:26] <Keybuk> davmor2: why not?
[11:27] <Keybuk> did you see an error message?
[11:27] <Keybuk> were there messages on another console?
[11:29] <davmor2> Keybuk: two ticks I'm just removing quite and usplash from kernel line as it doesn't provide me with any other consoles
[11:32] <geser> davmor2: which architecture are you using? i386 or amd64 or something else?
[11:34] <davmor2> Keybuk: Disk activity is constant it seems to of detected most of my hardware and now lists /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda  new line /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda/sda1 and repeats
[11:35] <wgrant> That's the one.
[11:35] <Keybuk> davmor2: great!
[11:35] <davmor2> geser: I386
[11:35] <Keybuk> can you explain the steps you went through to do this?
[11:36] <Keybuk> I'll try and replicate in vmware
[11:38] <davmor2> Keybuk: i386 alternat install.  Select guided - lvm whole drive for partitioning.  hit enter on the next screen and then on the next screen change -12-1 to 20% and hit enter complete the install
[11:38] <Keybuk> err, can you explain the -12-1 to 20% thing?
[11:38] <Keybuk> pretend that I've never seen the alternate installer before
[11:38] <Keybuk> was the disk blank when you did this?
[11:38] <Keybuk> or was there an existing operating system there?
[11:38] <Keybuk> did you remove the existing operating system?
[11:38] <Keybuk> or did you select resize?
[11:40] <cjwatson> Keybuk: I can help here
[11:40] <davmor2> Keybuk: http://testcases.qa.ubuntu.com/Install/AlternateLvm after the guided - use entire disk and set up LVM you now get the option to not use the entire disk for more flexibility (new feature)
[11:41] <cjwatson> Keybuk: the installer recently gained a feature whereby, if you choose guided LVM partitioning (i.e. erase whole disk, stick LVM on it), then rather than just munching the entire volume group for logical volumes, it asks you how much of the volume group you want to use
[11:41] <davmor2> I told it to use 20% of the 250GB drive rather than -12-1 (the whole drive)
[11:41] <cjwatson> Keybuk: the structure of the resulting volume group should be the same
[11:41] <Keybuk> ok, so whole-disk LVM
[11:41] <Keybuk> no MD?
[11:41] <cjwatson> davmor2: "-12-1"? that makes no sense to me
[11:41] <Keybuk> no encryption?
[11:41] <cjwatson> davmor2: is that literally what you saw?
[11:42] <davmor2> cjwatson: I think that is what it said I can re-run it to check for you
[11:42] <davmor2> it was something weird like that
[11:42] <cjwatson> davmor2: if you do see that, it's a bug, and I'd like syslog and partman; it should be more like "250 GB"
[11:42] <davmor2> Keybuk: no not encrypted
[11:42] <cjwatson> it could be some kind of overflow bug
[11:43] <davmor2> I think I got the logs from installer hang on
[11:44] <cjwatson> hmm, the partman test suite probably ought to test some bigger numbers
[11:44] <cjwatson> though it does test 4.3GB
[11:44] <cjwatson> $ longint2human 2500000000000
[11:44] <cjwatson> 2.5 TB
[11:44] <cjwatson> *seems* fine ...
[11:46] <cjwatson> my only guess is that vgs is outputting garbage
[11:47] <cjwatson> davmor2: I'd like the output of 'vgs -o vg_free --units K --noheading --nosuffix'
[11:49]  * Keybuk sees "8.3 GB"
[11:49] <Keybuk> I selected 50%
[11:50] <Keybuk> now it's installing the base system
[11:51] <davmor2> cjwatson: logs for partman and syslog should be http://www.davmor2.co.uk/syslog http://www.davmor2.co.uk/partman
[11:51] <Keybuk> davmor2: are you doing this in vmware or on a real machine?
[11:51] <davmor2> Keybuk: really hw
[11:51] <davmor2> real even
[11:52] <Keybuk> are you able to do it again?
[11:52] <davmor2> Keybuk: Restarting now
[11:52] <Keybuk> davmor2: when partman is up, can you switch to Alt+F2
[11:52] <Keybuk> then run
[11:53] <Keybuk> # killall udevd
[11:53] <Keybuk> # udevd --debug --resolve-names=never > /var/log/udev 2>&1
[11:53] <Keybuk> then continue with your test
[11:53] <Keybuk> if it hangs, let it for 15-30 seconds or so
[11:53] <Keybuk> then ^C udev
[11:53] <Keybuk> and give me that log file ;)
[11:54] <davmor2> cjwatson: from where would you like the vgs -o .... line typing ?
[11:57] <davmor2> Keybuk: problem kicks in upon restart the install works fine
[11:57] <ogra> Keybuk, ny< idea for my uuid prob ?
[11:57] <ogra> *any
[11:57] <Keybuk> davmor2: oh, you're saying that the install worked fine before?
[11:58] <Keybuk> ogra: what uuid problem?
[11:58] <Keybuk> ogra: I can suggest some cream?
[11:58] <ogra> Keybuk, http://paste.ubuntu.com/121199/
[11:58] <ogra> cream is always good
[11:58] <davmor2> Keybuk: yes it's at the end of the install it reboots only then nothing happens
[11:59] <Keybuk> ogra: *shrug* your UUIDs in your fstab are wrong
[11:59] <Keybuk> davmor2: this is what happened last time too?
[11:59] <Keybuk> davmor2: the install absolutely definitely worked, and it was after the reboot you had the problem?
[11:59] <ogra> Keybuk, so you say thats a d-i failure ? even if the uuids change to the proper ones after running udevadm trigger manually ?
[12:00] <Keybuk> ogra: I'm not saying anything
[12:00] <davmor2> Keybuk: yeap the install log is the one I posted for cjwatson
[12:00] <Keybuk> I'm just saying that all your pastebin shows is that your fstab is clearly wrong
[12:00] <ogra> i would expect them to be exactly whats in fstab on forst boot
[12:00] <ogra> *first
[12:00] <Keybuk> davmor2: ok, interesting
[12:00] <Keybuk> davmor2: so you can boot that system now, and it hangs on boot?
[12:01] <ogra> Keybuk, well, the fstab matches what i see after the uuids change when i call udevadm trigger, my question rather would be why are they different at all ?
[12:01] <Keybuk> ogra: no idea, why is the sky blue?
[12:01] <davmor2> Keybuk: grub works then detect hw works then you get the never ending stream of /sys/devices
[12:01] <Keybuk> ogra: please find out :)
[12:01] <IntuitiveNipple> Keybuk: Would it help if you can watch it happening?
[12:01] <Keybuk> davmor2: ok
[12:01] <Keybuk> davmor2: could you boot, get to grub, replace "splash" with "init=/bin/bash"
[12:02] <Keybuk> and then run the following
[12:02] <Keybuk> mount -o rw,remount /
[12:02] <ogra> Keybuk, because the pink paint was out
[12:02] <Keybuk> edit /etc/init.d/udev
[12:02] <Keybuk> actually
[12:02] <Keybuk> rewind that
[12:02] <davmor2> Keybuk: hang on mid install to confirm I can reproduce it
[12:02] <Keybuk> just boot with init=/bin/bash
[12:02] <Keybuk> and see if you get to a root prompt first
[12:03] <Keybuk> IntuitiveNipple: unless you have a serial console, I'm not sure how you could set that up ;)
[12:03] <IntuitiveNipple> Keybuk: I do, and I can give you shared SSH/screen access to view as it happens
[12:03] <Keybuk> IntuitiveNipple: that would be helpful
[12:04] <cjwatson> davmor2: tty2
[12:05] <davmor2> cjwatson: there isn't one on the installed system
[12:05] <cjwatson> davmor2: no, I mean during install, at the point where it gives you the LVM size prompt
[12:05] <davmor2> cjwatson: np's
[12:06] <cjwatson> although there most certainly is a tty2 on the installed system :-0
[12:06] <IntuitiveNipple> Keybuk: OK. I'll set it up. Just so you know what you'll be seeing: It's a lab PC with a clean install on Sunday. I've just downgraded udev/dmsetup to the pre-issue versions so it is possible to get control.
[12:06] <cjwatson> :-)
[12:06] <Keybuk> IntuitiveNipple: I assume it's ok for me to upgrade them again while the system is running?
[12:06]  * cjwatson peers at davmor2's syslog
[12:06] <cjwatson> Feb 23 10:09:31 main-menu[1756]: (process:11141): .
[12:06] <cjwatson> Feb 23 10:09:31 main-menu[1756]: (process:11141): TB
[12:06] <cjwatson> that's ... odd
[12:07] <IntuitiveNipple> Keybuk: Yes, it's a lab PC. I downgraded it specifically so we can see the initial reaction. You can also kick into the initrd by using kernel command-line "break" to stop before premount kicks off
[12:08] <davmor2> cjwatson: by the way I think it is wrong to now call guided - use entire disk and setup lvm if you can set it to not use the entire disk :)
[12:08] <Keybuk> IntuitiveNipple: and how do I install a package? ;o)
[12:09] <IntuitiveNipple> They are in the /root/ directory of the installation, for use with dpkg. I'll show you once you're attached
[12:09] <cjwatson> davmor2: maybe, though I'm reluctant to change the translated string
[12:10] <cjwatson> davmor2: it does use the entire disk in the sense that it erases everything there before and puts an LVM volume group over the entire disk
[12:10] <cjwatson> davmor2: one thing that may address your problem is that I've changed the text in the size question to talk about the amount of the volume group you want to allocate, rather than the amount of disk
[12:11] <davmor2> cjwatson: Right still listed as -12-1 and vgs line reads 159782010.88
[12:11] <IntuitiveNipple> Keybuk: OK... this will get you onto my laptop, from where you can attach to the screen multiuser session where the serial console is running: ssh -p 2222 remoteop@alexandros.tjworld.net
[12:11] <IntuitiveNipple> Keybuk: The remoteop password is: letmein
[12:12] <IntuitiveNipple> Keybuk: Once logged in, attach to my screen session using: screen -x tj/Multiuser
[12:12]  * davmor2 right Keybuk s line next
[12:12] <cjwatson> (you realise this is a publicly logged channel?)
[12:12] <IntuitiveNipple> cjwatson: I should hope so :)
[12:13] <Keybuk> weird, X-Chat just decided to crash there
[12:13] <IntuitiveNipple> Keybuk: Did you miss my connection instructions?
[12:13] <Keybuk> I've connected, and I can see the root@jaunty:~# prompt
[12:13] <Keybuk> this is the lab machine?
[12:14] <geser> Keybuk: I can confirm the last comment on that udev bug: when I disable one core, restart udev then the udevadm trigger doesn't cause any loop
[12:14] <IntuitiveNipple> Keybuk: That is the console to the lab machine... I'll send some commands
[12:14] <davmor2> cjwatson: was that directed at me?
[12:14] <cjwatson> davmor2: no, IntuitiveNipple (which I can only assume is intended to mean "completely unintuitive" ...)
[12:15] <IntuitiveNipple> Keybuk: You have control... snoop around... do you want to see it reboot with 137-1 so when we install 138-1 you can see the difference?
[12:15] <Keybuk> no, I know what a booting Ubuntu machine looks like ;)P
[12:16] <IntuitiveNipple>  :)
[12:16] <IntuitiveNipple> Do you want to update dmsetup?
[12:16] <cjwatson> davmor2: hmm, when you have a chance, it would be good if you could run through the installer, stop at the hostname prompt, 'nano /bin/perform_recipe_by_lvm' and stick 'set -x' at the top - then I need the resulting syslog after the rest of the installation
[12:16] <cjwatson> davmor2: sorry, I know each iteration takes a while
[12:16] <Keybuk> IntuitiveNipple: no, just going to take this one step at a time
[12:16] <davmor2> cjwatson: np's it's better to get it fixed now :)
[12:16] <IntuitiveNipple> Keybuk: ok... just there was a package dependency issue
[12:17] <cjwatson> davmor2: there's clearly an arithmetic bug somewhere but I can't reproduce it at an ordinary shell
[12:19]  * Keybuk hates screen
[12:19] <Keybuk> it's like it *tries* to get being a terminal completely wrong
[12:19] <Keybuk> on purpose
[12:19] <Keybuk> IntuitiveNipple: no swap? on purpose?
[12:20] <IntuitiveNipple> Keybuk: correct
[12:20] <Keybuk> what's /dev/sda2 and /dev/sda4 ?
[12:20] <IntuitiveNipple> Keybuk: sda2 is formatted for swap but not in fstab
[12:20] <Keybuk> sda2 is not properly formatted for swap ;)
[12:20] <Keybuk> someone didn't use parted for it
[12:20] <IntuitiveNipple> sda3 is /   sda4 is the demo LVM area, but nothing in it gets mounted.
[12:20] <highvoltage> ogra: I'm surprised that not more people agree with you on the long-term-reminder thing
[12:20] <Keybuk> "demo LVM area" ?
[12:21] <IntuitiveNipple> Keybuk: I had to build it using deboostrap - Sunday's live-CD ubiquity failed on starting
[12:21] <ogra> highvoltage, well, cjwatson's mail showed me that i probably didnt formulate it right
[12:21] <IntuitiveNipple> Keybuk: demo as in, it's not used but is 'there' to demo the bug.
[12:21] <ogra> so people might not have understodd what i meant
[12:21] <Keybuk> IntuitiveNipple: if you don't have that, do you not see the bug?
[12:22] <cjwatson> yes, ubiquity has a missing dependency at the moment (which probably needs to be fixed by removing the dependency, otherwise I'd have fixed it already)
[12:22] <cjwatson> Keybuk: how does sda2 manage to be improperly formatted for swap?
[12:22] <IntuitiveNipple> Keybuk: I'm not sure tbh... don't think I did that test. I know without the lvm2 package installed the bug doesn't show, but thats different. Do you want to delete sda4 ?
[12:22] <Keybuk> cjwatson: not wiped first, so looks like it has swap and ext3 metadata
[12:22] <Keybuk> IntuitiveNipple: can we rewind this conversation please
[12:22] <IntuitiveNipple> Keybuk: sure
[12:22] <Keybuk> IntuitiveNipple: your system is not set up "normally"
[12:22] <Keybuk> how you've set this up could be VERY important
[12:23] <cjwatson> does parted actually get that right, I wonder?
[12:23] <Keybuk> so, please explain your system's setup - and why it is the way it is
[12:23] <Keybuk> cjwatson: yes
[12:23] <cjwatson> note also that d-i sometimes falls back from libparted to mkswap when formatting swap partitions
[12:24] <cjwatson> ah yes, libparted memsets the header
[12:24] <IntuitiveNipple> Keybuk: It had to created using deboostrap, since Ubiquity failed. So, from the live-CD I fdisk-ed the 4 primary partitions and set their types, then used mkfs.ext3 /dev/sda1 and /dev/sda3, mkswap /dev/sda2, and pvcreate/lvcreate for sda4
[12:24] <Keybuk> so what is sda4 for?
[12:24] <Keybuk> why did you do that?
[12:24] <IntuitiveNipple> Keybuk: Then used debootstrap to install Ubuntu into it
[12:25] <IntuitiveNipple> Keybuk: sda4 was there to test that LVM would trigger the bug
[12:25] <Keybuk> ok
[12:25] <cjwatson> as, I think, does busybox mkswap (not explicitly but effectively)
[12:25] <Keybuk> so sda4 is an LVM with a bunch of logical volumes in it
[12:25] <Keybuk> do you mount those volumes?
[12:26] <cjwatson> util-linux mkswap also does a memset, so if ext3 metadata is left around, it must be outside the swap header region?
[12:26] <IntuitiveNipple> Keybuk: No. I was about to create an alternative boot option using them a few minutes ago (which is why it is mounted on /target/) but its totally unused
[12:26] <Keybuk> no you don't mount those volumes?
[12:26] <Keybuk> or no I'm wrong?
[12:26] <IntuitiveNipple> Keybuk: It's a sacrificial system set up just for testing this bug scenario
[12:26] <IntuitiveNipple> Keybuk: nothing in LVM is mounted
[12:26] <IntuitiveNipple> (unless I am playing about)
[12:27] <Keybuk> cjwatson: we should start a campaign to import "doch" into the English language
[12:28] <cjwatson> absolutely
[12:28] <cjwatson> very annoying omission from English
[12:29] <Keybuk> lrwxrwxrwx 1 root root 10 Feb 23 11:54 0c3390a5-9d90-460d-bc8d-10ff5d02a6f4 -> ../../dm-0
[12:29] <Keybuk> that's odd
[12:30] <IntuitiveNipple> Keybuk: The disk is 'thrashing' at this point
[12:30] <Keybuk> well, that definitely loops ;)
[12:30] <IntuitiveNipple> That's the same as happens at boot-time in initrd as soon as udev starts
[12:31] <IntuitiveNipple> and it never seems to stop... at least after leaving it 15 minutes it hasn't
[12:32]  * Keybuk hates screen
[12:33] <IntuitiveNipple> Well, while you hate it, I'll go grab a cuppa
[12:33] <geser> IntuitiveNipple: how many cpus/cores does this lab PC has?
[12:33] <Keybuk> single
[12:35] <Keybuk> IntuitiveNipple: this computer has no internet access?
[12:35]  * Keybuk needs to get that log file off
[12:38] <IntuitiveNipple> There you go
[12:38] <IntuitiveNipple> Remember I've also attached some full debug LOG_DEBUG logs to the bug report
[12:39] <Keybuk> yeah, but you cut the important bit off ;)
[12:39] <IntuitiveNipple> The gzip logs are the full capture from start... nothing was edited
[12:41] <davmor2> Keybuk: init=/bin/bash doesn't work :(
[12:41] <davmor2> cjwatson, Keybuk: I can confirm though that it is reproducible
[12:41] <Keybuk> davmor2: good to know, thanks
[12:42] <IntuitiveNipple> davmor2: No, it won't, since the issue starts in initrd... you need to do "rdinit=/bin/busybox" or just add "break" to stop initrd at the premount point
[12:42] <cjwatson> rdinit?
[12:42] <cjwatson> <cjwatson@sarantium ~>$ wcgrep rdinit /usr/share/initramfs-tools/
[12:42] <cjwatson> <cjwatson@sarantium ~>$
[12:43] <Keybuk> cjwatson: which init inside the initramfs to run
[12:43] <cjwatson> besides surely /bin/busybox will just print a message about how you should have nominated an applet to run
[12:43] <Keybuk> break=top would have been just as good
[12:43] <cjwatson> invoking /bin/sh would be more normal
[12:45] <IntuitiveNipple> cjwatson: sorry, yes, I was thinking and typing at the same time... always a dangerous thing to do (sh is provided by busybox was in my mind)
[12:47] <davmor2> cjwatson, Keybuk: I'm off for lunch in a second so cjwatson I'll try your other request when I get back.  Keybuk is there anything else you'd like me to try?
[12:47] <Keybuk> not at this time
[12:48] <Keybuk> IntuitiveNipple's machine is proving a useful study so far
[12:48] <davmor2> Cool :)
[12:48] <IntuitiveNipple> First time it's been useful in 5 years :)
[12:48] <IntuitiveNipple> It's damned noisy! How do fans get noisy when they're never used!?
[12:50] <Keybuk> ok
[12:51] <Keybuk> so in your case, it's lvm
[12:51] <Keybuk> lvm scans all the drives
[12:51] <Keybuk> and that is causing inotify events on them
[12:51] <Keybuk> quite why lvm is opening them writable is anyone's guess ;)
[12:58] <IntuitiveNipple> Keybuk: I did wonder, with the vscan && vgchange
[12:58] <IntuitiveNipple> s/vscan/vgscan/
[12:59] <IntuitiveNipple> The timing issue is interesting too... as I said before. With debug logging there seems to be sufficient delay between actions to avoid the inotify trigger
[12:59] <Keybuk> sure
[13:00] <Keybuk> lvm vgscan beats inotify watch
[13:00] <Keybuk> it's only the inotify watch on the block device that has the LVM PV that really matters
[13:01] <Keybuk> see
[13:02] <Keybuk> making it not watch the LVM PV fixes the problem ;)
[13:05] <Keybuk> IntuitiveNipple: I think I broke it - it's not responding?
[13:05] <IntuitiveNipple> let me check
[13:05] <IntuitiveNipple> I think you did :)
[13:06] <IntuitiveNipple> No response on the physical console
[13:06] <IntuitiveNipple> I'll try to force a restart
[13:07] <IntuitiveNipple> Booting with "break" to stop at pre-mount else we'll be stuffed
[13:07] <Keybuk> no we won't
[13:07] <IntuitiveNipple> Yes were are... disk is thrashing madly
[13:07] <IntuitiveNipple> s/were/we/
[13:07] <Keybuk> ah, it's thrashing inside the initramfs
[13:07] <IntuitiveNipple> I must hav mistyped the kernel command line
[13:07] <Keybuk> ok, can you reboot it again ;)
[13:07] <IntuitiveNipple> Yes, as always
[13:09] <IntuitiveNipple> This break-top
[13:09]  * IntuitiveNipple bites fingers
[13:09] <IntuitiveNipple> This *is* break=top
[13:11] <Keybuk> thrashing again or not?
[13:11] <IntuitiveNipple> OK you broke it again :)...I have noticed that when the udev issue occurs, the next warm-boot locks the PC at this point. I'll have to do a cold restart
[13:11] <IntuitiveNipple> No, it's froze up... give me amo
[13:11] <lool> pitti: No, we didn't really use elisa in main after all; I was interested in doing the work back then because there was a chance of including it in the seeds and it was used by OEM
[13:11] <lool> pitti: Nowadays, I think it's a blocker to have elisa* in main; so please demote if you feel like it
[13:11] <Keybuk> weird
[13:14] <Keybuk> grr, busybox sed is weird
[13:17] <Keybuk> IntuitiveNipple: what have you set the usual ^A to on this?
[13:18] <IntuitiveNipple> I've not changed anything; it's the default settings.
[13:18] <IntuitiveNipple> I think you want Ctrl+]
[13:20] <pitti> lool: ok, thanks
[13:28] <slangasek> pitti: libsmbios-bin is NBS in favor of smbios-utils; and it looks like some of the command names have also moved around - do you know which commands hal wants from this package?
[13:29] <pitti> slangasek: I know at least dellWirelessCtl, let me check for the others
[13:30] <slangasek> ok; dellWirelessCtl is still present
[13:30] <IntuitiveNipple> Keybuk: I have to shut everything down. Got an appointment with the electric company - they are here to replace the meter so everything has to go off for about 20 minutes.
[13:30] <Keybuk> ok, np
[13:31] <slangasek> pitti: oh hmm, superm1 has already committed the change to bzr, just not uploaded yet :)
[13:31] <pitti> slangasek: can do
[13:31] <pitti> slangasek: confirmed that it's just dellWirelessCtl
[13:32] <Keybuk> isn't smbios-utils all written in Python?
[13:32] <pitti> yes, that sucks, performance-wise
[13:32] <Keybuk> indeed
[13:32] <Keybuk> I'd like to object on boot performance grounds
[13:32] <Keybuk> this change shouldn't go ahead
[13:33] <slangasek> oh, there's a change of implementation language here?
[13:33] <pitti> C++ -> Python
[13:33] <slangasek> meh
[13:34] <kirkland> mvo: hi, i see that bug 319438 has a fix committed, any idea when it'll release?
[13:35] <slangasek> Keybuk: the libsmbios-bin binary has already been dropped from the package; if we're trying to avoid the change in implementation language, it needs to be resuscitated since it's in NBS right now
[13:35] <Keybuk> slangasek: indeed, I would recommend reverting to the previous version of the package
[13:35] <Keybuk> changing things run on boot to be written in a large, expensive language like Python just is *not* on my list of things I like to see
[13:36] <Keybuk> now, I realise I can't actually enforce that
[13:36] <Keybuk> but I can make nice puppy eyes ;)
[13:36]  * pitti melts
[13:36] <slangasek> heh
[13:38] <slangasek> Keybuk: well, I have no objections to a revert; perhaps you want to discuss it with superm1 and come to a consensus?
[13:38] <Keybuk> indeed
[13:38] <pitti> great
[13:39]  * pitti has no objection to a 2.2.13+really2.0.3.dfsg-0ubuntu1
[13:39] <pitti> we can probably get away with that for jaunty, but long-term upstream should do that as well
[13:40] <Keybuk> "do that" ?
[13:40] <pitti> Keybuk: I doubt it's actually that difficult; old libsmbios was C++ lib/binaries; new libsmbios is C library, python bindings, and python scripts
[13:41] <pitti> Keybuk: do that> provide compiled binaries
[13:41] <Keybuk> it's only the bits run on boot I care about
[13:41] <pitti> we only care about dellWirelessCtl
[13:42] <Keybuk> right
[13:44] <pitti> and in fact, hal-system-killswitch-set-power-linux only calls it in three different methods
[13:44] <slangasek> methods that are called at boot time?
[13:44] <superm1> Keybuk, pitti: I can speak with mebrown about writing a C binary to be used in place of the python smbios-wireless-ctl soon
[13:45] <superm1> it shouldn't actually be too difficult
[13:45] <pitti> my preferred option would be to just rewrite that hal addon in C and use libsmbios directly
[13:45] <pitti> it's some work, though
[13:45] <pitti> slangasek: yes, they are
[13:45] <superm1> yeah I would agree that's the right long term strategy at least
[13:45] <pitti> superm1: directly using libsmbios2 from hal, you mean?
[13:46] <superm1> pitti, yeah that's what I think should be done
[13:46] <superm1> that's one of the reasons it was rewritten in C, so it could be lightweight for other apps to use
[13:51] <asac> what do i need to run in postinst if i install a udev rule?
[13:51] <Keybuk> nothing
[13:51] <asac> cool ;)
[13:52] <Keybuk> your udev rule will be used next time the device is plugged in
[13:52] <asac> thats perfect
[13:52] <Keybuk> what's the rule?
[13:54] <asac> Keybuk: the udev-extras modem prober was internalized by NM
[13:54] <asac> so we dont need the rest of experimental stuff
[13:54] <Keybuk> ah, interesting
[13:54] <asac> debian/tmp/lib/udev/rules.d/77-nm-probe-modem-capabilities.rules
[13:54] <asac> debian/tmp/lib/udev/nm-modem-probe
[13:54] <asac> Keybuk: ^^
[13:57] <slangasek> doko: heh, seen bug #332978?
[13:58] <pitti> asac: modem-prober> rock!
[14:01] <doko> slangasek: ugh ... does ubiquity really need to use numpy? ok, no wonder that I didn't find that, not having ubiquity installed by default
[14:01] <slangasek> doko: no idea if it does or doesn't - just saw the bug pop up on the blocker list for alpha-5 and thought you might want to have a look
[14:01] <doko> looking
[14:01] <cjwatson> doko: it shouldn't, I mentioned the same to evand earlier today
[14:02] <cjwatson> numpy seems like total overkill there
[14:02] <cjwatson> i.e. I didn't just commit a change to add the dependency because I reckoned the code ought to be changed
[14:02] <evand> indeed, working on it
[14:02] <doko> yep, 20 elements arry
[14:06] <directhex> are we headed towards another alpha?
[14:08] <james_w> directhex: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-February/000534.html
[14:09] <james_w> "Our next testing milestone, Jaunty Alpha 5, is scheduled for next
[14:09] <james_w> Thursday, February 26.  Jaunty Alpha 5 will again use a "soft freeze" for
[14:09] <james_w> main[2].  This means that developers are asked to refrain from uploading
[14:09] <james_w> packages between Tuesday and Thursday which don't bring us closer to
[14:09] <james_w> releasing the alpha"
[14:09] <directhex> right. slangasek how do you feel about a bodge job on gmime, to eliminate all the mono 1.0 stuff from the cd (pending the gmime 2.4 stuff meebey spoke with you about)?
[14:10] <slangasek> directhex: uh... I already did that? :)
[14:10] <directhex> did you? oops ^_^
[14:10] <meebey> slangasek: apropros, gmime2.2 is now in pkg-gnome
[14:11] <slangasek> meebey: alrighty
[14:11] <directhex> slangasek, neat! so mono 1.0 classlib stuff is now gone from the cd?
[14:12] <slangasek> directhex: yep
[14:12] <seb128> slangasek: btw how many language packs did you manage to add with the recent changes?
[14:12] <directhex> slangasek, excellent! any early indications on space savings?
[14:12] <meebey> slangasek: when I got some spare time I will migrate gmime2.2 to mono 2.0 and start packaging gmime2.4 as extra source package
[14:12] <directhex> meebey, grab slangasek's 2.0'd 2.2 from patches.ubuntu.com?
[14:13] <slangasek> seb128: 10 on i386 alternate, 6 on amd64 alternate, 7 on i386 desktop, 5 on amd64 desktop
[14:13] <slangasek> (incl. en)
[14:13] <seb128> slangasek: excellent ;-)
[14:13] <meebey> directhex: if merging would be simple with sucky svn ;)
[14:13] <slangasek> directhex: well, we were at the point where corlib and i18n were the only bits left, so... that's how much we saved. :)
[14:13] <meebey> directhex: I will take a look though, but its will be probably just build-deps + configure params
[14:14] <meebey> slangasek: btw tomboy includes tons of translated images (pretty stupid)
[14:14] <meebey> slangasek: wondering what the ubuntu policy is on translations
[14:14] <meebey> if they should be split etc
[14:15] <slangasek> seb128: I guess we can squeeze one more on alternate i386, too; I'm confused by what I've been seeing in terms of alternate CD sizes, the CD size fluctuations as I add/remove don't seem to match the output of the langpacksize script for some reason
[14:15] <meebey> slangasek: 5.7M    /usr/share/gnome/help/tomboy
[14:15] <slangasek> meebey: ideally they would be split, but AFAIK we don't have good general infrastructure for splitting documentation currently
[14:16] <meebey> slangasek: you can make libmono0 optionally, I found out why its pulled in
[14:16] <directhex> meebey, yeah, was about to talk about monoposixhelper
[14:16] <meebey> slangasek: the compression streaming api uses it
[14:16] <slangasek> evolution just had its docs split which was a big savings, but I think that required a bit of manual effort
[14:16] <meebey> oh true, there are 2 libs in it
[14:16] <meebey> and the other one is really needed IIRC
[14:20] <IntuitiveNipple> Keybuk: How are you getting on?
[14:20] <Keybuk> IntuitiveNipple: about 2/3rds the way through my sandwich
[14:21] <IntuitiveNipple> I'm trying to make the new meter go backwards
[14:21] <IntuitiveNipple> System's back online if you need it
[14:33] <davmor2> cjwatson: back do you still need this doing ?  'nano /bin/perform_recipe_by_lvm' and stick 'set -x'  and does go below the #!/bin/bash line doesn't it?
[14:33] <cjwatson> what #!/bin/bash line? :-)
[14:33] <cjwatson> it's /bin/sh - but yes
[14:33] <cjwatson> put it on the second line of the script
[14:34] <davmor2> cjwatson: yes sorry :)
[14:37] <ara> kirkland: ping
[15:01] <Keybuk> hah
[15:01] <seb128> slangasek: are you doing source new today? I've been pinged about reviewing gwibber but I don't want to work conflict with you
[15:01] <Keybuk> so the reason I couldn't replicate the bug in VMware is annoyingly simple
[15:02] <slangasek> seb128: I'm unlikely to get all the way through the NEW queue, feel free to take it
[15:02] <seb128> slangasek: ok
[15:02] <directhex> Keybuk, how's your DH7 wrangling? trying to get the gdb addin for monodevelop ship-shape, but hitting a wall
[15:02] <Keybuk> DH7?
[15:03] <directhex> debhelper 7, minimal rules format specifically
[15:03] <Keybuk> never used it
[15:03] <directhex> hm. the quest goes on, then
[15:04] <geser> Keybuk: so you finally managed to reproduce that udev problem?
[15:05] <Keybuk> geser: not completely
[15:05] <Keybuk> I know _what's_ causing it
[15:05] <Keybuk> what I can't work out is why it only happens for certain people
[15:05] <maco> the lvm one?
[15:09] <Keybuk> right
[15:10] <maco> its not hitting all lvm users?
[15:10] <Keybuk> no
[15:11] <davmor2> cjwatson: logs http://www.davmor2.co.uk/partman1 http://www.davmor2.co.uk/syslog1
[15:12] <Keybuk> and I _think_ it's just limited to lvm too
[15:12] <Keybuk> mdadm looks sane
[15:13] <munckfish> asac: if you've got a sec I'd like to quickly discuss LP #289982, I've had a breakthrough with it, but discovered another issue - wireless only works when the ethernet cable is unplugged :)
[15:13] <geser> Keybuk: is it a bug in udev or lvm and udev simply triggered it?
[15:14] <Keybuk> geser: arguably a bug inside lvm
[15:14] <ccm> hey, is there a known bug in qt for Jaunty that prevents all qt applications to display correctly?
[15:14] <Keybuk> made worse by lvm not being designed to work with udev
[15:14] <ccm> i checked launchpad but don't know where exactly to look
[15:15] <Keybuk> basically each time we find an lvm device, we have to tell lvm to scan for new physical volumes and activate any volume groups found there
[15:15] <Keybuk> to scan for physical volumes, lvm opens every single block device to take a peek
[15:15] <Keybuk> the bug is that it opens them O_RDWR instead of O_RDONLY
[15:15] <Keybuk> meaning that when it closes them, you get an IN_CLOSE_WRITE event
[15:15] <Keybuk> which is what udev reacts to
[15:15] <Keybuk> as a change to the underlying block device
[15:15] <Keybuk> so it rechecks the block device
[15:16] <Keybuk> and because lvm doesn't quite support udev
[15:16] <Keybuk> it has to run lvm scan again
[15:16] <Keybuk> which reopens the block device O_RDWR, ...
[15:18] <cjwatson> davmor2: thanks, reproduced - could you file a bug on partman-auto-lvm with a skeleton description of what happened and I'll get it fixed? I don't need the logs any more
[15:18] <davmor2> Keybuk, cjwatson: out of interest would it be worth me run a standard lvm using the whole disk rather than part and see if it is still an issue?
[15:19] <Keybuk> davmor2: it will be an issue if you have any LVM anywhere
[15:19] <Keybuk> even if you're not mounting it
[15:19] <cjwatson> busybox printf is interestingly broken
[15:19] <cjwatson> $ busybox printf "%i%s%i %s\n" . 2 TB >/dev/null
[15:19] <cjwatson> .TB
[15:19] <cjwatson> (yes, it has the wrong number of arguments, which is the real bug here
[15:19] <cjwatson> )
[15:19] <davmor2> ah okay
[15:20] <Keybuk> cjwatson: err, how is that broken?
[15:20] <Keybuk> . isn't an integer
[15:20] <cjwatson> $ printf "%i%s%i %s\n" . 2 TB
[15:20] <cjwatson> -bash: printf: .: invalid number
[15:20] <cjwatson> -bash: printf: TB: invalid number
[15:20] <cjwatson> 020
[15:20] <cjwatson> is slightly more reasonable behaviour than outputting random inscrutable junk to stderr
[15:20] <Keybuk> cjwatson: telling me what bash does doesn't mean busybox sh is broken :)
[15:21] <asac> munckfish: which NM version?
[15:21] <Keybuk> and busybox sh is sufficiently minimal that reasonable behaviour isn't necessarily expected
[15:21] <cjwatson> Keybuk: I wasn't arguing that the arguments being passed to printf here were correct - they're clearly wrong
[15:21] <Keybuk> cjwatson: does busybox set the exit code
[15:21] <cjwatson> to 0
[15:21] <munckfish> asac: 0.7.1~rc1-0ubuntu2
[15:21] <munckfish> asac: Jaunty
[15:21] <pitti> tjaalton: out of interest, what does 102_dont_vblank.patch in mesa do?
[15:22] <munckfish> asac: Thing is wlan0 and eth0 both have the same MAC address on PS3, I wonder if that's causing the problem
[15:22] <cjwatson> Keybuk: maybe "broken" was a bit strong, but it certainly failed to provide any assistance in debugging until I saw the set -x trace :-)
[15:22] <maco> ccm: might be better in #kubuntu-devel
[15:22] <munckfish> asac: does NM try to bring up both when a user logs in?
[15:22] <cjwatson> although the exit code is clearly wrong
[15:23] <ccm> maco: okay. actually i am using ubuntu, but i will investigate further, thank you
[15:23] <Keybuk>     *
[15:23] <Keybuk> If an argument operand cannot be completely converted into an internal value appropriate to the corresponding conversion specification, a diagnostic message shall be written to standard error and the utility shall not exit with a zero exit status, but shall continue processing any remaining operands and shall write the value accumulated at the time the error was detected to standard output.
[15:23] <Keybuk> sounds "broken" to me
[15:23] <tjaalton> pitti: disables vblank again, to work around bug 320813
[15:23] <Keybuk> POSIX says it must output diagnostics and exit non-zero
[15:23] <cjwatson> I would argue that simply printing the argument does not really qualify as a diagnostic message, too :-)
[15:24] <maco> ccm: the kubuntu folks will know qt though
[15:25] <pitti> tjaalton: ah, thanks
[15:25] <Keybuk> interestingly
[15:25] <Keybuk> $ printf "%i%s%i\n" . 2 TB
[15:25] <Keybuk> printf: 1: .: expected numeric value
[15:25] <Keybuk> printf: 1: TB: expected numeric value
[15:25] <Keybuk> 020
[15:25] <Keybuk> (dash)
[15:25] <asac> munckfish: trying WPA enterprise?
[15:25] <pitti> Keybuk: how is '.' a number?
[15:25] <Keybuk> pitti: that's the point
[15:25] <davmor2> cjwatson: bug 333349
[15:25] <ion_> zsh: bad floating point constant
[15:25] <ion_> 020
[15:26] <pitti> Keybuk: ah, nevermind, just saw scrollback
[15:26] <Keybuk> we don't need a comparison of how shells handle this ;)
[15:26] <Keybuk> the only reason dash was relevant is that busybox's sh is theoretically dash
[15:26] <cjwatson> ish
[15:27] <cjwatson> I would not generally make that comparison because it's too confusing
[15:27] <cjwatson> davmor2: thanks
[15:27] <ion_> dashish sounds like something you’d smoke.
[15:27] <asac> munckfish: i mean the issue is that pkcs11 doesnt work. thought that is only used for enterprise. maybe consider to start with a new connection?
[15:27] <cjwatson> the real cause of the bug was that I'd misremembered how shell variable assignment deals with leading whitespace
[15:28] <cjwatson> I thought it was stripped when you did foo=$(bar), but it isn't
[15:28] <davmor2> Keybuk, cjwatson: Is there anything else you need before I move onto testing something else
[15:28] <Keybuk> no
[15:28] <cjwatson> davmor2: not from me, thanks
[15:29] <davmor2> np's
[15:29] <munckfish> asac: well the original issue was it couldn't connect to any type of WPA network. I've now proved it will connect to my WPA Personal network here at home, but like I said, only when the ethernet cable is unplugged and eth0 cannot be brought up.
[15:30] <munckfish> asac: Now I know that the eth and wlan interfaces use the same MAC address on PS3, now if they are meant to be brought up exclusively then that could be why this is happening
[15:31] <asac> munckfish: definitly. can you please paste the output of lshal ?
[15:31] <munckfish> asac: when it fails the wireless driver in the kernel fails to associate and just times out.
[15:31] <munckfish> asac: ok 1 sec
[15:33] <asac> munckfish: http://paste.ubuntu.com/121904/
[15:33] <asac> thats really looks like both devices are treated as the same on your system
[15:33] <asac> most likely driver issue
[15:34] <asac> (copy paste?)
[15:34] <munckfish> asac: exactly. lshal output http://paste.ubuntu.com/121905/
[15:35] <munckfish> asac: also relevant is the "Wireless" section of this description of the Linux kernel on PS3:
[15:35] <munckfish> asac: http://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-docs/ps3-linux-docs-08.06.09/LinuxKernelOverview.html
[15:35] <davmor2> Keybuk: Out of curiosity is the issue link to bug 332270 or is it something different?  Need to log it
[15:35] <Keybuk> "the issue" ?
[15:35] <davmor2> lvm issue
[15:35] <Keybuk> that is the lvm issue bug, yes
[15:36] <asac> munckfish: are both both drivers in mainline kernel tree?
[15:36] <davmor2> Keybuk: Thanks
[15:36] <asac> munckfish: seems its the same driver actually ;)
[15:36] <munckfish> asac: yes, drivers/net/ps3_gelic_*
[15:36] <asac> munckfish: what time in the daemon.log do you plug in the wired?
[15:37] <munckfish> asac: my understanding/knowledge is very sketchy here, but looking at that article I linked to above
[15:37] <munckfish> asac: it sort of implies that both should be able to run concurrently but using some sort of vlan control to direct packets ??? not sure how that affects things
[15:38] <munckfish> asac: I'm afraid that log is out of date, and only documents the issue when the cable is connected and NM is trying to connect to my wifi network
[15:38] <cjwatson> Keybuk: I think POSIX's text could be read either way regarding the intended exit code, actually
[15:38] <asac> munckfish: can you caputure a fresh log just with the "connect wired" ?
[15:39] <cjwatson> Keybuk: you could read it as meaning that it shouldn't exit immediately, but should continue with the rest of the arguments
[15:39] <Keybuk> cjwatson: but it still shall not exit with a zero status
[15:40] <Keybuk> oh, I see what you mean
[15:40] <munckfish> asac: I've recompiled the kernel this morning with all the debug prints enabled in the gelic driver. I can get a copy of that log for you.
[15:40] <Keybuk> you can read "shall not exit (with a zero status) and may instead continue with arguments (and then exit however it wants)"
[15:40] <IntuitiveNipple> Keybuk: We're got someone who has no LVM or RAID on the PC, but is using LUKS encryption on multiple file-systems.
[15:40] <cjwatson> yeah. I don't *think* this is the intended reading, but it's not entirely unambiguous
[15:40] <Keybuk> I think that reading it that way would be simply attempting to justify a stupid behaviour
[15:40] <cjwatson> you're probably right
[15:41] <cjwatson> it's certainly less helpful to exit zero
[15:41] <Keybuk> IntuitiveNipple: then at this point I assume they have a different bug
[15:41] <IntuitiveNipple> Keybuk: They have the 65-dmsetup.rule - taking the "watch" out of that and 60-persistent-storage fixes it
[15:42] <Adri2000> Keybuk: hi. did you file a rt ticket for mod_python support on casey?
[15:42] <Keybuk> IntuitiveNipple: the bug you have is very specific to LVM
[15:42] <Keybuk> Adri2000: weeks ago
[15:42] <Adri2000> ok
[15:43] <zul> slangasek: ping can you have a look at 330626 when you get a chance?
[15:44] <IntuitiveNipple> Keybuk: 65-dmsetup.rule runs "/sbin/dmsetup export"
[15:44] <Keybuk> IntuitiveNipple: so?
[15:45] <IntuitiveNipple> Keybuk: So, it looks like that triggers the issue the same way lvm vgscan does
[15:45] <Keybuk> dmsetup only looks at /dev/mapper/control
[15:45] <Keybuk> strace it if you don't believe me ;)
[15:46] <IntuitiveNipple> Keybuk: The reporter is MichaelEvans, comment #9 and many others in the bug report.
[15:46] <slangasek> zul: looks to me like that should be referred upstream
[15:46] <Keybuk> https://bugs.edge.launchpad.net/ubuntu/+source/udev/+bug/332270/comments/29
[15:47] <Keybuk> My setup:
[15:47] <zul> slangasek: yeah I have done that im just trying to get more debugging information and kind of busy with other things
[15:47] <Keybuk>  ...
[15:47] <Keybuk> An LVM partition
[15:47] <Keybuk> --
[15:47] <Keybuk> Michael Evans has LVM
[15:51] <maco> are "Unknown media type in type 'all/all'" (various other mimes as well) messages when dpkg installs various packages something to ignore or something about which to file bugs?
[15:51] <rgreening> ArneGoetje: ping
[15:52] <IntuitiveNipple> Keybuk: Yes, thanks for that. I'm querying that with him now since he had just said there's no LVM on the PC he's testing now
[15:53] <IntuitiveNipple> Keybuk: OK, he's trying to confuse me... he *does* use LVM :)
[15:53] <maco> haha
[15:53] <Keybuk> it won't matter whether or not it's mounted or used
[15:53] <rgreening> ArneGoetje: I have a question about the language-support-translations-en package and a hard dep for evolution-documentation-en. COuld this be changed/updated to be a suggests or can we make it nicer for Kubuntu by making it an '|' with an equivalent Kde package.
[15:53] <Keybuk> just as long as the PV is there
[15:56] <ArneGoetje> rgreening: does it hurt on Kubuntu?
[15:59] <rgreening> space on the disk for one is very limited ArneGoetje
[16:00] <IntuitiveNipple> Keybuk: question: when the 60- rule activates does it setup the watch before the 85-lvm2 rule is processed?
[16:00] <rgreening> and I dont think it will fit. plus we use Kontack and not thinderbird ArneGoetje
[16:00] <rgreening> Kontact I mean.
[16:00] <alex-weej> xev doesn't list any key event when using the eject key on computer_model could anybody help me to debug this?
[16:00] <rgreening> so, logically, it should be either a suggests or and "or" with equivalent KDE package ArneGoetje
[16:00] <alex-weej> macbook pro 3.1
[16:01] <rgreening> s/and/an
[16:01] <seb128> pitti, bryce, slangasek: is there a documented procedure to debug such issues nowadays?
[16:01] <rgreening> ArneGoetje: the hard dep pulls in 38 new packages, 13 meg
[16:01] <maco> alex-weej: did you check the hotkey wiki page? if it doesn't show anything in input_events either, might need a kernel quirk for it. you're talking about a keyboard-type eject button right, not the thing on the tray?
[16:02] <seb128> ie multimedia keys not triggering an xevent
[16:02] <rgreening> all of which are Ubuntu specific and not Kubuntu related.
[16:02] <maco> seb128: pgraner told me to check the dsdt to try to figure out my keys
[16:02] <alex-weej> maco: yes, keyboard.
[16:02] <slangasek> seb128: https://wiki.ubuntu.com/Hotkeys/Troubleshooting
[16:03] <seb128> alex-weej: ^
[16:03] <alex-weej> ok thanks
[16:03] <maco> seb128: ive got 2 keys which don't make it through what's on the page slangasek linked. near the end of the page it says if all else fails, kernel quirk. pitti and pgraner agreed.
[16:03] <slangasek> rgreening: it definitely shouldn't be a suggests.  If it needs to be an 'or', then so be it
[16:04] <cjwatson> rgreening,ArneGoetje: perhaps evolution-documentation-en should Depends: yelp | language-support-translations-en
[16:04] <cjwatson> that's what the OOo translation packages do; it's ugly but we have no particularly good solution here in the dependency system :-(
[16:04] <cjwatson> that would make the overhead a mere 200KB
[16:05] <rgreening> sounds good, as long as we aren't required to pull in all these extra bits unnecessarily.
[16:05] <ArneGoetje> cjwatson: +1
[16:05] <rgreening> still not sure why we need evolution docs in kubuntu
[16:05] <rgreening> :)
[16:05] <slangasek> cjwatson: I thought evolution-documentation-en is one of the packages they want to avoid pulling in along with language-support-translations-en, so this would be inverted?
[16:06] <rgreening> ya
[16:06] <cjwatson> slangasek: on its own, though, it's pretty tiny
[16:06] <cjwatson> I think it's the size impact of its dependencies that is the bulk of the practical problem
[16:06] <slangasek> ok
[16:06] <cjwatson> cf. openoffice.org-help-en-gb Depends: openoffice.org-writer | language-support-translations-en
[16:07] <cjwatson> rgreening: you don't, it's just that we have no way at the moment to say "install language support packages of type 'translations' *that apply to Kubuntu*"
[16:07] <seb128> what is the issue you try to solve?
[16:07] <slangasek> seb128: kubuntu wants language-support-translations-en, just like ubuntu, but doesn't want GNOME deps pulled in with it
[16:07] <cjwatson> seb128: dependency explosion on Kubuntu CDs due to dependencies language-support-translations-en -> evolution-documentation-en -> yelp
[16:08] <seb128> oh
[16:08] <cjwatson> seb128: and language-support-translations-en at the moment (perhaps unfortunately) has to account for both desktops
[16:08] <rgreening> cjwatson:, ArneGoetje: http://paste.ubuntu.com:80/121915/
[16:08] <rgreening> thats the list of new packages...
[16:08] <cjwatson> seb128: the standard solution to this, as deployed in the last eight Ubuntu releases, has been to have the dependencies of language-support-* use "| language-support-foo" where appropriate
[16:09] <seb128> can't language-support- have that | directly?
[16:09] <rgreening> I liike having a lang pack for -kde
[16:09] <cjwatson> seb128: consider the semantics of language-support-translations-en Depends: foo | language-support-translations-en ;-)
[16:09] <seb128> what is wrong is to install evolution-documentation-en there
[16:09] <cjwatson> seb128: true, but on its own evolution-documentation-en is a fraction of the size
[16:10] <seb128> well the | choice being a kubuntu package
[16:10] <cjwatson> seb128: I'm all for designing a better system, but in the meantime I would recommend deploying the existing solution to this until we figure out something better that provably works
[16:10] <seb128> ie  language-support-translations-en Depends "evolution-documentation-en | kubuntu-something"
[16:10] <rgreening> seb128: the ways its packaged, see the paste above. 38 packages get pulled in unecessarily.
[16:10] <seb128> rgreening: I understand the issue
[16:10] <cjwatson> rgreening: thanks, we understand the problem
[16:10] <rgreening> :)
[16:11] <rgreening> Anything you can do to assist, would be awesome
[16:11] <cjwatson> seb128: I think the problem there is that we don't have an obvious candidate for the kubuntu-something - kubuntu-desktop is removable in ways that still leave you with something that's basically Kubuntu, much like ubuntu-desktop is
[16:11] <seb128> alright
[16:11] <rgreening> kde/kubuntu uses kontack for its groupware client, so I suggest a "|" on kontact docs.
[16:12] <rgreening> or something like that
[16:12] <seb128> cjwatson: I'm fine with your yelp | ... suggestion feel free to do an upload to change that if you want
[16:12] <seb128> we should really split those by flavor at some point though
[16:12] <rgreening> thanks for your help :)
[16:13] <ArneGoetje> seb128: register a blueprint for karmic :)
[16:13] <seb128> ArneGoetje: I don't think I care enough for that ;-)
[16:13] <ArneGoetje> seb128: :P
[16:14] <cjwatson> seb128: will do when I've finished caning my computer with upgrades ...
[16:14] <cjwatson> thanks
[16:14] <cjwatson> rgreening: is there a bug number for this?
[16:19] <rgreening> cjwatson: nope, I just noticed it and thought I come ask about it
[16:19] <rgreening> :)
[16:20] <cjwatson> rgreening: could you please file one so that we have an audit trail of why we did this when we come back to figure it out later?
[16:20] <cjwatson> rgreening: just a paste of the IRC log is fine if you want
[16:20] <rgreening> cjwatson: sure. do you want a tag added to the bug report (if so what?)
[16:20] <cjwatson> no, I don't care
[16:20] <rgreening> kk.
[16:20] <rgreening> 1 min
[16:32] <rgreening> cjwatson:  bug 333401
[16:32] <cjwatson> thanks
[16:33] <cjwatson> sigh, I meant a bug on evolution about evolution-documentation-*'s heavy dependencies though. I'll reassign
[16:33] <Keybuk> a lot of the commenters seem to be of the impression that inotify is somehow recursive up
[16:33] <Keybuk> which is ironic, since it's not even recursive between directories ;)
[16:43] <IntuitiveNipple> Keybuk: I've found a solution. Will attach a patch to the bug-report in a moment.
[16:43] <pecisk> pitti: updated patch for lastest sl-modem package version on Jaunty, also attached my working init.d script fully, if patch doesn't work out again
[16:43] <Keybuk> IntuitiveNipple: "a solution" ?
[16:44] <IntuitiveNipple> Keybuk: Yes. Instead of setting OPTION+="watch" in any script, I've done ENV{inotify}="watch".
[16:44] <IntuitiveNipple> Keybuk: Then I have a 99-inotify.rules that matches that and adds the OPTION after all rules have been processed
[16:44] <Keybuk> I have a patch to udev to do the same thing
[16:44] <Keybuk> it's not the complete fix though
[16:45] <Keybuk> since if you ran "udevadm trigger" at any point, it would all kick off
[16:45] <pitti> pecisk: thanks
[16:45] <Keybuk> IntuitiveNipple: http://people.ubuntu.com/~scott/udev.inotify.patch  posted on Sunday
[16:45] <IntuitiveNipple> Keybuk: I'm trying with trigger - it won't provoke the bug
[16:46] <Keybuk> IntuitiveNipple: it will, because the watch already exists
[16:46] <Keybuk> so lvm vgscan will trigger the change event
[16:46] <IntuitiveNipple> Testing on the lab PC I can't get the bug to show issuing a trigger or vgscan
[16:47] <Keybuk> right
[16:47] <Keybuk> that's because you've now entered the strange situation I have
[16:47] <Keybuk> where I just can't replicate the bug
[16:47] <Keybuk> despite all the conditions being true
[16:47] <Keybuk> and this seems to be linked to the observance that adding/removing udev_log changes the outcome
[16:48] <Keybuk> as well as adding/removing cores
[16:48] <Keybuk> OOI, could you test the patch and see if it has the same effect as your rules change
[16:48] <asac> stgraber: pastebinit manpage doesnt really say where and in which format a user can set defaults.
[16:48] <asac> stgraber: also in jaunty it doesnt use paste.ubuntu.com by default anymore. is that intentional?
[16:51] <Keybuk> I can see lvm vgscan opening the block devices O_RDWR
[16:51] <Keybuk> and closing them again
[16:51] <Keybuk> but no inotify event is firing in udev
[16:51] <Keybuk> which is a bit odd
[16:51] <IntuitiveNipple> Keybuk: I have a build of the package with that patch included from yesterday; let me find where I put it
[16:52] <munckfish> asac: sorry I took so long. I have a log now that documents the problem. I closed the original WPA related bug as I'm fairly certain that's solved. Have attached to bug 309457
[16:58] <asac> munckfish: ok. there is no successful association in it
[16:58] <asac> but thats ok i guess
[16:58] <munckfish> asac: what do you mean?
[16:59] <munckfish> asac: I can get a log with the successful association too
[16:59] <asac> munckfish: no all fian ;)
[16:59] <asac> did you say in the bug that it works with wired unplugged?
[17:00] <kirkland> does anyone know if apport in Jaunty works through proxies?
[17:00] <munckfish> asac: ok. Yes that's right. I unplugged the eth cable. Rebooted to follow the same sequence of steps, and as soon as I hit the desktop the wifi connection was up just fine.
[17:01] <asac> munckfish: did you say so in the bug too (that was my question)?
[17:01] <asac> otherwise please add that info
[17:02] <munckfish> asac: I think I forgot, I'll add an extra note
[17:06] <asac> munckfish: thanks. i am in a meeting now (~30 minutes)
[17:07] <munckfish> asac: ok thx for your time, I've added extra notes now. Let me know if you have any thoughts on it. Cheers
[17:10] <Keybuk> IntuitiveNipple: any luck?
[17:11] <IntuitiveNipple> Had to rebuild the package, just done, and moving it to the lab PC
[17:15] <doko> Riddell: please have a look at bug 304622
[17:22] <Riddell> looking
[17:28] <Riddell> doko: hum, it says "Error: Unable to find either PyQt v3 or v4." during configure
[17:29] <Riddell> doko: hmm, python2.6 can't import PyQt4.pyqtconfig
[17:30] <Riddell> dunno why, I have /usr/lib/python2.6/dist-packages/PyQt4/pyqtconfig.py
[17:33] <doko> Riddell: the error message is in the python2.5 build
[17:33] <IntuitiveNipple> Keybuk: Just tested the patch on a clean source of 138-1 and it appears to have solved the issue.
[17:35] <Riddell> doko: not for me it isn't
[17:35] <doko> Riddell: my python2.6 changes are at http://people.ubuntu.com/~doko/tmp/q.diff  could you recheck with these?
[17:36] <doko> Riddell: I tried on i386, if that makes a difference
[17:38] <Riddell> doko: I'm missing /usr/lib/python2.6/dist-packages/PyQt4/__init__.py
[17:38] <doko> looking ...
[17:39] <geser> IntuitiveNipple: that patch http://people.ubuntu.com/~scott/udev.inotify.patch ? I tried it but it didn't solve the issue for me (but I can retest just to be sure)
[17:40] <IntuitiveNipple> Do you want the binaries to save time?
[17:40] <IntuitiveNipple> geser: http://tjworld.net/ubuntu/bugs/lp332270/
[17:41] <geser> IntuitiveNipple: I've debs, just want to double check that I'm testing the right patch
[17:47] <IntuitiveNipple> Keybuk: MichaelEvans is testing the binary patch with encrypted and he stills suffers the thrashing disk, although the root got opened/mounted without early incident. With the 99-inotify.rules version, his PC started without any issues
[17:59] <Keybuk> IntuitiveNipple: your claims make no sense ;)
[17:59] <Keybuk> the patch does what you're _trying_ to do with the ENV stuff
[17:59] <Keybuk> except what you're trying to do with the ENV stuff doesn't make any difference
[18:00] <IntuitiveNipple> Makes a lot of difference. With the 99-inotify.rules and changes to 60-pers... and 65-dmsetup, the systems start okay
[18:02] <kozz> just a stupid question about the new dialog in transmission when a torrent is completed, what is the "cancel" button supposed to do?
[18:02] <kozz> I didn't want to test right now :) but just realized that is seemed strange now when I say it
[18:03] <Keybuk> IntuitiveNipple: then there must be a bug in your rules
[18:03] <Keybuk> because moving the OPTIONS to 99 or to 01 won't make a blind bit of difference ;)
[18:04] <IntuitiveNipple> well, it has on two separate systems with reinstalled 138-1 and dmsetup's 65- manually altered.
[18:04] <Keybuk> without seeing exactly what you've done, I can't comment precisely
[18:04] <Keybuk> but I suspect you've simply ended up with no inotify watches
[18:05] <Keybuk> either by a typo or a mis-assumption
[18:07] <Keybuk> IntuitiveNipple: I'm guessing that you're assuming that by moving the setting to 99, "after" LVM, that udev won't set the watch until later?
[18:07] <Keybuk> udev doesn't work that way
[18:07] <Keybuk> it processes the rules in the same manner, no matter what order things appear in
[18:07] <Keybuk> e.g.
[18:08] <Keybuk>   01.rules  RUN+="foo $name"
[18:08] <Keybuk>   02.rules  NAME="bar"
[18:08] <Keybuk> it will actually do
[18:08] <Keybuk>   mkdir /dev/bar
[18:08] <Keybuk>   foo /dev/bar
[18:08] <Keybuk> not the opposite, as you might expect
[18:08] <Keybuk> because the opposite is actually stupid
[18:08] <Keybuk> so no matter where you put the OPTIONS+="watch", it will always add the inotify watch after mknod() but before all the RUN rules
[18:11] <IntuitiveNipple> Hmmm... the lab PC has your binary package installed right now. I'll put the other one in and check what watches are set up after it starts
[18:12]  * pitti hugs tseliot
[18:13] <pitti> tseliot: thanks for figuring out bug 329410, this is driving me mad
[18:22] <ScottK> pitti: I see you are somewhat behind in your blog reading.  I wrote that one on notifications a long time ago.
[18:23] <ScottK> pitti: I think giving users the easy option to get the more upstream experience is a great thing.
[18:23] <pitti> ScottK: sorry for that, I just added a missing title today; I wrote that one weeks ago
[18:24] <ScottK> pitti: OK.  That makes sense.
[18:24] <ScottK> Now that you mention it, I think I even remember it.
[18:26] <pitti> yeah, we talked about it on IRC
[18:27] <ScottK> Personally, I'm pretty happy with what Knotify provides in KDE 4.2.
[18:27]  * Keybuk facepalms
[18:27] <pitti> good night everyone
[18:37]  * Riddell can list half a dozen issues with Knotify
[18:38] <NCommander> Is there a way to put an alternate CD on a USB stick?
[18:46] <maxb> NCommander: usb-creator?
[18:47] <NCommander> it doesn't work for me with alternates or server CDs; I was on the impression it was just for liveCDs
[18:47] <maxb> I'm sure it worked for me, but I seem to recall it only fixed up *some* of the boot options
[18:47]  * maxb hunts bugnumber
[18:48] <maxb> LP 313366
[18:48] <Keybuk> NCommander: WFM
[18:48] <NCommander> WFM?
[18:49] <maxb> Works For Me
[18:49] <Keybuk> Works For Me
[18:49] <Keybuk> IntuitiveNipple: http://git.kernel.org/?p=linux/hotplug/keybuk/udev.git;a=summary
[18:49] <Keybuk> IntuitiveNipple: top 10 patches
[18:49] <IntuitiveNipple> Keybuk: I'll pull it to my local repo and build the package from that
[18:51] <IntuitiveNipple> Keybuk: I meant to ask... is the repo supposed to also contain the test/sys/ ... tree ? it plays havock with any grep
[18:52] <Keybuk> yes
[18:52] <Keybuk> it's the udev test suite
[18:54]  * soren needs "An idiot's guide to dpkg-statoverride"
[18:54] <soren> $ dpkg-statoverride --list '*euca*'
[18:54] <soren> root eucalyptus 04750 /usr/share/eucalyptus/euca_rootwrap
[18:55] <soren> ...yet when a package comes along and provides that package, I get:
[18:55] <soren> -rwsr-x--- 1 root root 6176 2009-02-20 09:40 /usr/share/eucalyptus/euca_rootwrap
[18:55] <IntuitiveNipple> Keybuk: okay, because there are endless "recursive directory loop"
[18:58] <tseliot> pitti: np
[19:13] <IntuitiveNipple> Keybuk: well done... 18 seconds to boot
[19:16] <soren> I thought statoverrides were supposed to be applied any time dpkg put the file in question in place?
[19:16] <cjwatson> they ought to be, yes
[19:17] <soren> cjwatson: So the stuff I pasted 15-20 lines up doesn't make any sense, does it?
[19:17] <cjwatson> soren: err, the permissions in your dpkg-statoverride match those in ls -l
[19:17] <soren> Not the ownership.
[19:17] <cjwatson> oh, right
[19:17] <cjwatson> sounds like a bug then, assuming that the package isn't doing anything else funny
[19:18] <cjwatson> maybe if you're replacing an existing file you need an explicit chgrp? not sure without looking at the code TBH ...
[19:18] <cjwatson> dpkg-statoverride does have an --update switch which may be relevant here
[19:18] <soren> cjwatson: I tried removing the file, and "dpkg -i package.deb" again... Still no luck.
[19:18] <soren> Hm...
[19:18] <soren> What if...
[19:19] <cjwatson> just a quick check, does that group actually exist?
[19:19] <soren> $ getent group eucalyptus
[19:19] <soren> eucalyptus:x:127:
[19:19] <soren> Indeed.
[19:19] <soren> And if I pass --update to dpkg-statoverride, it dtrt.
[19:20] <soren> ...but dpkg seems to not care much.
[19:20] <soren> dpkg-statoverride does it directly from perl, so it's an entirely different codepath.
[19:20] <cjwatson> indeed
[19:21] <cjwatson> I'm happy to investigate given sample packages and a tarball of /var/lib/dpkg
[19:21] <soren> I'll look into it myself for a little bit. I just wanted to check if I was obviously doing it wrong.
[19:22] <jdong_> are there any known jaunty issues with lvm+dmcrypt boot?
[19:22] <soren> cjwatson: I'll take you up on the offer if I can't work it out. Thanks :)
[19:24] <IntuitiveNipple> jdong: Yes: bug # 332270
[19:24] <jdong_> where is the best place to break to diagnose a "volume group 'main' not found"?
[19:24] <jdong_> oh.
[19:24] <IntuitiveNipple> jdong: Looks like we have a fix; I've just tested Keybuk's upstream patches and it seems to do the job
[19:24] <IntuitiveNipple> jdong: bug #332270
[19:26] <jdong_> IntuitiveNipple: thanks
[19:28] <jdong_> ha. silly me. breaking on top with a USB keyboard.
[19:33] <soren> cjwatson: False alarm.
[19:34] <jdong_> ok that's it. LiveCD time.
[19:34] <soren> cjwatson: dpkg dtrt. Immediately afterwards, the daemon I start from my postinst helpfully calls "chown root:root" on it.
[19:35]  * soren pats strace on the head
[19:35] <jdong_> I guess USB keyboard with broken udev is not going to work out well for my laziness.
[19:35] <IntuitiveNipple> jdong: Doesn't BIOS offer an option for "Legacy USB" to cover that period? I know many do
[19:36] <jdong_> IntuitiveNipple: not helpful when the kernel loads the EHCI/UCHI modules which seems to kick off the BIOS emulation
[19:37] <IntuitiveNipple> jdong: the wonders of modern technology :)
[19:37] <jdong_> lol, indeed :)
[19:37] <jdong_> oh how helpless are we all when udev dies
[19:44] <Keybuk> IntuitiveNipple: not a complete fix
[19:44] <Keybuk> if you have multiple PVs, they'll just trigger each other
[19:45] <soren> I have multiple pv's, but am not affected. What am I doing wrong? :)
[19:47] <Keybuk> soren: there's another bug in udev I found in the process
[19:47] <Keybuk> if lots of inotify events come in at once, then it only processes the first one
[19:48] <Keybuk> if you apply the patch to fix _that_ bug
[19:48] <Keybuk> then you'll be affected by the other ;)
[19:48] <soren> Oh. Erm.. "Thanks" :)
[19:50] <Keybuk> stupid dump question of the day
[19:50] <Keybuk> how do I build an i386 binary on an amd64
[19:52] <jdong_> package or binary? gcc -m32?
[19:53] <Keybuk> jdong_: that complains about missing libgcc.a
[19:53] <jdong_> fun
[19:53] <ScottK> doko: Is there documentation yet on pycentral.mk?  Should it be used by any CDBS using pycentral package?
[19:53] <Keybuk> I only have x86_64-linux-gnu in /usr/lib/gcc
[19:54] <jdong_> is that lib32gcc1's job?
[19:54] <jdong_> nope
[19:55] <Keybuk> ahh, gcc-multilib
[19:55] <doko> ScottK: not yet; I think it's better to move this into the python package, maybe with a better name. but I'll keep this one in python-central. Just didn't want to hard-code this in every dir
[19:56] <ScottK> OK.
[19:57] <Keybuk> IntuitiveNipple: so this package fixes it for you?
[19:57] <IntuitiveNipple> Keybuk: It appears to have done, yes.
[19:57] <Laney> IntuitiveNipple: Do you have a deb?
[19:57] <IntuitiveNipple> Keybuk: Do you want to provoke/test it at all?
[19:58] <Laney> I am having this too
[19:58] <Keybuk> IntuitiveNipple: now that I've fixed the bug that stopped me from being able to replicate it, I'm quietly confident
[19:58] <Keybuk> ie. I can fix that bug, replicate it every time in vmware, apply the other patches, and it goes away again
[19:58] <Keybuk> now, in theory
[19:58] <Keybuk> if I add another disk, with another LVM PV on it, it will explode
[19:59] <Laney> I have multiple PVs
[19:59] <IntuitiveNipple> Keybuk: OK... well if you need it, just shout
[20:00] <IntuitiveNipple> Laney: http://tjworld.net/ubuntu/bugs/lp332270/
[20:00] <Laney> thanks muchly
[20:00] <Laney> do I need both?
[20:00] <IntuitiveNipple> udev and libvolume-id1
[20:00] <Keybuk> just udev actuall
[20:01] <IntuitiveNipple> These are builds of Keybuk's git tree tip
[20:10] <IntuitiveNipple> Keybuk: Confirmed. I deleted the PV here and created an extended in its place, and added 3 PVs inside it. As soon as I'd run partprobe the disk started thrashing
[20:12] <Laney> I am getting "unable to create db file" errors with this udev deb
[20:12] <IntuitiveNipple> Keybuk: Deleting the PVs whilst udev is thrashing cures the problem... a bit drastic though :)
[20:13] <IntuitiveNipple> Laney: which arch?
[20:13] <Laney> amd64
[20:13] <Keybuk> Laney: it helps if you run it as root ;)
[20:13] <Laney> *run* it?
[20:13] <IntuitiveNipple> Hmmm, there were some glitches on the 'net when that was being transferred, but I did an md5sum check and it matched the source
[20:13] <Laney> I just restarted my machine
[20:13] <Keybuk> weird
[20:14] <Laney> and yeah, I have multiple PVs and it still doesn't boot
[20:14]  * Laney snaps a pic
[20:14] <IntuitiveNipple> multiple PVs will trigger the bug
[20:14] <Laney> hah
[20:14] <Laney> it just moved on before I had the chance
[20:17] <IntuitiveNipple> Keybuk: The obvious fix is upstream lvm, so vgscan doesn't open RDWR, but for now, could we work around it by having the rules add an attribute that would prevent the vgscan on any volumes that had already been scanned?
[20:18] <Keybuk> IntuitiveNipple: I'm looking into the obvious fix now ;)
[20:18] <IntuitiveNipple> :)
[20:19] <mathiaz> slangasek: re bug 305264 and your comment https://bugs.launchpad.net/ubuntu/+source/gnutls12/+bug/305264/comments/33 - do you have reference to the discussion you mention in your comment?
[20:22] <LaserJock> is there a kees-replacement while he's on vacation?
[20:22] <Keybuk> "kees-replacement" ?
[20:23] <Keybuk> soren is watching back episodes of Doctor Who, does that count?
[20:23] <mathiaz> LaserJock: mdeslaur may be able to help you - as well as jdstrand
[20:23] <Keybuk> pitti grew the "evil clone" beard a while back, so he's on "evil clone" duty
[20:23] <Keybuk> (either that, or pitti *is* now his own evil clone from a mirror universe)
[20:24] <LaserJock> Keybuk: is that a Multiverse clone then?
[20:24] <mdeslaur> LaserJock: yes?
[20:26] <LaserJock> mdeslaur: are Launchpad bugs filed for CVEs or are they handled separately?
[20:27] <jdstrand> LaserJock: I've been told you were looking for kees
[20:27] <jdstrand> LaserJock: I somehow dropped off Freenode
[20:27] <LaserJock> I'm looking at http://people.ubuntu.com/~ubuntu-security/cve
[20:27] <jdstrand> LaserJock: we track CVEs in ubuntu-cve-tracker
[20:27] <mdeslaur> LaserJock: you're asking if you should file a bug?
[20:27] <LaserJock> and there are a number of CVEs on a package I'm trying to work on
[20:28] <LaserJock> I think some are going to get fixed, but I'd like to be able to track everyting, figure out which releases are effected, etc.
[20:28] <tdomhan> the REVU is down? any information when it will be up again?
[20:28] <jdstrand> LaserJock: LP doesn't have enough flexibility for us to track everything in it
[20:29] <jdstrand> LaserJock: so we have ubuntu-cve-tracker, which that page you mentioned is generated from
[20:29] <LaserJock> so I noticed there are https://launchpad.net/bugs/cve/ links
[20:29] <jdstrand> LaserJock: we are getting close to being able to sync uct with LP
[20:29] <jdstrand> LaserJock: we do add LP bugs to uct as we see them
[20:29] <jdstrand> LaserJock: feel free to add bugs to LP, along with CVE links, and we'll get them in sync with uct
[20:29] <geser> thekorn: use revu.ubuntuwire.org instead of .com
[20:30] <geser> thekorn: sorry, wrong tab-completion
[20:30] <LaserJock> jdstrand: ok, but what if they're already on uct, does that mean they have an LP bug?
[20:30] <geser> tdomhan: use revu.ubuntuwire.org instead of .com
[20:30] <jdstrand> LaserJock: if you want to do triage in uct yourself, go to https://code.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master. check out a branch, read README and ping us when ready
[20:31] <tdomhan> geser, thanks, is that a permanent domain change?
[20:31] <jdstrand> LaserJock: being in uct does *not* mean they have an LP bug
[20:31] <jdstrand> LaserJock: when a couple of bugs are fixed in LP, that will change
[20:31] <LaserJock> jdstrand: ok
[20:31] <geser> tdomhan: I don't really know, I guess the .com will come back when it gets renewed again
[20:32] <cjwatson> soren: haha, excellent :-)
[20:32] <LaserJock> jdstrand: so in debian/changelog what's the best reference to say that we're fixing a CVE, just using the CVE number?
[20:32] <jdstrand> LaserJock: yes. please see https://wiki.ubuntu.com/SecurityUpdateProcedures#Preparing%20an%20update for details
[20:33] <jdstrand> LaserJock: it is good to reference the CVE number, the LP bug if there is one, as well as the patch url. The above link has details
[20:36] <LaserJock> jdstrand: ok cool, this package has 10 CVEs on the tracker, hopefully we can get that number down
[20:37] <jdstrand> LaserJock: excellent
[20:46] <Laney> Keybuk: Here (http://orangesquash.org.uk/~laney/udev.jpg) are the new messages that I get after installing IntuitiveNipple's .deb. They don't seem to affect the boot
[20:46] <Laney> also my interfaces have been renamed :(
[20:46] <Laney> (but I see there is a bug for this already)
[20:49] <asomething> jdstrand: Bug #316550, Debian's 0.1.1-10 only fixes CVE-2008-5620, my fix for CVE-2008-5619 comes from upstream. 2008-5620 isn't actually fixed in Testing it's fixed in unstable by using the new upstream release. i'm really not sure how to make it less invasive
[20:51] <Laney> Keybuk: Is udevd hosing the CPU a part of this bug?
[20:52] <asomething> jdstrand: err....  2008-5620 is fixed in testing not  2008-5619
[20:53] <jdstrand> asomething: aren't both? I also looked upstream and couldn't find the changeset that matched the debdiff.
[20:54] <jdstrand> asomething: if this is in error, can you comment on the bug and update the patch to reference the upstream commit that fixes this?
[20:54] <jdstrand> asomething: I thought 5619 was fixed in -9...
[20:56] <asomething> jdstrand: ahh, i see now, sorry. I'll use the debian fix. upstream provides new files here: http://sourceforge.net/forum/forum.php?forum_id=898542
[20:59] <jdstrand> asomething: that link isn't super useful. it would be best if you could find the svn commit. however, if you go with Debian's changes, then no need
[21:04] <Keybuk> Laney: that would be the primary symptom of the bug, yes
[21:04] <jdstrand> asomething: thanks for your work on this :)
[21:04] <Laney> Keybuk: Ah, I thought it was just slowness in the boot. Good to know, thanks
[21:05] <slangasek> mathiaz: the upstream discussion?
[21:07] <mathiaz> slangasek: yes
[21:07] <mathiaz> slangasek: was it an discussion with gnutls upstream or openldap upstream?
[21:08] <slangasek> mathiaz: gnutls upstream; linked to from the referenced Debian gnutls bug report
[21:08] <mathiaz> slangasek: ok. So openldap upstream hasn't been consulted
[21:09] <slangasek> indeed not
[21:41] <Keybuk> hmm
[21:41] <Keybuk> I wonder
[21:41] <Keybuk> can you re-open a file descriptor with different flags?
[21:43] <slangasek> well, I guess freopen() can, but I imagine it just closes and reopens as necessary?
[21:43] <cjwatson> dup2 + fcntl?
[21:43] <slangasek> ah
[21:43] <cjwatson> oh but you can't fiddle with O_WRONLY etc. with fcntl
[21:44] <Keybuk> cjwatson: yeah, sadly
[21:44] <Keybuk> close() and open() it is
[21:46] <directhex> Keybuk, we almost have a gdb addin package for monodevelop ready. and it already supports some source control systems directly. since you mentioned it on the blogosphere
[21:47] <Keybuk> directhex: \o/
[21:47] <Keybuk> does monodevelop have an equivalent of C-x 4 a
[21:48] <Keybuk> and does monodevelop support autoconf/make yet? :)
[21:48] <directhex> it has autofoo integration, although i haven't used it
[21:48] <directhex> and i know it has vi bindings - dunno about emacs
[21:48] <directhex> s/bindings/keyboard &/
[21:48] <Keybuk> I don't want vi or emacs bindings
[21:48] <Keybuk> what I mean is does it have an add-to-changelog functionality
[21:48] <Keybuk> ie. I'm editing source code
[21:49] <Keybuk> I press a key or two
[21:49] <directhex> oh. i think so. let me check
[21:49] <Keybuk> and it takes me to the ChangeLog file, with the date, my name, e-mail address, the current filename, and function all filled in already
[21:49] <racarr> Keybuk: A little late, but I think you want dup3
[21:50] <Keybuk> racarr: sadly again, you can only add O_CLOEXEC to the flags
[21:50] <RAOF> Keybuk: It does have autofoo integration, but I always end up writing the autofoo myself; it generates only semi-sane autofoo.
[21:51] <Keybuk> then again, knowing the kernel, to actually change the flags from O_RDONLY to O_RDWR would involve an fput()/fget() so it's a close()/open() anyway
[21:51] <Keybuk> RAOF: don't want it to generate it - just use what's there
[21:51] <RAOF> I think that works, yeah.
[21:51] <RAOF> Honestly, I use monodevelop as a glorified text editor.
[21:52] <racarr> Keybuk: Ah. Nevermind.
[21:52] <RAOF> In part because it doesn't respect PKG_CONFIG_PATH, and I'm always developting against stuff installed in ~/.local
[21:56] <directhex> Keybuk, no default key binding, but yes, changelog adding is a bindable menu option
[21:57] <Keybuk> directhex: nice
[21:57] <Keybuk> directhex: so when does the gdb stuff arrive?
[21:58] <directhex> Keybuk, when meebey, hanska & i manage to beat git into a bloody pulp..... and a nice friendly MOTU uploads it... and it passes NEW
[21:58] <Keybuk> PPA :p
[21:58] <Keybuk> and a valgrind addin? :p
[21:59] <directhex> Keybuk, patches welcome!
[21:59]  * Keybuk would have to learn C# properly
[21:59] <directhex> well you want the mdb addin if you wanted to learn c#
[21:59] <directhex> i thought you were happy enough with c/c++-like things
[21:59] <directhex> oh, wait, for patches
[22:00]  * directhex si teh dum
[22:01] <directhex> you can write addins in any mono language, if you're in the mood - e.g. monodevelop-boo is written in boo
[22:01] <directhex> boo's a cute language
[22:01] <meebey> 22:48:51 <Keybuk> what I mean is does it have an add-to-changelog functionality
[22:01] <meebey> yes it has, all VCS commits gets added to a changelog automatically
[22:01] <Keybuk> not quite what I meant
[22:02] <directhex> and non-vcs commits too
[22:02] <meebey> so whats add-to-changelog then
[22:02] <Keybuk> ChangeLog
[22:02] <Keybuk> it's a top-level file in most projects
[22:02] <meebey> yes thats what it does
[22:02] <meebey> you can set it to top-level or deepest
[22:02] <Keybuk> I write that as I go
[22:02] <directhex> i'd take a screenshot but, y'know, effort
[22:02] <Keybuk> then when I commit to a vcs, I just use the diff of the top-level ChangeLog as the log message
[22:02] <cjwatson> meebey: some of us prefer generating the VCS commit message from the changelog rather than the other way round :)
[22:03] <Keybuk> directhex: I can't actually find the option
[22:03] <cjwatson> it's easier to write that as you go along rather than being forced to do it all at the end when you're committing
[22:03] <meebey> you have to enable changelog integration in the solution or project first IIRC
[22:03] <directhex> Keybuk, Edit menu, near the bottom, to add an entry. project options bottom section lets you configure format
[22:03] <meebey> but AFAIK its bound to the VCS actions
[22:03] <directhex> meebey, nay!
[22:03] <directhex> not in 2.0b1 anyway
[22:03] <Keybuk> directhex: no option there, just "Insert standard header"
[22:04] <meebey> cjwatson: then you dont commit often enough!
[22:04]  * meebey runs
[22:04] <directhex> Keybuk, is this 1.0 or 1.9.2?
[22:04] <meebey> directhex: even 1.0 has changelog integration
[22:05] <Keybuk> directhex: 1.9.2 from your PPA
[22:05] <directhex> Keybuk, and it might be in the monodevelop-versioncontrol package, if you don't have that
[22:05] <Keybuk> not that I can figure out how to create a project in monodevelop anyway ;)
[22:06] <cjwatson> meebey: my commits are about as granular as I can possibly make them, actually ;)
[22:06] <cjwatson> (sanely, anyway)
[22:06] <meebey> cjwatson: excuses excuses! :-P
[22:07] <cjwatson> I can't help it if you like a crackful changelog generation method ;-)
[22:07] <directhex> if my request for UDS sponsorship gets approved, then there'll be an opportunity to play in a group environment :D
[22:07] <meebey> so you switch between the changelog and the source while you are working on it?
[22:08] <meebey> I usually read the diffs when I commit and then write what I changed..
[22:08] <meebey> as it might need a few cycles till it works (by testing)
[22:08] <Keybuk> directhex: actually, quite seriously
[22:08] <meebey> so the code is written but not working and maybe the approach was all wrong
[22:08] <Keybuk> how _does_ one open an existing piece of code in monodevelop? :p
[22:10] <RAOF> Keybuk: file->open ?
[22:10] <directhex> Keybuk, the root unit is a solution, a solution contains projects. you should be able to file/open individual files, but need a solution for useful interaction
[22:11] <Keybuk> so how do I create a solution/project for an existing program?
[22:13] <directhex> new empty solution, preferably of the language type that your project is, and add files
[22:13] <cjwatson> meebey: not all the time, but sometimes it is useful not to write the whole changelog message right at the end
[22:14] <directhex> anyway, feel free to beat upstream with a stick if you don't like it ;)
[22:14] <cjwatson> meebey: I often find that, while I'm describing what I did, I notice mistakes, pare down the diff somewhat, etc.
[22:14] <cjwatson> meebey: and I prefer to write the changelog with reference to a diff (i.e. bzr diff | view -, :spl ChangeLog) rather than with reference to a VCS commit editor
[22:14] <Keybuk> directhex: how does it know to use autoconf, etc.?
[22:15] <directhex> Keybuk, i don't think it has much in the way of existing-autofoo ability. it can create its own, but i don't know about importing existing
[22:16] <directhex> Keybuk, i forget which menu it's in, but there's a clicky option in a menu to create makefiles, which lets you pick autofoo
[22:17] <RAOF> Hm.  That's changed since 1.0
[22:17] <RAOF> There used to be a box "run autogen.sh before build"
[22:17] <Keybuk> right, but I have the complete existing project
[22:17] <Keybuk> and just want to edit things
[22:17] <Keybuk> can't you just go "here's a project, it has existing Makefile.am files, go figure it out yourself"
[22:18] <Keybuk> ideally that would result in a complete solution already
[22:18] <RAOF> No.  But that _would_ be pretty awesome.
[22:18] <RAOF> It sounds quite hard, though.
[22:18] <Keybuk> why?
[22:18] <Keybuk> Makefile.am are eeeeasy to parse
[22:18] <Keybuk> Project for each bin_PROGRAMS type entry
[22:18] <Keybuk> and lookup the SOURCES for them for the files
[22:18] <RAOF> I suppose if you don't want to support people doing crazy stuff, it'd be easy.
[22:19] <Keybuk> crazy stuff they can just Add File, etc.
[22:20] <RAOF> It'd work particularly well for C/C++ projects, because they do crazy stuff least frequently.
[22:20] <directhex> Keybuk, could be a fun challenge for someone who's a little bored
[22:20] <RAOF> directhex: How do you make "Edit->Add ChangeLog Entry" be not disabled?
[22:20] <directhex> RAOF, um... have you enabled it in project options?
[22:20] <RAOF> directhex: Yes.
[22:21] <directhex> ehm..... ya SUUUUUUUUUUUUURE?
[22:21] <directhex> i dunno. poke lluis or mhutch? it worked in my brief tinkering
[22:21] <RAOF> directhex: YES.  In both the default policies, and in the solution.
[22:22] <RAOF> Anyway.  Importing projects from a top-level Makefile.am would be pretty cool, and hopefully not too hard if you do it simple-mindedly.
[22:31]  * Keybuk breaks lvm
[22:39]  * geser will wait a few days before he updates udev and lvm
[22:39] <Keybuk> geser: yes, that's helpful
[22:39] <Keybuk> that way we won't know whether or not the bug is fixed
[22:41] <geser> Keybuk: I'd test the new packages but I currently don't have time to "break" my jaunty before Thursday
[23:37] <nhandler> Does anyone here know when elmo is usually online? I've been trying to contact him for a few weeks now. I have tried sending him /msg's and emails, but have not gotten a response.
[23:39] <cjwatson> he was travelling last week and thus working hard at fairly unpleasant times for him. Do you really need elmo specifically?
[23:40] <nhandler> cjwatson: I'm still trying to hunt down a status update of people.ubuntu.com. The response from everyone I have talked to has been to talk to elmo
[23:42]  * cjwatson looks for an RT request about this
[23:44] <cjwatson> normally, I would expect to be able to find elmo during UK working hours
[23:46] <nhandler> I have tried sending him a /msg at around 12:00 UTC (before I leave for the day). I have also tried sending him emails. It is nothing urgent, but I would appreciate a response
[23:47] <cjwatson> can't really help you further, sorry ...
[23:48] <nhandler> cjwatson: No problem. But if you see him, please let him know that I have been trying to contact him.
[23:48] <cjwatson> sure
[23:49] <Keybuk> Displaying first 80 comments.  View all 114 comments or add a comment.
[23:49] <Keybuk> !!
[23:49] <Keybuk> holy launchpad misfeature!
[23:50] <jdong_> It should say "Displaying summary. Add a comment, add a comment, post on Digg, or view all comments" right?
[23:50] <Keybuk> it needs a link to send whatever Jono's just blogged about to the PRESS
[23:50] <LaserJock> jdong_: no slashdot or technocrati?
[23:51] <Keybuk> but y'know
[23:51] <Keybuk> I'm usually interested in the _most_recent_ comments on a bug
[23:51] <Keybuk> not the _oldest_
[23:51] <jdong_> IMO there should be karma attachable to posts
[23:51] <jdong_> a la digg, with a developer/driver-tickable "bump up +9000" button.
[23:52] <Keybuk> no
[23:52] <jdong_> if you look at recent comments you are more than likely to see "yeah I get that too" times 100
[23:52] <Keybuk> we should give the posters a "bump up +9000" button
[23:52] <Keybuk> that when you click it gives them a big box saying "your post has been bumped"
[23:52] <Keybuk> but NOTHING ELSE
[23:52] <Keybuk> they'll click on it for weeks happily without realising
[23:52] <StevenK> Haha
[23:53] <directhex> jdong, what, 9000?
[23:58] <ScottK> doko: Since python-celementtree and python-elementtree are incorporated in Python 2.5+, should be be getting them removed or do you need them for Zope?