=== BenC__ is now known as BenC === lifeboyy is now known as lifeboy === smb` is now known as smb [08:23] * smb tries to wake up [08:23] * _ruben doesn't even bother to try... [08:27] Regarding my kernel building drama (It just doesn't work!!), I've put all my console output logs to pastebin over the weekend, but since the logs are big, I've put each step in a different paste [08:27] step 1: http://pastebin.com/hpQZd327 [08:27] step 2: http://pastebin.com/ATndWsXj [08:27] step 3: http://pastebin.com/fsP35Miv [08:27] step 4: http://dl.dropbox.com/u/12668653/part4.paste (too big for my pastebin) [08:30] * smb wonders what happened to pre-filtering ... (and needs to finish his first cup) [08:33] lifeboy, Generally, would you feel comfortable working with git? [08:35] smb: Why, I used git to download the sources, but whether I the git sources or the apt-get sources, I get exactly the same result [08:36] smb: and I read manpages from time to time... so if I should I would! ;-) [08:37] lifeboy, The tree is. but if you ever want to do this repeatedly it could help. Also you would have individual commits to look at... [08:39] lifeboy, If you would look at the last of your logs, you could notice at the end, that apparently you modified the configuration in a way that a lot of modules are missing (maybe built-in) [08:40] smb: did you look at my logs in pastebin? I changed exactly 4 things, 2 of which is trivial, one which is essential and one turns build debug code off [08:40] Some info that may help you: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance [08:41] lifeboy, Yes I looked at them. [08:41] II: Checking modules for generic... [08:41] reading new modules...read 2503 modules [08:41] read 2799 modules : new(1) missing(297) [08:41] EE: Missing modules (start begging for mercy) [08:43] lifeboy, It actually tells you which modules, too (but I won't paste them here for obvious reasons :)) [08:44] <_ruben> it's only 297 of 'em ;) [08:45] smb: I saw that, yes, but it's a totally fresh tree download!? Just as a test, at one stage over the weekend, I didn't change anything except added the "gts" suffix, to force some change and I got exactly the same. I think I must revert to 2.6.32-34? [08:45] morning * [08:45] ppisati, morning [08:46] lifeboy, As you start from what you got in the source I would think that maybe one option you changed has impact on many other (as a dependency) [08:47] lifeboy, You may decide that you want to have it that way, then there is info about how to prevent the checker from complaining in the link I posted. [08:49] morning * too [08:49] cking, up an running already. :) [08:50] yeah, got up late today [08:51] cking, Hm, does not look late to me === tkamppeter_ is now known as tkamppeter [08:52] smb, in HWE I was starting at 0730 [08:52] anybody in here have teamspeak by chance? [08:52] offtopic, i know [08:53] cking, Yep, though I would not "see" you untill later... :) And since most of "us" is not farther east than me... [08:53] glitchd_, nope [08:54] mmk [08:56] smb: I'll look at the options, in the meantime I'm testing it again with only one option changed (that must surely be trivial and without dependencies) [08:56] (gts) Local version - append to kernel release [08:56] I have to change something to get the script to save the config of the architecture I want, not so? How else would debian/rules know which arch to build? [09:00] lifeboy, Depending on how you change the changelog you may also need to get the abi files right (also in the link). Usually I would recommend a change like 2.6.32-x.y to 2.6.32-x.y+gts, that makes it a higher version than the original. But a new main version will override it. And only the arch of your host gets built. [09:01] On x86 its i386 or amd64 depending on your host/chroot (uname -m) [09:02] There is several flavours too. If you want to test only one you can do a "fakeroot debian/rules binary-xy" where xy could be generic, generic-pae or whatever flavours are present [09:02] lifeboy, "debian/rules help" or "debian/rules printenv" may help to understand things better [09:03] smb: So if I choose "n" on all the arch questions of "fakeroot debian/rules editconfigs" I would get a standard generic kernel if I do "binary-generic" after that? [09:04] lifeboy, If you do not want to change anything, then why call it at all, but yes [09:10] smb: I want to change what I need; it was a hypothetical question. I ran it with only gts appended, no other change and I still got "read 2799 modules : new(0) missing(5)"... Maybe I should finish reading your link first === popey_ is now known as popey [09:56] smb: As a test I have now deleted linux-2.6.32/ and re-extracted the source tree with dpkg-source -x *.dsc to get a clean .config for all architectures. I'm not running "fdr clean" followed by "fdr binary-generic" to make sure this works and actually builds a kernel package. [09:59] lifeboy, yes, sounds reasonable to make sure there is not something else that causes the build to fail [10:10] smb: Yes, that worked 100%, so now I will just add the r6040 driver, nothing else [10:11] lifeboy, ok [10:13] do we manually manipulare debian/control, or is it created somehow by some scripts?!?!? [10:13] s/manipulare/manipulate/ [10:14] ppisati, I think fdr clean manipulates debian/control, but apw or someone should know better than me [10:15] ppisati, do you have a debian/control.stub and debian/control.stub.in ? [10:15] yep clean makes all those files, thats why one has to clean before packaging [10:15] diwic: good point, didn't check those files [10:15] control.stub.in is the master copy, it gets converted twice to make control [10:16] hmm, is fdr clean being made when you do a launchpad build? [10:16] * diwic is thinking of his recipes [10:17] well, my problem is that i changed abi number (1200 vs 1400) in P/omap4 to avoid any clash between kernels in O and in P (since we don't have any 3.2 kernels for P/omap4 yet i'm reusing the same kernel in O) [10:17] and dpkg-gencontrol was complainging about a missing package version/numeber in debian/control [10:18] and that's when i noticed that debian/control contains package name and the abi version (and i was wondering where it gets the abi number) [10:18] * ppisati is reverse debugging the dpkg* stuff... :) [10:19] debugging in reverse, is that the same as putting more bugs in ;-) [10:20] ppisati, I think (but then again I'm not the expert here) that "fdr clean" would propagate the ABI num from debian/changelog to debian/control* [10:21] ppisati, yep those should also never be checked in, only control.stub.in [10:21] diwic, that is the normal flow yes [10:22] apw, hmm, so I'm working on taking over bjf's auto build ALSA stuff, and this is one part when I'm stuck... [10:23] apw, I guess I would have to make launchpad run "fdr clean" at some point, just cannot figure out *which* point... [10:24] before any packaging steps for sure [10:24] apw, that is before even making the source package...I was afraid so [10:24] yes, as to make the source pacakge you need the control file [10:25] that doesn't stop you checking it in in your copy that it builds from i guess [10:25] apw, I guess I'll have to resort to manually running "fdr clean" on every ABI update then and check in the result [10:25] that might work, cron can do that as well as you [10:25] apw, because launchpad won't allow me to run arbitrarily script at the recipe build stage [10:29] smb: Freakin' blinking living daylights! It actually compiled! Why on earth does adding a local version string and removing the "Compile the kernel with debug info" flag break the compile?? [10:30] before I get excited too quickly, let me just see if the all the modules I need are actually there [10:33] root@Ashton:/opt/ltsp/i386/usr/src/linux-2.6.32# lsinitramfs /opt/ltsp/i386/boot/initrd.img | egrep r6040 [10:33] lib/modules/2.6.32-35-generic/kernel/drivers/net/r6040.ko [10:33] So the module is there! :-) [10:33] lifeboy, I cannot say I understand why there have been modules missing. I would have understood if the ABi check failed for that. Because it could subtly change some commonly used structures. [10:34] lifeboy, Also one needs to be careful where to add the version string. It should only be done in debian.master/changelog [10:34] At least some results then [10:34] Yes :-) [10:35] could the version string have messed with debian/rules's senses? [10:36] lifeboy, Maybe... its one of those things one does not do (or I do not). [10:37] Generally the build environment can be a bit of a pain when stepping left or right of the usual path... [10:44] I suppose menuconfig makes it so easy to change things that it seems simple. It would be great to have an easy way to see which option requires the missing dependency if that is indeed the case [10:45] smb: Is there another way to identify a custom kernel then apart from inspecting which modules are in it? [10:46] lifeboy, Only if you modify the version in the changelog (which is really recommended) [10:46] The version there goes into the package nameing as well as being visible with uname -a [10:49] hmm, that makes sense (even to me! ;-) ) [10:57] smb: I actually have a boot image that works and my LTSP client loads!!! It has been an arduous journey of more than three weeks to accomplish this seemingly simple task, but it's actually done. [10:58] lifeboy, Many things look simpler than they are. Anyway, congratulations. :) [11:01] smb: Well at least it's that way round, since in life things look much more complex than they actually are. :-) Thanks for your and others' patient assistance. [12:05] ppisati, natty/ti-omap4 is _not_ a rebase tree is it ? [12:10] apw: nope [12:22] tseliot, do you look after wl as well as all the graphics drivers ? [12:31] apw: err... from time to time, what's up? [12:32] tseliot, oh it looks like it won't compile anymore if we upload 3.2 based kernels [12:33] apw: any logs? [12:37] tseliot, hrm yes somewhere. i hate dkms and its hiding of logs [12:38] apw: :) [12:39] apw: maybe /var/lib/dkms/driver ? [12:39] * tseliot -> lunch [12:40] tseliot, http://paste.ubuntu.com/745082/ [12:40] tseliot, i have the feeling that that has been removed in the kernel as no longer required (something else does the same thing now) [12:51] smb, ping. [13:11] smoser, yes? [13:21] so you think that bug 884320 is a dupe of bug 884320 ? [13:21] Launchpad bug 884320 in linux "EC2 oneiric "BUG: unable to handle kernel paging request at f57ba9a1"" [Undecided,Confirmed] https://launchpad.net/bugs/884320 [13:22] well, obviously its a dupe of itself [13:22] you think that is a dupe of bug 854050 [13:22] Launchpad bug 854050 in linux "BUG at /build/buildd/linux-2.6.38/mm/swapfile.c:255" [Medium,Confirmed] https://launchpad.net/bugs/854050 [13:26] smoser, ^ [13:26] smoser, I guess that is roughly what I said [13:26] comment #9 [13:26] and oneiric archive has a new kernel now ? [13:28] smoser, Give me a sec to check where it may be right now [13:28] https://launchpad.net/ubuntu/+source/linux says 3.0.0-13.22 is in -updates now [13:28] (for 4 hours) [13:30] smoser, that patch seems still on the next branch. So not yet in updates [13:31] so do es that mean that one can get said kernel at https://launchpad.net/~kernel-ppa/+archive/pre-proposed?field.series_filter=oneiric ? [13:32] smoser, It could be. Would need to look in the changes to make sure the "Partially revert" is in there [13:33] thanks for your help [13:39] so, generally , "fix committed" would mean something is available in the ppa ? (or at least will be in an automated fashion very shortly?) [13:43] smoser, the kernel team uses that state to mean that a patch has been committed to a core repository from which official kernels are generated. [13:44] (eventually) [13:44] right. [13:44] is the ppa manually maintained ? [13:44] or per-commit build ? [13:45] smoser, pre-prposed is automatically maintained. [13:45] its uploaded once per day if there have been changes [13:46] thank you, kind sir. [13:47] and is it acceptable for me to point people at those kernels, then if something is marked fix-committed ? [13:47] (purely from a "can you test if you still see this here" perspective) [13:47] smoser, that what its original intent was, e.g., testing tip of master-next [13:48] great. [13:52] Howdy sirs, any clue whether the adaptec 6405 controllers will be supported in any eventual release of ubuntu? [13:53] DW-10297, that depends on upstream support from Adaptec. Is this a new controller ? [13:53] it came out i believe at the beginning of 2011 [13:53] and there are driver sources, etc [13:56] herton, tgardner Just stumbled over a mail to upstream stable regarding igb driver and 3.0.8 when pulling the network cable. Though the report is unclear on whether this is a regression or not. [13:57] DW-10297, I'm not seeing much with adaptec and 6405 in the kernel. do you have PCI IDs ? [13:58] http://pastebin.com/HGPyHq9h look for 352.02:00.0 RAID bus controller: Adaptec Device 028b (rev 01) taken from Fedora16 [13:58] smb, hmm ok, today I should push a new oneiric update, but I can wait [13:58] DW-10297, looks like Adaptec is supplying a DKMS driver, http://www.adaptec.com/en-us/speed/raid/aac/linux/aacraid-dkms-1_1_7-28000_tgz.htm [13:59] is there some way to add that to the netboot installer? I have to install on like 50 machines [13:59] herton, I'd probably not wait, but just wanted to give you hinting in case this comes up [14:00] alternatively [14:00] 803.02:00.0 0104: 9005:028b (rev 01) [14:00] i believe it's 9005:028b. [14:00] I've asked adaptec to simply allow you to configure it to present itself as a 5405 since the controllers do seem to be somewhat identical but they don't like that idea =D [14:01] in f16 it just uses their aacraid driver [14:01] DW-10297, drivers/scsi/aacraid/linit.c: { 0x9005, 0x028b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 62 }, /* Adaptec PMC Catch All */ [14:01] smb, now I saw the thread "Kernel v3.0.8 igb driver dies when pulling network cable", not clear if it's a regression indeed, I'll just do the update and lets watch if we get reports about it [14:02] herton: is that the core i7 issue again? [14:02] herton, Right. Sounds good. I just was not sure you saw it or not. :) [14:02] where if you disconnect the dvi it breaks PCI/PCI-E/USB? [14:02] DW-10297, it's ang igb driver issue [14:03] *an [14:03] network driver [14:03] hehe https://bugzilla.redhat.com/show_bug.cgi?id=670948 [14:03] bugzilla.redhat.com bug 670948 in kernel "Disconnection of DVI cable causes IRQ lockup on Intel DH67BL" [Medium,New] [14:03] that's a fun platform by the way.. sandy bridge [14:04] tgardner: so does that mean it should work on the netboot kernel or it should not work on the netboot kernel? [14:04] DW-10297, it ought to at least load the driver. can you tell that from the dmesg ? [14:05] let me check... too many boxes on my desk =) [14:08] apw: yes, that's surely the case. I'll see what I can do [14:09] and before anyone goes "hey if you love fedora so much why don't you just use that"... welll i wouldn't be here if I thought that was an appropriate choice = [14:13] ah, okay... so um.. it does see sda it just ... doesn't install to it.. =) [14:14] DW-10297, well, thats kind of a different issue. [14:14] Not disagreeing with you [14:14] just usually when it tells me no root filesystem is defined it's because it can't find the disk [14:15] im guessing maybe the kickstart file format changed since 11.04 [14:16] DW-10297, uh, dunno. you're saying it installs OK, but then won't boot ? Or it just won't PXE boot ? [14:24] tyhicks, poke [14:25] Ah, what I originally thought was that it didn't have the driver for the adaptec 6405 because whenever it got to the part to partition the disk it failed out, then I went into the shell in the installer and did an fdisk -l and it shows sda in there, so then I thought it was my auto install kickstart script so I went into the script and commented out everything related to the disks so it [14:25] would present me with options instead of just trying to do it... now at the "Configure disks" step the only option is 'configure an ISCSI volume' even though if I do an fdisk -l, dmesg | grep sda there it sees the disk. [14:28] tgardner, https://bugs.launchpad.net/ubuntu/precise/+source/wireless-crda/+bug/856421 [14:28] Launchpad bug 856421 in wireless-crda "wireless-crda duplicates functionality found in crda+wireless-regdb from Debian" [Undecided,In progress] [14:47] * herton -> lunch [14:49] tgardner, good morning. looking at this bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/836250 . I was able to reproduce on my side. It looks like wireless-n routing in the centrino chips was working in 11.04, but not in 11.10. Looking at upstream bugs... the older firmware version seems to fix the issue. Whats a good idea for next steps? [14:49] Launchpad bug 836250 in network-manager "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [High,Invalid] [14:50] arges, regress the firmware ? is that what you're suggestuing ? [14:50] tgardner, well I will test on my laptop today. but that seems like not a good idea to regress [14:51] arges, I haven't checked lately. Has Intyel updated firmware for that adapter? It seems N routing is a fail on other models that use different firmware. [14:52] arges, what is your environment? I was not able to reproduce any N issues, but I've got quite a clean room RF wise. === yofel_ is now known as yofel [14:54] well I was at my in-laws house, and they have a newer wifi router. a/g/n if I put it into a/g mode I have no issues. If its in N mode I can connect to the AP, but pages seem to take forever to load. My chip on my laptop is a centrino ... [14:54] Intel Corporation Centrino Advanced-N 6205 (rev 34) [14:54] arges, so maybe its the compatibility mode? Pure N works OK, but a/g/n sucks ? [14:55] I'm not sure I tried that, but its been a few weeks [15:00] How can I ensure that the eact same kernel will be built (except for one file I hacked) for Lucid? I cloned teh source and want to copy /boot/config-2.6.32-35-generic to .config in my source dir, but I also want to skip make menufconfig somehow (because it seems like everytime I use that, tons of stuff is missing) [15:01] it seems linux (2.6.32-36.79) lucid-proposed; urgency=low is what I have checked out === tgardner is now known as tgardner-afk [15:14] is linux-meta going to get switched over to 3.2.0-1 in precise soon? I'd like to get rid of a couple of the last uninstallables in precise, which that should indirectly achieve [15:23] tgardner-afk, trying to check for the latest iwlwifi firmware, but seems like intellinuxwireless.org is not responding [15:26] cjwatson: am hoping to get it uploaded by EOD if not sooner. we're looking into one additional fix to squeeze in before uploading. [15:26] apw: regarding brcmsmac, looks like it was intentionally made to conflict with bcma: [15:26] commit 75e07b6b2bcb1dad971870a039d5f1441e64bd58 [15:26] Author: Henry Ptasinski [15:26] Date: Tue Aug 23 14:13:53 2011 +0200 [15:26] staging: brcm80211: only enable brcmsmac if bcma is not set [15:27] apw: so it looks like we'll have to choose either one or the other [15:27] ogasawara, do we even know what the options mean, sigh [15:27] oh wow, so you only get newer hardware support for b43 or brcmsmac then? [15:28] they are starting to annoy me enough to take my machine apart and throw their crap out [15:29] apw: according to Kconfig, BCMA is "Bus driver for Broadcom specific Advanced Microcontroller Bus Architecture." [15:31] * ogasawara back in 20 [15:31] How can I ensure that the eact same kernel options/config will be built (except for one file I hacked) for Lucid? I cloned the source and want to use /boot/config-2.6.32-35-generic as my config. [15:31] its the replacement for ssb in newer broadcom cards [15:31] Or remove overlapping device IDs from bcma [15:33] mjg59, yeah, is that all its about? [15:33] synapse, just follow the "Building the kernel" section at https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel, on your checked out tree, in case you didn't change any config option by hand [15:36] ok, I was trying to piece together https://help.ubuntu.com/community/Kernel/Compile and it didn't really make sense for what I'm doing [15:36] dw1501/1504 (broadcom 4313/14e4:4727) is one of the more popular wifi cards in dells in the past year (because its the cheapest) and that doesn't work with b43 yet it tries to load it [15:39] Sarvatt, sigh [15:41] ogasawara: ta [15:42] ogasawara, omg brcmsmac moved out of staging and into the real world [15:43] apw: Yup [15:43] Or remove the overlapping entries from brcmsmac [15:49] mjg59, any idea of that the plan upstream of if they are just throwing pies at each other [15:49] Right now they're throwing pies [15:49] I should just write a patch and see what happens [15:49] :) i guess i shouldn't be supprised [15:49] Actually, it's mostly just one person throwing pies [15:50] yeah i was wondering the same, fix it in some poo way and shove it over the wall [15:50] herton: so if I follow the section that says "Modifying the configuration", it says to "fakeroot debian/rules editconfigs" which takes the current configuration (in /boot?) and uses it for the config? [15:50] * apw tests if it fixes his broken lappy [15:50] I dont want to modify the configuration at all [15:50] synapse, no that uses the current config in the tip of the git tree [15:50] synapse, you don't need to do anything if you're not change any config option [15:50] which is very likely the same [15:50] *not changing [15:51] synapse, you can use fakeroot debian/rules genconfigs, and check the one you have against that in CONFIGS/* [15:51] does genconfigs use whats in /boot ? [15:51] synapse, just build, the build process will build the final config that goes into /boot, which is the same you have [15:51] oh [15:51] synapse, no it makes human readable configs from what is in the git tree [15:51] so skip the "Modifying configuration" section? [15:52] which u can compare against what you want it to match (which i suspect it will) [15:52] does it diff /boot/config/2.6.32-35-generic to somewhere? wheres the config it actually uses? [15:53] in CONFIGS? [15:54] synapse, it doesn't use /boot, it creates the config that goes into /boot, it assembles the config from debian.master/config/ in the source tree [15:54] fakeroot debian/rules genconfigs creates human readable configs in CONFIGS/*, they are simply a convienience so you can see what will be put in the packages which is what makes /boot/* when installed [15:56] I see, are the config options the same as what I am using now? [15:59] so I guess I don't understand some major concept here, when I use git to check it out, all of the kernel options/config are the same as when I update using update-manager? [16:01] synapse, the git tree is the master source of the configurations as well as the code [16:01] synapse, the configurations that end up in /boot are made from teh contents of the git tree and are placed into /boot as part of installing the .deb made from the git tree [16:03] synapse, the commands above let you extract the complete configs from the git tree if that is useful [16:06] ok, let me rephrase all of this, I don't want to change the config I am using with the kernel I currently am running at all [16:06] when an SRU kernel fails some tests, what do we do? i mean, do a open a new bug for every problem found? [16:06] s/a/we/ [16:06] synapse, then you need to compare it to whats in the git tree and fix any differences, though if its a stable release its most likely the same [16:06] can't I just copy it over from /boot ? [16:06] I am running #78 right now, #79 is what I checked out [16:07] synapse, if you really mean "i want whatever ubuntu will be using in the next update" then whats in the git tree is already that [16:07] synapse, the tree is configured the way it will be in the next release, its a full ubuntu configuration [16:07] (next release in the series you have chekced out) [16:07] so when I get kernel image/header updates via update-manager, it doesn't rely on applications I already have installed at all, just uses the config in the git tree? [16:08] synapse, If you want exactly what was in that release then do a "git checkout Ubuntu-2.6.32-35.78" then the tree and the configuration files that are in that tree will get you the identical kernel packages when compiled [16:09] thats the answer I needed :) [16:10] synapse, yes the kernel configuration is unrelated to what is on your machine, it is only specific to the kernel [16:10] so wait, I should do a git checkout Ubuntu-2.6.32-35.78 ? [16:10] Im totally lost [16:11] synapse, that is exactly the source which was used to make the source pacakge for the upload with version 2.6.32-35.78 [16:11] ppisati, are you referring to the ti-omap4 on maverick tests? I guess only one bug opened would be sufficient (different from the tracking bug), so it's referenced in the SRU patches and can be verified later [16:11] so inside my source dir (after cloining), I run git checkout Ubuntu-2.6.32-35.78 ? [16:11] cloining/cloning [16:12] synapse, If you cloned the ubuntu-lucid.git repo [16:12] that would do it [16:12] yeah [16:12] so I got "HEAD is now at 03b97f3... UBUNTU: Ubuntu-2.6.32-35.78" [16:13] now just build/install ? [16:13] * apw is unsure why you'd want to just build what you already have [16:13] * smb was sort of thinking the same [16:13] thats what I'm trying to do! [16:14] and keep getting different people telling me different steps to take [16:14] so I'm lost [16:15] synapse, if you run the build as described in https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel [16:16] you will get packages that should be exactly what you got installed already [16:16] ok [16:18] and expect it to take hours unless you have a monster machine [16:19] it takes 41 mins the last time I built [16:20] then you have something reasonably big [16:20] I just hope it boots [16:20] synapse, i suggest you make sure you have an older known working kernel to fallback on before you install your replacements [16:21] * apw suspect he doesn't want to know why you want to build and replace what you have with identicle ones [16:21] well, I have that now [16:21] FYI, thanks for the help. === tgardner-afk is now known as tgardner [16:28] herton: so, a generic bug with an excerpt with all the failed tests is enough? [16:28] tgardner: just fyi, testing precise rebased to latest upstream tip seems to resolve suspend/resume on hp-mini [16:29] ppisati, I think so, don't see a reason to have separate bugs, just extra work [16:29] ogasawara, thats good to hear. any idea what the fix was ? [16:29] tgardner: not specifically, just noticed a few power management related fixes so decided to give it a try. [16:30] ogasawara, test kernel somewhere ? [16:30] tgardner: on gomeisa [16:30] tgardner: in the precise-i386 dir [16:31] ogasawara, my box is 64 bit. guess I'll spin a kernel. have you pushed the recent rebase ? [16:31] tgardner: I haven't, was going to wait till -rc3. but I suppose it won't hurt to just push it to master-next. [16:32] ogasawara, taht would be good. I don't think you need to tag it [16:32] tgardner: ack [16:36] tgardner, might have got cut out earlier. looking at that centrino wifi issue. I will test with/without n again, in addition I will look and see if older firmware issues fix things. Any set of tests/tools I should be running for wireless to help verify its working correctly? [16:36] arges, I use iperf which will give you performance metrics [16:38] tgardner, ok will do that thanks! [16:39] ppisati, i assume you are owning precise ti-omap4 kernels, and handling any security poop we dump on oneiric if its applicable ? [16:40] stop dumping poop on us ! [16:40] :) [16:40] * apw makes a note, no security fixes for arm [16:40] lol [16:40] :~/source_backup/debian/linux-image-2.6.32-36-generic/boot$ diff config-2.6.32-36-generic /boot/config-2.6.32-35-generic <- shows no differences [16:40] :) [16:40] except the kernel version [16:40] apw: as long as we don't get any 3.2 TI BSP, i will import O/omap4 in P, so we will get that for free [16:41] apw: in short, yes [16:41] * sforshee goes to run an errand, back in about 30 minutes [16:41] ppisati, ok so i can ignore P arm for now then for security at least, thanks [16:42] bug 893190 [16:42] Launchpad bug 893190 in linux-ti-omap4 "Qa-testing failures for 2.6.35-903.27" [Undecided,New] https://launchpad.net/bugs/893190 [16:42] herton: ^^ [16:43] apw: I am on section "Building the kernel" and it wants me to install the .deb images/headers, but I don't see them.. do they reside in debian/linux-image-2.6.32-36-generic? [16:43] synapse, ? i am not sure i expect you to install them to build them, that doesn't seem right [16:43] synapse, ls ../*.deb [16:44] ahh after building, yes in the directory above [16:44] oh, it moves them out of the root dir [16:44] it puts them where the build expects to find them [16:45] so I have linux-headers-2.6.32-36_2.6.32-36.79_all.deb, linux-image-2.6.32-36-generic_2.6.32-36.79_amd64.deb, linux-headers-2.6.32-36-generic_2.6.32-36.79_amd64.deb and linux-tools-2.6.32-36_2.6.32-36.79_amd64.deb ... just issue sudo dpkg -i linux-*.deb to install and reboot? [16:45] ppisati, ok, you can use buglink for this bug when you drop the fixes for review, and we tag for verification later when pushing the fixed kernel [16:46] synapse, you need the two headers and the image only, but other than that yes [16:46] synapse, you only need linux-image [16:46] (you only need the headers if you have dkms packages installed) [16:46] can I just issue dpkg -i against them all? [16:46] any harm done? [16:47] or skip tools [16:47] no it should be safe, just not necessary if you don't need them [16:48] does it modify grub for me? === ericm|ubuntu is now known as ericm-Zzz [16:51] that document needs updated to say you need to sudo apt-get install linux-tools-common or it errors out on the install [16:53] ok, here it goes, rebooting, brb (I hope) [16:57] Linux darkside 2.6.32-36-generic #79 SMP Mon Nov 21 11:16:56 EST 2011 x86_64 GNU/Linux [16:57] :) thanks all [16:57] cirtianly not one of our builds [16:58] hehe [16:58] now time to try what the heck it was I was doing [17:00] whats the easiest way to change "generic" to something else? [17:01] synapse, there is no real way to change flavour names, they appear all over the place [17:02] it is a matter of finding the places it already appears, and the files with it in the name [17:03] well, thanks to your help, I was able to add support for the Roland Gaia synthesizer in linux now :) === lifeboyy is now known as lifeboy [17:03] since Roland doesn't want to release drivers for linux (win/mac only), I added a usb quirks table entry and now have ALSA support for usb audio and midi in/out [17:04] synapse, you should send that upstream [17:04] so it ends up in the real kernel sometime [17:04] I will be, I'm submitting it to the alsa-devel folks for review, I have some more tweaks to make [17:04] I am amazed this worked [17:04] ogasawara, ok so i ripped out the 'stop brcmsmac' change and now my wireless is working [17:04] apw: ack, want to just push it to master-next [17:05] apw: also, I'll be away on Fri, could you stand in for me at the release meeting [17:05] ogasawara, am thinking about whether we should be doing that for now, or fixing it better, perhaps this is ok as its only as bad as it was before [17:06] ogasawara, i suspect wl is still needed for a number of older devices [17:06] ogasawara, apw: I think we should prefer the brcmsmac solution since I believe we'll get better results from Broadcom as an upstream. [17:06] apw: it's no more offensive than it was before, so I say push it [17:06] tgardner, yeah they do seem to have pushed it into mainline ok, so they obviously are trying at least [17:07] and it sounds like they are going to allow coexistance in the end [17:07] i still use wl on my netbook, it's an lpphy model that's not supported at all on the new, and not very well on the b43 driver (it overheats and fails in neat ways) [17:07] apw, Broadcom is also paying engineers to work on it full time [17:07] we have two choices, allow both and cross fingers, or unpick the duplicates [17:07] apw, pull the duplicates from b43 ? [17:08] ogasawara, ok so i'll push my bodge for now, and we can look to unoverlap them if upstream doesn't sort their shit out [17:08] apw: ack, sounds good [17:08] tgardner, yeah that probabally the better solution overall [17:08] there is something in the changelog that implies they are working out how to use the common underlying layer [17:09] apw: was tseliot looking into the wl issue? [17:09] apw, yeah, but taht ain't gonna happen for 3.2 [17:09] apw: one last quick question, if I want to rebuild, can I just run fakeroot debian/clean ? [17:09] ogasawara, yep i believe he is doing so yes [17:09] and start all over? [17:09] synapse, yes [17:09] thanks so much [17:09] take care [17:09] ogasawara, i think wl is pretty fixable, i think we removed the need for something so we can just drop it from wl too [17:10] ogasawara, apw: yes, sorry, I've had a hardware failure and I'm dealing with that first (fortunately I had backups) [17:10] apw: cool, so it should be fixed relatively soon. in that case, I'm going to upload the brcmsmac fix, then upload linux-meta. [17:11] apw, Just a word of safety (probably not needed if the newer drivers are any better). But with some broadcom the b43 did seem to work but was a nightmare to work with (lots of dropped connections) [17:12] tseliot, nasty and a timely reminder for the rest of us [17:12] * tseliot nods [17:12] tseliot, yeah if we can get teh wl fixes in soon that'll make people happier [17:13] smb: does it "feel" like temperature problems or have you not experienced them yourself, cuz it really feels like it's a temperature thing on mine, it will work for say 2 hours; then it will just stop working, unloading & reloading the module would get you a few more minutes [17:13] ogasawara, ok utter bodge pushed [17:14] apw: I know but I'm afraid I won't be able to do it today [17:14] and last i looked theres not much accounting at all for temperature, the phy especially operates at a certain temperature and will start failing if it overheats [17:14] tseliot, no worries :) [17:14] ohsix, It may be that too. I only had it up for a bit and then got annoyed and replaced it with wl again [17:14] apw: but I'll focus on it tomorrow [17:15] tseliot: thanks [17:15] ogasawara, we should know before you upload meta whether wl is easy to fix [17:15] i already helped some linux-wireless guys fix the sprom problem i had on mine, but i didn't use b43 much longer after that, due to the aforementioned problem [17:15] tgardner, i will add a todo to unoverlap the two driver id lists preferring the brcmsmac where they overlap [17:15] smb: part of the discussion of the new bcrmsmac or whatever drivers, the broadcom guys alluded to temperature & test parameters being in the newer drivers and basically ignored in b43 [17:15] apw, ack [17:16] tgardner, or we could simply add a blacklist for b43 while we are at it [17:16] so people have to 'flip the two lines' there to get the other [17:17] apw, um, won't that involve user space changes? I think we should just fix the PCI IDs [17:17] tgardner, yep, though it might makse sense as it does allow easy testing of b43 for specific overlaps [17:18] ohsix, Thanks for the info. I will see to get some precise level install and testing on the laptop in question [17:18] neat, no problem [17:19] tgardner, whatever did come of the plan to move blacklists into the kernel package [17:19] apw, I'm not remembering that. would the blacklists be unique to teh kernel version? I think they would have to be [17:20] having the blacklists in the kernel does kind of make sense [17:20] right and i think that is why scott wanted to shove them over, never happened of course [17:20] sounds like a P think [17:20] thing [17:20] make it a TODO item? [17:21] adding it now [17:21] I wonder if modprobe has support for something like that? [17:21] smb: there are on device temperature probes but i didn't look into logging them or how to access them, haven't looked at bcrmsmac at all really [17:21] i suspect it likely doesn't but it cann't be hard to add [17:22]