[12:03] <\sh> elmo: please sync konserve from unstable, dropping ubuntu changes,thx
[12:05] <Kamion> mdz: hmm, 'bzr log' shows repeated changesets again from the previous merge - maybe 'bzr fix'?
[12:05] <mdz> Kamion: bzr fix crashes
[12:05] <Kamion> whee
[12:08] <mdz> ogra: update-rc.d remove is inappropriate for ThinClientFasterStartup because the links will be restored on upgrade
[12:09] <ogra> so i have to remove the packages completely then, ok
[12:09] <ogra> its a bit harder but will work too ...
[12:10] <ogra> i was planning to make a positive list and remove everything thats not in the list ...
[12:10] <mdz> ogra: no, you need to remove the startup links
[12:10] <ogra> you mean a plain rm ? 
[12:10] <mdz> yes
[12:10] <ogra> oki
[12:11] <mdz> ogra: does X autoconfiguration seriously take 30 seconds on any hardware you have available?
[12:11] <mdz> it is about 5 seconds here
[12:11] <ogra> yes
[12:11] <ogra> on your laptop ? 
[12:11] <mdz> yes
[12:11] <mdz> which is a 1.5GHz pentium M
[12:11] <sorush20> guys how do I get this package to be added to the graphics packaged in the development pachage lists? 
[12:11] <ogra> yes, on my amd64 3000+ its very fast
[12:11] <sorush20> http://www.path.unimelb.edu.au/~dersch/
[12:11] <mdz> on a 100mbit switched network
[12:11] <ogra> but thats exceptional for thin clients
[12:11] <mdz> sorush20: https://wiki.ubuntu.com/UniverseCandidates
[12:11] <ogra> i dont think thats network dependent at all
[12:12] <mdz> well, loading the X server and all its modules over the network takes some time
[12:12] <mdz> plus perl, etc.
[12:12] <ogra> its the probing that takes the time ... all appr should be in mem at this point
[12:12] <ogra> s/appr/apps/
[12:12] <mdz> unless it's a laptop LCD, the X server won't even be loaded at that point
[12:12] <ogra> wait a sec
[12:12] <mdz> it just scans the PCI bus with discover and uses debconf
[12:13] <ogra> i'll upload the recent bootchart from today
[12:14] <mdz> oh, that would be good
[12:14] <ogra> http://people.ubuntu.com/~ogra/edubuntu/dapper-20051205-1.png
[12:14] <ogra> grumbel ... my system is darn slow without DMA ...
[12:15] <ogra> compared with http://people.ubuntu.com/~ogra/edubuntu/breezy-20051113-1.png its a lot faster ...
[12:15] <ogra> but still not the 45sec i want ...
[12:15] <ogra> according to Keybuk we robably can achievethe 15 sec with his future fixes
[12:18] <mdz> ogra: the ltsp guys have no problem with using esd -public?
[12:18] <ogra> nope
[12:18] <ogra> they do it as well
[12:18] <mdz> if I were a student in a class which used that, I would play sounds through other students' thin clients to get them in trouble ;-)
[12:18] <ogra> i also was at linuxtage essen this weekend and talkeda lot to the skole people, they do it too
[12:18] <mdz> the alternative would be to send the esd auth cookie in an environment variable
[12:18] <mdz> which would require an esdlib patch
[12:19] <ogra> there is no other way to make esd listen on the net :/
[12:19] <ogra> yes
[12:19] <mdz> esd can use its usual authentication over the network
[12:19] <tseng> mdz: you would be the kid that MiM his ssh X tunnel and made bad pictures come up in a browser on his screen
[12:19] <ogra> most teachers tell me they will disable it anyway, because it will be distracting
[12:19] <mdz> but if everyone else is doing this, we can try it as a first cut
[12:20] <ogra> and encourages kids to download mp3s
[12:20] <mdz> tseng: except that the real me foiled that attack by stashing the server's ssh host key ahead of time
[12:20] <ogra> heh
[12:20] <mdz> ogra: it will be disabled by default
[12:21] <ogra> oh, i wanted enable it by default ... and make disabling optional
[12:22] <mdz> we should disable it by default; if I'm not mistaken, that's what ltsp does as well
[12:22] <ogra> btw, seems the X_MOUSEDEV patches dont work at all for serial mice... i had several people that tried it ... will get a serial mouse myself as soon as i can find one ...
[12:23] <mdz> ogra: it looks like those debconf-communicate calls take a long time; we should collapse them into a single invocation
[12:23] <mdz> I think the MOUSEDEV stuff came from pere or vagrantc
[12:23] <ogra> as well as the colordepth patches from pere cant work with our xorg
[12:23] <ogra> i talked to daniels about it
[12:24] <ogra> as long as seen is set in debconf, it won be touched at all ... but he wanted to make a ENV var available
[12:24] <ogra> it would break the autodetection if we'd change the dbeconf behavior if i undrstood him right
[12:25] <ogra> but 16bit by default is essential
[12:25] <ogra> else we'll eat all mem ...
[12:26] <Keybuk> ogra: still haven't tracked down what causes that no-DMA issue; it affects you too?
[12:26] <ogra> i'm astonished the mouse stuff doesnt work ... a shame i cat test myself
[12:26] <ogra> Keybuk, yes, but the driver is loaded fine
[12:26] <mdz> ogra: thin client memory usage approved
[12:26] <ogra> ut since my lappie already has a 4200rpm drive its really a pain :)
[12:26] <ogra> YAY
[12:27] <Keybuk> ogra: yeah, that's the same thing mdz sees
[12:27] <Keybuk> ogra: are you around tomorrow AM (UTC) for some hot debugging action?
[12:27] <ogra> sure :)
[12:28] <mdz> ogra: in ThinClientAudioSupport, you removed my comment about esddsp but didn't address it
[12:29] <mdz> Keybuk: I can trace first-hand what happens; I just don't understand why it didn't happen before
[12:29] <mdz> Keybuk: have you checked with BenC if something changed in kernel-land
[12:30] <Keybuk> he didn't seem to think anything did, kay had no idea either
[12:30] <mdz> Keybuk: is it expected that ide-disk isn't loaded when piix loads?
[12:30] <Keybuk> do you concur that we're loading the right modules, but the module isn't claiming the disk and ide-generic is instead?
[12:30] <ogra> mdz, because the ssh_remote_commad hac worked so well... i'll look at esddsp again
[12:30] <Keybuk> tbh, I'm not sure ... I think mine does the same thing, and only loads ide-disk once ide-generic is loaded _except_ that for some reason, the right driver claims the disk
[12:31] <mdz> ogra: you are basically reimplementing esddsp on the command line
[12:32] <ogra> but i have to set ESPEAKER= anyway 
[12:32] <ogra> so we wont get around this hack
[12:32] <mdz> ogra: esddsp is a lot better than setting LD_PRELOAD on the command line
[12:33] <ogra> yes, thats true, but i have still to add ENV vars ... so we'll have to make changes in two places instead of one ...
[12:33] <mdz> ogra: give it a try, update the spec for that, and it is ready for approval
[12:33] <mdz> ogra: no, it's still in one place
[12:33] <ogra> oki
[12:34] <ogra> i'll update it before the next dev meeting ...
[12:34] <BenC> are we talking about cdroms?
[12:34] <ogra> BenC, nope
[12:34] <ogra> harddisks
[12:34] <BenC> ok
[12:34] <mdz> just remove the LD_PRELOAD stuff, remove ESDDSP_MIXER, and use esddsp -m
[12:34] <ogra> Keybuk, -generic isnt loaded here 
[12:34] <ogra> oki
[12:34] <mdz> ogra: it'll look like this:
[12:35] <Keybuk> ogra: ide-generic being loaded is hard-coded into the script <g>  if it's not loaded, you've been playing silly buggers :D
[12:35] <mdz> ogra: ['env', ..., 'esddsp', '-m', session_manager, ...] 
[12:35] <ogra> ah, k
[12:35] <ogra> that doesnt require ESPEAKER ??
[12:35] <mdz> ESPEAKER is still required
[12:35] <ogra> that what i thought
[12:35] <mdz> well
[12:36] <mdz> or you could use esddsp --server
[12:36] <mdz> that is probably clearer
[12:36] <ogra> yup
[12:36] <mdz> ogra: also, why mess with amixer?
[12:36] <mdz> the alsa init script does a better job
[12:36] <ogra> its full volume here if i dont do anything ...
[12:37] <ogra> thats *very* loud
[12:37] <mdz> it should have exactly the same volume as if you booted the live CD or installed ubuntu
[12:37] <ogra> and thats what ltsp.org does as well btw
[12:37] <mdz> which is 80%
[12:37] <mdz> on most cards
[12:37] <ogra> hmm, then i'll have to inspect this
[12:37] <mdz> but the script has logic to set an appropriate level, and you should use it
[12:38] <ogra> yes, might also be 80% but y next neighbor hears it (150m away) if my window is open in the office
[12:39] <ogra> at least on the ltsp client i have here its to loud ...
[12:39] <Keybuk> mdz, ogra: when you do "udevplug -Bpci -Iclass=0x01*" at break=premount ... can you recall which modules are loaded?
[12:40] <ogra> ide-disk and the via driver iirc
[12:40] <mdz> Keybuk: I did that test on friday
[12:40] <Keybuk> mdz: can you recall the output?
[12:40] <mdz> I believe I got only piix and deps
[12:40] <ogra> via82cxxx
[12:40] <mdz> no ide-disk
[12:40] <mdz> will try again now
[12:40] <Keybuk> ide-core, piix and "generic" ?
[12:40] <ogra> oh, and -generic 
[12:41] <Keybuk> easiest way to tell is to do UDEV_LOG=info udevd --daemon
[12:41] <mdz> actually, will try again after upgrading the laptop
[12:41] <Keybuk> then read the output
[12:41] <Keybuk> heh
[12:41] <ogra> oh, intresting 
[12:42] <[g2] > Anyone from the installer team around ?  I'm wondering about an embedded installer (XScale target)
[12:42] <ogra> i suddenly can switch on DMS
[12:42] <ogra> DMA
[12:42] <jbailey> [g2] : We don't have any embedded targets atm.
[12:42] <ogra> i didnt try since todays upgrade
[12:42] <jbailey> [g2] : So, no arm binaries in Ubuntu at this point.
[12:42] <ogra> Keybuk, so it works again at least, its just not on by default
[12:43] <[g2] > jbailey that's ok, I've got an XScale target and they 13.5K debian packages are ported to it
[12:43] <[g2] > s/debian/Debian
[12:43] <Keybuk> ogra: I still suspect you've not got the right association to your driver
[12:43] <jbailey> [g2] : Right.  But we don't inherit the binaries from Debian, only source packages.
[12:43] <jbailey> [g2] : So there's no Ubuntu arm binaries that you can use.
[12:44] <[g2] > jbailey right, two of my buddies build all the packages form source
[12:44] <jbailey> [g2] : https://wiki.ubuntu.com//%c2%b5buntu has some info on where it's heading, but we're not there yet.
[12:44] <[g2] > jbailey I know. I'm ahead of you
[12:44] <Diablo-D3> hrm
[12:44] <[g2] > I talked with Jeff W. after the trilug meeting about it
[12:44] <Diablo-D3> kernel is built with gcc4 now, right?
[12:45] <ogra> Keybuk, lsmod looks like it looked in breezy ... i just habe the prob that DMA is off
[12:45] <ogra> *have
[12:45] <Diablo-D3> ooh
[12:45] <Diablo-D3> and new X
[12:45] <Diablo-D3> <3
[12:46] <Keybuk> ogra: right
[12:47] <Keybuk> ogra: could you do # readlink /sys/bus/ide/devices/0.0 for me
[12:47] <ogra> ../../../devices/pci0000:00/0000:00:11.1/ide0/0.0
[12:47] <ogra> all for you :)
[12:48] <Keybuk> ok
[12:48] <Keybuk> also
[12:48] <Keybuk> readlink /sys/devices/pci0000:00/0000:00:11.1/driver
[12:48] <mdz> Keybuk,jbailey: any reason not to add lsmod to initramfs for debugging?
[12:48] <\sh> ok...I'll give up...
[12:48] <mdz> it must be laughably small
[12:48] <Keybuk> mdz: cat /proc/modules is the same thing ... though I have no problem with lsmod being there
[12:48] <mdz> Keybuk: it is close but it is a lot more typing
[12:49] <mdz> and I don't have a keymap in initramfs
[12:49] <Keybuk> Colin is currently my hero for adding readline support :p
[12:49] <Keybuk> ogra: what was the output of the second readlink?
[12:49] <ogra> ../../../bus/pci/drivers/PCI_IDE
[12:49] <ogra> sorry
[12:50] <Keybuk> thanks ... # ls /sys/bus/pci/drivers
[12:50] <ogra> agpgart-amd64  ohci1394         r8169     VIA 82xx Audio  vt596_smbus
[12:50] <ogra> ehci_hcd       parport_pc       serial    VIA 82xx Modem  yenta_cardbus
[12:50] <ogra> nvidia         pcieport-driver  shpchp    VIA_IDE
[12:50] <ogra> nvidiafb       PCI_IDE          uhci_hcd  via-ircc
[12:50] <Keybuk> what model laptop is yours?
[12:51] <ogra> acer aspire 1520
[12:51] <ogra> amd64, nvidia card and 512MB
[12:51] <Keybuk> mdz: yours is an IBM T42?
[12:51] <mdz> Keybuk: yep
[12:51] <mdz> ok, from break=premount
[12:51] <mdz> I did UDEV_LOG=info udevd --daemon
[12:51] <mdz> and udevplug -Bpci -Iclass=0x01*
[12:52] <mdz> I get one modprobe and a bunch of has_drivers
[12:52] <jbailey> mdz: No real objection.
[12:52] <Keybuk> ok
[12:52] <mdz> and when the dust settles, I have piix, ide_core and 'generic' loaded
[12:52] <Keybuk> that modprobe is for pci:bllaaaaah
[12:53] <mdz> correct
[12:53] <Keybuk> then if you modprobe ide-generic, you get a whole frat-party of events?
[12:53] <mdz> yes, I did that before
[12:53] <mdz> do you want me to try it now or check something else first?
[12:53] <Keybuk> could you do that now, so I can get the readlink outputs on yours
[12:53] <Keybuk> (I'm composing an e-mail to the IDE list first)
[12:54] <mdz> ok, gobs of events
[12:54] <mdz> more than console scrollback worth
[12:54] <Keybuk> right
[12:54] <Keybuk> readlink /sys/bus/ide/devices/0.0
[12:54] <mdz> ../../../devices/pci0000:00/0000:00:1f.1/ide0/0.0
[12:55] <Keybuk> readlink /sys/devices/pci0000:00/0000:00:1f.1/driver
[12:55] <mdz> ../../../bus/pci/drivers/PIIX_IDE
[12:55] <Keybuk> oh, now that's interesting
[12:56] <mdz> well, I'm not testing exactly the same code as before
[12:56] <mdz> perhaps I should continue the boot and see if DMA is still b0rked
[12:56] <Keybuk> what code has changed?
[12:57] <Keybuk> sure ... just press ^D to continue the boot
[12:57] <Keybuk> (COLIN IS A HERO)
[12:57] <mdz> Keybuk: that one was me, actually ;-)
[12:57] <Keybuk> oh, was that you?
[12:57] <Keybuk> then you are also a HERO
[12:57] <mdz> interesting, I got a DEVPATH missing message from udevd
[12:57] <[g2] > jbailey thx for the URL
[12:57] <mdz> just after ext3 loaded it looked like
[12:58] <Keybuk> that's kinda interesting
[12:58] <mdz> anyway, since friday I've got new initramfs and new kernel I think
[12:58] <jbailey> [g2] : Glad to help.  I'm just running out.  I'd love to chat more about it another time, since I'm interested in the buntu project.
[12:58] <mdz> hah!
[12:58] <mdz> Keybuk: using_dma = 1
[12:58] <jbailey> [g2] : I'm jbailey@ubuntu.com if you want to chat more.
[12:58] <mdz> lemme do a default boot
[12:58] <Keybuk> could've been a kernel bug then ...
[12:58] <[g2] > jbailey cheers
[12:59] <Keybuk> if this is another one of those annoying races though, I'm going to get grumpy
[12:59] <tseng> [g2] : !
[01:00] <[g2] > hey!
[01:00] <tseng> [g2] : i was just looking for you the other day
[01:00] <mdz> Keybuk: using_dma = 1
[01:01] <Keybuk> mdz: could you keep a close eye on that every time you reboot?
[01:01] <Keybuk> at least for the next few times, anyway
[01:01] <Keybuk> BenC: were there any piix driver changes recently?
[01:02] <BenC> not that I know of, but I can check
[01:02] <BenC> ata or ide?
[01:03] <Keybuk> ide
[01:03] <mdz> Keybuk: my boot time is back down to pre-bootchart pre-new-udev-world-order levels
[01:03] <mdz> Keybuk: http://people.ubuntu.com/~mdz/bootchart/dapper-20051205-1.png
[01:04] <mdke> is there any particular place that those of us who can't usefully debug our bootcharts should be uploading them? perhaps wiki pages?
[01:04] <BenC> Keybuk: piix.c hasn't been touched except to allow it to be modular
[01:05] <Keybuk> mdz: that's better ... you'll benefit a lot from moving ifup back into hotplug events by the looks of it
[01:05] <BenC> maybe the modular changes are broken, did it ever work in 2.6.15?
[01:05] <mdz> Keybuk,BenC: I'll boot .15-5 again for kicks
[01:05] <tseng> elmo: please sync libapache-mod-musicindex. dropping changes
[01:05] <mdz> Keybuk: is readahead still fucked?
[01:05] <BenC> that modular change was in -1.1, so it's always been there
[01:06] <ogra> mdz, woah, over a minute ? 
[01:06] <ogra> my lappie is ~50 sec even with a slow HD
[01:06] <Keybuk> mdz: I have a tool to generate new lists now, going to play follow-the-lady with rcS tomorrow and wednesday and upload new readahead with that
[01:07] <Keybuk> http://www.ussg.iu.edu/hypermail/linux/kernel/0512.0/0669.html
[01:07] <Keybuk> ^ mmmm
[01:08] <ogra> the intro text is worrying
[01:09] <Keybuk> heh
[01:09] <Keybuk> why?
[01:09] <Keybuk> SATA != IDE
[01:09] <mdke> Keybuk, any idea on my question above (at 00:04)?
[01:10] <ogra> yeah, but testing IDE with a cf reader due to lack of HW makes me worry about the ide implementation
[01:10] <mjg59> Keybuk: That's nice and easy
[01:10] <Keybuk> mdke: there is no particular place, upload them anywhere you like and attach them to reports of bugs or mail them to the users list, etc.
[01:11] <mjg59> ogra: The patch is trivially obvious(tm)
[01:11] <BenC> the change to piix.c is so minimal it couldn't affect operation
[01:11] <mdke> Keybuk, okay, the users list?
[01:11] <BenC> it has like a couple of lines for module exit, and that's it
[01:11] <Keybuk> BenC: I've heard that before <g>
[01:12] <Keybuk> mjg59: the subsystem maintainer is having a sulk though
[01:12] <mjg59> Keybuk: Bart?
[01:12] <Keybuk> yeah
[01:12] <mjg59> Oh, Broadcom wireless stuff is now usable with a bit of fiddling
[01:12] <mjg59> So we'll certainly be shipping with support
[01:15] <segfault> hotplug dropped from dapper?
[01:16] <Keybuk> segfault: keep up <g>
[01:16] <Keybuk> mjg59: bitched about the missing ide-scsi and ide-optical stuff
[01:17] <desrt> segfault; hopefully.
[01:17] <segfault> whats replacing it?
[01:17] <desrt> udev
[01:17] <desrt> and the kernel netlink socket
[01:17] <Keybuk> which is probably a good census of people who use them, because neither the Debian, Ubuntu or SuSE ide helpers load those modules <g>
[01:17] <mjg59> Keybuk: Well, tough
[01:17] <Keybuk> segfault: udev has entirely replaced it
[01:17] <mjg59> Heh
[01:17] <Keybuk> all of the hotplug scripts have been replaced by the command
[01:17] <Keybuk> "modprobe $MODALIAS"
[01:18] <desrt> no more kernel shelling out to /sbin/hotplug
[01:18] <Keybuk> welcome to the revolution, baby
[01:18] <segfault> heh
[01:18] <ogra> hehe
[01:18] <Keybuk> <fx: voodoo child intro>
[01:18] <desrt> does that make modules.conf the right place to blacklist these days?
[01:18] <Keybuk> desrt: yes.
[01:19] <desrt> excellent!
[01:19] <segfault> any sound handling changes in dapper?
[01:19] <Keybuk> segfault: not yet, they're on my tofix list :p
[01:19] <segfault> i have no sound here, although the snd-intel8x0 is loaded
[01:19] <segfault> its quite weird
[01:20] <Keybuk> yeah, you'll probably find the OSS driver has STOLEN YOUR SOUND
[01:20] <ogra> evil
[01:20] <segfault> heh, exactly
[01:27] <mjg59> Wow. I hadn't realised just how easy writing a libata-based PATA driver is
[01:27] <Keybuk> mjg59: you now need to cackle manically
[01:27] <Keybuk> as if writing a libata-based PATA driver was the key to world domination
[01:27] <mjg59> You provide a setup function, a table of function pointers and some functions that set the timing
[01:28] <mjg59> Utter win
[01:31] <ploum> lol :-)
[01:31] <ploum> Just look at the changelog of libcairo2
[01:31] <ploum> "* debian/patches/02-no-ft-glyphslot-embolden.patch:
[01:31] <ploum>      - not required."
[01:32] <ploum> not required...  Thus now every gnome application fail with : "symbol lookup error: /usr/lib/libcairo.so.2: undefined symbol: FT_GlyphSlot_Embolden"
[01:32] <ogra> not here
[01:32] <Keybuk> ploum: "required" and "used" are different words
[01:33] <ploum> ogra : you don't have this on a dapper install ?
[01:33] <ogra> nope
[01:33] <ogra> all fine here
[01:33] <ploum> so maybe it's me...
[01:39] <ploum> found
[01:39] <ploum> sorry, it was (as always) my fault ;-)
[01:40] <ogra> :)
[01:40] <ploum> (libfreetype6 not upgraded)
[01:40] <ogra> yup thete is a lot fuss about the freetype stuff currently ...
[01:41] <ploum> I will suggest to seb128 that the package libcairo2 must depend of libfreetype6 >= 2.1.10
[01:41] <ploum> Do you think it worths a bug ?
[01:41] <ploum> (or things are moving so quickly that it doesn't matter?)
[01:42] <ploum> I don't know anything about freetype. Exciting new stuffs ?
[01:49] <ploum> good night
[01:59] <Diablo-D3> hrm
[02:09] <Keybuk> ogra: around?
[02:09] <ogra> yup
[02:09] <ogra> sure :)
[02:10] <Keybuk> the laptop with the via chip, can you debug some stuff with that while you IRC from another machine?
[02:10] <ogra> hmm...
[02:10] <ogra> i have to save some stuff
[02:10] <mjg59> Keybuk: I've got a VIA laptop here, if you have a general via problem that needs debugging
[02:11] <Keybuk> mjg59: is it running dapper?  the problem is that the IDE chipset doesn't probe for or register the devices
[02:11] <mjg59> Keybuk: Ah. No, it's on Breezy.
[02:12] <Keybuk> don't suppose you know a way of getting dmesg output without /bin/dmesg ?
[02:12] <ogra> give my evo 2min (it needs it to close)
[02:12] <mjg59> Keybuk: cat /proc/kmsg
[02:12] <Keybuk> ahh, of course
[02:12] <mjg59> Oh, except that doesn't seem to give the current contents of the buffer
[02:15] <ogra_> Keybuk: ok
[02:16] <ogra_> reboot with break=premount ?
[02:17] <Keybuk> yup, please
[02:17] <Keybuk> then run scripts/init-premount/thermal to stop your laptop burning up
[02:17] <ogra_> heh ... will do
[02:18] <ogra_> done
[02:18] <Keybuk> right
[02:18] <Keybuk> udevd --daemon
[02:19] <Keybuk> udevplug -Bpci -Iclass=0x01*
[02:19] <Keybuk> (wait about 10-15s)
[02:19] <ogra_> ok
[02:20] <ogra_> hmm the fan is still running
[02:20] <Keybuk> that's ok
[02:20] <Keybuk> think that should be enough of a wait
[02:20] <Keybuk> now modprobe ide-generic
[02:20] <Keybuk> and wait another 10-15s
[02:21] <ogra_> done ...
[02:22] <Keybuk> ok, then hit ^D ... and once booted, send me your /var/log/dmesg
[02:22] <ogra_> ouch ...
[02:22] <ogra_> udevd socket: illegal seek
[02:23] <ogra_> and some other failures
[02:23] <Keybuk> yeah, that's ok
[02:24] <Keybuk> also mail me output of lspci -vvv
[02:25] <elmo> Kamion: around?
[02:27] <ogra_> Keybuk, on its way
[02:28] <Keybuk> thanks
[02:29] <ogra_> whee ...
[02:29] <ogra_> using_dma = 1
[02:29] <ogra_> hmm .... what changed ?
[02:30] <mdz> Keybuk: when do you expect to have a new udev upload ready?  sounds like you have a bunch of fixes queued up
[02:33] <ogra> hmm, 4:41 ... not a nice bootchart :p
[02:34] <Keybuk> mdz: tomorrow AM
[02:35] <ajmitch> heh
[02:35] <ajmitch> that sounds a little slow
[02:36] <ogra> it has the human factor ;)
[02:37] <ogra> (which indeed doesnt show up in the chart)
[02:39] <Keybuk> don't you have a long ogra bar in the gaps?
[02:40] <Keybuk> ... bed time for you, dude
[02:40] <ogra> heh, yes 
[02:41] <ogra> dog time before :)
[02:41] <Diablo-D3> has anyone booted with 2.6.15.2-2?
[02:43] <ogra> why should we, thats old cruft
[02:43] <ogra> 6.8 is recent
[02:45] <Diablo-D3> ogra?
[02:45] <ogra> wahhh ... oo.o looks worse than yesterday in my cdimage report :/
[02:45] <ogra> Diablo-D3, 2.6.15-6.8
[02:45] <Diablo-D3> argh, thats out now?
[02:46] <Diablo-D3> when did that happen?
[02:46] <ogra> thats sone days (1-2) old
[02:46] <Diablo-D3> wtf!?
[02:46] <ogra> *some
[02:46] <Diablo-D3> wait, does restricted modules have a seperate version number?
[02:46] <ogra> its from Thu,  1 Dec 2005
[02:47] <ogra> linux-restricted-modules-2.6.15 2.6.15.2-2
[02:47] <Diablo-D3> yup it does -_-
[02:48] <Diablo-D3> hrm
[02:49] <Diablo-D3> I wonder when dapper will get xorg 6.9-rcx 
[02:49] <Diablo-D3> or this mystical godlike 7.0 everyone is talking about
[02:50] <minghua> huh? aren't we using 7.0-rc now?
[02:50] <tseng> we are
[02:50] <Diablo-D3> the one thats supposed to cure cancer and bring peace to the middle east
[02:50] <Diablo-D3> diablo@infinity:~ $ apt-cache show xserver-xorg | grep Version
[02:50] <Diablo-D3> Version: 6.8.2-77
[02:54] <crimsun> that's a dummy package.
[02:54] <Diablo-D3> ... hrm.
[02:54] <crimsun> Look instead at xserver-xorg-core
[02:54] <Diablo-D3> Version: 1:0.99.3-0ubuntu6
[02:54] <Diablo-D3> so thats not quite helpful either
[02:55] <crimsun> X Window System Version 6.99.99.902 (7.0.0 RC 2)
[02:55] <crimsun> just head the log
[02:55] <Diablo-D3> ... lol I guess I could do that
[02:55] <Diablo-D3> I gotta go figure out why control-+/- doesnt work anymore
[03:02] <bmonty> elmo: please sync stardict from unstable, ok to drop ubuntu changes, thanks
[03:06] <ryanpg> so I'm told the two lists to join if testing dapper are ubuntu-devel and dapper-changes yes? and are there others?
[03:07] <ajmitch> ubuntu-devel-announce
[03:07] <ryanpg> k
[04:39] <Diablo-D3> The Matrix-XP, funny as hell: http://www.uni-duesseldorf.de/~ricke/matrix_xp/mxp_engl_l.zip
[05:02] <stub> Launchpad will be going down in 30 minutes time, which will also put the Ubuntu wikis into read only more. Estimated down time is 30 minutes.
[05:03] <desrt> stub; good luck.
[05:03] <Diablo-D3> now only if ubuntu bugzilla died too
[05:04] <LaserJock> stub: so the wiki.ubuntu.com will be read only for 30 min.?
[05:04] <stub> LaserJock: With luck, yes
[05:05] <LaserJock> stub: ok, I guess I will wrap up my editing ;-)
[05:47] <ajmitch_> morning sabdfl 
[05:47] <sabdfl> hia ajmitch_
[05:47] <sabdfl> erk
[05:47] <SEJeff> ogra: ping
[05:47] <sabdfl> EST not yet working for me
[05:49] <SEJeff> May I ask why my bug was closed on xscreensaver being reverted to the old dialog? It seriously takes away from the polish that I always brag on ubuntu for
[05:50] <LaserJock> SEJeff: yeah, I know what you mean. I was like "ewww" when I saw that the Ubuntu dialog was gone
[05:51] <Amaranth> I can't wait to get DSL again.
[05:51] <sabdfl> SEJeff, LaserJock, i expect it's just a merge from debian that needs to be cleaned up. we are testing gnome-screensaver too
[05:51] <Amaranth> This dialup connection is going down more than <insert insult>
[05:51] <SEJeff> I wouldn't be angry if the bug wasn't immediately closed with a "this isn't a bug" http://bugzilla.ubuntu.com/show_bug.cgi?id=20522
[06:11] <ispiked> desrt: ping
[06:11] <desrt> hello.
[06:12] <desrt> you're the guy who filed the battstat bug.
[06:12] <ispiked> desrt: I am. :)
[06:12] <desrt> i just wrote a patch against HAL to fix it
[06:12] <desrt> wanna test?
[06:12] <ispiked> desrt: tried to PM you, but freenode is blocking those from non-reg. users.
[06:12] <desrt> ispiked; freenode is evil.
[06:12] <ispiked> derekS: hrm... possibly. I was just going to ask why it doesn't read form "charging state: ".
[06:12] <ispiked> like as a last resort or something.
[06:13] <ispiked> damn.
[06:13] <ispiked> sorry derekS.
[06:13] <desrt> because it incorrectly assumes that the values it is provided with will be sane/correct :)
[06:13] <desrt> (which is incorrect in your case and many others)
[06:13] <desrt> the correct place for all of these work-arounds is in hal, though
[06:14] <ispiked> I thought I was using HAL, according to the troubleshooting part.
[06:14] <desrt> it's not so easy... the inside of battstat is a bit archaic
[06:14] <desrt> it was made to support apm/acpi backends directly
[06:14] <desrt> as such it doesn't have an idea of batteries 'charging' or 'discharging'
[06:15] <ispiked> alright.
[06:15] <Diablo-D3> desrt: eww
[06:15] <desrt> all it has is 'charging' and a zero or non-zero rate for discharge
[06:15] <fabbione> morning all
[06:15] <desrt> fabbione; word.
[06:15] <ispiked> desrt: fwiw, I haven't tried the cvs version of batstat to see if the bug exists there.
[06:15] <desrt> ispiked; very little has changed
[06:15] <desrt> ispiked; school has been kicking my ass lately... very little time for freesoftware
[06:15] <desrt> ispiked; (which is why it took me so long to respond to your bug)
[06:16] <Diablo-D3> desrt: thats easy to fix!
[06:16] <Diablo-D3> quit school!
[06:16] <ispiked> desrt: hopefully I can say the same as you next semester. :)
[06:16] <desrt> 4 more months.
[06:16] <ispiked> I've been slacking off waaaay too much. (first sem. or college)
[06:16] <desrt> jan-april is my last term as an undergraduate
[06:16] <mjg59> desrt: I've just submitted a patch for gdm, and I'm about to upload a new g-p-m that takes advantage of it
[06:16] <desrt> mjg59; elite.
[06:16] <desrt> mjg59; you know that gdm is maintained by queen elizabeth the second, right?
[06:17] <ispiked> mjg59: this related to me and desrt conversation?
[06:17] <desrt> ispiked; not really
[06:17] <mjg59> desrt: So I noticed
[06:17] <mjg59> So I've just put it in the Ubuntu bugzilla for now, and Seb can deliver it next time he's in London
[06:17] <Diablo-D3> wtf?
 mjg59; you know that gdm is maintained by queen elizabeth the second, right?
