[06:53] <himcesjf> Hello! Can anyone guide me on loading a module to kernel?
[07:20] <cking> himcesjf, use sudo modprobe modulename
[07:35] <smb> morning .+
[07:37] <himcesjf> cking: Yes, I'm trying to load acpi module processor and fan. After I modprobe the module, I don't see any change in dmesg to confirm whether its supported on my hardware or not
[07:40] <smb> himcesjf, Depending on what release you are, those may not be modules anymore
[07:43] <himcesjf> smb: http://paste.ubuntu.com/717632/ 
[07:46] <himcesjf> and the processor module was built into kernel 2.6.20.7-2 
[07:48] <ppisati> morning *
[07:49] <smb> So? Your list shows that there is no module for fan or processor, I am not sure what this has to do with 2.6.20... 20? 
[07:49] <smb> If you are missing /proc/acpi/processor and .../fan, could be that those finally got removed from proc and only have some place in /sys
[07:50] <himcesjf> ah, yes right. /proc is being deprecated
[07:52] <himcesjf> Then how do I enable acpi processor support in kernel?
[07:55] <smb> I should not be necessary. If the acpi bios includes the right information it will always happen automatically
[07:55] <himcesjf> ok
[08:24] <apw> 2.6.20 ?
[08:24] <apw> smb, morning
[08:25] <smb> apw, Thats what he said... :) Mornign
[08:25] <apw> thats like feisty or something
[08:26] <smb> at least pre-hardy and I cannot remember farer back (or at least I worked hard to forget)
[10:44] <ppisati_> uhm
[10:44] <ppisati_> can't build an hardy kernel (inside an hardy x86_64 chroot)
[10:44] <ppisati_> http://paste.ubuntu.com/717707/
[10:44] <ppisati_> "Could not open /home/flag/canonical/ubuntu-hardy/debian/linux-image-2.6.24-29-generic/lib/modules/2.6.24-29-generic/modules.alias at debian/tests/check-aliases line 10."
[10:44] <ppisati_> any idea?
[10:53] <apw> ppisati_, normally that specific error occurs if the version number is broken
[10:54] <ppisati_> uhm
[10:54] <apw> /home/flag/canonical/ubuntu-hardy/debian/linux-image-2.6.24-29-generic/lib/modules/
[10:54] <apw> ls that directory on the builder and see what if anything is in there
[10:54] <ppisati_> i've 6 patches on top of hardy's HEAD
[10:54] <ppisati_> i could try backing out them
[10:55] <ppisati_> but they don't touch the version number/any files in debian/*
[10:55] <apw> ls that directory on the builder and see what if anything is in there
[10:56] <apw> /home/flag/canonical/ubuntu-hardy/debian/linux-image-2.6.24-29-generic/lib/modules/
[10:56] <ppisati_> drwxr-xr-x 4 flag flag 4096 2011-10-24 12:41 2.6.24-29-generic
[10:56] <ppisati_> only this dir
[10:57] <apw> and what is in that dir
[10:57] <ppisati_> drwxr-xr-x 2 flag flag 4096 2011-10-24 12:41 initrd
[10:57] <ppisati_> drwxr-xr-x 9 flag flag 4096 2011-10-24 12:41 kernel
[10:57] <apw> so i'd say depmod may have failed
[10:57] <apw> ahhh what is your host running ?
[10:57] <apw> it is running oneiric
[10:57] <ppisati_> onerici
[10:58] <ppisati_> but i'm in a hardy-x86_64 chroot
[10:58]  * apw bets depmod is shitting self over the kernel version number, look for DEPMOD in the log
[10:58] <ogra_> geez, hardy
[10:59] <ppisati_> DEPMOD  2.6.24-29-generic
[10:59] <apw> did it error at all after that?
[10:59] <ogra_> 7me coughs because of all the dust in the channel
[10:59] <apw> ^ proof you have a .de keyboard
[11:00] <ogra_> hehe
[11:00] <ppisati_> bot at that point
[11:00] <ppisati_> it was INSALLing all the modules
[11:00] <ppisati_> s/bot/not/
[11:00] <ogra_> the uk ac100 is twice as expensive so yeah, i took the german model (now sold for 125€ here) ;)
[11:01] <apw> ppisati_, can you pastebin the whole log please
[11:05] <apw> ogra_, you and your funny money
[11:05] <ogra_> haha
[11:07] <ppisati_> apw: http://people.canonical.com/~ppisati/hardy-O.log
[11:08] <apw>   /home/flag/canonical/ubuntu-hardy is not clean, please run 'make mrproper'
[11:09] <apw> your tree is damaged, and i think its not configuring right
[11:09] <apw> you might try 'rmdir include/config' and see if that repairs that
[11:10] <apw> or if you ran make mrproper, then a git checkout -f would be needed after
[11:10] <ppisati_> apw: saw that, but i think i did 'git reset --hard HEAD' in another terminal
[11:10] <ppisati_> (that's the entire cut&paste of a screen session)
[11:13] <apw> ppisati_, ok nothing obvious to see in there.  iirc the depmod run makes the modules.alias, as it didn't make the wrong directory i think the next step is to try runing the depmod yourself
[11:13] <apw> you'll have to work out the incantation though
[11:14] <ppisati_> apw: well, compiling on tangerine now (didn't check but i hope it's not O yet)
[11:31] <ppisati_> ok, tangerine got it
[11:35] <Kano> hi apw , could you set for next rc kernels a ~rc
[11:36] <Kano> would be a good idea to change that before 3.2~rc1
[11:36] <apw> given the kernel names differ, so they don't replace each other, is there anything to be gained by that
[11:37] <Kano> why on earth does the FINAL kernel have got a libc6 depend?
[11:37] <Kano> the gain is, when you had rc kernels installed and install the final kernel, then rc kernel is on top of the kernel list
[11:37] <Kano> and the final is below every rc kernel
[11:38] <apw> Kano, well that isn't a use case we care about much, so with UDS coming up it'll not be high on my priority list
[11:38] <Kano> the ~ means that it is below
[11:38] <Kano> thats a 5 min change or less
[11:38] <Kano> but tell me why
[11:38] <Kano> libc6 (>= 2.11) now?
[11:38] <Kano> for headers
[11:38] <Kano> thats crap
[11:38] <apw> if it was that easy you'd be making your own kernels
[11:39] <Kano> i dont see a reason to compile a kernel without patches again
[11:39] <apw> you really have a way of saying things that makes me want to help
[11:39] <Kano> i can not install the headers with lenny systems now
[11:39] <Kano> with that new change
[11:40] <apw> its not something which we have changed deliberatly
[11:40] <Kano> you changed the build system?
[11:40] <apw> its something that (likely) came of changing it to build them in the right chroots
[11:40] <apw> something you asked for
[11:40] <Kano> i asked for a libc6 depend which is even wrong?
[11:41] <apw> no you asked for mainline builds for oneiric to be build in oneiric chroots
[11:41] <apw> and i suspect it is fallout from that
[11:41] <Kano> i?
[11:41] <Kano> never
[11:41] <apw> noone else ever talks to me about mainline builds
[11:41] <apw> but either way i suspect its an unintended side effect of that
[11:42] <Kano> i need em build with an older chroot
[11:42] <Kano> otherwise i can not use the headers
[11:42] <Kano> something with libc6 2.7
[11:42] <apw> it is unclear why we would have any libc deps on any headrs
[11:43] <Kano> maybe you updated the packageing code
[11:43] <Kano> like you did a while ago, there i had to hack the depends too
[11:44] <Kano> last time i had to hack this:  sed -i s/3.13/3.2/ linux-image/DEBIAN/control
[11:45] <Kano> this time it is in the headers package
[11:46] <apw> well building the images in teh right chroot is the right thing, else you can't use dkms packages with them
[11:46] <Kano> thats incorrect
[11:46] <apw> as to why we have a libc dep on headers
[11:46] <apw> define incorrect
[11:46] <Kano> you can use any newer libc6 without problems
[11:46] <Kano> thats what i did all the time
[11:46] <Kano> i used the kernels on lenny + squeeze
[11:46] <apw> it is unclear why a pure headers package would need any dep on any other pacage
[11:47] <Kano> and fglrx/nvidia/vbox always compiled correctly
[11:47] <Kano> squeeze had a much newer libc6
[11:48] <apw> loadable modules should not be built with a different compiler, that is the key constraint
[11:48] <Kano> that was a problem when switching from 2.9x to 4.0
[11:49] <Kano> but never later
[11:49] <Kano> they are compatible
[11:50] <Kano> if you use gcc 4.3 or newer it does not matter
[11:50] <Kano> absolutely never had issues because of that
[11:51] <apw> and we have, and that is our constraint, and our builds
[11:51] <apw> the libc6 dep seems spurious and i'll try and figure out where that is coming from
[11:51] <Kano> well it would not help if you remove it and build still with oneric chroot
[11:52] <apw> why so
[11:52] <Kano> well you can compile with a newer gcc but not with an older one
[11:52] <Kano> most likely because of missing symbols in older libc6
[11:53] <Kano> thats why you can use software compiled with older libc6 on a much newer libc6 but not the other way around
[11:54] <apw> but the kernel doesn't use libc, so a dependancy on it makes no sense
[11:54] <Kano> the headers do
[11:54] <Kano> the headers have got binary components
[11:54] <Kano> those can not get linked
[11:55] <Kano> when you build extra modules
[11:55] <Kano> linux-image would work everywhere, thats clear
[12:00] <apw> Kano, can you point me to a binary in that package
[12:03] <Kano> for x in $(dpkg -L linux-headers-$(uname -r)); do file $x; done|grep ELF|grep sha
[12:03] <Kano> for x in $(dpkg -L linux-headers-$(uname -r)); do file $x; done|grep ELF
[12:03] <Kano> that way
[12:06] <Kano> 19
[12:06] <Kano> shared 10
[12:28] <apw> unity is only updating my internal panel now, not bothering with my external even though it is showing the correct cursors on it
[12:29] <ppisati_> anyone with an hardy box wiliing to test a kernel?
[12:29] <smb> ppisati_, youre not doing the same thing apw was doing last week=
[12:29] <smb> ?
[12:30] <ppisati_> apw: IIRC he was doing the...
[12:30] <ppisati_> smb: ^
[12:30] <apw> CVE-2011-1548
[12:30] <ubot2> apw: The default configuration of logrotate on Debian GNU/Linux uses root privileges to process files in directories that permit non-root write access, which allows local users to conduct symlink and hard link attacks by leveraging logrotate's lack of support for untrusted directories, as demonstrated by /var/log/postgresql/. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1548)
[12:30] <ppisati_> smb: cifs/smb pwd stuff
[12:30] <apw> yeah that was the one
[12:30] <ppisati_> uhm no
[12:30] <apw> not 1548
[12:30] <ppisati_> i'm doing the
[12:30] <apw> the one you said
[12:30] <ppisati_> CVE-2011-1082
[12:30] <ubot2> ppisati_: fs/eventpoll.c in the Linux kernel before 2.6.38 places epoll file descriptors within other epoll data structures without properly checking for (1) closed loops or (2) deep chains, which allows local users to cause a denial of service (deadlock or stack memory consumption) via a crafted application that makes epoll_create and epoll_ctl system calls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1082)
[12:31] <ppisati_> i backported 2 patches, plus 4 more to ease the "porting"
[12:31] <smb> ppisati_, Ok, well anyway I can try your kernel if there is a reproducer
[12:31] <tgardner> ppisati_, that looks HW independent. you can likely use a VM for testing
[12:32] <ppisati_> yep, don't have a vm but i can roll one...
[12:38] <ppisati_> smb: no, there's no reproducer
[12:38] <ppisati_> i should look for one
[12:42] <smb> ppisati_, Having one is ideal. Or at least know what would be using epoll to see that this is still working after the changes.
[12:44] <ppisati_> smb: ok. i've a reproducer now
[13:48] <tgardner> ogasawara, did you notice 3.1 is out ?
[13:49] <ogasawara> tgardner: yep, rebasing it right now
[13:49] <tgardner> ogasawara, cool
[13:49] <ogasawara> tgardner: I mailed you some wifi cards, not sure if you've been home though?
[14:22]  * ogasawara back in 20
[14:26] <bjf> tgardner, ogra_ pointed out on friday that mvl-dove for maverick wasn't supposed to be released, it was just a plaything for NCommander
[14:27] <bjf> tgardner, i mentioned that we were still doing security patches to it regularly
[14:29] <ogra_> bjf, well, the prob we have now is that it cant be removed after release
[14:30] <ogra_> nor can we demote it to universe after release
[14:30] <ogra_> so even though it hasnt a single user (byond tobin doing his tests) we cant really drop it now
[14:36] <tgardner> ogra_, bjf: dang, I wish we'd have known this up front.
[14:36] <tgardner> oh well.
[14:36] <tgardner> ogasawara, I did receive your package
[14:36] <ogra_> tgardner, dito
[14:38] <tgardner> ogra_, its just part of the stable updates machine for now. it'll expire soon enough.
[14:38] <ogra_> another what, 12 months ?
[14:38] <ogra_> or is it only 6 ?
[14:38] <tgardner> 6 I think
[14:38] <ogra_> it burns manpower for no reason, thats what annoys me 
[14:39] <tgardner> true, but we have most of that kind of stuff scripteed
[14:40] <ogra_> k
[14:40] <ogra_> at least lucid will be EOL by end of the week :)
[14:40] <ogra_> (for arm that is)
[14:40] <tgardner> long live imx51
[14:41] <ogra_> well
[14:41] <ogra_> thats another wart 
[14:41] <ogra_> i think IS still wants imx51 security updates for the buildds until they get killed
[14:41] <ogra_> though thats a matter of IS to talk to you guys
[14:42] <tgardner> ogra_, maybe we can get 'em to purge all of the babbages when someone _finally_ releases a good ARM server
[14:42] <ogra_> well, thats another 6 months (at least)
[14:43] <tgardner> and I think thats optimistic :)
[14:44] <ogra_> i'm an optimist by design ... else i wouldnt work on arm ;)
[15:01] <tgardner> apw, how come we're getting 3 notices for mainline build v3.1 ?
[15:01] <AlanBell> hullo, I was wondering if someone can have a look at bug 614238
[15:01] <ubot2> Launchpad bug 614238 in linux "Intel Core i3 External Monitor Wavy Output" [Medium,Confirmed] https://launchpad.net/bugs/614238
[15:02] <apw> tgardner, manual rebuilds 3 is 'right'
[15:02] <AlanBell> the bug has a patch, that works, but I am not sure that the right things have been done to upstream it and get it into Ubuntu
[15:02] <tgardner> apw, ok, just wanted to make sure it wasn't a script that was running amok
[15:02] <apw> tgardner, nope its me thats amok
[15:03] <tgardner> sforshee, weren't you working on the wavy external monitor ?
[15:04] <tgardner> AlanBell, sforshee is on vacation, back tomorrow.
[15:04] <ohsix> AlanBell: is that the one where the spread spectrum is on vga outputs?
[15:05] <ohsix> from what i've heard of it theres not a lot that can be done since the clock is shared, you just need to force it off if you use vga
[15:09] <AlanBell> ohsix: not sure what the cause is, but there is a patch which fixes it perfectly
[15:10] <ohsix> it "fixes" it by disabling ssm, which is actually useful on the nonvga outputs
[15:11] <AlanBell> hmm, laptop screen and HDMI output worked fine for me
[15:53]  * ppisati_ goes out to see a new flat
[16:13] <tgardner> ogasawara, apw: tangerine.buildd:~rtg/lucid/debootstrap/debootstrap_1.0.20ubuntu1.4_all.deb for your local lucid build hosts. I've added the precise chroots on tangerine; gomeisa and tyler soon to follow.
[16:13] <ogasawara> tgardner: thanks
[16:13] <tgardner> update your kteam-tools
[17:56]  * tgardner -> lunch
[20:16] <smoser> smb, kernel on ec2 is ill (not a surprise) 
[20:16] <smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881076
[20:16] <ubot2> Launchpad bug 881076 in linux "precise kernels do not boot on ec2" [Undecided,Incomplete]
[20:50] <bjf> nice, thanks
[21:35] <bjf> jsalisbury, i think bug #558569 can be marked "Won't Fix" don't you?
[21:35] <ubot2> Launchpad bug 558569 in module-init-tools "Unable start as live cd Lucid Beta 2" [High,Fix released] https://launchpad.net/bugs/558569
[21:37] <jsalisbury> bjf, yes I would say so.  Looks like it's won't fix for Lucid, justs needs the Linux and Linux(Ubuntu) entries updated.
[21:38] <jsalisbury> bjf, may need to think about ways to expire bugs like this
[21:39] <bjf> yes, i think this one won't expire because there are two tasks 
[21:39] <jsalisbury> bjf, ahh, I see
[21:40] <bjf> jsalisbury, but i'm not sure
[21:41] <jsalisbury> bjf, Hmm, I can't mark the upstream task as wont fix since bugzilla.kernel.org is unavailable
[21:42] <jsalisbury> bjf, I guess I can just remove that task
[21:44] <bjf> jsalisbury, not sure what the policy is for that
[21:44] <jsalisbury> bjf, ok