[00:00] <cjwatson> (zapping the '^' check and copying the entire string one-by-one breaks too)
[00:00] <keescook> that leaves the "^" though, right?
[00:01] <cjwatson> right
[00:01] <cjwatson> oh, hmm, I wonder if 'put' needs to be given a pointer type
[00:01] <cjwatson> I bet it's type-sensitive ...
[00:19] <keescook> cjwatson: it's performing a forall against menuitemmap.text while changing the contents of menuitemmap.text...
[00:19] <cjwatson> the forall is against the string returned by translate, actually
[00:20] <keescook> er, or not? the forall is the translation -- yeah
[00:20] <cjwatson> I'm trying to replace it by for though in case forall is the problem
[00:20] <cjwatson> hmm, that sentence could have used some punctuation
[00:20] <cjwatson> nope, using a for loop instead doesn't help
[00:20] <keescook> it was easier to parse than gfxboot code ;)
[00:21] <cjwatson> coffee
[00:23] <slangasek> "by for though in case" - who needs punctuation, just declare it to be a new dialect of python
[00:43] <cjwatson> keescook: as far as I can see, any attempt to write into menuitemmap.text using 'put' breaks it
[00:44] <mathiaz> jdstrand: re bug  202706 - did you forward the patch to Debian ?
[00:44] <ubotu> Launchpad bug 202706 in mysql-dfsg-5.0 "MySQL 5.0.51: ORDER BY not working with GROUP BY" [High,Fix released] https://launchpad.net/bugs/202706
[00:44] <jdstrand> mathiaz: not yet, plan to
[00:45] <keescook> cjwatson: odd, very odd
[00:47] <keescook> cjwatson: are there other cases of string-putting working?
[00:48] <cjwatson> keescook: loads
[00:48] <cjwatson> it's used all over the place
[00:49] <keescook> cjwatson: what happens if you drop "translate" and leave everything else?
[00:49] <ion_> FilenameType		Size	Used	Priority
[00:49] <ion_> /dev/compcache0                         partition	30416	22380	100
[00:49] <keescook> I don't really see why the source of the put should matter, though
[00:49] <ion_> Uh, sorry.
[00:49] <cjwatson> keescook: I think that worked, would have to check again
[00:54] <emgent> heya people
[00:54] <keescook> cjwatson: does forall include the terminating null?
[00:55] <keescook> oh, nm, it's nulled at the end.  hrmf
[00:55] <cjwatson> shouldn't
[00:55] <cjwatson> gfxboot is at 4.0.1 upstream
[00:55] <cjwatson> yarrr
[00:58] <cjwatson> though no changes in bincode.asm so I guess that isn't relevant
[00:59] <mathiaz> Is there a way I can figure out which packages depends on mysql-server (excluding Recommends and Suggests) ?
[01:00] <jdstrand> mathiaz: apt-cache rdepends?
[01:01] <jdstrand> (don't know how it deals with Recommends and Suggests off-hand)
[01:02] <keescook> cjwatson: interesting update to /split def
[01:03] <mathiaz> jdstrand: hum - it includes Recommends and Suggests
[01:03] <cjwatson> keescook: hmm, where?
[01:04] <keescook> in the upstream system.inc
[01:05] <keescook> +  % split does not work if str1 is in a special memory region (where
[01:05] <keescook> +  % 'cvp length' does not work). So we dup it first.
[01:05] <keescook> cjwatson: you want the full diff pasted somewhere?
[01:06] <cjwatson> keescook: no, I have it. I think that might be referring to string literals in the bytecode
[01:06] <keescook> yeah... ow my head
[01:07] <cjwatson> keescook: stripping out a bunch of keymaps also works around it, as Riddell suggested earlier on #ubuntu-release
[01:07] <cjwatson> I think we're overflowing gfxboot's available memory, perhaps
[01:07] <Volans> Hi, lool can I ask you a thing about the automount of a crypted partition of a USB HD?
[01:08] <cjwatson> I might be able to fix it by stripping out some unused strings
[01:08] <jdstrand> mathiaz: apt-rdepends?
[01:10] <jdstrand> mathiaz: I think it goes too far though
[01:10]  * Riddell hugs colin and kees and goes to bed
[01:11] <keescook> I don't understand why reducing the memory footprint would solve it -- both strcpy and put operate on the same already-malloc'd region.  hmpf
[01:12] <cjwatson> yeah, I know
[01:12] <mathiaz> jdstrand: awesome - that's what I was looking for
[01:12] <cjwatson> this is all very, very weird
[01:13] <cjwatson> if I rip out dia_install.inc and everything related to it (since it was unused in Ubuntu anyway), it all works
[01:13] <keescook> cjwatson: the bootloader defines available memory? it's not yet obvious to me where that happens.
[01:14] <cjwatson> err. somewhere in syslinux and/or gfxboot, I'm not entirely certain where
[01:14] <keescook> looks liek gfxboot reads it from a "sysconfig" area of the boot loader
[01:15] <keescook> I've haven't looked at the memory areas yet, but maybe the stack is crashing into malloc? strcpy is smaller than forall
[01:16] <keescook> I have no idea where code vs stack vs data vs malloc is stored yet :{
[01:16] <cjwatson> it could be that, yeah
[01:17] <cjwatson>  58 files changed, 3 insertions(+), 3042 deletions(-)
[01:17] <cjwatson> I have to say I'm happy with that kind of change on principle
[01:17] <keescook> hah -- what's that? 4.0 release?
[01:17] <cjwatson> no, ripping all this stuff out
[01:17] <keescook> oh haha
[01:18] <cjwatson> including translations
[01:18] <keescook> eek
[01:18] <keescook> cjwatson: so, what produces the syslinux config that launches gfxboot?
[01:18] <cjwatson> http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
[01:27] <keescook> cjwatson: my brain is melted enough for one day -- sounds like we have a viable workaround.  :P
[01:27] <Hobbsee> mmmm....brains....
[01:27] <cjwatson> keescook: me too
[01:27] <keescook> (I don't see any hard-coded memory limits in config files -- perhaps isolinux has one internally, but I'm going to stop looking)
[01:27] <keescook> cjwatson: I feel kind of up to speed on gfxboot now, though.  ;)
[01:28] <cjwatson> yay
[01:28] <cjwatson> a victim
[01:28] <cjwatson> :-)
[01:28] <keescook> hehe
[01:28] <cjwatson> the discussion was useful even if the solution was a lot cruder than we might have hoped
[01:28] <cjwatson> we might need those associative memories again in the future ...
[01:29] <keescook> yup, I figure I might actually be useful Next Time.  :)
[01:30] <cjwatson> you were :)
[01:30] <keescook> heh
[02:21] <bryce> slangasek: aforementioned fix posted to bugs 197645 and 199960 for validation of the fix before uploading.
[02:21] <ubotu> Launchpad bug 197645 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in rw_screen_list_outputs()" [Medium,In progress] https://launchpad.net/bugs/197645
[02:21] <ubotu> Launchpad bug 199960 in gnome-settings-daemon "error starting GNOME Settings Daemon" [High,Confirmed] https://launchpad.net/bugs/199960
[02:25] <vlowther> bug #198808, what is up with that?  Who though it would be a good idea to pass all the video quirks unless specifically told not to?
[03:09] <Amaranth> hmm, seems i spend 10 seconds in initramfs on boot
[03:09] <jdong> lol you're really motivated to fix that, huh? :)
[03:09] <RAOF> Amaranth: Fujitsu was also seeing something like that (although 30 sec or something)
[03:09] <Amaranth> jdong: was watching a movie :)
[03:09] <Amaranth> jdong: and i want my < 20 second boot :D
[03:09] <jdong> Amaranth: lol
[03:09] <jdong> everyone wants my 19s boot :)
[03:10] <Amaranth> jdong: not fair that you get 19s with 19MB/s and I get 32s with 47MB/s :P
[03:11] <Amaranth> i can see why you have me start udev on starting readahead though, i guess I have the IO to spare :P
[03:12] <pwnguin> is this something that shows up before bootchart begins loggin?
[03:12] <Amaranth> no
[03:13] <Amaranth> http://www.realistanew.com/random/hardy-20080317-3.png
[03:13] <Amaranth> jdong: also, you start a lot less stuff
[03:13] <pwnguin> oh wow
[03:13] <Amaranth> pwnguin: yeah, it's upstart scripts calling init scripts
[03:13] <Amaranth> but in parallel and event driven
[03:13] <Amaranth> jdong did it
[03:14] <pwnguin> what?
[03:14] <pwnguin> made it tank?
[03:14] <jdong> Amaranth: nice, your real boot is 22s if initramfs didn't suck.
[03:14] <Amaranth> oh, the 10 second stall isn't jdong
[03:14] <Amaranth> i'm pretty sure it's been doing that all along
[03:14] <jdong> pwnguin: the solid blue from 23 to 30 is all me :)
[03:14] <pwnguin> but look at that green line
[03:14] <pwnguin> that's all seek =(
[03:14] <Amaranth> jdong: yeah, i think if i trim down what i start and try that defragment thing i can get 12-15 seconds :)
[03:15] <jdong> Amaranth: try an easy cheap defrag replacement first
[03:15] <Amaranth> pwnguin: the whole boot is seek except for readahead
[03:15] <pwnguin> even readahead
[03:15] <Amaranth> that's why readahead is there :P
[03:15] <Amaranth> eh? during readahead I peak at 47MB/s
[03:15] <jdong> Amaranth: tar up all the files in /etc/readahead/boot
[03:15] <jdong> Amaranth: then unpack it back into /
[03:15] <jdong> actually cpio probably works better with a list of files ;-)
[03:16] <Amaranth> that's...sneaky
[03:16] <pwnguin> heh
[03:16] <jdong> Amaranth: for me that halved readahead time.
[03:16] <pwnguin> if it works
[03:16] <jdong> Amaranth: cheaper than defragging
[03:16] <Amaranth> i see why it works
[03:16] <jdong> lol it is really sneaky and cheap :)
[03:16] <Amaranth> gimme a script or something? :)
[03:16] <pwnguin> xargs?
[03:17]  * Amaranth lazy
[03:17] <jdong> Amaranth: lol one sec
[03:17]  * jdong whips out the command he used
[03:17] <jdong> Amaranth: cat /etc/readahead/boot | xargs sudo tar cvpf /tmp/init.tar
[03:18] <ion_> Wasn't someone working on actually rearranging blocks on the partition based on usage patterns? That would entirely remove the need for readahead, i'd think.
[03:18] <jdong> Amaranth: sudo tar xvpf /tmp/init.tar -C /
[03:18] <Amaranth> tar cf foo `cat /etc/readahead/boot | xargs`
[03:18] <Amaranth> alright, i'll use yours
[03:18] <jdong> lol yours works too :)
[03:18] <jdong> I'd use p with tar though
[03:18] <jdong> you never know what permissions some of those files might need :)
[03:18] <pwnguin> then pipe that back out to tar ;)
[03:19] <jdong> pwnguin: LOL that sounds like... fun :D
[03:19] <pwnguin> jdong: so how expensive is ext3 defrag?
[03:19] <pwnguin> im not even aware of an application that does that
[03:19] <jdong> pwnguin: e2defrag
[03:19] <jdong> psusi patched it to work with ext3
[03:19] <jdong> it works... just is a lot more destructive than this
[03:19] <jdong> this operation is more or less atomic
[03:20] <pwnguin> define destructive
[03:20] <Amaranth> wow that went way too fast
[03:20] <jdong> pwnguin: lose power in the middle of the process
[03:20] <pwnguin> ah
[03:20] <jdong> Amaranth: yeah it's instantaneous and yields a measurable performance for me
[03:20] <jdong> Amaranth: btw I'm really impressed by how deep your bootchart is
[03:20] <jdong> that's amazing
[03:21] <Amaranth> ok that was scary
[03:21] <Amaranth> deep?
[03:21] <jdong> must be at least 50 processes in parallel
[03:21] <Amaranth> ah
[03:21] <pwnguin> tall
[03:21] <Amaranth> yeah, my CPUs freak out for a bit :P
[03:21] <Amaranth> brb, seeing if i destroyed anything
[03:21] <jdong> :)
[03:21] <pwnguin> now for an after picture
[03:22] <pwnguin> one hopes that green line shows considerable improvement
[03:22] <jdong> indeed
[03:22] <jdong> my green line is still rpetty abysmal
[03:22] <jdong> pwnguin: http://jdong.mit.edu/~jdong/macbook/bootchart-upstart.png
[03:22] <jdong> actuallly
[03:22] <jdong> http://jdong.mit.edu/~jdong/macbook/hardy-upstart-defragged.png
[03:22] <jdong> that's after the "defrag"
[03:23] <pwnguin> nice
[03:23] <jdong> pwnguin: yeah, at this point unless readahead or modprobe (udevtrigger) drastically improves, I think I'm at my peak boot speed
[03:24] <pwnguin> like someone else said, you could potentially group files together based on access patterns
[03:24] <pwnguin> ie, config files at boot grouped togethre
[03:24] <jdong> pwnguin: I generated a dependency diagram of my upstart boot at http://jdong.mit.edu/~jdong/macbook/depchart/upstart-dep.png
[03:24] <jdong> pwnguin: it's nicely massively parallel
[03:24] <Amaranth> whee
[03:25] <Amaranth> jdong: http://www.realistanew.com/random/hardy-20080317-4.png
[03:25] <Amaranth> peak went down but throughput seems to have gone up overall
[03:26] <Amaranth> only cut a second off though
[03:26] <pwnguin> readahead's much shorter that time
[03:26] <jdong> shows some improvement
[03:26] <pwnguin> theres a wierd exe though
[03:26] <Amaranth> i think that's upstart
[03:26] <jdong> how the hell is your readhead so short?
[03:26]  * jdong cries
[03:26] <pwnguin> because it's faster?
[03:26] <jdong> Amaranth: move up udev
[03:26]  * lamont wonders why it is that,  when I have "shadow: compat db" in nsswitch.conf, the gnome screen lock needs read access to /var/lib/misc/shadow.db before I can unlock the screen.
[03:27] <Amaranth> jdong: i don't have the sad excuse of a harddrive that apple puts in their laptops
[03:27] <pwnguin> heh
[03:27] <pwnguin> 12? ouch
[03:27] <jdong> Amaranth: /etc/event.d/udev, "start on starting readahead"
[03:27] <Amaranth> jdong: this HD was the fastest you could get for a laptop until a year after i bought it
[03:27] <jdong> Amaranth: try that for size. That should reduce the readahead bottleneck
[03:27] <jdong> (hopefully no races :D)
[03:28] <pwnguin> i should probably rerun profile
[03:28] <jdong> Amaranth: same for lrm-manager
[03:28] <Amaranth> yeah but i still can't go fast until i fix initramfs
[03:28]  * jdong looks at dep chart
[03:28] <Amaranth> what could make it slow?
[03:29] <pwnguin> reiserfs?
[03:29] <Amaranth> /etc/event.d/udev is already "start on starting readahead"
[03:29] <Amaranth> you told me that one before
[03:29] <Amaranth> pwnguin: no, ext3
[03:29] <jdong> Amaranth: oh, do the same for lrm-manager
[03:29] <Amaranth> alright, done
[03:30] <Amaranth> i wish this was a pdf so i could search through it
[03:30] <jdong> Amaranth: are you booting verbosely?
[03:30] <Amaranth> yeah
[03:30] <Amaranth> don't do that?
[03:30] <jdong> Amaranth: you should be able to see where it hangs up in initramfs then
[03:30] <jdong> right?
[03:30] <jdong> I'm guessing probably the probing of some sort of hardware, either USB or disk
[03:31] <jdong> initramfs runs a udevtrigger IIRC, which could be costly
[03:31] <Amaranth> it sits at "Starting up" then "Loading", then it seems to start for a little bit at setting up cfq
[03:31] <jdong> you might win by removing all USB stuff from initramfs
[03:31] <Amaranth> but it does sit for a second or two on "Starting up"
[03:31] <jdong> Amaranth: ok, I *DARE* you to....
[03:32] <jdong> Amaranth: http://jdong.mit.edu/~jdong/macbook/event.d.new.tar.gz
[03:32] <Amaranth> my keyboard and touchpad are ps/2 so... :P
[03:32] <Amaranth> what is that?
[03:32] <jdong> Amaranth: diff that against your event.d
[03:32] <jdong> Amaranth: it's my updated event.d after shaving 2 secs off my boot
[03:32] <jdong> Amaranth: it sets the IO scheduler to AIO and disabled pdflush during boot
[03:32] <jdong> Amaranth: btw, you're responsible in rc.local to revert those two changes :D
[03:33] <jdong> see event.d/pdflush
[03:33] <jdong> Amaranth: that should further reduce seek and write pressure during boot
[03:33] <jdong> and HERE, we cross into the realm of voodoo boot magic
[03:33] <Amaranth> you changed udevtrigger?
[03:33] <jdong> Amaranth: I did?
[03:34] <jdong> Amaranth: my memory kind of fails
[03:34] <Amaranth> -start on stopped lrm-manager
[03:34] <Amaranth> +start on started udev
[03:34] <jdong> Amaranth: oh, I wanted to trigger a bit earler as I didn't have any LRM devices
[03:34] <Amaranth> ah
[03:34] <Amaranth> but i do :P
[03:34] <jdong> Amaranth: yeah so you shouldn't do that :D
[03:35] <Amaranth> gimme your rc.local :P
[03:36] <jdong> Amaranth: my rc.local is slightly scary :)
[03:36] <Amaranth> is your change in load-modules the same thing?
[03:36] <Amaranth> +start on stopped udevtrigger
[03:36] <ScottK2> jdong: As long as you don't say worksforme and then insist everyone should do it this way.
[03:37] <jdong> Amaranth: right, I think load-modules should start on udev instead.
[03:38] <jdong> Amaranth: http://jdong.mit.edu/~jdong/macbook/rc.local
[03:38] <jdong> ScottK2: lol, this is hack central, anyone who dares try this is at minimum insane :D
[03:38] <jdong> Amaranth: useful stuff are the last line and the 2nd line
[03:38] <jdong> Amaranth: the rest of hacks to save about 2W of power on my system
[03:39] <jdong> and note the modprobe usbhid for when I couldn't get udev started correctly :D
[03:39]  * jdong puts on his hack shame hat
[03:39] <Amaranth> jdong: should it really be initctl emit shutdown in rc6?
[03:39] <emgent> heya
[03:41] <jdong> Amaranth: well, shutdown and reboot meant the same thing when I just wanted Pulse to save mixer levels.
[03:41] <Amaranth> hehe
[03:41] <jdong> :)
[03:41] <Amaranth> i don't ever reboot anyway
[03:42] <jdong> Amaranth: good, I'm not sure rebooting works all that gently
[03:42] <jdong> Amaranth: it's kind of the extreme end of the "faster shutdown" spec from 2 releases ago
[03:42] <jdong> :D
[03:42] <Amaranth> yeah, i see lots of devmapper errors on shutdown
[03:42] <Amaranth> because stuff goes away in the wrong order
[03:42] <Amaranth> but screw it, it's shutdown :P
[03:43] <jdong> :)
[03:43] <jdong> good enough, tear things down, sync, umount, good neough
[03:43] <jdong> Amaranth: since you're conveniently syndicated on planet, you should probably do a quick blogpost once you're done :D
[03:44] <Amaranth> uh oh
[03:44] <Amaranth> i knew there was a catch
[03:44] <jdong> :)
[03:45] <Amaranth> brb, i hope
[03:45] <pwnguin> heh
[03:45] <jdong> he didn't have it nearly as bad as me
[03:45] <pwnguin> adventurous to do that one one machine
[03:45] <jdong> let me  tell you, screwing up udev mount order on a USB keyboard system is NOT fun
[03:46] <pwnguin> haha
[03:46] <pwnguin> you mean apple notebooks dont have a serial debugger port?
[03:46] <jdong> gasp :)
[03:46] <jdong> pwnguin: I'm lucky to have an optical drive and a mouse button.
[03:47] <pwnguin> but just the one button, no more
[03:47] <jdong> pwnguin: watch multitouch replace that 6 months from now.
[03:48] <pwnguin> ?
[03:48] <jdong> pwnguin: I doubt trackpads will have buttons at apple's rate
[03:48] <jdong> everyhting's gonna be encapsulated in touch and drag type gestures
[03:48] <pwnguin> like a multitouch screen, or the trackpad just gets even smarter
[03:48] <jdong> the trackpad getting smarter
[03:50] <travis> jdong: ok, something went bad
[03:50] <jdong> eep
[03:50] <Amaranth> I got a desktop but I've got three sleeps running and got no bootchart
[03:51] <jdong> hmm
[03:51] <jdong> Amaranth: is rc.local hanging?
[03:51] <jdong> Amaranth: initctl status, look for anything in starting phase
[03:52] <Amaranth> jdong: initctl: missing job name
[03:52] <jdong> Amaranth: sorry, list.
[03:53] <Amaranth> grep says nothing
[03:53] <Amaranth> oh, wait
[03:54] <Amaranth> i've got a bunch of stuff in 'waiting' but i think some of it is supposed to be there and some of it isn't
[03:54] <Amaranth> oh, no, that's all for on stop
[03:54] <jdong> Amaranth: what's bootchart's status?
[03:54] <pwnguin> man. i have this five second "resume" crap
[03:55] <Amaranth> jdong: waiting :/
[03:56] <jdong> Amaranth: follow up the chain: http://jdong.mit.edu/~jdong/macbook/depchart/upstart-dep.png
[03:56] <jdong> Amaranth: usplash->gdm->acpi_support->laptop_mode->rc_local->stop_bootchart
[03:56] <Amaranth> jdong: http://rafb.net/p/ZelU1G27.html
[03:57] <Amaranth> it's waiting for gdm? that doesn't make sense
[03:57] <jdong> Amaranth: no stopped is the normal state for that
[03:57] <Amaranth> i should probably go through here and remove all the things i don't have init scripts for
[03:57] <jdong> Amaranth: those are all "script / end script" relationships, which enter stopped/waiting once they finish
[03:57] <Amaranth> oh, i did have a typo in my rc.local
[03:58] <Amaranth> cfg instead of cfq
[03:58] <Amaranth> :P
[03:58] <jdong> Amaranth: well that'll do it :)
[03:58] <jdong> Amaranth: yay set -e.
[03:58] <Amaranth> so those jobs should be started to not need ok
[03:58] <jdong> Amaranth: agreed
[03:58] <Amaranth> err, i hope that made sense :P
[03:58] <jdong> Amaranth: try "start on starting shutdown" for size :)
[03:59] <Amaranth> stop-bootchart should not depend on rc.local working
[03:59] <jdong> stratus: right, it should just depend on rc.local stopping
[03:59] <jdong> err, wrong person entirely
[03:59] <Amaranth> wait, waht?
[03:59] <Amaranth> start on starting shutdown? for what?
[03:59] <jdong> Amaranth: for an oxymoronic statement
[03:59] <jdong> Amaranth: it was quite awkward writing rules that sounded like that :)
[03:59] <jdong> Amaranth: that's where upstart's UI falls
[04:00] <jdong> (and yeah blame it on PEBKAC)
[04:00] <Amaranth> alright brb again
[04:00] <jdong> good luck
[04:02] <pwnguin> hmm
[04:05] <Amaranth> jdong: man you're killing me here: http://www.reaistanew.com/random/hardy-20080317-5.png
[04:05] <pwnguin> http://people.cis.ksu.edu/~jld5445/after-readahead-tar.png
[04:05] <pwnguin> Amaranth: ye olde 404
[04:05] <Amaranth> http://www.realistanew.com/random/hardy-20080317-5.png
[04:05] <jdong> Amaranth: hmm
[04:06] <Amaranth> pwnguin: you did the upstart thing too?
[04:06] <pwnguin> Amaranth: no
[04:06] <Amaranth> wow
[04:06] <Amaranth> oh you start almost nothing
[04:06] <jdong> Amaranth: so perhaps we should concentrate all the modprobing together instead, and start readahead after that's done
[04:06] <pwnguin> i start X and gdm
[04:07] <jdong> Amaranth: it seems like hwenever we do modprobing everyhing else grinds to a halt
[04:07] <Amaranth> jdong: sounds good to me
[04:07] <pwnguin> Amaranth: what am i not starting/
[04:07] <Amaranth> although i should really take some time to figure out where my initramfs bug is
[04:07] <jdong> Amaranth: so I guess move udev*, lrm load-modules to "start on stopped mount-kernel-filesystems ok"
[04:08] <Amaranth> pwnguin: i dunno, i seem to start about twice as many things
[04:08] <jdong> Amaranth: and move readahead to the last thing in the module loading chain.
[04:08] <pwnguin> Amaranth: keep in mind that bootcharts elide short lived processes
[04:08] <pwnguin> maybe my computer's fast enough that things don't show up in the charts ;)
[04:08] <jdong> pwnguin: Amaranth seems to have a larger bluetooth stack, ntfs mount, and firestarter/iptables
[04:08] <pwnguin> those are all valid points ;)
[04:08] <pwnguin> ntfs in particular would be painful
[04:09] <Amaranth> yeah, firestarter is for connection sharing, ntfs can go away
[04:09] <Amaranth> and bluetooth? wtf
[04:09] <jdong> pwnguin: your blotchy stuff towards the end of bootup looks like could be optimized.
[04:09] <pwnguin> jdong: im sure it can be
[04:09] <jdong> pwnguin: it would seem like resources are heavily underutilized the last quarter of your boot
[04:10] <jdong> pwnguin: so.. either join the dark side or creatively use ampersands :)
[04:10] <pwnguin> jdong: i agree, but im more curious about the first quarter where nothing's going on and a process called resume is sitting there
[04:10] <jdong> pwnguin: yeah that's annoying too
[04:12]  * pwnguin should drop bluetooth
[04:14] <Amaranth> don't suppose you guys have any idea where to poke to figure out initramfs troubles
[04:14] <wasabi> /usr/share/initramfs-tools
[04:14] <wasabi> or -utils
[04:14] <wasabi> i forget. ;)
[04:14] <pwnguin> i recall someone saying there was an interactive boot version of initramfs stuff
[04:14] <Amaranth> i think thinking more "what would likely cause the stall" :P
[04:15] <jdong> pwnguin: break={init, top, premount, mount, postmount, bottom, magic, other voodoo}
[04:16] <wasabi> Ahh. Yes. All that stuff.
[04:16] <wasabi> When I'm debugging the initramfs I braek premount usually.
[04:16] <wasabi> Then just step through it manually.
[04:16] <wasabi> Which is a bit hard with such a crappy shell.
[04:24] <pwnguin> hmm. well, just touching rc to use CONCURRENCY=shell seems to have broken hal
[04:24] <pwnguin> which is a shame, since it went about 5 seconds faster
[04:24] <jdong> pwnguin: haha see ya still need those dependency things :)
[04:25] <pwnguin> it was quick enough to undo :P
[04:26] <pwnguin> hmm
[04:26] <pwnguin> "/scripts/local-premount/resume: /scripts/local/premount/resume: 57: log_begin_msg: not found"
[04:27] <jdong> pwnguin: I wonder if we can put some sort of mini-upstart in initramfs :)
[04:27] <pwnguin> just use make ;)
[04:28] <pwnguin> im not even sure what that message means, or which file to look for line 57 on =(
[04:29] <wasabi> jdong: it's been mentioned a few times that I remember
[04:29] <wasabi> I'd like to see upstart used for desktop session stuff.
[04:29] <jdong> pwnguin: /usr/share/initramfs-tools/scripts
[04:30] <jdong> wasabi: well right now I'm wasting over 5s in bootup because udevtrigger is called once in initramfs and once in mount
[04:30] <jdong> wasabi: I'd like to see some of that duplication removed, as initramfs is nearly 1/3 of my bootup right now
[04:31] <wasabi> udevtrigger is async though, and does not reload modules... which is the slow part. No?
[04:32] <jdong> wasabi: seems like things that close to touching the kernel aren't async
[04:32] <jdong> wasabi: and right, it doesn't reload modules but it does waste time that could be spent loading the rest of the modules :)
[04:32] <jdong> wasabi: maybe instead I need a really big initramfs with all my modules :)
[04:32] <wasabi> Hehe.
[04:33] <wasabi> Does it really waste time? I find that odd.
[04:33] <wasabi> I'd think it'd be nearly instant to finish it's work after it's already run once.
[04:34] <Amaranth> jdong: http://www.realistanew.com/random/hardy-20080317-9.png
[04:34] <Amaranth> we seem to be doing the same amount of work in the same amount of time just in a different order :P
[04:34] <jdong> Amaranth: I guess that's a good sign of hitting a bottleneck :)
[04:35] <Amaranth> hehe, yeah
[04:35] <jdong> Amaranth: that bootchart would be SO sexy if the first 11s were stripped.
[04:35] <Amaranth> so to get faster i just need to trim down services and fix initramfs
[04:36] <Amaranth> i wonder if bootchart is the one breaking my initramfs :P
[04:36] <jdong> Amaranth: lol that would be funny
[04:36] <jdong> Amaranth: have you tried what happens if you zap out readahead altogether? Does your disk seek fast enough ? :)
[04:36] <Amaranth> because i don't remember whether or not it paused this long before before starting usplash
[04:36] <Amaranth> hmm
[04:36] <jdong> Amaranth: easiest way to test would be to move aside /etc/readahead/boot and replace it with a blank.
[04:37] <Amaranth> or comment out the exec
[04:37] <jdong> Amaranth: replace it with exec true :)
[04:44] <Amaranth> jdong: yes, my HD can seek fast enough :P
[04:44] <jdong> really?
[04:45] <Amaranth> jdong: 36 seconds
[04:45] <jdong> Amaranth: slight loss though not too bad
[04:45] <Amaranth> jdong: same location, -10 instead of -9
[04:46] <Amaranth> i dunno how else to optimize this
[04:46] <Amaranth> what i should do is start from a clean install
[04:46] <Amaranth> i've got a lot of cruft i'm too lazy to clear out
[04:49] <Amaranth> eh, i never boot anyway
[04:49]  * Amaranth leaves if for now
[04:49] <StevenK> Never, you say?
[04:50] <Amaranth> since 2.6.24 suspend is _really_ reliable
[04:50]  * StevenK removes the battery from Amaranth's laptop and then cuts the power
[04:50] <Amaranth> i only reboot when i get a kernel upgrade or something
[05:09] <nxvl> is there any way to tell a .desktop file to use gkdu or kdesu depending on if it is KDE or GNOME?
[05:10] <RAOF> You could ship 2 desktop files, one with OnlyShowInGnome, the other OnlyShowInKDE?
[05:20] <pwnguin> well i found the problem with resume
[05:20] <pwnguin> # Default delay is 5s
[05:22] <pwnguin> which leads into an interesting question: what's the point of uuids if they change between releases?
[05:27] <nxvl> RAOF: and where should i add OnlyShowInGnome? on the desktop file?
[05:31] <RAOF> nxvl: It's actually a desktop file field, IIRC.  OnlyShowIn=GNOME
[05:37] <Amaranth> I would to NotShowIn=KDE; for the gksudo one and OnlyShowIn=KDE; for the kdesu one
[05:37] <Amaranth> because you're more likely to have gksudo (XFCE)
[05:37] <Amaranth> s/to/do/
[05:46] <pwnguin> hmm
[05:46] <pwnguin> if [ "x${resume}" = "x" ]; then
[05:47] <pwnguin> i presume this means to check if resume has something to it
[05:48] <nxvl> RAOF: thanx
[05:49] <dholbach> good morning
[05:50] <ion_> good night
[05:59] <pwnguin> interesting
[06:00] <pwnguin> Google announced the summer of code organizations
[06:00] <RAOF> pwnguin: Do expound, dear chap.
[06:00] <pwnguin> i dont see ubuntu on the list
[06:00] <pwnguin> http://code.google.com/soc/2008/
[06:09] <Amaranth> interesting
[06:09] <pwnguin> see?
[06:10] <Amaranth> but yay, Xorg got accepted this year
[06:10] <pwnguin> well that's good
[06:10] <dmb> no ubuntu SOC?
[06:10] <pwnguin> i asked a few weeks ago
[06:11] <pwnguin> and someone pointed to brainstorm and that was about the end of the conversation
[06:11] <pwnguin> well, at least debian's on there
[06:12] <dmb> ubuntu is normally in it
[06:12] <dmb> thats weird
[06:12]  * pwnguin wonders if ubuntu even applied
[06:12] <dmb> theres no good debian ideas
[06:13] <pwnguin> debgraph looks good
[06:13] <pwnguin> i thought i saw something like that done already though
[06:13] <Amaranth> so much for telling people to propose compiz ideas to ubuntu for soc :P
[06:14] <pwnguin> from now on i think i'll just put questions on the council agendas
[06:15] <superm1_> asac, most certainly didn't come up nicely from suspend
[06:15] <superm1_> but i dont know that's regressible for me.  i had video related suspend problems previously (that appear to be better now).  I haven't suspended for months due to them
[06:17] <RAOF> Man.  I want to do the liboiljit GSoC project :)
[06:17] <Amaranth> liboiljit?
[06:18] <RAOF> http://gstreamer.freedesktop.org/wiki/LiboilJIT
[06:18] <RAOF> Turn liboil into a small JIT'd runtime.
[06:19] <RAOF> Compiler writing is always fun.
[06:19] <RAOF> * for certain values of "fun".
[07:00] <Mirv> bryce: hi. do you have that i18n-fixed screen resolution tool coming up? after beta I assume?
[07:02] <bryce> Mirv, indeed I have the package posted and am just waiting on seb128 to upload it:  http://people.ubuntu.com/~bryce/Testing/XrandrGui/gnome-control-center_2.21.92-0ubuntu3_source.changes
[07:04]  * Fujitsu is impressed to have found a page that crashes both webkit- and xulrunner-based browsers.
[07:11] <Mirv> bryce: hmm, it seems seb128 has already uploaded version 2.22.0-0ubuntu1 without those patches on Mar 11th
[07:14] <bryce> Mirv, oh yeah; I updated it today:  http://people.ubuntu.com/~bryce/Uploads/gnome-control-center_2.22.0-0ubuntu2_source.changes
[07:17] <pitti> Good morning
[07:18] <TheMuso> Morning pitti.
[07:19]  * bryce waves to pitti
[07:19] <ion_> Good night
[07:20] <Mirv> bryce: ah, ok. great!
[07:38] <warp10> Good morning
[07:47] <superm1> bryce, gah, displayconfig-gtk's showing up in the "Other" menu all alone now.  I thought the goal of that last upload was to disable it in the menu system :)
[07:47] <bryce> yeah it was.  I removed all the categories for it
[07:48] <bryce> does the desktop file need some other modification to get rid of it?
[07:49] <superm1> i'm not sure..
[07:49] <superm1> maybe just dont install the desktop file?
[07:49] <superm1> or at least install it somewhere that it doesnt get populated for now until you want it to show up
[07:50]  * TheMuso checks the desktop file variable needed to hide an item.
[07:50] <TheMuso> Hang on a sec.
[07:51] <TheMuso> NoDisplay=true should do the trick.
[07:51] <TheMuso> Thats used in the gnome-orca package, as well as others to hide the desktop icon.
[07:51] <bryce> TheMuso: aha, thanks
[07:51] <TheMuso> bryce: Welcome.
[07:52] <superm1> much more appropriate solution :)
[08:08] <soren> cjwatson: I just took a peek in http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/etc/crontab to figure out when I could expect the new JeOS image to be built, but it's not listed. I could have sworn that it used to be?
[08:12] <mdke> slangasek: was there a problem with the ubuntu-docs upload? I don't see it in Launchpad
[08:14] <kagou> hey seb128, i will redo login time test with the daily-live iso, to see impact of prefetch etc.
[08:14] <seb128> hello kagou, thanks
[08:38] <kagou> there are no daily(live) isos today ?
[08:44] <asac> superm1: maybe try ;)
[08:49] <slangasek> mdke: no problem, I just had an X crash and lost track of the fact that I hadn't pushed it through the approved queue yet
[09:11] <pitti> erk
[09:11] <pitti> seb128: 'sudo users-admin', does that work for you? I can't do anything in it
[09:11] <pitti> seb128: I just noticed that on the current live system all PK stuff is broken due to that (also gnome-mount -vbd /dev/sda1, etc.)
[09:12] <seb128> pitti: admin tools use policykit and need a bus session to connect, etc, don't run those using sudo?
[09:13] <pitti> seb128: longer context: on the live CD we change PolicyKit.conf to grant all access to 'ubuntu'
[09:13] <pitti> to avoid asking for an empty password
[09:13] <seb128> looks good
[09:13] <seb128> still you should not need sudo?
[09:14] <pitti> I konw
[09:14] <pitti> seb128: it just more or less emulates the situation
[09:14] <seb128> hum
[09:14] <seb128> I'm not sure I understand
[09:14] <seb128> you should be able to run users-admin
[09:14] <pitti> ah, nevermind
[09:14] <seb128> and click on unlock
[09:14] <pitti> I get a parse error
[09:14] <seb128> and it should work
[09:14] <pitti> seb128: right, but ideally root wouldn't need to unlock
[09:14] <pitti> it should just work for root
[09:15] <seb128> the sudo case it different, you run with an user with has no dbus session available
[09:15] <pitti> and indeed root doesn't need to unlock
[09:15] <pitti> hm, why does it need a session dbus?
[09:15] <seb128> not sure, does policykit use it for authentification?
[09:15] <pitti> nevermind, I found the bug in casper
[09:16] <seb128> ok
[09:16] <pitti> there's an extra blank line at the start of PolicyKit.conf
[09:16] <seb128> still the question on why it needs a bus stands
[09:16] <pitti> thus XML parsing error
[09:16] <pitti> seb128: right, I wonder about that, too
[09:16] <pitti> slangasek: I need to upload a new casper to unbreak PolicyKit in the live system, sorry
[09:17] <pitti> cjwatson: that'll include your committed-but-not-uploaded fix for bug 202699, I guess that's ok?
[09:17] <ubotu> Launchpad bug 202699 in casper "[Hardy] casper-snapshot wrongly labels squashfs as cpio.gz" [Undecided,Fix committed] https://launchpad.net/bugs/202699
[09:17] <seb128> pitti: the session bus is used for policykit apparently
[09:17] <seb128> pitti:
[09:17] <seb128> 	message = dbus_message_new_method_call ("org.gnome.PolicyKit",
[09:17] <seb128> 						"/org/gnome/PolicyKit/Manager",
[09:17] <seb128> 						"org.gnome.PolicyKit.Manager",
[09:17] <seb128> 						"ShowDialog");
[09:17] <cjwatson> pitti: should be, your call of course
[09:17] <seb128> 	dbus_connection_send_with_reply (priv->session_bus, message, &pending_call, -1);
[09:17] <seb128> pitti: ^
[09:18] <cjwatson> casper-snapshot is only ever run by hand so I can't see how it'd break anything
[09:18] <pitti> right, was just going to say
[09:18] <pitti> seb128: interesting
[09:18] <slangasek> pitti: ok, eta on that upload?
[09:18] <pitti> slangasek: give me 5 minutes, so that I can test it
[09:19] <slangasek> ok
[09:19] <RAOF> asac: Why is nspluginwrapper (Universe) maintained in a bzr repository only core-devs can push to?
[09:20] <asac> RAOF: i guess thats a bug :)
[09:20] <RAOF> asac: I've finally picked that merge-from-debian up.  Shall I push bzr to somewhere ubuntu-dev can write to? :)
[09:20] <pitti> slangasek: uploaded
[09:21] <asac> RAOF: yes, please push to ubuntu-dev and change control accordingly
[09:21] <slangasek> pitti: cheers
[09:21] <asac> RAOF: can you try to resurrect the .debian branch as well?
[09:21] <asac> e.g. so we can merge using bzr means?
[09:21] <Fujitsu> asac: Or you could just delete the -core from the owner.
[09:21] <asac> i can?
[09:21] <asac> let me see
[09:21] <RAOF> asac: Not right now, but that'd be nice.
[09:22]  * pitti does some test installs
[09:23] <Fujitsu> asac: `Change registrant' if you hadn't found it already.
[09:25] <pitti> slangasek: I take it it gets a little late for new langpacks?
[09:25] <asac> Fujitsu: is that field really used for permission control?
[09:26] <asac> Fujitsu: ok i changed the author to just ubuntu-dev, but i don't think that this helps
[09:27] <asac> i think the easiest way is just to push that to -dev and let me know so i can abandon the other branch
[09:27] <stgraber> moin
[09:28] <asac> Fujitsu: oh. you were i right i guess
[09:28] <asac> no all is fine
[09:28] <asac> thanks
[09:28] <Fujitsu> asac: Yes, that controls it.
[09:28] <slangasek> pitti: yes :/
[09:28] <Fujitsu> that's good
[09:28] <Fujitsu> arrrgh, x on the other hand is not good.
[09:28] <asac> doing the same for the upstream and debian branch
[09:29] <pitti> slangasek: ok, then I better upload fresh ones after the beta; the current CDs don't have a lot of langpacks anyway, right?
[09:29] <asac> but someone should push at least a bzr revision with the adapted Vcs header
[09:30] <slangasek> pitti: yeah, currently we're down to around 5 languages due to lack of space
[09:30] <pitti> :(
[09:30]  * cjwatson blinks at the last comment in bug 199048
[09:30] <ubotu> Launchpad bug 199048 in partman-partitioning "swapoff before swapon" [Medium,In progress] https://launchpad.net/bugs/199048
[09:30] <cjwatson> took me a moment to get the reference :-)
[09:31]  * pwnguin guesses the karate kid
[09:31]  * pitti wonders whether he'll ever get used to those new progress bar
[09:31] <cjwatson> yes
[09:33] <pitti> slangasek: casper is in unapproved, and my ssh is currently broken again; can I ask you to accept it?
[09:33] <slangasek> yes, looking
[09:34] <pitti> slangasek: thanks
[09:36] <james_w> Does the installer ever ask anything about the root account? (I don't know whether they used the alternate or not).
[09:37] <cjwatson> james_w: the alternate/server installer will ask if and only if you also use expert mode
[09:37] <james_w> cjwatson: thanks, I'll ask if they used the alternate then.
[09:37] <cjwatson> (otherwise known as "I am an installer developer and want lots of noise" mode)
[09:39] <slangasek> pitti, cjwatson: this casper change to rename the images according to the image type isn't going to break builds, is it?
[09:39] <cjwatson> casper-snapshot is only run by hand
[09:39] <slangasek> ok
[09:40] <cjwatson> nothing in the CD build process uses it
[09:42] <stgraber> slangasek: Is 20080318 good for early testing or is there another set of ISO to come in the next hours ? (gfxboot fix ?)
[09:46] <slangasek> stgraber: there'll be another set for the gfxboot fix
[09:46] <slangasek> the Ubuntu ones should be ok for early testing despite being superseded later; the Kubuntu and Xubuntu ones are known not to boot
[09:47] <slangasek> (well, presumed not to boot, given the gfxboot breakage)
[09:47] <pwnguin> i've been redirected to here with a questions, so I'll pose it: what on earth is the initramfs-tools resume script doing waiting five seconds for?
[09:48] <stgraber> oh, and daily-live is oversized on i386
[09:49] <slangasek> stgraber: ack; that was one of the things I was checking for with this run, ohwell...
[09:52] <slangasek> pwnguin: according to the source, it only sleeps that long if that's how long it takes your resume device to become available
[09:56] <pwnguin> slangasek: the trouble im having is that i didn't hibernate
[09:56] <pwnguin> and it's still going off
[09:57] <soren> cjwatson: Your tasksel fix for JeOS worked perfectly. Thanks very much!
[09:59] <slangasek> pwnguin: well, yes, that seems like a plausible bug to me; if it's waiting for a disk that will never exist, for instance
[09:59] <pwnguin> slangasek: hmm
[10:00] <slangasek> pwnguin: the script I'm looking at *implies* that this only happens if you've booted with a 'resume=' option
[10:00] <pwnguin> slangasek: thats the thing i cant figure out -- where is resume getting set from?
[10:01] <pwnguin> kernel          /boot/vmlinuz-2.6.24-12-generic root=UUID=4cd91330-31b1-4a9b-aa9f-0f8b0c729420 ro quiet splash
[10:03] <slangasek> pwnguin: afraid I don't know the answer to that
[10:03] <TheMuso> pwnguin: It gets set from initramfs configs in /etc/mkinitramfs
[10:03] <TheMuso> err /etc/initramfs-tools
[10:04] <TheMuso> pwnguin: /etc/initramfs-tools/conf.d/resume to be exact.
[10:04] <soren> pwnguin: /etc/initramfs-tools/conf.d/resume
[10:04] <cjwatson> soren: woo. I left the JeOS project bug task open, so I guess you can close that bit now
[10:04] <pwnguin> i swear
[10:04] <pwnguin> UUIDS are worthless
[10:04] <soren> pwnguin: Eh?
[10:05] <pwnguin> looks like that's a uuid to a device that doesn't exist
[10:05] <pwnguin> never did
[10:05] <pwnguin> or at least, doesnt anymore
[10:06] <pwnguin> the other day, i discovered that swap was using the wrong uuid, so i had no swap
[10:06] <pwnguin> err, fstab was using the wrong uuid for swap. dont know why
[10:07] <cjwatson> which is because something remade the swap partition; unfortunately we don't know what
[10:08] <pwnguin> at any rate, thanks for the help here
[10:10] <pwnguin> cjwatson: ive always wondered where uuids come from -- are they in the partition table?
[10:13] <cjwatson> pwnguin: they're in the filesystem itself
[10:38] <pitti> mdke: hm, https://translations.edge.launchpad.net/ubuntu-doc/ is obviously not where I should go to fix a translation bug in ubuntu-docs?
[10:47] <pitti> mdke: ah, found it
[10:55] <pitti> ah, my test installs look reasonably well
[11:04] <mvo> ogra_: have you seen bug #201230 yourself at some point? I was not able to reproduce it
[11:04] <ubotu> Launchpad bug 201230 in kdeedu "kverbos "breakes" the gui-installer" [Undecided,Incomplete] https://launchpad.net/bugs/201230
[12:07] <Riddell> mvo: could we add ksplash-engine-moodin to dist upgrade tools list of packages to remove?
[12:27] <mvo> Riddell: sure, added
[12:29] <Riddell> thanks
[12:29] <Riddell> mvo: oh, its probably too late but app-install-data is preferring KDE 4 .desktop files over KDE 3 ones
[12:30] <Riddell> mvo: ideally it would list both, but I guess that would be notable changes
[12:30] <mvo> Riddell: meh, sorry for that. do they have the same name?
[12:30] <Riddell> mvo: yes, in most cases
[12:32] <mvo> Riddell: ok, I have a look later
[12:32] <Riddell> mvo: if its complex to fix, don't worry about it.  but if there's an easy way to have both kde 3 and 4 files in there that would be nice
[12:34] <mvo> ok
[12:38] <Riddell> stgraber: kubuntu 20080318.1 are up and needing testing
[12:40] <stgraber> Riddell: ok, thanks
[12:40] <kagou> seb128, WoW 17.4sec for gnome login (as fast as Mandriva)
[12:40] <seb128> kagou: excellent ;-)
[12:40] <seb128> kagou: how much did we have before the changes?
[12:40] <kagou> seb128, yes :) login time as increased too but just for 2 sec
[12:41] <kagou> before : 39 + 29
[12:41] <kagou> now : 41 + 17
[12:41] <kagou> knowing that compiz is not activated, and no more deskbar+tracker
[12:42] <ion_> What was changed?
[12:43] <kagou> seb128, i should retest last mandriva to compare with hardy
[12:47] <seb128> ion_: update-manager and jockey delay their work, gdm does preloading and we stopped using deskbar and tracker
[12:48] <seb128> 29 seconds to 17 is not too bad ;-)
[12:49] <ion_> Nice
[12:55] <kagou> mvo, seems that apturl don't work with firefox beta4 ?!
[12:55] <kagou> someone can confirm this bug ?!
[12:55] <seb128> pitti, slangasek: would it be ok to uploade a yelp with updated translation now for beta?
[12:56] <seb128> kagou: no need to use extra ponctuation ;-) How do you I test apturl?
[12:56] <pitti> seb128: an upload is certainly ok, but I'm not sure whether we'll get it on the CD; IIRC Riddell will/did trigger the last/next CD rebuild
[12:56] <kagou> open apt://inkscape
[12:56] <bardyr> does not work
[12:57] <kagou> under firefox it would prompt to install inkscape
[12:57] <bardyr> kagou, it prompts to select a handler for apt://
[12:57] <kagou> ok i open a bug. thanks
[12:58] <bardyr> but it works if you select to open it with /usr/bin/apturl
[13:01] <kagou> bardyr, please could you confirm Bug #203538
[13:01] <ubotu> Launchpad bug 203538 in apturl "Don't work with Firefox3 beta4" [Medium,New] https://launchpad.net/bugs/203538
[13:01] <bardyr> yea 2sec
[13:05] <bardyr> kagou, confirmed
[13:12] <soren> ogra_cmpc: Do you have a moment to fill in a few blanks for me?
[13:12] <soren> ogra_cmpc: I'm working on iscsi support in initramfs.
[13:12] <ogra_cmpc> sure, if i can :)
[13:13] <soren> ogra_cmpc: I want to try to configure iscsi if I have network setup.
[13:13] <ogra_cmpc> check for a default route ?
[13:13] <soren> ogra_cmpc: Is there a simple way to determine whether I have that?
[13:13] <soren> Hm..
[13:13] <soren> Yes, I suppose that's a reasonable heuristic
[13:14] <soren> Do you have an ipconfig command line handy to do that?
[13:14] <ogra_cmpc> NETWORKUP=$(route -n |grep -c ^<IP_ADDRESS>)
[13:14] <ogra_cmpc> if its 1 youre online
[13:14]  * soren hugs ogra_cmpc
[13:15] <soren> Awesome! Just what I needed. Thanks very much.
[13:15] <ogra_cmpc> :)
[13:16] <kagou> thanks bardyr
[13:31] <Riddell> Ubuntu Desktop beta candidate CDs up for testing( 20080318.1)
[13:33] <cgregan> Hello all, I wanted to introduce myself here on the community pages. I just joined Canonical as Ubuntu Mobile QA Engineer. If there is anything I can do to improve the relationship between community devel and test, please let me know. Thanks
[13:34]  * _MMA_ waves hi to cgregan.
[13:34] <pedro_> hey cgregan welcome
[13:35] <stgraber> hi cgregan
[13:35] <cgregan> Thanks....glad to be a aboard
[13:43] <Hobbsee> hey cgregan
[13:44] <soren> ogra_cmpc: How does the nic driver land in the initramfs? Do you manually add it to /etc/initramfs-tools/modules?
[13:45] <ogra_cmpc> depends what kind of initramfs you use
[13:45] <ogra_cmpc> if your config uses MODULES=most it should be in
[13:46] <ogra_cmpc> same for MODULES=netboot
[13:46] <soren> Oh, and that's the default, I suppose.
[13:46] <soren> most, that is. Not netboot :)
[13:48] <jpatrick> welcome cgregan :)
[13:48] <mvo> asac: could you tell me about bug #203538 ? does firefox need a different location than /usr/share/firefox/defaults/pref in beta4?
[13:48] <ubotu> Launchpad bug 203538 in apturl "Don't work with Firefox3 beta4" [Medium,Confirmed] https://launchpad.net/bugs/203538
[13:52] <asac> mvo: yes. we have now /usr/lib/firefox-3.0b4/defaults/syspref -> /etc/firefox-3.0/pref
[13:52] <asac> is it ok to put it in /etc/..
[13:52] <asac> ?
[13:52] <mvo> asac: aha, ok. I will change the package then
[13:53] <asac> mvo: please test before upload. but it should work
[13:55] <kagou> Riddell, ok let's go testing :)
[13:56] <asac> mvo: you can keep the old place and depend on '| firefox-2' if you want
[14:09] <Riddell> ogra_cmpc: you're wanting CDs for beta presumably?
[14:10] <ogra_cmpc> sure
[14:18] <pitti> mvo: do you have some time in the next days for verifying bug 198129?
[14:18] <ubotu> Launchpad bug 198129 in tzdata "Chile delay in 3 weeks the daylight time transition" [Undecided,Fix committed] https://launchpad.net/bugs/198129
[14:18] <pitti> mvo: (right, deja vu, we had to update tzdata again for that)
[14:19] <mvo> pitti: aha, sure. how urgent is it? if super urgent, I squeeze it in today
[14:20] <pitti> mvo: no, it's not; by mid next week would be good, though
[14:20] <pitti> mvo: the bug will occur on March 29
[14:20] <pitti> (tzdata is probably the only package which allows us to predict future bugs that precisely :-P)
[14:21] <mvo> heh :) we should have more of those
[14:21] <pwnguin> hmm. its too bad CONCURRENCY=shell doesn't work, because it brings my boot down below 20 seconds =(
[14:22] <pitti> TheMuso, cjwatson: as "happy" broadcom wifi users, do you have an idea about bug 197819?
[14:22] <ubotu> Launchpad bug 197819 in b43-fwcutter "[Hardy]b43-fwcutter install script fails to fetch firmware in first run" [Undecided,Confirmed] https://launchpad.net/bugs/197819
[14:25] <Riddell> soren: ready for ubuntu server beta candidates to be built?
[14:32] <Keybuk> *blink*
[14:32] <Keybuk> my gpg public key just vanished off my box
[14:33] <pitti> Keybuk: secret key still intact?
[14:33] <Keybuk> yes
[14:33] <jdong> meh you never need your own public key anyway ;-)
[14:42] <soren> Riddell: Yes, I think now is a good time.
[14:42] <superm1> asac, well yeah no video issues this time around, but still the wifi doesn't come up nicely on 0.6.6
[14:42] <soren> Riddell: Er.. Hang on.
[14:42] <soren> Riddell: When is the beta due out?
[14:42] <Riddell> soren: thursday
[14:43] <soren> Riddell: Ah, I somehow convinced myself it'd be today. In that case, I have more stuff I'd like to sneak in, so not today.
[14:43] <soren> Riddell: Is that cool? I'm not familiar with the processes involved.
[14:43] <Riddell> soren: hmm, we're in quite deep freeze already
[14:43] <zdzichuBG> will hardy get mobile broadband support like in fedora? maybe via updates/backports?
[14:44] <Riddell> soren: it should be important changes only by now
[14:44] <soren> Riddell: Oh, it's important alright.
[14:44] <soren> Riddell: I'll run it by slangasek, when he shows up. Cool?
[14:44] <asac> superm1: so even not with the patch?
[14:44] <asac> superm1: is there an improvement at all?
[14:45] <Riddell> soren: fine with me but he won't be awake for another 4 or so hours
[14:45] <superm1> asac, the improvements with the patch get me connected
[14:45] <superm1> but not after suspend
[14:45] <asac> ok
[14:45] <asac> please attach that information to your bug and post a new syslog
[14:45] <seb128> asac: do we need to have this network manager editor in the menus?
[14:45] <asac> superm1: ^^
[14:45] <superm1> asac, alright
[14:45] <soren> Riddell: I'm not the one who's in a hurry :)
[14:46] <asac> seb128: well ... except that there i bugs i don't see why we wouldn't want that
[14:46] <asac> seb128: ?
[14:46] <asac> i see that its in multiple places. we can probably fix that
[14:47] <seb128> asac: it doesn't really seem to be useful, isn't the context menu entry on the applet enough?
[14:49] <pitti> ryanakca: since you fixed some jockey-gtk bugs (thanks!), are you interested in some more cosmetical things?
[14:50] <pitti> ryanakca: (in particular bug 197777)
[14:50] <ubotu> Launchpad bug 197777 in jockey "Need space in error message" [Undecided,Confirmed] https://launchpad.net/bugs/197777
[14:50] <asac> seb128: its bug 270663
[14:50] <asac> oops
[14:50] <asac> seb128: bug 201127
[14:51] <asac> feel free to milestone if you want it removed
[14:51] <seb128> asac: thanks
[14:51] <seb128> asac: well, rather discuss it, I got comments about the preferences menu not fitting on a 1024x768 screen in the default installation
[14:52] <seb128> asac: so I'm trying to see what we can move away from there
[14:52] <asac> seb128: i have such a screen on x61 ... it fits here
[14:53] <seb128> asac: ok, somebody told me that it was touching the bottom panel, I didn't verify
[14:54] <seb128> asac: maybe it depends of the dpi you are using ;-)
[14:54] <asac> hmm ... i have both panels on auto-hide
[14:54] <asac> didn#t change dpi
[14:54] <_MMA_> seb128: Maybe remove "Main Menu" (Alacarte) as right-click on the menu itself launches it also?
[14:55] <asac> seb128: without autohide its stiill a bit above the bottom panel
[14:55] <seb128> ok
[14:55] <asac> seb128: this is a clean hardy install i did about 3 weeks ago
[14:55] <seb128> _MMA_: I think people argued it was not discovrable enough
[14:56] <seb128> asac: anyway I don't want to argue about a few pixels, we have lot of items there and I was just looking if we could simply it a bit
[14:56] <seb128> maybe we should use applications, system tools again
[14:56] <asac> sure. if you milestone it on behalf of the desktop team, i will go on and remove it
[14:56] <seb128> looks like something is installing the hardware testing application there already
[14:56] <seb128> asac: ok, thanks
[14:56] <asac> but for final plesae :)
[14:57] <asac> beta is too close. if i upload anything i will include this fix of course
[14:57] <seb128> right, not for beta
[14:57] <seb128> 8.04 is good
[14:57] <seb128> milestoned
[14:58] <_MMA_> seb128: Ok. One could argue that windows users are doing the same thing now to edit the Start menu. They seem to find it fine. *If* they are our target audience. I don't mind either way. :P
[14:58] <seb128> ;-)
[15:00] <mathiaz> Riddell: what do you think about bug 197476 ?
[15:00] <ubotu> Launchpad bug 197476 in mysql-dfsg-5.0 "akonadi  does not work with the apparmor rules introduced for /usr/sbin/mysqld on hardy." [Low,Incomplete] https://launchpad.net/bugs/197476
[15:01] <mathiaz> Riddell: "akonadi starts a user-specific mysqld to store it's PIM data.
[15:01] <Riddell> mathiaz: I think it should be fixed :)
[15:01] <Riddell> on the apparmour side
[15:02] <mathiaz> Riddell: It's unusual that a program would start its own mysqld process
[15:02] <mathiaz> Riddell: why can't akonadi use the system databases ?
[15:02] <\sh> relmgr: please approve claws-mail and claws-mail-extra-plugins to hit the buildds/archives
[15:02] <wasabi> I don't find that really unusual. Completely removes any consideration of security.
[15:03] <wasabi> To an extend I'd prefer more apps worked like that.
[15:03] <wasabi> extent
[15:03] <soren> Could someone please give back virt-manager?
[15:04] <ogra_cmpc> wasabi, but then its really cleverer to use a serverless db like sqlite
[15:04] <mathiaz> wasabi: I agree with ogra_cmpc
[15:04] <mathiaz> wasabi: sqlite has been designed for that
[15:05] <Riddell> mathiaz: let me try and ask someone
[15:05] <wasabi> So?
[15:06] <wasabi> Not everybody wants to use sqlite. ;)
[15:06] <mathiaz> Riddell: I think the concerns raised by the reporter are valid
[15:06] <mathiaz> Riddell: I question the use of mysql as a storage backend to fix their concerns.
[15:06] <Hobbsee> soren: given back
[15:06] <soren> Hobbsee: Thanks very much.
[15:06] <Hobbsee> yw
[15:09] <Riddell> mathiaz: sqlite doesn't work well enough
[15:11] <mathiaz> Riddell: could you be more precise about what doesn't work well enough ?
[15:11] <mathiaz> Riddell: or point me to a channel where these things are discussed ?
[15:11] <Riddell> mathiaz: not really, I'm not an akaonadi developer
[15:11] <Riddell> mathiaz: #kontact
[15:11] <wasabi> I think arguing about what technology a given app uses is not helpful.
[15:12] <wasabi> They chose to use MySQL. They might have had more experience with it.
[15:12] <wasabi> Or a hundred different factors.
[15:12] <mathiaz> wasabi: well - I'd like to know why they're using it.
[15:12] <ogra_cmpc> wasabi, if it doesnt fit our security model its at least friendly t0o suggest something that works right
[15:13] <wasabi> I agree... I just wonder what's different from using MySQL per-user vs SqlLite per-user.
[15:13] <ogra_cmpc> or to find out why they cant use something that fits in
[15:13] <SupaFly> hey how can i participate in ubuntu's development?
[15:13] <ogra_cmpc> wasabi, one starts a server daemon, the other doesnt ?
[15:13] <wasabi> But he said it was per-user, no?
[15:13] <wasabi> Starts a per-user instance of MySQL.
[15:14] <wasabi> Maybe I misread.
[15:14] <ogra_cmpc> yes thats what he said
[15:14] <wasabi> Oh. Does it listen on external ports or something?
[15:15] <Riddell> ogra_cmpc: you have 20080318.2 CDs to test
[15:15] <ogra_cmpc> no idea ... but if the policy is to lock down servers to a certain extent for security reasons and such a corner case comes around that doesnt work through that, do you drop the whole policy or do you ask the dev if he cant use something thats supported ?
[15:16] <ogra_cmpc> Riddell, gracias
[15:17] <pitti> ryanakca: nevermind, I fixed it myself
[15:17] <pitti> yay mastering pyqt ;)
[15:18] <emgent> heya pitti :)
[15:18] <pitti> Riddell: for bug 193985: is there only myWindowObject.exec_() or a static method like gtk.main() in PyQt?
[15:18] <ubotu> Launchpad bug 193985 in jockey "jockey-kde crashed with AttributeError in ui_main_loop()" [Undecided,Confirmed] https://launchpad.net/bugs/193985
[15:19] <cjwatson> Keybuk: is MINKVER="2.6.17" in /usr/share/initramfs-tools/hooks/udev still accurate?
[15:19] <Keybuk> cjwatson: I think so
[15:19] <pitti> Riddell: basically I need to process events for the tray icon until it gets clicked; would KApplication.kApplication().exec_loop() work for that?
[15:19] <Keybuk> untested, obviously
[15:19] <Keybuk> but there's no reason it shouldn't work
[15:20] <Keybuk> we include both sets of rules for the old usb devices, etc.
[15:20] <Riddell> pitti: not for a qt4 app, you need   QApplication.exec_()  I think
[15:21] <pitti> Riddell: oh, great; I'll try that
[15:24] <cjwatson> Keybuk: ok, just following up on bug 190281
[15:24] <ubotu> Launchpad bug 190281 in linux "Segfault in initrd with 2.6.24-7 on intel x86_64" [Medium,In progress] https://launchpad.net/bugs/190281
[15:24] <Keybuk> err?
[15:24] <seb128> pitti: do you have any idea of why the policykit-gnome translations are not in the current language packs?
[15:25] <cjwatson> oh, it's the other way round
[15:25] <cjwatson> hardy kernel on feisty
[15:25] <seb128> pitti: danilo said that the template has been imported in rosetta some weeks ago and the translations should be available
[15:26] <pitti> seb128: oh, I see; I was just going to check for a .pot build
[15:26] <seb128> pitti: I did check that, and talked with him, the template has been imported correctly
[15:26] <pitti> argh argh ssh
[15:27] <pitti> seb128: do you see them in rookery:/srv/language-packs.../hardy/sources-base/ somewhere?
[15:27] <seb128> pitti: yes
[15:28] <seb128> pitti: for some locales but not the ones I'm interested in ;-)
[15:29] <pitti> seb128: upstream package only has Danish translations, nothing else
[15:30] <seb128> pitti: right, but it has been translated in french on rosetta for example
[15:30] <Mirv> seb128: and they're translated in Rosetta you're looking at? at least Finnish has made its way to language packs.
[15:30] <seb128> pitti: though that seems to be recent, so maybe in next update round
[15:30] <pitti> seb128: right; the previous export came too late and was broken, so I'll do another update on Friday, after beta
[15:30] <seb128> pitti: ok, seems to not be a bug
[15:30] <seb128> pitti: ok, thanks
[15:30]  * pitti hugs seb128
[15:31]  * seb128 hugs pitti
[15:39] <Riddell> evand: ready for gobuntu CDs for beta candidates?
[15:47] <evand> Riddell: hrm, allow me to give them a quick look over.  Pulling downnow.
[15:51] <\sh> cjwatson: bug #107326 do we have any possibility to fix this in time for hardy?
[15:51] <ubotu> Launchpad bug 107326 in parted "non working gpt labels" [High,Confirmed] https://launchpad.net/bugs/107326
[15:52] <cjwatson> \sh: are you in a position to test the result?
[15:52] <cjwatson> it should be doable, and it's definitely on at least one "fix by hardy" list
[15:52] <\sh> cjwatson: hopefully next week yes...I'm getting back a machine with 7TB...
[15:52] <\sh> cjwatson: amd64 that is
[15:53] <cjwatson> I'll see if we can have a look after beta
[15:54] <\sh> cjwatson: if it's only a matter of replacing parted with a new version on the alternate cd..I can try over the weekend to tweak the alternate cd we have...
[15:56] <cjwatson> \sh: no, it's not just a matter of that
[15:56] <cjwatson> Actual Coding is involved.
[15:58] <\sh> cjwatson: you mean the sync problem on macs?
[15:58] <cjwatson> yes
[15:59] <cjwatson> curiously, http://developer.apple.com/technotes/tn2006/tn2166.html claims that Apple uses a protective MBR
[15:59] <cjwatson> whereas (we think) it's actually a legacy MBR for legacy BIOS compatibility
[16:01] <\sh> when I reported the bug regarding broken GPT lables, these days the problem was parted, not writing correctly the partition tables...because I never booted from partitions >2TB...but all partitions >2TB were not usable, because they had a msdos label and not GPT label
[16:01] <\sh> dapper worked correctly
[16:01] <\emgent> heya
[16:01] <cjwatson> \sh: thank you, I understand the problem
[16:02] <\sh> cjwatson: well, I'm confused now ... I'm trying to figure out what grub has to do with it (reading some comments)
[16:02] <cjwatson> \sh: not much these days
[16:03] <cjwatson> well, it impedes better solutions
[16:03] <cjwatson> I don't really want to explain it now, I'm trying to figure out other things
[16:03] <cjwatson> like whether there's actually a standard for Intel Mac >2TB disks
[16:06] <\sh> cjwatson: and I'll try to stop being confused with further readings
[16:07] <\sh> cjwatson: and if you need someone to test on amd64 hw, next week I'm able to do it
[16:08] <maswan> you need some testing with >2TB partitions? anything I can help out with?
[16:08] <maswan> I can find a server or two with a decent ammount of storage
[16:09] <\sh> maswan: always the very same people, I think ;)
[16:09] <maswan> We usually don't partition those filesystems though
[16:09] <cjwatson> 2TB is the (relatively) easy bit; the problem is that what you have to do to cope with >2TB and what you have to do with Intel Macs conflict, and I'm trying to work out what will happen if somebody puts a >2TB disk in an Intel Mac and tries to dual-boot OS X and Ubuntu on it
[16:09] <maswan> Ah, no macs around here
[16:09] <cjwatson> which will very likely be the case in the lifetime of Hardy
[16:10] <\sh> maswan: well, I had to, and it looks like I have to do this in the very near future again :(
[16:11] <pitti> Riddell: ok, I think I got the jockey-kde notifications fixed; the kde test suite is still a mess, but at least the app itself works now
[16:11] <\sh> maswan: and again with *censored* areca raid
[16:12] <cjwatson> (note that I am not saying that the above should impede the >2TB case in general from being fixed in hardy, but it seems like something we need to consider)
[16:12] <maswan> \sh: oh, they are still bad? hm. hope ours won't be too horrible, we'll get a few delivered soon.
[16:14] <\sh> maswan: well, the ones we had during combots time ;) which were crashing because of broken firmware...and old kernel drivers...the native ones in newer linux kernels are much better, but firmware was again very bad these days...let's see what the new firmware gives me
[16:14] <maswan> \sh: ok, hope we'll have less issues. anyway, delivery seems to be delayed, so we might run hardy on them from the start. :)
[16:16] <\sh> maswan: when you get hands on your controllers, just send me the model number :) so I can think of replacing those old ones :)
[16:16] <maswan> \sh: sure, if they work. now off.
[16:21] <cjwatson> I think it may be that >2TB disks on Intel Macs simply have to be an error :-/
[16:23]  * ogra_cmpc wonders why his rsync is lagging so heavily
[16:24] <ogra_cmpc> does anyone else have slow rsyncs or is it just me ?
[16:25] <mvo> siretart: if you don't mind, I would like to upload http://paste.ubuntu.com/5811/
[16:29] <\sh> cjwatson: >2TB disks in intel mac laptops, for sure...;)
[16:32] <mvo> bryce: when you uploaded displayconfig-gtk, did you put your changes in bzr?
[16:39] <Riddell> ogra_cmpc: other people are grumping too
[16:40] <Riddell> evand: shall I build gobuntu?
[16:40] <evand> Riddell: it seems the seeds need to be updated
[16:40] <evand> the install is failing on the missing hwdb-client-gnome issue from a few days back
[16:40] <ogra_cmpc> my first one was flying ... the second one sits at 4k with 28h to go since 30min already
[16:40] <evand> working on that now
[16:41] <Riddell> evand: ok, let me know if you need uploads approved
[16:41] <evand> Riddell: will do, thanks
[16:43] <pitti> bryce, tjaalton: hm, can you please tell me if http://launchpadlibrarian.net/12724433/xorg.conf is actually valid? I particularly mean the "  screen 0 "aticonfig-Screen[0]" 0 0
[16:43] <pitti> " line in ServerLayout
[17:02] <ogra_cmpc> did anyone try alternate yet ? i'm getting a ton of perl errors here
[17:02] <ogra_cmpc> hmm, but seems that only spams the log
[17:07] <evand> Riddell: gobuntu-meta 1.11 whenever you have a free moment.
[17:17] <mvo> pitti: I updated the information in bug #174128  - if you are happy with the debdiff I will upload it
[17:17] <ubotu> Launchpad bug 174128 in dhcp3 "asks debconf question on dapper->hardy upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/174128
[17:17] <jdstrand> hi lamont
[17:18] <jdstrand> lamont: just sent git patch for bug #203528
[17:18] <Riddell> evand: accepted
[17:18] <ubotu> Launchpad bug 203528 in bind9 "apparmor profile should be in complain mode on certain upgrades" [Undecided,In progress] https://launchpad.net/bugs/203528
[17:19] <jdstrand> lamont: this follows the (updated) ApparmorProfileMigration
[17:19] <evand> Riddell: thanks
[17:20] <lamont> jdstrand: ok.  for beta, or post-beta?
[17:20] <jdstrand> lamont: basically, it just makes sure pre-apparmor bind9 upgrades are in complain mode, as well as forcing complain mode the apparmor-profiles is unchanged
[17:20] <jdstrand> lamont: that was why I wanted to talk to you
[17:20] <jdstrand> lamont: I *doubt* there will be many dapper-hardy upgrades for beta, but there will be gutsy-hardy
[17:21] <lamont> true
[17:21] <jdstrand> lamont: therefore, it probably should go in before
[17:21] <lamont> ok.  I'll upload and request the sync tonight-ish
[17:21] <jdstrand> lamont: cool, thanks!
[17:22]  * jdstrand now goes to update mysql and openldap in the same way
[17:22] <pitti> mvo: looking
[17:22] <lamont> jdstrand: if you have a patch for the host-doesn't-print-nameserver list bug too, that'd be wonderful. :-)
[17:22] <lamont> jdstrand: bug 191530
[17:22] <ubotu> Launchpad bug 191530 in bind9 ""host" cannot see sites in .org" [Medium,Triaged] https://launchpad.net/bugs/191530
[17:22] <pitti> mvo: ah, so it was never really a conffile prompt?
[17:23] <jdstrand> the one we talked about on saturday? sorry, no
[17:23] <pitti> mvo: does the default DTRT?
[17:23]  * lamont yawns at bug 203476 - does anything actually _use_ that inet_ntoa>?
[17:23] <ubotu> Launchpad bug 203476 in bind9 "[libbind9] [CVE-2008-0122] off-by-one error in the inet_network function" [Undecided,New] https://launchpad.net/bugs/203476
[17:24] <jdstrand> lamont: rh said they don't, in their bug report
[17:24] <mvo> pitti: frankly, I don't know if the initial thing was "needs-start" or "files-moved-around", I could be mixing the initial report up
[17:24] <mvo> pitti: the default should be fine, its just a debconf note
[17:24] <lamont> jdstrand: yeah, and debian has the bug sitting there stale for some time as well.
[17:24] <jdstrand> I saw that, went 'oh my', and then went, ohh-- backburner
[17:25] <pitti> mvo: ah, great
[17:25] <lamont> yeah
[17:26] <lamont> jdstrand: every now and then, as I read the bug page, I go "HUH!?!?!" and then go "yeah. right."
[17:26] <jdstrand> haha
[17:26] <mvo> pitti: ok, if all is cool with the diff I will upload (at this stage of the freeze I like to always double check :)
[17:26] <pitti> mvo: sure
[17:29] <lamont> jdstrand: maybe I'll backport that patch from 9.4.3 (or the report) just to shut that up
[17:30] <jdstrand> oh the fedora one? I haven't looked at it
[17:31] <lamont> the CVE-2008-0122 thing
[17:31] <ubotu> Off-by-one error in the inet_network function in libbind in ISC BIND 9.4.2 and earlier, as used in libc in FreeBSD 6.2 through 7.0-PRERELEASE, allows context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via crafted input that triggers memory corruption. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0122)
[17:32] <lamont> ah u\botu got smart about CVE too
[17:32] <jdstrand> yeah, it certianly seems harmless enough
[17:32] <jdstrand> certainly
[17:32]  * lamont isnt' on the good mailing list anymore
[17:32] <jdstrand> https://bugzilla.redhat.com/attachment.cgi?id=292030
[17:33] <jdstrand> not private
[17:33] <jdstrand> https://bugzilla.redhat.com/show_bug.cgi?id=429149 is the bug
[17:33] <ubotu> Red Hat bug 429149 in vulnerability "CVE-2008-0122 libbind off-by-one buffer overflow" [Low,Verified: ]
[17:33] <infinity> lamont: Aww, quitting HP got you knocked off vendor-sec?
[17:35] <lamont> infinity: well, it was through hp, so yeah
[17:36] <ryanakca> pitti: sorry, I'm at school :)
[18:43] <pitti> ScottK: I don't quite understand why we keep the remaining delta for cyrus-sasl2-heimdal
[18:43] <pitti> ScottK: libdb-dev is by and large equal to libdb4.6-dev?
[18:47] <slangasek> soren: what are you running by me? :)
[18:48] <milli> lamont: you get my patch against 9.4.2?
[18:58] <pitti> ryanakca: NP, I fixed them all :)
[18:59] <emgent> asac: ping
[18:59] <emgent> there is a critical problem in nm-applet on hardy
[19:00] <emgent> seems dont work with new Intel PRO/Wireless 3945ABG
[19:01] <emgent> with iwconfig working fine in hardy, but GUI dont work
[19:01] <asac> emgent: hidden network?
[19:01] <emgent> asac: no
[19:02] <asac> everyone i know that has 3945 could connect
[19:02] <ogra_cmpc> asac, can we get rid of the NM console messages on shutdown for final ?
[19:02] <ogra_cmpc> they look scary
[19:02] <emgent> it's an open A.P.
[19:02] <asac> ogra_cmpc: i never shutdown my system. how do they look like?
[19:02] <asac> emgent: hmm
[19:03] <asac> emgent: can you try WPA?
[19:03] <ogra_cmpc> asac, console messages, debug stuff
[19:03] <emgent> tried first, same problem
[19:03] <emgent> i think that it's a problem with device name
[19:03] <ogra_cmpc> it only blinks up shortly before usplash kicks in with the shutdown screen
[19:03] <emgent> new ipw driver generated "wlan0_rename" device
[19:03] <ogra_cmpc> but on first glance it looks like an error msg
[19:04] <asac> emgent: i have several reports that it works with WPA
[19:04] <asac> emgent: how far does nm get?
[19:04] <emgent> asac: false i used WPA TKIP
[19:04] <asac> do you see one green light at least?
[19:05] <emgent> nope led too dont work.
[19:05] <asac> please try to connect now and post your complete syslog somewhere
[19:05] <emgent> but ipw driver working fine
[19:06] <emgent> asac: it's impossible, i can only connect with iwconfig, but not in GUI
[19:06] <asac> emgent: most likely it doesn't work fine; otherwise nm would work :)
[19:06] <emgent> i cant see the possibility to connect with it :P
[19:06] <asac> ah
[19:06] <asac> post /etc/network/interfaces then
[19:07] <emgent> http://nopaste/p/aJWKMiQGH
[19:07] <Keybuk> I had that the other day
[19:07] <Keybuk> it was because something had installed the -386 kernel for me
[19:07] <emgent> seems see eth0 and lo
[19:07] <Keybuk> and since -386 < -generic, that's what grub picked
[19:07] <Keybuk> emgent: what does uname -a say?
[19:07] <slangasek> bryce: can you help me understand the gnome-control-center upload?  199549 is about settings not taking effect on an i965, doesn't that support xrandr 1.2?  and bug #198951 isn't assigned to gnome-control-center at all; are these fixes that are important for beta?
[19:07] <ubotu> Launchpad bug 198951 in gnome-desktop "gnome-display-properties crashed with SIGSEGV in screen_info_new() - i855, fglrx, radeonhd" [High,Fix released] https://launchpad.net/bugs/198951
[19:08] <emgent> 2.6.24-12-generic
[19:08] <emgent> on i686
[19:08] <Keybuk> ok, not the same problem then
[19:08] <emgent> only GUI dont work
[19:09] <Keybuk> what does iwconfig say?
[19:09] <emgent> driver working fine to me
[19:09] <Keybuk> (when run without arguments)
[19:09] <bryce> slangasek: they could wait until after beta, I think the gnome-settings-daemon fixes may cover us sufficiently.  the gnome-control-center changes just make the new xrandr gui more useful
[19:09] <slangasek> bryce: ok, I'll sit on it, thanks
[19:09] <Keybuk> emgent: driver is clearly not working fine, or the GUI would work
[19:09] <emgent> Keybuk: http://nopaste/p/aI3ckLUNw
[19:10] <Keybuk> ok
[19:10] <emgent> i'm connected to wifi no, but only with iwconfig.
[19:10] <Keybuk> emgent: sudo mv /etc/udev/rules.d/70-persistent-net.rules /root
[19:10] <Keybuk> then reboot
[19:11] <emgent> k
[19:11] <emgent> just a moment.
[19:11] <lamont> Keybuk: /root... is that your version of a persistent /tmp ? :-)
[19:11] <Keybuk> lamont: exactly
[19:11] <emgent> heheh :)
[19:13] <asac_> emgent: sorry reconnect. did you answer what Keybuk asked you?
[19:13] <emgent> yes
[19:13] <Keybuk> he did, just waiting for him to reboot
[19:13] <asac_> so why does -386 break NM?
[19:13] <emgent> now working fine..
[19:14] <emgent> udev rules..
[19:14] <Keybuk> asac_: it doesn't have the iwl driver in it if you don't install the modules package :)
[19:14] <Keybuk> asac_: I only got the kernel by some upgrade bug
[19:14] <asac_> strange
[19:14] <asac_> but it appears to have ipw3945
[19:14] <emgent> Keybuk: ok thanks
[19:14] <asac_> or is that independent?
[19:14] <Keybuk> asac_: isn't that in linux-ubuntu-modules ?
[19:15] <asac_> yes i think so
[19:15] <Keybuk> right
[19:15] <Keybuk> that's what I didn't get installed
[19:15] <asac_> but not 100% source
[19:15] <Keybuk> just linux-image
[19:15] <asac_> yeah, but emgent appeared to have at least some driver :)
[19:15] <asac_> thats why i wondered
[19:16] <Keybuk> I suspect he just had some transient problem
[19:16] <Keybuk> the reboot cured it
[19:16] <Keybuk> maybe caused or not caused by that udev rename bug
[19:16] <asac_> right. lets keep it that way :)
[19:22] <dneary>  Hi
[19:22] <dneary>  I've got a .dsc, .diff.gz and _orig.tgz from a Hardy package that I'd like to build on Gusty
[19:22] <dneary>  Anyone mind running me through generating a .deb from the package files?
[19:22] <dneary> I'm not exactly starting from scratch, and I've been having lots of trouble going in circles in the packaging guide
[19:23] <jdstrand> bryce: hi!
[19:23] <bryce> jdstrand: hey
[19:23] <Keybuk> dneary: dpkg-source -x DSCFILE ; cd DIRECTORY ; debuild
[19:23] <jdstrand> bryce: are you aware of any weird bugs with /tmp/.ICE-unix ?
[19:23] <jdstrand> access to it
[19:23] <Keybuk> (with build-essential, dpkg-dev, devscripts and fakeroot installed)
[19:23] <bryce> nope
[19:23] <jdstrand> hrmm
[19:26] <zul> mvo: is there a howto to do a LTS->LTS on the wiki somewhere?
[19:27] <jdstrand> bryce: I can't open terminals, vim hangs, and probably other things
[19:27] <jdstrand> bryce: strace xterm gives:
[19:27] <jdstrand> connect(4, {sa_family=AF_FILE, path="/tmp/.ICE-unix/9709"}, 21) = 0
[19:27] <jdstrand> fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
[19:27] <jdstrand> write(4, "\0\1\0\0\0\0\0\0", 8)         = 8
[19:27] <jdstrand> read(4,
[19:27] <jdstrand> then hang forever
[19:27] <jdstrand> bryce: I really have no idea what could be causing that-- ever seen anything like it?
[19:28] <bryce> jdstrand: no I haven't seen bugs with errors in /tmp/.ICE-unix.
[19:28]  * jdstrand scratches his head
[19:29] <bryce> jdstrand: I would guess to look first at what changes have happened to your system recently...  we've not done many significant X uploads lately, so my first guess would be something non-X related, but who knows.
[19:29]  * jdstrand nods
[19:29] <bryce> jdstrand: also I'd doublecheck resources are okay, clear tmp, restart, etc. etc.
[19:29] <jdstrand> did all that
[19:30] <mvo> zul: yes: https://help.ubuntu.com/community/HardyUpgrades#head-e7f287c730b93116f89de7ea7e05efbe95fa6dd1
[19:30] <bryce> possibly the .ICE-unix is just a symptom of an underlying issue
[19:32] <dneary> Keybuk: Thanks
[19:32] <zul> mvo: thanks!
[19:32] <dneary> What package does debuild come in, I don't think it's installed?
[19:32] <mvo> devscripts
[19:32] <jdstrand> bryce: ok thanks
[19:32] <mvo> command-not-found should know that too
[19:34] <dneary> Do I also need fakeroot?
[19:34] <dneary> thanks mvo
[19:34] <jdstrand> bryce: was X built since the latest libc6 update?
[19:34] <mvo> cheers
[19:34] <dneary> So, yes, I need fakeroot :)
[19:35] <dneary> or I have to build as root
[19:35] <dneary> Woohoo! autoconf output!
[19:35] <bryce> jdstrand: last upload was Mar 13th it looks like
[19:35] <slangasek> jdstrand: fuser -vm /tmp/.ICE-unix/9709?
[19:36] <mvo> Riddell: could you please check http://paste.ubuntu.com/5819/ ? this is dapper->hardy
[19:37] <jdstrand> slangasek: http://paste.ubuntu-nl.org/60069/
[19:37] <Riddell> mvo: mm, right
[19:37] <dneary> Keybuk, mvo: Thanks a lot, that's just what I needed.
[19:37] <Riddell> mvo: any other koffice issues?
[19:37] <dneary> keysign didn't work because I'm missing the private key, it says
[19:37] <slangasek> jdstrand: er, oops - I meant fuser -v /tmp/.ICE-unix/9709
[19:37] <dneary> Anyone know where I can get that?
[19:38] <mvo> Riddell: not that I'm aware of
[19:38] <dneary> (OK, I was joking there...)
[19:38] <jdstrand> /tmp/.ICE-unix/9709: jamie      9709 F.... x-session-manag
[19:38] <jdstrand> slangasek: ^^
[19:38] <jdstrand> slangasek: it exists, perms are ok
[19:38] <jdstrand> I checked the obvious stuff...
[19:38] <slangasek> jdstrand: yes; the question is really, what's happening at the other end of the socket - x-session-manager may be broken on your system
[19:38] <slangasek> I don't know if it's sane to try stracing that process, but that would be my next step
[19:39] <mvo> Riddell: I can have a look later too if you are too busy
[19:39] <slangasek> (don't know if it's sane -> don't know if your session will survive ;)
[19:39] <jdstrand> slangasek: I'll wait til my non-screen'd build finishes
[19:39] <jdstrand> :)
[19:40] <Riddell> mvo: I can do it
[19:43] <jdstrand> slangasek: $ strace -p 9709
[19:43] <jdstrand> Process 9709 attached - interrupt to quit
[19:43] <jdstrand> restart_syscall(<... resuming interrupted call ...>
[19:43] <jdstrand> tried launching stuff, but nothing
[19:44] <jdstrand> oh, let me try -f
[19:44] <jdstrand> aha!
[19:44] <jdstrand> [pid  9790] read(24,
[19:44] <jdstrand> hangs there
[19:45] <jdstrand> I don't have a pid 9790...
[19:45] <slangasek> a thread, perhaps
[19:45] <slangasek> what is x-session-manager on this system? gnome-session?
[19:46] <slangasek> (x-session-manager is an alternative)
[19:46] <jdstrand> slangasek: yes
[19:46] <jdstrand> gnome-session
[19:46] <slangasek> ok
[19:46] <jdstrand> I do have /usr/bin/seahorse-agent --execute x-session-manager
[19:47] <slangasek> well, all I can say is that the two sides of the socket don't agree about whose turn it is to write :/
[19:48] <Keybuk> mathiaz: really don't add a status to udev
[19:48] <Keybuk> it'd encourage people to think that "start" and "stop" are useful commands
[19:48] <Keybuk> when they're not
[19:48] <Keybuk> if you run either on a real system, you'll break it
[19:48] <jdstrand> slangasek: somewhat disturbing, as I wasn't actively fiddling with anything.  just 'working'
[19:48] <mathiaz> Keybuk: sure - for udev it doesn't make sense
[19:49] <jdstrand> slangasek: this happened once before-- around the libc6 madness (but I never installed the bum version on the system)
[19:49]  * jdstrand scratches his head more
[19:49] <Keybuk> mathiaz: it also struck me that your list is pretty much the list of packages that are likely to be the first to go to upstart
[19:49] <Keybuk> so I'm not sure how much effort it's worth putting into a complex status() command
[19:50] <mathiaz> Keybuk: well - my target is really hardy
[19:50] <slangasek> Keybuk: well, I don't think the proposed command was terribly complex either?
[19:50] <Keybuk> right, but you're adding a potentially complex thing to debug and support
[19:50] <Keybuk> especially if you're doing more than just pidof()
[19:50] <mathiaz> Keybuk: as you mentionned, Intreprid would use upstart which is fine by me
[19:51] <mathiaz> Keybuk: Hardy is going to be around for some time and adding status action to init script is valuable IMO
[19:51] <mathiaz> Keybuk: I wouldn't defend this idea if hardy wasn't an LTS
[19:51] <Keybuk> ironically it's precisely because it's going to be around for a long time that it makes me nervous ;)
[19:52] <mathiaz> Keybuk: I see your point.
[19:53] <mathiaz> Keybuk: IMO it's worth the tradeoff - the code to add a status action is small and isolated.
[19:53] <cjwatson> is it good to have a status option for just a few init scripts in an LTS, thereby confusing people because it isn't there across the board?
[19:53] <mathiaz> Keybuk: I don't think it's worth adding a complex status action that does more than check if the pid is running.
[19:54] <cjwatson> I don't think you should do a half-baked job of it for an LTS, and I don't think we have time for you to do a full job
[19:54] <kirkland> cjwatson: it's already in a couple...  postgres, mysql
[19:54] <Keybuk> mathiaz: what pid?
[19:54] <mathiaz> cjwatson: well - I think it's better than nothing. Moreover it's already available in some of them.
[19:54] <cjwatson> kirkland: right, but a tiny minority
[19:54] <Keybuk> where do you get the pid ?
[19:55] <mathiaz> Keybuk: it depends on the init script.
[19:55] <slangasek> mathiaz: btw, your count is off, zul already took the liberty of adding this option to /etc/init.d/samba in his latest upload..
[19:55] <mathiaz> Keybuk: some init scripts define a PID file.
[19:55] <Keybuk> mathiaz: exactly, then we start to get into more complicated territory
[19:55] <Keybuk> and you'll have race conditions with when pid files appear/disappear
[19:55] <cjwatson> I don't have a problem with it being done gradually, but I don't think it's worth breaking feature freeze for
[19:55] <mathiaz> Keybuk: some don't.
[19:55] <mathiaz> slangasek: I know - but I think you mentionned that it reports only smbd.
[19:56] <mathiaz> slangasek: nmbd should also be checked.
[19:56] <slangasek> mathiaz: hrm, if you mean my bug reopen, that was about the if-up.d script that was added that doesn't do anything useful
[19:57] <mathiaz> cjwatson: well - some people would argue that it's a bug.
[19:57] <cjwatson> it's not
[19:57] <mathiaz> cjwatson: now I do think it's a new feature
[19:57]  * lamont mutters about cups/printers.conf having &*)*^*)_ timestamps in it from when cups was last started...
[19:57] <lamont> that's not something that belongs in /etc
[19:58] <mathiaz> cjwatson: but looking at the required changes and the testing to be done, it's worth the tradeoff.
[19:58] <kirkland> slangasek: i had already posted patches for samba, apache, and cron to Launchpad before we started thinking about how to solve this more generally, and posted the lsb- note to ubuntu-devel
[19:58] <mathiaz> cjwatson: as I said, it's really something that stands out when compared to other distros such as redhat or suse
[19:58] <Keybuk> I guess I also wonder ...
[19:59] <Keybuk> *why* would cron ever not be running?
[19:59] <cjwatson> it won't stand out if we do a partial job
[19:59] <lamont> what binary is it that implements the gnome session screen lock?
[19:59] <Keybuk> lamont: gnome-screensaver
[19:59] <lamont> danke
[19:59] <lamont> Keybuk: I just restarted cron on a dapper machine where it was not running... nfc why it decided to walk away from the table, though.
[19:59] <mathiaz> cjwatson: well - some scripts already have a status action. so it's already a partial job.
[20:00] <cjwatson> why is it worth pushing through feature freeze if it's not going to be complete?
[20:00] <kirkland> Keybuk: cron, udev -- exactly should always be running.  it would be nice to determine through a common mechanism if they're not, such that a monitor or ebox or a human or some such could take evasive action ;-)
[20:00] <Keybuk> kirkland: I'd prefer to fix things so that they're never not running
[20:00] <lamont> nagios?
[20:00] <lamont> Keybuk: that'd be wonderful
[20:00] <Keybuk> people actually building things on these status arguments makes me even more against them than before :)
[20:01] <Mithrandir> Keybuk: software has bugs, systems run out of memory and processes get killed, those kinds of things.
[20:01] <mathiaz> cjwatson: when we posted the patch to add status to samba init script to the Debian bts, we got a reply right away from users to include it.
[20:01] <Keybuk> Mithrandir: "respawn"
[20:01] <mathiaz> cjwatson: so I take the approach that users are really requesting it.
[20:01] <Mithrandir> Keybuk: people hack on those daemons too, in which case respawn often isn't what you want. :-P
[20:01] <mathiaz> cjwatson: and I don't think to do everything in one go - it won't be possible.
[20:01] <Keybuk> Mithrandir: "stop" :-)
[20:02] <mathiaz> cjwatson: in that particular case, we can really implement it step by step
[20:02] <kirkland> Keybuk: is it preferable to have people building things on `ps -ef | grep foo | awk bar` ?
[20:02] <mathiaz> cjwatson: package by package - it's not a big rollout. We just fixe annoyance in everyday life or sysadmin
[20:02] <Keybuk> kirkland: I'd prefer people waited for the proper fix
[20:03] <cjwatson> mathiaz: and potentially introduce little niggling bugs
[20:03] <Keybuk> mathiaz: that's fine during the usual development stages
[20:03] <Keybuk> but the whole point of freezes is that after them we concentrate on fixing bugs
[20:03] <Keybuk> rather than the continued deployment of features
[20:04] <lamont> Keybuk++
[20:04] <siretart> mvo: ugh darn. good catch! thanks!
[20:06]  * lamont grumbles at jdstrand for his commit messages
[20:06] <jdstrand> lamont: ?
[20:06] <lamont> fix for LP: #203528 (force complain for apparmor on certain upgrades Signed-off-by: Jamie Strandboge<EMAIL_ADDRESS>[20:07] <jdstrand> hey, I didn't touch changelog this time!
[20:07] <lamont> heh
[20:08] <mvo> siretart: thanks, no problem
[20:08] <lamont> so the change is that if the package is upgraded, then it's just complain-mode, and enforce-mode on clean installs?
[20:08] <jdstrand> lamont: not exactly
[20:09] <jdstrand> lamont: it is complain on pre-feisty package to enforcing package upgrade
[20:09] <jdstrand> lamont: it is also complain on pre-enforcing but apparmor aware OS
[20:10] <jdstrand> lamont: and the apparmor profile on the system prior to upgrade is in complain mode
[20:10] <jdstrand> this is documented in ApparmorProfileMigration
[20:11] <lamont> apparmor: force complain-mode for apparmor on certain upgrades
[20:11] <lamont> Set complain mode on upgrades from 1:9.3.4-2ubuntu2 and earlier,
[20:11] <lamont> rather than enforcing mode.  See also
[20:11] <lamont> https://wiki.ubuntu.com/ApparmorProfileMigration
[20:11] <lamont> Addresses-Ubuntu-Bug: 203528
[20:11] <lamont> Signed-off-by: Jamie Strandboge<EMAIL_ADDRESS>[20:11] <lamont> so like that?
[20:11] <jdstrand> lamont: well, that covers the first case, yes
[20:12] <lamont> see, if you wrote real commit logs, then I wouldn't have to rewrite  them and get it wrong... :-)
[20:12] <jdstrand> lamont: but not when upgrading from feisty or gutsy and apparmor-profiles is installed, or usr.sbin.named exists
[20:12] <lamont> the first line gets added as the changelog entry, with the relevant Addresses-{Ubuntu,Debian}-Bug: entries.
[20:13] <lamont> the Signed-off-by comes from git commit -s, if you're actually using git to do the formatting... :-)
[20:13] <lamont> s/formatting/committing/
[20:13] <lamont> and if there was a bzr UI that actually read _and_wrote_ git backends, then you could just use bzr
[20:13] <jdstrand> I used git
[20:14] <lamont> ok.  just throw the -s in and it'll add the signed-off-by line
[20:14] <jdstrand> that's what I did
[20:14] <lamont> then something smashed it all together.
[20:14] <lamont> because it was one line after the git-am
[20:14] <mvo> Riddell: could you please check http://paste.ubuntu.com/5821/  too ? this is dapper->hardy
[20:14] <jdstrand> but, I didn't want to be too wordy on the commit, as I quoted the bug, that talks about it and has the link.  *shrug*
[20:15] <jdstrand> I'll admit I forgot you used the commit message to get the changelog
[20:15] <lamont> the changelog creation script uses the first line, and the addresses-* lines.  the rest of the log is for posterity and can be as verbose as you want
[20:15] <jdstrand> ok
[20:15] <jdstrand> somewhat terse first line, the rest as descriptive as need be
[20:16] <cjwatson> heno: any word on bug 199129?
[20:16] <ubotu> Launchpad bug 199129 in ubiquity "Auto-resize install fails to mount drive" [Undecided,New] https://launchpad.net/bugs/199129
[20:16] <lamont> which also means that the first line wants a 'apparmor:' or such prefix to say what part of bind9 it's mucking with
[20:16] <cjwatson> heno: especially https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/199129/comments/8, if possible
[20:16] <ubotu> Launchpad bug 199129 in ubiquity "Auto-resize install fails to mount drive" [Undecided,New]
[20:16] <Riddell> mvo: ok, fixing
[20:18] <afflux> screen brightness does not change at all, even echoing to /sys/class/backlight/acpi_video0/brightness does not work. Is this a bug in the kernel?
[20:35]  * lamont slaps 191530 around, before going back to work for another 20 minutes
[20:41] <mvo> asac: could you please have a look at http://paste.ubuntu.com/5823/ ? (dapper->hardy)
[20:43] <heno_> cjwatson: looking
[20:43] <asac> mvo: looking
[20:44]  * heno tests it again
[20:45] <asac> mvo: does dapper have a network-manager-gnome package or is it "all-in-one"?
[20:46] <mvo> asac: dapper has a network-manager-gnome
[20:46] <asac> hmm
[20:48] <asac> mvo: ok that file appears to be shipped by nm inself now
[20:48] <asac> strange
[20:48] <amitk> afflux: yes it is known, fix will go in after the beta AFAICT
[20:49] <afflux> amitk: oh, okay, thanks
[20:51] <asac> mvo: would a versioned conflict ensure that the package getes removed _before_ unpacking is attempted?
[20:53] <mvo> asac: I haven't looks at it, but all you need is probably a "Replaces: n-m-gnome (<< version-where-the-file-moved-from-nm-to-nm-gnome)
[20:53] <mvo> asac: I can have a closer look if you want me
[20:54] <asac> mvo: yes its NN replaces or conflicts nm-gnome < XXX
[20:54] <asac> mvo: just not sure if conflicts would be enough
[20:54] <mvo> asac: ok, replaces should be fine
[20:54] <mvo> asac: a conflicts is the needed, a replaces really means "replaces files " and that is what happens
[20:54] <mathiaz> slangasek: I don't see any ubuntu-server iso in iso.qa.ubuntu.com. What's your testing plan for the server isos ?
[20:54] <mvo> asac: a conflicts is too strong if its just files moving around
[20:55] <slangasek> mathiaz: to click this 'add build(s)' button right now so they appear
[20:55] <asac> mvo: well, but we don't want version of NM-gnome considerably lower than NM :)
[20:55] <mathiaz> slangasek: ah ok. I was just to impatient then...
[20:55] <asac> mvo: thats why i thought that its more accurate to use conflicts.
[20:56] <asac> mvo: but i will go with whatever you prefer
[20:56] <slangasek> mathiaz: no, your comment was what reminded me that I hadn't clicked the button yet, thanks :)
[20:56] <mathiaz> slangasek: is this the first iso candidates ?
[20:56] <mvo> asac: heh :) I have no idea aobut the nm package relations - let me have a look first before I make more unqualified comments
[20:57] <mathiaz> slangasek: I remember heno sending an email about two phases testing or something like that. I wonder how would that apply to the ubunu-server iso
[20:57] <slangasek> mathiaz: we're in phase two at this point
[20:57] <slangasek> i.e., full validation of all images
[20:58] <mathiaz> slangasek: hum... was there something planned for phase one for ubuntu-server iso ?
[20:58] <asac> mvo: indee
[20:58] <asac> mvo: independent of that its questionable if that file belongs to NM at ll
[20:59] <slangasek> mathiaz: I don't know; if so I guess it was coordinated just among #ubuntu-testing
[21:00] <mvo> asac: yeah, that may actually be the right solution to move it to the -gnome package - the nm package does not have a glade or gtk dependency AFAICS
[21:03] <asac> mvo: i think the upstream source split led to that. no idea if they forgot to move it
[21:03] <asac> mvo: added to my todo
[21:06] <mvo> asac: looks like bug #123772 caused the move
[21:06] <ubotu> Launchpad bug 123772 in network-manager-openvpn "network-manager-applet no longer produces/provides usr/bin/nm-vpn-properties" [Low,Fix released] https://launchpad.net/bugs/123772
[21:06] <mvo> asac: that is what the old changelog says
[21:07] <mvo> asac: I think http://paste.ubuntu.com/5826/ should be enough
[21:08] <mvo> asac: if you are happy with it, I will commit and upload
[21:10] <asac> mvo: let me do that
[21:11] <asac> mvo: i need to add bugs to the other changelog entry thats already on the branch
[21:12] <amitk> top line from 'top':  5959 amit      20   0 1756m 1.4g 3012 S    0 70.9  12:52.29 compiz.real
[21:12] <mvo> asac: ok, thanks (even better :) - my changelog is a bit short, you may want to add somehting like "fix file overwrite problem on dapper->hardy upgrades" or something like this
[21:12]  * mvo hugs asac
[21:12] <mvo> amitk: is that with nvidia?
[21:12] <amitk> umm... is it normal for compiz to show 70.9% memory?
[21:13] <amitk> mvo: no... I have a poor old Intel graphic adapter
[21:14] <amitk> mvo: Intel Corporation 82G33/G31 Express Integrated Graphics Controller, FWIW
[21:18] <mvo> 1.4g is quite impressive
[21:19] <mvo> Amaranth: ---^ have you seen numbers like this already?
[21:19] <Keybuk> doesn't compiz directly map video memory on newer drivers?
[21:19] <Keybuk> amitk: can you nopaste /proc/5959/maps somewhere?
[21:19] <Amaranth> no idea
[21:21] <amitk> Keybuk: http://pastebin.ubuntu.com/5828/
[21:21] <mvo> amitk: how long is that system running (i.e. do you always suspend/resume it?)
[21:22]  * mvo wonders if exa may have anything to do with that
[21:22] <amitk> Keybuk: result of uptime ->  23:22:01 up  9:22,  6 users,  load average: 0.09, 0.17, 0.34
[21:23] <Keybuk> amitk: it's all heap
[21:23] <amitk> Keybuk: no, this machine doesn't suspend/resume, only reboots when there are upgrades to the kernel
[21:23] <Keybuk> so looks like a genuine leak
[21:23] <amitk> Keybuk: want me to file a bug?
[21:24] <Keybuk> amitk: --> mvo ;)
[21:26] <mvo> amitk: please
[21:26] <hunteke> where can I find more information about upstart?  will it be included in hardy?
[21:26] <mvo> amitk: anything special in the plugin settings (i.e. have you played with ccsm)?
[21:28] <amitk> mvo: I might have, though I could restore it to defaults. Any way to dump current CCSM settings?
[21:28] <Keybuk> hunteke: what would you like to know?
[21:29] <mvo> amitk: yeah, it has save current settings in the left-hand side under preferences
[21:29] <mvo> amitk: the more information you can gather, the better :)
[21:30] <hunteke> Keybuk: what's holding it back, how a noob can help/get involved with only about 3 hrs/wk to commit to it, why only a few devs care about it . . . I guess some of the esoteric things of "more about it"
[21:30] <soren> slangasek: I wanted to get your opinion on whether to build the beta now or to wait until I had finished my iscsi changes. It's moot now anyway, though, as I'm not done, and we should get the iso built sooner rather than later.
[21:31] <SwissPhoenix> Hi folks, I'm using hardy and getting a PANIC on my RAID Controller, files a bug ten day ago, but nobody noticed - just wondering if anybody cares to fix it to the release or if I have to do something more....
[21:31] <Keybuk> hunteke: to answer your last question first, I guess the primary reason only a few people care about it is that it's beneath the level most people tend to look
[21:31] <Keybuk> we have some kind of service management today, it just sucks
[21:31] <Keybuk> and only a few very strange people actually care that it sucks, and want to do something about it to fix it
[21:32] <Keybuk> and much of the energy of those kinds of people is already distracted by things at the same level like D-Bus, HAL, udev, etc.
[21:32] <hunteke> Keybuk: I know. :-(  although I'm looking at it from an end-user perspective of "I want linux to beat windows"
[21:32] <hunteke> :-)
[21:32] <SwissPhoenix> hunteke: Never use the force to do harm ;
[21:33] <Keybuk> hunteke: Upstart, at best, gives us feature parity with Windows
[21:33] <Keybuk> Windows (NT branch, at least) has always had a service management framework
[21:33] <hunteke> Keybuk: well, then, call it more a "I want a faster boot because sleep is so sketchy right now" less harm oriented for SwissPhoenix ;-)
[21:33] <amitk> mvo: https://bugs.edge.launchpad.net/ubuntu/+bug/203715
[21:33] <ubotu> Launchpad bug 203715 in ubuntu "compiz eats lots of memory" [Undecided,New]
[21:34] <Keybuk> hunteke: Upstart won't give you a faster boot
[21:34] <Keybuk> it will just give you a boot where the order that things happen is no longer important
[21:34] <asac> slangasek: network-manager 0.6.6-0ubuntu2 knocks on your door
[21:34] <Keybuk> (which means we can take out a lot of sleep statements and busy loops)
[21:34] <hunteke> no? I thought it was event based so a lot of the serialization could be parallelized
[21:34] <hunteke> but I suppose also sleep statements removed
[21:34] <Keybuk> it's event based so we can do things when we can do them
[21:34] <Keybuk> rather than doing things in the hope that we can do them
[21:35] <hunteke> hehe, point
[21:35] <Keybuk> the first question is that it's not being held back
[21:35] <Keybuk> http://bazaar.launchpad.net/~keybuk/upstart/trunk/changes
[21:36] <Keybuk> there's been a vast amount of development in bzr
[21:36] <Keybuk> this hasn't reached Ubuntu because Ubuntu is doing an LTS release
[21:36] <Keybuk> and some of the development is a bit exciting
[21:36] <Keybuk> (I've been hanging around cjwatson too long and am getting conservative in my old age)
[21:36] <SwissPhoenix> If anybody cares: Its bug#199934, so far I'm using an gutsy kernel which works...
[21:37] <hunteke> oh gosh, Keybuk, you're main dev on upstart (just whoised you).  Before I go any farther, let me say thank you for your work.
[21:41] <Seveas> Keybuk, how's they grey hair doing? :)
[21:41] <Keybuk> Seveas: heh, if I was taking that much after Colin it'd be going red, not grey
[21:42] <Seveas> lol, true that
[21:42] <Seveas> it'd also be a tad longer
[21:45] <Seveas> Keybuk, do you plan to break intrepid the minute hardy has been released, or will we have to wait for upstart goodness a bit longer?
[21:45] <Keybuk> depends
[21:45] <Keybuk> D-Bus and I have yet to become friends
[21:46] <Seveas> that's tough love
[21:46] <Seveas> I'm fighting the pythin bindings now, there seems to be something in there that's less than optimal when sending a message
[21:47] <Seveas> and I'm sending a lot of messages :)
[21:47] <jdong> what are the hard dependencies of starting gdm?
[21:47] <jdong> of course x11-common and checkroot'ed
[21:47] <jdong> but is dbus actually needed before login?
[21:48] <Keybuk> absolutely
[21:48] <Keybuk> since the gdm greeter will need dbus
[21:48] <Keybuk> and hal, and policykit, and consolekit, etc.
[21:48] <jdong> oh ok
[21:48] <jdong> so I'm getting too greedy :)
[21:49] <jdong> Keybuk: is there a way to use initctl to block until some event has happened? (i.e. start X first then have early gdm init block until dbus is ready)
[21:49] <Keybuk> gdm starts X
[21:49] <Keybuk> that's kinda the point
[21:49] <Keybuk> GNOME *DISPLAY MANAGER* :)
[21:50] <jdong> Keybuk: well the VT switching into X on my macbook takes like 3-4 bloody seconds
[21:50] <jdong> Keybuk: I'm wondering if that could be taken care of in a more parallel manner :)
[21:50] <Keybuk> jdong: that's fixed by other bits of work in progress
[21:50] <jdong> that's good to hear
[21:51] <wasabi> I hear mode switching will move into the kernel, so modes won't have to be switched when changing VTs and such, unless resolution actually changes.
[21:52] <Keybuk> exactly
[21:52] <Keybuk> getty-gtk ;)
[21:52] <wasabi> usplash should leave it in the right res for GDM
[21:52] <wasabi> getty-gtk sounds awesome.
[21:52] <wasabi> How far are we from all that?
[21:53] <Keybuk> I've seen people actually using it now
[21:53] <wasabi> Seriously? Wow.
[21:53] <Keybuk> which is a good step up from seeing people demo it
[21:53] <Keybuk> so end of the year maybe before it's in shippable drivers
[21:53] <Keybuk> (where it = kernel mode setting/TTM/Gallium3D/etc.)
[21:55] <soren> I've seen interfaces get renamed to eth?_renamed a few times before... What's that all about?
[21:55] <wasabi> That's exciting stuff. Can't wait to see it all come together.
[21:55] <Keybuk> soren: interface renaming
[21:55] <soren> Keybuk: No kidding? :)
[21:55] <Keybuk> soren: it's about renaming interfaces from one name to another :)
[21:56] <Keybuk> so, the kernel is a bit thick
[21:56] <soren> Keybuk: Oh. This is very enlightening.
[21:56] <soren> :)
[21:56] <Keybuk> it has a counter
[21:56] <soren> Right.
[21:56] <Keybuk> every time it sees a new interface, it increments that counter, and names it that
[21:56] <soren> I realise why we rename them.
[21:56] <Keybuk> so the first interface the kernel sees is eth0
[21:56] <Keybuk> the second one is eth1
[21:56] <Keybuk> and so on
[21:56] <soren> Sure, sure.
[21:56] <soren> I got that.
[21:56] <soren> I also get the persistent naming and all that.
[21:56] <Keybuk> unfortunately the kernel doesn't see them in any kind of consistent or useful order
[21:56] <wasabi> So usplash starts, puts monitor in right mode, initramfs finishes quickly, upstart comes up, something can send job status text from upstart to usplash if we care, then X appears. No clicking or anything.
[21:56] <Keybuk> so we have to rename them
[21:57] <Keybuk> the problem is when the kernel sees A=eth0 and B=eth1
[21:57] <Keybuk> but we want B=eth0 and A=eth1
[21:57] <Keybuk> the only way to resolve that deadlock is to rename them to something else
[21:57] <soren> Keybuk: Ah.
[21:57] <Keybuk> so udev names A=eth0_rename B=eth1_rename
[21:57] <Keybuk> then renames A=eth1 and B=eth0
[21:57] <soren> Makes sense.
[21:57] <Keybuk> sometimes this comes a bit unglued when it tries to rename A and B to the same thing
[21:57] <Keybuk> so you end up with A=eth0 and B=eth1_rename
[21:58] <Keybuk> this tends to happen with mac80211 devices which have both a wmaster0 and wlan0 interface
[21:58] <soren> Right. This is in the installer with two identical NIC's (different MAC's though).
[21:58] <Keybuk> and udev thinks they should both be wlan0 or eth1
[21:58] <Keybuk> it shouldn't ever try and rename two things with different MACs to the same name
[21:58] <soren> These are realtek 8139 nic's.
[21:58] <Keybuk> address matching is on MAC
[21:58] <ion_> Obvious solution: create a program that changes the bytes directly in /dev/kmem.
[21:58] <soren> Yeah, I know.
[21:58] <soren> Hmm..
[21:58] <Keybuk> wasabi: upstart starts in initramfs, hands over to upstart in real system
[21:59] <wasabi> We're going to get it to that?
[21:59] <soren> Maybe the peristent-names-generator is racy somehow.
[21:59] <Keybuk> soren: shouldn't be
[21:59] <wasabi> I saw your latest upstart release thing fly by. I was excited to see it coming along.
[21:59] <soren> No, persistent-net.rules looks fine.
[21:59] <soren> Hm...
[21:59]  * soren scratches his head
[21:59] <Keybuk> it happens *inside* the installer?
[21:59] <soren> Yeah.
[21:59] <Keybuk> that's not doing anything crazy like killing udev, right?
[22:00] <soren> Ah, sorry. I've booted into rescue mode on the server cd, but I belive I saw the same in the real installer.
[22:00] <Keybuk> do you have /var/log/udev you can nopaste for me?
[22:00] <soren> 70-persistent-net.rules *is* odd, now that I think about it.
[22:00] <soren> The rules look like:
[22:00] <Keybuk> can you nopaste that too? :)
[22:00] <soren> SUBSYSTEM=="net", ACTION=="add"; ATTR{type}=="1", NAME="eth0"
[22:01] <Keybuk> there's a ";" there?
[22:01] <soren> Mistyped.
[22:01] <Keybuk> ok
[22:01] <soren> The interesting bit is the lack of a mac.
[22:01] <Keybuk> yeah that's VERY interesting :)
[22:01] <Keybuk> that means there was no address node in sysfs for that card
[22:01] <Keybuk> is there one now? :)
[22:02] <Riddell> ogra_cmpc: edubuntu dvds for beta?
[22:02] <soren> Keybuk: Yep.
[22:02] <Keybuk> weird
[22:02] <Keybuk> can you nopaste both for me?
[22:02] <soren> Quite.
[22:02] <soren> Keybuk: Do you have kvm capable hardware?
[22:03] <Keybuk> soren: how do I find out?
[22:03] <soren> Keybuk: grep -E '(vmx|svm)' /proc/cpuinfo
[22:03] <Keybuk> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
[22:03] <soren> Great.
[22:03] <soren> Then you do. install kvm, and fire it up like so:
[22:03] <seb128> soren: I guess that virt-manager limiting cursors move to the wrong area until you move it on the right is a known issue?
[22:03] <Keybuk> soren: I do?
[22:03] <Keybuk> soren: neither of those things is in there
[22:04] <mvo> amitk: thanks!
[22:04] <soren> Keybuk: Oh, I thought that was the output of the grep.
[22:04] <soren> Keybuk: (the output would be the empty string if you didn't have them)
[22:04] <Keybuk> :)
[22:04] <soren> ..so I didn't really look all that closely.
[22:04] <Keybuk> no, I was mentally grepping and pasting in case I had anything else useful in there that you recognised
[22:05] <Keybuk> in fact
[22:05] <Keybuk> none of my machines have either of those
[22:05] <soren> Shame.
[22:05] <Keybuk> this is an Athlon 64 X2
[22:05] <Keybuk> the laptops are Intel Core Duo U2500 and Core 2 Duo T5550
[22:05] <Keybuk> they don't have it either
[22:05] <mvo> ogra__: do you handle moodle? I get a upgrade problem from stock dapper->hardy with it
[22:06] <soren> Keybuk: Yeah, there are a few models of C2D's that don't. Those might be the ones :)
[22:07] <soren> Keybuk: You want the udev log and the persistent-net.rules?
[22:07] <soren> Keybuk: Was that it?
[22:07] <Keybuk> yup, please
[22:07] <LaserJock> mvo: what kind of problem?
[22:08] <soren> wtf... There's no /var/log/udev.
[22:09] <crimsun> LaserJock: keep in mind the delta between dapper and dapper-{security,updates}
[22:09] <soren> Keybuk: I'm finding myself increasingly unable to construct coherent sentences. I need sleep :) I'll look at it tomorrow morning.
[22:09] <crimsun> LaserJock: namely, debian/{postinst,templates}
[22:10] <mvo> LaserJock: not sure yet, it seems to got stuck at a ucf prompt at dapper->hardy, I need to investigate further
[22:10] <LaserJock> crimsun: sure. I was going to say that a lot has changed in moodle since dapper
[22:10] <LaserJock> mvo: ucf?
[22:11] <crimsun> mvo: dapper's stock moodle has that nasty debconf bit (i.e., fails to install)
[22:12] <mvo> crimsun: interessting, I have it in my dapper image, that indicates that it somehow got installed without failure
[22:12] <mvo> LaserJock: package urc: Description: Update Configuration File: preserve user changes to config files.
[22:12] <mvo> LaserJock: meh, make that "package: ucf"
[22:12] <crimsun> mvo: was moodle installed before or after apache?
[22:13] <crimsun> I vaguely remember discussing this with Martin a couple years ago
[22:13] <ScottK2> pitti: On cyrus-sasl2-heimdal, yes, today libdb-dev and libdb4.6-dev is the same, but there's no guarantee in the future.  Since cyrus-sasl2-heimdal needs the same version as cyrus-sasl2, we needed an ubuntu1 version in any case and so we might as well keep the better build-dep.  That's my view anyway.
[22:14] <mvo> crimsun: that is a very good question :)
[22:14] <pitti> ScottK2: ah, right, that version identity; I see
[22:14] <pitti> ScottK2: thanks for confirming
[22:14] <pitti> ScottK2: btw, I just fixed that 'apport crashes on guidance' bug (I hope), in unapproved now
[22:15] <mvo> crimsun: hm, it seems like moodle is a fresh install, not a upgrade (brought in by edubuntu something)
[22:16] <Riddell> evand: gobuntu oversized :(
[22:16] <evand> ARGH!
[22:19] <ScottK2> pitti: Great (I hope).  At least I'll know the truth then ..
[22:20] <soren> Keybuk: No /var/log/udev in the proper installer either (I was in the installer's rescue mode before)
[22:20] <Keybuk> that's odd
[22:20] <Keybuk> maybe they don't make one
[22:29] <mvo> crimsun: I can not install moodle in a pbuilder chroot here, it hangs and the process list shows me there is something ucf releated going on (but no prompt or anything)
[22:29] <mvo> (not sure that I should talk to you about it :)
[22:30] <mvo> or is ogra a better person to ask here?
[22:30] <mvo> hm, pressing "\n" helped
[22:30]  * mvo scratched his head
[22:32] <crimsun> mvo: the last time I touched moodle was for dapper-updates
[22:32] <crimsun> so no, I'm probably not the best WRT hardy
[22:33] <mvo> ok, thanks crimsun
[22:33] <LaserJock> mvo: the newer packages were done by moquist
[22:33] <mvo> LaserJock: does he do irc?
[22:33] <LaserJock> in #edubuntu sometimes
[22:33] <mvo> last update in gutsy ... hmmm
[22:34] <soren> Keybuk: Oh.. I think I may have an idea.
[22:34] <LaserJock> mvo: yeah, that's when we did a major repackaging and got it into Main
[22:34] <mvo> LaserJock: thanks a lot, I will look into it and see what I can do
[22:34] <LaserJock> mvo: we did a lot of changes to debconf stuff, it's possible something broke when we did so
[22:35] <Keybuk> soren: what is your idea?
[22:36] <soren> Keybuk: I just noticed the persistent-net-generator.rules weeds out nic's with locally assigned mac addresses.
[22:37] <soren> ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""
[22:38] <moquist> mvo: LaserJock clued me in. What's up?
[22:38] <soren> Keybuk: Hm.. The macs start at 52:54:00:12:34:56 where the last octet is increased for each nic.
[22:38] <soren> Keybuk: They should be alright.
[22:39] <mvo> hello moquist! I was having trouble with moodle and was wondering if you might help, I can not install it in a pbuilder chroot, it hangs and only continues if I press "enter" (but there is no prompt)
[22:39] <mvo> moquist: it hanged in my auto dapper->hardy upgrade test, this is why I came to it
[22:39] <mvo> moquist: I run with DEBIAN_FRONTEND=noninteractive, so it might be something that is not easily triggered
[22:39] <soren> Keybuk: Er... No. I'm on crack.
[22:40] <soren> Keybuk: That *does* match that pattern, so the mac is cleared.
[22:40] <soren> Anyhow.. Bed time.
[22:40] <soren> Long over due.
[22:40] <mvo> moquist: I suspect its something to do with debconf and/or ucf - something like a leftover file descriptor or something equally crazy
[22:41] <mvo> (in the postinst)
[22:42] <moquist> mvo: You're working with a version of the package that I've never touched; I didn't work on it until gutsy, really.
[22:44] <mvo> moquist: this happens in a hardy pbuilder chroot too
[22:45] <mvo> moquist: but give me a bit, I'm looking into it - I *think* the call to dh_stop might be the problem
[22:45] <moquist> mvo: ah! And thanks for all the diagnosis.
[22:46] <mvo> moquist: so if I move handle_config before db_stop all seems to be fine. I have little clue about this package, so if you could double check that I'm not on crack, that would be much appreciated
[22:47] <moquist> mvo: I'm checking into it now.
[22:47] <mvo> moquist: great, thanks a lot!
[22:49] <nxvl> i'm having a problem with Bug #203710
[22:49] <ubotu> Launchpad bug 203710 in mysql-dfsg-5.0 "mysql-server-5.0 does not prompt for conffile update on upgrades" [High,Confirmed] https://launchpad.net/bugs/203710
[22:50] <nxvl> i can't find out why is that it isn't recognizing the configfile as changed
[22:50] <jdstrand> nxvl: conffile
[22:50] <Keybuk> is it a conffile or a config file?
[22:50] <nxvl> conffile
[22:50] <Keybuk> sure?
[22:50] <jdstrand> Keybuk: it's a confile as seen in /var/lib/dpkg/status
[22:50] <jdstrand> hrm conffile
[22:51] <Keybuk> jdstrand: what are the exact two packages involved here?
[22:51] <Keybuk> (URLs to .deb files, please)
[22:52] <jdstrand> Keybuk: well, the 'upgrade to' package was one I was working on, but I didn't change anything
[22:52] <jdstrand> Keybuk: with the conffiles
[22:52] <nxvl> Keybuk: http://paste.ubuntu.com/5837/
[22:52] <jdstrand> Keybuk: nxvl has some IIRC
[22:52] <Keybuk> jdstrand: do you have the one you were working on and the one you had before?
[22:53] <nxvl> i do it upgrading from gutsy to hardy
[22:53] <jdstrand> Keybuk: nxvl confirmed it with gutsy version to hardy version
[22:53] <jdstrand> Keybuk: if you give me a minute, I can fire up a gutsy vm and upgrade
[22:54] <nxvl> i did it from: https://edge.launchpad.net/ubuntu/gutsy/+source/mysql-dfsg-5.0/5.0.45-1ubuntu3
[22:54] <nxvl> to https://edge.launchpad.net/ubuntu/hardy/+source/mysql-dfsg-5.0/5.0.51a-3ubuntu2
[22:54] <nxvl> using pbuilder environment
[22:54] <Keybuk> nxvl: i386?
[22:54] <nxvl> Keybuk: yep
[22:54] <jdstrand> Keybuk: mine was amd64
[22:54] <Keybuk> which package?
[22:55] <nxvl> mysql-server-5.0
[22:55] <jdstrand> nxvl: did you also see it with mysql-common (with my.cnf)?
[22:55] <nxvl> jdstrand: with my.conf it asked
[22:55] <Keybuk> d'ling...
[22:57] <Riddell> ogra_cmpc: your dvds are nastily oversized
[22:59] <mvo> lamont: this http://paste.ubuntu.com/5841/ is probably a bug for you, right?
[23:03] <nxvl> jdstrand: it seems that it isn't recognizing it as a conffile -> http://paste.ubuntu.com/5843/
[23:05] <ScottK2> doko: If you're around I'd like to discuss python-xml transition for a moment?
[23:15] <jdstrand> Keybuk: just confirmed bug bites on a gutsy to hardy upgrade (both clean installs) on amd64
[23:15] <jdstrand> Keybuk: during install happened to get:
[23:15] <jdstrand> $ md5sum ./debian-*
[23:15] <jdstrand> 7ac6cab7c0c2efaaaca2691b4ec3d6ec  ./debian-start
[23:15] <jdstrand> 4272e4d740c8ae651ac35bbf4d2ed6dc  ./debian-start.dpkg-new
[23:16] <jdstrand> and of course /var/lib/dpkg/status had:
[23:16] <jdstrand>  /etc/mysql/debian-start 4272e4d740c8ae651ac35bbf4d2ed6dc
[23:17] <nxvl> jdstrand: how did you get that?
[23:17] <nxvl> got*
[23:17] <jdstrand> nxvl: just lucky timing :)
[23:18] <Keybuk> so you installed 5.0.45
[23:18] <Keybuk> modified debian-start
[23:18] <Keybuk> then installed 5.0.51a ?
[23:18] <jdstrand> nxvl: ran md5sum after unpack but before postinst
[23:18] <Keybuk> and it didn't prompt?
[23:18] <nxvl> Keybuk: yep
[23:18] <jdstrand> Keybuk: yes
[23:18] <jdstrand> it's kooky
[23:18] <nxvl> jdstrand: oh!
[23:19] <jdstrand> nxvl: -v
[23:20] <nxvl> jdstrand: yes, i already did that
[23:21] <jdstrand> Keybuk: I did not know of a way to prevent dpkg from prompting on a conffile
[23:21] <Keybuk> jdstrand: ?
[23:21] <jdstrand> Keybuk: I am simply puzzled by the behavior
[23:22] <jdstrand> Keybuk: I have not seen it before
[23:22] <Keybuk> someone remind me how I disable debconf? :p
[23:22] <mvo> export DEBIAN_FRONTEND=noninteractive
[23:22] <Keybuk> thanks
[23:23] <Keybuk> D000020: process_archive conffile `/etc/mysql/debian-start' no package, no hash
[23:23] <Keybuk> ok, so that's sensible on first install
[23:25] <nxvl> Keybuk: where did you get that output?
[23:25] <Keybuk> nxvl: dpkg
[23:25] <jdstrand> nxvl: --debug
[23:25] <nxvl> thnx
[23:25] <nxvl> :D
[23:26] <Keybuk> -D77777 actually
[23:26] <Keybuk> D000020: deferred_configure `/etc/mysql/debian-start' (= `/etc/mysql/debian-start') useredited=-1 distedited=-1 what=204
[23:26] <Keybuk> ok
[23:26] <Keybuk> sensible on first configure
[23:27] <Keybuk> I have edited that file
[23:27] <Keybuk> Conffiles:
[23:27] <Keybuk>  /etc/init.d/mysql 4f0c573e38f141149bd19e4a929305b9
[23:27] <Keybuk> and edited to
[23:27] <Keybuk> 347d7585c6ba7936e4d11ed0b1df8b0e  /etc/mysql/debian-start
[23:28] <Keybuk> err
[23:28] <Keybuk>  /etc/mysql/debian-start 4272e4d740c8ae651ac35bbf4d2ed6dc
[23:28]  * Keybuk pastes the right line from status
[23:29] <doko> ScottK: discuss what? just remove it ;)
[23:31] <Keybuk> ok, so now let's unpack 51a
[23:31] <Keybuk> D000020: process_archive conffile `/etc/mysql/debian-start' package=mysql-server-5.0 same hash=4272e4d740c8ae651ac35bbf4d2ed6dc
[23:32] <Keybuk> and install
[23:33] <chadmiller> Hi.  I haven't made a new .deb in /years/.  What's the recommended tool these days to boostrap making a new package?
[23:34] <chadmiller> I mean, initialization with example debian/* files and such.
[23:34] <ScottK2> chadmiller: Packaging questions are best on #ubuntu-motu
[23:34] <Keybuk> D000020: deferred_configure `/etc/mysql/debian-start' (= `/etc/mysql/debian-start') useredited=1 distedited=0 what=2
[23:35] <Keybuk> nxvl, jdstrand: I am seeing no bug here
[23:35] <Keybuk> could you be a little more specific about what you're expecting to happen
[23:35] <Keybuk> and more importantly, *why* you're expecting that to happen
[23:35] <chadmiller> ScottK2: Thanks.
[23:35] <jdstrand> Keybuk: why didn't it prompt on upgrade?  the file changed, the package installed a new version
[23:35] <jdstrand> scratch
[23:35] <nxvl> Keybuk: if i edited debian-start, dpkg should ask me if i want to keep the edited file or update it
[23:35] <Keybuk> file hasn't changed
[23:36] <jdstrand> ist didn't install a new version, but should have prompted to install the new version
[23:36] <nxvl> Keybuk: and it's not asking, just ignoring it
[23:36] <Keybuk> no it shouldn't
[23:36] <nxvl> so
[23:36] <jdstrand> Keybuk: it isn't the same as the old one, so it is non-default
[23:37] <jdstrand> granted, it didn't overwrite it
[23:37] <Keybuk> why should it prompt?
[23:37] <nxvl> what you ar saying is that as the packaged debian-start from old and new version are the same, dkpg shouldn't ask?
[23:37] <Keybuk> right
[23:37] <nxvl> s/ar/are
[23:37] <jdstrand> and I agree
[23:38] <jdstrand> it is that the file on the system changed and is like neither the old installed version, or the new
[23:38] <nxvl> so, if i change debian-start on the new package and try to install it, then it should promt, didn't it?
[23:38] <jdstrand> s/new/new installed version/
[23:39] <nxvl> jdstrand: yes, but as the 2 packaged conffiles are the same, there is no problem with the changes i have done to the file (if i have understood correct)
[23:40] <nxvl> Keybuk: didn't it?
[23:40] <Keybuk> right
[23:43] <jdstrand> oh-- because the md5 of 5.0.45 and 5.0.51a were the same, we can keep the changes and be reasonably sure things are ok
[23:43] <nxvl> jdstrand: yep
[23:44] <jdstrand> and that just happened to also be the case for the file I was working with
[23:44] <jdstrand> man, I feel like a dumbass
[23:44] <jdstrand> Keybuk: thanks for your time on this
[23:44] <nxvl> i'm rechecking packing a changed version of debian-start, just to be sure
[23:45] <nxvl> well, at least i learn a lot about packages wasting my time on this bug :D
[23:45]  * jdstrand goes and makes a note of this subtelty
[23:45]  * nxvl HUGS Keybuk and jdstrand
[23:45]  * jdstrand and appreciates dpkg even more
[23:47] <jdstrand> nxvl: I invalidated the bug
[23:48] <jdstrand> nxvl: thanks for your time
[23:48] <jdstrand> too
[23:48] <nxvl> jdstrand: heh, i was doing it right now
[23:48] <nxvl> :P