[06:37] tjaalton, Have you also looked at the other kernel trees? (linux-ports, linux-lpia). I think those would be the sources for linux-libc-dev for architectures for which the kernel isn't provided by linux. [06:39] persia: oh right :) [06:39] I didn't [06:48] anyway, the armel build should've pulled linux-libc-dev AIUI, since libc6-dev should depend on it === smb_tp_ is now known as smb_tp [13:12] apw: thanks for your help yesterday [13:13] Domas still hasn't made a showing so I just went ahead and restarted most of the 32GB servers with 3GB less target mem usage [13:13] http://ganglia.wikimedia.org/pmtpa/?m=mem_report&r=hour&s=by%2520hostname&c=MySQL&h=&sh=1&hc=4&z=small [13:35] I am getting a kernel panic in about 10 min when running some firewire cam stuff [13:35] 2.6.27-9 generic x64 [13:36] I am now trying -7 [13:43] CarlFK, also try the -11 kernels in -proposed [13:45] will do [13:56] Hi! bug 51779 was about having to manually load the ircomm module and to create some /dev/ircommX devices. The devices are now created automatically, after loading ircomm manually. Can I consider this fixed? [13:56] Malone bug 51779 in linux-source-2.6.17 "IRDA-Devices are not created by default (ircomm: 161-0" [Wishlist,Won't fix] https://launchpad.net/bugs/51779 [13:59] -7 just paniced. but i got -11 installed in time :) [14:11] -11 panic: up 23 min, load average: 1.33, 1.56, 1.18 Cpu0 : 82.0%us, 1.3%sy, 0.0%ni, 16.7%id, [14:12] I bet I should pull nvidia... [14:22] what's the command to rebuild menu.lst? (it adds lines for the kernels it finds in /boot) [14:23] update-grub [14:23] thanks [14:39] update-grub lies: Found kernel: /boot/vmlinuz-2.6.27-11-generic ... Updating /boot/grub/menu.lst ... done http://dpaste.com/108526/ [15:07] hi rtg , did you change some dell blacklight settings in the last kernels? [15:07] somebody with dell vostro 1000 had working fn keys for backlight but then it stopped working [15:08] Kano: apw did in Jaunty. perhaps http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=e9c7dae04d7168ce7f3b823a1d7349e2212e29fb [15:09] hmm i guess i revert that [15:12] there are a bunch of people in various tates of regession against hardy, the fixes there fixes most. with the stack there we have been able to get all of the reporter working either automatically or diabling acpi_backlight on the command line. a more complete fix needs to come from upstream [15:12] or i just compile 4.9 kenrel again [15:15] Someone just needs to figure out why i915 interrupts don't work properly === BenC1 is now known as BenC [16:13] lool, would you be able to test an lpia kernel for me, the test image is in my ppa: deb http://ppa.launchpad.net/apw/ubuntu jaunty main [16:14] as linux-lpia as 'normal' [16:20] apw: Yup [16:43] rtg, ok i've squashed down all the debian/* junk into one commit and pushed the new tree to zinc. ubuntu/ubuntu-jaunty-lpia.git [16:44] apw: cool. thanks. [16:45] note there are some AUTO commits in there which are built but amits automation [16:45] now its all cleaned and squashed the delta is minute, four patches [16:46] apw: you want it packaged and uploaded? [16:47] i'll counter with two questions: [16:47] 1) is it any use without -lum et al? [16:48] 2) should we wait for the testing smb and lool are doing [16:49] apw: the kernel needs to be uploaded _before_ LUM for header packages [16:49] there is actually only a lrm it seems, no idea what is in it yet [16:49] apw: until we upload linux-lpia-meta no one automatically pulls the package. [16:51] as its a rebase tree, a new kernel isn't the end of the world its just a bounce of the .N at the end, so if you think it looks sensible as a first step thats fine with me [16:57] apw: I understand that the debian/ changes were not merged; if you intend to keep this tree, I guess you might want to merge the debian/ changes from ubuntu-jaunty.git into ubuntu-jaunty-lpia.git perhaps? [16:59] lool: can't we just start with what it is? Its a 2.6.28 kernel with some UBUNTU patches applied, which _are_ represented in the changelog. [17:00] rtg: I thought you guys wanted to minimize delta between linux and linux-lpia [17:00] And I wish that too [17:00] yeah we do, but you wanted it yesterday too [17:00] Sure, I'm not saying this is urgent [17:00] Sorry, I should have hinted this is minor [17:01] lool: I really only care about code delta. The debian directory changes don't matter much. [17:01] i can't see why we have a different debian directory in here really [17:01] we should probabally pull the differences out that matter and make them a delta on the top of the normal debian dir [17:01] rtg: These include config changes for instance [17:02] All the work you've been doing on demodularizing the kernel [17:02] I'll get back to you. kernel IRC meeting right now [17:02] those of course are lpia specific so less difficilt to manage === TimStarling is now known as Tim-away === asac_ is now known as asac [17:54] rtg: I also have decent ARM hardware (Thecus N2100 I think it's 600 MHz 512 M) but not running jaunty yet [17:55] If it's something blocking you, I can prioritize bringing it up [17:55] lool: I need to get this fixed anyway since its sort of a long term issue. [17:55] Obviously porter box would be much more convenient [17:55] I'll just figure out qemu, I have a dual quad core. [17:56] It's relatively slow and segfaults a lot with lots of memory [17:56] But I'm glad you'll try that out, will make you have a look at the video issue :) [18:03] apw, So, you're the current lpia person? Would you be able to help me understand the difference between lpia and lpiacompat? [18:04] erm, i think thats an over simplification. i touched it last :) [18:05] OK. Last I looked, "lpia" had CONFIG_M586=y and "lpiacompat" had CONFIG_M586 is not set. The information I received originally was that "lpia" was for A1x0 and Atom, and "lpiacompat" was for everything else. Something seems not to match. [18:05] persia, but the difference as i see it is that lpia has lots of useless things turned off so is leaner [18:05] "useless"? Would that be why I have better device support with -generic on i386 on my Atom device than with lpia? [18:06] Actually, ignore the second question :) [18:06] persia, very probabally, lots of things like ATM AppleTALK, HIPPI, IPX etc are off in that kernel [18:07] So, is there any way to tell which would the better kernel to install between lpia and lpiacompat? [18:07] Oh, those are useless :) [18:07] I thought maybe M586 would be the key, but it seems backwards from how I would expect it. [18:07] the only difference is config, and the difference there is in the git tree [18:08] So when should "lpia" be installed, and when "lpiacompat"? [18:08] About 6 months ago, amitk told me that it was 586/686 as a split, but it seems to have moved. [18:09] (or is opposite what I expected, or I misunderstand the CONFIG_M586 config option) [18:10] i can't say i have definitive knowlege, but i would say lpia is for real devices in the field (it has 586 set), and lpiacompat might be for buildd's or something, running the same code on a normal machine [18:10] So every sensible end-user device should just have "lpia" installed, and if that doesn't work, users ought file bugs? [18:11] (noting that some users may be told "Use i386") [18:18] persia, that sounds reasonable to me yes [18:19] Thanks. That makes the necessary installer magic really simple :) If later something (e.g. /proc/cpuinfo flags) can be used to differentiate or something, we can change to support that. [18:54] apw: did you use some variant of rebase-intrepid when creating the Jaunty lpia tree? [19:00] yes, i did exactly that [19:00] rtg, i used it to handle the auto part, then pulled the patches in by hand [19:00] and then massaged it to fold them down [19:01] apw: but you didn't update the script, right? It still references Intrepid [19:01] yes that is partly error, partly deliberate [19:01] as to do an intrepid to jaunty conversion on has to hack it to be scitofrenic [19:02] so a new rebase-jaunty needs to be in there, but i've not had a chance to test it [19:02] apw: ok, I'm just cleaning out some arm cruft [19:02] could you see if we need the -virtual thing in control while you are there [19:04] apw: I don't think we do. though its in the Intrepi LPIA tree, its never build 'cause it doesn't exist within the LPIA arch [19:04] i was confused by it, but left it cause it was in intrepid too [19:06] apw: if you look in debian/sub-flavours/virtual.vars you can see thats its only built for arch="i386 amd64" [19:07] yeah [19:22] rtg is there some trick to building an lrm? [19:23] apw: the new -intel fails to build again using the kernel drm headers.. libdrm 2.4.3 has something newer that's needed.. just a heads up, can't hunt commits right now: http://pastebin.com/m3a90934c [19:23] (the new being 2.5.99.2) [19:25] post-alpha3 stuff anyway.. [19:25] tjaalton, ok thanks [19:30] hi, are there somewhere older 2.6.28 kenrels than -4.9? [19:32] as deb [19:33] is kernel-package maintained by the kernel team? [19:37] the upstream is severely broken... it produces unusable headers, for one.... see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475036 and http://sidux.com/PNphpBB2-viewtopic-t-11109.html [19:37] Debian bug 475036 in kernel-package "kernel-package: kernel-package is suffering from bit rot, and is severly broken" [Serious,Closed] [19:37] anyway the version in ubuntu is likewise affected [19:38] be back in a few... lunch [19:41] it appears the fix received hex: 1872151 according to a changelog for 11.002 [19:47] apw: still having problems with lrm? [19:48] apw: jaunty lpia uploaded [19:51] rtg, no i think i got myself sorted basically [19:52] it needs the headers [19:52] apw: yeah, needs kernel headers [19:55] rtg, so whats the rules on version matching. i assume its supposed to be the same as the kernel [19:56] apw: only the ABI has to match. the minor (uopload) number is not relevant [19:56] upload, even [19:56] ahh thats better [19:56] apw: you can look in the generated /debian/control to see what it depends on [19:57] doh of course [20:03] rtg: btw. it seems the 4.9 kernel without that backlight patch works [20:03] apw: ^^ [20:03] for vostro 1000 [20:04] i fetched the u binary [20:04] because my pbuilder failed with the source [20:04] 'that backlight patch' whats the title for that one [20:04] there are not so many patches from .9 to .10 [20:05] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=e9c7dae04d7168ce7f3b823a1d7349e2212e29fb [20:05] that one was the one smb_tp reverted i believe [20:05] in intrepid at least, he replaced it with something else [20:06] apw, No just reverted [20:06] at least this code [20:06] i thought you put some other change on the top, the one i reviewed, to get things working [20:06] for the time being I just allowed acpi and vendor drivers concurrently [20:07] ok, so speaking i replaced it [20:07] thats the one i was thinking of [20:08] The -4.9 without that patch in question will probably work mostly [20:08] just not for T61 and Asus... [20:08] yes, it did work, just not 4.10 [20:10] Kano, At least with Intrepid there were some happy some not [20:12] maybe make an extern video override package [20:13] I guess we got a workable state for Intrepid now. For Jaunty it is more of getting the acpi driver better in upstream [20:14] apw: why does scripts/setlocalversion in the kernel keep adding cruft to include/config/kernel.release. i.e., 2.6.28-4-orion5x-00002-gf1820d3 [20:15] rtg, There was a config option about local option that adds git sha's [20:15] Trying to remember [20:15] it does that by default if the tree isn't clean [20:15] or something like that [20:15] you should never see that in the debian/build thing [20:16] CONFIG_LOCALVERSION_AUTO [20:16] distclean'ing [20:17] smb_tp: you're a genius. [20:17] I think it was if this option is set and the head is not tagged it creates that stuff [20:18] its been driving me nuts. keeps hosing up my armel build [20:18] heh ... yeah its not always on [20:18] well, it is inconsistently set in the jaunty tree. fixing that now [20:18] thats very wrong... [20:46] so waht defines the source package for a package other than the Source: line in debian/control? [20:46] dpkg-gencontrol: error: source package has two conflicting values - lpia-linux-restricted-modules and linux-restricted-modules [20:48] apw: the source package name is defined in debian/changelog [20:48] apw: uh, maybe it needs to be the same as debian/control [20:49] * apw tries that [20:49] apw: looks like you have the name backwards [20:49] should be linux-restricted-modules-lpia [20:50] i didn't change that [20:50] (i don't think) [20:50] where are you getting lpia-linux-restricted-modules [20:50] ? [20:50] thats in control.stub.in [20:51] so at least i am past there [20:51] apw: not in the intrepid version, its linux-restricted-modules-lpia [20:51] wtf [20:55] rtg not in the one i have cloned here: [20:56] ~/git2/ubuntu-intrepid-lpia-lrm [20:56] apw@dm$ head -1 debian/control [20:56] Source: lpia-linux-restricted-modules [20:56] apw: zinc.canonical.com:/srv/kernel.ubuntu.com/git/ubuntu/ubuntu-intrepid-lpia-lrm.git ? [20:57] rtg@lochsa:/usr3/ubuntu/ubuntu-intrepid-lpia-lrm$ head -1 debian/control [20:57] Source: linux-restricted-modules-lpia [20:58] apw: huh, I just updated, now I have the same as you: lpia-linux-restricted-modules [20:59] apw: * Change the source package name to work around Soyuz. [20:59] apw: Steve K has been messing with it. [21:01] no wonder its all broken [21:02] apw: well, it built for Intrepid, so it shouldn't be too far off for Jaunty. [21:56] anyone happen to know if e4defrag is in jaunty yet? [21:58] it appeared to be part of the patchset for 2.6.28 but as its a userland tool I wasn't sure if it made it into jaunty === Tim-away is now known as TimStarling