[13:54] <mjg59> BenC: #180678 - seriously. Every single release I can remember. This really isn't funny any more.
[13:54] <alex_joni> bug #180678
[13:54] <ubotu> Launchpad bug 180678 in acpi-support "dmesg: toshiba_acpi: Unknown parameter `hotkeys_over_acpi'" [Medium,In progress] https://launchpad.net/bugs/180678
[13:56] <BenC> mjg59: every release it is the same reason...acpi core changes so much the patch cannot be applied
[13:56] <BenC> mjg59: pretty sure it was in the list of "patches that got left behind"
[13:57] <BenC> mjg59: we've audited the patches that got removed at hardy kernel rebase, and that's the only one
[13:58] <mjg59> BenC: As far as I can tell, that mail never went anywhere public?
[13:58] <mjg59> Amit replied with a subset Cc:ed to kernel-team
[13:59] <BenC> mjg59: I mean the list I sent you months ago
[14:03] <mjg59> BenC: No, it's not in that list
[14:04] <mjg59> Can you check whether any other patches have fallen through the cracks?
[14:14] <amitk> BenC: can you please send me this other list that you sent to mjg59
[14:14] <BenC> mjg59: I told ya we just did an audit of the patches :)
[14:14] <BenC> amitk: it's the same one you got, minus stuff that already got checked
[14:14] <amitk> BenC: ok
[14:15] <mjg59> BenC: As I said, that patch isn't in hardy git. It was in gutsy. It's not in the email you sent me.
[14:15] <mjg59> If your audit process doesn't pick that up, then that's a problem with your audit process
[14:16] <mjg59> Which is consistent with previous occasions where patches have gone missing from the lists of missing patches
[14:18] <mjg59> BenC: 2d35697db5e3c4f240ac288c7c5abeb5a03c805c in gutsy
[14:19] <BenC> interesting...it applies cleanly...wonder why it didn't hit the rebase
[14:20] <mjg59> BenC: It would be good to know if anything else falls into the same category
[14:20] <rtg> BenC: be sure to mark it as  a SAUCE patch so we don't lose it again.
[14:59] <siretart> did someone already encounter bug #197006, and/or knows a workaround?
[14:59] <ubotu> Launchpad bug 197006 in linux-meta "NFS over Unionfs prevents updating existing files" [Undecided,New] https://launchpad.net/bugs/197006
[15:16] <BenC> mjg59: toshiba_acpi patch applied
[15:16] <mjg59> BenC: Thanks
[15:55] <rtg> tjaalton: I'm turning the ABI crank today. I'll upload -11 in a few hours in advance of Alpha 6 scheduled for next Thursday.
[16:12] <Kano> hi rtg , did you find my bug report
[16:12] <Kano> rtg: btw. the ivtv-fb driver is not working, maybe compiled against wrong header
[16:12] <rtg> Kano: I didn't notice it. What number is it?
[16:12] <Kano> #196745
[16:13] <Kano> will check if i can do a fix for ivtv-fb
[16:13] <rtg> Kano: we are still working on the ABI mismatch which is probably what is wrong with ivtv-fb
[16:13] <Kano> yes the most easy way is to overwrite the included .h files with the one from the kernel
[16:13] <Kano> that fixes it
[16:14] <rtg> Kano: can't do that (debian policy). see https://wiki.ubuntu.com/KernelTeam/Sprints/Feb2008/HeadersABI for possible solution
[16:15] <Kano> then remove the included headers
[16:15] <Kano> how about that
[16:15] <Kano> they are not needed anyway
[16:15] <rtg> dunno. we'll get it figure out before Beta.
[16:16] <Kano> the fastest hack is just to replace the ivtv-fb headers - not the kernel ones
[16:18] <rtg> Kano: at the risk of sounding pedantic, file a  LP bug so I can track it.
[16:18] <Kano> rtg: will try to fix it and then report a bug
[16:18] <Kano> i have got a pvr 350..
[16:19] <Kano> just dont use it so often
[16:24] <tjaalton> rtg: ok, I have nvidia almost ready to go, targeted -11
[16:24] <Kano> rtg: how about enabling vmware client modules?
[16:25] <rtg> Kano: which ones? seems like there is a pending LP for a sound module.
[16:25] <Kano> well the standard ones needed for vmplayer
[16:26] <Kano> i think those will not change
[16:26] <rtg> Kano: do you think enabling ALSA in the kernel would be sufficient?
[16:26] <Kano> virtual box needs always differnet modules, so i would not integrat it
[16:27] <Kano> i think you have alsa already enabled?
[16:27] <Kano> didnt you
[16:27] <tjaalton> zul: what about xen & nvidia?
[16:28] <zul> tjaalton, i havent got a chance to look at it
[16:29] <tjaalton> zul: ok
[16:40] <Kano> rtg: also did you notice that "ifneq ($(wildcard /CurrentlyBuilding),)" has to be "ifeq ($(wildcard /CurrentlyBuilding),)" in debian/rules.d/0-common-vars.mk ?
[16:40] <Kano> currently it is absolutely stupid that it compiles faster when there is a dir/file named /CurrentlyBuilding
[16:41] <Kano> dont you think so...
[16:42] <Kano> ps aux|grep -e -j
[16:42] <rtg> Kano: looks to me like it just overrides CONCURRENCY_LEVEL when on a buildd.
[16:43] <Kano> yes, but completely in the wrong way
[16:43] <Kano> why would somebody build on a multi core machine with -j1?
[16:44] <Kano> you could even disable that check
[16:44] <rtg> Kano: because there might be other builds going on the same machine.
[16:44] <Kano> rtg: i thought that, but then the logic is completely reversed!
[16:45] <Kano> as you compile with 1 thread when there is NO such file and with twice the number of cores when it is there
[16:45] <Kano> check it out yourself
[16:48] <Kano> you will at least see -j2 even with a single core when the file is there and -j1 when it is not there
[16:48] <Kano> must be clear
[16:48] <Kano> that this is wrong
[16:48] <rtg> Kano: this particular problem is not important. I've a zillion other issues to deal with. buildd passes happen overnight for me, so I just don't care.
[16:49] <Kano> rtg: but i care
[16:49] <rtg> start a bug report then.
[16:49] <Kano> you only have to remove the "n" 
[17:06] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197040
[17:06] <ubotu> Launchpad bug 197040 in linux "reversed logic for bbuild check leads to -j1 default" [Undecided,New] 
[17:06] <Kano> here it is
[17:31] <Kano> sound/usb/usx2y/snd-usb-usx2y.o
[17:31] <Kano> you mean that erro?
[17:52] <Kano> hmm no, the error is in toshiba_acpi.c
[17:52] <Kano> what did you do there
[17:54] <rtg> Kano: I'm just getting to buld testing. looks like the acpi crack broke something.
[17:54] <Kano> yes it does not build
[17:54] <tjaalton> rtg: lrm with new nvidia ready
[17:55] <rtg> tjaalton: I'm still build testing. it'll be a bit yet.
[17:55] <tjaalton> rtg: np
[17:56] <Kano> tjaalton: if you added .12 then you can be sure it will not be the last update
[17:56] <tjaalton> Kano: surprise
[17:57] <Kano> latest is still set to 169.112
[17:57] <Kano> that can show my script with -v latest option...
[17:58] <Kano> DISPLAY= fakeroot install-nvidia-debian.sh -pv latest
[17:58] <Kano> 169.12
[17:58] <rtg> mjg59: can you have a look at the acpi patch BenC applied? It doesn't build, so I've reverted it. I'm kind of on a deadline for Alpha 6.
[17:58] <mjg59> rtg: Not currently, no
[17:59] <mjg59> I'm up to my eyes in mobile
[18:00] <rtg> mjg59: ok, its gonna have to wait until after -11 is released.
[18:00] <mjg59> Well, as long as it hits before final, I'm unfussed
[18:00] <rtg> mjg59: can do.
[18:02] <Kano> btw. you know that at least 2 ide modules are too much?
[18:03] <Kano> via82cxxx and amd74xx are useless, because you have pata_via and pata_amd
[18:03] <Kano> which work much better
[18:04] <Kano> maybe more, but you can be sure that pata drivers are tested for those
[18:05] <Kano> tjaalton: so what did you package 169.12 or 171.05?
[18:09] <Kano> btw. did you try pxe boot for your live images?
[18:10] <Kano> live-helper can for example use net as target
[18:10] <Kano> and creates a tftpboot dir
[18:12] <boucman> hello all
[18:12] <boucman> I have been skimming the bug list for some time, but can't find a bug similar to what I observe
[18:13] <boucman> my machine has some huge speed problems with 2.6.24 (2.6.22 is fine)
[18:13] <Kano> boucman: lsmod|grep -e ide -e pata
[18:13] <Kano> best check this
[18:14] <Kano> if you have got an legacy ide + pata driver loaded blacklist the old ide and run: update-initramfs -u
[18:14] <boucman> Kano: thx... I'm using 2.6.22 right now, are you interested in what it reports, or should I reboot in 2.6.24 to check ?
[18:15] <Kano> well you would need 2.6.24
[18:15] <Kano> to get this output
[18:15] <boucman> I do get an output :P
[18:16] <Kano> sure, but i dont think something with pata or?
[18:16] <boucman> Kano: you're right
[18:17] <boucman> I'll reboot in a minute, but since I'm unable to log to irc with that kernel, what should I be looking for precisely ?
[18:17] <Kano> the problem is when you would do that now you could not boot your old kernel ;)
[18:17] <Kano> i would prefer those old modules removed, but..
[18:17] <boucman> you mean 2.6.22 wouldn't boot anymore after doing that ?
[18:18] <Kano> if you blacklist the module and run update-initramfs -u (updates initramfs for current kernel)
[18:19] <Kano> usually the new kernel runs the devices without dma access
[18:19] <Kano> because 2 drivers want to work with the same device, disabling the old ones fixes that usally
[18:20] <boucman> Kano: ok, can you walk me throught the process (or point me to a web page ) I would be gratefull
[18:20] <Kano> well i dont think that ubuntu ppl did that before, thats what i did for kanotix users ;)
[18:22] <boucman> ok, so 
[18:22] <boucman> 1) blacklist the module 
[18:22] <tjaalton> Kano: 169.12
[18:22] <boucman> 2) reboot with .24 kernel
[18:22] <boucman> 3) run "update_initramfs -u"
[18:22] <boucman> right ?
[18:22] <Kano> no you forget the major step
[18:22] <boucman> oh, 
[18:22] <Kano> the blacklisting
[18:23] <boucman> that was step 1, but I'm not sure how to do that
[18:23] <Kano> show me lsmod|grep -e ide -e pata
[18:23] <Kano> after reboot
[18:23] <boucman> Kano: ok, I'll reboot, do that and come back.
[18:23] <boucman> then we'll discuss how to fix
[18:23] <boucman> and thx a million for your help
[18:23] <boucman> brb
[18:27] <boucman> back
[18:28] <Kano> so check lsmod|grep -e ide -e pata
[18:28] <Kano> also
[18:28] <Kano> cat /etc/fstab
[18:28] <Kano> cat /proc/cmdline
[18:28] <boucman> video                  23316  0 
[18:28] <boucman> output                  5632  1 video
[18:28] <boucman> ide_core              136344  1 amd74xx
[18:28] <boucman> pata_amd               16772  0 
[18:28] <boucman> pata_acpi               9856  0 
[18:28] <boucman> libata                176304  4 pata_amd,sata_nv,ata_generic,pata_acpi
[18:28] <Kano> to be sure that you use uuids
[18:28] <boucman> that's under .24 (i'm back to .22 right now)
[18:28] <Kano> the problem is definitely amd74xx
[18:28] <boucman> ok
[18:28] <Kano> why dod you boot the .22 kernel?
[18:29] <Kano> doesnt it boot at alls?
[18:30] <boucman> it does, but usually it takes approx 5' just to start pidgin
[18:30] <boucman> so not really usable
[18:30] <Kano>  cat /proc/cmdline
[18:30] <Kano> show this
[18:30] <boucman> root=UUID=aefdb9c5-c42d-4de4-863d-e8db4afcd1e8 ro quiet splash
[18:30] <Kano> ok, should be no problem to use the fix
[18:30] <boucman> :)
[18:30] <Kano> which 2.6.24 do you want to fix
[18:31] <boucman> main one, I guess
[18:31] <Kano> -10?
[18:31] <boucman> yes, that's the latest one
[18:31] <Kano> ls /boot/vmlinuz-2.6.24-*
[18:31] <boucman> (so far :P )
[18:31] <Kano> show this
[18:31] <boucman> /boot/vmlinuz-2.6.24-10-generic
[18:31] <Kano> echo blacklist amd74xx > /etc/modprobe.d/custom-blacklist
[18:32] <Kano> update-initramfs -uk 2.6.24-10-generic
[18:32] <Kano> then you should be able to boot new kernel
[18:33] <boucman> running...
[18:33] <boucman> ok, done
[18:33] <boucman> I'll be back in a minute (hopefull with .24) thx again for your time
[18:33] <Kano> i hope you did that after sudo -i
[18:34] <Kano> then it should work
[18:34] <boucman> yeah, I used the "administrator terminal" not the normal one
[18:35] <Kano> rtg: at least it compiles with reverted toshiba
[18:36] <Mike_Feravolo> Hello People
[18:37] <Mike_Feravolo> I loaded the lastest hardy update and my dual amd opteron 840 will not boot anymore
[18:38] <Kano> Mike_Feravolo: i guess because of amd74xx kernel module in initrd ;)
[18:38] <boucma1> hmm
[18:38] <Mike_Feravolo> i just what to make sure that someone knows
[18:38] <Kano> boucma1: didit boot
[18:39] <boucma1> Kano: yes, but pidgin froze at startup like it used to, I'll start a few app to see if it's better than previously
[18:39] <Mike_Feravolo> i have been running the hardy alpha for a couple of months and this is the first major snarl
[18:39] <boucma1> and login was very slow...
[18:40] <Kano> boucma1: but at last the hd should be fast, you could check that
[18:40] <Mike_Feravolo> kano- hangs on the UBUNTU splash screen
[18:40] <boucma1> Kano: yes, it seems to work better but still very slow
[18:40] <Kano> boucma1: i only use the kenrel not the rest
[18:41] <boucma1> Kano: well, pidgin start time was my measure of perf, but it applies to everything
[18:41] <boucma1> it's usable now, at least
[18:41] <Kano> boucma1: fdisk -l
[18:41] <Kano> then you will see only sd?
[18:41] <Kano> you can then check performance with
[18:41] <Kano> hdparm -tT /dev/sd?
[18:42] <Mike_Feravolo> I am not near that system now, but i will try a few things before reloading gusty - Thank You
[18:42] <Kano> Mike_Feravolo: can you boot antoher kernel?
[18:42] <boucma1> /dev/sda:
[18:42] <boucma1>  Timing cached reads:   1604 MB in  2.00 seconds = 801.97 MB/sec
[18:42] <boucma1>  Timing buffered disk reads:  220 MB in  3.00 seconds =  73.27 MB/sec
[18:42] <boucma1> (no idea if that's good
[18:43] <Kano> sure, without dma it would be less than 10 the 2nd one
[18:43] <boucma1> ok
[18:43] <Mike_Feravolo> yes the gusty 64 live cd boots, so does dsl, slax and other 32bit distros
[18:44] <Kano> well you only need a live cd to chroot to it
[18:44] <Kano> if your install is 64 bit you need that of course
[18:44] <Mike_Feravolo> kk
[18:44] <Mike_Feravolo> thanks
[18:44] <boucma1> ok, thx a lot, I'll use it like that
[18:44] <boucma1> bye all
[18:45] <Kano> rtg: i hope you get how bad the amd* module is...
[18:45] <Kano> via is not needed too
[18:47] <Kano> blacklisting is a bit dangerous to older kernels,but easy to verify
[18:47] <Kano> best disable the modules you dont need
[18:50] <Kano> via+amd are the most common ones
[19:10] <Kano> rtg: disable at least
[19:10] <Kano> grep BLK_DEV /boot/config-2.6.24-10-generic |grep -e AMD -e VIA
[19:10] <Kano> CONFIG_BLK_DEV_AMD74XX=m
[19:10] <Kano> CONFIG_BLK_DEV_VIA82CXXX=m
[19:10] <Kano> to avoid huge problems
[19:10] <Kano> amd is critical
[19:33] <Kano> rtg: also you could use -jX for lum too
[19:37] <Kano> rtg: http://paste.debian.net/50205
[19:37] <Kano> thats the problem with ivtv-fb
[19:58] <Kano> rtg: what you try is to use ivtv-driver.h
[19:58] <Kano> rtg: thats basically <linux/ivtv.h>, but then you have to fix the driver itself
[19:59] <rtg> Kano: is there a patch for ivtv-fb ?
[19:59] <Kano> well not an easy one
[19:59] <Kano> 1.0.3 is only up to 2.6.23
[19:59] <Kano> where did you get the driver?
[20:00] <rtg> dunno, probably inherited it from Feisty/Gutsy
[20:02] <Kano> will check if the driver can be used from v4l hg
[20:03] <Kano> maybe you need then ivtv + ivtvfb from hg
[20:10] <Kano> hmm that will also need m52790
[20:16] <rtg> Kano: https://bugs.edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/197089
[20:16] <ubotu> Launchpad bug 197089 in linux-ubuntu-modules-2.6.24 "ivtv oops" [Medium,Confirmed] 
[20:17] <Kano> well disalbing is not really fun. as you could even use a new xorg driver with it or for pvr350 output plugin
[20:18] <Kano> btw. the -j bug is in lum too
[20:18] <Kano> for debugging -j1 is more easy but in that case you can set CONCURRENCY_LEVEL=1 if needed
[20:29] <Kano> rtg: maybe it is much more easy 
[20:30] <Kano> you have that module already
[20:30] <Kano> in the main kenrel
[20:30] <Kano> but you miss the right firmware
[20:31] <rtg> Kano: attaching a patch to the LP report increases the likely hood  that it will get fixed .
[20:31] <Kano> rtg: you can remove the code completely from lum
[20:31] <Kano> the module is default and enabled in the kernel
[20:31] <Kano> you only need the correct firmware
[20:32] <rtg> which needs to be updated in lum
[20:32] <Kano> hmm
[20:33] <Kano> when this is already in lum just disable the module -you can completely remove the code
[20:33] <Kano> http://paste.debian.net/50210
[20:33] <Kano> when i remove lum
[20:34] <Kano> grep -i ivtv /boot/config-$(uname -r)
[20:34] <Kano> CONFIG_VIDEO_FB_IVTV=m
[20:34] <Kano> CONFIG_VIDEO_IVTV=m
[20:34] <Kano> standard kernel
[20:34] <rtg> is the firmware the same version as is already in lum? the file names are the same as the web site.
[20:34] <Kano> didd not try, but look
[20:34] <Kano> isnt that nice
[20:35] <rtg> its certainly an easy fix.
[20:43] <NthDegree> where can I find a list of .patch files used in the Ubuntu Gutsy kernel?  as in each individual patch, like for example just ubuntu's apparmor patches or just ubuntu's dazuko patches 
[20:45] <Kano> rtg: yes and it seems to work
[20:45] <rtg> NthDegree: https://wiki.ubuntu.com/KernelGitGuide
[20:46] <Kano> http://paste.debian.net/50212
[20:46] <rtg> NthDegree: search the log for 'SAUCE:'. Thats most of our special patches.
[20:46] <NthDegree> hmmm
[20:47] <Kano> so you just have to disable some legacy ide modules
[20:47] <rtg> Kano: I'm still researching that
[20:47] <NthDegree> rtg: so there's no chance of just grabbing things like a linux-2.6-apparmor.patch or the like that applies to the Ubuntu kernel then?
[20:48] <Kano> rtg: kanotix thorhammer has a kernel completely without config_ide set. only very few pcs could not boot it
[20:48] <Kano> the 2 modules i told you before are definitely verified
[20:48] <Kano> and share the same pciids
[20:48] <rtg> Kano: its likely that I'll blacklist them so that the binaries are still built, just not installed.
[20:49] <Kano> no good idea
[20:49] <Kano> because when somebody executes update-initramfs -uk all
[20:49] <Kano> then older 2.6.22 kernel will never be bootable
[20:51] <Kano> isnt something like that even triggered by module-init-tools?
[20:51] <Kano> you can use that as hotfix
[20:51] <Kano> but no for permanent use
[20:52] <rtg> Kano: start an LP report so we don't lose track, but its gonna have to wait until after Alpha 6 and I'm gone Mar 4-27 so you'll have to deal with the other kernel folks
[21:13] <zul> hmmm... https://wiki.ubuntu.com/ZenKernel