[01:53] <cr3> hi folks, is there a way to determine whether a system supports vpro technology because I'm particularly interested in AMT support? for example, might there be something in /proc/cpuinfo that I could check?
[02:02] <stgraber> cr3: it's unlikely to be exported as a CPU flag but it might show up in the dmi (look at dmidecode). From a quick test here on two machines that have AMT support, I'm not seeing anything obvious, though I don't think I have it turned on on any of these so that might explain it
[02:16] <cr3> stgraber: ah, I was hoping it would show up even when it was turned off. I'm mostly curious about AMT potential to spare me from having to look in all the BIOS menus
[06:13] <queency> hello all i'm using ubuntu9/04 can someone direct me to install power save to my machine
[06:47] <MCR1> bryceh, RAOF, shadeslayer: Hi :) Just FYI: I've now tested 3.6-RC5 (~kernel-ppa/mainline) and SSL uploading (at least to launchpad) is still broken (did not get it to work on any of the 3.6RCs, while it works on the same system with all 3.5 versions)...
[07:00] <RAOF> MCR1: SSL uploading to launchpad is broken by the kernel?
[07:01] <MCR1> RAOF: Yes, I am pretty sure about it.
[07:02] <RAOF> That's going to be an *awesome* bug once it's found.
[07:02] <MCR1> Once I downgrade to 3.5 there are no problems anymore
[07:03] <MCR1> If I push a new branch in 3.6 for example the branch gets created on launchpad, but no data is ever pushed (empty branch) and I have to bzr break-lock it.
[07:04] <MCR1> The dialogue for entering the SSL password does not appear also...
[10:49] <caribou> quick noobie question : what needs to be added to a kernel module source code to avoid the "tainted kernel" mention ?
[10:49] <caribou> i.e. I'm writing a 10 lines module and I want to avoid tainting the kernel with it
[10:55] <amitk> caribou: what is your module's license?
[10:55] <caribou> amitk: I'd say GPLv2, it's just for testing
[10:56] <cking> MODULE_LICENSE("GPL"); is requirec
[10:56] <cking> or MODULE_LICENSE("GPL v2");
[10:56] <amitk> right
[10:58] <caribou> cking: amitk: thanks
[10:58] <caribou> cking: just trying to hack my own slab corrupting module ;)
[10:59] <amitk> caribou: so you _are_ trying to taint the kernel, only in a different way ;)
[11:00] <caribou> amitk: I'm chasing a nasty slab corruption bug, I'm trying to build a systemtap probe that will trigger when slub_debug gets enabled
[11:00] <caribou> amitk: but you're right :)
[11:09] <caribou> amitk: cking thanks
[12:04] <dileks> initramfs-tools-0.99ubuntu13.1+dileks1.debdiff: http://paste.ubuntu.com/1202471/
[12:04] <dileks> hmm, shall I add debian-bugnos
[12:07] <dileks> looks good <http://nopaste.snit.ch/165713>
[12:19] <dileks> http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git;a=commitdiff;h=71ece1498644e162e2d7271098e97d52d18ce3e2
[12:19] <dileks> http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git;a=commitdiff;h=1d6b272f9ce08d8f6f5eee56f5382f25a8a3a5ef
[13:03] <sforshee> rtg, I dunno, that's really weird
[13:04] <rtg> sforshee, I was just reading your comments. perhaps it is binutils
[13:05] <rtg> sforshee, I'm updating my local chroot to see if I can repro
[13:05] <sforshee> rtg, I did build the same source in a precise chroot and saw that there was some space between video_cards and video_cards_end
[13:05] <sforshee> rtg, but it's absolutely bizarre that you bisected to that commit
[13:06] <rtg> sforshee, I was getting a different symptom, e.g., black screen. I did see the unknown video mode thing at least once.
[13:06] <rtg> sforshee, where do you find setup.elf ?
[13:07] <sforshee> rtg, after doing build generic it's in debian/build/arch/x86/boot
[13:07] <sforshee> *build-generic
[13:07] <rtg> sforshee, ack
[13:17] <cking_> bother, just bricked a laptop
[13:20] <rtg> cking, I managed to wreck mine twice yesterday, but no bricking was involved (at least at the BIOS level)
[13:21] <cking> this one just hung, reboot, no life whatsoever
[13:21] <rtg> cking, pull the batter and reset the EC ?
[13:21] <rtg> battery*
[13:22] <cking> now on boot there is no splash and the fan spins madly and that's it.  Can't pull the battery, it's a ultrabook, need to open it up
[13:22]  * cking rummages around for some suitable tools
[13:25] <hallyn> stgraber: have you heard any updates in teh last two days about the netns bug?
[13:27] <cking> bah, intel primier support, punch me now and get the pain over and done with
[13:30] <stgraber> hallyn: nope. Last thing I heard was that 3.6 "might" have a fix for it but cooloney still had to figure out which
[13:34] <hallyn> ah, thx, that's the nick i was looking for :)
[13:35] <rtg> rtg@salmon:~/ubuntu/ubuntu-quantal$ readelf -s ./debian/build/build-generic/arch/x86/boot/setup.elf|grep video_card
[13:35] <rtg>    138: 00003658     0 NOTYPE  GLOBAL DEFAULT   12 video_cards
[13:35] <rtg>    151: 00003658     0 NOTYPE  GLOBAL DEFAULT   12 video_cards_end
[13:35] <hallyn> stgraber: i noticed it wasn't on the kernel hotlist...  but i guess that's automatically defined
[13:36] <rtg> sforshee, ^^ this is with current toolchain building Ubuntu-3.5.0-13.14
[13:36] <rtg> sforshee, gonna build with precise just to be sure
[13:39] <sforshee> rtg, that looks about like what I got. As long as I'm understanding the code and linker scripts correctly that means the video_cards array is empty.
[13:40] <rtg> sforshee, that certainly would appear to be the case. I'll know for sure after compiling against precise ()which will be done in a few minutes)
[13:42] <sforshee> rtg, The array being empty is the only thing that makes sense to me anyway. We should end up with a minimum of 1 usable resolution if video_vga is included in video_cards[].
[13:44] <rtg> sforshee, with Precise tool chain:
[13:44] <rtg> rtg@salmon:~/ubuntu/ubuntu-quantal$ readelf -s ./debian/build/build-generic/arch/x86/boot/setup.elf|grep video_card
[13:44] <rtg>    160: 000042ec     0 NOTYPE  GLOBAL DEFAULT   12 video_cards
[13:44] <rtg>    173: 00004340     0 NOTYPE  GLOBAL DEFAULT   12 video_cards_end
[13:44] <sforshee> rtg, yep, now there's something there
[13:44] <rtg> sforshee, so next lemme back out the recent binutils update in my quantal chroot
[13:54] <bjf> jjohansen: bug 1050430 - i'm just now getting back to this
[13:54] <ubot2`> Launchpad bug 1050430 in apparmor "QRT regression test failure on quantal" [Undecided,New] https://launchpad.net/bugs/1050430
[14:22] <rtg> doko, bug #1049650 might be a tool chain issue. how can I build gcc-4.7 4.7.1-7ubuntu1 from source ? Is there a bzr branch that I can pull from ?
[14:22] <ubot2`> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,In progress] https://launchpad.net/bugs/1049650
[14:26] <doko> rtg, likely. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687448 popped up as well. can you reproduce this? I'll provide you with (some) toolchain builds
[14:26] <ubot2`> Debian bug 687448 in gcc-4.7 "Kernel compiled with 4.7.1-8 fails to boot" [Normal,Open]
[14:27] <rtg> doko, I can tell just from the build whether the kernel will work. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1049650/comments/6
[14:27] <ubot2`> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,In progress]
[14:29] <doko> rtg, could you check with https://launchpad.net/ubuntu/quantal/+source/binutils/2.22.90.20120816-2ubuntu1 ?
[14:30] <rtg> doko, gimme a bit
[14:47] <rtg> doko, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1049650/comments/8 for build results. Its definitely different.
[14:47] <ubot2`> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,In progress]
[14:48] <rtg> and likely better.
[14:56] <rtg> doko, a kernel built with that binutils actually boots.
[15:27] <jjohansen> bjf: thanks
[15:35] <bjf> jjohansen: if you need more, just ask. apport-collect not working on that system. it's a lab system and i can just let you have at it if you like
[15:36] <jjohansen> bjf: okay, I'll get back to you on that
[16:07] <orated> Hello! Where can I find information related to sound and webcam? Like how one can interface GPIO from /sys. Is there a similar way to fetch data and interact for
[16:08] <orated> webcams and sound card.
[17:27] <jsalisbury> rtg, Are you familiar with what firmware should be included on the mini.iso?  There is a bug talking about missing wireless firmware: bug 1047092
[17:27] <ubot2> Launchpad bug 1047092 in linux "Mini.iso doesn't load wireless drivers" [Medium,Confirmed] https://launchpad.net/bugs/1047092
[17:29] <rtg> jsalisbury, this seems to be more of an installer issue if /lib/firmware is missing
[17:29] <jsalisbury> rtg, ok that makes sense.
[17:35] <rtg> arges, you around ?
[17:35] <arges> rtg, yes
[17:35] <rtg> arges, working on the eglibs stuff. do you have to install it after installing the xen hypervisor ?
[17:35] <rtg> eglibc*
[17:36] <arges> rtg, you should be able to reproduce with just xen according to the bug
[17:36] <rtg> bug #956051
[17:36] <ubot2> Launchpad bug 956051 in eglibc "libc6 crash while running 'xm'" [High,Fix committed] https://launchpad.net/bugs/956051
[17:37] <rtg> arges, oh, it reproduces just fine
[17:37] <arges> rtg, ok good
[17:37] <rtg> xm[1324] trap invalid opcode ip:7f5273faa5fc sp:7fff1bea09d0 error:0 in libm-2.15.so[7f5273f68000+f9000]
[17:37] <arges> rtg, then we can try the test package ... let me get the link
[17:37] <arges> rtg, https://launchpad.net/~christopherarges/+archive/ppa-test/+sourcepub/2629659/+listing-archive-extra
[17:39] <rtg> arges, shall I just add that PPA an then update ?
[17:39] <arges> rtg, umm
[17:39] <arges> rtg, just realized there are a ton of debs
[17:40] <rtg> yeah, which uis why its easier to just update
[17:40] <arges> rtg,i have a bunch of stuff in this test ppa... let me clean it up
[17:40] <rtg> arges, quota is the only other Precise package
[17:41] <arges> rtg, the problem is we need to test the lucid package... so not sure if PPAs will let you add and install the other version
[17:42] <rtg> ah, lucid
[17:42] <rtg> arges, I have a lucid chroot installed. couldn't get the lucid kernel to boot, so installed precise instead
[17:43] <arges> rtg, we could try installing this version over the precise eglibc... (although that might be pretty risky)
[17:43] <rtg> arges, yeah, lemme try the chroot first
[17:46] <arges> rtg, cool. you should be able to add the PPA that way since eglibc and libhugetlbfs are hte only packages there. so should be safe enough
[17:46] <rtg> arges, OK, lemme make sure I can repro the problem under the lucid chroot. it requires xen-utils-common
[17:52] <rtg> arges, hmm. xen-utils-common did not appear until oneiric. how can you repro this issue under lucid ?
[17:54] <arges> rtg, btw here is the other related bug
[17:54] <arges> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/979003
[17:54] <ubot2> Launchpad bug 979003 in eglibc "libc incorrectly detects AVX support" [High,Confirmed]
[17:54] <arges> rtg, looking for another way to reproduce
[17:55] <arges> rtg, ok getting more info one second
[17:55] <rtg> arges, ack
[18:06] <vanhoof> rtg: natty EOL's real soon now, right?
[18:07] <bjf> vanhoof: yes, i'm loading the gun as we speak
[18:07] <vanhoof> bjf: fire in the hole!
[18:07] <bjf> vanhoof: the *last* kernel is in the pipe right now
[18:08] <vanhoof> bjf: cool, just saw a bug come across re: natty and I was pretty sure we're really close to EOL :)
[18:09] <bjf> vanhoof: the door is closed and locked
[18:09] <vanhoof> bjf: you set a chair behind the door too, yeah? :)
[18:10] <bjf> vanhoof: yup and booby trapped
[18:11] <vanhoof> bjf: lol
[18:11] <cking>  I wil miss natty. not
[18:12] <cking> bjf, what will the stable team do with all that extra time now natty is not being maintained? ;-)
[18:13] <bjf> cking: quantal
[18:13] <cking> nngggg
[18:13] <bjf> cking: when one drops another is picked up
[18:14] <cking> its like burying one's  grandma and getting a baby in one go
[18:17] <bjf> cking, the king is dead, long live the king (or queen)
[18:46] <orated> Hello! Where can I find information related to sound and webcam? Like how one can interface GPIO from /sys. Is there a similar way to fetch data and interact with sound card/webcam?
[19:00]  * cking -> EOD (literally)
[19:11] <alexbligh1> Is there a /maintained/ backport of the Precise kernel to Lucid? (a la lts-backports)
[19:12] <vanhoof> alexbligh1: dont believe so, no
[19:16] <alexbligh1> vanhoof, ok, that's a pity. Are the lts-backports kernels simply the Oneiric (or whatever) sources within a Lucid build environment? IE if I set up something to sync the sources automatically and publish a repo, would that be it? Or is it more complex than that?
[19:17] <alexbligh1> (OTOH may be I should just take all the excuses I can find to u/g everything to Precise)
[19:17] <vanhoof> alexbligh1: I'm not entirely sure if that's how they're formally built but I have done similar with success in the past
[19:17] <alexbligh1> vanhoof, ok, thanks, useful.