[06:17] <ispiked> desrt: anyway, how would I install batstat after compiing from cvs with the new patch applied?
[06:17] <Diablo-D3> wtf?
[06:17] <desrt> :)
[06:18] <desrt> ispiked; the patch is against HAL
[06:18] <ispiked> desrt: hrm...
[06:18] <desrt> oh.  i should probably provide you with an actual copy of the patch :)
[06:18] <desrt> http://desrt.mcmaster.ca/random/hal-rate.patch
[06:19] <desrt> ispiked; apt-get source hal
[06:19] <desrt> ispiked; then toss the patch into the patches dir
[06:19] <desrt> ispiked; and dpkg-buildpackage
[06:19] <desrt> ispiked; if all goes well you can then dpkg -i the resulting .deb
[06:19] <Diablo-D3> http://bugzilla.ubuntu.com/quips.cgi?action=show
[06:19] <Diablo-D3> hehehehee
[06:20] <Diablo-D3> scroll to the bottom
[06:20] <desrt> cute.
[06:20] <Diablo-D3> we really need a qdb setup for feenode
[06:21] <desrt> Diablo-D3; i didn't make that up :p
[06:21] <ispiked> desrt: dpkg-checkbuilddeps: Unmet build dependencies: cdbs libdbus-glib-1-dev (>= 0.35.2-0ubuntu3) libsysfs-dev libcap-dev doxygen intltool (>= 0.22)
[06:22] <desrt> ispiked; sudo apt-get build-dep hal
[06:25] <desrt> ispiked; also, fakeroot dpkg-buildpackage
[06:25] <desrt> ispiked; and in order to get the patch to apply cleanly you'll have to erase the first bit that modifies the ChangeLog
[06:25] <ispiked> fakeroot?
[06:25] <desrt> dpkg-buildpackage needs to (think that it is being) run as root
[06:26] <desrt> fakeroot fakes it
[06:27] <desrt> i think it has to do with being able to assign correct ownership to the files contained inside the .deb
[06:27] <Amaranth> err, i think i don't know how to read bootchary
[06:27] <Amaranth> bootchart
[06:27] <desrt> Amaranth; time flows left to right
[06:27] <Amaranth> because it looks like this guy is booting suse into a usable kde desktop in 15 seconds
[06:27] <desrt> Amaranth; the bar is when a process is active
[06:28] <desrt> got a url?
[06:28] <Amaranth> http://www.kdedevelopers.org/node/1664
[06:28] <ispiked> desrt: Trying patch debian/patches/hal-rate.patch at level 0...1...2...failure. :(
[06:28] <desrt> ispiked; did you remove the changelog part?
[06:28] <Amaranth> i guess KDE startup spends 1/3 of it's time in the linker
[06:29] <ispiked> desrt: yeah. let me double check.
[06:29] <Amaranth> they should love meeks' -Bdirect patch
[06:29] <desrt> Amaranth; this is just for logging into kde
[06:29] <Amaranth> oh
[06:29] <Amaranth> from kdm to usable desktop?
[06:29] <desrt> from invocation of 'startkde' to usable desktop
[06:30] <Amaranth> 15 seconds is horrible then
[06:30] <Amaranth> i guess that includes X though
[06:30] <ispiked> desrt: http://rafb.net/paste/results/70Ek5A44.html
[06:30] <desrt> ispiked; err. are you in breezy?
[06:31] <ispiked> desrt: yes. :(
[06:31] <desrt> eep.
[06:31] <desrt> that patch definitely won't work with breezy
[06:31] <ispiked> desrt: I can install dapper, but not tonight.
[06:32] <desrt> ispiked; you could try and manually merge the patch in
[06:32] <desrt> ispiked; but it's a freakin' minefield in there
[06:32] <ispiked> desrt: that, too.
[06:32] <ispiked> desrt: what do you mea?
[06:32] <desrt> ispiked; martin and i backported so much crap into breezy's hal :/
[06:32] <ispiked> desrt: oh. :(
[06:32] <desrt> and a lot of it modifies that file and that function in particular
[06:33] <desrt> don't do it just for testing a dumb patch :p
[06:34] <Amaranth> they aren't joking
[06:34] <desrt> heh.
[06:34] <Amaranth> my vmware player image stopped doing snapshot loading and the kernel is fubar
[06:34] <desrt> "dapper is actually fine here"
[06:34] <desrt> ok ya.. the kernel is interesting to say the least
[06:35] <ispiked> desrt: your patch makes sense, I'm willing to bet it'll work. :P
[06:35] <desrt> ispiked; i hope so :)
[06:35] <desrt> ispiked; i've mailed it off to the HAL folks to ask if i can commit it
[06:35] <Amaranth> wow, i've been connected more than 5 minutes
[06:36] <Amaranth> i think my dialup stopped sucking for the night
[06:42] <mjg59> Hmm.
[06:42] <mjg59> Other than something quite horrible happening in the kernel, that seemed to work
[06:45] <mjg59> Hurrah. Objective achieved without having to patch hal at all.
[06:45] <mjg59> Now I just need to worry about the KDE case. And the XFCE case. And, oh well.
[06:46] <desrt> from my understanding hal is suitably neutered by its not running as root
[06:46] <desrt> pitti++
[06:46] <mjg59> gdm, however...
[06:47] <mjg59> I've added two lines to gdm to check that the person requesting the suspend is on the current VT
[06:47] <mjg59> Which sorts out the idle suspend thing
[06:48] <desrt> probably even an improvement compared to what we had before
[07:01] <Diablo-D3> http://rss.slashdot.org/Slashdot/slashdot?m=2286
[07:02] <Diablo-D3> took long enough for slashdot to pick that story up
[07:04] <mjg59> Hm.
[07:04] <mjg59> So it works fine if I disable screen locking, but otherwise takes ages
[07:04] <mjg59> Which sounds like some sort of dbus breakage
[07:05] <zakame> rainy afternoon all :)
[07:05] <Diablo-D3> I wonder when women will think geeks are desierable.
[07:07] <LaserJock> probably when geeks stop thinking they are desirable. ;-)
[07:07] <Diablo-D3> LaserJock: we dont.
[07:08] <Amaranth> Diablo-D3: When they realize geeks make large piles of money.
[07:08] <Diablo-D3> Amaranth: except most of us dont
[07:08] <Diablo-D3> I sure as hell dont
[07:18] <dholbach> good morning
[07:23] <yi> daniels: i see that the xmodmap stuff was fixed in xorg 7.0RC3, is that coming to dapper anytime soon?
[07:23] <Amaranth> let's hope xorg does a mozilla and has rc3 end up being final ;)
[07:24] <yi> i don't think so, if you take a look at the master bug tracker there are quite a few still outstanding
[07:26] <Amaranth> shh!
[07:26] <Amaranth> let me dream
[08:18] <pitti> Good morning
[08:18] <ajmitch_> morning pitti 
[08:19] <pitti> Hey ajmitch_, how are you?
[08:19] <ajmitch_> good, yourself?
[08:19] <dholbach> hey pitti
[08:19] <pitti> fine
[08:20] <pitti> Hi dholbach 
[09:28] <infinity> Oh boy, new NVIDIA drivers!
[09:28] <infinity> Hot on the heels of me, like, updating the drivers.

