[00:05] zequence: You got the bug closure syntax wrong in your lowlatency upload to precise, BTW. [00:06] zequence: Needs to be "LP: #1234" not "LP:#1234" [00:06] 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] zequence: (Closing the bug manually this time) [00:07] smb`: And you just completely missed having the right tracking bug in the linux-ec2 upload. :) [00:09] hi, what was the reason to switch CONFIG_SATA_AHCI=y to CONFIG_SATA_AHCI=m? [00:09] with =m the kernel alone of course does not boot with efibootmgr, initrd is required which is slower [00:11] switched from 3.8 rc6 to rc7 [00:13] Kano: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1056563 [00:13] Ubuntu bug 1056563 in linux (Ubuntu) "Please change AHCI driver back to module in 12.10" [Medium,Fix released] [00:13] Kano: In short, it can conflict with other modules, so builtin is the wrong answer for a generic kernel. [00:14] why is that raid ahci not mainline [00:15] that would be the correct answer [00:16] http://kanotix.com/files/dragonfire/linux-3.8.0-6.13kanotix1/0001-Bluetooth-Add-support-for-AR3012-0489-e04e.patch [00:16] that should be added as well. if you want signed it and push to mainine [00:16] did you add that to your kernel? [00:16] 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] without you can not boot 3.8 with ivtv or cx18 card installed [00:17] Kano: There's a mailing list for your patches. [00:18] i hate mailinglists, btw. the 2nd is from one [00:18] it is not my patch only the first [00:18] s/patches/pull requests/ [00:18] http://patchwork.linuxtv.org/patch/16734/ [00:19] that patch is critical [00:21] so you see, it was on the list and was not added [00:21] "i hate the thing everyone uses to do this, but i insist on doing this" [00:22] Kano: Fine. Can you mail a pull request to kernel-team@? Thanks. [00:22] well you can tell your users to use kanotix instead too, there it is fixed ;) [00:23] bye [00:23] somehow that's a reasonable thing to do, but not for the reason he stated :d === rsalveti is now known as rsalveti|afk [06:41] infinity: Sorry, and thanks [07:51] moin === smb` is now known as smb [08:28] infinity, meh.... :-P [08:28] morning [08:35] smb: moin [09:08] moin [09:08] infinity, bah i missed that too [09:08] * apw self flagilates, and it is far too early for such things [09:15] apw, isn't it also too early to start punching oneself [09:18] i am not very accurate at this time of day for sure === henrix_ is now known as henrix [09:32] ppisati, there was some resaon we had CONFIG_CPU_FREQ turned off for omap wasn't there [09:33] apw: yes, upstream is missing some pieces for omap4 [09:33] ppisati, sweet [09:33] apw: if we turn if on, it crashses on boot [09:33] ppisati, now that is a good reason indeed [09:34] apw: there should be a link to the upstream discussion about it in the config change that i sent [09:36] 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] apw: ack [09:45] ppisati, CONFIG_IMX_SDMA and CONFIG_IMX_DMA are off for -omap, are they not useful for imx ? [09:46] apw: probably not fr the board that we support, but letme check [09:46] ppisati, thanks [09:47] * ppisati is eating strawberries.. and he loves it... :) [09:47] Any idea why why tigon and bnx2x were removed from linux-firmware in 1.88 ? [09:48] aissen, have you checked the changelog ? [09:49] aissen, and in which release are you talking abuot ? [09:50] I checked the changelog, it says: "Remove boot essential duplicated firmware files that are also carried in the linux-image package." [09:50] the release is quantal but it carried over raring. [09:51] aissen, ahh there you go, so we think it is in linux [09:51] Is it to save some space then ? [09:52] aissen, yeah there is no point in having two copies on the system for sure [09:52] now if we have ended up with zero copies that is broken [09:53] 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] aissen, i suspect so indeed [09:55] that's what I thought but I wanted input from someone who knew the rationale. [09:55] 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] yeah, first thing I noticed is that rtg wasn't here. I'll wait till he comes back === Nafallo_ is now known as Nafallo [10:16] 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) === yofel_ is now known as yofel [10:17] apw: actually support for those boards is all upstream, so if anyone has the hw we could easily add support for it [10:21] ppisati, but for now off makes sense ? [10:21] apw: yep [10:42] 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] (thats bug 1077704 ) [10:42] Launchpad bug 1077704 in ubuntu-nexus7 "Can't connect to ad-hoc wifi networks" [Medium,Confirmed] https://launchpad.net/bugs/1077704 [11:28] ppisati, CONFIG_HWSPINLOCK_OMAP is off in -omap, is that deliberate [11:32] ppisati, CONFIG_KEYBOARD_IMX is off in -omap ... what about that one [11:33] apw: HWSPINLOCK_OMAP seems omap4-only, i'll have to check it [11:33] apw: KEYBOARD_IMX can be compiled as a module [11:34] 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] ppisati, K_IMX ack [11:36] apw: i'll give the first option a try [11:36] ppisati, CONFIG_MTD_NAND_MXC on -omap ? [11:38] ONFIG_MMC_MXC too [11:38] apw: /me checking [11:39] apw: MMC_MXC is !imx6 (our board) [11:39] ppisati, ack will leave it be then [11:41] apw: apw same for MTD_NAND_MXC (is for the imx31) [11:41] ppisati, ack ta [11:48] ppisati, CONFIG_PWM_IMX ? [11:49] apw: =m? [11:50] ppisati, will do [12:06] 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] i'm compiling against the same ubuntu stock kernel (3.2.0-29-generic) [12:06] cnf, if you are able to distribute the source, then you might want to be using dkms [12:06] apw: i don't want compilers on all the servers [12:07] cnf, well as we build LBM that exact same way it should work as far as i know [12:07] cnf, what happens when you try to load them [12:07] eb 22 11:46:38 62-213-199-42 kernel: [ 2652.522284] saa716x_core: disagrees about version of symbol dvb_frontend_detach [12:07] Feb 22 11:46:38 62-213-199-42 kernel: [ 2652.522288] saa716x_core: Unknown symbol dvb_frontend_detach (err -22) [12:07] times a lot :P [12:08] 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] cnf, and you are sure you used the right .config [12:09] apw: i'm building in a vm, if i delete de vm right after compilation, and reinstall the same kernel [12:09] it fails [12:09] if i load them right after i compiled them, it works [12:10] both with linux-image-3.2.0-29-generic [12:10] maybe i'm doing something wrong, or missing something, but i can not figure out what [12:11] apw: and the .config in the kernel source tree is identical to the one in /boot/ for the running kernel [12:11] cnf, and if you reboot the original VM and try installing them again does that work [12:11] as that should be equivalent to your delete and recreate VM [12:11] in theory as the bits should be the same [12:12] apw: yeah, i can reboot the vm, and reinstall the .deb [12:12] works fine [12:12] wipe the vm, bring it up again (vagrant), install kernel image and my package [12:12] no go [12:13] i'm sure i'm doing something stupid, but what :/ [12:13] cnf, i struggle to see how that could not work, as otherwise we could not ship lbm [12:13] cnf, what release [12:13] apw: of? [12:13] ubuntu [12:14] oh, [12:14] Ubuntu 12.04 LTS [12:14] (target is 12.04.1, but i'm ignoring that one for now) [12:15] cnf, can i have a full dmesg from a failure please [12:15] sure, hold on [12:15] http://pastie.org/6316122 [12:18] apw: i could even share the vagrant project, if you have ny use for it [12:24] cnf, can i get the whole dmesg from the top pls [12:25] cnf, and a cat /proc/version and a gcc -v from the system failing to load them [12:26] apw: how far back? that is everything related to the loading [12:26] cnf, i want to see the top mostly but you never know what clues are in there [12:27] (and there is no gcc on the systems failing to load) [12:27] cnf, point, actually i want it from the one building it when it is building it really don't i [12:27] http://pastie.org/6316165 [12:29] 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] let me rebuild the builder [12:29] (takes a few minutes) [12:31] and http://pastie.org/6316179 for gcc version [12:31] cnf, get me a /proc/version and well as gcc -v off that one [12:31] it's not running the kernel i compile for [12:32] 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] cnf, does it have the headers for the one you are compiling for installed ? [12:32] (i install the right headers and image for the kernel i _do_ compile for, obviously) [12:33] cnf, but then it would not be possible to load them on the builder [12:33] cnf, and you say that _does_ work ? which it shouldn't [12:33] sure, but i reboot to test that :P [12:33] the builder installes the linux-headers and linux-image of the target kernel specified [12:33] automatically [12:33] if i reboot to test (so it runs the right kernel) [12:33] then it does work [12:34] builds against them, then you reboot it and load them [12:34] yep [12:34] so _building_ is done on another kernel, but after a reboot to the right kernel, it works [12:34] ok can we do that next, reboot it, and get me /proc/version and the dmesg shen they do load [12:34] when [12:34] yep [12:35] i do this, btw, so i can automate my package building, and just speficy what the target kernel is in my config [12:35] yes that makes sense indeed [12:35] and we build all our stuff in a similar way, in a chroot for the release [12:35] uhu [12:35] with the wrong kernel running, so it should just work as it works for us [12:35] ok, package is build [12:35] let me reboot the vm [12:36] but there must be something different between the two somewhere [12:36] yeah... [12:36] can we keep this vm rebooted in the working and loads state [12:36] and get the saame exact .ko copied to one you made fresh [12:36] sorry? [12:36] and confirm 1) it doesn't load [12:37] can we keep the builder VM in the testing state, so on the right kernel with the module proven loaded [12:37] and at the saem time make a consumer VM and pull the .ko off the [12:37] builder VM and hand put it on the other VM [12:37] and see if that loads [12:37] if it does, we know it is a 'copying' issue when making the .deb to carry it [12:37] sure [12:37] if it does not we know it is somehow a differnece in the two VMs [12:38] though i did md5sum some of the modules [12:38] and perhaps with both running we can find it [12:38] but i'll try it none the less [12:38] sensible indeed [12:38] as it seems impossible as stated of course [12:38] it's a bit of juggling though, because this is vagrant [12:38] so it must be subtle [12:38] as soon as i reboot, my setup breaks [12:38] (no more vbox modules, so no more shared folders etc) [12:40] also, it's not just one .ko, it's a mess of modules ^^; [12:40] cnf, well i mostly only care about the one which fails first :) [12:41] :P [12:42] setting up the 2nd vm [12:42] it's installing the right kernel now [12:42] 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] ok [12:43] i am sure it will but ... never hurts to test the basicxs [12:44] i'm gonna take some snapshots, so i can revert a bit faster :P [12:45] plan indeed [12:45] VMs have their uses [12:45] indeed [12:46] ok, 2nd vm is up [12:46] so _not_ install the package, you said? [12:50] 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] ok [12:50] i want to know they are bit for bit the same [12:50] i would like to see lsmod on the builder against lsmod when it fails to load as well [12:52] ok [12:52] (faling at scp atm ^^;) [12:52] there we go ^^; [12:54] http://pastie.org/6316289 success [12:56] http://pastie.org/6316299 fail [12:56] apw: see those tbs6??? modules? [12:56] those are part of my package... [12:56] WARNING: Error inserting rc_core (/lib/modules/3.2.0-29-generic/kernel/drivers/media/rc/rc-core.ko): Invalid argument [12:56] but that one not ? [12:57] no, i don't think it is part of my package [12:57] and they are auto loading on the test system? or do you have the modprobe command [12:57] nope, it isn't [12:57] autoload [12:57] sorry [12:57] sec [12:58] modprobe saa716x_tbs_dvb [12:58] is what i run [12:58] on either system [12:58] and got no output when it worked ? [12:58] apw: exactly [12:58] ok note rc_core is loaded on the working system [12:58] so modprove rc_core on the broken one [12:59] modprobe even ... [12:59] what does that say, and does it say anything in dmesg for it [12:59] # modprobe rc_core [12:59] root@precise64:~# lsmod |grep rc_core [12:59] 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] now try probing your module [13:00] on the broken system [13:00] WARNING: Error inserting rc_core (/lib/modules/3.2.0-29-generic/kernel/drivers/media/rc/rc-core.ko): Invalid argument [13:00] (and the same following lines) [13:00] ? [13:01] http://pastie.org/6316322 [13:01] lsmod | grep rc_core works on the broken system [13:01] yes [13:01] but modprobe of your module still triggers an error loading it ? [13:01] yes [13:01] i find that hard to believe [13:01] and it wasn't probed in the lsmod you pasted originally [13:02] can i have a new lsmod off it [13:02] somethign really screwey is going on, or we are not understanding each other [13:02] http://pastie.org/6316329 [13:02] yeah [13:03] hmm [13:03] ok, rc-core has a different md5sum on both system [13:03] o,O [13:03] cnf, !?! [13:04] well that would cirtainly not be right [13:04] indeed [13:04] damned screwey 3rd party software :/ [13:04] was it wrong before you installed your package [13:04] yeah you have to hate it [13:05] apw: it's part of the default system [13:05] so i didn't touch it with my package [13:05] so which one is wrong [13:05] but aparently, this driver package recompiles rc-core.ko [13:06] and i guess depends on the changed version? [13:06] ouch [13:06] so you need to bring that too i assume [13:06] vile vile vile vile [13:06] hmm, i guess [13:06] well easy to test, scp it over [13:06] rmmod it, and try again [13:06] but _can_ i even overwrite existing files managed by a different package? [13:06] then send hatemail to someone :) [13:07] with a .deb? [13:07] cnf, with difficulty [13:07] cnf, though in this case you can put it in /lib/modules//update/ as well [13:07] and that takes precident over the 'real' one [13:07] aha? [13:07] oh, shiny! [13:07] ok, lets start the scping [13:07] or is it updates, anyhow it should exist whatever it is called [13:08] that is where dkms makes its mess as well [13:08] hehe [13:10] apw: do you have native ipv6 or you use a tunnel? [13:10] apw: thank you for your help so far [13:10] ppisati, an HE tunnel, the uk isn't very advanced in ipv6 land [13:10] apw: i'm gonna give my brain a small break, and hack on this a bit [13:10] apw: ok [13:10] apw: i'll probably be back in a bit :P but you have been a great help so far! [13:12] apw: oh, should the path under updates mirror the path under kernel? [13:12] cnf, i think it doesn't matter as it is found by depmod [13:12] aha, ok [13:12] cnf, but i would probabally make it so [13:14] right :P [13:21] hmz [13:21] apw: ok, same error [13:22] did you rmmod rc-core [13:22] and modprobe it again ? [13:22] and did you run depmod? to pick up the new one [13:22] i did a rollback [13:22] and ERROR: Module rc_core does not exist in /proc/modules [13:22] on an rmmod [13:24] and yeah, my package runs depmod -a on install [13:31] i think you got it right when you used the word "vile" :P [13:32] hmm [13:32] apw: the _new_ rc-core module loads on the new system, but gives similar "disagrees about version of symbol" messages in dmesg [13:33] 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] bah [13:33] yeah :/ [13:34] md5sum is your friend [13:34] so i guess i'll be writing a script that does a find and a md5sum on everything [13:34] and compares before and aftyer === yofel_ is now known as yofel === rsalveti|afk is now known as rsalveti [14:01] * cnf facepalms [14:01] apw: they are actually recompiling the rc-*.ko drivers for _other_ cards as well [14:07] cnf, i think you should send that s/w back with a brick attached [14:08] apw: considering it [14:08] apw: and herpes [14:08] a good combination [14:08] isn't it :P [14:10] apw: normally if one where to write kernel modules [14:10] how would you make it easy for packagers? [14:10] something like --prefix or $DESTDIR, no? [14:10] not changing existing ones, using the prefixes we have for updates, or make new names [14:11] really they should make new names [14:11] uhu [14:11] as they are recompiling all of rc-* becaure they are renaming rc-core [14:11] cause they are rebuilding rc-core [14:11] they should be making a copy and calling it my-rc-core to avoid all this [14:12] indeed :/ [14:12] i did a `find . -exec md5sum {} \; > file` pre and post [14:13] the nr "recompiled" modules is appalling! [14:13] totally unrelated modules have different sums [14:13] probabally dependancies of those other ones [14:13] or ones which use them [14:13] yeah, indeed [14:13] which is doubly why one should not do this [14:14] yeah! [14:14] or one should just apply the patches to our source and build your own kernel [14:14] i'm not a C coder (doing learn C the hard way atm :P ) but _i_ know this, damnit >,< [14:14] as you are not runnign our kernel, and nothing about your kernel should call itself the version we shipped [14:14] that is just confusing ... [14:14] hello choir [14:15] yeah :P === kentb-out is now known as kentb === cheako911 is now known as cheako [15:06] brb === rsalveti_ is now known as rsalveti [15:11] i'm going home, thanks again apw ! [15:11] \o [15:24] 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] apw: I'll push out a rebase real quick and pull your changes before uploading [15:25] cool [15:26] apw: should I rebase against master or master-next? [15:27] i would rebase whever you normally do i guess, master, as the changes are outside the tree for ppc [15:27] BenC, it may make sense to rebase and upload a v3.8 rebase to match master [15:27] apw: normally I rebase against the latest tag [15:27] then we isolate any breakage from v3.8 against any breakage from teh config changes [15:28] our config changes are separate to the v3.8 final rebase as well [15:29] i can then do the config changes against your tag and it will be all nice and claen [15:29] BenC, ^ [15:32] apw: my ppc branch is pushed and synced to ubuntu/master [15:32] sweet [15:33] apw: Thanks [15:36] * ogasawara back in 20 [15:44] ogasawara, just pushed the result of the full by-menu config-review for v3.8 final [15:44] (it even builds) [16:02] apw: is your panda alive? if i provide you with a kernel in ~20mins can you give it a spin? [16:03] ppisati, if this board is a panda, i think it is alive [16:06] apw: got a patch from rmk about the align/ipv6 problem we had, and i can't reproduce the BUG() here [16:06] apw: i mean, after i applied the patch i can't reproduce it anymore [16:06] apw: sounds like it fixes it [16:06] ppisati, sweet, it seemed to kill my machine in the face on a regular basis [16:06] so i should know just by leaving it on [16:06] apw: right [16:06] * ppisati is building a test kernel [16:07] great [16:19] 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] ppisati, ack [16:28] smb, apw thank you for your console/ttyS0 help. [16:29] 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] (note that it doesn't, at least not in raring) [16:29] sforshee, nope, because you should have linux-foo installed which gives you the right ones [16:30] 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] smoser, welcome. lets see whether we can find a working way [16:31] sforshee: Are these 12.10 users? [16:31] infinity, yes for the ones I'm aware of [16:31] 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] sforshee, upgrades or fresh installs [16:32] sforshee: 12.10 has a bug where the installer removes the headers (and the metapackage) at the end of the install. [16:32] heh that would do it [16:33] infinity, ah. Yes, the bug I'm looking at seems to be a fresh install [16:33] 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] 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] infinity, makes sense [16:34] apw, thanks for the explanation, I wasn't thinking about pae being a separate metapackage [16:34] tseliot: ^ [16:35] sforshee: Well, not just -pae, but the ARM variants, etc. [16:35] right [16:36] it is the inability of the dkms dependancies to make a sensible decision that is the real issue [16:36] infinity: that would be bug #1123107 and my packages are waiting for approval [16:36] Launchpad bug 1123107 in jockey (Ubuntu) "Jockey should install the linux-$flavour metapackage" [High,Fix committed] https://launchpad.net/bugs/1123107 [16:36] tseliot: I don't see any Q tasks for that. [16:36] tseliot: Which is where most of the affected users are. [16:39] infinity: if that's desirable, I can backport it from raring to quantal. I think precise has the highest priority though [16:40] 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] infinity: oh, I wasn't aware of this [16:42] 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] ouch [16:43] Or something along those lines. I forget the exact bug now, just the symptom. [16:46] 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] apw: yes [16:46] apw: when will ubuntu/master be uploaded? [16:46]