[00:06] <tormod> thanks a lot
[00:09] <rtg> tormod: it'll probably take a 3-4 days to show up in the archive.
[00:09] <rtg> off to a mardi gras party.
[00:10] <tormod> was just back from Carneval here :)
[00:11] <rtg> I saw pictures of that in Brazil. Looks like fun. gotta go.
[00:22] <tormod> 'night
=== asac_ is now known as asac
[08:26] <kraut> moin
[08:53] <abogani> Morning all
[08:56] <abogani> amitk: No way last -rt kernel flavour on amd64 with nvidia-glx-new driver didn't works.
[08:56] <amitk> abogani: so reinstalling the driver doesn't help?
[08:57] <abogani> amitk: "apt-get remove --purge nvidia-glx-new", reinstall and reboot don't help
[08:59] <amitk> did you try the hardy live cd?
[08:59] <abogani> amitk: 2.6.22-14.51 no, 22-14.47 works after depmod -a, before of the 22-14.47 works fine
[09:00] <abogani> amitk: In your opinion where should i look? 
[09:01] <amitk> abogani: have you tried the hardy live cd?
[09:02] <abogani> amitk: Yes it works but it is -generic or i can select -rt on boot menu? :-)
[09:02] <amitk> abogani: -rt is not on the live cd. You will have to install the -rt kernel separately
[09:03] <abogani> so i should install Hardy, right?
[09:03] <amitk> tjaalton: might have some more ideas
[09:06] <tjaalton> abogani: what was the original problem?
[09:06] <abogani> I can't explain to myself why, with the same hw, on 32bit works great and on 64bit is broken :-(
[09:06] <abogani> tjaalton: After last (security) update of the kernel X don't want start at boot with nvidia X driver on 64bit (32bit works fine)....
[09:06] <tjaalton> abogani: does it work if you disable usplash (nousplash on the kernel cmdline)
[09:07] <abogani> tjaalton: Kernel loading all things without warning or error. lsmod nvidia return Ok. 
[09:08] <abogani> X tell me this: (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module! Please ensure
[09:08] <abogani> (EE) NVIDIA(0):     that there is a supported NVIDIA GPU in this system, and
[09:08] <tjaalton> abogani: please put the full log somewhere
[09:09] <tjaalton> also the part from dmesg where it loaded ok
[09:11] <abogani> tjaalton: Ok
[10:37] <abogani> tjaalton: I have removed all -rt packages (linux-image-*-rt, linux-ubuntu-*-rt, linux-restricted-*-rt) and i have reinstalled the same and it works!
[10:38] <tjaalton> abogani: good to hear :)
[10:41] <laga> tjaalton: any change #144322 will be fixed? (a bit off-topic in here, but since i just saw you here..)
[10:41] <laga> s/change/chance/
[10:41] <tjaalton> bug 144322
[10:41] <ubotu> Launchpad bug 144322 in xserver-xorg-video-ati "interlacing broken in gutsy on radeon/ati open source driver" [Medium,Confirmed] https://launchpad.net/bugs/144322
[10:42] <tjaalton> laga: try the package from https://wiki.ubuntu.com/XorgOnTheEdge
[10:43] <laga> tjaalton: for the ati driver?
[10:43] <tjaalton> yes
[10:44] <laga> tjaalton: i compiled it manually from git and it didn't work a few weeks ago. of course, i'll try the package but i doubt it'll be fixed.
[10:45] <tjaalton> laga: then your best bet is to post your results on the upstream bug :)
[10:48] <laga> tjaalton: ah. which translates to "it'll never be fixed" because upstream is somewhat unresponsive
[10:48] <tjaalton> laga: alex happens to work for AMD/ATI now
[10:49] <tjaalton> so maybe it's not high priority, but will be fixed
[10:49] <laga> well, i figured it wouldn't be fixed because he's too busy working for them right now :) 
[10:49] <laga> there's a workaround so i'll be OK, though
[11:00] <amitk> abogani: that is weird. We don't want to become windows, so it would be good to know what happened... ;-)
[11:01] <ogra> thegodfather, dropping rpc sevices didnt help with bug 189224 ... i fear its actually the unlock thats broken for me (bug updated)
[11:01] <ubotu> Launchpad bug 189224 in linux "sunrpc causes kernel oopses on 2.6.24-5-generic" [Undecided,New] https://launchpad.net/bugs/189224
[11:07] <abogani> amitk: sounds reasonable :-)
=== doko_ is now known as doko
=== LifeHacker is now known as tuxmaniac
[16:11] <Kano> hi rtg ,did you see that alsa 1.0.16 final is out now?
[16:11] <rtg> Kano: nope, but I'll pick it up in the next couple of days.
[16:11] <Kano> i guess not much changed
[16:12] <Kano> it was out today
[16:43] <tll> Hi, it's there a rt2x00/rt73usb module backport for the gutsy 2.6.22 kernel through the module-assistant?
[16:44] <rtg> tll: not to my knowledge. furthermore, its gonna be quite difficult because of changes in the mac80211 API.
[16:53] <tll> rtg, thanks for answering - I know I'm a bit OT here. So make-kpkg is the only way out? I fear this will break the network-manager et al. stuff.
[16:54] <rtg> tll: I have not used make-kpg in awhile. It stopped working for me during Gutsy.
[16:58] <tll> rtg, I just got lazy and stopped using kpg and debian. I hate that the kernel/userlevel interdependency breaks things - so I switch to ubuntu and hope for faster release cycles. :) So here it caught me again. And I was buying ralink for the gnu-feeling ;( 
[17:01] <rtg> tll: if you can get me open sources for the ralink drivers, I could put them in l-u-m.
[17:02] <rtg> assuming, of course, that they work with 2.6.24 and have no license restrictions.
[17:04] <tll> rtg, here: http://rt2x00.serialmonkey.com/rt2x00-cvs-daily.tar.gz, they should work with 2.6.24-rc1 and have no license restrictions, AFAIK, they are the only ones.  
[17:05] <rtg> tll: the rtl series are already in the kernel: rtl8187_rtl8225.c and rt2x00/
[17:11] <tll> rtg, yepp I know, so it's dist-upgrading to hardy then?
[17:12] <Kano> rtg: as far as i know has rt73 problems with networkmanager
[17:12] <rtg> tll: boot the live CD first. The wireless stuff ought to work (or not as the case may be)
[17:13] <rtg> I've read that some folks are having better luck with wicd.
[17:14] <tll> rtg, thanks good idea. I will check the cd and wicd, nm is often painful. 
[17:19] <tll> Kano, yes and rt73usb is really broken with gutsy and my card. I will try rt73 and wicd, maybe they'll like each other.
[17:23] <tll> http://wicd.sourceforge.net/wiki/doku.php?id=testing sounds like a hit, thanks. I will try now.
[17:23] <Kano> with rt2500 others have got not problems, just rt73 seems stupid...
[17:27] <Kano> rtg: wicd seesm to be a bit stupid, it shows WEP for WPA wlans..
[17:29] <rtg> Kano: I didn't think WEP was possible for WPA. Perhaps its just a mis-type.
[17:30] <Kano> it detects it false
[17:45] <ogra> Kano, i dont have any problems here with the recent hardy kernel and the NM 0.7 packages from asac's ppa 
[17:45] <ogra> (rt73)
[17:45] <Kano> well i use hostap to test
[17:45] <ogra> working fine with WEP here at home as well as with th WPA in our main office ... 
[17:45] <ogra> i didnt try unencrypted though 
[17:46] <ogra> that was the only mode that worked reliable in gutsy
[17:57] <Kano> i never use wep, thats totally unsecure.. well forcing to use wpa1 worked however with that wicd
[18:00] <maks_> Kano is to lame to have an open network :)
[18:02] <asac> Kano: nm 0.7?
[18:02] <Kano> asac: 0.6.5
[18:02] <Kano> using that with hostap results in system crash after a few transfered bytes..
[18:03] <asac> Kano: please try nm 0.7 from my ppa
[18:03] <asac> Kano: do you use wext with wincd?
[18:03] <asac> wicd?
[18:04] <Kano> sure
[18:04] <asac> then try nm 0.7
[18:04] <Kano> but that wicd is not really stable
[18:04] <asac> how?
[18:04] <Kano> usually i write my network/interfaces manually 
[18:04] <Kano> with that specific card
[18:05] <asac> but still using wext for supplicant?
[18:06] <asac> Kano: try https://edge.launchpad.net/~asac/+archive 0.7 in hardy please
[18:06] <asac> and let me know. thanks
[18:06] <Kano> asac: i use etch + my own backports
[18:07] <asac> etch? why would this channel of any help then?
[18:07] <Kano> asac: i use the ubuntu kernel - just a bit modified
[18:08] <Kano> anything against reusing the kernel?
[18:08] <asac> its your system :)
[18:12] <Kano> btw. there is no network-manager-kde in your archive
[18:13] <asac> that doesn't exist for 0.7 yet
[18:14] <Kano> well i need the kde interface
=== smb is now known as smb_away
=== smb_away is now known as smb
[19:04] <torkel> asac: will nm 0.7 be included in hardy or is it too late already?
=== BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-7.11 | Latest news: 2.6.24 Release in Hardy | Kernel Team machine: http://kernel.ubuntu.com
=== BenC changed the topic of #ubuntu-kernel to: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.24-7.11 | Latest news: 2.6.24 Release in Hardy | Next meeting: Feb 12, 16:00 UTC | Kernel Team machine: http://kernel.ubuntu.com
[20:52] <smb> mjg59: ping
[21:00] <mjg59> Hi
[21:04] <smb> Hi Matthew, I was told you would be a good contact regarding my current question of which hdaps driver might be more preferrable for ubuntu hardy. The one in the kernel or rather the one from tp-smapi (includeing the other stuff). For edgy you got tp-smapi into the kernel. But somehow stuff got dropped after that.
[21:04] <mjg59> The smapi one is probably more useful in the long run
[21:06] <asac> torkel: most likely hardy+1 (unless upstream goes final soon, which is unlikely imo)
[21:06] <smb> It looked more recent and more powerful to me. I was wondering why nothing went into the mainline kernel. It was mentioned that this is rather due to some procedural reasons. Do you know a bit more of that history behind that?
[21:19] <rtg> mdomsch: do you know anything about USB keyboards not working on recent syslinux? Specifically on Dimension E520 and 9200. This is a change in behavior from Feisty to Gutsy.
[21:34] <amitk> mjg59: is there some question as to the provenance of the tp_smapi code?
[21:35] <mjg59> amitk: No, I think all those got answered
[21:37] <amitk> smb: ^^^
[21:38] <smb> amitk: mjg59: Hm, still the statement from Shen Multinymous was: mainline inclusion will not happen any soon.
=== calc_ is now known as calc
[23:21] <TheMuso> c
[23:21] <TheMuso> ugh wrong tab
[23:30] <mdomsch> rtg, nothing here
[23:30] <mdomsch> hmm, though sounds somewhat familiar
[23:30] <mdomsch> ping hpa
[23:32] <mdomsch> rtg, there was something either in syslinux or early boot that hpa had messed up briefly, but thought he had fixed