[09:28] <infinity> Timing.  Mine.  Sucks.
[09:30] <minghua> poor infinity
[09:30] <infinity> I wouldn't complain, except that updating the orig.tar.gz for l-r-m takes FOREVER on my slow DS lline.
[09:30] <infinity> Like, over and hour to upload the new tarball after I roll it.
[09:30] <infinity> s/DS l/DSL /
[09:31] <infinity> s/and hour/an hour/ too.  Time to go sober up after my Saint Nick celebrations.
[09:36] <sivang> morning all
[10:02] <sivang> infinity: who's Saint Nick?
[10:03] <infinity> Saint Nicholas.
[10:07] <sivang> infinity: eh
[10:08] <mantiena> doko, hi
[10:08] <mantiena> doko, are you near the computer ? I have few question about OpenOffice.org plans in Ubuntu
[10:10] <doko> ?
[10:11] <zyga> morning
[10:12] <pitti> hi zyga 
[10:14] <sivang> hey pitti 
[10:14] <sivang> , zyga 
[10:14] <pitti> hi sivang 
[10:18] <dholbach> ogra: try the patch from Mithrand1r - he fixed a fileselector amd64 issue
[10:18] <ogra> dholbach, do you really want to document every observation while working on a package ? 
[10:18] <dholbach> no
[10:19] <ogra> you wont come around to do your merges if you have to do paperwork all the time ;)
[10:19] <dholbach> but judging by the bug report, i thought "he's too busy" and i did the merge on my own
[10:19] <ogra> i grabbed that bug on thursday or friday ...
[10:19] <dholbach> ok
[10:19] <dholbach> sorry, didnt see that
[10:19] <dholbach> try the patch from 0.75-7ubuntu2
[10:20] <dholbach> Mithrand1r: fixed a fileselector issue on amd64
[10:20] <dholbach> oops, drop the ":"
[10:20] <ogra> ah, i didnt try on other arches yet 
[10:21] <ogra> thats 40_gcc40_64bit_fixes, right ? 
[10:22] <dholbach> ogra: should be... i read it in the changelog - check if there's something about fileselector stuff in it
[10:22] <dholbach> hey mvirkkil 
[10:22] <dholbach> hey mvo
[10:23] <ogra> yup, matches
[10:24] <mvo> hey dholbach !
[10:24] <seb128> mvo: what did you do to him?
[10:25] <seb128> hey mvo :)
[10:26] <mantiena> hi mvo 
[10:28] <mantiena> :)
[10:29] <mantiena> mvo, I wanna talk with you about gksu and gdebi backports to breezy (I'm main developer of Ubuntu-based Linux distribution - look at http://baltix.akl.lt )
[10:29] <mantiena> mvo, could you help me ?
[10:31] <mvo> mantiena: a start would the mail I send to the backports people. it explains what needs to be done to backport gdebi
[10:31] <mvo> if you /msg me your mail address, I'll do that
[10:33] <sivang> morning mvo :)
[10:33] <mantiena> mvo, my email is mantas@akl.lt, but I think I simply could  read backports mailing list archive, I'm right ?
[10:35] <mvo> mantiena: hm, good point :)
[10:35] <mvo> mantiena: http://lists.ubuntu.com/archives/ubuntu-backports/2005-November/000460.html
[10:36] <mvo> this is where it starts
[10:36] <mvo> http://lists.ubuntu.com/archives/ubuntu-backports/2005-November/000464.html
[10:37] <mvo> mantiena: if you backport it, plesae let me know about the feedback from your users. it's still pretty fresh software, I would be interessted in their feedback (and bugs found etc)
[10:37] <mantiena> mvo, thank you very much
[10:37] <mvo> mantiena: let me know if you have any other questions :)
[10:37] <crimsun> elmo: please sync pyserial from Sid (ok to override Ubuntu changes), thanks
[10:47] <infinity> mvo : I just installed gdebi and tested it on the first two .debs I could find, and the version handling is a bit... Annoying.
[10:48] <infinity> mvo : No option to force a downgrade or force reinstalling.  I assume that's intentional, but maybe if you hid the force options in the menu or something..?
[10:49] <mvo> infinity: I can add it, I left it out to minimize the "shoot-in-your-food" risk
[10:50] <infinity> Nice typo...
[10:51] <infinity> And yeah, maybe it's best for a pretty GUI tool to not allow too much foot-shooting.
[10:51] <infinity> OTOH, people downloading random debs and installing them with a GUI are already a bit scary, so we should likely allow them to swap older versions easily, etc.
[10:51] <mvo> re-install seems to be useful, downgrading ... maybe sometimes (I heard about people using multiple versions of cedega because sometimes a older one works better for a certain game etc)
[10:52] <infinity> (Say you're downloading someone's pre-packagaged device driver or something, you find out the new one doesn't work well, you want to downgrade to the old package you have...)
[10:52] <infinity> But I was definitely expecting it to allow me to reinstall.  I had to download something I don't have installed just to test the app. :)
[10:53] <mvo> infinity: heh :) did you download something that needed dependency resolution too? to give it a bit of a real test ?
[10:53] <infinity> Granted, Debian policy (and people packaging .debs in general) doesn't really make much noise about downgrading, and it's an "at your own risk" deal, but MOST packages downgrade smoothly anyway.
[10:53] <infinity> mvo : I will.  Hey, I've only had it installed for 6 minutes. :)
[10:54] <mvo> downgrading is something that I never liked because of it's potential to break in spectacular ways
[10:54] <mvo> all the scary things that postins scripts do to "upgrade" stuff 

