[01:59] <verwilst> hellow
[02:00] <verwilst> zul: i seem to be having a problem that i can't start a domU because it cannot connect to the vif ( which is what the message says )
[02:00] <verwilst> zul: changing nothing in the configs, but simply rebooting with the official 2.6.18-xen kernel makes it work just fine
[11:32] <tseliot> BenC: I need to talk to you about bug https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/98641
[11:33] <tseliot> my patch wasn't applied in its entirety therefore the wfb module is still missing
[11:35] <tseliot> please contact me, even privately if you wish
[11:35] <tseliot> thanks
[11:49] <Ornedan> Hi. Which system is used for suspend/hibernate in Ubuntu?
[12:34] <tseliot> BenC: I wrote a full explanation of the reason for the changes  in my patch:
[12:34] <tseliot> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/98641/comments/101
[12:52] <tseliot> and here's the latest patch:
[12:52] <tseliot> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/98641/comments/102
[01:42] <jeromeg> hello
[01:42] <jeromeg> just a single question
[01:43] <jeromeg> should I assign hotkeys not working bugs to the kernel ?
[05:09] <tseliot> BenC ?
[05:32] <BenC> tseliot: it's fixed in gutsy, I plan an upload for feisty with 100 series driver
[05:32] <tseliot> BenC: no it has a problem
[05:32] <tseliot> I had a look at the code
[05:33] <BenC> tseliot: I think you're wrong
[05:33] <BenC> at least as far as the type of if statement to use
[05:33] <tseliot> I have described what and above all why my patches did all that in the bugreport today
[05:34] <BenC> libwfb should be included if it exists, regardless of the version
[05:34] <tseliot> ok, we agree on this
[05:34] <BenC> which is why I used the -e test and not a "new version" test
[05:34] <tseliot> I see your point
[05:35] <tseliot> and we could keep it your way and add other if-statements
[05:35] <tseliot> whenever a new module is added to the 
[05:35] <tseliot> latest driver
[05:35] <BenC> right
[05:35] <tseliot> but
[05:36] <tseliot> there is another problem
[05:36] <tseliot> the links for nvidia-glx-new
[05:36] <tseliot> should be kept separate from the links
[05:36] <BenC> which links?
[05:36] <tseliot> in nvidia-glx
[05:36] <BenC> not sure what you mean
[05:36] <BenC> the current package works, right?
[05:36] <BenC> it is working for me at least
[05:37] <tseliot> there should be a link to the wfb module
[05:37] <tseliot> otherwise the driver will crash with geforce 8xxx
[05:37] <BenC> there is a link
[05:37] <BenC> I am using 8400M right now
[05:38] <tseliot> do you refer to version 2.6.22.3-11.2 ?
[05:38] <BenC> lrwxrwxrwx 1 root root     26 Aug 27 13:04 /usr/lib/xorg/modules/libwfb.so -> libnvidia-wfb.so.100.14.11
[05:39] <BenC> wait, maybe that's a symlink I added manually before the fix in the package
[05:39] <BenC> Ok, I can fix that now and do another upload
[05:39] <tseliot> where would you like to add the link?
[05:40] <tseliot> in the debian/rules?
[05:40] <BenC> yes, I'm adding it to the if statement
[05:40] <BenC> give me 5 minutes, I'll have it uploaded
[05:41] <tseliot> why don't you keep a separate nvidia-glx-new.links.in and a nvidia-glx-new.links.amd64.in ?
[05:41] <tseliot> so that you can add the links there in the future?
[05:42] <tseliot> I mean, instead of touching the debian/rules
[05:44] <BenC> tseliot: because again, that makes it ver specific, when it needs to be file specific
[05:44] <BenC> this saves us work down the road
[05:44] <BenC> don't want the same bug report popping up when we get an nvidia-glx-really-new :)
[05:45] <tseliot> ahhh. Ok, now I do see your point
[05:46] <tseliot> according to the same logic the script will create the link if the module exists. It makes sense to me now.
[05:46] <BenC>                         ln -s libnvidia-wfb.so.$$this_ver                                       \                          $(CURDIR)/debian/nvidia-glx$${nv_flav}/usr/lib/xorg/modules/libwfb.so;\
[05:46] <BenC> added that, doing a build, and will upload once I verify it works
[05:49] <tseliot> in the nvidia-glx-new.links I put this link:
[05:49] <tseliot> usr/lib/xorg/modules/libnvidia-wfb.so.@@VERSION@@ usr/lib/xorg/modules/libwfb.so
[05:50] <tseliot> which I guess is the same ;)
[05:52] <BenC> lrwxrwxrwx 1 root root      26 Sep  8 11:52 libwfb.so -> libnvidia-wfb.so.100.14.11
[05:52] <BenC> works, so uploading
[05:53] <tseliot> perfect
[05:54] <BenC> done
[05:57] <tseliot> BenC: please, remember to put the link in Feisty's restricted modules as well
[05:58] <BenC> will do
[05:58] <tseliot> thanks
[06:08] <bullgard4> How can I run the SysRq function on a x86 laptop computer using kernel 2.6.20-16generic? Pressing the SysRq key doesn't do it.
[06:09] <BenC> bullgard4: are you in X?
[06:09] <bullgard4> yes
[09:45] <ant1> Hello, I got a problem in gutsy, when I set vga=0x314 I cannot access the virtual console, when I switch from X to virtual console I just get messy colors, if I remove splash option,I don't see boot messages, also I tried with acpi=off, my laptop is of 15.4"  screen. Is this bug kernel related ? If yes, is it known to you guys ?
[09:46] <ant1> if it is not kernel related, do you know in what component should I report this bug ?
[09:54] <bullgard4>  How can I run the SysRq function on a x86 laptop computer using kernel 2.6.20-16generic? Pressing the SysRq key doesn't do it. Either in X or in a console.
[09:54] <ant1> ctrl+alt+sysrq ?