[00:05] <infinity> zequence: You got the bug closure syntax wrong in your lowlatency upload to precise, BTW.
[00:06] <infinity> zequence: Needs to be "LP: #1234" not "LP:#1234"
[00:06] <ubot2`> Launchpad bug 1234 in Launchpad itself "Gina is an unmaintainable mess of command line options, environment variables and shell scripts" [Medium,Fix released] https://launchpad.net/bugs/1234
[00:06] <infinity> zequence: (Closing the bug manually this time)
[00:07] <infinity> smb`: And you just completely missed having the right tracking bug in the linux-ec2 upload. :)
[00:09] <Kano> hi, what was the reason to switch CONFIG_SATA_AHCI=y to CONFIG_SATA_AHCI=m?
[00:09] <Kano> with =m the kernel alone of course does not boot with efibootmgr, initrd is required which is slower
[00:11] <Kano> switched from 3.8 rc6 to rc7
[00:13] <infinity> Kano: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1056563
[00:13] <ubot2`> Ubuntu bug 1056563 in linux (Ubuntu) "Please change AHCI driver back to module in 12.10" [Medium,Fix released]
[00:13] <infinity> Kano: In short, it can conflict with other modules, so builtin is the wrong answer for a generic kernel.
[00:14] <Kano> why is that raid ahci not mainline
[00:15] <Kano> that would be the correct answer
[00:16] <Kano> http://kanotix.com/files/dragonfire/linux-3.8.0-6.13kanotix1/0001-Bluetooth-Add-support-for-AR3012-0489-e04e.patch
[00:16] <Kano> that should be added as well. if you want signed it and push to mainine
[00:16] <Kano> did you add that to your kernel?
[00:16] <Kano> http://kanotix.com/files/dragonfire/linux-3.8.0-6.13kanotix1/media-cx18-ivtv-fix-regression-remove-__init-from-a-non-init-function.patch
[00:17] <Kano> without you can not boot 3.8 with ivtv or cx18 card installed
[00:17] <infinity> Kano: There's a mailing list for your patches.
[00:18] <Kano> i hate mailinglists, btw. the 2nd is from one
[00:18] <Kano> it is not my patch only the first
[00:18] <infinity> s/patches/pull requests/
[00:18] <Kano> http://patchwork.linuxtv.org/patch/16734/
[00:19] <Kano> that patch is critical
[00:21] <Kano> so you see, it was on the list and was not added
[00:21] <ohsix> "i hate the thing everyone uses to do this, but i insist on doing this"
[00:22] <infinity> Kano: Fine.  Can you mail a pull request to kernel-team@?  Thanks.
[00:22] <Kano> well you can tell your users to use kanotix instead too, there it is fixed ;)
[00:23] <Kano> bye
[00:23] <ohsix> somehow that's a reasonable thing to do, but not for the reason he stated :d
[06:41] <zequence> infinity: Sorry, and thanks
[07:51] <ppisati> moin
[08:28] <smb> infinity, meh.... :-P
[08:28] <smb> morning
[08:35] <ppisati> smb: moin
[09:08] <apw> moin
[09:08] <apw> infinity, bah i missed that too
[09:08]  * apw self flagilates, and it is far too early for such things
[09:15] <smb> apw, isn't it also too early to start punching oneself
[09:18] <apw> i am not very accurate at this time of day for sure
[09:32] <apw> ppisati, there was some resaon we had CONFIG_CPU_FREQ turned off for omap wasn't there
[09:33] <ppisati> apw: yes, upstream is missing some pieces for omap4
[09:33] <apw> ppisati, sweet
[09:33] <ppisati> apw: if we turn if on, it crashses on boot
[09:33] <apw> ppisati, now that is a good reason indeed
[09:34] <ppisati> apw: there should be a link to the upstream discussion about it in the config change that i sent
[09:36] <apw> ppisati, no that is enough info, i trust your judgement on these things.  i am annotating it so the config checker doesn't try and turn it back on
[09:36] <ppisati> apw: ack
[09:45] <apw> ppisati, CONFIG_IMX_SDMA and CONFIG_IMX_DMA are off for -omap, are they not useful for imx ?
[09:46] <ppisati> apw: probably not fr the board that we support, but letme check
[09:46] <apw> ppisati, thanks
[09:47]  * ppisati is eating strawberries.. and he loves it... :)
[09:47] <aissen> Any idea why why tigon and bnx2x were removed from linux-firmware in 1.88 ?
[09:48] <apw> aissen, have you checked the changelog ?
[09:49] <apw> aissen, and in which release are you talking abuot ?
[09:50] <aissen> I checked the changelog, it says: "Remove boot essential duplicated firmware files that are also carried in the linux-image package."
[09:50] <aissen> the release is quantal but it carried over raring.
[09:51] <apw> aissen, ahh there you go, so we think it is in linux
[09:51] <aissen> Is it to save some space then ?
[09:52] <apw> aissen, yeah there is no point in having two copies on the system for sure
[09:52] <apw> now if we have ended up with zero copies that is broken
[09:53] <aissen> yeah, I would have removed the copy in linux-image; but maybe there's something I don't understand. Is linux-image used in places where linux-firmware isn't ? (network boot?)
[09:54] <apw> aissen, i suspect so indeed
[09:55] <aissen> that's what I thought but I wanted input from someone who knew the rationale.
[09:55] <apw> rtg would have done the changes, he has been on a mission for firware upstream and in ubuntu, trying to rationlise it all
[09:57] <aissen> yeah, first thing I noticed is that rtg wasn't here. I'll wait till he comes back
[10:16] <ppisati> apw: right, IMX_SDMA and IMX_DMA are all for boards that we don't support (imx 31/35/51/53 and imx 21/27)
[10:17] <ppisati> apw: actually support for those boards is all upstream, so if anyone has the hw we could easily add support for it
[10:21] <apw> ppisati, but for now off makes sense ?
[10:21] <ppisati> apw: yep
[10:42] <ogra_> oh, a fix for adhoc wifi support on the nexus7 https://launchpadlibrarian.net/132034143/linux-nexus7_3.1.10-9.27-adhoc.patch
[10:42] <ogra_> (thats bug 1077704 )
[10:42] <ubot2`> Launchpad bug 1077704 in ubuntu-nexus7 "Can't connect to ad-hoc wifi networks" [Medium,Confirmed] https://launchpad.net/bugs/1077704
[11:28] <apw> ppisati, CONFIG_HWSPINLOCK_OMAP is off in -omap, is that deliberate
[11:32] <apw> ppisati, CONFIG_KEYBOARD_IMX is off in -omap ... what about that one
[11:33] <ppisati> apw: HWSPINLOCK_OMAP seems omap4-only, i'll have to check it
[11:33] <ppisati> apw: KEYBOARD_IMX can be compiled as a module
[11:34] <apw> ppisati, it may be that the first one is not possible when you have a generic thing going on indeed.  thanks for investigating
[11:35] <apw> ppisati, K_IMX ack
[11:36] <ppisati> apw: i'll give the first option a try
[11:36] <apw> ppisati, CONFIG_MTD_NAND_MXC on -omap ?
[11:38] <apw> ONFIG_MMC_MXC too
[11:38] <ppisati> apw: /me checking
[11:39] <ppisati> apw: MMC_MXC is !imx6 (our board)
[11:39] <apw> ppisati, ack will leave it be then
[11:41] <ppisati> apw: apw same for MTD_NAND_MXC (is for the imx31)
[11:41] <apw> ppisati, ack ta
[11:48] <apw> ppisati, CONFIG_PWM_IMX ?
[11:49] <ppisati> apw: =m?
[11:50] <apw> ppisati, will do 
[12:06] <cnf> hi. I'm trying to compile some 3rd party kernel modules for packaging in a .deb however, my kernel modules won't load on any system it wasn't compiled on
[12:06] <cnf> i'm compiling against the same ubuntu stock kernel (3.2.0-29-generic)
[12:06] <apw> cnf, if you are able to distribute the source, then you might want to be using dkms
[12:06] <cnf> apw: i don't want compilers on all the servers
[12:07] <apw> cnf, well as we build LBM that exact same way it should work as far as i know
[12:07] <apw> cnf, what happens when you try to load them
[12:07] <cnf> eb 22 11:46:38 62-213-199-42 kernel: [ 2652.522284] saa716x_core: disagrees about version of symbol dvb_frontend_detach
[12:07] <cnf> Feb 22 11:46:38 62-213-199-42 kernel: [ 2652.522288] saa716x_core: Unknown symbol dvb_frontend_detach (err -22)
[12:07] <cnf> times a lot :P
[12:08] <apw> cnf, and you are absolutly sure it was the same version of the kernel, and the very same compiler version as built the kernel
[12:09] <apw> cnf, and you are sure you used the right .config
[12:09] <cnf> apw: i'm building in a vm, if i delete de vm right after compilation, and reinstall the same kernel
[12:09] <cnf> it fails
[12:09] <cnf> if i load them right after i compiled them, it works
[12:10] <cnf> both with linux-image-3.2.0-29-generic
[12:10] <cnf> maybe i'm doing something wrong, or missing something, but i can not figure out what
[12:11] <cnf> apw: and the .config in the kernel source tree is identical to the one in /boot/ for the running kernel
[12:11] <apw> cnf, and if you reboot the original VM and try installing them again does that work
[12:11] <apw> as that should be equivalent to your delete and recreate VM
[12:11] <apw> in theory as the bits should be the same
[12:12] <cnf> apw: yeah, i can reboot the vm, and reinstall the .deb
[12:12] <cnf> works fine
[12:12] <cnf> wipe the vm, bring it up again (vagrant), install kernel image and my package
[12:12] <cnf> no go
[12:13] <cnf> i'm sure i'm doing something stupid, but what :/
[12:13] <apw> cnf, i struggle to see how that could not work, as otherwise we could not ship lbm
[12:13] <apw> cnf, what release
[12:13] <cnf> apw: of?
[12:13] <apw> ubuntu
[12:14] <cnf> oh,
[12:14] <cnf> Ubuntu 12.04 LTS
[12:14] <cnf> (target is 12.04.1, but i'm ignoring that one for now)
[12:15] <apw> cnf, can i have a full dmesg from a failure please
[12:15] <cnf> sure, hold on
[12:15] <cnf> http://pastie.org/6316122
[12:18] <cnf> apw: i could even share the vagrant project, if you have ny use for it
[12:24] <apw> cnf, can i get the whole dmesg from the top pls
[12:25] <apw> cnf, and a cat /proc/version and a gcc -v from the system failing to load them
[12:26] <cnf> apw: how far back? that is everything related to the loading
[12:26] <apw> cnf, i want to see the top mostly but you never know what clues are in there
[12:27] <cnf> (and there is no gcc on the systems failing to load)
[12:27] <apw> cnf, point, actually i want it from the one building it when it is building it really don't i
[12:27] <cnf> http://pastie.org/6316165
[12:29] <cnf> Linux version 3.2.0-29-generic (buildd@allspice) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012
[12:29] <cnf> let me rebuild the builder
[12:29] <cnf> (takes a few minutes)
[12:31] <cnf> and http://pastie.org/6316179 for gcc version
[12:31] <apw> cnf, get me a /proc/version and well as gcc -v off that one
[12:31] <cnf> it's not running the kernel i compile for
[12:32] <cnf> but Linux version 3.2.0-23-generic (buildd@crested) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu4) ) #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 on the builder
[12:32] <apw> cnf, does it have the headers for the one you are compiling for installed ?
[12:32] <cnf> (i install the right headers and image for the kernel i _do_ compile for, obviously)
[12:33] <apw> cnf, but then it would not be possible to load them on the builder
[12:33] <apw> cnf, and you say that _does_ work ?  which it shouldn't
[12:33] <cnf> sure, but i reboot to test that :P
[12:33] <cnf> the builder installes the linux-headers and linux-image of the target kernel specified
[12:33] <cnf> automatically
[12:33] <cnf> if i reboot to test (so it runs the right kernel)
[12:33] <cnf> then it does work
[12:34] <apw> builds against them, then you reboot it and load them
[12:34] <cnf> yep
[12:34] <cnf> so _building_ is done on another kernel, but after a reboot to the right kernel, it works
[12:34] <apw> ok can we do that next, reboot it, and get me /proc/version and the dmesg shen they do load
[12:34] <apw> when
[12:34] <cnf> yep
[12:35] <cnf> i do this, btw, so i can automate my package building, and just speficy what the target kernel is in my config
[12:35] <apw> yes that makes sense indeed
[12:35] <apw> and we build all our stuff in a similar way, in a chroot for the release
[12:35] <cnf> uhu
[12:35] <apw> with the wrong kernel running, so it should just work as it works for us
[12:35] <cnf> ok, package is build
[12:35] <cnf> let me reboot the vm
[12:36] <apw> but there must be something different between the two somewhere
[12:36] <cnf> yeah...
[12:36] <apw> can we keep this vm rebooted in the working and loads state
[12:36] <apw> and get the saame exact .ko copied to one you made fresh
[12:36] <cnf> sorry?
[12:36] <apw> and confirm 1) it doesn't load
[12:37] <apw> can we keep the builder VM in the testing state, so on the right kernel with the module proven loaded
[12:37] <apw> and at the saem time make a consumer VM and pull the .ko off the
[12:37] <apw> builder VM and hand put it on the other VM
[12:37] <apw> and see if that loads
[12:37] <apw> if it does, we know it is a 'copying' issue when making the .deb to carry it
[12:37] <cnf> sure
[12:37] <apw> if it does not we know it is somehow a differnece in the two VMs
[12:38] <cnf> though i did md5sum some of the modules
[12:38] <apw> and perhaps with both running we can find it
[12:38] <cnf> but i'll try it none the less
[12:38] <apw> sensible indeed
[12:38] <apw> as it seems impossible as stated of course
[12:38] <cnf> it's a bit of juggling though, because this is vagrant
[12:38] <apw> so it must be subtle
[12:38] <cnf> as soon as i reboot, my setup breaks
[12:38] <cnf> (no more vbox modules, so no more shared folders etc)
[12:40] <cnf> also, it's not just one .ko, it's a mess of modules ^^;
[12:40] <apw> cnf, well i mostly only care about the one which fails first :)
[12:41] <cnf> :P
[12:42] <cnf> setting up the 2nd vm
[12:42] <cnf> it's installing the right kernel now
[12:42] <apw> one thing i would like to know is that md5sum /boot/vmlinuz-`uname -r` sort of thing really matches on the working and not working ones
[12:42] <cnf> ok
[12:43] <apw> i am sure it will but ... never hurts to test the basicxs
[12:44] <cnf> i'm gonna take some snapshots, so i can revert a bit faster :P
[12:45] <apw> plan indeed
[12:45] <apw> VMs have their uses
[12:45] <cnf> indeed
[12:46] <cnf> ok, 2nd vm is up
[12:46] <cnf> so _not_ install the package, you said?
[12:50] <apw> well i am happy if you use the package, if we compare them md5sum with the ones you loaded successfully on the rebooted builder
[12:50] <cnf> ok
[12:50] <apw> i want to know they are bit for bit the same
[12:50] <apw> i would like to see lsmod on the builder against lsmod when it fails to load as well
[12:52] <cnf> ok
[12:52] <cnf> (faling at scp atm ^^;)
[12:52] <cnf> there we go ^^;
[12:54] <cnf> http://pastie.org/6316289 success
[12:56] <cnf> http://pastie.org/6316299 fail
[12:56] <cnf> apw: see those tbs6??? modules?
[12:56] <cnf> those are part of my package...
[12:56] <apw> WARNING: Error inserting rc_core (/lib/modules/3.2.0-29-generic/kernel/drivers/media/rc/rc-core.ko): Invalid argument
[12:56] <apw> but that one not ?
[12:57] <cnf> no, i don't think it is part of my package
[12:57] <apw> and they are auto loading on the test system?  or do you have the modprobe command
[12:57] <cnf> nope, it isn't
[12:57] <cnf> autoload
[12:57] <cnf> sorry
[12:57] <cnf> sec
[12:58] <cnf> modprobe saa716x_tbs_dvb
[12:58] <cnf> is what i run
[12:58] <cnf> on either system
[12:58] <apw> and got no output when it worked ?
[12:58] <cnf> apw: exactly
[12:58] <apw> ok note rc_core is loaded on the working system
[12:58] <apw> so modprove rc_core on the broken one
[12:59] <apw> modprobe even ...
[12:59] <apw> what does that say, and does it say anything in dmesg for it
[12:59] <cnf> # modprobe rc_core
[12:59] <cnf> root@precise64:~# lsmod |grep rc_core
[12:59] <cnf> rc_core                26412  7 ir_lirc_codec,ir_mce_kbd_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder
[13:00] <apw> now try probing your module 
[13:00] <cnf> on the broken system
[13:00] <cnf> WARNING: Error inserting rc_core (/lib/modules/3.2.0-29-generic/kernel/drivers/media/rc/rc-core.ko): Invalid argument
[13:00] <cnf> (and the same following lines)
[13:00] <apw> ?
[13:01] <cnf> http://pastie.org/6316322
[13:01] <apw> lsmod | grep rc_core works on the broken system
[13:01] <cnf> yes
[13:01] <apw> but modprobe of your module still triggers an error loading it ?
[13:01] <cnf> yes
[13:01] <apw> i find that hard to believe
[13:01] <apw> and it wasn't probed in the lsmod you pasted originally
[13:02] <apw> can i have a new lsmod off it
[13:02] <apw> somethign really screwey is going on, or we are not understanding each other
[13:02] <cnf> http://pastie.org/6316329
[13:02] <cnf> yeah
[13:03] <cnf> hmm
[13:03] <cnf> ok, rc-core has a different md5sum on both system
[13:03] <cnf> o,O
[13:03] <apw> cnf, !?!
[13:04] <apw> well that would cirtainly not be right
[13:04] <cnf> indeed
[13:04] <cnf> damned screwey 3rd party software :/
[13:04] <apw> was it wrong before you installed your package
[13:04] <apw> yeah you have to hate it
[13:05] <cnf> apw: it's part of the default system
[13:05] <cnf> so i didn't touch it with my package
[13:05] <apw> so which one is wrong
[13:05] <cnf> but aparently, this driver package recompiles rc-core.ko
[13:06] <cnf> and i guess depends on the changed version?
[13:06] <apw> ouch
[13:06] <apw> so you need to bring that too i assume
[13:06] <apw> vile vile vile vile
[13:06] <cnf> hmm, i guess
[13:06] <apw> well easy to test, scp it over
[13:06] <apw> rmmod it, and try again
[13:06] <cnf> but _can_ i even overwrite existing files managed by a different package?
[13:06] <apw> then send hatemail to someone :)
[13:07] <cnf> with a .deb?
[13:07] <apw> cnf, with difficulty
[13:07] <apw> cnf, though in this case you can put it in /lib/modules/<version>/update/<path> as well
[13:07] <apw> and that takes precident over the 'real' one
[13:07] <cnf> aha?
[13:07] <cnf> oh, shiny!
[13:07] <cnf> ok, lets start the scping
[13:07] <apw> or is it updates, anyhow it should exist whatever it is called
[13:08] <apw> that is where dkms makes its mess as well
[13:08] <cnf> hehe
[13:10] <ppisati> apw: do you have native ipv6 or you use a tunnel?
[13:10] <cnf> apw: thank you for your help so far
[13:10] <apw> ppisati, an HE tunnel, the uk isn't very advanced in ipv6 land
[13:10] <cnf> apw: i'm gonna give my brain a small break, and hack on this a bit
[13:10] <ppisati> apw: ok
[13:10] <cnf> apw: i'll probably be back in a bit :P but you have been a great help so far!
[13:12] <cnf> apw: oh, should the path under updates mirror the path under kernel?
[13:12] <apw> cnf, i think it doesn't matter as it is found by depmod
[13:12] <cnf> aha, ok
[13:12] <apw> cnf, but i would probabally make it so
[13:14] <cnf> right :P
[13:21] <cnf> hmz
[13:21] <cnf> apw: ok, same error
[13:22] <apw> did you rmmod rc-core
[13:22] <apw> and modprobe it again ?
[13:22] <apw> and did you run depmod? to pick up the new one
[13:22] <cnf> i did a rollback
[13:22] <cnf> and ERROR: Module rc_core does not exist in /proc/modules
[13:22] <cnf> on an rmmod
[13:24] <cnf> and yeah, my package runs depmod -a on install
[13:31] <cnf> i think you got it right when you used the word "vile" :P
[13:32] <cnf> hmm
[13:32] <cnf> apw: the _new_ rc-core module loads on the new system, but gives similar "disagrees about version of symbol" messages in dmesg
[13:33] <cnf> so i am going to go out on a limb, and say they did the same thing to a bunch of other modules...
[13:33] <apw> bah
[13:33] <cnf> yeah :/
[13:34] <apw> md5sum is your friend
[13:34] <cnf> so i guess i'll be writing a script that does a find and a md5sum on everything
[13:34] <cnf> and compares before and aftyer
[14:01]  * cnf facepalms
[14:01] <cnf> apw: they are actually recompiling the rc-*.ko drivers for _other_ cards as well
[14:07] <apw> cnf, i think you should send that s/w back with a brick attached
[14:08] <cnf> apw: considering it
[14:08] <cnf> apw: and herpes
[14:08] <apw> a good combination
[14:08] <cnf> isn't it :P
[14:10] <cnf> apw: normally if one where to write kernel modules
[14:10] <cnf> how would you make it easy for packagers?
[14:10] <cnf> something like --prefix or $DESTDIR, no?
[14:10] <apw> not changing existing ones, using the prefixes we have for updates, or make new names
[14:11] <apw> really they should make new names
[14:11] <cnf> uhu
[14:11] <apw> as they are recompiling all of rc-* becaure they are renaming rc-core
[14:11] <apw> cause they are rebuilding rc-core
[14:11] <apw> they should be making a copy and calling it my-rc-core to avoid all this
[14:12] <cnf> indeed :/
[14:12] <cnf> i did a `find . -exec md5sum {} \; > file` pre and post
[14:13] <cnf> the nr "recompiled" modules is appalling!
[14:13] <cnf> totally unrelated modules have different sums
[14:13] <apw> probabally dependancies of those other ones
[14:13] <apw> or ones which use them
[14:13] <cnf> yeah, indeed
[14:13] <apw> which is doubly why one should not do this
[14:14] <cnf> yeah!
[14:14] <apw> or one should just apply the patches to our source and build your own kernel
[14:14] <cnf> i'm not a C coder (doing learn C the hard way atm :P ) but _i_ know this, damnit >,<
[14:14] <apw> as you are not runnign our kernel, and nothing about your kernel should call itself the version we shipped
[14:14] <apw> that is just confusing ... 
[14:14] <apw> hello choir
[14:15] <cnf> yeah :P
[15:06] <ppisati> brb
[15:11] <cnf> i'm going home, thanks again apw !
[15:11] <cnf> \o
[15:24] <apw> BenC, yo .. do you have a v3.8 rebase in the works.  i am working on the configuration updates for master, and want to do teh same for ppc, but you are 'behind'
[15:25] <BenC> apw: I'll push out a rebase real quick and pull your changes before uploading
[15:25] <apw> cool
[15:26] <BenC> apw: should I rebase against master or master-next?
[15:27] <apw> i would rebase whever you normally do i guess, master, as the changes are outside the tree for ppc
[15:27] <apw> BenC, it may make sense to rebase and upload a v3.8 rebase to match master
[15:27] <BenC> apw: normally I rebase against the latest tag
[15:27] <apw> then we isolate any breakage from v3.8 against any breakage from teh config changes
[15:28] <apw> our config changes are separate to the v3.8 final rebase as well
[15:29] <apw> i can then do the config changes against your tag and it will be all nice and claen
[15:29] <apw> BenC, ^
[15:32] <BenC> apw: my ppc branch is pushed and synced to ubuntu/master
[15:32] <apw> sweet
[15:33] <BenC> apw: Thanks
[15:36]  * ogasawara back in 20
[15:44] <apw> ogasawara, just pushed the result of the full by-menu config-review for v3.8 final
[15:44] <apw> (it even builds)
[16:02] <ppisati> apw: is your panda alive? if i provide you with a kernel in ~20mins can you give it a spin?
[16:03] <apw> ppisati, if this board is a panda, i think it is alive
[16:06] <ppisati> apw: got a patch from rmk about the align/ipv6 problem we had, and i can't reproduce the BUG() here
[16:06] <ppisati> apw: i mean, after i applied the patch i can't reproduce it anymore
[16:06] <ppisati> apw: sounds like it fixes it
[16:06] <apw> ppisati, sweet, it seemed to kill my machine in the face on a regular basis
[16:06] <apw> so i should know just by leaving it on
[16:06] <ppisati> apw: right
[16:06]  * ppisati is building a test kernel
[16:07] <apw> great
[16:19] <ppisati> apw: check it out - http://people.canonical.com/~ppisati/linux-image-3.8.0-7-omap_3.8.0-7.15~ipv6align_armhf.deb
[16:20] <apw> ppisati, ack
[16:28] <smoser> smb, apw thank you for your console/ttyS0 help.
[16:29] <sforshee> ogasawara, rtg, apw: there's a message on ubuntu-devel about proprietary drivers failing to install due to not having the kernel headers, and I've been working a bug that looks to be the same issue. Shouldn't dkms have a dependency on linux-headers-generic?
[16:29] <sforshee> (note that it doesn't, at least not in raring)
[16:29] <apw> sforshee, nope, because you should have linux-foo installed which gives you the right ones
[16:30] <apw> sforshee, and depending on one just means you have the wrong ones for your kernel force installed when you install dkms and things still don't work
[16:31] <smb> smoser, welcome. lets see whether we can find a working way
[16:31] <infinity> sforshee: Are these 12.10 users?
[16:31] <sforshee> infinity, yes for the ones I'm aware of
[16:31] <apw> sforshee, ie you are using linux-image-generic-pae but have no headers, you install dkms, that has a dep of 'linnux-headers-generic | linux-headers-generic-pae' that installs the first one, which is useless and you don't get anywhere
[16:32] <apw> sforshee, upgrades or fresh installs
[16:32] <infinity> sforshee: 12.10 has a bug where the installer removes the headers (and the metapackage) at the end of the install.
[16:32] <apw> heh that would do it
[16:33] <sforshee> infinity, ah. Yes, the bug I'm looking at seems to be a fresh install
[16:33] <infinity> sforshee: Other than doing a point release of 12.10, I'm not sure how best to resolve that.  And that still won't get old installs the metapackage back.
[16:33] <infinity> sforshee: tseliot was working on a fix to jockey/drivers-common that would try to ensure the right metapackages were installed.  Not sure if that's made it in.
[16:33] <sforshee> infinity, makes sense
[16:34] <sforshee> apw, thanks for the explanation, I wasn't thinking about pae being a separate metapackage
[16:34] <infinity> tseliot: ^
[16:35] <infinity> sforshee: Well, not just -pae, but the ARM variants, etc.
[16:35] <sforshee> right
[16:36] <apw> it is the inability of the dkms dependancies to make a sensible decision that is the real issue
[16:36] <tseliot> infinity: that would be bug #1123107 and my packages are waiting for approval
[16:36] <ubot2`> Launchpad bug 1123107 in jockey (Ubuntu) "Jockey should install the linux-$flavour metapackage" [High,Fix committed] https://launchpad.net/bugs/1123107
[16:36] <infinity> tseliot: I don't see any Q tasks for that.
[16:36] <infinity> tseliot: Which is where most of the affected users are.
[16:39] <tseliot> infinity: if that's desirable, I can backport it from raring to quantal. I think precise has the highest priority though
[16:40] <infinity> tseliot: Sure, precise is more important for a variety of reasons, it's just that Q had the unfortunate installer bug that means many/most amd64 users don't have any headers installed by default (oops).
[16:41] <tseliot> infinity: oh, I wasn't aware of this
[16:42] <infinity> tseliot: Was a slightly overzealously greedy glob when removing linux-signed (for non-SB systems), if I recall, that led to a few more packages than intended being removed at the end of the install. :/
[16:42] <tseliot> ouch
[16:43] <infinity> Or something along those lines.  I forget the exact bug now, just the symptom.
[16:46] <apw> BenC, i have just pushed a startnewrelease pile onto that ppc branch for you, if i push the config changes are you able to reset them off if they don't work for you?
[16:46] <BenC> apw: yes
[16:46] <BenC> apw: when will ubuntu/master be uploaded?
[16:46] <apw> then that sounds like a plan, it'll be there shortly
[16:47] <apw> BenC, actuall the v3.8 final -7 has already been pushed, perhaps we should upload that as is
[16:47] <BenC> apw: is master still the same as the -7 tag?
[16:47] <infinity> Eh, why waste build resources, if there's another one in the pipe?
[16:47] <apw> BenC, and then i'll do the confi changes relative to it separatly, to keep the two changes easy to test
[16:47] <BenC> Right
[16:48] <apw> diagnosability agasist build resources indeed
[16:48] <apw> BenC, so whats uploaded was the clean rebase, ie -7, i'll see about getting this config update uploaded soon i think
[16:48] <BenC> Ok, I'll hold out for that upload
[16:49] <apw> ogasawara, what do you think about me uploading this config change today
[16:49] <BenC> Nothing in the rebase or config is critical to ppc right now, other than making it match ubuntu/master
[16:49] <ogasawara> apw: works for me
[16:49] <apw> BenC, reasonable
[17:25]  * ppisati goes for some sweating
[17:25] <ppisati> later
[17:49]  * apw idly wonders if pp understands just how that sounds ...
[17:50] <ogra_> heh
[17:50] <ogra_> i was wondering the same a few days ago 
[18:18] <infinity> apw: Who doesn't enjoy some good sweating?
[18:18] <neoshades> Hi Just joined to ask a question - What complier is used to create mainline kernel 3.7.9-raring?
[18:18] <infinity> neoshades: If you're running the kernel, /proc/version will tell you which compiler was used.
[18:19] <apw> neoshades, we may record that too
[18:21] <neoshades> I tried but could not get gnome to run as nvidia drivers 3.10.32 to create dkms module as it complained about the compiler version 
[18:24]  * infinity wonders idly why the GCC version string has a trailing space...
[18:25] <neoshades> I am running 3.7.5-030705-generic at moment and have managed to install 3.10.32 nvidia - /proc/version shows it was compiled with gcc 4.6.3 but installed vrsion is gcc (Ubuntu/Linaro 4.7.2-2ubuntu1 
[18:26] <neoshades> damm yo many chars
[18:27] <neoshades> am running 3.7.5-030705-generic with nvidia 3.10.32 ok
[18:28] <neoshades> 3.7.9 won't compile with nvidia 3.10.32 for dkms
[18:28] <infinity> So, you might need to either install gcc-4.6 and export CC=gcc-4.6, or convince your binary driver build that compiler versions don't matter.
[18:29] <apw> neoshades, pretty much that is very likely
[18:29] <apw> neoshades, what release are you running it on?
[18:29] <neoshades> why is mainline using gcc 4.6.3 instead of 4.7.2?
[18:30] <apw> so that was built pre the change to 4.7
[18:30] <apw> neoshades, it is using the default compiler when it was built
[18:30] <apw> they are meant for testing only and we don't expect binary driver to work with them
[18:30] <apw> that is the way of the world
[18:30] <infinity> apw: From his GCC version, I assume he's running quantal.
[18:31] <neoshades> yes quantal originally
[18:31] <neoshades> mainline build downloaded from site http://kernel.ubuntu.com/~kernel-ppa/mainline/
[18:32] <apw> yes those are the ones, they are pretty much guarenteed to not work with binary drivers cause of the compiler skew
[18:32] <neoshades> compiler skew?
[18:33] <apw> the compiler on teh system not matching that they are built with
[18:33] <infinity> The thing you were just complaining about...
[18:33] <apw> as they are not built with the compiler for your system, but the one for precise
[18:33] <apw> to allow maximal use of the kernel across versions to allow baseline testing
[18:34] <infinity> neoshades: Is there a reason you need to be running mainline kernels?
[18:34] <neoshades> that's what I thought but I suppose I assumed that mainline builds would be using latest gcc
[18:34] <infinity> neoshades: The packaged kernels in the archive are, generally, a much better idea for most people.
[18:34] <neoshades> no reason apart from testing
[18:36] <apw> neoshades, well if they were they would be using raring's compiler, which would skew from your locla compiler anyhow
[18:36] <apw> same problem
[18:37] <neoshades> erm so what is raring comipler version?
[18:37] <sforshee> apw, you have a machine with BCM4313 wireless don't you?
[18:38] <apw> sforshee, it has brcm something yes
[18:38] <infinity> raring's compiler is 4.7.2, shouldn't cause too many issues with quantal.
[18:38] <infinity> (And, in fact, a raring kernel package installed on Q should behave just fine)
[18:38] <apw> 02:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)
[18:38] <sforshee> apw, someone is complaining about brcmsmac with BCM4313 so if you had that hardware I wondered how well it's working for you
[18:38] <apw> sforshee, ^^
[18:39] <apw> sforshee, its the normal pile of shit all brcm drivers are, expect to rmmod modprobe it at least daily
[18:39] <apw> its been much better since your last fixes, but not perfect
[18:39] <sforshee> huh, okay
[18:39] <apw> but given it is brcm, its purfect
[18:39] <apw> and given i run full ipv6, and i have to nail network-manager and nm-applet about as often
[18:39] <sforshee> I rarely have problems with by BCM43224 in 3.8
[18:40] <apw> i cannot be sure it is completly brcms fault
[18:40] <apw> can you tell i am bitter about it
[18:40] <apw> broadcom please sort out your drivers
[18:40] <neoshades> but as ubuntu now install 3.7.2 on quantal why are mainline not built with such - no worries will compile my own from git
[18:40] <apw> and no shipping random source on your website does not fit the definition of 'sort out'
[18:41] <apw> neoshades, it is built in a precise environment to let us use them on the LTS and later
[18:41] <sforshee> I think broadcom generally cares more about the fullmac drivers because that's what android devices use ...
[18:41] <apw> the only downside is that binary drivers do not work, and frankly we don't care about them
[18:41] <apw> sforshee, and therefore they should not make devices for anything else
[18:41] <apw> sforshee, or they shoudl sort out something useful
[18:42] <apw> either or, don't care
[18:42] <apw> just don't make me live with their lazyness
[18:42] <sforshee> maybe I need to try and get my hands on a BCM4313 card
[18:42] <apw> i should try swapping my pcix card in this machine with something from intel
[18:42] <apw> and give you the thing
[18:43] <sforshee> I can get one of amazon for about $12
[18:43] <sforshee> might cost you more to ship it to me ;-)
[18:43] <apw> sforshee, expense it
[18:44]  * henrix -> EOD
[18:50] <neoshades> so what u are saying is that as gcc is updated the kernels in the archive are compiled with latest gcc
[18:50] <neoshades> as per LTS
[18:57] <apw> a mainline kernel is built with the nearest configuration series wise, and in the previous LTS chroot wise
[18:57] <apw> to maximise what it can be installed safely on
[18:59] <apw> (given it is a completly automated build and no brains are applied in their making)
[18:59] <apw> neoshades, ^^
[19:01] <infinity> neoshades: The mainline kernels are meant for nothing more than quick testing of "if this is broken in the distro kernel, does it work with mainline?", they're not meant for people to run.
[19:35] <apw> BenC, i ahve pushed the config change and abi bump to the branch, it builds for me in a cross environment but a proper build test on something ppc would be good