[03:41] <Solarion> so, anyone around now?
[03:45] <Solarion> man, my life is going to suck for a while then
[03:45] <Kano> haha
[03:45] <Solarion> Kano: is not funny.  filesystem horkage is no joke
[03:45] <Solarion> maybe in ten years I'll be able to laugh
[03:46] <Kano> what filesystem do you use
[03:46] <Solarion> reiser is the only one atm
[03:46] <Solarion> space is at a premium, but that's not the problem
[03:46] <Solarion> lack of enabled usb persistance is my problem.
[03:47] <Solarion> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197166
[03:47] <ubotu> Launchpad bug 197166 in linux "[hardy] kernel should have usb persist mode built in" [Undecided,New] 
[03:47] <Solarion> ubotu: thanks
[03:47] <ubotu> You're welcome! But keep in mind I'm just a bot ;-)
[03:47] <Solarion> ubotu: I know, but bots rock
[03:48] <Kano> yes reiserfs is very tricky. you will lose your data fast when you oc your system or your ram is faulty...
[03:48] <Solarion> I'm not doing either thing
[03:48] <Solarion> but regardless, the reason I'm here is to discuss enabling USB pesist mode in the kernel
[03:49] <Solarion> it doesn't actually turn on usb persist mode; it only enables it.
[03:49] <Solarion> persist must still be turned on per device, so those users who don't need it won't feel the change
[03:49] <Solarion> those (like me) who need it will have their lives suck much less
[03:50] <Kano> you can recompile the kernel with that option with ease
[03:50] <Solarion> so it's pretty clear-cut to me, but then I'm not an ubuntu let alone an ubuntu kernel dev, so I might have missed it
[03:50] <Kano> did you do that
[03:50] <Solarion> Kano: I'm doing it
[03:51] <Solarion> I want to try to keep it semi-official, so I'd rather not keep doing it every time the kernel gets updated, which happens pretty often with hrdy
[03:53] <Kano> just remove the meta package
[03:53] <Kano> whats the problem
[03:53] <Solarion> I then have to maintain the kernels myself?
[03:54] <Solarion> is one of the reasons I use a distro?
[03:54] <Kano> well maybe somebody adds your option, thats of course more easy
[03:54] <Solarion> Kano: are you an ubutu kernel dev?
[03:54] <Kano> no, i am from kanotix
[03:54] <Solarion> Kano: yes, that is my hope; find out if I can get it enabled in the ubuntu build
[03:55] <Kano> no problem to do that
[03:55] <Kano> you could do that even via sed ;)
[03:55] <Solarion> to do which?
[03:55] <Kano> to enable options
[03:55] <Solarion> yeah, I know
[03:55] <Solarion> but enabling it in the ubuntu build is significantly more difficult, now isn't it?
[03:56] <Kano> i do that this way
[03:56] <Kano> yesterday somebody asked me to disable one option and then i disabled with via a sed command too - fully scripted
[03:57] <Solarion> toll, aber das hilft mir net weiter
[03:59] <Kano> guck dir das query an, in dem script sind einige tricks,wie man mit sed an config files rumspielt
[03:59] <Solarion> ich kann doch mit config files rumgehn
[04:00] <Kano> das bezweifle ich
[04:00] <Solarion> das Problem is halt, dass ich usb persist mode in *ubuntus* kern aktivieren, nicht in meinem selbstgebauten
[04:00] <Solarion> kannst ruhig tun
[04:01] <Kano> naja ich kann den u kernel nicht ändern, nur kanotix kernel
[04:01] <Solarion> Kano: dann kannste mir net weiterhelfen.  :)
[04:01] <Solarion> weiterbringen?
[04:01] <Kano> im dem script im query findest aber alle infos wie man die config von u standard kernels ändert
[04:01] <Kano> wers nicht sieht ist blind
[04:02] <Kano> bye
[04:02] <Solarion> mensh, das letzte mal, als ich in Deutschland wohnte, hab' ich in DM bezahlt.  :)
[04:04]  * Solarion notices that kano pm'ed him
[04:04] <Solarion> ah well.  I'm still not blind then.  :)
[04:09] <Solarion> sleeptime
[08:10] <kraut> moin
[14:21] <Solarion> mornin
[14:22] <Solarion> this is a very quiet channel
[14:49] <amitk> Solarion: you can start making the noise :)
[14:49] <amitk> Solarion: were you the one requesting that USB_PERSISTENCE be turned on?
[15:14] <zul> *sigh* who was asking me about nvidia xen stuff last week
[15:18] <tjaalton> zul: _o/
[15:18] <zul> tjaalton:  http://people.ubuntu.com/~chucks/nv-fix.diff is the fix for you
[15:26] <tjaalton> zul: thanks!
[15:26] <zul> np
[16:40] <Solarion> amitk: yes
[16:41] <Solarion> kraut: moin moin
[16:46] <kraut> Solarion: hi
[16:47] <Solarion> was fúr eine Art Kraut biste denn?
[16:47]  * Solarion ist UNkraut
[16:50] <kraut> sauerkraut, wenn du so weiter machst ;)
[16:50] <Solarion> heh
[17:13] <amitk> Solarion: I'll be looking at enabling USB_PERSIST sometime this week...if the default behaviour is off, then it should be in the next kernel.
[17:39] <Solarion> amitk: it is, from the documentation I read
[17:39] <Solarion> I'm compiling today's kernel (2.6.24-11) with it enabled to try it out
[17:40]  * Solarion is rather a n00b when it comes to doing kernels the Ubuntu/Debian way.
[17:57] <Solarion> amitk: ping
[18:16]  * Solarion grabs lunch
[18:20] <johanbr> crimsun_: Have you had any time for bluetooth testing? One thing that's happened is that the cvs version of the bluez audio service doesn't immediately drop the connection upon close, but reuses it in case an app reopens the connection in the next few seconds. This makes voip work much better.
[18:21] <johanbr> I think it'd be nice to have this patch in Hardy.
[18:36] <mario_limonciell> is there a trick to attempting to get a USB serial console up and running?  I've tried to include the usb-serial driver in the initramfs
[18:37] <mario_limonciell> or will I have to recompile the kernel differently to allow this at least?
[18:49] <fR_> hi, i'm trying to add a new option to the custom xen kernel config. what I've tried doing is modifing debian/binary-custom.d/xen/config.amd64, however when the scripts/kconfig/conf is run, it removes my option from the file it creates.
[18:52] <fR_> is this the correct way to do this? can I make this conf script explain why it's rejecting the option?
[19:01] <amitk> Solarion: hi
[19:11] <Solarion> amitk: do you want/need the bug number or more information?>
[19:26] <amitk> Solarion: no. As i said, I am looking into it now.. Hopefully I'll have it enabled for Hardy beta.
[19:34] <Solarion> amitk: right, I was just trying to be helpful.  :)
[19:34] <Solarion> amitk: thanks for looking in to it.
[19:40] <Solarion> hmm, if it's not gonna be in before the beta, I'm gonna have to keep compiling my own until then, particularly for next week
[20:07] <amitk> Solarion: thanks. We are in freeze for alpha 6 now, so it won't go in before beta
[20:21] <crimsun_> johanbr: a bit but not on recent hardy due to gvfs being a bit unstable.  I'll check tomorrow's daily-live
[21:13] <smb> mjg59: Hi Matthew, can you help me with a missing piece of powermanagement? When pressing the hibernate button I can follow the call chain until acpi_fakekey is called.
[21:13] <smb> mjg59: What exaclty does acpi_fakekey do? Just sending a virtual keypress (to what)?
[21:15] <mjg59> Yes, which should then be caught by hal and turned into a dbus event
[21:16] <smb> mjg59: Which then would be handled by powermanagers listening there. Has there been a change you know of which could change defautls here?
[21:17] <smb> mjg59: I am asking because I was looking at a report where the fakekey was called but the reporter claims there doesn't happen anything
[21:18] <mjg59> Nothing springs to mind
[21:21] <smb> mjg59: Hm, ok. Seems the next debugging step would then be to check for hal and dbus events. Or just plainly ask whether there is a power mannagement applet running... Thanks
[21:21] <mjg59> xev should show the keystroke
[21:24] <smb> mjg59: Got a log from showkay that shows the keypress. Could try xev as well but I expect this yields same results
[21:29] <mjg59> Hm. Showkey wouldn't show it if it was from acpi_fakekey
[21:30] <mjg59> So I suspect that's not what's happening
[21:33] <smb> mjg59: Or it might just be unrelated. Just proving the key does something at all. But then xev would be a good candidate to go on. And maybe dbus-monitor
[21:39] <BenC> smb: if showkey has it, it may just need to be mapped properly with the hotkeys-setup package for that particular model
[21:40] <smb> BenC: It already does show up in acpid.log and call the correct action script, which does then an acpi_fakekey
[21:40] <BenC> smb: hmm...sounds out of the kernel space to me then
[21:43] <smb> BenC: Sounds like it. I just wanted to make sure I don't miss a bit. But I would generically suspect power management applets/daemons. 
[21:47] <fR_> ok, I think the problem is that by selecting the XEN subarchitecture type, ARCH_SUPPORTS_MSI gets set to false, which prevents CONFIG_PCI_MSI, which is required by CONFIG_DMAR (the option I wanted to add). Does anyone here know anything about this? My understanding was that IOMMU is designed specifically for virtualization.