[10:56] <infinity> Hence why I said "most". :)
[10:56] <mvo> yeah :)
[10:56] <infinity> But I'm not sure "learn to use dpkg" is the right answer to "I want to downgrade my package" either.
[10:57] <mvo> yes, agreed. I need to ponder a bit how to present it in the gui
[10:57] <infinity> So, having force options in the menus (users seem to instinctively know that stuff in menus is "scarier" and more "advanced" than stuff on shiny buttons) might go okay...
[10:57] <infinity> With blinking warnings when you attempt it.
[11:06] <mantiena> mvo, I've read your email about gdebi in backports mailing list, but there are no info about backporting gksu :(
[11:07] <doko> fabbione: that works for me: apt-get install openoffice.org2-core-experimental openoffice.org2-common openoffice.org2-l10n-en-us
[11:07] <doko> I need the two binary-all packages, or else apt-get complains
[11:08] <fabbione> doko:
[11:08] <fabbione> The following packages will be REMOVED:
[11:08] <fabbione>   firefox firefox-gnome-support gnome-app-install yelp
[11:08] <fabbione> doko: i will try again later
[11:09] <mvo> mantiena: oh, you want to backport it not because it's a depedency? but because it's cooler and shinnier than the version in breezy :) ?
[11:09] <fabbione> perhaps my mirror is still not 100% in sync
[11:09] <fabbione> but it doesn't explain why ppc install fine
[11:09] <mantiena> doko, what are OpenOffice.org plans in Ubuntu dapper and breezy backport ?
[11:09] <dholbach> fabbione: does that system have a bunch of other held back packages?
[11:09] <mvo> mantiena: well, you will also need to backport libgksu1.2, and libgksuui1.0 (in addition to gksu). but that should be straightforward and only a matter of recompiling the sutff
[11:09] <fabbione> dholbach: not that i know of
[11:09] <dholbach> ok
[11:10] <fabbione> 0 upgraded, 5 newly installed, 4 to remove and 0 not upgraded.
[11:10] <fabbione> so no
[11:10] <dholbach> *nod*
[11:10] <doko> mantiena: make it work
[11:10] <mantiena> mvo, sort of, users of Baltix distribution wanna have *working* choice between sudo and separate root mode
[11:10] <mantiena> doko, :)
[11:11] <fabbione> doko: anyway don't get too much headacke now
[11:11] <fabbione> i will try to rsync my mirror again
[11:12] <mantiena> mvo, what about these problems: udo dpkg -i /tmp/libgksuui1.0-1_1.0.7-1_i386.deb
[11:12] <mantiena> dpkg: considering removing libgksuui1.0-0 in favour of libgksuui1.0-1 ...
[11:12] <mantiena> dpkg: no, cannot remove libgksuui1.0-0 (--auto-deconfigure will help):
[11:12] <mantiena>  python2.4-gnome2-extras depends on libgksuui1.0-0
[11:12] <mantiena>   libgksuui1.0-0 is to be removed.
[11:12] <mantiena> dpkg: regarding .../libgksuui1.0-1_1.0.7-1_i386.deb containing libgksuui1.0-1:
[11:12] <mantiena>  libgksuui1.0-1 conflicts with libgksuui1.0-0 (<< 1.0.6-1)
[11:12] <mantiena>   libgksuui1.0-0 (version 1.0.5-1ubuntu2) is installed.
[11:14] <mvo> oh, right. python2.4-gnome2-extras will need a recompile as well
[11:15] <mvo> as well as gnome-system-monitor and gnome-volume-manager
[11:15] <pitti> oh, right
[11:16] <mantiena> mvo, maybe I should simply recompile the same versions of python2.4-gnome2-extras, gnome-volume-manager and gnome-system-monitor with backported libgksuui1.0-1-dev ???
[11:17] <pitti> Hi Keybuk, how are you
[11:17] <mvo> mantiena: yes, absolutely
[11:19] <Keybuk> heyhey
[11:20] <mvo> HUG DAY!
[11:20] <Keybuk> it's always hug day in keybukland
[11:21] <pitti> that always reminds me of soap operas
[11:21] <siretart> mass hugging?
[11:22] <mantiena> mvo, maybe gksu from dapper could work with libgksuui1.0-0 after recompilation ???
[11:22] <TerminX> is there an easy fix for gnome-settings-daemon segfaulting with the xklavier error?  didn't restart GNOME for a couple of weeks, heh...
[11:22] <pitti> ok, with 169 people in the channel, we need (169*170)/2 hugs
[11:22] <zyga> pitti: d'oh
[11:23] <pitti> 14365
[11:23] <zyga> for persion in... : hug(person) everone
[11:23] <zyga> (and then discard the duplicates)
[11:24] <Kinnison> for A,B in everyone.cross(everyone): hug(A,B)
[11:24] <pitti> Kinnison: that's twice as much as necessary
[11:24] <pitti> although hugging people twice can't hurt :)
[11:24] <Kinnison> pitti: More hugs == better
[11:24] <mvo> mantiena: I'm not sure, it may be worth a try. but IIRC the api changed
[11:26] <zyga> Kinnison: while 1: hug(everyone) ?
[11:26] <Keybuk> for (;;) hug (everyone);
[11:27] <siretart> looks similar to a fork bomb: for(;;) fork(); *g*
[11:27] <Treenaks> is it hug day again?
[11:28] <pitti> hug([Person|Others] ) :- hug (Person), hug(Others); hug(Person)
[11:28] <zyga> heheheh
[11:28] <pitti> hug(Person)
[11:28] <pitti> -? hug("#ubuntu-devel").
[11:28] <Keybuk> what language is that?  Haskell?
[11:28] <sivang> pitti: what is that?
[11:28] <pitti> Prolog
[11:28] <siretart> prolog
[11:29] <sivang> oh prolog
[11:29] <zyga> for(;;) if (fork() == -1) hug();
[11:29] <sivang> pitti: what's that :- thingy?
[11:29] <pitti> oops, the '; hug(Person)
[11:29] <pitti> ' was wrong
[11:29] <mantiena> mvo, btw, could you tell what are main improvements from users point of view in gksu from dapper comparing to gksu in breezy ? Maybe it would be better simply to patch config file in gksu from breezy to use sudo mode as default ?
[11:29] <pitti> sivang: a query to the problem solver
[11:29] <zyga> does anyone know Henrik Nilsen Omma?
[11:29] <ogra> sivang, a smiley without mouth ;)
[11:30] <sivang> ogra: yes, I Was going to say that - but I was very curious to know if it had some sort of meaning in the language, or pitti had just made a mistake.
[11:30] <Kamion> zyga: yes, he's a Canonical employee; why?
[11:30] <pitti> sivang: no, it's just the counterpart of the '$' in shell
[11:30] <zyga> Kamion: I'd like to talk to him about an interesting project, I could mail him but talking on irc is faster
[11:31] <ogra> zyga, he's not around, mail him
[11:31] <zyga> k, thanks
[11:31] <sivang> zyga: what other world taking plans are you plotting ? :-)
[11:31] <pitti> sivang: oh, no, sorry; the -? is the prompt; :- is 'reverse implication'
[11:31] <zyga> sivang: sinister, with bloodbaths and screaming :-)
[11:31] <pitti> sivang: i. e. "hug([Person|Others] )" is true, when "hug (Person)" is true and "hug(Others)" is true
[11:31] <mvo> mantiena: just backporting the patch is probably the easiest option
[11:31] <Keybuk> mmmm, bloodbaths
[11:32] <Keybuk> tricky, you have to keep them warm, otherwise it congeals and you get a crust
[11:32] <zyga> Keybuk: then with hellfires too
[11:32] <Keybuk> brimstone makes a good pummice
[11:32] <zyga> anyway back to work
[11:33] <sivang> Keybuk: dude, that was ick
[11:33] <siretart> ((define hug persons) (if (not (eq persons 'nil)) (begin (hug-person (car persons)) (hug (cdr persons))))))
[11:33] <sivang> siretart: ok, this I can read :) lisp
[11:33] <zyga> okay now anyone with a Basic or Java hugging around? ;-)
[11:33] <siretart> sivang: scheme, (a lips dialect)
[11:33] <sivang> siretart: cool
[11:34] <zyga> siretart: scheme? I thought scheme has eq?
[11:34] <pitti> zyga: I could still offer x86 and Atmel AVR assembler...
[11:34] <zyga> (eq with ?)
[11:34] <sivang> pitti: Atmel AVR assembler ?
[11:34] <pitti> sivang: I programmed these a lot during my university times; it's a microcontroller for embedded devices
[11:35] <mantiena> mvo, you are talking only about gconf patch, which sets default mode to sudo ?
[11:35] <mvo> mantiena: yes
[11:35] <sivang> pitti: cool :) 
[11:37] <mantiena> mvo, hehe, gksu in breezy uses /etc/gksu.conf, not gconf :-P
[11:41] <mantiena> mvo, maybe you know why kov decided to change simple config file to gconf ?
[11:43] <tepsipakki> hmm, my gam_server seems to be eating memory (breezy), how could I debug that?
[11:43] <tepsipakki> after two days it had 1gig
[11:44] <mantiena> doko, did you tried to build OOo any 2.0.1 prerelease or release candidat on ubuntu ?
[11:44] <mantiena> tepsipakki, 8-)
[11:44] <infinity> mantiena : The current OOo2 in dapper is a 2.0.1 pre-release.
[11:46] <ogra> argh ... why do debian maintainers not use the upstream versioning scheme and make 0.7.5 be 0.75 ? 
[11:47] <mantiena> infinity, hehe, I didn't noticed ;)
[11:47] <Keybuk> ogra: sometimes it's because they think upstream are going to change the versioning scheme
[11:47] <Keybuk> Debian maintainers go through all sorts of evil hacks to avoid epochs
[11:47] <ogra> tsk ...
[11:47] <Keybuk> ie. the Debian udev packages were versioned 0.<upstream>
[11:47] <Keybuk> which is effectively a 0: epoch anyway
[11:47] <ogra> i can understand the aim to avoid epochs, but thats just silly
[11:47] <zyga> epochs?
[11:48] <Kamion> zyga: <number>: at the start of a version number; is the most significant part of the version number
[11:48] <Kamion> so 1:0 > 0:99999.9.9
[11:48] <siretart> zyga: short: run away on sight ;)
[11:49] <mantiena> infinity, it seems OOo 2.0.1RC was uploaded few hours ago ;)
[11:49] <Kamion> no, not necessarily
[11:49] <Kamion> its correct use is when upstream changes their versioning scheme, and you need to recover
[11:49] <sivang> Kamion: also used to sort version conflicts, or is that wrong?
[11:49] <Kamion> some people use it for rollback, but that's best avoided, especially when libraries are concerned (because you confuse the hell out of shlibdeps)
[11:49] <Kamion> sivang: what do you mean?
[11:50] <mantiena> Who is resposible for changelogs pool  ( http://packages.ubuntu.com/changelogs/pool ) ? it misses almost all changelogs from dapper :( 
[11:50] <sivang> Kamion: sorry, I think I got the question wrong and confused between another term.
[11:51] <Kamion> mantiena: packages.ubuntu.com is an unofficial service; there is a contact address listed on its front page
[11:51] <mantiena> Kamion, ok
[11:52] <mantiena> Kamion,  frank@lichtenheld.de ?
[11:52] <Kamion> (well, by unofficial I mean not provided by Canonical, and its maintainer isn't generally here; it's maintained by the same guy who does a lot of the work on packages.debian.org)
[11:52] <Kamion> mantiena: yes
[11:52] <Keybuk> gah, I still can't train my fingers not to put the "z" in "xzf"/"czf"/"tzf"
[11:53] <pitti> Kamion: for tar? :)
[11:53] <Keybuk> right
[11:53] <mvo> mantiena: I run the changelog thing
[11:54] <Kamion> mvo: oh, huh, you run the one on packages.ubuntu.com? sorry, didn't know that
[11:54] <mvo> mantiena: we have our changelogs at changelogs.ubuntu.com
[11:54] <mvo> Kamion: no problem, I only dothe changelog bits (because update-manager uses them)
[11:55] <mvo> Kamion: I don't run packages.ubuntu.com, no
[11:56] <Kamion> http://packages.ubuntu.com/changelogs/ appears to be != http://changelogs.ubuntu.com/changelogs/; I assume the former is an out-of-date mirror of the latter
[12:02] <ogra> Kamion, did you already try a livefs build ? just to warn you there seems something wrong with xauth, i cant get a xserver to run on my thin clients over here ...
[12:03] <ogra> havent found out what it is though
[12:04] <mantiena> mvo, so, I need to write email to frank@lichtenheld.de and ask him to change changelogs URL in packages.ubuntu packages.ubuntu.com, right ?
[12:05] <mvo> mantiena: probably, I wonder if we shouldn't purge packages.u.c/changelogs then 
[12:06] <Kamion> ogra: there are other problems with the live CD
[12:07] <Kamion> ogra: I haven't got remotely that far yet
[12:07] <ogra> Kamion, yes, just a warning that there is more broken ...
[12:07] <mantiena> doko, maybe you know are there some plans to backport OOo 2.0.1 RC or final version to breezy ?
[12:08] <ogra> i'll try to find out the reason sicne i need my thin clients for testing, but there is no obvious indicator ...
[12:08] <ogra> mantiena, thats something to ask the backports team :)
[12:10] <mvo> seb128: why does poppler-utils conflict with xpdf-utils? this makes xpdf more or less uninstallable (without removing a bunch of stuff like cupsys)
[12:11] <pitti> mvo: file conflicts (/usr/bin/pdf2ps etc.)
[12:11] <seb128> mvo: ask doko, he didn't those change, I just did the sync
[12:11] <ogra> mantiena, usually we only care for the upcoming version and apply fixes if the backports team approaches us ...
[12:11] <mantiena> ogra, ok
[12:11] <pitti> mvo: but it should replace/provide xpdf-utils
[12:11] <seb128> s/didn't/did/
[12:11] <seb128> mvo: why do you need xpdf for?
[12:12] <seb128> s/why/what/
[12:14] <mvo> seb128: I don't need it, but I got a mail about it and I think we should still provide it (if possible). I sometimes get better results with xpdf than evince
[12:14] <doko> mvo: it has the same utilities, yes a provides would be ok
[12:14] <mvo> pitti: cupsys explicitly depends on poppler-utils
[12:15] <mvo> doko: so I can change xpdf-utils to provide poppler-utils?
[12:16] <pitti> mvo: shouldn't it be the other way round?
[12:16] <doko> pitti: yes
[12:17] <mvo> pitti: probably. I don't know why cupsys explicitly depends on poppler-utils
[12:17] <pitti> mvo: to make sure to not use xpdf-utils
[12:17] <pitti> mvo: and to keep xpdf-utils in universe
[12:18] <mvo> pitti: ok, but that is probably the root of the problem. if people want to install xpdf now, this require them to remove poppler-utils, this removes cupsys. people will not want to do this
[12:18] <pitti> mvo: hm, what about changing xpdf to Depends: xpdf-utils | poppler-utils?
[12:19] <doko> why not have xpdf depend on popple-utils as an alternative?
[12:19] <pitti> hm, well, a poppler-utils Provides: xpdf-utils should work as well
[12:19] <opi> Oi
[12:22] <mvo> pitti: xpdf uses a versionized dependency on the exact version for xpdf-utils. is it wise to add "|poppler-utils" in this case? assuming the xpdf-utils=$ver is there for a reason etc?
[12:22] <pitti> oh, uh
[12:22] <mvo> yeah :/
[12:22] <mvo> pitti: is the cupsys dependency for the upgrade case? 
[12:22] <pitti> so the provides wouldn't work
[12:23] <mvo> yes
[12:23] <pitti> mvo: cupsys needs pdf2ps; debian uses xpdf-utils, we use poppler-utils to confine the code to the poppler lib
[12:25] <mvo> pitti: would poppler-utils|xpdf-utils in cupsys be a option?
[12:25] <pitti> mvo: yes,  in this order
[12:25] <pitti> mvo: how urgent is this? shall I do an upload now just for that?
[12:26] <mvo> pitti: not really urgend, if you could just remember it for the next upload (I can file a bug too if you want)
[12:26] <pitti> mvo: I'll fix it here right now
[12:26] <mvo> thanks!
[12:27] <pitti> mvo: odd though, I do have xpdf-reader installed
[12:27] <pitti> mvo: since evince crashes all over the place for me
[12:27] <pitti> mvo: ah, you tried to install 'xpdf', not 'xpdf-reader', right?
[12:27] <mvo> yes
[12:28] <seb128> pitti: could you please send me a backtrace for this evince crasher
[12:28] <pitti> seb128: will do, using xpdf was just a quickfix when I edited the diploma thesis of my gf
[12:28] <seb128> pitti: we can't fix issues not reported, and some users are likely to have your issue as well
[12:28] <pitti> right, I didn't forget about it
[12:28] <seb128> thanks
[12:29] <lifeless> mvo: I emailed you the trace you wanted
[12:29] <pitti> it doesn't seem to like changing the PDF file while it is opened
[12:29] <mvo> lifeless: yes, thanks. I just answered
[12:31] <lifeless> mvo: sweet, thanks
[12:32] <mvo> cheers
[12:34] <torkel> pitti: re USN-224-1, do you know if any of the CVE's are still relevant for heimdal, or are they already fixed in heimdal?
[12:35] <pitti> torkel: I would assume that heimdal in warty and hoary is still vulnerable
[12:35] <pitti> torkel: I didn't check thoroughly yet, though (still on my list, but low prio)
[12:36] <pitti> torkel: the newer three CVEs for krb5 were specific to MIT kerberos
[12:36] <pitti> torkel: but the two telnet vulns are likely to affect heimdal as well
[12:38] <pitti> torkel: but heimdal-clients is in universe as well, so unless somebody beats me to it (or gives me a debdiff :) ), it won't happen quickly
[12:39] <torkel> pitti: you did an update of heimdal in September, no announcement though
[12:39] <torkel> pitti: https://launchpad.net/distros/ubuntu/+source/heimdal/+bug/1176
[12:39] <pitti> torkel: oh, right, http://people.ubuntu.com/~pitti/ubuntu-cve/fixed.html says that heimdal is fixed in warty and hoary
[12:40] <pitti> torkel: that update was done by a MOTU security dude, that's probably why I don't remember
[12:41] <torkel> pitti: can't say I consider myself a MOTU :-)
[12:54] <seb128> pitti: I've uploaded a fixed evince for this crash on refresh bug to breezy-updates/dapper
[01:05] <pitti> seb128: cool, thanks
[01:05] <pitti> seb128: you rock :)
[01:05] <seb128> np, thanks ;)
[01:05] <seb128> (you too)
[01:06] <seb128> k, time to grab some food
[01:06] <pitti> enjoy
[01:09] <dholbach> me too
[01:14] <pitti> Hi jbailey 
[01:14] <jbailey> Heya Martin!  How goes?
[01:15] <pitti> jbailey: pretty fine - I mess up cdbs gnome.mk even further :)
[01:16] <jbailey> Excellent!
[01:16] <jbailey> It probably needs some tough love. =)
[01:16] <pitti> I'm so much not proud of this shell hack, but it avoids touching ~100 packages, so what...
[01:17] <jbailey> Shell hack? =)
[01:17] <pitti> jbailey: look at the existing gnome.mk to see what I mean
[01:17] <pitti> jbailey: the blob to update the pot file at build
[01:18] <jbailey> Ahahha.
[01:18] <jbailey> Fun. =)
[01:18] <pvanhoof> Does somebody know wheter I can find a precompiled Transmeta Crusoe TM5800 kernel? I'm trying to get Ubuntu breezy working on a Xybernaut Atigo
[01:18] <jbailey> Does this mean that Rosetta isn't expected to export anytime soon?
[01:18] <pvanhoof> of course the standard 386 kernel works ..
[01:18] <pitti> jbailey: what does that have to do with Rosetta?
[01:18] <jbailey> pitti: Isn't this the scrape for Rosetta?
[01:18] <pvanhoof> just wondering whether there's kernel binaries (I'd dislike having to hassle with crosscompilers bla)
[01:19] <pitti> jbailey: (I currently add updating .desktop files in gnome.mk)
[01:19] <pitti> jbailey: right, it is; it'll stay as it is :)
[01:19] <jbailey> pvanhoof: I think it's unlikely.  If such a target really has obvious wins, then it might be worth talking to Ben about.
[01:19] <jbailey> pvanhoof: But he'll probably want profile data showing how it's an improvement.
[01:20] <pvanhoof> jbailey, to get it officially supported by ubuntu you mean?
[01:20] <pitti> jbailey, seb128: btw, IMHO gnome.mk really belongs into gnome-pkg-tools...
[01:20] <jbailey> pvanhoof: Right.  I try to discourage people fro doing anything to the kernels if I can.
[01:20] <pvanhoof> official support isn't extremely important for my case, I'd be glad with a kernel image that would work
[01:20] <pvanhoof> I understand
[01:21] <jbailey> pvanhoof: As soon as you replace the kernel, it's not longer a supportable version of Ubuntu.  If you have a serious need, it's best to try and get Ubuntu bent to your needs.  Sometimes we can accomidate, sometimes not.
[01:21] <pvanhoof> but atm I've installed breezy on the device. X11 works, the USB doesn't and the touchscreen doesn't. And it's extremely slow at startup. So my idea was to try with a transmeta kernel
[01:21] <jbailey> pvanhoof: For boot speed slowness, best to try dapper.
[01:21] <pvanhoof> is it stable atm? By that I mean, will it boot?
[01:22] <jbailey> The other items just sound like real bugs that ought to be filed.
[01:22] <pvanhoof> some guys told me to hold because of kernel upgrades
[01:22] <jbailey> It depends how much pain you're willing to risk.  It booted for me 20 minutes ago, fully upgraded.
[01:22] <pvanhoof> yes, indeed. I'm going to file those issues as bugs
[01:22] <jbailey> However, there are quirks.
[01:22] <jbailey> Like, networking doesn't fire up on its own.  You have to ifup it right now.
[01:22] <pvanhoof> what about the quirks :)? I have a dapper of last week on this laptop, no quirks
[01:23] <pvanhoof> ah that's an imporant issue .. you see
[01:23] <jbailey> xscreensaver seems to hang my machine
[01:23] <pvanhoof> I don't have a keyboard nor touchscreen
[01:23] <pvanhoof> so if the network doesn't start, I can
[01:23] <pvanhoof> t use the device
[01:23] <pvanhoof> :)
[01:23] <jbailey> and if I type too fast for too long, X hangs.
[01:23] <pvanhoof> okay
[01:23] <pvanhoof> going to wait with dapper then
[01:23] <pvanhoof> :P
[01:23] <jbailey> Everything else is perfect so far ;)
[01:24] <pvanhoof> I think slowness is because it's booting from a compact flash
[01:24] <jbailey> I haven't tried the keyboard problems yet since the xinput update that came recently.  It was usually about 20 or 25 minutes of nethack or writing long emails that would kill it.
[01:25] <Keybuk> BenC: about?
[01:25] <pvanhoof> I'm guessing the ubuntu boot isn't optimized for booting from a flash disk
[01:25] <Keybuk> is there something I need to do to upstream kernel sources to make them work with an initramfs?
[01:25] <pvanhoof> where it would be better to load as much as possible into ram, rather than reading things random
[01:26] <Robot101> pvanhoof: reading a flash randomly is surely going to be better than reading disk randomly? seek times are constant on flash.
[01:26] <Robot101> pvanhoof: I think it's more that flash is very slow. :)
[01:26] <Diablo-D3> hey man
[01:26] <Diablo-D3> its not that slow
[01:26] <jbailey> Keybuk: No.
[01:26] <jbailey> Keybuk: Are you having troubles?
[01:27] <pvanhoof> Robot101, not sure, a fsck was blazingly fast
[01:27] <Diablo-D3> 20meg/sec reads.
[01:27] <Diablo-D3> thats like... a slow harddrive.
[01:27] <Keybuk> jbailey: yes, it appears I need to add "initrd /..." to the grub menu.lst :p
[01:27] <pvanhoof> Robot101, an fsck was much faster than booting ubuntu .. 
[01:27] <Diablo-D3> but still a fuckload faster than a cdrom
[01:27] <Robot101> pvanhoof: fscks seek a lot but don't read much
[01:28] <jbailey> Keybuk: It's an excellent start.  Or you can embed it in the data segment of the kernel. =)
[01:28] <pvanhoof> I see
[01:28] <jbailey> Booting at what stage?
[01:28] <Robot101> pvanhoof: booting seeks a lot and reads a lot, it's the latter that will suck on flash. :)
[01:28] <jbailey> if it's from grub, you're getting non-DMA access to a slow flash device.
[01:28] <jbailey> It should suck quite badly.
[01:29] <pvanhoof> well, the "Loading kernel" part isn't fast but also not extremely slow
[01:29] <pvanhoof> it's rather after gdm started, loading the desktop. And loading the modules
[01:29] <pvanhoof> but
[01:30] <pvanhoof> I think the modules is slow because the uhci device fails (the slower usb controller)
[01:30] <Keybuk> jbailey: we found the cause of the IDE strangeness anyway
[01:30] <pvanhoof> the kernel module is retrying etc etc
[01:30] <Keybuk> now when I modprobe alim15x3 (or piix, or via83cxx, etc.) they all find the disks themselves
[01:30] <Keybuk> you don't need to load ide-generic
[01:31] <mhz> jdub: ping
[01:31] <pvanhoof> and about the touchscreen, when I cat /dev/ttyS0 and tap the screen .. I see characters
[01:32] <pvanhoof> but using that device in X11 doesn't really work
[01:32] <pvanhoof> so trying to get that working .. is there a way to detect the protocol?
[01:33] <pvanhoof> it's using a lot '/' characters when moving (my finger accross the screen)
[01:33] <jbailey> Keybuk: Ah.  Is kmodprobe picking them up now?
[01:33] <jbailey> Keybuk: When I was doing my tests before I couldn't seem to get kmod to fire.
[01:33] <jbailey> Andres always said that it was supposed to work, though.
[01:34] <Keybuk> jbailey: dunno about kmodprobe
[01:35] <Keybuk> but loading the right ide driver (with udevplug) causes the disks to be detected
[01:35] <Keybuk> and fires off uevents for each primary block device and udev picks the right ide-cd/disk/etc. module to load
[01:35] <Keybuk> so modprobe alim15x3 does the right thing for me (with udev running) ... I don't need to modprobe ide-generic to kick it in the balls
[01:36] <Keybuk> and, in fact, loading ide-generic does absolutely nothing -- it's unused and can be rmmod'd again
[01:36] <jbailey> That sounds right.
[01:36] <Keybuk> yup
[01:36] <Keybuk> do you know what I did to make it work right? :p
[01:36] <jbailey> Nice, glad that's all sorted out.
[01:37] <jsgotangco> hello
[01:37] <jbailey> Keybuk: Mmm..  Replace udev with upstram?
[01:37] <Keybuk> nope
[01:37] <jbailey> jsgotangco: g'day
[01:37] <Keybuk> replaced the kernel with upstream :p
[01:37] <Keybuk> it's a bug in our patch set
[01:37] <jbailey> Eh?
[01:37] <Keybuk> upstream, vanilla, 2.6.15-rc5 works exactly as intended
[01:37] <jbailey> Oh, hmm.
[01:38] <Keybuk> loading a particular ide driver scans and takes ownership of the disks
[01:38] <jbailey> I don't envy you your next 2 days. =)
[01:38] <Keybuk> its our kernels that are broken
[01:39] <jbailey> The patch has quite likely been there since at least warty, and possibly slightly before.
[01:39] <jbailey> Since I think I spoke to Andres about this at UDU
[01:39] <Keybuk> yup
[01:39] <Keybuk> it's Herbert Xu
[01:39] <fabbione> modular-ide?
[01:40] <Keybuk> fabbione: yeah
[01:40] <fabbione> it has been in Debian for ages
[01:40] <Keybuk> it's bust
[01:40] <fabbione> but upstream has been looking at it
[01:40] <jbailey> I keep forgetting we had him touch our kernel at one point, didn't we?
[01:40] <fabbione> and merged a bunch of the bits
[01:40] <Kamion> jbailey: he was contracted to maintain it for some time
[01:40] <Kamion> even after fabbione took over, he was still doing security maintenance
[01:40] <Keybuk> what was it actually supposed to do?
[01:40] <Keybuk> the ide drivers are modules without it
[01:40] <fabbione> Keybuk: no they are not
[01:41] <fabbione> some stuff might build as module
[01:41] <jbailey> Kamion: Ah neat.  At some point while there's still institutional memory for it, a big chart should be made of who touched what and caused what to happen when.
[01:41] <fabbione> but they don't work
[01:41] <Keybuk> right
[01:41] <Keybuk> well, nothing works with this patch :p
[01:41] <fabbione> the patch did attempt to fix that
[01:41] <Keybuk> so I guess that's an improvement of a sort <g>
[01:41] <Kamion> jbailey: hmm, I wonder how to get that started
[01:41] <Kamion> it would already be enormous
[01:42] <Keybuk> yup, the warty kernel exhibits the same bug
[01:42] <fabbione> Keybuk: the major issue is that you can't even solve it the other way
[01:42] <fabbione> if you don't make modules
[01:42] <Keybuk> "the other way" ?
[01:42] <fabbione> if you revert the patch
[01:42] <fabbione> you endup to build-in a bunch of ide drivers
[01:42] <fabbione> that as a consenque you will have no control over their init sequence
[01:43] <fabbione> so you lose
[01:43] <fabbione> in one way or another
[01:43] <Keybuk> but this patch does exactly that
[01:43] <Keybuk> it disables the init sequence of every driver
[01:43] <Diziet> `Newsflash: Xen 3.0.0 has been released!'  So is it stable ?
[01:43] <fabbione> Diziet: no
[01:43] <Kamion> argh, kernel-image-*-di still provides ext2-modules
[01:43] <jsgotangco> we wish
[01:44] <fabbione> it's a cvs snapshot randomly tagged as xen 3.0
[01:44] <Keybuk> so you also have no control over their init sequence, because they don't have one
[01:44] <fabbione> Kamion: i can fix that...
[01:44] <fabbione> Kamion: what arches?
[01:44] <Diziet> fabbione: !
[01:44] <Keybuk> instead ide-generic does the init'ing and then you're at hash-table luck as to which driver wins the device
[01:44] <jbailey> Kamion: No idea.  About the time I came on, we started actually leaving audit trails of what all we were doing with the specs and such.  It would have to have someone with a history bent who's interested in the project to convince others to be interested, I guess.
[01:45] <fabbione> Keybuk: -> blacklist my friend :)
[01:45] <pitti> $(patsubst %,binary-install/%,$(DEB_PACKAGES)) :: binary-install/%:
[01:45] <pitti>   -- jbailey, I love cdbs...
[01:45] <Keybuk> fabbione: we can't blacklist ide-generic
[01:45] <Keybuk> which is the principal module that seems to win :D
[01:45] <fabbione> Keybuk: do in such a way to always try it as last resource?
[01:46] <Keybuk> I still can't see what this patch is actually trying to achieve though
[01:46] <fabbione> Keybuk: i don't know all udev internals, but i assume it does some kind of grep to decide what module to load
[01:46] <Keybuk> why not just let each driver do its own probing?
[01:46] <Keybuk> you're misunderstanding the problem
[01:46] <Keybuk> the problem is
[01:46] <Keybuk> 1) udev loads IDE-driver-of-choice
[01:46] <Keybuk> 2) driver loads, but has had its init sequence removed by this patch, so does nothing
[01:47] <Keybuk> 3) ide-generic is loaded by hand ("modprobe ide-generic" in the init script)
[01:47] <Keybuk> 4) ide-generic's init script probes for devices, and assigns them to the first driver that seems to want them
[01:47] <Keybuk> s/init script/init sequence/
[01:47] <Kamion> fabbione: it shouldn't be provided by any arches any more, since ext2 is modular on all arches
[01:47] <Keybuk> 5) ide-generic wins devices over the driver-of-choice
[01:47] <Kamion> fabbione: filing a bug now
[01:47] <fabbione> Kamion: fixing in git :).. don't bother with a bug
[01:48] <Kamion> too late, #20535; I needed a bug anyway to document the seed workaround I need to make
[01:48] <fabbione> Kamion: ok
[01:48] <jbailey> Keybuk: So ide-generic was still wining anyway?
[01:48] <Keybuk> jbailey: right
[01:48] <jbailey> That doesn't make sense, since we were actually getting DMA out of drives.
[01:48] <Keybuk> jbailey: it won sometimes
[01:48] <jbailey> Mmm.  Joy. =)
[01:48] <Keybuk> pretty much hash-table-luck
[01:48] <Keybuk> ie. if your ide driver hashed earlier than ide-generic, you won DMA
[01:49] <Keybuk> if your ide driver hashed later, you lost DMA
[01:49] <fabbione> Keybuk: ok.. can't we just fix this hash-table to do what we want?
[01:49] <Keybuk> fabbione: no
[01:49] <Keybuk> we should drop this patch
[01:49] <fabbione> why?
[01:49] <Keybuk> because it's wrong
[01:50] <Keybuk> each driver should probe for its own devices
[01:50] <Keybuk> I don't see why that's a problem
[01:50] <Kamion> fabbione: while you're there, could you arrange for all arches to generate an ext2-modules udeb? at present hppa and sparc don't
[01:50] <Keybuk> if I "modprobe piix", I damned well want /dev/hda1 to appear with that driver
[01:50] <fabbione> Kamion: sure
[01:51] <Keybuk> this patch seems to do two things
[01:51] <Keybuk> one adds _exit() functions to each driver
[01:51] <Keybuk> that seems sane
[01:51] <Keybuk> the other moves all driver init to ide-generic, which just seems wacky
[01:51] <Keybuk> unless there's a rationale for that, we should stop it
[01:52] <Kamion> fabbione: thanks
[01:52] <fabbione> Kamion: no problem
[01:54] <fabbione> Keybuk: i am pretty sure herbet has a clear idea on why it has been done that way
[01:54] <fabbione> Keybuk: you really want to ask him before reverting
[01:54] <Keybuk> well, doing that breaks everybody
[01:54] <Keybuk> and the upstream IDE subsystem maintainer thinks it's a very stupid thing to do, also
[01:54] <Keybuk> which to me is somewhat a clue that we don't want to do it :)
[01:55] <Keybuk> the patch makes _some_ sense for when we just used to load every ide module and hope for the best
[01:55] <Keybuk> but even then could be considered a kludge
[01:56] <Keybuk> (ie. load every ide module, then let them fight to win devices, then remove anything that hasn't claimed a device)
[01:56] <Keybuk> now we're smarter, we load just the one, right, ide module
[01:59] <fabbione> IDE upstream is not exactly the most open person in this world
[01:59] <fabbione> since even Alan Cox has been pushing that patch
[01:59] <Nafallo> Keybuk: morning. would you care to backport your fix in ifupdown to breezy-updates? the clients get a new ip every time they ask about one :-/.
[02:00] <Keybuk> fabbione: bits of the patch do look right
[02:00] <Keybuk> but the patch does two things
[02:00] <Keybuk> and one of them is clearly wrong
[02:00] <Keybuk> why would you want to load an ide driver and *NOT* have it claim devices?
[02:00] <fabbione> Keybuk: revert the patch and try
[02:01] <fabbione> see how many systems breaks and than we can evaluate :)
[02:01] <jbailey> Wow.  I setup biarch x86_64/i386 kernel headers in may, and noone noticed that I had the x86_64 headers on there twice and no i386 headers. =)
[02:01] <fabbione> Keybuk: have you consider ATA-RAID controllers?
[02:01] <jbailey> Clearly a well used setup. =)
[02:01] <Keybuk> what about them?
[02:01] <fabbione> Keybuk: some of them are visible as both raid and ide
[02:02] <Keybuk> so?
[02:02] <fabbione> Keybuk: if you allow the ide to claim the device you won't see the raid anymore
[02:02] <Keybuk> right
[02:02] <Keybuk> but that would be broken today if that were the case
[02:02] <Keybuk> because we'd have loaded the ide module and ide-generic, and it would have claimed the device
[02:03] <fabbione> Kamion: i fixed ext2-modules for sparc64, but hppa has always been there
[02:03] <Kamion> this all sounds kinda reminiscent of the piix/ata_piix thing we delayed the hoary preview over?
[02:03] <Kamion> fabbione: well it's not in the archive
[02:03] <Keybuk> because we were working around this "loading the right ide module doesn't actually claim the devices" problem in breezy
[02:04] <Keybuk> and, as you say, we can always just blacklist things
[02:04] <fabbione> Kamion: i am checking
[02:07] <fabbione> Kamion: the ext2 thing for hppa was added a while ago in .15. The problem is that there is no .15 for hppa in the archive
[02:07] <fabbione> Kamion: that's something i can't really fix
[02:07] <fabbione> anyway sparc should be ok
[02:10] <fabbione> Kamion: done.. BenC needs only to pull from my archive
[02:10] <Kamion> fabbione: ah, ok
[02:10] <Kamion> thanks
[02:10] <fabbione> no problem
[02:11] <BenC> what's up?
[02:12] <Kamion> #20535, live CD hosage, fabbione fixed
[02:14] <Keybuk> hmm, is the config stored in the linux-source package anywhere?
[02:15] <fabbione> Keybuk: debian/config/$arch/
[02:16] <Keybuk> I don't have a debian directory
[02:17] <Keybuk> http://people.ubuntu.com/~scott/fixed-ide.patch
[02:17] <Keybuk> ^ so this is the patch I'm trying
[02:18] <Keybuk> it unpicks the part of the modular-ide patch I think is in crackywackyland
[02:19] <Diablo-D3> am I the only one here who finds linux depressing?
[02:25] <BenC> anyone know if there's a way to do parental controls for website access?
[02:25] <Diablo-D3> yes, but not with any foss tools afaik
[02:25] <Diablo-D3> /that/ and its impossible
[02:25] <BenC> impossible?
[02:26] <Diablo-D3> the tools dont work
[02:26] <Kamion> dansguardian and something else came up the last time we discussed this seriously
[02:26] <BenC> works on MacOSX
[02:26] <Diablo-D3> I mean, they dont filter what they should
[02:26] <Kamion> squidguard I think
[02:26] <BenC> I don't want filter, I want a white list
[02:26] <Diablo-D3> BenC: ahhh
[02:26] <Diablo-D3> now thats much easier.
[02:26] <Diablo-D3> yeah, theres some squid-based tool that will do it
[02:27] <Diablo-D3> BenC: also, what stops you from just whitelisting hosts using iptables
[02:27] <Diablo-D3> stop them from doing anything
[02:28] <BenC> I was looking for something integrated that would pop-up and say "You do not have access to this website, please enter the admin password to override"
[02:28] <Diablo-D3> hrm.
[02:28] <Diablo-D3> ask kamion =P
[02:28] <Kamion> no, don't
[02:29] <BenC> Kamion: I need to ask you a question...
[02:29] <BenC> :)
[02:30] <mvo> Kamion: do we have a list of expected removals on a dist-upgrade somewhere already? 
[02:30] <BenC> hotplug is one, and some things with HP print/scan stuff
[02:30] <BenC> that's all I know of
[02:31] <Keybuk> modutils and initrd-tools will be going soon
[02:31] <mvo> thanks, I'm looking for it for the save-dist-upgrade spec, I wonder if we have something for hoary->breezy already for example
[02:31] <mvo> (not wanting to re-invent the wheel etc)
[02:32] <BenC> Kaybuk: is initrd-tools dist-wide, or just the archs that support initramfs?
[02:32] <Keybuk> BenC: the theory is to make all the archs support initramfs
[02:33] <Diablo-D3> oh wow
[02:33] <Diablo-D3> debian planet has new articles
[02:33] <Keybuk> I'm not entirely sure that initrd works now, for example :)
[02:33] <Kamion> mvo: not that I know of
[02:33] <StevenK> BenC: However, it would be fairly easy to write a squid filter that grabbed the URL, and returned a 403 if they were denied (which forces the browser to pop up the auth dialog) or 200 if the page is ok.
[02:34] <Robot101> StevenK: you forgot dbus.!
[02:34] <jbailey> BenC: No effort will be made to make initrd-tools work without devfs.
[02:34] <BenC> ah
[02:34] <StevenK> Robot101: How is dbus supposed to fit in there? :-P
[02:34] <Keybuk> iirc. I saw a patch for the last arch that didn't work that we care about go in a while back
[02:34] <jbailey> BenC: So it's one of those moments where the archs have to be able to do it, or they'll die off.  In this case, I think we have patches in hand for all arches now anyone.
[02:34] <Keybuk> and that was one of lamont's toys
[02:34] <Robot101> StevenK: not sure, but it's a requirement for new free software projects nowadays. :)
[02:34] <jbailey> BenC: I have a new patch from kyle for hppa, and lamont has a patch for elilo
[02:35] <BenC> jbailey: can you send me the one for hppa?
[02:35] <BenC> I'd like to test it
[02:35] <jbailey> BenC: Sorry, it's a klibc patch, not a kernel one.
[02:35] <StevenK> Robot101: So, how can I debug why gaim won't add itself to the Notification area?
[02:35] <BenC> do you have a patches klibc though?
[02:35] <jbailey> BenC: I'll just upload it to the archive over lunch probably.
[02:35] <BenC> ok
[02:35] <Robot101> StevenK: oh dear
[02:35] <jbailey> BenC: The lag to my usual hppa box last night was painful, so I went to bed instead.
[02:35] <Robot101> StevenK: other stuff does, just gaim fails to?
[02:36] <StevenK> Robot101: amarok does, printing does, upgrade notification does.
[02:37] <Diablo-D3> to dapper mwhahaha
[02:37] <fabbione> Diablo-D3: read /topic before doing so
[02:37] <Keybuk> we could probably remove that bit now
[02:38] <pitti> Keybuk: s/getting/has/, but the unstable part might still be true :)
[02:38] <Robot101> fabbione: the bit that says "#ubuntu for support and general discussion"? :)
[02:38] <Robot101> StevenK: and you have the tray icon plugin loaded?
[02:39] <StevenK> Robot101: I have no idea. My .gaim is fairly old.
[02:39] <jbailey> Keybuk: Mmm, it's probably still worth noting that networking isn't likely to come up.
[02:39] <Diablo-D3> fabbione: uh?
[02:39] <Diablo-D3> fabbione: 2.6.15-6.8 is working fine for me
[02:39] <fabbione> Robot101: more likely the part that says Dapper might be on crack.. if it breaks.. sucks to be you
[02:39] <Diablo-D3> fabbione: so unless you know of any other new kernels that I should be aware of, please tell me
[02:39] <fabbione> Diablo-D3: do whatever you want.. 
[02:40] <fabbione> if it breaks.. sucks to be you
[02:40] <Keybuk> this is open source development at its best
[02:40] <Keybuk> when it breaks, you get to keep the pieces
[02:40] <Diablo-D3> fabbione: dude, quit being lame.
[02:40] <StevenK> Robot101: Okay, that fixed it.
[02:40] <Keybuk> and it's usually a good idea to have the glue standing by first
[02:40] <Diablo-D3> I've been running devel kernels longer than you've ran linux.
[02:41] <fabbione> Diablo-D3: dapper is not made of new kernels only...
[02:41] <Diablo-D3> so don't start running you're mouth off to me.
[02:41] <dholbach> Diablo-D3: stop it
[02:41] <fabbione> Diablo-D3: and please it's time you moderate your tone here
[02:41] <zakame> hey all :D wazup?
[02:41] <fabbione> Diablo-D3: because from me giving you a piece of advice
[02:42] <fabbione> Diablo-D3: you are turning into something that's not nice
[02:43] <Robot101> StevenK: phew, it's not a real bug, just Gaim being crack :)
[02:45] <StevenK> Robot101: The best kind.
[02:46] <Robot101> StevenK: roll on telepathy... :)
[02:47] <\sh> ignoring trolls now
[02:49] <ogra> daniels, thanks 
[02:49] <\sh> thx daniels 
[02:50] <\sh> oh well...security break ...
[02:52] <crimsun> elmo: please sync pysol from Sid (ok to override Ubuntu changes), thanks
[02:55] <Kamion> Keybuk: "don't install" is still true
[03:00] <lll> dss
[03:00] <lll> 
[03:01] <lll> asd
[03:01] <Kamion> lll: take the testing somewhere else, please
[03:01] <lll> sorry
[03:02] <lll> hellp
[03:02] <lll> hello
[03:02] <lll> hello
[03:03] <lll> hi
[03:03] <lll> hi
[03:03] <lll> hi
[03:03] <lll> hi
[03:03] <lll> hi
[03:03] <lll> hi
[03:03] <lll> ] 
[03:29] <jbailey> elmo, Znarl: Can you please update linux-kernel-headers in the amd64 dapper chroot on concordia? (RT #1099)
[03:32] <Znarl> jbailey : No problem.
[04:07] <Keybuk> BenC: when is your next planned kernel upload?
[04:07] <BenC> in about 30 minutes
[04:07] <Keybuk> ok
[04:07] <Keybuk> hold it for one second
[04:07] <Keybuk> I have a patch which reeeeally needs to go in
[04:08] <BenC> ok, just say when
[04:08] <Keybuk> I just want to reboot to make sure my machine's still happy with it applied
[04:08] <BenC> ah, ok
[04:08] <BenC> what's it for?
[04:08] <Keybuk> fixes IDE
[04:08] <BenC> fixes it how?
[04:08] <jbailey> BenC: You sound suspicious. =)
[04:09] <Keybuk> http://people.ubuntu.com/~scott/fixed-ide.patch
[04:09] <Keybuk> reverts some of the "modular ide" patch
[04:09] <BenC> "fixes IDE" is a slightly broad patch description :)
[04:09] <Keybuk> let me just check I didn't fluff it, and I'll explain in detail
[04:09] <jbailey> Keybuk: You're touching exported symbols, hope it was an abi bump anyway. =)
[04:10] <Keybuk> jbailey: I expect BenC is about to bump the ABI anyway
[04:10] <Keybuk> ok
[04:10] <Keybuk> so let me explain it
[04:10] <BenC> yeah, it's -7.9 so all good
[04:11] <Keybuk> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commitdiff;h=149744c1475cdaf2c6babfd92f163cca8f10c540;hp=5a373d68631531fff09047364be4565d67335f08
[04:11] <Keybuk> ^ that is our "modular-ide" patch
[04:11] <BenC> yeah, from breezy
[04:11] <Keybuk> it's advertised as making more of the IDE drivers work when modules and not built-in
[04:11] <Keybuk> but it actually does two things
[04:11] <Keybuk> one is fix those drivers (adding the exit functions, etc.)
[04:11] <Keybuk> and the other is to prevent ANY driver from claiming devices when loaded
[04:11] <Keybuk> and instead move device claiming to ide-generic
[04:12] <Keybuk> the effect of this is:
[04:12] <Keybuk> modprobe piix
[04:12] <Keybuk> doesn't claim any devices
[04:12] <Keybuk> instead you have to wait for that to settle, then modprobe ide-generic
[04:12] <Keybuk> and ide-generic dishes out the devices to interested drivers
[04:12] <Keybuk> the bug is
[04:12] <Keybuk> that ide-generic is also interested, and frequently wins the fight
[04:12] <Keybuk> now,
[04:12] <BenC> I remember that same type of thing in breezy
[04:12] <Keybuk> the rationale for this, afaict, was that we _used_ to load all the ide drivers and let them fight it out
[04:12] <BenC> right
[04:13] <Keybuk> ie. we actually loaded every single one, loaded ide-generic last, then removed any driver that wasn't hanging on to a device
[04:13] <Keybuk> so it makes kinda sense, in a very kludgy way
[04:13] <Keybuk> but we don't do that now
[04:13] <Keybuk> now we're clever, we load exactly the right single ide module we wanted
[04:13] <Keybuk> and we can resolve issues like "piix and ata_piix might claim the same device" in userspace, where we're supposed to
[04:13] <Keybuk> (by loading the right module in userspace through modprobe blacklists, et al)
[04:14] <BenC> what about the cases where none of the specific drivers claimed it, and ide-generic needs to be loaded?
[04:14] <Keybuk> those we can also handle in userspace
[04:14] <BenC> can or do?
[04:14] <Keybuk> do
[04:15] <Keybuk> so back to the patch
[04:15] <BenC> I just want to know what to look out for so if anything pops up, I know whether you or I need to fix it :)
[04:15] <Keybuk> this unpicks the part of the modular-ide patch that changed the way drivers grabbed drivers
[04:15] <Keybuk> so puts us back to upstream in that regard
[04:15] <Keybuk> so loading the driver for a particular ide device will claim that device
[04:16] <BenC> back to upstream is good, I didn't much like the way this patch worked
[04:16] <Keybuk> right
[04:16] <Keybuk> so things that could pop up, in theory, if you have something that could either be RAID/SATA or IDE
[04:16] <Keybuk> and the wrong driver gets loaded first
[04:16] <Keybuk> the way to fix that is to tell me, and we'll arrange for the right thing to happen in the initramfs
[04:17] <BenC> what sort of troubleshooting do I ask of users having problems with this?
[04:18] <Keybuk> dmesg output will once again reveal which driver wins the device
[04:18] <BenC> "load ide-generic", "blacklist module foo"?
[04:18] <Keybuk> exactly
[04:18] <Keybuk> does adding "blacklist the-wrong-module" to /etc/modprobe.d/blacklist work?
[04:18] <Keybuk> (and update-initramfs)
[04:19] <BenC> one thing we are eventually going to end up dealing with (so I've found out today) is when pata drivers start getting included, devices will go from hda -> sda, for instance, but that will probably be post-dapper
[04:19] <Keybuk> my favourite debugging trick is to boot with break=premount and get them to step through the process of loading the modules for their rootfs, and seeing which one throws the spring across the room
[04:19] <Keybuk> yeah
[04:19] <Keybuk> that will be a nice day
[04:19] <BenC> ok
[04:19] <Keybuk> then we can rename sd? to just disk or something <g>
[04:20] <Keybuk> http://people.ubuntu.com/~scott/fixed-ide.patch
[04:20] <BenC> we may want to make sure we have the UUID mounting stuff ready in dapper
[04:20] <BenC> which will make it easier for post-dapper to make the switch
[04:20] <Keybuk> ^ right, that's the patch.  it applies cleanly to our linux-source-2.6.15-6.8 (it might need a wiggle for your git tree)
[04:20] <Keybuk> and doesn't break compilation
[04:20] <Keybuk> and doesn't break booting for my laptop

[04:21] <Keybuk> if it fixes booting on our boss's laptop, so much the better
[04:21] <BenC> ok, I'll put it in, and trust it (so I don't have to wait 3 hours for my test builds to finish :)
[04:21] <Kamion> ~ # chroot /target
[04:21] <Kamion> chroot: cannot execute /bin/sh: Exec format error
[04:21] <Kamion> I do love broken live filesystems
[04:22] <BenC> applied, with no fuzz :)
[04:22] <Keybuk> damn, I give good patch
[04:22] <Amaranth> pata? why the rename?
[04:22] <Amaranth> pata == ide, no?
[04:23] <BenC> pata is done in the scsi layer
[04:23] <infinity> parallel ata is a superset of ide, if you want to be anal.  But who really cares anymore?
[04:23] <BenC> so uses scsi device names
[04:23] <Amaranth> seb128: LaserJock wants a Science menu to be added to applications.menu
[04:23] <seb128> Amaranth: file a bug on gnome-menus upstream
[04:23] <Amaranth> seb128: gnome has a bug filed and someone created an icon for the menu, just needs to get used
[04:24] <HiddenWolf> just hide the menu if it's empty. ;)
[04:24] <seb128> Amaranth: I've the list of gnome-menus bug at screen atm and there is no one about this
[04:24] <Amaranth> HiddenWolf: That's default.
[04:24] <Amaranth> http://bugzilla.gnome.org/show_bug.cgi?id=140900
[04:24] <Keybuk> Amaranth: you know how SATA devices appear as SCSI drives?
[04:24] <seb128> -Amaccording to the number that's before gnome-menus
[04:25] <Keybuk> well, PATA is the same for IDE drives
[04:25] <Amaranth> it got filed against gnome-icon-theme, i guess because the idea was that once an icon was created it was good to go
[04:25] <Amaranth> Keybuk: Yeah, which doesn't make much sense to me.
[04:25] <Keybuk> so you'll have /dev/sda1 instead of /dev/hda1
[04:25] <seb128> Amaranth: still, don't expect it to move if you don't file a bug on gnome-menus upstream
[04:25] <Keybuk> Amaranth: the SCSI subsystem is rather better than the IDE subsystem, and it's easier to implement generic bus-of-drive-like-devices in SCSI
[04:25] <seb128> gnome-icon-theme is not likely to be tracked by markmc
[04:25] <Keybuk> whatever the underlying protocol
[04:25] <infinity> Kamion : You never specified you wanted live filesystems to WORK... Just get built.
[04:25] <Keybuk> if you want to look at it another way, that's semantically less scary
[04:26] <Amaranth> seb128: It was filed against gnome-menus at one time. Should I file a new bug saying the icon has been created, we just need to include it?
[04:26] <Keybuk> "there will be a single subsystem for drives of all kinds; SCSI, IDE/PATA, SATA and USB storage will all appear under it"
[04:26] <Amaranth> seb128: I think the icon needs to get into gnome-icon-theme first though.
[04:26] <Keybuk> it just happens that the single subsystem is the existing SCSI subsystem, not a new one <g>
[04:26] <Amaranth> Keybuk: ah, i guess that makes sense
[04:26] <Amaranth> Keybuk: but the sd naming no longer does
[04:27] <infinity> Amaranth : We're not the only OS with this oddity.  SCSI programming is easier in Windows too, which is why many 3rd-party IDE controller drivers present themselves in the Windows device manager as SCSI controllers.
[04:27] <Keybuk> right, device names are userspace though -- we can always drop the "s"
[04:27] <seb128> Amaranth: that's what bug Depends are for
[04:27] <Keybuk> or just pretend it means "standard disk" or something <g>
[04:27] <seb128> Amaranth: create a gnome-menus bug and make it depends on the icon one
[04:27] <StevenK> Keybuk: "Special Device" :-P
[04:28] <seb128> Amaranth: and I'm not sure that a science category is useful, want to put to it?
[04:28] <jbailey> Keybuk: What are you quoting from?
[04:28] <seb128> what do you want to put to it?
[04:28] <infinity> StevenK : "storage device", and I think you've nailed it.
[04:28] <Amaranth> seb128: LaserJock appearently has a large number of programs that fit in it.
[04:28] <StevenK> Heh, I was joking.
[04:28] <Keybuk> jbailey: quoting?
[04:28] <Keybuk> infinity: perfect.
[04:28] <Amaranth> seb128: I told him to use Categories=Applications;Science;Education; but that doesn't seem to be a good fit.
 "there will be a single subsystem for drives of all kinds; SCSI, IDE/PATA, SATA and USB storage will all appear under it"
[04:29] <Keybuk> jbailey: ah, English style (at least that I learned) is to use 'blah blah' for real quotes and "foo bar" for quotables
[04:29] <Keybuk> ie. that was a single sentence that could be less scary
[04:29] <Amaranth> Keybuk: most people just mix them randomly
[04:29] <seb128> Amaranth: some example of the "large number of programs that fit in it"?
[04:29] <Keybuk> I wasn't quoting anyone in particular
[04:29] <mjg59> Keybuk: Any ideas on how we could sensibly transition people from /dev/hda to /dev/sda ?
[04:29] <Amaranth> seb128: You'd have to talk to him.
[04:29] <Amaranth> LaserJock: ping?
[04:30] <jbailey> Keybuk: Ah alright.  I didn't do english schooling, so I'll remember this. =)
[04:30] <seb128> Amaranth: I'm not convinced, we are trying to make the menu easier, not to have a zillions of categories with 1 icon
[04:30] <mjg59> Keybuk: Answers of the form "For certain devices, create hda device nodes that are actually SCSI devices" may be acceptable
[04:30] <LaserJock> Amaranth: pong. sorry was a little busy ;-)
[04:30] <Amaranth> seb128: Something about schools and science apps that don't fit into edutainment
[04:30] <infinity> mjg59 : I'm not sure.  How's it been done in the past (when SATA controllers moved to libata)?
[04:30] <Amaranth> (which gnome doesn't seem to have an icon for)
[04:30] <mjg59> I think people had to do manual configuration
[04:30] <Kamion> Keybuk: we could just symlink sda* to hda* ...
[04:31] <infinity> mjg59 : Somewhere in the 2.4 series, I had a mess of hard drives migrate to the SCSI side.  I assume some commercial vendors actually had to deal with that, while I did it manually.
[04:31] <seb128> Amaranth: http://bugzilla.gnome.org/show_bug.cgi?id=321703
[04:31] <Keybuk> yeah, either works
[04:32] <mjg59> Basically, there's some chance of migrating to using libata-based PATA drivers for most hardware
[04:32] <Amaranth> seb128: As usual you're way ahead of me. :)
[04:32] <mjg59> Which has certain compelling advantages, and the large disadvantage that they're almost untested
[04:32] <LaserJock> seb128: I can understand wanting to keep the menu clean. It is just frustrating that science applications end up in Other or Education when they aren't really either
[04:33] <mjg59> seb128: Did you see my gdm patch?
[04:33] <seb128> mjg59: I've seen the mail/bug but not looked on the patch yet, trying to get gst0.10 packaged this way so my focus is on it atm
[04:33] <seb128> s/way/week/
[04:33] <mjg59> seb128: Ok, no problem
[04:33] <Amaranth> woo, gstreamer 0.10
[04:34] <seb128> mjg59: it's on my list of stuff ot look after gst, don't worry :)
[04:35] <Kamion> infinity: any idea what's up with them?
[04:35] <seb128> LaserJock: please open an upstream bug (bugzilla.gnome.org) against gnome-menus for science category
[04:36] <LaserJock> seb128: I believe there is one already. Amaranth gave me the url yesterday but I can't find it at the moment
[04:36] <Amaranth> LaserJock: Yeah, your bug, you file it. :) Give specific examples of what would go in it. Make sure you make it depend on 140900
[04:36] <Amaranth> LaserJock: That's gnome-icon-theme, to make the icon for the menu.
[04:37] <infinity> Kamion : No, I'm just being an unhelpfully sarcastic jerk while I wait on some stuff I have building in the background.
[04:37] <infinity> Kamion : If you want help with (live)cd stuff tomorrow, though, I'm all yours.
[04:39] <Kamion> infinity: "/mnt/bin/bash: data" according to file
[04:40] <infinity> !
[04:40] <infinity> In the base livefs?
[04:41] <infinity> Kamion : Is bash special in that regard, or is the whole system similarly b0rked?
[04:44] <Kamion> infinity: full live fs
[04:44] <infinity> Which arch/date?
[04:44] <Kamion> infinity: random sample, gunzip's fine, false's fine, ddate's broken
[04:45] <Kamion> infinity: i386, whatever's in the images I built an hour or two ago
[04:45] <infinity> Full ubuntu?... That hasn't actually succeeded since Nov 22...
[04:46] <Kamion> oh, huh
[04:46] <Kamion> yeah, full
[04:47] <Kamion> I guess I'm spoiled by late breezy
[04:47] <infinity> Yeah. :)
[04:47] <infinity> I'm wondering if it's worth hunting this, or if we should test recent base first to see if it seems transient.
[04:48] <Kamion> I was mostly just trying to get far enough to be able to port the root fs switchover code to initramfs
[04:48] <infinity> Okay, the non-compressed image has a working bash.
[04:49] <Kamion> hmm, powerpc looks like it should succeed if built at the moment
[04:50] <infinity> Didn't 12 hours ago, but a lot can change in 12 hours..
[04:56] <infinity> Cute, I don't actually have cloop support on the buildds, so I can't mount the images there.
[04:57] <LaserJock> seb128: ok, just rereading the log here. So I should file a bug against gnome-menus with info on the need for a science category and then put a dependency on the gnome-icon-theme bug 
[04:59] <seb128> LaserJock: exactly
[04:59] <LaserJock> seb128: ok, will do. thanks
[05:00] <seb128> np, thank you
[05:03] <Kamion> infinity: the machine COULD be insane
[05:03] <infinity> Kamion : Would it be beneficial if I included md5sum output of the cloop in the build log somewhere?
[05:04] <Kamion> sure
[05:06] <Kamion> pitti: #ubuntu-meeting, opinions on zyga for membership?
[05:07] <infinity> Kamion : Alright, I'll TODO that.  For now, the MD5 of the image you're trying to use that's broken should be:
[05:07] <infinity> 734bd42f6097b1232b0144e4435bbf70  livecd.ubuntu-20051122-i386.cloop-1024:65536
[05:14] <\sh> hmm...who is Fabio Marzocca? 
[05:17] <ogra> \sh, thesaltydog
[05:17] <\sh> http://lxer.com/module/newswire/view/49268/index.html nice interview :)
[05:17] <ogra> and no, he's no ubuntu developer, even if heclaims it in the interview ...
[05:17] <zakame> er?
[05:18] <ogra> but he develops his stuf with ubuntu in mind i guess ...
[05:22] <zakame> ogra: just to be clear, what qualifies as a ubuntu dev? :)
[05:23] <ogra> zakame, being in one of the launchpad dev teams i'd say 
[05:23] <ogra> at least if you use it as a headline in an interview
[05:23] <Kamion> ubuntu-dev or ubuntu-core-dev
[05:23] <ogra> what Kamion said
[05:24] <Keybuk> anyone here running dapper, and has a SCSI CD-ROM drive?
[05:24] <zakame> Kamion: ogra: ah, i see... that was also what I had in mind...
[05:25] <Keybuk> (or, I guess, SATA CD drive)
[05:29] <wasabi_> The hotplug stuff in /etc/network/interfaces is confusing.
[05:30] <Keybuk> wasabi: yeah, it's going
[05:30] <wasabi_> Suppose it's safe to just rip it out and use traditional "auto"
[05:31] <wasabi_> I guess what I think would be really nifty is a "mac NN:NNetc" in an iface stanza
[05:31] <wasabi_> which also took over ifrename heh
[05:31] <wasabi_> Or something similar.
[05:31] <Kamion> infinity: md5sum matches
[05:31] <Keybuk> udev is replacing ifrename
[05:31] <Kamion> wasabi_: some of that's already changing in netcfg upstream
[05:31] <Keybuk> as that can actually rewrite the event as it goes and pass the right thing to ifup
[05:32] <Kamion> only affects new installs of couse
[05:32] <wasabi_> Ahh nifty.
[05:32] <wasabi_> Man what I really want though is n-m to become just a frontend to this. =9
[05:32] <wasabi_> this whole seperation thing bites.
[05:33] <thierry_> seb128 : if I want to solve a unmet dependencies problem, where do I send the patch? malone?
[05:59] <desrt> Seveas; ping
[06:00] <infinity> Kamion : I didn't want to know that.  Yell at me about it tomorrow, and we'll dig deeper.  It'a 4am and bedtime.
[06:00] <desrt> Seveas; is there any reason you changed my 'install -t dest src' to 'install src dest'?
[06:00] <Kamion> infinity: ok
[06:00] <desrt> Seveas; i'm incorporating a bunch of your changes upstream and am wondering about that one
[06:00] <Kamion> what's install -t? it's not in --help
[06:00] <desrt> Kamion; destination directory
[06:00] <desrt> 'target'
[06:00] <Seveas> -t doesn't work on ubuntu and is not in the manpage
[06:00] <desrt>        -t, --target-directory=DIRECTORY
[06:00] <desrt>               copy all SOURCE arguments into DIRECTORY
[06:01] <Seveas> which version of install is that?
[06:01] <desrt> works on my ubuntu :)
[06:01] <desrt> install (GNU coreutils) 5.93
[06:01] <desrt> (dapper)
[06:01] <Seveas>        -S, --suffix=SUFFIX override the usual backup suffix
[06:01] <Seveas>        -v, --verbose
[06:01] <Seveas>               print the name of each directory as it is created
[06:01] <Kamion> must be a very new option; it's not in my Debian installation's version
[06:01] <desrt> if it's not even in breezy then that's definitely reason enough to not include it :)
[06:01] <Seveas> I've been testing (and using) the pacjage on breezy
[06:02] <desrt> elite.  i'll be releasing 0.1.1 today
[06:02] <Seveas> cool
[06:02] <desrt> do you want me to package it?
[06:03] <Seveas> neh, I'll do it, gives me some practice :)
[06:03] <desrt> i was hoping the same for myself :p
[06:03] <Seveas> hehe
[06:03] <desrt> anyway.  lunch.  bbl.
[06:07] <desrt> btw-- any feature requests for 0.1.1?  you've probably been using it more than anyone
[06:07] <desrt> mostly i've just fixed the licensing problems and added your .desktop file.... but i also added a feature that the gnome-terminals get invoked with a 'keyboardcast' profile (so you can have smaller text, for example)
[06:09] <pitti> elmo: is it possible to remove evolution | 2.2.1.1-0ubuntu4.1 from hoary-updates? It has been superseded by 2.2.1.1-0ubuntu4.2 in hoary-security
[06:10] <pitti> elmo: i. e. the -security version includes the -updates fix, so there is no reason to use the -updates version which has vulns
[06:14] <Keybuk> \o/
[06:14] <Keybuk> fixed the /dev/sr0 group "floppy" issue
[06:16] <mdz_> Keybuk: what was it?
[06:20] <Keybuk> a duff udev rule
[06:20] <Keybuk> I'd enclosed those in SUBSYSTEM!="scsi_device"
[06:20] <Keybuk> but block devices are made by the block SUBSYSTEM :p
[06:20] <mdz_> pitti: if there have been no problems with the -updates version, we can consider folding it into -security so you don't need to maintain two branches
[06:20] <Keybuk> I really needed ENV{PHYSDEVBUS}!="scsi"
[06:24] <Keybuk> pitti: I was just about to ping you about your pcspkr problems :p
[06:25] <xkahn> Okay.  So I made a patch to add pam_xauth to ubuntu.
[06:25] <xkahn> And then I started the flamewar on the -devel mailing lists.
[06:26] <xkahn> Now what do I do to get it approved?
[06:26] <xkahn> Sadly, it wasn't a very GOOD flamewar...
[06:26] <xkahn> Oh.  And I filed a bug.
[06:26] <xkahn> Forgot that bit.
[06:29] <mdz_> pitti: please work with mjg59 to get acpi-support installable in main again
[06:32] <mdz_> Keybuk: pcspkr was not being loaded for me, but I assumed it was because I was on 2.6.12 on that box
[06:32] <mdz_> Keybuk: it seems to load fine on my laptop, which runs 2.6.15
[06:33] <Keybuk> yeah, there was a pnp_modules bug, which I thought I fixed, pitti filed a bug though, but then resolved it again when he upgraded :p
[06:33] <mdz_> seb128: why is xchat opening hyperlinks in w3m for me now?
[06:34] <seb128> mdz_: what does gnome-open do (gnome-open http://)?
[06:35] <Kamion> sigh, I always find the HIG really hard to find on the GNOME web site
[06:35] <mdz_> Error showing url: There was an error launching the default action command associated with this location.
[06:35] <mdz_> seb128: gnome-terminal still works (loads it in firefox)
[06:35] <mdz_> oh, not on this machine
[06:35] <Kamion> it always seems that it should be under "GNOME Policies" or "Standards" before I think to try "Programming Guides"
[06:35] <mdz_> on my desktop, xchat uses w3m and g-t uses firefox correctly
[06:35] <seb128> mdz_: run the preferred app capplet, and set firefox instead of mozilla-firefox
[06:35] <mdz_> on my laptop, g-t gives an error and xchat uses w3m
[06:36] <mdz_> seb128: is this because I changed it sometime, or will it affect the default config?
[06:36] <seb128> mdz_: I'll have a look for xchat, I use xchat-gnome atm I'm not sure it uses the standard gnome_vfs call (like gnome-open). The default system key has been updated so it'll affect only people who did some user change
[06:36] <mdz_> seb128: that fixed gnome-open; I assume I need to restart xchat?
[06:37] <mdz_> seb128: is xchat-gnome workable for dapper?
[06:37] <ogra> mdz_, err, see your alternatives fro x-www-browser
[06:37] <mdz_> x-www-browser - status is manual.
[06:37] <mdz_>  link currently points to /usr/bin/mozilla-firefox
[06:37] <mdz_> /usr/bin/firefox - priority 70
[06:38] <mdz_> that shouldn't be manual
[06:38] <seb128> mdz_: I use it for some months, it works quite fine for me but that would be nice to get user feedback on it
[06:38] <mdz_> seb128: if there are no known showstoppers, let's switch and see what happens
[06:38] <ogra> mdz_, and it shouldnt point to a non existing binary :)
[06:39] <seb128> mdz_: it has some nice plugin (can use libnotify, autoset away when gnome-screensaver starts, etc)
[06:39] <seb128> mdz_: I guess there is no issue to switch now so we can get feedback on it
[06:39] <mdz_> seb128: ok, go ahead and update the seeds and ubuntu-meta please
[06:40] <seb128> mdz_: oki, doing that now
[06:42] <mdz_> seb128,ogra: how about gnome-screensaver?  any reason not to switch that as well?
[06:42] <ogra> none apart from ugliness ...
[06:42] <ogra> i havent done the main inclusion report yet ... will do after dinner
[06:43] <mdz_> ogra: xscreensaver in dapper is ugly already
[06:43] <ogra> hehe, yes, indeed :)
[06:43] <seb128> mdz_: for xchat seems that you need to restart it, ype
[06:43] <seb128> yep
[06:44] <ogra> if i can get it in without main inclusion report, i'll switch the seeds immediately ...
[06:45] <mdz_> xchat-gnome looks nice
[06:45] <Amaranth> isn't some of that integrated into xchat?
[06:45] <seb128> Amaranth: no
[06:45] <Amaranth> maybe it's just the silverex windows version that does it but this thing has the treeview for servers
[06:46] <seb128> ?
[06:46] <ogra> mdz_, if i can get it in without main inclusion report, i'll switch the seeds immediately ...
[06:47] <mdz_> GRRRRRR
[06:47] <mdz_> seb128: xchat-gnome has the ^W bug still
[06:47] <Amaranth> it's a feature :P
[06:47] <mdz_> ogra: gnome-screensaver is a new implementation, not just a new frontend for xscreensaver, right?
[06:47] <mdz_> ogra: as such, it needs a report
[06:48] <ogra> yup
[06:48] <seb128> mdz_: what bug? it uses w3m?
[06:48] <mdz_> seb128: the bug where ^W closes the tab rather than deleting backward one word
[06:48] <ogra> we switched in breezy without one, thats why i ask
[06:48] <mdz_> ogra: that was a sab override ;-)
[06:48] <ogra> hehe, oki
[06:49] <seb128> mdz_: that's a standard GNOME shortcut :)
[06:49] <seb128> mdz_: it does the same with gedit by example
[06:49] <mdz_> seb128: it's a standard UNIX shortcut for something less destructive ;-)
[06:49] <seb128> right ;)
[06:49] <Keybuk> GNOME doesn't use Emacs shortcuts
[06:49] <mdz_> seb128: in xchat, if you use gtk-theme-name Emacs it disables that
[06:49] <Keybuk> there's a gtkrc recipie you can use to make it
[06:49] <mdz_> er
[06:49] <mdz_> gtk-key-theme or whatever
[06:50] <seb128> I'll bug upstream about that :)
[06:50] <Amaranth> seb128: http://www.realistanew.com/random/xchat-windows.png
[06:50] <mpt> This is why GNOME should have used Alt, not Ctrl, when copying Mac shortcuts ...
[06:50] <Keybuk> it copied Windows shortcuts, didn't it?
[06:50] <mpt> then Ctrl+W for delete word and Alt+W for close window could have coexisted peacefully, like the humans and the fishes
[06:50] <jbailey> mdz_: gtk-key-theme-name = "Emacs"
[06:50] <seb128> Amaranth: weird, it's not the same with linux
[06:51] <mpt> Keybuk, iirc the only major Microsoft programs where Ctrl+W works are Internet Explorer and Excel
[06:51] <mpt> Windows programs, that is
[06:51] <dholbach> anoter pro argument for xchat-gnome would be that we could report bugs to b.g.o and not to sourceforge :)
[06:52] <Burgwork> dholbach, almost worth it right there
[06:53] <Diziet> dchroot--
[06:53] <Diziet> -anarres:~> dchroot -q echo ' 1 ' ' 2 '
[06:53] <Diziet> 1 2
[06:55] <pitti> mdz_: that's what I already did, the -security version contains the -updates fix (it was just a fixed bug tracker URL)
[06:56] <elmo> pitti: who has -security and not -updates in their sources.list?
[06:56] <elmo> pitti: and why do we care about them?
[06:56] <pitti> elmo: hm, you mean who has -updates and no -security?
[06:56] <elmo> err, yes
[06:56] <pitti> elmo: probably nobody
[06:57] <pitti> elmo: it's just that we have a vulnerable version in -updates, and it yells at me in the CVE tracker
[06:57] <elmo> pitti: well I'm kind of reluctant to just remove it
[06:57] <elmo> because that doesn't help the people who do only have -updates
[06:57] <elmo> I'd rather propagate it into -updates or something
[06:58] <pitti> elmo: it would only help for new installs, to prevent silly updates to -updates instead of -security
[06:58] <elmo> hum
[06:58] <pitti> elmo: right now I feel obliged to fix -updates, too
[06:59] <pitti> which I would do if we don't remove the updates version
[06:59] <pitti> would be fine for me, but I wanted to ask first :)
[07:00] <mdz_> pitti: I don't think -updates without -security makes much sense, tbh
[07:00] <mdz_> -updates should imply -security
[07:00] <pitti> me too
[07:00] <pitti> mdz_: it's really just a cosmetical issue and removing a branch we have to care for
[07:01] <zyga> http://ubuntu.suxx.pl/ubuntu-photo-project/
[07:01] <zyga> ideas/comments welcome
[07:01] <zyga> gnome comments for the last section welcome
[07:01] <mdz_> pitti: ok, so further updates need only go to -security
[07:01] <mdke_> i have a comment on the url
[07:01] <mdke_> zyga, shocking
[07:01] <zyga> yes I know I've got a crappy domain name
[07:01] <mdke_> clicking now
[07:01] <mdz_> pitti: it would have been simpler to release the -security update with a version >> -updates if it contained the changes already
[07:01] <zyga> please don't comment that (I tried to buy roxx.pl later but it was sold)
[07:02] <pitti> mdz_: that's exactly what I did
[07:02] <mdz_> pitti: then why was a -updates upload required?
[07:02] <mdke_> zyga, looks like some good ideas, perhaps work with the art team?
[07:02] <pitti> mdz_: the -updates one was there first, later I did a -security udpate and folded in the -updates fix
[07:03] <zyga> mdke_: I want to make the template for light/dark photos and maybe modify the background dialog
[07:03] <mdz_> pitti: oh, i only saw -updates on -changes
[07:03] <mdke_> zyga, art team sounds like a good place to work then no?
[07:03] <zyga> mdke_: #ubuntu-artwork is more less ghostship, but in general yes
[07:03] <pitti> mdz_: I don't think that -security goes to any -changes list
[07:04] <mdke_> zyga, you could try a mailing list or wiki pages, or contacting people directly
[07:04] <mdke> sorry ogra 
[07:04] <ogra> lol
[07:04] <mdke> damn home connection
[07:04] <ogra> i wasnt serious at all
[07:04] <pitti> mdz_: btw, both evolution uploads are already pretty old, I just noticed today that evolution 2.2.1.1-0ubuntu4.1
[07:05] <pitti> is still vulnerable
[07:05] <mdke> ogra, i know :)
[07:05] <ogra> just waiting for my food to warm up :)
[07:05] <Keybuk> pitti: you didn't fix the hal.rules file yet, right?
[07:05] <mhz> jdub: ping
[07:05] <zyga> mdke: I'll try the mailing list, thanks
[07:05] <pitti> Keybuk: in my local package here, but I didn't yet upload it
[07:05] <pitti> Keybuk: I thought it could wait for some days when I have some more fixes
[07:06] <Keybuk> pitti: could you upload that?
[07:06] <Keybuk> it's breaking things
[07:06] <pitti> Keybuk: but if you need it, I can, sure
[07:06] <mdz_> pitti: hoary-security is a newer version
[07:06] <mdz_> pitti: I think we can safely say that if someone doesn't have -security in sources.list, they can't expect security updates
[07:07] <pitti> mdz_: for real branches (i. e. -updates not merged), I also fixed the -updates version, so in a way they can
[07:07] <mdz_> pitti: we should not give them that expectation
[07:07] <pitti> i.e. whenever -updates has a higher version than -security, I fix both branches
[07:07] <pitti> otherwise using -updates wouldn't make much sense
[07:07] <mdz_> they are separate to allow users to opt out of updates, not opt out of security
[07:08] <pitti> Keybuk: uploaded
[07:08] <janimo> pitti, what should I need to be working on of wrt langpacks in xubuntu?
[07:09] <janimo> I saw it mentioned in the spec
[07:09] <pitti> mdz_: you say that users who use -updates should not get security updates?
[07:09] <mdz_> pitti: the two supported configurations are: security+updates, and security-only
[07:09] <pitti> janimo: you mean in LangpacksDesktopfiles?
[07:10] <janimo> yes
[07:10] <pitti> mdz_: right, but if the -updates version is newer than -security, then -updates needs to be fixed as well
[07:10] <mdz_> pitti: or -security needs a higher version
[07:10] <pitti> mdz_: right, when the -updates changes are merged into -security; this branch unification helps me, but isn't always appropriate IMHO
[07:11] <pitti> it was for evolution, that's why I did it
[07:13] <pitti> janimo: whichever library xubuntu uses to parse desktop files need to be taught to use gettext() for the translation instead of just taking the translated string in the desktop file
[07:13] <janimo> pitti, ok
[07:14] <janimo> so .desktop file no longer contain texts for all locales?
[07:14] <pitti> janimo: the new changes in dapper for ubuntu won't break anything in xubuntu, don't worry; it's just an added feature
[07:14] <pitti> janimo: they will, for backwards compatibility and e. g. for xubuntu or users of other WMs
[07:14] <pitti> janimo: we will just additionally use langpack translations to update/add translations
[07:14] <wasabi_> Uh so what's the "status file" refered to by /usr/sbin/install-docs?
[07:15] <janimo> pitti, thanks
[07:15] <wasabi_> ahh.
[07:17] <pitti> mjg59: ping
[07:20] <Kamion> mpt: the GnomeDruid class looks ideal for implementing the top level of https://wiki.ubuntu.com/UbuntuExpress/GnomeUserInterface, except that it has slightly different button arrangements which don't appear to be customisable
[07:20] <Kamion> you always get Cancel, Back, and Forward, and there's a switch to change Forward to Finish
[07:20] <Kamion> do you feel strongly enough about it that I should use something else?
[07:22] <mjg59> pitti: Hi
[07:22] <Kamion> or is GnomeDruid crack?
[07:22] <Amaranth> Isn't GnomeDruid one of those deprecated "kill me now" kind of widgets?
[07:22] <pitti> mjg59: I currently review laptop-mode to make acpi-support installable again
[07:22] <Kamion> Amaranth: I have no idea. How is one supposed to tell?
[07:22] <Kamion> and what's recommended instead?
[07:22] <Amaranth> Kamion: Hopefully it'd be in the documentation.
[07:23] <Kamion> Amaranth: hahahahaha
[07:23] <pitti> mjg59: the shell script is scaringly long :) but all this code is just called from the /etc/power scripts anyway, so it does not process user input, right?
[07:23] <Amaranth> Kamion: And _none_ of the documentation says what replaces it.
[07:23] <ogra> afaik there was momentum to drop GnomeDruid ages ago
[07:23] <ogra> but since this didnt happen *shrug*
[07:24] <Diziet> dchroot--
[07:24] <Kamion> ok, somebody tell me what to use instead and I'll happily use it; I have no attachment to anything in particular, it just seemed plausible
[07:24] <pitti> mjg59: erm, laptop-mode-tools, of course
[07:24] <Diziet> Cannot run commands in the chroot when the command starts with a `-'.
[07:24] <mpt> Kamion, somebody asked me about a design detail for GnomeDruid's replacement recently
[07:24] <Kamion> Diziet: no --?
[07:24] <mpt> I don't remember who it was
[07:24] <ogra> just plain glade with a content win and two buttons at the bottom ? 
[07:24] <mjg59> pitti: Right
[07:24] <Burgwork> Kamion, it appears to be here --> http://live.gnome.org/AddedDeprecatedInterfaces
[07:24] <pitti> mjg59: are you happy with it from a functional POV?
[07:25] <Diziet> kamion: No.  But you can use the first bug to work around the 2nd.
[07:25] <Amaranth> What does GnomeDruid get you that a dialog and a couple lines of code doesn't?
[07:25] <mjg59> pitti: Yup
[07:25] <Diziet> dchroot ' -command' works but shouldn't.
[07:25] <janimo> Kamion, do you think the UE installer will need gnome libs besides glade/gtk?
[07:25] <Kamion> ogra: it wouldn't be a content Window, it would be something else. What would the content widget be called?
[07:25] <pitti> mjg59: ok, fine, thanks; I'll do a report and some QA review
[07:25] <Kamion> janimo: pluggable UI
[07:25] <janimo> yes but the gnome ome
[07:25] <janimo> one
[07:25] <Kamion> janimo: and I'm not getting into that now because I have *this* problem to solve
[07:25] <pitti> mjg59: could you please LSBify the init script?
[07:25] <mdz_> Kamion: did you do your baz->bzr stuff using tailor, or bzr --baz-import?
[07:25] <Kamion> janimo: I have absolutely no idea and don't want to think about it now
[07:25] <Kamion> mdz_: bzr.integration on chinstrap
[07:26] <Robot101> Kamion: http://live.gnome.org/ProjectRidley_2fEggAssistant
[07:26] <mjg59> pitti: Sure
[07:26] <ogra> Kamion, you have a win, a hbox and put the content in the upper part of the hbox.. add a buttonbox at the bottom part 
[07:26] <Robot101> Kamion: EggAssistant is the mooted replacement for GnomeDruid
[07:26] <Amaranth> libgnomeprintui is "not a part of the Platform"?
[07:26] <Burgwork> Kamion, http://bugzilla.gnome.org/show_bug.cgi?id=115348
[07:27] <Kamion> ogra: seems kind of inconvenient for changeable content; ideally I'd have a top-level widget for the content so that I could put the pages in separate glade files
[07:27] <Kamion> Burgwork: deprecated> that page lists three gnome_druid_* functions none of which I care about :)
[07:27] <ogra> you can put whatever you want into the top part of the hbox ...
[07:27] <Kamion> ogra: not a Window, surely?
[07:27] <ogra> but EggAssistant might be right, didnt work with it yet
[07:28] <Kamion> anyway, gotta go for dinner
[07:28] <mpt> Kamion, I'd rather not have (effectively) two cancel buttons at every step (I'm squeamish even about having two in the first step)
[07:28] <Burgwork> Kamion, the bug is what you care about, that lists the patches for eggassistant
[07:28] <ogra> nope, indeed, not a window
[07:28] <pitti> mjg59: it looks like this package should be shipped for ppc as well, right? hd spindown will likely work there
[07:28] <Kamion> Burgwork: ok, I don't want to use anything not in the distro yet though, I have enough to do
[07:28] <mjg59> pitti: Should do, yup
[07:29] <Burgwork> Kamion, my thought is that eggassisant is sort of a dapper+1 thing
[07:29] <Robot101> Kamion: it's conventional to just copy egg widgets in to your app :-S
[07:29] <Kamion> Burgwork: run away, then ...
[07:29] <Kamion> Robot101: run away harder
[07:29] <pitti> mjg59: so instead of making it an acpi-support dependency, what do you think of seeding it to desktop?
[07:29] <Robot101> Kamion: everyone has one in their app somewhere :)
[07:29] <ogra> Kamion, eggs might fit well with a dapper :)
[07:29] <Kamion> ogra: I need a top-level widget that can be the root of a glade file
[07:29] <Kamion> Robot101: not this app
[07:29] <pitti> mjg59: (assuming that you just added the dependency to pull the package in; not sure if it is actually required by acpi-support now)
[07:30] <Kamion> well, not copied C code anyway
[07:30] <ogra> well, the druid widget isstill there ... it just looks a bit ugly imho ...
[07:30] <Kamion> sounds like it doesn't meet mpt's requirements, so fair enough
[07:32] <ogra> Kamion, but why do you want a single glade file for every page i wonder ? 
[07:32] <Kamion> ogra: life is always easier when things are modular
[07:32] <ogra> you can just reparent non-top-level widgets
[07:32] <ogra> and keep all in one glade file
[07:32] <Kamion> ogra: in this case I can put the separate glade files in different packages, conceivably
[07:33] <Kamion> I do not want one enormous glade file that's a pain to edit and impossible to look back through its history
[07:33] <ogra> true, but then you will need something like druid ...
[07:33] <slomo> elmo: please sync swt-motif from debian/unstable... ubuntu changes can be dropped
[07:36] <pitti> mdz, mjg59: laptop-mode-tools report written and approved (assuming that it get an LSB init script)
[07:37] <Diziet> Woah, bzr is in universe ??
[07:56] <slomo> elmo: please sync skippy from debian/unstable... ubuntu changes can be dropped
[08:00] <slomo> pitti: are the few points by an upstream dev i added to the avahi main inclusion report useful for you?
[08:01] <Riddell> slomo: got a URL for that?
[08:01] <slomo> Riddell: https://wiki.ubuntu.com/MainInclusionReportAvahi
[08:01] <Riddell> thanks
[08:02] <BenC> FYI, linux-source-2.6.15, linux-meta and linux-restricted-modules all uploaded for 2.6.15-7.9
[08:02] <ogra> and amd64 already built :)
[08:02] <BenC> may your machines all reboot safely
[08:03] <slomo> ppc too
[08:03] <BenC> yeah, ppc and amd64 seem to be kicking i386's ass
[08:03] <BenC> ppc64 beware, I know jbailey is experiencing lockups on his G5 randomly, seems to be X related
[08:04] <mdz_> seb128: XCHAT ^W FURY
[08:04] <slomo> Riddell: are you also interested in getting avahi into main for kde?
[08:04] <Riddell> slomo: certainly am
[08:04] <mdz_> can someone tell me the IP address from which I connected the last time I connected here?
[08:04] <Riddell> 19:04 -!- mdz_ [n=mdz@69-175-232-197.vnnyca.adelphia.net]  has left #ubuntu-devel ["Ex-Chat"] 
[08:04] <mdz_> Riddell: thanks
[08:05] <mdz_> hmm, no, that's where I'm connected from now
[08:05] <mdz_> i mean the previous time
[08:05] <seb128> mdz_: your patches are welcome :)
[08:05] <ogra> -> mdz_ (n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net
[08:05] <BenC> mailto:n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net
[08:05] <mdz_> thanks
[08:05] <slomo> Riddell: cool, i'll most probably update to 0.6.1 tomorrow... are the kde pieces already 0.6-compatible?
[08:05] <BenC> s/mailto:/
[08:05] <ogra> lol
[08:05] <mdz_> silly dynamic IPs
[08:05] <ogra> xchat i great
[08:05] <ogra> *is
[08:06] <Riddell> slomo: hmm, no idea, I'll ask
[08:06] <Riddell> slomo: much changed?
[08:08] <mdz_> seb128: I can send you my old xchat patch which disables the shortcut the easy way ;-)
[08:08] <slomo> Riddell: the API changes slightly... all current packages we have which are using avahi (i.e. nss-mdns and s-d-a) already work with the new API
[08:08] <seb128> mdz_: easy fix for you
[08:09] <seb128> mdz_: open the "Discussion" menu, go on the "close" label, press backspace
[08:10] <seb128> mdz_: you need to have /desktop/gnome/interface/can_change_accels (gconf) set
[08:11] <ogra> BenC, if you are interested in a user experiencing #16874 / #1994, there is one in #edubuntu
[08:12] <BenC> ogra: with dapper kernel?
[08:12] <ogra> nope, breezy
[08:13] <BenC> 16874 says it was fixed upstream in 2.6.14-rc
[08:13] <ogra> he cant use the card on install apparently ... but since he sets up the system for a review, he might be willing to play around with it ...
[08:13] <ogra> ah, k
[08:13] <dholbach> brb
[08:14] <ogra> i just noted the bug was NEEDINFO
[08:14] <ogra> didnt look deeper into it
[08:14] <pitti> slomo: everything is useful for these reports :) I didn't yet look at it, though; I'm off tomorrow, and had some higher-urgency things today, sorry
[08:20] <Burgwork> mpt, ping
[08:20] <mpt> Burgwork, pong
[08:21] <Burgwork> mpt, do you have the mockup for the new logout dialog?
[08:23] <slomo> pitti: np :)
[08:24] <mpt> Burgwork, no, but I could rustle one up right now if you want
[08:24] <mpt> (or in six minutes, at least)
[08:24] <Burgwork> mpt, np if you don't have one on hand
[08:24] <Burgwork> I thought I saw one
[08:26] <mpt> Burgwork, you probably saw my shutdown dialog
[08:27] <Burgwork> mpt, yes, but where is taht one the wiki?'
[08:28] <ogra> mdz_, pitti gnome-screensaver main inclusion report ready ...
[08:29] <mpt> Burgwork, https://wiki.ubuntu.com/PowerManagementConfiguration#head-86fd22dbf812daed4c3bcb0d55f12a6b5b9f1f56
[08:30] <ogra> mpt, where is hibernate ? 
[08:30] <mpt> ogra, that's what I was discussing this morning with dholbach and co.
[08:30] <mpt> how to make the distinction between Sleep and Hibernate
[08:31] <ogra> in german it says sleepmode (Disk) and sleepmode (Memory) here in the current logout dialog
[08:31] <mpt> eww
[08:32] <ogra> which is not perfect, but quite good already imho
[08:32] <ogra> since its both "sleep"
[08:34] <ogra> Your rationale doesnt cover low battery warnings for wireless mice or keyboards ? 
[08:35] <ogra> why is that ? 
[08:36] <mpt> That's not my rationale
[08:36] <ogra> ah, ok
[08:36] <ogra> i thought it is ...
[08:36] <mpt> I did the Use cases and Design sections
[08:37] <mpt> well, rewrote the use cases to be more than one sentence each :-)
[08:37] <ogra> heh
[08:37] <ogra> yes, our specs are all pretty bad literature ;)
[08:46] <ogra> pitti, i'm wondering how long it takes until he draws a full line over the screem :)
[08:46] <ogra> *screen
[08:46] <pitti> heh
[08:46] <sivang> \sh: https://www.linkedin.com ?
[08:46] <\sh> sivang: jepp
[08:47] <sivang> \sh: seems cool
[08:47] <Kamion> oh, that thing that people keep using to spam me
[08:48] <\sh> Kamion: I need to improve my connections to other countries and other people and other managers to have a new job  VERY SOON
[08:48] <HiddenWolf> jdub, ping
[08:49] <janimo> pitti, firewall spec is being worked on by someone or deferred?
[08:50] <ogra> janimo, isnt that from breezy ? 
[08:50] <pitti> janimo: that's carstenh 's playground
[08:50] <janimo> ogra, dapper low prio too I think
[08:53] <elmo> BenC: server-{high,low}end ?
[08:57] <dilinger> hm?
[08:58] <ogra> dilinger, see dapper-changes :)
[09:00] <dilinger> heh
[09:01] <Riddell> ogra: I've added about 4 lines.  (and a lot of debugging due to random buildd breaking)
[09:01] <mdz_> BenC: I'd prefer that we used server-generic and server-highend, or even just server and server-highend
[09:01] <BenC> ok, easy change
[09:01] <ogra> Riddell, i'm just seeing all these uploads :)
[09:02] <elmo> what _is_ server-highend?
[09:02] <BenC> > 8 CPU's
[09:02] <BenC> Summit/ES7000/BIGSMP kernel
[09:02] <BenC> like machines that cost as much as my house type deals
[09:02] <elmo> hum
[09:03] <elmo> not to bikeshed, but wouldn't -bigiron or -moremoneythansense be better?
[09:03] <Keybuk> -fabbione
[09:03] <ogra> ++
[09:03] <elmo> I'd consider a fully loaded 4-way DL585 high end, but maybe mark just isn't buying me the right sort of presents
[09:04] <BenC> the naming scheme is going to be pretty moot, since we'll have to document what exactly they are for anyway
[09:04] <BenC> no matter what you call the bigone, people are going to say "well, this is a bug server to me, so let's install it"
[09:04] <BenC> s/bug/big/
[09:05] <elmo> oh, oh, I know
[09:05] <elmo> kernel-server-SUPERSIZEME
[09:05] <elmo> or kernel-MAXIMUM-server
[09:05] <BenC> personally I wanted -server-EATS_GOATS_FOR_DINNER
[09:06] <dilinger> -realultimatepower?
[09:06] <Keybuk> bigiron is the best suggestion so far, sysadmins tend to know what that means
[09:06] <Keybuk> the kind of server that you need structural support in the floor to buy
[09:06] <BenC> exactly
[09:07] <BenC> ok, -server and -server-bigiron it is
[09:07] <BenC> you people are never around when I bring this up _before_ releasing it :P
[09:07] <ogra> change your timezone  :)
[09:08] <BenC> being online 16 out of 24 hours doesn't matter? :)
[09:08] <sivang> \sh: I need to add myself there as well .... Or else I will be QAing on windows as well , which is urgh^2 :-/
[09:08] <\sh> sivang: email?
[09:08] <sivang> \sh: you mean, mine? :)
[09:08] <ogra> BenC, hmm, might be the wrong 16h then :)
[09:08] <\sh> sivang: yes
[09:08] <sivang> \sh: PM you
[09:09] <zyga> \sh: kudos for the MOTU school
[09:10] <zyga> \sh: what is the shedule?
[09:10] <ajmitch_> morning
[09:10] <\sh> zyga: 10th dec, ajmitch will held a lesson about "packaging without debhelper or cdbs"
[09:11] <zyga> \sh: what time?
[09:12] <zyga> I'll gladly attend
[09:12] <zyga> :-)
[09:12] <zyga> also: are thre any logfiles?
[09:12] <sivang> \sh: what lessons have I already missed ?
[09:12] <ogra> shuffling around zeros and ones until you have a deb  ?
[09:12] <zyga> like irc logging
[09:12] <ajmitch> still considering what time is going to hurt people the least
[09:12] <zyga> #ubuntu-school or something :-)
[09:12] <ajmitch> either 10:00 UTC or 18:00 UTC
[09:12] <zyga> ajmitch: average of the timezone probably 
[09:12] <\sh> zyga: #ubuntu-motu-school
[09:12] <zyga> +18
[09:12] <ajmitch> I'll be sleeping between those times ;)
[09:13] <\sh> ajmitch: 18 UTC is quite nice I think for everybody :)
[09:13] <ajmitch> \sh: that'll put a definite 2 hour limit on it
[09:13] <zyga> UTC == +0 timezone?
[09:13] <ajmitch> I need to leave by 20:00 UTC at the latest
[09:13] <\sh> zyga: yes
[09:14] <\sh> ajmitch: hmmm...17:00 UTC...I actually dunno what's your local time then
[09:14] <zyga> that suits me (and probably everyone else from eu)
[09:14] <fabbione> Keybuk: -fabbione would really sinthetize the size, doesn't it? :P
[09:14] <ajmitch> \sh: 6AM
[09:14] <\sh> ajmitch: sunday?
[09:14] <Keybuk> fabbione: I was just thinking of your love for the big iron, actually
[09:14] <ajmitch> yep
[09:15] <\sh> ajmitch: good one :)
[09:15] <zyga> is there any idea to make a recurring shedule?
[09:15] <zyga> like every week?
[09:15] <fabbione> Keybuk: ehehe
[09:15] <\sh> zyga: there will be a presentation 
[09:16] <ajmitch> \sh: *maybe* 6 AM is still possible
[09:16] <ajmitch> if I go to sleep reeally early ;)
[09:17] <ajmitch> ok, got to run to work
[09:18] <\sh> ajmitch: would be cool :)
[09:22] <ogra> \sh, did you ask mike hearn about an autopackage lesson ? 
[09:22] <zyga> heh
[09:23] <\sh> ogra: I'll eat your cats the next time...grrrr
[09:23] <ogra> *g*
[09:24] <\sh> oh no...I can't eat your cats...when I'm drinking I never eat .. and you owe me bacardi gold :)
[09:24] <ogra> granted :)
[09:25] <\sh> .oO(python and no xml parser in the std lib...lol)
[09:26] <\sh> and finally my new sempron64 will be delivered tomorrow
[09:26] <\sh> I can fix the universe at least
[09:27] <ogra> the powerpc guys didnt answer my mail yet :/
[09:28] <\sh> ogra: hmmm...create an ebay account dude..
[09:28] <desrt> can i just randomly create a new upstream project in launchpad for bug-tracking purposes even if it's not packaged by ubuntu?
[09:28] <desrt> like... is this a kosher use of launchpad?
[09:29] <ogra> thast the plan of malone at least ...
[09:30] <Burgwork> desrt, yes, that is kosher
[09:30] <ajmitch> \sh: who should I give my home phone number to to wake me up? ;)
[09:30] <desrt> awesome.
[09:30] <ogra> but i'm not sure if youre supposed to creae a product of it first
[09:30] <\sh> ajmitch: your mobile number is still valid?
[09:30] <ogra> *create
[09:30] <Burgwork> desrt, one might even say that is the whole point of LP
[09:30] <desrt> Burgwork; that's excellent
[09:30] <ajmitch> \sh: nope, the phone is probably somewhere in montreal :)
[09:31] <Burgwork> people seen the new gnome bugzilla interface?
[09:31] <Burgwork> it doesn't suck!
[09:31] <\sh> ajmitch: thats why I ask...
[09:31] <ajmitch> \sh: want to post a mail to the motu list with the new time for me?
[09:31] <ogra> Burgwork, didnt look different 1/2h ago
[09:31] <\sh> ajmitch: hmm...send me your new mobile number or homephone...so I can give u a ring :)
[09:31] <Burgwork> http://bugzilla-test.gnome.org/
[09:31] <\sh> ajmitch: I'll announce :)
[09:31] <ajmitch> since 6AM should be mindnumbingly early enough for me
[09:34] <\sh> ajmitch: u will hear the lovely voice of \sh then :)
[09:34] <ajmitch> lucky me
[09:34] <ogra> Burgwork, but still very buggy... every search, no matter what for gives yu a list with 6741 bus
[09:35] <ogra> *bugs
[09:35] <Burgwork> ogra, htat is a db issue
[09:35] <Burgwork> ogra, not a UI one
[09:35] <ogra> the ui looks like bugzilla with round corners ...
[09:35] <ogra> just some different css
[09:36] <Burgwork> log in and go here --> http://bugzilla-test.gnome.org/describeuser.cgi
[09:36] <\sh> mdz: if you have time..would you be so kind an spare a few mins with amu and me to explain in detail the meaning of http://lists.ubuntu.com/archives/sounder/2005-December/003340.html ? please ping amu or me :) thx :)
[09:39] <ogra> Burgwork, seems they dont share the same DB, i cant log in there
[09:40] <Burgwork> ogra, they share the same login ID
[09:40] <ogra> doesnt work for me ..
[09:40] <Burgwork> hmm, anyway, it looks good
[09:40] <Burgwork> will be live on the 18th of Dec anyway
[09:42] <mdke> Burgwork, shiny
[09:42] <dholbach> good night
[09:42] <ogra> night dholbach 
[09:42] <dholbach> bonne nuit, ogra
[09:48] <mdke> elmo, jdub, the doc-commits mailing list is still down, can you help?
[09:50] <elmo> mdke: no it's not
[09:50] <elmo> mdke: read your email
[09:50] <mdke> elmo, i read it...
[09:51] <elmo> http://lists.ubuntu.com/archives/ubuntu-doc-commits/2005-December/001705.html
[09:51] <elmo> it's working fine
[09:51] <elmo> you're going to need better details than "it's not working" if you want me to actually look at it
[09:51] <mdke> ok
[09:52] <mdke> elmo, that message is the last one we've had, it was last week sometime. Since then we are at revision 2187, and no mails have come through
[09:52] <mdke> last 13 commits haven't come through
[09:53] <mdke> elmo, if I can give any more details, let me know what you need
[09:53] <zyga> bye guys
[10:12] <\sh> elmo: please sync gtklookat from unstable, dropping ubuntu changes ok
[10:12] <\sh> elmo: thx
[10:12] <elmo> mdke: try a dummy commit for me?
[10:12] <mdke> elmo, sure
[10:13] <mdke> elmo, sent now
[10:13] <mdke> (2188)
[10:14] <mdke> elmo, mail arrived too :)
[10:14] <elmo> mdke: right, fixed.  sorry about that
[10:14] <mdke> elmo, np thanks a lot. it was rt 1077 if you wanna close it
[10:14] <elmo> already have, thanks
[10:15] <mdke> great, thanks again!
[10:29] <seth_k> For future reference, how do you mark a bug fixed in Launchpad? I filed a merge bug, the merge was done, but I never could figure out how to mark the bug fixed... dholbach had to do it
[10:34] <fabbione> hmm
[10:34] <fabbione> is the new kernel building somewhere for i386?
[10:34] <fabbione> there are no build logs yet and it has been a few hours
[10:42] <Kamion> seth_k: edit status, up at the tpo
[10:42] <Kamion> tpo
[10:42] <Kamion> GAH, top
[10:43] <seth_k> Kamion, does launchpad have editbugs privilege requirements or something? I don't have any link like that (I reported the bug, even)
[10:43] <mdke> yeah, you need to be the assignee i think
[10:44] <seth_k> ah ha :) alright, no bustage then, I'm happy
[10:44] <seth_k> cheers Kamion, mdke 
[10:44] <Kamion> you'd have to ask on #launchpad for a definitive opinion there, I don't know
[10:58] <Nafallo> maswan: ping :-)
[11:00] <\sh> jbailey: ping
[11:00] <greenpenguin13> hey that means im adventurous :)
[11:01] <greenpenguin13> does anyone apart from me get a seg fault with synaptic on dapper?
[11:02] <mvo> greenpenguin13: I haven't had any reports about this yet, did you do a compelete upgrade to dapper? or only some packages? when does the segfault happens?
[11:02] <TerminX> on a similar note, has gnome-settings-daemon been broken since around Thanksgiving for anyone else?
[11:02] <seb128> TerminX: no bug about this
[11:02] <greenpenguin13> whenever i start dapper :(
[11:03] <greenpenguin13> had it for a while
[11:03] <TerminX> seb128: it dies with some mention of xklavier
[11:03] <seb128> TerminX: what sort of mention?
[11:03] <greenpenguin13> whenever i start synaptic even
[11:03] <TerminX> is there a pastebin site I can use to show you?
[11:04] <seb128> pastebin by example :p
[11:04] <greenpenguin13> joseph@pingu:~$ sudo synaptic
[11:04] <greenpenguin13> Segmentation fault
[11:04] <greenpenguin13> joseph@pingu:~$
[11:04] <TerminX> seb128: http://pastebin.com/451563
[11:04] <seb128> greenpenguin13: sudo gdb synaptic, (gdb) run
[11:05] <seb128> TerminX: what version of Ubuntu do you use, what keymap have you configured?
[11:05] <TerminX> I'm using Dapper right now
[11:05] <greenpenguin13> Program received signal SIGSEGV, Segmentation fault.
[11:05] <greenpenguin13> [Switching to Thread -1221753152 (LWP 6461)] 
[11:05] <greenpenguin13> 0xb749746d in __gnu_cxx::__pool<true>::_M_reclaim_block ()
[11:05] <greenpenguin13>    from /usr/lib/libstdc++.so.6
[11:05] <\sh> #ubuntu-motu-school: 2005-12-10/17:00 UTC - Topic: Packaging without debhelper and cdbs - Prof.: Andrew Mitchell 
[11:06] <TerminX> and I haven't changed any key mapping stuff
[11:06] <seb128> I've to plan a "why starting to package with cdbs" :p
[11:06] <\sh> mvo: did you rebuild it?
[11:06] <mvo> greenpenguin13: can you please type "bt" and put the result (a long list) into paste.ubuntulinux.nl?
[11:06] <\sh> seb128: jbailey just applied...you do "Gnome Packaging the right way" :)
[11:06] <greenpenguin13> sure
[11:06] <mvo> \sh: yes, it should work
[11:07] <ajmitch> \sh: what is jbailey teaching?
[11:07] <mvo> \sh: but *should* is the important bit here :)
[11:07] <\sh> ajmitch: cdbs :)
[11:07] <ajmitch> yay :)
[11:07] <seb128> ajmitch: your course sucks
[11:07] <ajmitch> seb128: sure it does
[11:07] <jbailey> ajmitch: My talk is probably "Enhancing your sex life with cdbs"
[11:07] <\sh> mvo: you bet :)
[11:07] <ajmitch> seb128: \sh made me do it
[11:07] <seb128> I don't get why you guys trying pushing beginner to hard stuff
[11:07] <jbailey> I'm trying to work on the same theory that the gnome people are.  If a product doesn't help you get laid, it doesn't have mass market appeal.
[11:07] <seb128> to make them run away?
[11:07] <ajmitch> jbailey: hm, I didn't find that in the source yet :)
[11:08] <seb128> jbailey: ah ah :)
[11:08] <\sh> jdub: please teach me the breezy/dapper/whatever dance..the next time I need to dance with you on the "PR stage" ,)
[11:08] <ajmitch> seb128: because cdbs is great when you know what you're doing
[11:08] <seb128> jbailey: what's going on with cdbs2, we still lack multibuild ...
[11:08] <jbailey> jdub: I vote for the whatever dance.
[11:08] <seb128> ?
[11:08] <ajmitch> seb128: plenty of people still just use dh_make templates without understanding debhelper at all
[11:09] <jbailey> seb128: Aren't you supposed to be asleep? =)
[11:09] <\sh> ok...just for the rational
[11:09] <seb128> ajmitch: I don't think you need to know the internals of everything to start
[11:09] <ajmitch> seb128: certainly not
[11:09] <seb128> jbailey: it's only 11pm :)
[11:09] <jbailey> One thing I do appreciate is that at least ajmitch's talk is a *true* bare bones talk.
[11:09] <TerminX> seb128: do you have any ideas about that gnome-settings-daemon issue?
[11:09] <jbailey> As opposed to "cdbs it too high level.  Let's use debhelper instead" =)
[11:09] <ajmitch> jbailey: I'll try & use dpkg-dev at least :)
[11:09] <\sh> debhelper and cdbs are cool helper applications...but if you don't know what happens behind the scene, it will cause more troubles.
[11:10] <seb128> ajmitch: packaging without any dh_* is likely to just scare people away
[11:10] <jbailey> ajmitch: I think you have to.  Last I heard, they're not real ar archives.  They only pretend to be.
[11:10] <\sh> seb128: no
[11:10] <seb128> should I start running away?
[11:10] <jbailey> Anyhow, really going grocery shopping this time. =0
[11:10] <seb128> I'm lucking not beeing a motu :p
[11:10] <\sh> seb128: stop...you are using a keyboard where you enter the numbers with "shift"
[11:11] <ajmitch> seb128: it's not mandatory to attend :P
[11:11] <\sh> seb128: so you can't be scared by "packaging without anything"
[11:11] <seb128> no, but I think that's pretty useless
[11:12] <\sh> seb128: it's building a wall of knowledge
[11:12] <seb128> you don't need to be a Makefile wizard to use dh_*
[11:12] <seb128> that's crap
[11:12] <\sh> seb128: do you think many people are reading manpages?
[11:12] <\sh> or info pages?
[11:12] <seb128> no
[11:12] <\sh> see..
[11:12] <seb128> and?
[11:12] <\sh> we will change it
[11:12] <greenpenguin13> there
[11:12] <seb128> that's not showing them 400lines of Makefile that will fix the issue
[11:12] <seb128> sure
[11:13] <ajmitch> seb128: I'll try & keep it gentle & explain as much as possible
[11:13] <seb128> ajmitch: still, reading a "good old way hand made Makefile of 400 lines" is nothing useful to package using dh_*
[11:13] <ogra> seb128, most packages arent cdbs packaged, soif you have to fix stuff, cdbs is the worst to start 
[11:13] <seb128> I'm pretty sure nobody will learn for an 1 hour course
[11:14] <seb128> you should rather teach them to use the dh_*
[11:14] <ogra> yes
[11:14] <mdke> hi all, has anyone got time/strength of will for some dapper new kernel/udev debbugging? or shall I just go to bugzilla?
[11:14] <\sh> seb128: it's a start...and we will build on this knowledge..it's not "use it for daily use" but it's "now you know the truth, and now you can hide the truth as daily business"
[11:14] <seb128> that's like saying people need to now asm to do python
[11:14] <ogra> but ajmitch wants to starts the basics of dh_make
[11:14] <ogra> seb128, thats wrong
[11:15] <ogra> seb128, most motu work is done on existing packages
[11:15] <greenpenguin13> all on there
[11:15] <ogra> most pacxkages we have arent cdbs
[11:15] <seb128> I'm not speaking about cdbs but the dh_*
[11:16] <ogra> seb128, if you want to be a car mechanic you shoul knoe what a wrench is, dont you ? 
[11:16] <\sh> infinity wanted to see that all motus are going the "NM/DD" way...we start it now, alltogether..even ogra will attend and learn
[11:16] <ogra> bah, my typing sucks
[11:16] <seb128> modern car have a lot of electronic and people probably don't know how to program the CPU
[11:16] <seb128> and they don't need to
[11:17] <ogra> they need to nowadays
[11:17] <\sh> seb128: see..we will show them :)
[11:17] <seb128> they just know they have to plug the calculator on it
[11:17] <seb128> bah
[11:18] <Kamion> come on, "program CPU" is not a good analogy for "stick files in a package somewhere" - the latter is hardly rocket science
[11:18] <ogra> seb128, we have a lot of old 2CV in the archive ;)
[11:18] <\sh> seb128: sorry..there is no way back..not for ajmitch not for me...the announcement is made...and we will stick to it...and I have a lot of feedback
[11:18] <Kamion> I think you're making it out to be an awful lot harder than it is
[11:18] <\sh> ogra: lol
[11:18] <\sh> Kamion: believe me when I say it will be fun...and it's not hard to understand
[11:19] <seb128> ogra: I doubt you have a lot of packages not using dh_* and having packaging bugs to fix
[11:19] <Kamion> I think you have a strange idea of fun, but it's up to you :)
[11:19] <ogra> \sh, he's not opposing you
[11:19] <Kamion> generally I've inherited them, but still
[11:19] <ogra> seb128, thats true... butits still good to know the basics 
[11:19] <\sh> and thinking about jbailey explaining cdbs from scratch...
[11:20] <seb128> and I didn't find that fun
[11:20] <seb128> neither useful for what I'm doing now
[11:20] <ogra> because you switch everything to cdbs :P
[11:20] <ajmitch> it's not so much the doing, as the explaining
[11:20] <seb128> they will not keep anything of what you explain
[11:20] <Kamion> it's still just cp, install, and a couple of pretty well-documented dpkg-* commands. kind of different from assembly versus python
[11:20] <ajmitch> we don't expect everyone to run out & package without it
[11:21] <\sh> seb128: as I said : "How to package gnome/kde software with cdbs"..I'll ask riddell to second you :)
[11:21] <seb128> we would better explain what the dh_* are and how to use them
[11:22] <\sh> seb128: when do you have a free timeslot? January that is
[11:22] <ajmitch> seb128: which is what I'll try & do
[11:22] <ogra> in my example ite the equivalent of a spark plug and a carbruretor 
[11:22] <mvo> greenpenguin13: any luck with the backtrace yet? 
[11:22] <seb128> I don't want to participe to this stuff :p
[11:22] <\sh> seb128: you just applied :) thx :)
[11:22] <greenpenguin13> should be on paste.ubuntu.nl
[11:22] <ogra> seb128, do a class about cdbs :)
[11:22] <Kamion> I can see why that requirement is there in NM; having been an AM I found it impossible to distinguish actual talent from dh_make, so I had to have *some* way to test people
[11:22] <Kamion> well, not a requirement, it's one option that AMs use
[11:22] <\sh> Kamion: AM?
[11:22] <Kamion> I would prefer some other option if it were available
[11:23] <Kamion> \sh: Debian application manager
[11:23] <ogra> \sh, application manager 
[11:23] <\sh> Kamion: ah
[11:23] <\sh> Kamion: thx..again I learned something new :)
[11:23] <seb128> Kamion: I don't say it's not useful for NM, I say I doubt it's really useful for maintaining a package with a modern packaging system 
[11:23] <ogra> \sh, call it "packaging teacher and tester"
[11:23] <Kamion> nowadays I imagine I'd say "ok, now please explain to me why each of those bits are there and what they do"
[11:24] <Kamion> seb128: sure, I'd tend to agree; perhaps ajmitch's talk should be viewed as "a guide to the guts of the Debian packaging toolchain"
[11:24] <seb128> right :)
[11:25] <Kamion> rather than a howto
[11:25] <\sh> Kamion: would you like to speak up for the "Debian way of a packagers life"? I would like to see our ancestors being mentioned...
[11:25] <daniels> meh, packaging without dpkg is the true test of one's mettle.
[11:25] <Kamion> \sh: with my current workload, not especially, although maybe later
[11:25] <seb128> hey daniels
[11:26] <ajmitch> morning daniels 
[11:26] <\sh> Kamion: would be cool...well, this educational thing is growing..I have a load of topics right now..and I have to sort it out
[11:27] <daniels> yo sebarino, ajmitch, mvo
[11:27] <\sh> daniels: g'evening :) and thanks for giving back xvfb-run :)
[11:27] <daniels> mvo: sorry I didn't get back to you about your dri problem; completely forgot
[11:27] <daniels> \sh	np
[11:28] <mvo> daniels: oh, not a big issue. I'm just itching to use my shinny r300 for something usefull :)
[11:28] <seb128> TerminX: what keymaps do you use?
[11:28] <seb128> daniels: is there any slowness issue due to new xorg? It takes like 1-2s to draw the nautilus background when switching desktops here
[11:28] <TerminX> seb128: whatever is default AFAIK
[11:28] <\sh> Kamion: btw...when do you have time to speak about ubuntu-express and kde ui add?
[11:28] <seb128> daniels: that happens for like 10 days
[11:29] <seb128> TerminX: gconftool-2 -R /desktop/gnome/peripherals/keyboard/kbd
[11:29] <daniels> seb128: not that I know of ... what sort of hardware?
[11:29] <seb128> daniels: ATI 9600 pro, "ati" driver
[11:29] <daniels> seb128: weird
[11:29] <TerminX> seb128: says us pc104 with overridesettings = false and no options set
[11:29] <daniels> seb128: if anything, it should've got *faster*
[11:29] <\sh> ogra: do you have a nvidia card in your laptop?:
[11:29] <mvo> daniels: oh, I have the same issues, I blamed gtk so far :P
[11:29] <Kamion> \sh: I'm writing the guts of it at the moment, so now is not a great time because I don't actually really know how it'll work yet
[11:29] <ogra> yup
[11:29] <seb128> it doesn't happen without nautilus
[11:30] <mvo> (ati as well)
[11:30] <Kamion> \sh: I'm hoping to have the structure nailed down a bit more solidly in the next week or two; maybe then
[11:30] <seb128> daniels: could it be a xrender issue? I know that cairo has some workaround for slowness like this
[11:31] <seb128> TerminX: could you copy that on pastebin?
[11:31] <\sh> Kamion: ok...I actually don't know if we can make it for dapper or not...but we need some background about how we can plug in the qt/kde UI and what we can use for some things..speaking of "replacement of gparted", world map for timezones etc.
[11:32] <\sh> ogra: is it working with the orig. nvidia drivers on amd64?
[11:32] <Kamion> \sh: oh, all the background for that is already in the wiki; start with https://launchpad.net/people/kamion/+assignedspecs
[11:32] <daniels> seb128: i think that was only for repeating offscreens though
[11:32] <ogra> \sh, i didnt try for some time 
[11:32] <ogra> but it used to
[11:33] <daniels> seb128: try Option "AccelMethod" "EXA" and run xcompmgr -a if you want a shiny fast desktop
[11:33] <seb128> daniels: I would like to have the same speed as before without using new options to start
[11:33] <\sh> Kamion: wow..u improved the specs..I should invest more time, when I'm not working anymore :)
[11:33] <seb128> daniels: it takes like 2s to switch workspace atm, and I do switch workspaces a lot
[11:34] <Kamion> \sh: there's a lot more there than there was at the start of UBZ, yes ;)
[11:35] <TerminX> seb128: http://pastebin.com/451619
[11:35] <TerminX> (changed it to pc101 in gnome-keyboard-properties because I have a 101 key keyboard but as I expected it didn't do anything)
[11:37] <mvo> seb128: do you have working dri on your ati with dapper?
[11:38] <daniels> i think it needs a new drm
[11:38] <seb128> TerminX: does "setxkbmap -model pc101 -layout us -option '' -print | xkbcomp - :0.0" works as expected?
[11:38] <daniels> seb128: yeah, I'm just curious if it's a geberal thing or an XAA thing specifically
[11:38] <seb128> mvo: how do I know that?
[11:39] <seb128> daniels: BTW while you are around :p
[11:39] <seb128> $ Xnest :1
[11:39] <seb128> error opening security policy file /usr/lib/xserver/SecurityPolicy
[11:39] <seb128> Could not init font path element /usr/share/X11/fonts, removing from list!
[11:39] <seb128> Fatal server error:
[11:39] <seb128> could not open default font 'fixed'
[11:39] <ogra> seb128, do a benchmark with glxgears *giggle*
[11:39] <TerminX> seb128: apparently nothing on my system depends on package xkbutils because it isn't installed
[11:39] <mvo> seb128: glxinfo will tell you
[11:39] <seb128> TerminX: ah ah
[11:39] <TerminX> shall I install it?
[11:39] <seb128> yep
[11:39] <seb128> mvo: direct rendering: Yes
[11:39] <TerminX> wait, what the hell
[11:40] <mvo> aoooohhh, I have working dri as well. something happend on the last upgrade. 
[11:40] <TerminX> seb128: okay, what you told me to do gives me errors, pastebin them?
[11:40] <seb128> TerminX: ?
[11:40] <TerminX> that setxkbmap line you gave me gives me errors
[11:41] <TerminX> http://pastebin.com/451637
[11:41] <jdong> ugh what a day it's been already.....
[11:41] <jdong> is elmo around?
[11:41] <seb128> TerminX: xorg issue, bouncing to daniels ;)
[11:41] <seb128> TerminX: g-s-d is doing this setxkbmap call
[11:41] <ogra> xserver-common bg
[11:41] <ogra> bug
[11:41] <TerminX> okay
[11:42] <seb128> this syntax error is weird
[11:42] <daniels> ARGH!
[11:42] <daniels> TerminX: you get that too?
[11:42] <TerminX> yeah
[11:42] <daniels> it's complaining about compat/misc
[11:42] <daniels> i haven't been able to track it down
[11:43] <daniels> seb128: heh, cool
[11:43] <jdong> I've been getting very frustrated recently at the lack of response from elmo as to backports build requests
[11:43] <TerminX> in your defense, however, this install has been around forever and might have little bits of other X installs in it still
[11:43] <daniels> seb128: i'll sort out the xnest thing in a sec
[11:43] <seb128> daniels: thanks ;)
[11:43] <daniels> mvo: working dri> kernel
[11:43] <mdke> jdong, yes he is around. You can leave him a message or email though
[11:43] <jdong> mdke: you think I haven't been trying e-mail for the past 3 weeks?
[11:43] <mdke> jdong, i don't think
[11:43] <daniels> also, xbase-clients depends on xkbutils
[11:43] <mvo> meh, starting ppracer gave me a blank screen and dosn't want to give anything back
[11:44] <TerminX> daniels: yeah, that was a mistake on my part
[11:44] <TerminX> (about it not being installed I mean)
[11:44] <mvo> (that is, it doesn't want to become a non-blank screen)
[11:44] <daniels> TerminX: does rm -rf /etc/X11/xkb/{symbols,compat} && sudo dpkg -i --force-confmiss /var/cache/apt/archives/xkeyboard-config_0.6-8_all.deb, help?
[11:44] <daniels> mvo: heh, cool
[11:44] <TerminX> I'll check, sec
[11:44] <jdong> this current Backports system isn't working out... I can't live with an unpredictable build timeframe.... that spikes into 3+ weeks at times
[11:45] <jdong> I get the feeling like the Backports Project is being ignored around here and shoved to the bottom
[11:45] <jdong> which is fine and I understand there are other priorities
[11:45] <jdong> but the current build/mirror/archive architecture is not working too well with me since the beginning of Breezy
[11:45] <TerminX> daniels: I still get the error
[11:47] <mdke> jdong, if you don't find the right person here in irc, perhaps it would be worth emailing the devel mailing list to discuss it
[11:48] <daniels> TerminX: argh
[11:48] <jdong> mdke: thanks; I'll first try leaving him a message, then perhaps I'll go off to the mailing list
[11:48] <mdke> cool
[11:48] <jdong> mdke: I'm usually very patient :)... Just with all the forums crap also going on today, I'm getting kinda cranky :)
[11:48] <\sh> daniels: can you have a look at http://bugzilla.ubuntu.com/attachment.cgi?id=5186 and http://bugzilla.ubuntu.com/attachment.cgi?id=5187..there is some issue with xauth I think
[11:49] <TerminX> daniels: also, is it normal that I have to manually set mod5 to scroll lock using xmodmap?
[11:49] <mdke> jdong, i'm sure you can find a solution that works for everyone
[11:51] <elmo> jdong: you're being a little disingenuous - AFAIK there hasn't been a 3+ week delay ever.  backports wasn't created for quite some time due to the various LP vs DAK issues.  then it was created, and someone decided that meant backports was open.  it wasn't.
[11:51] <jdong> elmo: can you push through the 5 or so outstanding requests, and also a rebuild of vlc?
[11:51] <elmo> jdong: and your requests aren't making things easier either.  the requests to me should be final "backport this", not 10+ msg threads about whether or not it should be backported, and maybe foo should too
[11:52] <jdong> elmo: sorry about the occasional trail of messages that tend to go with disagreements about backporting X or Y....
[11:52] <jdong> elmo: is there a bug tracking system or some other way you'd prefer?
[11:52] <elmo> jdong: bbias, I need to deal with something else
[11:53] <daniels> TerminX: that's a symptom of missing xkb
[11:53] <TerminX> ah
[11:54] <TerminX> that happened about a year ago I think, I set up a script to fix it whenever I logged in and kind of forgot about it :)
[11:55] <daniels> \sh: sounds like it's simply not working, though no idea why
[11:55] <TerminX> I think that was way back when it was still a sid install before warty, actually...