[00:59] <blueyed> Is there a chance to include virtualbox-ose-modules in linux-ubuntu-modules or something similar, so it gets rebuild for new kernels more automatically?
[01:07] <amitk> blueyed: unlikely, tomorrow is feature freeze for hardy. But there are exceptions for legitimate cases... So write email to kernel-team@lists.ubuntu.com explaining what needs to be done and why. Providing a patch that already works with Ubuntu gets bonus points.
[01:29] <blueyed> amitk: what should the patch target? linux-ubuntu-modules? Please note, that virtualbox-ose-modules is already around, but needs to be uploaded for new kernels always separately.
[06:29] <Hammer89> anyone have any idea what's causing this error? http://paste.ubuntu-nl.org/55947/
[06:30] <Hammer89> (I was referred from the #ubuntu channel to ask on here)
[06:31] <Hammer89> only modifications I've made were some recent updates from synaptic... which included kernel updates
[07:36] <tjaalton> rtg: do you have any changes to lrm other than the ones by me and tseliot?
[07:58] <tjaalton> rtg: ok, I'll prepare the lrm but won't upload until ack'ed
[08:25] <kraut> moin
[09:19] <Kano> hi rtg , do you want to add dmraid45?
[09:21] <Kano> #97655
[09:24] <abogani> Bug #97655
[09:24] <ubotu> Launchpad bug 97655 in linux-source-2.6.20 "dmraid45 target please" [Wishlist,Won't fix] https://launchpad.net/bugs/97655
[10:16] <kraut> this vmsplice issue is fixed in the vanilla kerne 2.6.24-2, not in -1, correct?
[10:21] <tjaalton> right
[11:14] <kraut> tjaalton: thanks
[13:51] <rtg> tjaalton: I don't have anything for lrm, though I might take a stab at producing a -server version later on. (next week)
[13:57] <tjaalton> rtg: I'm trying to do that now, if it's ok
[13:57] <rtg> tjaalton: that works for me :)
[13:57] <rtg> its not like I lack for things to do.
[14:05] <tjaalton> rtg: hehe, ok. it should be easy
[14:57] <tjaalton> whee, lrm-server built
[14:59] <tjaalton> fritz and ltmodem have been disabled for some time now, but ltmodem seems to build fine
[15:00] <rtg> tjaalton: I'll be uploading a -8 kernel this morning that fixes the compile issues with sparc/hppa/ia64.
[15:01] <tjaalton> rtg: you'd have the lrm ready by then?
[15:01] <tjaalton> +like
[15:02] <rtg> tjaalton: I assumed you were doing a -8 release for lrm, right?
[15:02] <natvie> hi
[15:03] <tjaalton> rtg: sure, but how much do I have time left?-)
[15:03] <natvie> i have this weird issue with ram.. i have an old pc with me, its a pentium550mhz intel i810 mothermotherboard and it had 128 mb sdram. so recently i thought of upgrading it to 512mb ram. so i bought this 256mb X 2 sticks as my motherboard have only two slots and support upto 512 mb. its all 133 mhz. ie same speed.now the problem is ..when i put this 512 mb ram.. my booting time takes almost 20 minutes.. so i checked it with only 256 mb in the slot.. th
[15:03] <natvie> en it took almost 7-8 mins.. but with my old 128mb ram it usedto take only less than 2 mins...i.e as i increase the ram the system is getting slower
[15:03] <rtg> tjaalton: even if you upload now it ought to DEPWAIT on the arches that have yet to build.
[15:04] <rtg> tjaalton: I guess my point is, I don't think we need to coordinate on when you upload since there is already a -8 kernel in the archive.
[15:04] <natvie> can anyone help me
[15:04] <tjaalton> rtg: ok, cool. I hope to be ready soon
[15:05] <rtg> natvie: have you run the memtest ?
[15:06]  * ogra has a really funny bug here ...
[15:06] <natvie> yes.. idi run the mem test.. evrything is fine
[15:06] <rtg> ogra: how amused will I be?
[15:06] <natvie> one more  thing.. i have got dual boot.. and 512 is working perfectly with my windows XP
[15:07] <ogra> since the beginning of hardy i noticed that my music playback didnt keep a constant speed (sounding like you play with the reel on a tape)
[15:07] <natvie> i use ubuntu 6.06. as i'm new in linux..
[15:07] <ogra> i was looking for bugs in mp3 playback and even in rhythmbox ....
[15:07] <rtg> ogra: I think listening to that would make me ill :)
[15:07] <ogra> today i had to stopwatch something ... 
[15:08] <ogra> intrestingly that showed me that not my playback but my system constantly seems to change speed
[15:08] <natvie> rtg:i tried 512mb and 128mb seprately on suse9.1, gnu/linux, ubuntu 5.10 etc.. in all the above i did fresh installations.. but in all the above ..i'm having trounle with this ram upgrade
[15:08] <tjaalton> rtg: btw, now that we have open-vm-tools, aren't the ones in lrm redundant?
[15:08] <tjaalton> they are not even built
[15:09] <rtg> tjaalton: likely, contact soren. He just updated the lum version.
[15:09] <ogra> (i never noticed that before, but the "wait" cursor rotates according to teh music speed as well)
[15:09] <rtg> ogra: could it be a problem with the codec device and/or driver?
[15:10] <natvie> rtg: wat could possibly be the problem
[15:10] <ogra> rtg, unlikely and i wonder how that should influence my cursor 
[15:11] <ogra> its also not constantly there
[15:11] <soren> tjaalton: No.
[15:11] <rtg> ogra: well, if interrupts were not getting serviced. something like that. arethere any complaints in syslog?
[15:11] <smb> ogra: is that the same machine that has this oopses and sometimes some clock issues
[15:11] <ogra> only happens at times, very unpredictable but lasts for a while then
[15:11] <tjaalton> soren: ok, thanks
[15:11] <ogra> smb, nope, other one
[15:11] <soren> tjaalton: The ones in lrm are the ones you need on the host side. The ones in lum are the ones you can benefit from in the guest.
[15:12] <smb> ogra: ah. ok. just came to my mind :)
[15:13] <tjaalton> soren: ok, they haven't been built since feisty though :)
[15:13] <natvie> wat can i do abt he ram
[15:13] <soren> tjaalton: *shrug*
[15:13] <ogra> rtg, hmm, nothing in syslog it seems
[15:14] <tjaalton> soren: not to mention that they are old, but maybe I'll just leave them be for the time being :)
[15:14] <rtg> ogra: what kind of platform?
[15:15] <soren> tjaalton: I forget why they were added to begin with.. I wasn't involved in that stuff back then.
[15:15] <ogra> ogra@ceron:~$ cat /proc/cpuinfo |grep model
[15:15] <ogra> model		: 4
[15:15] <ogra> model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
[15:15] <ogra> model		: 4
[15:15] <ogra> model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
[15:15] <ogra> dual core pentium
[15:15] <rtg> ogra: looks identical to mine.
[15:15] <soren> Actual dual core or hyperthreading?
[15:16] <ogra> play some internet radio during the next days while working ;)
[15:16] <rtg> soren: hyperthreaded.
[15:16] <tjaalton> soren: seems that the kernel modules are now in partner repo
[15:16] <rtg> ogra: I play local tunes quite often. The only time I notice drop out is under heavy disk activity.
[15:17] <ogra> hmm, i rarely play local tunes ...
[15:17] <ogra> i'll switch to local for the day tomorrow, so i can see if it shows up there as well
[15:19] <ogra> its really significant sometimes ... like you hold back the tape, lest loose and it rushes past the head quickly it really behaves very analogue :)
[15:19] <ogra> s/lest/let/
[15:20] <rtg> ogra: see if you can correlate that behavior with other activity, such as wireless or wired network activity, background disk indexing, etc.
[15:21] <rtg> maybe screen updates?
[15:23] <ogra> well, its an ltsp server so it doesnt have or drive any screen
[15:24] <rtg> ogra: so, lots of network activity, then?
[15:24] <ogra> well, not really, i usually only run a single terminal on it ... 
[15:25] <rtg> but your audio is coming over the network, right?
[15:25] <ogra> right
[15:25] <ogra> through pulse
[15:25] <rtg> any change that the stream is being affected somewhere else?
[15:25] <ogra> emulating an alsa device in the user session ... 
[15:25] <rtg> s/change/chance/
[15:26] <ogra> well, the line between server and client is a direct connection ... my payload goes over the other networks here in the house
[15:27] <ogra> all ist does is serving one terminal over 100Mbit ... if i do tests i usually run up to ten terminals on that network piece without any saturation issues
[15:28] <ogra> additionally i would expect audio to get choppy rather than changing speed if the net is involved
[15:28] <rtg> ogra: I agree.
[15:29] <rtg> ogra: I also know that if this bugs the shit out of you, you're capable of figuring it out :) 
[15:29] <ogra> right
[15:29] <rtg> I don't havbe a quick anser.
[15:29] <ogra> its not overly important and i wasnt after pushing anyone to fix it :)
[15:30] <ogra> as i stated initially ... funny bug :)
[15:41] <amitk_> ogra: could you check if frequency scaling is involved?
[15:42] <ogra> amitk, i did alreaady seems not :/
[15:42] <ogra> (that was actually the first thing i checked after searching in the audio stack)
[15:42] <amitk> ogra: install latencytop and keep it running it through these apparent slow downs
[15:43] <ogra> but i suspect there is a clocking issue *somewhere* 
[15:43] <ogra> cool, thanksi didnt know about that tool 
[15:43] <amitk> recently released
[15:44] <ogra> ah, thats why apt doesnt find it :)
[15:44] <ogra> where do i get it ?
[15:44] <amitk> latencytop.org i believe
[15:45] <ogra> uuuh
[15:45] <ogra> does our kernel have the required patch ? 
[15:45] <rtg> tjaalton: see http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=983c3899ef3f44ec0e65f23cf6fd8571a8bc4d5b . You'll need to do this for lrm.
[15:46] <amitk> unfortunately, no. But I'm thinking if we should...
[15:47] <ogra> yeah
[15:47] <ogra> t least during development we should
[15:47] <ogra> seems like a helpful monitoring tool 
[15:48] <rtg> amitk: its gotta happen today.
[15:48] <tjaalton> rtg: needed for lrm too?
[15:48] <amitk> rtg: ogra: there is an overhead with tracking anything.
[15:49] <ogra> amitk, i dont mind having some overhead during the development cycle ... you can remove it for the release
[15:49] <rtg> tjaalton: the new dpkg-buildpackage passes options to all build. kernel stuff just won't work unless you unexport LDFLAGS (in particular)
[15:50] <amitk> rtg: would enabling it now and disabling it in some Beta be acceptable?
[15:50] <rtg> amitk: how about ifdef'ing it? ogra can build his own kernels.
[15:51] <amitk> rtg: it is #ifdef'ed. You need to enable CONFIG_LATENCYTOP
[15:51] <ogra> (that doesnt mean he wants to :P )
[15:51] <rtg> even better, a sysfs entry to enable it dynamically?
[15:51] <ogra> yeah
[15:51] <ogra> that sounds handy
[15:52] <tjaalton> rtg: gotcha
[15:52] <rtg> amitk: it would be easy enough to peridically produce a CONFIG_LATENCYTOP enabled kernel in a PPA.
[15:53] <amitk> rtg: yup, let me see how current the patch is. I'll get back to you
[15:53] <rtg> amitk: np. we can add it later  since its not an active feature (by default)
[15:56] <soren> How far are we from a new linux-meta?
[15:57] <rtg> soren: as soon as I verify the kernel FTBS are fixed. probaly later this afternoon.
[15:58] <soren> rtg: When is "afternoon"? I forget your $TZ.
[15:59] <rtg> its 0900 here. so, another 3-4 hours?
[15:59] <soren> Awesome.
[16:28] <amitk> rtg: you already wrapping up -8.14?
[16:28] <rtg> amitk: test building as we speak.
[16:28] <rtg> making damn sure I didn't break ABI
[16:29] <amitk> rtg: so I can commit to git?
[16:29] <rtg> yep, but don't start a new release just yet.
[16:29] <rtg> just in case.
[16:29] <amitk> rtg: this is the latencytop patch
[16:29] <rtg> ok
[17:17] <tjaalton> rtg: hmm, the new lrm will end up in NEW because of adding -server
[17:18] <rtg> tjaalton: thats OK. almost every kernel does as well.
[17:18] <tjaalton> ah, ok
[17:19] <rtg> tjaalton: besides, I know the archive admins.
[17:19] <tjaalton> :)
[17:36] <tjaalton> rtg: phew, lrm is now uploading
[17:37] <rtg> bombs away... kernel in a bit. I want to make _really_ sure I've solved the dpkg-buildpackage FTBS carnage.
[18:02] <Kano> rtg: do you know this driver: http://www.ralinktech.com.tw/data/drivers/2007_1220_RT2870_Linux_STA_v1.2.1.0.tar.bz2
[18:02] <Kano> it fails to build with 2.6.24
[18:03] <rtg> Kano: why am I responsible for that?
[18:03] <Kano> well it is a wlan driver
[18:03] <Kano> and you could add it if you get it compiled
[18:03] <Kano> i am sure there will be more users for that driver
[18:11] <rtg> Kano: its likely it'll have to go into the lbm package (if anywhere)
[18:11] <Kano> whats lbm?
[18:11] <rtg> linux-backports-modules
[18:12] <Kano> replacement for lum?
[18:12] <rtg> its in addition to lum
[18:12] <Kano> ah
[18:12] <Kano> whats teh difference
[18:12] <rtg> in the past its how I upgraded ALSA with impacting users who choose _not_ to install lbm
[18:12] <rtg> s/with/without/
[18:13] <rtg> lbm modules take precedence over lum and kernel.
[18:13] <rtg> e.g., they are first in the depmod search order.
[18:13] <Kano> but is completely empty now?
[18:14] <rtg> it is empty for Hardy. Look at Gutsy for an example.
[18:50] <mjg59> Hm. -7 boots *very* slowly on one of my test boxes, until / gets mounted
[18:50] <mjg59> Then it seems to speed up
[18:50] <mjg59> Caps lock takes ages to respond, so it seems to be somewhere in the kernel
[18:54] <rtg> mjg59: I've noticed that on at least one as well. I'm hoping -8 (without the generic IDE driver) will help.
[18:54] <rtg> mjg59: -8.14 that is.
[18:56] <mjg59> Hm. Yeah, generic has ended up binding. 
[18:56] <mjg59> Wait, no.
[18:56] <Kano> rtg: how about using pata_nv for nvidia?
[18:56] <inuka_desk> amitk, Jay toled me that you guys were having issues with the driver....?
[18:56] <rtg> mjg59: I backed all the IDE changes out: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=351cc10d3c1c2ab09773b24994389d7533c832dd
[18:57] <amitk> inuka_desk: it was an ABI and versioning confusion in the mobile PPA
[18:57] <amitk> should be solved soon
[18:57] <mjg59> rtg: Right, if the legacy drivers are enabled they need to be blacklisted by default
[18:57] <inuka_desk> amitk, oh ok just checking...
[19:00] <rtg> Kano: CONFIG_SATA_NV=m in all configs except virtual.
[19:03] <Kano> rtg: but i have got hda
[19:03] <Kano> i mean PATA_NV
[19:03] <Kano> the other nv driver disables dma for my dvd drive
[19:03] <amitk> mjg59: rtg: Wouldn't it be nicer to have a way to explicitly enforce an order in which modules are tried: ata_piix -> ide_generic 
[19:04] <rtg> pata_amd.c: Nvidia SATA devices are claimed by sata-nv.c
[19:04] <mjg59> amitk: There's only really one order that makes sense
[19:04] <Kano> i will compile the kernel without old ide drives but it is really annoying when you try the generic one
[19:04] <rtg> amitk: some thing in itiramfs ?
[19:04] <rtg> s/itiramfs/initramfs/
[19:05] <mjg59> amitk: There's only really one order that makes sense (native,acpi,pci-generic,generic)
[19:06] <mjg59> The problem is that there's two different native drivers provided
[19:06] <mjg59> Either will work, but libata is basically always preferred
[19:06] <amitk> rtg: yeah... apparently fedora does something like this in the mkinitrd script
[19:06] <amitk> s/the/their
[19:06] <mjg59> The sensible thing is just not to include the legacy ones in the initramfs when a libata driver is shipped
[19:07] <amitk> mjg59: but sometimes (admittedly very rarely now) the libata driver doesn't work
[19:08] <mjg59> amitk: Right, so in that case we should ship the legacy one and blacklist the libata one :)
[19:08] <mjg59> You'll never want both in the initramfs
[19:08] <mjg59> Unless one trips bugs on some hardware and the other trips bugs on different hardware, in which case we should probably just trim the PCI IDs
[19:09] <Kano> no good idea when you want to use em with a different config
[19:09] <mjg59> Kano: ?
[19:10] <Kano> well when you want to do a kernel without legacy ide drivers
[19:10] <mjg59> I still don't understand what you're saying
[19:10] <Kano> which ids do you want to remove?
[19:11] <mjg59> Any overlapping IDs when we need to provide both in the initramfs
[19:16] <Kano> then remove the legacy ids
[19:19] <mjg59> Well, obviously
[19:20] <Kano> also pata_amd i would prefer (it is not pata_nv)
[19:24] <mjg59> amitk: It would probably be helpful to write something to scan through the modules and flag any cases where we have multiple modules supporting the same IDs
[19:34] <amitk> mjg59: sure
[19:35] <Kano> mjg59: thats easy
[19:36] <Kano> just usw awk on modules.pcimap
[19:46] <mjg59> amitk: Then we can add appropriate blacklist entries or remove IDs as necessary
[19:58] <tjaalton> rtg: crap, lrm failed to build on i386, nv-new for -server
[19:58] <Kano> tjaalton: do you want a patch
[19:59] <Kano> or do you want to seek for it alone ;)
[19:59] <Kano> i fixed that weeks ago *g*
[19:59] <tjaalton> Kano: you have one?
[19:59] <Kano> i reused the fedora one
[19:59] <Kano> accept dcc
[20:00] <Kano> whats up
[20:00] <tjaalton> url please
[20:00] <tjaalton> or pastebin
[20:00] <Kano> extracted from source.rpm
[20:00] <tjaalton> which package?
[20:00] <Kano> http://rpmfind.net/linux/RPM/mandriva/devel/cooker/x86_64/media/non-free/release/dkms-nvidia-current-169.09-1mdv2008.1.x86_64.html
[20:01] <Kano> nvidia-2.6.24-xen.patch
[20:01] <Kano> is what you need
[20:01] <Kano> already included in http://kanotix.com/files/install-nvidia-debian.sh
[20:04] <Kano> tjaalton: i think it was before from fedora, but just seek for the name, very easy to find
[20:05] <tjaalton> Kano: ok thanks
[20:06] <Kano> that script installs nvidia with a patched standard installer and has that patch also integrated in case of xen found
[20:07] <tseliot> Kano: doesn't this line work any more?
[20:07] <tseliot> export IGNORE_XEN_PRESENCE=1
[20:07] <Kano> it works but for 2.6.24 you need an extra patch
[20:08] <Kano> i told you the name, gave you link to rpm with that, even a script with it...
[20:08] <tseliot> ok, thanks
[20:09] <tseliot> I asked since DKMS + export IGNORE_XEN_PRESENCE=1 works well on Hardy
[20:10] <Kano> it can not be for xen
[20:11] <Kano> that deb has
[20:11] <Kano> err rpm
[20:11] <Kano> PATCH[0]="nvidia-2.6.24-xen.patch"
[20:11] <Kano> PATCH_MATCH[0]="^2.6.2[4-9]"
[20:11] <Kano> do you see that
[20:11] <Kano> in the dkms.conf
[20:13]  * tseliot nods
[20:13] <tseliot> you're right
[20:14] <tseliot> It looks like I'll have to modify Envy
[20:14] <Kano> you write envy?
[20:14] <tseliot> Yes, I did
[20:14] <Kano> well i wanted to adopt that for my script too
[20:15] <Kano> maybe i add dkms support,seems to be easy
[20:15] <tseliot> yes, it's quite easy to do
[20:15] <Kano> only that dkms file
[20:16] <tseliot> I did it
[20:16] <Kano> i never use envy ;)
[20:16] <tseliot> well, I haven't released EnvyNG yet
[20:16] <tseliot> ;)
[20:17] <Kano> my scripts have been out years before envy and work still
[20:17] <tseliot> EnvyNG (Next Generation) will use DKMS
[20:17] <tseliot> yes, I know :-)
[20:17] <Kano> will change the fglrx script to dkms , thats easy, for nvidia it is a bit tricky
[20:17] <tseliot> not that tricky ;)
[20:18] <Kano> well maybe i put it in a package like fglrx
[20:18] <tseliot> maybe you can have a look at EnvyNG when it's finished
[20:19] <tseliot> that is to say very soon
[20:19] <Kano> maybe, but i prefer "own" solutions *g*
[20:19] <tseliot> there's only one solution as regards dkms.conf :-P
[20:20] <Kano> you can reuse the mandrake one too
[20:20] <tseliot> I tried but DKMS refused to install the module
[20:21] <Kano> so upload yours
[20:22] <tseliot> sure, I would like to include the patch you gave me first
[20:22] <Kano> i can think of the 2 lines
[20:22] <Kano> thats not the problem
[20:22] <Kano> nvidia, 169.09, 2.6.24-7-generic, i686: built
[20:22] <Kano> that worked btw...
[20:23] <tseliot> with Mandriva's dkms?
[20:23] <tseliot> with Mandriva's dkms.conf ?
[20:23] <Kano> i only changed ver to 169.09
[20:24] <tseliot> really? Then it means that I had tried some older version of the package
[20:25] <Kano> i used the one i gave you
[20:25] <tseliot> I remember that the package built but when I tried to install it, DKMS failed
[20:25] <tseliot> have you tried to install the packages?
[20:27] <Kano> maybe it needs the makefile for other kernels too
[20:28] <tseliot> have you tried the packages yourself?
[20:28] <Kano> the package now
[20:28] <Kano> no
[20:28] <Kano> i only extracted a few things
[20:28] <tseliot> ah, ok
[20:29] <Kano> but in theory i could try that too...
[20:30] <tseliot> it shouldn't break anything
[20:30] <tseliot> if it's only the part with DKMS
[20:32] <Kano> hmm when i copy it completely i get bad exit status 2
[20:32] <Kano> musst diff it
[20:33] <Kano> -mcmodel=kernel -mno-red-zone
[20:34] <Kano> and removed xenchat
[20:38] <tseliot> does this depend on your specific system configuration?
[20:40] <Kano> well i fetched the x86_64 rpm ;)
[20:41] <Kano> you need a 64 bit system
[20:41] <tseliot> aah
[20:45] <Kano> well basically only 2 files are different to 32 bit
[20:45] <Kano> Module.symvers + nv-kernel.o
[20:47] <Kano> then it works
[20:47] <tseliot> I see
[20:54] <Kano> i just dont understand why
[20:54] <Kano> DEST_MODULE_LOCATION[0]="/kernel/drivers/char/drm"
[20:54] <Kano> this is used
[20:54] <Kano> usually it is in
[20:54] <Kano> kernel/drivers/video/
[20:55] <Kano> do you get this?
[20:57] <tseliot> let me check
[20:58] <Kano> which is stupid
[20:58] <tseliot> it should be
[20:58] <tseliot> /kernel/drivers/video/nvidia
[20:58] <Kano> as when you uninstall the module an older module will be copied to the new location
[20:59] <tseliot> it works well with that
[20:59] <Kano> sure, maybe mandrake specific
[21:00] <tseliot> I don't use Mandriva
[21:01] <tseliot> therefore, yes it might be mandriva specific
[21:03] <Kano> interestingly fglrx uses the drm location for dkms.conf
[21:06] <Kano> but misc when you use m-a...
[21:06] <Kano> (edgy target)
[21:07] <Kano> dont know what the installer uses
[21:08] <tseliot> true, but I don't know why fglrx requires that line...
[21:08] <Kano> i dont think that you require it, maybe you just use it for both
[21:11] <tseliot> currently I use a customised dkms.conf for NVIDIA while I leave the ATI installer the burden to build the packages for me
[21:15] <Kano> why is it impossible to use remove before using build?
[21:16] <Kano> dkms remove $(dkms status|awk '/^nvidia/{print "-m "$1" -v "$2}'|sed 's/,//g'|uniq) --all
[21:16] <Kano> that only works after build but not directly after add...
[21:17] <Kano> stupid or not...
[21:24] <Kano> rm -rf /var/lib/dkms/nvidia/
[21:24] <Kano> maybe thats faster...
[21:34] <Kano> as final cleanup
[21:38] <Kano> dkms remove $(dkms status 2>/dev/null|awk '/^nvidia/{print "-m "$1" -v "$2}'|sed 's/,//g;s/:$//'|uniq) --all 2>/dev/null
[21:38] <Kano> this works... forgot that :
[21:44] <Kano> tseliot: what do you think about creating the dir, adding it, mkdeb --source-only and then just install the deb?
[21:45] <tseliot> I don't understand your question
[21:46] <Kano> how do you package it
[21:46] <tseliot> I use the packaging scripts of the lrm
[21:46] <ntolia> Hi. I am tryiing to compile a Xen kernel using the linux-source package in 7.10. However, simply copying the config file from the linux-xen image and running make oldconfig doesn't seem to work. Any suggestions / instructions on how to build it?
[21:46] <tseliot> so that I get 3 packages
[21:46] <Kano> ok
[21:46] <Kano> well to integrate into my script i will first use another way
[21:47] <tseliot> sorry but I have no experience whatsoever with Xen kernels (yet)
[21:47] <tseliot> Back to what I was saying, I generate 3 packages:
[21:48] <tseliot> nvidia-glx{new,legacy}, nvidia-glx{new,legacy}-dev, nvidia-kernel-source
[21:48] <tseliot> where nvidia-kernel-source contains the dkms part
[21:49] <Kano> well my script works a bit differnt
[21:49] <Kano> it has a -v option to specify the driver or it chooses automatically the best driver for th card
[21:49] <Kano> so it is more generic
[21:50] <tseliot> Envy can do that for me
[21:50] <tseliot> so that I can build whatever the user wants
[21:50] <tseliot> or whatever autodetection decides
[21:51] <Kano> nv autodetect is really simple... fglrx you need to update everytime
[21:51] <tseliot> I keep id lists for both drivers
[21:52] <Kano> i use whitelist for fglrx and blacklist for nv
[21:55] <tseliot> I keep the ids in python dictionaries. Each driver flavour has its own dict
[21:57] <Kano> there are always different ways
[21:58] <tseliot> yep
[21:59] <Kano> i do not understand python, i use bash
[21:59] <Kano> or better: dash
[21:59] <Kano> as the script is pure posix
[22:02] <tseliot> I use Python because it's just too easy to use
[22:02] <tseliot> and I can use both GTK and QT4 with it
[22:03] <tseliot> and of course I know Python better than bash
[22:04] <tseliot> it's a matter of taste
[22:08] <tseliot> btw, envy was originally written in bash
[23:19] <Caesar> re: #183928, is the intention only to carry the Centrino branded and certified version of iwlwifi at the expense of the various improvements in the later versions?
[23:20] <Caesar> (particularly talking about Hardy here)
[23:20] <alex_joni> bug #183928
[23:20] <ubotu> Launchpad bug 183928 in linux-ubuntu-modules-2.6.24 "update iwlwifi to latest version" [Medium,Won't fix] https://launchpad.net/bugs/183928
[23:20] <rtg> Caesar: for now. its possible that if there are compelling reasons I might do an lbm version.
[23:20] <Caesar> rtg: how would you like to be compelled? :-)
[23:21] <rtg> There would have to be a number of failure cases. At any rate, I'm not going to get to it for a few weeks.
[23:21] <Caesar> serge: you have failure cases, right?
[23:21] <serge> Versions like 1.2.23 is being used by Fedora 8 so could be considered well tested 
[23:22] <serge> on WPA enterprise roaming from one access point to another we get packet loss, I have bug reports from people saying that their connection drops 
[23:23] <serge> drops out from time to time
[23:23] <serge> also my logs are full of TKIP decrypt failed for RX
[23:23] <serge> etc
[23:24] <serge> I don't think the users look at their logs so have not had any reports 
[23:24] <Caesar> rtg: can we make this easier for you? Provide a patch?
[23:25] <rtg> sure, but do it for linux-backports-modules
[23:25] <serge> Fro Hardy ? 
[23:25] <rtg> yep.
[23:28] <Caesar> rtg: why backports?
[23:28] <rtg> because its an elective install. lum and the kernel are required.
[23:53] <tjaalton> rtg: I hope the latest lrm builds on i386, since I need to get some sleep :)
[23:53] <tjaalton> lpia is the only one that has finished building
[23:54] <tjaalton> so far