[00:21] <Kano> hi, the .35 ubuntu kernel has got patches from .36 it seems so that fglrx does not compile
[01:16] <melkor> fglrx compiles with the .35 kernel?
[01:18] <Kano> with mainline it does
[01:29] <melkor> I forgot, the reason I can't use the new fglrx is because my card isn't supported any more hd3650.
[01:29] <Kano> it is supported
[01:30] <Kano> just 10-9 is not for xserver 1.9, but you could try lucid with 2.6.35 mainline and it will work
[01:30] <Kano> just not with the maverick kernel
[01:30] <melkor> Last I checked (months ago) it was supported with the 9.xx drivers, but not the 10.x.
[01:30] <Kano> thats incorrect
[01:30] <Kano> hd2+ is supported
[01:31] <melkor> But I'd need to install the mainline kernel and not the backports maverick?
[01:31] <Kano> mainline works
[01:31] <Kano> 100%
[01:32] <melkor> Is there a repo with mainline?
[01:33] <Kano> not directly a repository
[01:33] <Kano> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35.4-maverick/
[01:36] <melkor> Kano: isn't that a maverick kernel?
[01:37] <Kano> maybe it was compiled with maverick
[01:37] <Kano> but the libc6 is compatible with lucid
[01:37] <Kano> so headers work
[01:38] <Kano> its even compatible with squeeze ;)
[01:40] <bjf[afk]> melkor: the -maverick indicates it was build with the maverick configuration settings
[01:41] <bjf[afk]> s/build/built/
[01:43] <melkor> So after I install this I should be able to reboot to that kernel and install fglrx.  Sometimes I have trouble with fglrx trying to install on the wrong kernel.
[01:45] <Kano> my script is able to install it
[01:46] <Kano> rm -f /etc/X11/xorg.conf*
[01:46] <Kano> http://kanotix.com/files/install-fglrx-debian.sh
[01:46] <Kano> use my script with -z optoin and reboot then
[01:46] <Kano> well use a supported kernel... dont forget to install both header debs
[01:50] <melkor> That is one hell of a script.
[01:51] <melkor> How do I check my x server version?
[01:51] <Kano> X -version
[01:52] <melkor> 1.8.2
[01:52] <Kano> no problem then
[01:53] <Kano> .35 kernel is supported, just not the u patched variant
[01:53] <melkor> what about using the x-swat fglrx package?
[01:53] <Kano> will not be much different
[01:54] <melkor> I'm gonna give that a shot it seems easier to undo.
[01:54] <Kano> i update the script in the minutes after a new fglrx when i know about it. it is even prepared for maverick
[01:54] <Kano> as soon you can dl the file
[01:54] <Kano> but not with maverick kernel ;)
[01:55] <melkor> alright I'm gonna give it a shot.
[08:34] <smb> RAOF, Are you still around?
[08:59] <erez_> helo
[08:59] <erez_> hello
[09:01] <erez_> I have a kernel oops. i want to report it, but I can't find where to attach the dmesg
[09:01] <erez_> who should i report it o ?
[09:03] <smb> erez_, Report it against the linux package (ubuntu-bug linux). If you can write the dmesg to a file to add it to the generated bug report.
[09:04] <erez_> it doesn't let me add the dmesg log
[09:05] <smb> erez_, Isn't there a little item to the bottom that says attach file?
[09:05] <smb> Actually it says "Add attachment or patch" in the bug report
[09:06] <erez_> not that i saw. i'll try again...
[09:06] <smb> If you open the bug report in the browser its very much to the bottom of the page. Above "What next"
[09:06] <erez_> no, it doesn't
[09:07] <smb> Hm, are you logged into launchpad?
[09:07] <erez_> no, i used ubuntu-bug linux command
[09:07] <smb> That should have opened a bug report or at least given you the bug number 
[09:09] <erez_> i didn't proceed when it said "send report" as the report wasn't finished
[09:09] <erez_> it also asks strange questions, i have to choose if this is a regression or not, but there is no "i don't know" option
[09:10] <smb> erez_, Ah, ok. I cannot say from my memory how this exactly looks like. But it should not matter. Just finish it off and then the report can be completed 
[09:10] <erez_> ok, trying right now
[09:10] <smb> erez_, Did it work before (with and older release or the same release)?
[09:10] <erez_> is an OOPS is a "Kernel Config" or "Other" or "I Don't know"
[09:11] <erez_> I know what a "regression is", i just didn't test this with a previous ubuntu 
[09:12] <smb> Was that still the question about regression or another one (the one with kernel config ....) Ok, in that case I would rather say no to regression
[09:12] <smb> It also can be changed later, when more is known
[09:13] <smb> Otherwise an oops is rather unlikely a kernel config. So I'd say either other or don't know 
[09:15] <smb> erez_, One note, if you are using the system which had the oops for the generation of the bug report, then ubuntu-bug adds the dmesg output automatically
[09:17] <erez_> ok, thanks
[09:20] <erez_> after i finished the bug report, it opened lunchpad on my browser. i can login, however - it doesn't seem to associate that to the ubuntu-bug i just used 
[09:22] <smb> Hm, it has been a little while when I used it. I thought it would redirect you to the bug report after login. Was there any printing of the generated bug number somewhere?
[09:23] <erez_> no
[09:23] <erez_> i will just have to fill it manually
[09:30] <erez_> ok, thanks smb, bug commited
[09:30] <erez_> bye
[10:56] <tseliot> apw, smb: there's no gpl code in fglrx hence I can't use that workaround that you suggested. Furthermore it seems that things broke in Lucid too
[10:57] <tseliot> as shown in make.log here: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/573748/comments/28
[10:57] <ubot2> Ubuntu bug 573748 in fglrx-installer (Ubuntu) "[MASTER] fglrx does not build on 2.6.33 kernel and higher (affects: 103) (dups: 33) (heat: 618)" [Medium,Triaged]
[11:00] <tseliot> apw, smb-afk: the problem is that even if I patch the driver to call arch_compat_alloc_user_space instead of compat_alloc_user_space when dealing with 2.6.32 and 2.6.35 I can't check the ABI and the patch may or may not break the module compilation
[11:00]  * tseliot repeats things for smb-afk
[11:01] <tseliot> smb: there's no gpl code in fglrx hence I can't use that workaround that you suggested. Furthermore it seems that things broke in Lucid too, as shown in make.log here: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/573748/comments/28
[11:01] <ubot2> Ubuntu bug 573748 in fglrx-installer (Ubuntu) "[MASTER] fglrx does not build on 2.6.33 kernel and higher (affects: 103) (dups: 33) (heat: 618)" [Medium,Triaged]
=== smb-afk is now known as smb
=== smb is now known as smb-afk
=== ivoks-afk is now known as ivoks
[11:14] <smb> tseliot, That is bad. In hindsight it might have been better to modify the security patches to export normally
[11:15] <tseliot> smb: yep. What do you suggest that we do now?
[11:16] <tseliot> patch the kernel and undo the breakage?
[11:18] <smb> tseliot, I'll have to talk to the security team. Problem atm likely is that no binary gfx driver works (or is this restricted to fglrx only
[11:18] <smb> ?)
[11:18] <smb> The question would be whether to revert it as a single upload or have it packaged into the next security release
[11:19] <tseliot> smb: nvidia doesn't seem to use that function so hopefully it's just fglrx
[11:21] <smb> tseliot, Ok, at least something but I agree that it should be reverted. I just hope that changing the type of export does not cause an abi bump. But on the other hand it did not when the function was made gpl only.
[11:22] <tseliot> smb: ok. Are you referring only to Lucid's kernel or also to Maverick's?
[11:22] <smb> That would be only Lucid and before, though. Long term (and that would inlcude Maverick) the fglrx driver likely needs somehow to cope
[11:23] <smb> This change is upstream that way and I don't think it will change there
[11:24] <tseliot> smb: I suspected that. In Maverick I'll have no way to check the availability of that function at compilation time so my patch won't work on kernels with older ABIs
[11:24] <tseliot> :/
[11:25] <smb> tseliot, But to as back about the workaround: what was the problem that may break older things?
[11:25] <tseliot> smb: I would call arch_compat_alloc_user_space instead of compat_alloc_user_space
[11:26] <smb> tseliot, When you posted that I was trying to get an irc proxy working, so I might have missed details
[11:26] <tseliot> ^
[11:26] <smb> ok, there was no place for the wrapper? calling arch would not be very good. 
[11:27] <smb> Neither in old code which does not have it nor in new where it is not doing any checking
[11:27] <tseliot> smb: the wrapper that you suggested would work well only if there were GPL files in the fglrx driver
[11:27] <tseliot> Amd told me that there isn't any
[11:27] <smb> tseliot, Would it not be possible to add a file and make that gpl?
[11:29] <smb> Somehow I thought they had some issues with other functions that became gpl exported only before
[11:30] <tseliot> smb: I'm not sure. I guess that would be a problem too
[11:32] <tseliot> smb: the problem is that they moved compat_alloc_user_space from asm/compat.h to kernel/compat.c and did EXPORT_SYMBOL_GPL(compat_alloc_user_space)
[11:32] <smb> tseliot, Hm, I guess I need to think about that. I need to leave for lunch, too. Let me think and I'll get back to you.
[11:32] <tseliot> smb: ok, thanks
[11:32] <smb> tseliot, remind me of the source package name for fglrx
[11:33] <tseliot> smb: fglrx-installer
[11:33] <smb> ok, ta
=== amitk is now known as amitk-afk
=== amitk-afk is now known as amitk
[14:04] <tseliot> smb: this is the correct bug report: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/642518
[14:04] <ubot2> Ubuntu bug 642518 in fglrx-installer (Ubuntu Lucid) (and 1 other project) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx (affects: 176) (dups: 165) (heat: 1408)" [High,Triaged]
[14:05] <smb> tseliot, Ok, I just sent out an email. I believe this could work.
[14:06] <tseliot> smb: did you CC me?
[14:06] <smb> tseliot, no, I To'ed you
[14:06] <tseliot> ah, even better
[14:07] <smb> In essence you may be able to decide whether to use arch_compat_... or compat_... based on whether compat_alloc_user_space is an exported symbol in kallsyms
[14:08] <smb> tseliot, I have not tested against old kernels yet, but I believe the principle should work
[14:10]  * tseliot reads the email
[14:15] <smb> Darn, most of my systems have ATI cards that are no longer supported by fglrx
[14:15] <tseliot> smb: now, that's clever :)
[14:16] <smb> tseliot, Clever of ATI :-P They used to be previously but them removed support apparently
[14:17] <tseliot> smb: yes, I was referring to your patch ;) I'm more than fine with the open driver even with cards that are supported by fglrx
[14:17] <tseliot> ~$ grep "T compat_alloc_user_space" /proc/kallsyms
[14:17] <tseliot> ffffffff810a5630 T compat_alloc_user_space
[14:18] <tseliot> this is with 2.6.35-22-generic
[14:19] <smb> Ah I thought you referred to the cards no longer being supported. :) I just checked on an older Lucid kernel, there is no such entry in kallsyms
[14:19] <smb> Seems I found a system that has a more recent card
[14:22] <tseliot> good
[14:22] <smb> *argh* that is a 32bit installation...
[14:23] <tseliot> hey at least we can use the workaround in Maverick
[14:23] <tseliot> I can try a Lucid livecd
[14:24] <smb> We could potentially use the workaround on Lucid, too. Somehow I suspect we get the fglrx package updated faster than the kernel
[14:24] <smb> (not to forget that I know how much pain it will be to do from the amount of work)
[14:26] <smb> tseliot, Oh, so actually the breakage is limited to 64bit as well...
[14:27] <smb> given that this 32bit install is happy with the most recent kernel. OK, should have known by the fact that this is in compat_...
[14:27] <tseliot> smb: yes, sorry, I should have pointed that out before
[14:28] <smb> tseliot, As I said I should have known from the code. :)
[14:30] <tseliot> hehe ok
[14:36] <smb> tseliot, How much effort would it be for you to update fglrx for the older releases as well? I am winching about making a kernel update as that not only means new kernel packages for all the releases but also merging things around and creating new proposed uploads for Karmic and Lucid... again...
[14:37] <tseliot> smb: if your workaround works as expected on Lucid, I think I can safely do that. Oh does it also affect Karmic?
=== ivoks is now known as ivoks-brb
[14:38] <smb> tseliot, Unfortunately that change went in back to Dapper, so it would affect all that have som fglrx support. (I think Hardy its envy)
[14:39] <tseliot> smb: ouch
[14:39] <smb> Yeah. :( 
[14:40] <tseliot> ok, it looks like I'll have some additional work to do
[14:41] <smb> tseliot, Hm I am not even sure just changing EXPORT_SYMBOL_GPL to EXPORT_SYMBOL would be enough as the function declaration is in linux/compat.h and I think you mentioned that the fglrx driver only includes asm/compat.h. *urgh*
[14:42] <tseliot> smb: yes, it can't include linux/compat.h
[14:43]  * smb offers to by tseliot beers in Orlando (though I was told you might not enjoy that)
[14:44] <tseliot> smb: hehe, right, I don't drink. Let's put it this way, you can offer me a coke and I'll buy you a beer for your patch ;)
[14:45] <smb> tseliot, Ah ok. NP with that. (though I was actually referring to the beer quality) :)
[14:45] <tseliot> smb: I wouldn't have noticed anyway ;)
[14:45] <smb> I see that know. :)
[14:45] <tseliot> hehe
[14:47] <smb> tseliot, Should I update the bug report with those facts we have discussed here?
[14:47] <tseliot> smb: yes, sure that would be welcome
[14:47] <smb> ok, will do
[15:58] <tseliot> smb: your patch works well in Maverick. I'll test it in Lucid soon
[15:59] <smb> tseliot, OK, cool. :)
=== ivoks-brb is now known as ivoks
[17:17] <aquarius> after upgrading to maverick, when I tell my machine (dell m1330) to restart, it jumps to the "ubuntu" shutdown screen with the 5 dots, and the 5 dots continue to tick over forever, but the machine never shuts down/restarts. It worked under lucid, so this is a regression somewhere. Which information do I need to provide to help you chaps fix it?
[17:19] <aquarius> is "ubuntu-bug -p linux" sufficient?
[17:19] <jjohansen> aquarius: its a start, along with a description of what is going on
[17:20] <jjohansen> aquarius: if you still have the Lucid kernel installed it is worth booting with it too
[17:20] <aquarius> jjohansen, ok, I'll do that
[17:20] <jjohansen> that would help isolate whether its actually the kernel or maybe upstart/plymouth
[17:20] <aquarius> er. Warning: The options -p/-P are deprecated, please do not use them. :)
[17:22] <aquarius> will try rebooting with the lucid  kernel next time I reboot before fiiling a bug
[17:27] <ogasawara> smb: your misc blueprint work item to pull back the Lucid version of fsl-imx51 to karmic-fsl-imx51... didn't you mention we won't do that?  ie I can mark that one off the list?
[17:28] <smb> ogasawara, Oh, I think I should make that announcement I wanted to but forgot with oall the other stuff going on
[17:29] <ogasawara> smb: also, I thought that you, sconklin, and bjf[afk] have been documenting the stable team processes.  Anything left to document there?  or can I mark that work item as done also.
=== bjf[afk] is now known as bjf
[17:30] <bjf> ogasawara: please mark it done though with all kernel wiki documentation its really never ending
[17:30] <ogasawara> bjf: ack
[17:30] <smb> ogasawara, I have the feeling that there might still be something. But as bjf says
=== amitk is now known as amitk-afk
[17:34] <sconklin> ogasawara: I think that we have enough documentation for Brad and I to consult, but not of a quality to be generally useful. We've done a lot. Maybe it's appropriate to close it and open a new task for next cycle.
[17:39] <smb> ogra, Is there a specific mailing list for arm or is this ubuntu-mobile?
=== ivoks is now known as away
=== away is now known as ivoks-away
=== ivoks-away is now known as ivoks
[19:23] <fta> could someone please have look at bug 638024? looks like a kernel panic (with a patch in the upstream bug)
[19:23] <ubot2> Launchpad bug 638024 in chromium-browser (Ubuntu) "Crashes ubuntu on application exit (affects: 3) (heat: 18)" [Undecided,New] https://launchpad.net/bugs/638024
[19:33] <jjohansen> fta: I'll take a look in a bit
[19:36] <ogasawara> fta: comment #32 - http://code.google.com/p/chromium/issues/detail?id=54617#c32 notes this doesn't seem to be an issue with the 2.6.35 kernel
[19:37] <ogasawara> fta: so I assume this shouldn't be an issue for Maverick
[19:39] <fta> the OP seems to be using lucid
[19:42] <ogasawara> fta: indeed, so it seems they should confirm if the issue still exists in Maverick before any further work is done trying to backport anything to Lucid.
=== ivoks is now known as ivoks-dinner
=== jsalisbury is now known as jsalisbury_brb
[19:54] <jjohansen> -> lunch
[20:20]  * ogasawara lunch
=== jsalisbury_brb is now known as jsalisbury
=== amitk-afk is now known as amitk
=== ivoks-dinner is now known as ivoks
=== bjf is now known as bjf[afk]
[23:44] <Keybuk> mjg59: here's a random one for you, when you're up
[23:44] <Keybuk> the current MBPs have both an Intel GMA HD and an nVidia card in them, right?
[23:44] <Keybuk> Linux only sees the NV
=== ivoks is now known as ivoks-afk