[02:56] <NCommander> apw, just a off question, but why break the ABI range for ARM kernels; its a different source package after all. (I curious at the rationale why imx51 starts at 100, and dove starts at 200 ...)
[06:57] <theemahn> I think this is the place, I want to be straight kernel issue with 9.10, not a showstopper right?
[08:38] <apw> NCommander, we have split ABI ranges because the shared header packages collide in the archive.  that could likely be resolved by renaming that package but at the time it was simply less risk to split the abi
[08:39] <NCommander> apw, ah, that makes sense. I was just unsure the reasoning behind it
[08:40] <apw> yeah mostly lack of time to go the 10 uploads needed to get it all sorted as it was only spotted late in the cycle i think
[09:09] <benh> apw: ping
[09:09] <apw> benh, yo
[09:09] <benh> yo mate !
[09:09] <benh> any chance you guys stick that in:
[09:09] <benh> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cede3930f0ca6fef353fa01306c72a01420bd45e
[09:09] <benh> and respin the powerpc ISOs ? :-)
[09:10] <benh> I forgot to send it to greg for -stable
[09:10] <benh> I'll do that asap
[09:10] <TheMuso> benh: I don't think respinning the powerpc isos is possible, I'll have to rebuild them by hand I'd suspect, once the updated kernel is made available, if it is done at all
[09:10] <benh> ouch
[09:10] <TheMuso> /c/c
[09:11] <benh> oh well, if you can put the rebuilt ones somewhere on ppa, that will do
[09:11] <benh> we can then point the poor users of those nasty iMac G5 "iSight" to that
[09:11] <benh> without that patch, offb is busted on those (and some G5s with the X1900 "mac" radeon)
[09:12] <apw> benh, can they boot the CD without the patch and get it as an update?  i assume so if a PPA is helpful
[09:12] <benh> nope
[09:12] <apw> ouchies there
[09:12] <benh> problem is, the gfx card gets moved by the PCI code due to bogus conflicts
[09:12] <benh> so they get no display
[09:12] <benh> ie
[09:12] <apw> so how would they recover from that using the PPA you suggest
[09:13] <TheMuso> apw: I'd have to role disks by hand to get the new kernels.
[09:13] <benh> radeonfb would have worked ... except it doesn't work with those specific machines due to some fuckage I never sorted out (need physical HW access and I haven't got that yet)
[09:13] <benh> so offb fallback is the only solution
[09:13] <benh> and the bug breaks .. offb
[09:13] <benh> since the address of the framebuffer changes
[09:13] <benh> apw: a new ISO
[09:13] <benh> apw: another option would be to put on PPA a set of files to stick on a USB dongle
[09:14] <benh> apw: just yaboot, config & new kernel/initrd
[09:14] <benh> apw: that can then move on to the CD
[09:14] <apw> yeah that would work i guess
[09:14] <TheMuso> benh: also note that pPAs don't build ppc packages
[09:14] <apw> so ... an updated kernel should do the trick.  so lets get a LP bug in the system with the patch on it
[09:14] <apw> i think you said it was going via stable as we speak
[09:15] <apw> and i'll get it on our stable teams radar so we can get it in ...
[09:15] <benh> TheMuso: ok, whatever, your home dir somewhere we can point people to :-) 
[09:15] <benh> I'll send it to Greg tomorrow, need to check that it applies cleanly on .31 first etc...
[09:15] <benh> ok cool
[09:15] <benh> no big hurry
[09:16] <benh> only one user nagging so far :-) 
[09:16] <TheMuso> heh right.
[09:16] <benh> that PM code is also needed for some older x86 boxes in fact
[09:16] <apw> if you get the launchpad bug and .31 patch together  one of us can build you a kernel you can use for your USB thingy
[09:17] <benh> ok
[09:17] <benh> I can cook up a yaboot.conf for the users myself
[09:17] <benh> allright, I'll try to get that done over the next few days
[09:17] <apw> benh please subscribe me to the bug
[09:17] <benh> will do when I open it :-)
[09:18] <apw> (indeed)
[09:18] <benh> ie, not tonight :-)
[09:18] <benh> btw, about that Huawei modem fiasco
[09:18] <benh> I find it funny that there have been tons of "me too" with E220/E620 for which the patch don't fix it yet
[09:18] <benh> and none of them so far has sent usbmon logs
[09:18] <benh> which I've asked ... about 3 times
[09:19] <benh> oh well, no logs, no fix
[09:19] <apw> users are like that, they have changed the title to 'some huawei dongles' now ...
[09:19] <benh> but I wonder if you guys should just revert the initial patch that caused the whole damage in the first place
[09:19] <smb> benh, That is the magic one is supposed to have
[09:19] <benh> from a distro quality POV it makes a lot of sense
[09:19] <apw> when the fix releases we'll ask for a retest, and a 'file a new bug if you don't have E169 and its not working' style on it
[09:19] <benh> ie, bring it back to 2.6.31.1 status
[09:19] <smb> benh, btw, subscribe me to that bug too please
[09:20] <benh> smb: email, or I'll forget :-)
[09:20] <smb> benh, An as good memory as mine :) ok
[09:21] <benh> apw: it's all caused by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d0defb855c8504c49b92bdc0203689ce9b4cf7ba
[09:21] <apw> benh, possibly yes but then we are out of step with stable which may trigger ongoing maintenance, and we'll only get the issue back in lucid where we would much less prefer to have it
[09:21] <benh> apw: as far as I can tell... the fun thing is .. the patch was submitted by Huawei themselves :-)
[09:21] <apw> that being an LTX as upstream also has it
[09:21] <apw> LTS
[09:21] <benh> apw: right well, we'll still try to fix it :-)
[09:21] <apw> yeah they are looking a little foolish for sure
[09:21] <benh> apw: but in the meantime, fixing the problem for all users would seem like a priority 
[09:22] <benh> apw: ie, it's a fucking lot of 3G modems out there that don't work
[09:22] <apw> we always have that backout as an option if this is not sufficient (which we know its likely not)
[09:22] <benh> apw: but it's your call guys :-) I don't do Canonical policy :-)
[09:22] <benh> right
[09:22] <apw> but till we fix E169 we can't see whats left
[09:22] <benh> I'd really like to not let it drop until we fix 220 and 620 either, I kept the kernel.org bug open for that too
[09:22] <apw> and as you can tell everyone just says 'mee too'
[09:22] <benh> but there's little I can do without users sending logs
[09:23] <benh> true
[09:23] <apw> being not fixed on the update should help us there
[09:23] <benh> yup
[09:23] <benh> definitely
[09:23] <apw> so we think that 220 and 620 are not going to be fixed with this update
[09:23] <benh> that's what it -seems- from the reports
[09:23] <benh> but it's hard to tell with lusers
[09:23] <apw> i may go do some stiring on the bug then, and push that bug to E169 only
[09:24] <benh> backing out the original patch will have the side effect of disabling the storage part of the modem
[09:24] <benh> which is not a big deal
[09:24] <apw> yeah ...
[09:24] <benh> nobody cares about the windows SW on it
[09:24] <benh> which leaves the micro-SD thingy but that's not a huge issue, and it didn't work before either anyway
[09:24] <apw> we should likely point them all at the pre-proposed kernel build 
[09:24] <apw> yeah there is no regression in that, if we have to back it out
[09:25] <benh> it doesn't help that some bot keep fucking up the bug status :-)
[09:25] <smb> yeah, could that have been that one of in size problem with "no sense"?
[09:25] <benh> smb: well, the size problem with sense is fixed by the patch that went into .5
[09:25] <smb> benh, exactly
[09:25] <benh> smb: but -apparently- (hard to tell for sure) there's more problems with 220 and 620
[09:25] <smb> just being at that to put into pre-proposed kernels
[09:26] <benh> smb: all related to what looks like FW bugs in the modem, in their implementation of the USB storage protocol
[09:26] <apw> i applied that same fix in the batch we did before the .5 drop arrived, so it should be in your curent built
[09:26] <apw> joy :)
[09:26] <benh> yeah :-)
[09:26] <benh> foot-crafted firmware
[09:27] <apw> heheh ...
[09:27] <benh> for the sense stuff, at least we made the fix in the form of making the driver robust enough to cope with that crap in all cases rather than a quirk
[09:27] <benh> but it looks like we still get defeated somewhere
[09:28] <apw> ok so it sounds like we'll get the .5 update into pre-proposed and we'll ask those users to test there
[09:28] <benh> sounds good
[09:28] <apw> lets find out if it fixes them all at once
[09:28] <benh> you may want to stick a build with the original patch backed out somewhere too
[09:28] <benh> so users can test both and report
[09:28] <benh> what would give us more solid data
[09:28] <apw> yeah sure
[09:29] <benh> eventually, we can then write up the procedure to do the usbmon log
[09:29] <benh> it's actually very easy
[09:29] <benh> but I'm sure most users just didn't know what I was talking about
[09:29] <benh> brb
[09:29] <apw> benh, sounds good, if you can show us we can get someone to do a wiki page on it
[09:30] <smb> benh, you mean something like https://wiki.ubuntu.com/KernelTeam/Debugging/USB?
[09:30] <Appiah> hey apw 
[09:31] <Appiah> that kernel that you compiled (?!) worked great for the "no network on some laptops"
[09:31] <apw> Appiah, which bug # please/
[09:31] <Appiah> https://bugs.launchpad.net/bugs/418933
[09:31] <ubot3> Malone bug 418933 in linux "no internet connection (wifi+ethernet doesn't work)" [Low,Confirmed] 
[09:33] <benh> apw: there's already something on the wiki
[09:33] <benh> smb: right
[09:33] <apw> nice, love it when a plan comes together
[09:33] <benh> smb: but that might be a bit thick for a luser
[09:33] <smb> benh, It can be improved I agree
[09:33] <apw> benh, ok the plan is to get the .5 stable and .5 stable with that original patch reverted built and pushed to that bug for comparitive testing
[09:33] <benh> smb: easy enough to write up the 3 commands to type in the bug, will do that after we have sorted out whether they really still have a problem
[09:34] <benh> sounds like a plan :-)
[09:39] <Appiah> apw: if any more info is needed I'd be happy to help
[09:40] <apw> Appiah, that old kernel is so out of step with current mainline and karmic kernel its not likely a useful data point now.  do you have a dell?
[09:42] <Appiah> apw: nope a Acer
[09:45] <apw> what does rfkill status say
[09:46] <Appiah> on the kernel that dont work or yours?
[09:48] <apw> on the non-working one
[09:56] <TheMuso> apw: Out of curiocity, do you guys have a tentative target kernel version for lucid?
[09:57] <apw> TheMuso, its in the air still based on timing and where other stables go, definatly at least .32, maybe .33 if its early enough
[09:57] <TheMuso> apw: Right, I thought as much.
[09:57] <apw> i think we may be conflicted, .32 for stabilty and .33 for sexy goodness
[09:58] <TheMuso> Right.
[10:08] <indus> hi
[10:09] <indus> hi friends apw smb here?
[10:35] <apw> indus, high
[10:35] <indus> apw hello
[10:41] <indus> apw: i need a small favour ( or big one)
[10:42] <indus> apw remember i said about that game called quake4 which crashes on running the quake4-smp executable.? Could you give me some possible places or hints where i could look at? I generated an strace but its 130 MB size, and in the end it just says segmentation fault
[10:42] <apw> well the clues if any are just before the crash i'd think
[10:43] <apw> what did it do just before going bang
[10:43] <apw> of course if you can't change the program, you can't fix its likely
[10:44] <apw> i thought you could get the same smb mode by starting the non-smp version and enabling it from the menu anyhow?
[10:44] <indus> apw the crash happens when i connect to any server online. It reads a config file , initialises display again(where it comes back to desktop), then starts game again, says loading menus then boom
[10:45] <indus> apw well, the quake4-smp is meant to use multicore capabilities, so right now i disable smp in console, then after map loads,  i enable it again 
[10:45] <indus> works fine in single player is the reason iam curious
[10:46] <indus> could it have something to do with ext4 at all?
[10:46] <apw> sounds unlikely it would be ext4 to me
[10:47] <apw> what was the previous few system calls before the explosion
[10:47] <indus> hmm dont recollect now, but some munmap 4096
[10:48] <indus> ok i rephrase this question, what are the things which are extra into an exe which takes into account multicore processors.? anything at all to do with libs etc? or just low level 
[10:49] <apw> given it worked on an older kernel, and it works in non-smp mode for the map load, and you then can reenable it, i'd say that its most likely quake4 has always had an SMP issue in the map loading code and has always been lucky before now, some change in the scheduler has changed timings of the threads and exposed the bug
[10:49] <apw> and if thats true, unless you can look at and modify the code you are likely to not be able to fix it
[10:49] <apw> (the code in quake4 i mean here)
[10:50] <indus> apw yeah always had an issue with it , it was fixed in a patch later on, various fixes
[10:50] <indus> apw i guess we wait for q4 to be open sourced then, which will happen eventually
[10:50] <apw> heres hoping
[10:51] <indus> so how are things today with you
[10:51] <indus> your friend smb not here it seems
[10:52] <indus> apw did you find out what an HSM violation is
[10:52] <apw> heh smb is like that, off making kernels i expect
[10:52] <apw> yep, it is a Host State Machine violation ... ie the host has no idea where to go next based on what the drive said ... the drive said something mad
[10:53] <smb> sort of here and not. and not much help for quake issues too
[10:53] <indus> could you tell me other tools like strace for debugging? strace didnt tell much before segfault
[10:54] <apw> you could try gdb
[10:54] <apw> if quake has debug symbols in it it may help
[10:54] <smb> yeah, not sure how much more info you get out of that given your app is closed source
[10:54] <indus> ok 
[10:55] <indus> just curious thats all, its the only game i play
[10:55] <indus> you folks can try it, it looks great
[10:56] <indus> btw, can i volunteer to help you? 
[10:56] <apw> to help with kernel stuff?
[10:56] <indus> maybe testing, iam not a computer engineer though
[10:56] <indus> but iam always interested
[10:57] <apw> we are always interested in people helping us generally
[10:57] <apw> some people help with testing, which can be as little as using the -proposed repositories
[10:57] <apw> others help with our bug days, or with bug triage
[10:58] <indus> so all require a knowledge of C then
[10:58] <apw> that requires less specific knowledge of computers, and more of our process and the things we need to knw
[10:58]  * indus grumbles i never quite learnt it in college
[10:59] <indus> iam a mech engineer actually
[10:59] <indus> but did a little python
[10:59] <apw> ogasawara is a good person to talk to about helping out on bug days and with triage if that interests you
[10:59] <indus> apw ok ill do that then, is he around here too?
[10:59] <apw> she is normally around around in my afternoons
[10:59] <apw> she is west coast US timezone 
[10:59] <indus> hmm ok late 
[11:00] <smb> well helping with testing and looking at bugs often requires more of a reprodible and repeatable approach at things
[11:00] <apw> i think you are east of me, so she may be awake still in your morning?
[11:00] <indus> iam in india
[11:00] <indus> ya probably
[11:01] <indus> but its better later nights when its morning for her
[11:01] <indus> i have a job regular daytime
[11:01] <apw> yeah
[11:02] <indus> so are you folks working on something special for the ubuntu kernel 
[11:02] <indus> boot etc maybe
[11:02] <apw> i personally am working on the lucid kernel in general
[11:03] <indus> ok carry on, ill speak some other day, you probablywork full time for canonical?
[11:03] <apw> indus, ogasawara would point you to: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies in the kernel team wiki, in our knowlege base
[11:03] <apw> https://wiki.ubuntu.com/KernelTeam/KnowledgeBase
[11:04] <apw> you might find those informative in how we do things and the like
[11:04] <apw> yeah i am lucky enough to get paid to work on the kernel
[11:04] <indus> sadly, i have a problem with alsa also in quake 4 :)
[11:05] <indus> lots of changes seem to have been done in newer releases
[11:05] <apw> heh ... yeah the kernel moves on a furious pace
[11:05] <indus> personally i found alsa output much richer than oss in this game, and they added support 3 years ago with a patch
[11:06] <apw> people like to improve the kernel... about 2000 commits wo
[11:06] <apw> make that 11000 commits in the last kernel update
[11:07] <apw> and we have about 2 kernel releases per ubuntu release ...
[11:07] <smb> indus, there is also a #ubuntu-bugs channel which should have people in them to help n generic bug triaging procedures
[11:07] <apw> i think there is an #ubuntu-bug channel where you can get .... waht smb said
[11:07] <indus> iam already triaging bugs
[11:08] <indus> little slow due to work and other commitments though
[11:08] <apw> ahh ... then if you have those skills then we always need help traiging kernel bugs :)
[11:08] <indus> huhuhu
[11:08] <apw> and hanging out here and helping people who ask questions, helping them to find things like docs and stuff helps us a lot
[11:08] <apw> anything anyone can do to help lightens the load on us
[11:08] <indus> yeah know i know ubuntu-bug -p linux is the way to get data
[11:09] <apw> cool
[11:09] <indus> here? this is a dev room isnt it, 
[11:09] <apw> thats how most people start, pointing people to the docs
[11:09] <indus> you mean in general #ubuntu?
[11:09] <apw> yeah it is, but that doesn't stop people asking questions :)
[11:09] <indus> like me for example :D
[11:10] <apw> heh yeah like you
[11:10] <smb> yeah :-D 
[11:10] <indus> but is it a bother if users generally drop in here?
[11:10] <smb> but here mostly things related to the kernel in special
[11:10] <apw> generally they end up here whent hey are desperate and #ubuntu/+1 has not been able to help and its kernel
[11:10] <indus> in my case, i had no dvd for a year so someonein ubuntu-bugs directed me here
[11:10] <smb> no, if they can accept that we might not be helpful when it comes to user-space applications
[11:11] <apw> people who are trigaing bugs for us might well want to hang out and ask us questions to aid them triage better etc
[11:11] <apw> heh see so the process works, if slowly
[11:11] <smb> As for the dvd thing, it actually helped as we had a quicker feedback and could give you hints on the master slave thing
[11:14] <indus> so , will that bug be addressed in future? not everyone reads launchpad :) most are new general users 
[11:14] <indus> i guess peopel like me help them fix it then :)
[11:14] <apw> the master slave one?  its a tricky one, the general information we are getting is that mostly its not expected to work if you have just a slave on a cable
[11:15] <apw> in that context its hard to know why it did work before
[11:15] <smb> what apw said. maybe it was just coincidental but not according to the spec
[11:15] <indus> why should the kernel not look if there is a slave drive there?
[11:15] <apw> of course its not cirtain that everyone with a broken cd is the same issue as the issue is so broadly stated in the bug
[11:15] <apw> its not so much about looking, it is looking, and finding and breaking
[11:16] <indus> hmm
[11:16] <apw> the drive is doing something it should not and being rejected
[11:16] <apw> which it does not do if its a master drive
[11:16] <apw> which is somewhat supprising and incomprehensible
[11:16] <indus> or maybe the kernel doesnt like what the drive is telling her
[11:16] <indus> its a sony combo drive, maybe firmware issues?
[11:16] <smb> based on the assumption that there cannot be a slave without a master
[11:17] <apw> well what the drive says makes no sense under the spec.  iirc correctly its saying ERROR with data and then provides no data
[11:17] <indus> well, the cd drive came with default jumper at slave
[11:18] <apw> so we ask it to identify and it says ERROR read this then refuses to tell us why and we say .... it doesn't seem to be a drive, hrm and ignore it
[11:18] <indus> but now, my boot up is much smoother it seems without kernel probing madly all devices
[11:18] <smb> which probably was at some time mostly used on the same channel as a hd
[11:18] <apw> yeah common default, as in the old days we put them on the same channel as our disk which was master
[11:18] <apw> now we would not do that as the DMA modes for drives go much hihger, and are capped at the slowest drive on the cable
[11:18] <apw> and extra ports are cheap.  so all drives are on their own and should be primary
[11:19] <apw> but the manufacturers put the cd ones in the same place still 
[11:19] <apw> as to whether it should work, that is still an open question
[11:19] <smb> at some point things changed and cds where placed as master on the second bus. I actually think they canged to make it master by default
[11:19] <smb> but that might be not always the case
[11:19] <indus> one question, there is a cable selector option other than msater and slave, how does tht work?
[11:20] <smb> when you set the drive to cable select it will depend on which of the connectors you put it
[11:20] <smb> usually the cables have on line broken up between the second and third connector
[11:20] <indus> ok nvm now, its a different discussion anyway
[11:21] <indus> but iam really glad, you people helped me solve this long standing problem 
[11:22] <indus> ok ill see you around
[11:22] <indus> bye and have a nice day/days apw and smb and others
[11:47] <Appiah> apw: sorry for the late response
[11:48] <Appiah> but rfkill status is not valid..
[11:48] <apw> what does it say?
[11:48] <Appiah> status is not a command
[11:49] <Appiah> just shows the help
[11:49] <Appiah> you mean rfkill list ?
[11:50] <apw> apparently so yes
[11:50] <Appiah> http://pastebin.ca/1656506
[12:02] <ricflomag8> Hi, i need advice on tweaking the generic karmix kernel: i want to disable the experimental VIA PATA driver and replace it with the VIA IDE driver (I suspect the VIA PATA driver to be responsible for random hardlocks)
[12:04] <ricflomag8> i've tried to build the whole kernel using https://help.ubuntu.com/community/Kernel/Compile (old debian way), but i get a huge deb file (900M)
[12:04] <ricflomag8> is it the place to ask ? :)
[13:37] <apw> 900M ... which one is that big
[13:38] <apw> Appiah, is the dmesg for that machine available ?
[13:40] <smb> apw, I strongly suspect it has to do with the old debian way (which seems to be kpkg-make) and the fact that our config is to make debugable code and strip before putting into packages.
[13:41] <apw> yeah ... sounds like the debug stuff.  just wondering which file it made was that big
[13:41] <smb> sort of all of them
[13:42] <apw> rsync -a --exclude debian --exclude debian.mvl-dove * /home/apw/local/git2/ubuntu-karmic/debian/build/build-dove
[13:42] <apw> how is that safe ?
[13:42] <apw> oh missed the --exclude debian ... blind as a bat
[13:43] <smb> heh, happens
[13:51] <Appiah> apw: not at the moment sorry
[15:34] <apw> dtchen, hey ... it seems we have a lot of people running the wrong kernel after an upgrade
[15:35] <apw> do you have any feel for how many you have seen?
[15:35] <apw> i hear you get to find out cause it breaks sound
[15:38] <MsMaco> i think on friday he said 200 or so in 2 days
[15:38] <MsMaco> i saw his inbox. timestamps for bugmail on that issue were every minute
[16:20] <apw> MsMaco, thanks for the info
[16:20] <apw> i assume he must have  closed them out as i cannot find them currently
[16:23] <Appiah> apw: what more then dmesg output do you want?
[16:24] <apw> interested to see the bits where the wireless is initialised
[16:24] <Appiah> cuz I gotta reboot , get the log , save it , reboot , upload it
[16:28] <sconklin> I discovered a cool tool for intel graphics hardware - blogged about it here: http://www.illruminations.com/post/232984141/development-tools-for-intel-graphics-drivers-on-linux
[16:28] <apw> Appiah, its not that big, so i'd get the lot
[16:29] <Appiah> oki you will get it in a min
[16:36] <tormod> sconklin, that's intel-gpu-tools, is moved to a separate package now
[16:36] <tormod> *will be
[16:37] <tormod> sconklin, sorry, the reg dumper will be moved to the separate package intel-gpu-tools
[16:44] <Appiah> apw: http://pastebin.com/d239546a7
[16:45] <Appiah> 1413 wlan stuff begins
[16:46] <apw> thanks can you get that in the bug pls
[16:46] <Appiah> alright
[16:48] <Appiah> apw: posted
[17:28] <hagabaka> I installed the image and header packages from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc6/ , grub update says it found the new kernel, and I see symlinks to them in /boot/, but menu.list doesn't list them. how can I fix that?
[17:29] <smb> hagabaka, Have you tried "sudo update-grub"?
[17:29] <hagabaka> yeah
[17:30] <smb> I see. Is the file actually touched after you run that. (ls -la)
[17:32] <hagabaka> yeah, it is touched
[17:34] <hagabaka> does grub use the symlinks in /boot/ if I don't enter the menu?
[17:35] <smb> no, only the first entry in menu or whatever was saved...
[17:35] <hagabaka> oh
[17:35] <smb> it is strange that it seems to tell you it finds it but does not add it
[17:38] <hagabaka> I wonder if it's using a regexp and not considering versions containing "rc"
[17:39] <smb> This would have been seen more often by now. There are quite some using those afaik
[17:39] <hagabaka> oh
[17:41] <hagabaka> ah, it was because I was using gdebi-kde to install it before, the installation asked me to choose whether to use maintainer's menu.list, since it had modifications. the KDE version doesn't deal with those dialogs...
[17:42] <smb> ah. ok. think there are variations of that problem around
[17:44] <apw> yeah that -kde tool seems to betriggering all manner of issues
[17:45] <hagabaka> does the gtk one deal with them?
[17:46] <hagabaka> I'll try the new kernel, see you
[18:31] <hagabaka> I'm using x-edgers, 2.6.32 kernel to enable KMS for ATI Radeon 9800 Pro using the open source driver. there are flashing lines on the screen in both console and X. I can stop the flashing lines by changing to a different resolution or refresh rate, but after rebooting they're back again. is there a way to "save" the refresh rate setting? it doesn't seem to be just an X configuration problem.
[18:32] <hagabaka> the flashing lines have the screen image shifted horizontally, and the shift grows larger near the right edge of the screen
[18:35] <hagabaka> I do have the hsync and vrefresh values for the monitor in xorg.conf
[19:07] <ukev> hi, what does the following want to tell me?
[19:07] <ukev> [86251.635098] python2.6[18415]: segfault at 7f06b9c70d49 ip 00007f06b1994610 sp 00007fff63ffb9c8 error 4 in libpython2.6.so.1.0[7f06b1900000+156000]
[20:57] <apw> hagabaka, you should ask that question over on #ubuntu-x, as they do the x-edgers stuff
[21:51] <tormod> sconklin, you want to upload stuff in xorg-edgers?
[22:22] <sconklin> tormod: no, but I'm working on getting a crack-of-the-day build going for the upstream Intel drivers
[22:23] <tormod> sconklin, kernel driver?
[22:23] <sconklin> tormod: yes, sorry. Porbably it will be a build of their kernel working tree
[22:24] <tormod> sconklin, aha, nothing we want into xorg-edgers, but maybe a separate PPA?
[22:24] <tormod> we can use intel-gfx-testing ppa for it maybe
[22:24] <sconklin> tormod: Yes, I already have a PPA set up, first test build with some patches should land any minute
[22:26] <sconklin> tormod: I'll publicize it once I've tested and got my work flow down
[22:26] <tormod> sconklin, cool I'll add you to the teams, but ask before dumping something in there :)
[22:26] <sconklin> tormod: no problem :)
[22:27] <sconklin> tormod: is xorg-edgers a good place to call for testing of intel kernel driver patches?
[22:28] <tormod> sconklin, well xorg-edgers is just a ppa, and as I said we probably don't want a crack kernel in there
[22:28] <tormod> but you can advertise on the PPA page
[22:28] <sconklin> tormod: yeah, ok. That's good.
[22:28] <tormod> the phoronix forum is the best place to find crack testers with good technical skills
[22:29] <tormod> plenty of people will love to test fresh kernels, we often get requests
[22:29] <sconklin> tormod: ok, thanks for that.
[22:30] <sconklin> gotta run now, I'm burning dinner :)
[22:30] <tormod> if you could team up with apw and make daily builds  including drm-next ...
[22:46] <Kano> hi, is it known that p54 does not work with 64 bit  only 32 bit?
[22:51] <tormod> sconklin-afk, (when you're back) if you can build dailies with aufs so we can make live cd iso's with them that would rock
[22:51] <tormod> Kano, you reminded me about asking for that :)
[22:52] <Kano> thats really crap that kernel, i had to use my 32 bit install to get online
[22:55] <sconklin-afk> tormod: Let me check with apw on that, he already has the build process set up for Linus's upstream and is going to be looking at how to do the intel driver upstream also.
[22:56] <sconklin-afk> tormod: oh and thanks for the package note on intel_reg_dumper, I updated the blog post
[22:58] <tormod> sconklin-afk, well I was a bit coming in from the future on that remark :)
[22:58] <sconklin-afk> that's ok, since blog posts live forever
[22:59] <dtchen> apw: yes, all related to some strange failure-to-update-grub's-conffile
[23:13] <tormod> ogasawara, what is that httpd trick on the initramfs wiki page?
[23:15] <ogasawara> tormod: hrm, not quite sure I know what you're talking about here.  Can you point me to the wiki you're looking at?
[23:16] <apw> dtchen, yeah it does look that way doesn't it ... we'll get some automation on gettting those responded to tommorrow
[23:17] <tormod> ogasawara, sorry can't find it now, it was about debugging boot and stuff, there was a section about httpd in the initrd and I traced that to you
[23:17] <tormod> never heard about it before
[23:17] <tormod> https://wiki.ubuntu.com/DebuggingKernelBoot
[23:18] <dtchen> apw: I think bug 463853 is the tracking one
[23:18] <ubot3> Malone bug 463853 in grub "no sound at all in 9.10" [High,Incomplete] https://launchpad.net/bugs/463853
[23:19] <tormod> dtchen, so grub gets blamed?
[23:20] <tormod> oh kernel upgrade
[23:20] <dtchen> tormod: it clearly isn't an alsa-kernel issue
[23:20] <dtchen> tormod: I've triaged about 700 of these by myself
[23:21] <dtchen> along with the awesome spew that people leave in comments saying "ubuntu sucks", etc., etc.
[23:21] <tormod> have you seen a menu.lst yet?
[23:21] <dtchen> I've seen quite a few
[23:22] <tormod> and they only have the old kernel?
[23:22] <dtchen> yes
[23:23] <dtchen> I'm not going to devote cycles to debugging it, because 1) I'm tired, 2) others more experienced are looking at it, 3) there are a crackton other bugs to look at
[23:23] <tormod> can you link to one report which has menu.lst or more?
[23:25] <tormod> ok I found bug 470265
[23:25] <ubot3> Malone bug 470265 in grub "[MASTER] jaunty to karmic upgrade failed to update menu.lst (update-grub missing from kernel-img.conf)" [High,New] https://launchpad.net/bugs/470265
[23:26] <dtchen> tormod: sure, there's also 465937
[23:26] <dtchen> just take a look at the bugs affecting alsa-driver if you're interested
[23:28] <dtchen> bjf: hi, thanks for helping with these grub bugs
[23:29] <bjf> dtchen, happy to help
[23:34] <TheMuso> Yeah, any help with audio bug triage is welcome. We have received so many bugs since Karmic came out its not funny.
[23:37] <dtchen> actually, it's pretty awesome. linux-side at least they break down into three big classes: 1) grub fubar (resolved by fixing the grub conffile), 2) mic sensing for IDT, VIA, & Realtek (resolved by installing linux-backports-modules-alsa-karmic-generic and rebooting), 3) powerdown anomalies for non-IDT/Sigmatel (resolved by disabling power_save)
[23:37] <dtchen> pulseaudio-side is a little -- okay, a lot -- more bleak
[23:39] <joaopinto> will anyone be working on the libsdl 1.2.14 upgrade which according to the release notes fixes improves support for PA ?
[23:39] <dtchen> joaopinto: yes, I am. I've got it in another terminal here.
[23:40] <dtchen> it also improves support for ALSA
[23:40] <joaopinto> I have started settings dupos into bug 454879
[23:40] <ubot3> Malone bug 454879 in libsdl1.2 "Applications using libsdl1.2-alsa randomly use 100% cpu and have broken sound playback" [Undecided,New] https://launchpad.net/bugs/454879
[23:41] <dtchen> yes, I've seen. Thank you!
[23:41] <joaopinto> grr, hedgwars played fine now, I didn't figured yet the random factor