[02:41] <Sarvatt> is it a known issue that theres no linux-backports-modules for 2.6.32-17 in the archives yet?
[02:59] <MTecknology> Sarvatt: it's in the pocket
[02:59] <MTecknology> so.. it shoulda been there already
[04:25] <JohnFlux> woohoo!  Suspend works now on my machine :-)
[04:25] <JohnFlux>  It didn't work in 9.10  but does in 10.04
[04:25] <JohnFlux> I love you guys! :)
[04:43] <JohnFlux> Why do drivers released by companies have such poor quality?
[04:44] <johanbr> if you're talking about closed-source drivers, it seems like the authors often have a less than perfect understanding of how to interface with the kernel properly
[04:44] <JohnFlux> even GPL'ed drivers
[04:44] <JohnFlux> The released ralink driver doesn't compile because they removed MODULE_LICENSE("GPL") at the last moment
[04:45] <JohnFlux> it contains a serious flaw that lets root the system remotely
[04:45] <johanbr> oh that... yes, ralink is a mess
[04:45] <JohnFlux> It spams the syslog with the message "#"  once for every packet!!
[04:45] <JohnFlux> The email addy bounces
[04:46] <JohnFlux> but I've seen this mess elsewhere
[04:46] <JohnFlux> I worked for a company writing video drivers for SGX
[04:47] <JohnFlux> people keep pushing us to release the code for the driver..  but there's a good reason we don't show anyone it.. :-D
[04:47] <johanbr> right :)
[04:47] <johanbr> I think opensource encourages good programming practices
[04:48] <JohnFlux> we used RCS, and actually sent customer patches as a Word document!
[04:48] <JohnFlux> with instructions to copy and paste the text, then manually fix the smart quotes..
[04:49] <johanbr> yikes :)
[04:49] <JohnFlux> when I left, last year, they were planning to upgrade to CVS
[04:49] <JohnFlux> they still haven't though :-D
[04:50] <johanbr> maybe they got rid of the Word patches at least :)
[04:50] <JohnFlux> no, I tried to at least automate the process..  but no luck
[05:09] <syn-ack> Seriously, *word*?
[05:09] <syn-ack> man, I could understand something like notepad or wordpad but *word*?!!? /me shudders
[05:46] <crimsun> bjf: patch for #303789 sent to stable and upstream
[08:24] <amitk> smb: the d-i patch, shouldn't it say modularise instead of de-modularise?
[08:25] <smb> amitk, Yes Andy should have known better. Thats how those patches are now in the repo. I won't rewrite history
[08:26]  * amitk doubts andy's english skills, he's english after all 
[08:26] <smb> (and actually we all failed to spot it in looking at the patches. /me included)
[08:27] <smb> amitk, MY language skill get bad in any language given the time of day is late enough. ;-P
[08:31] <amitk> there has to be a better way to create our d-i modules files automagically - comparing config file changes to d-i changes is painful
[08:36] <amitk> smb: do you know if PATA_SIS == module(pata_sl82c105.ko)?
[08:37] <amitk> I guess I can look at the Kconfig help text
[08:37] <smb> amitk, I created the list from the modules I found on my build system.
[08:37] <smb> There are a few that are different between amd64 and i386 but I hope this catches all
[08:40] <amitk> smb: some discrepancies
[08:40] <amitk> PATA_SIS is enabled in the config, but not in d-i
[08:41] <smb> Ok, I should add that then
[08:42] <amitk> In Sata:
[08:42] <smb> amitk, Hm, pata_sis? I only see sata_sis.ko
[08:43] <amitk> smb: I see a PATA_SIS enabled in debian.master/config/config.common.ubuntu
[08:45] <amitk> sata looks good
[08:46] <smb> amitk, For some reason the PATA_SIS ends up being built in...
[08:46] <smb> amitk, Need to check the lower config files
[08:47] <amitk> smb: you're right, I missed the =y, so yes it is built in
[08:47] <amitk> so according to config, the d-i is correct.
[08:47] <smb> amitk, Though I wonder whether this should also becom =m
[08:47] <amitk> whether or not PATA_SIS should be built-in or not is a separate story
[08:47] <smb> yeah
[08:47] <smb> I make a sticky-note for apw
[08:48] <smb> amitk, I just want that d-i change out and in today as this breaks a good deal of things
[08:51] <amitk> smb: ack away
[08:51] <smb> amitk, Many thanks
[09:08] <JohnFlux_> smb: Hey man
[09:08] <smb> JohnFlux_, mornin
[09:08] <JohnFlux_> smb: I'm going to ask a very stupid question..  what does "Fix Committed" mean ? :-)
[09:09] <JohnFlux_> smb: This means it's now a patch in the ubuntu kernel, right?  But not yet accepted by the staging drivers guys upstream?
[09:09] <smb> JohnFlux_, :) That I put the patch into our git tree. When it gets uploaded and released it will become fix released
[09:09] <smb> The status has nothing to do with upstream. Just internal workflow
[09:12] <JohnFlux_> smb: got ya.  We added 0x0411, 0x015D     but I'm seeing the occasional post about the same thing also being   0x0411, 014F
[09:12] <JohnFlux_> smb: e.g.  http://forums.ncix.com/forums/index.php?mode=showthread&msg_id=2026623&threadid=2026623&forum=105&product_id=37959&msgcount=0&overclockid=0
[09:12] <smb> JohnFlux_, I plan to do an upload late today. So it should become available latest next week. For some things I need other people to do it, so it can get delayed.
[09:13] <JohnFlux_> smb: Should I update  https://help.ubuntu.com/community/HardwareSupportComponentsWirelessNetworkCardsBuffalo   to change the status to working?
[09:13] <smb> JohnFlux_, If there are other IDs, those should get filed as separate bugs. Nothing worse that one bug with plenty of different "oh and this ID too"
[09:14] <smb> JohnFlux_, Maybe wait for the official kernel to be available for that
[09:14] <smb> Just being paranoid. ;-)
[09:15] <JohnFlux_> smb: hum, it seems easier to just add them now and see if we get bug reports about them
[09:15] <smb> JohnFlux_, And again, the official kernel will not contain the ID for that ralink 2070L
[09:15] <JohnFlux_> official ubuntu kernel, or official linus's kernel?
[09:16] <JohnFlux_> oh right, the 2070
[09:16] <JohnFlux_> Hopefully I can get someone else to confirm it works in time
[09:16] <JohnFlux_> but..   what's the harm?
[09:16] <JohnFlux_> we know that this is the driver that should be used
[09:16] <JohnFlux_> we know that it _should_ work
[09:16] <JohnFlux_> and we know that without the change, it certaintly won't work
[09:16] <JohnFlux_> so what's the harm in just adding it?
[09:17] <smb> JohnFlux_, Exactly _should_. I like to be _certain_
[09:17] <JohnFlux_> smb: I can be _certain_ that it won't work without it
[09:17] <JohnFlux_> smb: how's that for certain? :P
[09:17] <smb> JohnFlux_, Not enough to convince me. :-P
[09:18] <JohnFlux_> smb: I don't really get why not :P  Seems a very obvious choice between "certaintly won't work" and "probably should work"
[09:18] <smb> JohnFlux_, But I won't carry a patch that _might_ work. If it _does_ work it should go upstream, but I won't bother Greg with something that maybe works
[09:19] <JohnFlux_> okay
[09:22] <amitk> JohnFlux_: we don't carry "probably works" patches. They has to be verification that it works.
[09:25] <JohnFlux_> is there a way to force a driver to work anyway for a given usb id?
[09:29] <smb> JohnFlux_, I think there is a bind file in sysfs for each driver, which you can echo IDs into...
[09:31] <amitk> JohnFlux_: http://lwn.net/Articles/143397/
[09:32] <amitk> JohnFlux_: apologies, that was for driver binding, this one is for adding a new ID: http://www.ha19.no/usb/
[09:33] <smb> amitk, Good find. I just was about to mention new_id
[09:33] <JohnFlux_> very interesting
[13:16] <JohnFlux_> smb: http://ubuntuforums.org/showthread.php?p=9030092#post9030092   someone said that your kernel doesn't boot for them?
[13:16] <JohnFlux_> smb: they mentioned that they have an eepc though
[13:16] <JohnFlux_> 'mounted root fs can not mount /dev/pts and something else cant mount rootfs'
[13:17] <JohnFlux_> Does this error mean anything to anyone ?
[13:19] <smb> It seems to be unable to find or mount the root file system and another virtual fs. Why is hard to say. Have you tried the kernel I made?
[13:19] <smb> Probably not as you had a working kernel before
[13:21] <JohnFlux_> smb: sorry, this is what someone else said
[13:21] <JohnFlux_> smb: I haven't actually tried your kernel :-)
[13:22] <JohnFlux_> smb: I pasted that error from that link I just gave
[13:22] <smb> But the information is not very detailed. Could be something gone wrong installing. Could be something in the build. But its just the usual build with two more patches
[13:22] <smb> I have seen that. But its hard to tell more
[13:23] <JohnFlux_> smb: might be something related to the EEPC ?
[13:24] <smb> I would doubt it. If they had been running Ubuntu before...
[13:27] <cnd> how do you delete a chroot after you don't need it anymore?
[13:27]  * cnd doesn't need lucid chroot now that I'm running lucid
[13:29] <smb> cnd, You could rm -rf and remove the entry from the config. But I would still keep it as its a better controlled environment
[13:30] <cnd> smb, good point, but not good enough when I need to conserve space :)
[13:31] <cnd> since I do most of my kernel builds on emerald.mills anyways
[13:31] <cnd> well, all my builds really
[13:32] <smb> cnd, How can one be so tight on space. I hardly was able to by a laptop hardrive below 250G nowadays. :-P
[13:32] <smb> cnd, But as said. You can edit /etc/schroot/schroot.conf and remove the lucid entry
[13:33] <smb> and then just remove the directory where you installed the chroot
[13:33] <pmatulis> are there recent kernels (PPA) i can try on 8.04? there is "Using newer kernels on LTS releases" in LP but it says the project is "closed"
[13:33] <smb> cnd, Just make double sure, that nothing has bind mounted /home somewhere in it
[13:33] <cnd> smb: macbook has 120GB, ~80 is used by os x (which I don't really use anymore, but need to keep around), and I have the rest split between main partition and test partition
[13:33] <cnd> smb: good call
[13:34] <smb> pmatulis, I don't think so.
[14:00] <ogasawara> manjo: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/507148 - will you be able to test the upstream patches?
[14:00] <ubot3> Malone bug 507148 in linux "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed] 
[14:03] <smb> manjo, Have you tested with the -17 kernel on that?
[14:09] <Keybuk> so tempted to do a companion blog to cking's blog of awesome
[14:10] <Keybuk> "system calls and C library functions you didn't know about"
[14:10] <Keybuk> today I found statfs()
[14:10] <cking> Keybuk, I only blog about obscure stuff so I can google search it later :-)
[14:11] <Keybuk> cking: and as a result, your blog is one of the most useful ones in the known universe ;-)
[14:11] <cking> you're too kind
[14:13] <Keybuk> more particularly, I know this trick
[14:13] <Keybuk> stat("/") => info
[14:13] <Keybuk> stat("/dev") => dev_info
[14:13] <Keybuk> if info.st_dev != dev_info.st_dev:
[14:13] <Keybuk>   then dev is mounted
[14:13] <cnd> smb, so about that acpi patch that upstream isn't biting on, I still think it should go into lucid
[14:13] <Keybuk> better trick, just statfs("/dev") :-)
[14:13] <cnd> smb: http://patchwork.ozlabs.org/patch/47164/
[14:14] <smb> cnd, I think I remember the one about the warning level for those resource conflicts
[14:14] <cnd> smb: yep
[14:14] <smb> cnd, Hasn't mjg59 acked that sort of? No I guess just said it would be ok
[14:15] <cnd> smb: right, he just seemed to agree in principle at the time
[14:15] <cnd> but I'd be happy to have mjg59 ack it (wink wink)
[14:16] <cnd> :)
[14:16] <smb> cnd, If nothing happens, we might go and take it as a sauce patch for now. But I guess I will leave that to the time apw gets back
[14:17] <cnd> smb: ok, just want to make sure it's not left until it becomes too late for inclusion
[14:17] <smb> cnd, No its still clearly visible on our list 
[14:18] <cnd> I'm just new to the process, so I figure it's better to be safe than sorry
[14:26] <cking> Keybuk, that's a trick worth documenting
[14:42] <cnd> amitk: what was your methodology for determining which power saving features to put into powersave-policy?
[14:42] <cnd> I'm curious if there's anything else that didn't do much for you, but maybe works well for others?
[14:43] <cnd> overall though, I'm not seeing a huge difference in power consumption with the extra policy scripts
[14:46] <amitk> cnd: the first step was just to make laptop-model-tools redundant. There are a few more script in laptop mode tools that were very hacking and/or too intrusive
[14:46] <amitk> s/hacking/hackish
[14:46] <cnd> amitk: so we've basically taken everything from laptop-mode-tools that seems reasonable?
[14:48] <amitk> cnd, yes IMO. I'll send you an email listing why I didn't pick the others.
[14:48] <cnd> amitk: thanks
[15:08] <ogasawara> JFo: can you add bug 532374 and bug 548513 to our list for monday
[15:08] <ubot3> Malone bug 532374 in linux "Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend" [Critical,Confirmed] https://launchpad.net/bugs/532374
[15:08] <ubot3> Malone bug 548513 in linux "Firewire disks not working under 10.04" [Critical,Confirmed] https://launchpad.net/bugs/548513
[15:08] <JFo> ogasawara, will do
[15:09] <smb> cking, Isn't that your pet area nowadays? ^
[15:09] <JFo> ogasawara, done
[15:09] <ogasawara> JFo: thanks. robbiew asked that we get them on our radar.
[15:09] <JFo> no problem
[15:10] <cking> smb, yes jerone asked me to eyeball that when I was on vacation. It's on my ever growing list
[15:11] <JFo> and I just made the list huge
[15:11] <JFo> Kernel Regression Bug Day schedule announced in e-mail
[15:11] <smb> cking, I wonder whether we might be allowed to volunteer you to have a look after that
[15:11] <cking> please do
[15:12] <smb> JFo, ^
[15:12] <JFo> ok, for the bug call on Monday?
[15:12] <pgraner> cnd: you want to save power? Turn of the bling, doing that on my netbook saved almost 2watts
[15:12] <cnd> pgraner: bling?
[15:12] <JFo> smb, that for the firewire one?
[15:12] <pgraner> cnd: bling == compiz
[15:12] <smb> JFo, If its on that list cking would have the best insight I think (no the i7)
[15:13] <pgraner> cnd: putting the gpu into 2d mode makes a big difference
[15:13] <cnd> pgraner: I have a feeling people would get upset if we started flipping compiz on and off every time you plug in and out of ac
[15:13]  * cking notes that disabling video and ssh'ing in helps save power too :-)
[15:13] <pgraner> cnd: yea since now it tends to gather you desktops onto one
[15:14] <pgraner> cking: you're so damn old school
[15:14] <pgraner> cking: X for me is nothing more than a VT arranging utility
[15:14] <cnd> pgraner: do you know how to disable compiz and 3d on demand?
[15:14] <cking> pgraner, I'm happy with a serial console ;-)
[15:14] <cnd> I'd like to try it personally just to see how effective it is
[15:14] <pgraner> cnd: nope, talk to bryceh 
[15:14] <pgraner> cnd: or one of the desktop guys
[15:15] <JFo> smb, ok
[15:15] <cnd> compiz for netbook edition seems overkill if I can get 2W back
[15:15] <cnd> since it only uses 10W right now anyways
[15:15] <cking> http://smackerelofopinion.blogspot.com/2009/11/improving-battery-life-on-hp-mini.html is my powersaving hack
[15:15] <cnd> and it should help with flash
[15:16] <cking> and also: http://smackerelofopinion.blogspot.com/2009/06/reducing-wifi-beacon-interval-to-save.html
[15:20] <pgraner> cnd: if your running compiz you can use: metacity --replace  & compiz --replace to switch between them
[15:21] <pgraner> cnd: I'm supposing you want to test it in the scripts?
[15:21] <cnd> pgraner: nope, just running metacity
[15:21] <cnd> pgraner: no, just for personal usage
[15:21] <cnd> and documenation
[15:21] <pgraner> cnd: well thats how you switch inbetween them
[15:22] <cnd> ok
[15:27] <crimsun> amitk: / cnd: hmm, I see (using cnd's pm-utils-powersave-policy 0.4~powersave2) that powerdown is now enabled for all hda when on battery -- that annoying pop will return for non-IDT/Sigmatel codecs
[15:27] <crimsun> that was the reason for the earlier check for the idt module
[15:27] <cnd> crimsun: yeah, Keybuk mentioned it, and I forgot to remove the script in powersave2
[15:27] <crimsun> ah ,ok
[15:28] <cnd> crimsun: unless there's some easy way to check for good codecs in the script?
[15:28] <cnd> though in that case, it should just be on all the time
[15:28] <crimsun> cnd: yes, in the original, I check for the existence of the module dir in /sys
[15:28] <cnd> and besides, this is targetted at M, at which point the popping should be sorted out for all the codecs right?
[15:28] <crimsun> sec, will pull the diff
[15:29] <crimsun> cnd: ah, so it's not for Lucid?
[15:29] <cnd> crimsun: no, it's too late for Lucid
[15:29] <crimsun> ah, then that's no big deal :-)
[15:31] <crimsun> cnd: yeah, just a simple [ -e $CODEC -a -w $PD ] currently (where $CODEC is /sys/module/snd_hda_codec_idt)
[15:32] <cnd> crimsun: so in M, the popping will be fixed for all codecs?
[15:33] <crimsun> cnd: kernel version-dependent, but yes
[15:33] <cnd> crimsun: what do you mean?
[15:34] <crimsun> cnd: well, there's the assumption that 2.6.32-2.6.34 won't be chosen
[15:35] <cnd> crimsun: ok?
[15:35] <crimsun> cnd: so with a sufficiently new kernel, then yes, those symptoms are fixed
[15:35] <cnd> how new are we talking? .34 isn't out yet
[15:36] <cnd> is there some patch waiting in the wings for the .35 merge window?
[15:36] <crimsun> yes, I have updates for the conexant and realtek ones
[15:36] <crimsun> there were a number of realtek ids added since 2.6.32
[15:37] <cnd> ok
[15:37] <cnd> even if M is based on .34, we'd likely take a look at the patches anyways
[15:37] <cnd> especially if it's just a matter of ids at that point
[15:38] <crimsun> ok
[15:40] <cnd> amitk: what about laptop_mode itself?
[15:40] <cnd> doesn't laptop-mode-tools enable that? pm-powersave doesn't yet
[15:46] <marga> Hi!  I'm a Debian person (user, developer, etc), but I'm trying to help an Ubuntu user, that has a 32bit user space Ubuntu installation, with a 64bit processor.  In Debian we have an -amd64 flavor, for 64 bits processors with the i386 userspace.  By looking at the Ubuntu flavors for i386, the one that is 64bits -apparently- is -server... What is special about -server? Can it be used by a 64bit desktop?
[15:49] <amitk> cnd: yeah, that should be enabled too
[16:07] <cnd> amitk: I reread the spec, and laptop_mode shouldn't be enabled by default per Ted T'so due to interactions with ext4
[16:07] <cnd> so we look good there
[16:18] <cnd> amitk: thanks for the writeup!
[16:18] <cnd> helps explain many questions I had
[16:31] <nosse1> Hi. I'm trying to build a kernel for an ARM target. Where can I find a "standard" set of kernel config which represents what ubuntu requires from the kernel?
[16:40] <manjo> ogasawara, on https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/507148 building and testing the kernel on jdstrand's laptop 
[16:40] <ubot3> Malone bug 507148 in linux "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed] 
[16:40] <ogasawara> manjo: cool, thanks
[16:40] <manjo> ogasawara, was busy with several audio bugs ... so results will be after lunch ... 
[16:41] <ogasawara> manjo: k thanks, just mainly wanted to know the status for the release meeting
[16:41] <manjo> ogasawara, ah ok... 
[16:53] <crimsun> manjo: for #548371, your Mic Boosts are still set at zero
[16:53] <crimsun> (...unless you're just pasting outdated alsa-info output?)
[16:54] <manjo> crimsun, no the last one I posted was with  ubuntu audio dev ppa 
[16:55] <crimsun> manjo: I mean that you're running the script when the capture is not occurring
[16:55] <crimsun> same for #528719, BTW
[16:57] <manjo> hmmm so what is that amixer option to boost it ? 
[16:57] <manjo> crimsun, ^  ?
[17:11] <crimsun> manjo: (sorry, I'm at a conference currently) for which bug?
[17:12] <manjo> should I do amixer set 'Capture',1 cap
[17:12] <crimsun> manjo: for #528719, it's amixer set 'Mic Boost' 100%,100%
[17:13] <manjo> ok
[17:13] <crimsun> similar for #548371 but you also need 'Front Mic Boost'
[17:17] <manjo> crimsun, after the boost I still get white noise 
[17:17] <manjo> crimsun, I hear my voice very very faintly.
[17:19] <crimsun> manjo: for which hw?
[17:19] <manjo> acer
[17:19] <manjo> #528719
[17:22] <manjo> crimsun, on the aspire1 
[17:22] <manjo> Simple mixer control 'Mic Boost',0
[17:22] <manjo>   Capabilities: volume penum
[17:22] <manjo>   Playback channels: Front Left - Front Right
[17:22] <manjo>   Capture channels: Front Left - Front Right
[17:22] <manjo>   Limits: 0 - 3
[17:22] <manjo>   Front Left: 3 [100%]
[17:22] <manjo>   Front Right: 0 [0%]
[17:22] <manjo> how do I boost  Front Right: 0 [0%] to 100% ? 
[17:22] <crimsun> manjo: err, did you use the syntax above?
[17:23] <manjo> yes
[17:23] <crimsun> huh. Well, just 100%
[17:24] <manjo> ok that made both 100%
[17:24] <crimsun> bah, bug in amixer :-(
[17:25] <manjo> ok tried after setting that.... and again .. white noise with faint recording of the sound 
[17:26] <manjo> crimsun, btw the bug is only when using external mic, and does not occur with built in mic 
[17:26] <manjo> crimsun, I have used 2 diff mics to make sure its not the mic hw
[17:28] <crimsun> manjo: ok, please update the bug reports, respectively. I'm having a difficult time tracking irc and conference simultaneously, sorry
[17:28] <manjo> crimsun, no problem! will update
[17:28] <crimsun> I should have a free stretch in two hours
[21:19] <cnd> bryceh: I'm looking at bug 544741
[21:19] <ubot3> Malone bug 544741 in linux "[X700] KMS, amd64: Kernel panic while trying to launch system > preferences > appearance" [High,Triaged] https://launchpad.net/bugs/544741
[21:19] <cnd> I saw your email about edid quirks
[21:20] <cnd> actually, let me read the email once again, and I'll get back to you
[22:55] <mozmck> How do I create a new flavour of the lucid kernel?