[01:19] <rsalveti> cooloney: can you check bug 960770?
[01:19] <ubot2`> Launchpad bug 960770 in dkms "Packages requiring dkms at Pandaboard (omap 4) will also pull linux-headers-generic because current dkms dependencies" [Medium,New] https://launchpad.net/bugs/960770
[01:19] <cooloney> rsalveti: cool, let me take a look
[01:25] <rsalveti> cooloney: thanks :-)
[01:31] <rsalveti> cooloney: also, perf is currently broken on omap4
[01:32] <rsalveti> if you want to take a look on that :-)
[01:54] <cooloney> rsalveti: i remember i fixed linux-tools package for ti-omap4 before, but haven't try it for a long time
[08:03]  * apw yawns
[08:04]  * smb waves
[08:20] <cking> yawn too
[08:23] <_ruben> +3
[08:23] <dholbach> hiya
[08:23] <dholbach> can anyone comment on http://fridge.ubuntu.com/2012/02/23/ubuntu-12-04-development-update-15/comment-page-1/#comment-4633?
[08:30] <apw> they are asking about a patch in a comment on a blog post and expecting that to get to the right people ?
[08:31] <diwic> apw, obviously it seems to succeed? :-)
[08:33] <apw> just making me grumpy
[08:34] <smb> +1
[08:34] <diwic> we've all been newbies
[08:34] <apw> smb, are you able to sync the stable queue ?
[08:34] <smb> apw, not this morning apparently
[08:35] <apw> bah that makes a cogent answer hard to make, i want to know if his patch is in there
[08:35] <smb> apw, give me a sec
[08:36] <smb> apw, I only found a mail in the archive discussing the addition of the stable cc, but not yet the announcement to have it queued
[08:37] <apw> smb, ok ... thanks ... now ... why can't i pull this thing ... kernel.org OI
[08:37] <smb> apw, Linus tree still works...
[08:37] <smb> But neither linux-stable nor linux-stable-queue do
[08:38] <apw> ok both work for me, but linus is zippy and stable is clears swimming in treacle
[08:38] <apw> there was a suggestion that linus might get its own backend server for security separation
[08:39] <smb> apw, Hm, and it does not look like the patch has cc: stable added
[08:42] <apw> thats something, as you say its not in there yet
[08:42] <smb> apw, Well as they seem to have "forgot" the cc: stable... not sure it will
[08:43] <smb> Man, kernel.org really is unpredictable right now
[08:44] <apw> smb, perhaps one of the servers in the rotation is sick or something
[08:45] <smb> apw, Or rebooting. When you first asked I got the connection reset, now a fetch just is stuck forever as it seems
[08:48] <smb> Wow, 5minutes later it succeeds...
[08:49] <apw> that is officially not rapid
[08:49] <smb> spring tiredness ...
[08:59] <smb> moco time...
[09:01] <apw> dholbach, http://fridge.ubuntu.com/2012/02/23/ubuntu-12-04-development-update-15/comment-page-1/#comment-4642 have replied
[09:01] <dholbach> apw, thanks a bunch - pushed it through the queue
[09:43]  * apw reboots to get new shineies
[09:45] <cking> apw, crash n burn
[09:53] <Daviey> brendand: hey.. so bug 960311 .. you are seeing it on every release?
[09:53] <ubot2`> Launchpad bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [High,Incomplete] https://launchpad.net/bugs/960311
[09:53] <brendand> Daviey, so far i tried with Oneiric and Precise (beta1 kernel)
[09:53] <Daviey> brendand: Did this hardware never work.. or has something changed on the server?
[09:54] <brendand> Daviey, the hardware worked last on monday
[09:54] <brendand> Daviey, i *suspect* a firmware upgrade was done, but i still didn't get a confirmation from the lab engineer
[09:54] <Daviey> brendand: has anything changed in the hardware since then.. bios flash?
[09:54] <Daviey> ah
[09:55] <Daviey> brendand: How soon can you get confirmation ?
[09:55]  * cking wonders if a data base of firmware versions per machine is being kept so one can look this up easily
[09:56] <Daviey> cking: a validation one, or by those looking after servers?
[09:57] <Daviey> I always thought, bios flashing was only done if you encounter issues with the current bios.. I learnt recently that people seem to be doing as a matter of course.
[09:57] <brendand> cking, would be a good idea...
[09:57] <brendand> Daviey, another thing is this:
[09:57] <brendand> failed dmesg:
[09:57] <cking> brendand, because BIOS is firmware and firmware changes effectively make the machine behave differently, so it *should* be tracked
[09:57] <Daviey> (smb, are you following this?)
[09:58] <brendand> eth0: no IPv6 routers present
[09:58] <brendand> earlier log, no fail
[09:58] <brendand> that message doesn't appear
[09:58] <Daviey> brendand: no, that is fine.. it just means it's an IPv4 only network
[09:58] <smb> Daviey, No I am drinking coffee.. :-P
[09:58] <Daviey> smb: And you didn't make one for the rest of us?!
[09:58] <brendand> Daviey - but that wasn't there before?
[09:59] <brendand> Daviey, with the same image so nothing different software side
[09:59] <brendand> just one day and the lack of that message
[09:59] <brendand> and there have *definitely* been lab config changes
[09:59] <brendand> that i know for sure
[09:59] <cking> apw, we can hear you but you can't seem to hear us
[10:00] <Daviey> brendand: I think this bug is blocked on knowing what has changed.
[10:03] <smb> Daviey, yes, I hope my comment there was clear enough. 
[10:03] <apw> diwic, just had to kill pulseaudio again to get output to work in mumble
[10:04] <apw> after a fresh reboot ... it seemed to lose its mind when i asked the mic to change from one channel to another
[10:04] <apw> diwic, and after that output no longer worked
[10:04] <smb> Daviey, Since the message in the dmesg points to firmware and there has actually been a bios/fw update, I really would rahter expect a hw failure
[10:04] <brendand> Daviey, email sent to lab engineer. cc'd you and smb
[10:05] <diwic> apw, could you *not* kill pulseaudio the next time it happens, so the faulty state could be examined better?
[10:05] <apw> diwic, sure
[10:05] <apw> i was in a hurry to get on mumble today
[10:05] <diwic> apw, unless you have pulseaudio already on verbose log mode in syslog?
[10:06] <brendand> smb - bear in mind this is not a black and white case of the card never working. it still works to allow the system to pxe install and is accesible for a few minutes after boot
[10:06] <apw> diwic, not on tnis machine indeed
[10:06] <brendand> smb - you'll notice those errors come several minutes after boot
[10:06] <diwic> apw, ok.
[10:07] <smb> brendand, I would bear that in mind if that was written down in the bug report
[10:07] <brendand> smb - i can state that explicitly, of course. dmesg already says pretty much the same thing
[10:10] <smb> brendand, It does not tell you about pxe boot explicitely and it only shows me a message right after setting up interrupts for it about a fw issue. It won't tell anything about the bios update or anything else. And that wasn't in the initial report either. 
[10:11] <brendand> smb - i don't know if there was a bios update, that's the problem
[10:12] <amitk> jk-: common clock is finally going in, congratulations and thanks for starting the effort!
[10:14] <smb> brendand, Well, what I am trying to say is that even the possibility of it mentioned is something that should be in the report. Or whether this is a machine that used to work or... context is important. We do not own working crystal balls
[10:15] <brendand> smb - i know. i am adding details as i obtain them. sorry for not mentioning the pxe install in the first instance. the other things i have just been finding out today, or have yet to find out
[10:16] <brendand> smb - btw, can you tell me what the current development kernel version is? to make sure i get the right one
[10:17] <smb> brendand, Just feeling that the order of things is a bit out of order. First to gather info , then mark the bug critical would be better than the other way round. ;)
[10:17]  * ppisati -> brb
[10:17] <smb> For 3.2 I think we uploaded yesterday...
[10:18] <apw> smb, sitting in the new queue now across the board
[10:18] <smb> ok so 3.2.0-19.30 is latest as of now
[10:21] <brendand> smb - well, *i* didn't set the importance :) anyway, i'm focusing right now on completing the picture according to all the requests so hopefully all the info will be there soon
[10:28] <jk-> amitk: woooot :)
[10:30] <amitk> jk-: those 6-7 patches have taken 2 years I think :)
[10:31] <apw> amitk, thats pretty quick :/
[10:32] <amitk> apw: if you see the thread, there are still arguments (after the maintainer accepting them) to mark them EXPERIMENTAL
[10:32] <amitk> it's been a saga
[10:32] <apw> heh ... never ends does it
[10:32] <amitk> even the popcorn went stale a long time ago
[10:32] <apw> unopened popcorn would have gone off by now
[10:33] <amitk> jk-: beers on me if you decide to make the trip to Hong Kong
[10:43] <apw> ppisati, do your panda boards boot on the precise images ?
[10:47] <apw> ppisati, i have reports that they do not, and wondering if you are seeing issues
[11:07] <ppisati> apw: last time i tried yes, they worked
[11:07] <ppisati> apw: any particular image or just the last one?
[11:12] <apw> the compainant is implying that they have not worked for some time, so if you have booted someting in the last week that is interesting, is that !XM, XM or both you have done?
[11:12] <apw> oh that is beagle isn't it
[11:12] <apw> ppisati, ^^
[11:12] <ppisati> yep
[11:13] <ppisati> uhm
[11:13] <ppisati> i think i tested it last week
[11:13] <ppisati> iirc
[11:13] <ppisati> i mean, omap3 (beagle, beagle xm)
[11:13] <ppisati> while i use panda eveyday
[11:14] <ppisati> so, is it beagle or panda? omap3 or omap4?
[11:14] <apw> its panda i am told, so panda you tested in the last 24 hours and it works
[11:15] <ppisati> definitely
[11:15] <ppisati> i'm using latest kernel i released
[11:15] <ppisati> but i'm downloading latest preinstalled image just to see
[11:16] <apw> ppisati, let me know ... thanks
[11:18] <apw> ppisati, he has a 'rev 1A pandaboard' is that older than yours, do you have one?
[11:19] <ppisati> apw: same here, rev A1
[11:20] <apw> A1 or 1A
[11:20] <ppisati> sticker on the back of my board says rev A1
[11:20] <ppisati> did he use the daily preinstalled image?
[11:20] <apw> yep checking if his is 1A or he typo'd it
[11:21] <apw> ok its A1
[11:31] <apw> ppisati, if it works for you, could you also paste the URL for the working image you used
[11:33] <ppisati> yep
[11:33] <ppisati> dd takes ages...
[11:34] <apw> sd cards are soooo fast
[11:39] <ppisati> apw: works here, i'm in the installer
[11:39] <ppisati> apw: let me finish the installation
[11:39] <apw> ppisati, thanks
[11:41] <ppisati> ah
[11:41] <ppisati> a new installer! :)
[11:41] <ppisati> we can choose a pic now
[11:41] <ppisati> or even take one
[11:42] <apw> shiney, yeah i think i saw that somewhere, i like the burning match
[11:55] <ppisati> http://cdimage.ubuntu.com/daily-preinstalled/current/precise-preinstalled-desktop-armhf+omap4.img.gz
[11:56] <ppisati> zcat Downloads/precise-preinstalled-desktop-armhf+omap4.img.gz | sudo dd of=/dev/sdc bs=4M
[11:56] <ppisati> put the resulting sd card in the panda sd slot,  power the board and follow the installation procedure
[11:56] <ppisati> apw: ^^
[11:57] <ppisati> of course, 'of=/dev/sdc' is system dependent (i don't want to wipe his system)
[12:10] <apw> yep :)
[12:16] <Daviey> ppisati: yes you do :)
[12:35] <apw> tgardner, can you hear us ?
[12:36] <tgardner> fu576`3ing pulse
[12:39] <ericm|ubuntu> diwic, are you still on mumble? I seems to be dropped and not succeeded in connecting so far
[12:39] <diwic> ericm|ubuntu, meeting has ended, sorry
[12:39] <ericm|ubuntu> diwic, due to connection problem?
[12:40] <diwic> ericm|ubuntu, we figured you were about to say something evil about the government and they proactively cut you off
[12:40] <ericm|ubuntu> diwic, yeah I was about to
[12:40] <ericm|ubuntu> diwic, but how does the great firewall predicts that?
[12:40] <diwic> ericm|ubuntu, it is very intelligent
[12:41] <diwic> ericm|ubuntu, the meeting ended when the few of us who were there had said what we were supposed to say
[12:41] <ericm|ubuntu> diwic, really impressed by the party's cutting edge technology
[12:41] <ericm|ubuntu> diwic, the rest just cannot get on again?
[12:41] <ericm|ubuntu> diwic, just want to make sure it's not happening to me _only_
[12:42] <diwic> ericm|ubuntu, only you and a16g had connection problems, for the others it was fine I believe
[12:43] <ericm|ubuntu> diwic, sounds like a connection problem behind the great firewall
[12:45] <apw> glxinfo -l | grep GL_MAX_TEXTURE_SIZE
[12:46] <tgardner> apw, GL_MAX_TEXTURE_SIZE = 8192
[13:06] <ppisati> a new kernel is baking, in the mean time i'm out for a bit
[13:20] <tgardner> ppisati, have you seen bug #961133 ?
[13:20] <ubot2`> Launchpad bug 961133 in linux "Ubuntu Desktop ARM Images do not boot on my Pandaboard" [Undecided,Incomplete] https://launchpad.net/bugs/961133
[13:29] <tgardner> ogasawara, gomeisa arm* chroots appear to be working again.
[13:29] <ogasawara> tgardner: cool, what changed?
[13:29] <tgardner> qemu-static AFAICT
[13:29] <tgardner> looks like I still need to twiddle with armhf, nut armel is working
[13:29] <tgardner> *but
[13:38] <ppisati> tgardner: i think that's what apw told me earlier this morning
[13:39] <tgardner> ppisati, ok
[13:39] <ppisati> tgardner: i tested today's image and it's working ok on my panda
[13:39] <ppisati> btw
[13:39] <tgardner> ppisati, I noticed he's got an A1
[13:39] <ppisati> at least on tangerine, armhf chroot kind-of work
[13:39] <tgardner> would that make a difference ?
[13:39] <ppisati> tgardner: yes and no, but i got an A1 too and it's working
[13:56]  * cking reboots
[14:02] <tgardner> ogasawara, I'm dribbling ABI bumper cruft into precise master-next
[14:02] <ogasawara> tgardner: ack
[14:03] <tgardner> ogasawara, so no need to startnewrelease, etc
[14:31] <vanhoof> anyone know if it's possible to create a config idential to what I see in /boot/config-3.2.0-1409-omap4 from git?  Been playing w/ fdr genconfigs/genportconfigs as well as splitconfigs.pl but I must be doing something wrong, I always end up with a common omap config
[14:33] <tgardner> vanhoof, our config algorithm is a many to one relationship, so its hard to go backwards
[14:34] <ogasawara> vanhoof: which branch are you in?
[14:38] <vanhoof> ogasawara: the wrong one :)
[14:38] <vanhoof> ogasawara: ikepanhc got me hooked up
[14:39] <ikepanhc> :)
[14:39] <vanhoof> after a checkout of the right branch, i'm all set after fdr clean..genconfigs
[14:41] <cking> rtg, you may also like to try http://www.piware.de/2012/02/power-usage-report-find-power-drain-causes/
[14:45] <apw> ppisati, are there jumpers on your A1, if so perhaps you could enumerate your settings
[14:45] <apw> (in that bug(
[14:45]  * ogasawara back in 20
[14:46] <apw> vanhoof, and yes fdr clean; fdr genconfigs would be the approved way to get the configs out
[15:09] <ppisati> sometimes i don't understand git rebase...
[15:09] <ppisati> apw: panda is jumperless
[15:10] <apw> ppisati, git rebase> why whats it done
[15:10] <apw> ppisati, panda> ahh ok, then not that then
[15:11] <ppisati> vanhoof: export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linux-gnueabihf-; fakeroot debian/rules clean prepare-omap4
[15:11] <ppisati> vanhoof: in ti-omap4 branch (git checkout ti-omap4 from an ubuntu-precise git tree)
[15:12] <ppisati> apw: well, it's reapplying patches i din't expect should be reapplied
[15:12] <apw> ppisati, you rebasing against a rebased tree?
[15:13] <ppisati> apw: yes
[15:13] <ppisati> apw: P/omap4 on P/master
[15:13] <apw> ppisati, and are you telling it where your base is ?
[15:13] <ogra_> my panda jumps if i hit the table really hard
[15:13] <apw> as it cannot find the bottom of the rebase correctly in that situation
[15:13] <ppisati> apw: good point, but i never had to
[15:14] <ppisati> apw: ok wait
[15:14] <kees> okay, I have a git tree based on 3.3, and I've got the precise tree. is there a sane way to pull a chunk of patches off the top of the 3.3 tree onto the precise tree without doing per-commit cherry-picks?
[15:14] <apw> ppisati, yeah and it'll probabally work mostly as long as there arn't any commits dropped in the original master
[15:14] <ogasawara> kees: you can cherry-pick a range of commits now
[15:14] <ppisati> apw: let's say you are in topic branch created from master
[15:14] <kees> ogasawara: oh! that's much better
[15:14] <apw> but the most reliable way is to use the rebase --onto origin/master-next old-master
[15:14] <apw> form of re
[15:14] <ppisati> apw: git co topic; git rebase master
[15:14] <apw> rebase
[15:14] <ogasawara> kees: I know!  just found that out a week or so ago.
[15:15] <ppisati> apw: and it almost immediately complain about a clashing commit
[15:15] <apw> ppisati, that is valid _if_ master is not a rebased branch
[15:15] <apw> ppisati, as in P it still is you need to use: git rebase --onto master oldmaster
[15:16] <apw> where oldmaster is where you last were rebased to, or the commit before your first one
[15:16] <ppisati> apw: you go look at your actual tree just to notice that is different from master (while i expect the first thing it does is to kind of format-patch the pile of patches not present in master, git reset --hard origin/master and then apply all of the patches one by one)
[15:16] <apw> git cannot work out the correct base point in your case till P releases, then we stop rebasing master and life is fine
[15:17] <ppisati> fine, i'll do
[15:17] <apw> and that is what it does, but it does it by working out where the previous common commit is between the old and new branches, and using that base to lift all the patches
[15:17] <apw> as wehave rebased too the common merge point is back on mainline somwhere and so you try and pick up the whole of leanns stuff too, fail
[15:17] <ppisati> so according to merge-base i should be in Linux-3.2.9 but i'm not there either
[15:18] <ppisati> yep, i figured that out
[15:18] <apw> what does merge-base say
[15:18] <ppisati> Linux-3.2.9
[15:18] <ppisati> so it picks all the stuff from there on (almost)
[15:18] <ppisati> ok
[15:18] <apw> yep, it can detect some identicle commits are the same and drop them
[15:18] <apw> but its not very easy and tends to go pop
[15:19] <ppisati> i got it while talking
[15:19] <ppisati> the funny thing is that we had these apparmor commit before
[15:19] <apw> anyhow if your base is a rebase tree then --onto is the only sane way to use it
[15:19] <ppisati> these where dropped
[15:19] <ppisati> later reapplied (last kernel)
[15:20] <ppisati> ah, nevermind
[15:21] <apw> ppisati, we are dropping and readding apparmor en-toto so that the patches can be updated to match upstream exactly to make maintenance of the result easier
[15:21] <ppisati> right
[15:31] <GrueMaster> ppisati: Just fyi, I have been seeing strange lockups on the pandaES with the desktop image.  I'm trying to capture some log output, but so far unsuccessful.   System has to sit for a long while (this particular try has run since Monday evening).
[15:32] <GrueMaster> Other community members have seen it also on #ubuntu-arm.
[15:33] <ppisati> GrueMaster: are you using the sgx driver?
[15:33] <ppisati> GrueMaster: if yes, try to uninstall it
[15:33] <GrueMaster> No.  Desktop image from 20120319.  No updates, fresh image.
[15:33] <ppisati> k
[15:35] <GrueMaster> I do not see it on server, which leads me to believe it may be kernel/Xorg related.  I saw something similar during Natty(?) where the system would lose the monitor during sleep and hang as a result, but it would at least spew stuff in the log.  This is a hard lock (solid LED instead of heartbeat).
[15:38] <GrueMaster> I enabled serial console on this image in the hopes of capturing something, but I don't have anything on the serial console post Upstart.
[15:39] <ppisati> that reminds me i should expense an ES board
[15:39] <ogra_> ++
[15:41] <ppisati> ogra_: you, stop bumpinmg your board! :)
[15:42] <ogra_> hehe
[15:49] <GrueMaster> ppisati: Rebooted and looking for residue in the logs.  I am seeing a lot of spamming (every ~1.5 sec) from the kernel: ti_hdmi_4xxx_detect: by detect line: 1 (1 == connected)
[15:49] <ogra_> i have that too here 
[15:50] <ogra_> doesnt kill the board for me though
[15:52] <GrueMaster> Yea, I see it on all systems, including the headless ones.
[16:01] <ppisati> GrueMaster: i'll kill it in the next update
[16:01] <GrueMaster> k, thanks.
[16:02] <apw> ogasawara, so that EDID patch ... you might want to hold fire on reading it right now ... seems upstream now has a different way ... BAH ... i find out 30s after I sent it
[16:03] <ogasawara> apw: ack
[16:03] <smb> lamont, Ok, just updated the bug with test kernel location. Now hopefully you see some magic "Dropped by" messages in dmesg ...
[16:05] <tgardner> apw, too late. I've already been polluted.
[16:16] <sforshee> tgardner, ogasawara: the apple-gmux driver that's landing upstream has a couple of changes from what we're carrying in precise. I'd like to update precise -- would you prefer patches on top of our sauce patch or replacing it with the patches headed upstream?
[16:16] <ogasawara> sforshee: I prefer to replace with what's heading upstream
[16:17] <sforshee> ogasawara, ack
[16:22] <lamont> smb: I'll upgrade later today and see what we see
[16:22] <smb> lamont, ack
[16:31]  * ppisati -> disappear for a bit
[16:36] <vindex> hi
[16:36] <vindex> has anybody used perf successfully on ubuntu?
[16:36] <vindex> im having trouble getting a custom vanilla kernel compiled with perf properly working
[16:36] <vindex> 3.2.10
[16:36] <vindex> (vm guest)
[16:37] <apw> vindex, yes i have used basic perf on ubuntu kernels
[16:37] <vindex> apw: im experiencing a "vmlinux symtab| mismatch, and after stracing the process it never opens a vmlinux image, only kallsyms
[16:37] <vindex> the kernel has proper perf support compiled in, dbg symbols and other stuff
[16:38] <vindex> (im doing kernel development)
[16:38] <apw> hmm never seens that, though we 
[16:38] <apw> we build perf with the kernel when we build it
[16:38] <apw> as it is in theory build differently based on the kernel
[16:38] <vindex> well, ive done make oldconfig, all/modules/bzimage, modules instal, install, boot
[16:39] <vindex> and then cd tools/perf make
[16:39] <vindex> yes, it uses kernel sources / headers directly so it is influenced
[16:39] <apw> then that sounds reasonable faximily of what our packaging does, so i'd not expect issues indeed
[16:39] <tgardner> vindex, is what you're doing work on a stock Ubuntu kernel ?
[16:39] <vindex> thats why im quite pissed at this stage to have issues
[16:39] <apw> other than saying it seems to work ok without our packages, i am not sure what the issue is
[16:40] <vindex> tgardner: it is applicable, but i like to work on git vanilla srcs first
[16:40] <vindex> since i develop for the kernel, not ubuntu. ubuntu is the platform i use for development, and the patches i work on apply fine to ubuntu kernels
[16:40] <vindex> but it is far from being the only audience i target
[16:40] <apw> vindex, yep ... but no we've not seen that
[16:41] <vindex> vmlinux symtab matches kallsyms: failed
[16:41] <vindex> thats the error, nothing obvious when i try to see what might fail
[16:41] <vindex> all open() calls seem successful
[16:42] <vindex> how is linux-image-tools built for each kernel?
[16:43] <apw> vindex basically the way you indicate, and they seem to work here
[16:43] <vindex> i mean how could i replicate the pkg from vanilla sources? it doesnt seem like a make-kpkg target
[16:44] <vindex> where does perf read the vmlinux file from normally?
[16:44] <apw> /boot i assume as thats the only one in place
[16:45] <apw> the master branches in our git repos represent the raw source we use, building that package drops the linux-tools package
[16:46] <vindex> is there any backport/testing pkg for 3.2?
[16:46] <vindex> perhaps i could use linux-tools from those
[16:47] <apw> there are 3.2.12 ish based kernels in the archive for precise
[16:47] <apw> we only build tools in the official ubuntu builds
[16:50] <vindex> seems like at least the ubuntu perf exec looks for vmlinux in /boot
[16:57] <vindex> vanilla doesnt
[16:57] <vindex> weird.
[18:14] <ogasawara> bjf: I'm looking at http://people.canonical.com/~kernel/reports/_precise-open-bugs_.html and am just curious how it determines which bugs to put on there?
[18:14] <ogasawara> bjf: more specifically I guess I'm curious how bug 936552 is still managing to show up there
[18:14] <ubot2`> Launchpad bug 936552 in xserver-xorg-input-synaptics "MacBookAir 4,1 trackpad does not work with evdev/multitouch driver" [Medium,Confirmed] https://launchpad.net/bugs/936552
[18:15] <ogasawara> bjf: is it the kernel-da-key tag?
[18:16] <bjf> looking
[18:20] <bjf> ogasawara: it shouldn't be, i'll look into it
[18:20] <ogasawara> bjf: ack
[19:18] <kees> ogasawara: karblewy, pull request for seccomp delivered!
[19:18] <ogasawara> kees: thanks!
[19:18] <kees> it's huuuuge :)
[19:19] <ogasawara> kees: sounds ominous
[19:21] <kees>  39 files changed, 1660 insertions(+), 74 deletions(-)
[19:21] <kees> it's relatively isolated, as it turns out, but it's still big.
[19:22] <kees> anyway, the Chrome security team was really hoping they could see it in beta 2, so I cranked it out today. Upstream seems pretty settled on everything, so I figure the day before beta 2 freeze is about as late as I can stand. :)
[19:50] <apw> kees, i susect you have missed the boat, as the kernel takes 2 days to get done
[19:58] <kees> apw: noooo
[19:58] <kees> apw: that sucks -- the freeze is tomorrow! :P
[20:30]  * tgardner -> EOD
[20:43] <kees> ogasawara: so, is it likely that seccomp will see beta 2?
[20:43] <ogasawara> kees: what time is freeze tomorrow?
[20:44] <kees> ogasawara: I have no idea :P
[20:44]  * kees asks in #u-release
[20:44] <ogasawara> kees: I'm going to assume it's an ABI bumper in which case I'm not sure we could make the freeze deadline
[20:45] <ogasawara> kees: so we likely would need to get a freeze exception
[20:45] <ogasawara> kees: which probably wouldn't be too painful if we give them a heads up
[20:45] <kees> ogasawara: 2100 UTC
[20:45]  * ogasawara checks what time it is now
[20:45] <kees> 20:45 UTC, so just over 24 hrs from now
[21:23] <ogasawara> commit 8e8079f9e951ef1921b0de648568ea4b10c38d8b
[21:23] <ogasawara> Author: Andy Lutomirski <luto@amacapital.net>
[21:23] <ogasawara> Date:   Mon Jan 30 08:17:26 2012 -0800
[21:23] <ogasawara>     UBUNTU: SAUCE: SECCOMP: Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
[21:23] <ogasawara>     
[21:23] <ogasawara>     With this set, a lot of dangerous operations (chroot, unshare, etc)
[21:23] <ogasawara>     become a lot less dangerous because there is no possibility of
[21:23] <ogasawara>     subverting privileged binaries.
[21:23] <ogasawara>     
[21:23] <ogasawara>     This patch completely breaks apparmor.  Someone who understands (and
[21:23] <ogasawara>     uses) apparmor should fix it or at least give me a hint.
[21:24] <ogasawara> kees: ^^ "This patch completely break apparmor" has me concerned
[21:24] <ogasawara> kees: breaks apparmor how?
[21:26] <ogasawara> kees: ha, disregard
[21:26] <ogasawara> kees: I'm now seeing the next patch :)
[21:31] <kees> ogasawara: heh, yes :)
[21:35] <pbuckley> anyone have a good link for the differences between ubuntu's 11.10 kernel (3.0) and the 12.04 kernel (3.2)?
[21:36] <ohsix> kernelnewbies has most of the interesting stuff in the release notes
[21:36] <pbuckley> cool thanks
[21:36] <ohsix> beyond that, git log :>
[21:37] <pbuckley> heh.. that seems like a like of commits to go thru.. just trying to justify building our next project on 12.04 vs 11.10 thats going to ship in like 6 months
[21:37] <pbuckley> +alot
[21:39] <ohsix> linus has a release message that has interesting stuff in it too, but kernelnewbies is the meat
[21:40] <pbuckley> hrmm i only see 3.3
[21:40]  * pbuckley digs around some more
[21:41] <pbuckley> http://kernelnewbies.org/Linux_3.2
[21:41] <pbuckley> \o/
[21:51] <ogasawara> kees: getting build failures on arm
[21:51] <ogasawara> kees: kernel/seccomp.c:27:25: fatal error: asm/syscall.h: No such file or directory compilation terminated.
[21:52]  * kees shakes a fist
[21:52] <ogasawara> kees: I gotta drop off for a bit, I'll check back in a bit
[21:52] <kees> okay
[21:53] <kees> ogasawara: I don't have an ARM build environment :(
[21:53]  * Daviey passes kees a qemu-system-arm.
[21:53] <kees> ogasawara: can you wrap the #include line with #ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER block maybe?
[21:53] <kees> Daviey: if only it were that easy! :)
[21:53] <Daviey> kees: i'd love to know how long cpu virt takes to build an arm kernel :)
[21:54]  * kees cries
[21:56] <Daviey> kees: ScottK was given two arm 'server' boxes to setup for community access.. he's had them over a year, ask them how access is progressing. :)
[21:57] <kees> actually, it turns out I've already set up for qemu-arm, I just need to override the mirror and mk-sbuild will DTRT
[21:58] <ogra_> Daviey, they were slow ones and still havent finished their boot :P
[21:58] <Daviey> ogra_: I blame the canonical arm team for the slow booting :P
[21:59] <ogra_> haha, you never booted an ac100 with a recent image, did you ?
[21:59] <ogra_> (boots faster than any x86 SSD based machine i have around)
[22:00] <ogra_> (though indeed ac100 is a community effort, cant credit the ubuntu arm team for it ;) )
[22:02] <kees> mk-sbuild --arch=armel precise --debootstrap-mirror=""
[22:02] <kees> wheee
[22:07] <apw> kees, can't you cross compile, thats what most of us do to confirm compilability
[22:11] <jjohansen> apw: for the apparmor rebase should I do a whole sale drop in of 3.4 aa as a single patch, or cherry pick the 20 or so upstream patches
[22:34] <bandit5432> what channel should i be in to talk about the latest mainline release?
[22:39] <pbuckley> oh yay.. that numa stuff made it into 3.1
[22:44] <bandit5432> any have any regressions with 3.3 from rc7 and optical drives?
[22:54] <bandit5432> kernel v3.3-precise does not recognize my ide optical drives any thoughts? v3.3-rc7-precise works fine
[23:04] <ogasawara> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
[23:04] <ogasawara> index 8af235b..d22ef26 100644
[23:04] <ogasawara> --- a/kernel/seccomp.c
[23:04] <ogasawara> +++ b/kernel/seccomp.c
[23:04] <ogasawara> @@ -24,7 +24,9 @@
[23:04] <ogasawara>  #include <linux/slab.h>
[23:04] <ogasawara>  #include <linux/uaccess.h>
[23:04] <ogasawara> +#ifdef CONFIG_HAVE_ARCH_SECCOMP_FILTER
[23:04] <ogasawara>  #include <asm/syscall.h>
[23:04] <ogasawara> +#endif
[23:04] <ogasawara> kees: ^^ seems to fix it
[23:05] <ogasawara> kees: I'm just gonna squash it with "UBUNTU: SAUCE: SECCOMP: seccomp: add system call filtering using BPF"
[23:31] <c_smith> hey, I encountered something strange, and fixed it after quite a while, but it pertains to the kernel, as it kept either dumping a crash log to my screen, or throwing me a Kernel Panic, the situation was that I had all 3 of my RAM slots in my desktop filled with a 1 GB PC-3200 RAM stick each, and kept getting said crash dumps and kernel panics.
[23:32] <bandit5432> did you test the ram?
[23:32] <c_smith> Yes, I did, once with each ram stick inserted one at a time and then again with all 3, memtest86 reported no errors.
[23:33] <c_smith> and I ran all 9 tests with Memtest86.
[23:33] <bandit5432> how did you fix it?
[23:33] <c_smith> removed one stick.
[23:33] <ohsix> did you check your motherboard documentation, some of them aren't expected to be stable with the ram slots filled in different ways
[23:33] <bandit5432> do you have a bad ram slot
[23:33] <ohsix> eg. they need to go in as pairs or the like
[23:33] <c_smith> sadly, I don't have the documentation, the desktop was given to me.
[23:34] <bandit5432> you can download the docs from the manufacture 
[23:34] <ohsix> some chipsets don't even terminate the other banks when there's one piece of memory in a pair of slots :P
[23:34] <c_smith> and it might be the slot, no clue. I got the desktop only recently.
[23:34] <c_smith> hmmm, that might be handy, I'll look at the manufacturer.
[23:35] <c_smith> ofc, I have no clue as to even the model for the mainboard.
[23:35] <c_smith> would it say on the mainboard?
[23:35] <bandit5432> yes
[23:35] <c_smith> cool, I'll get to that info,
[23:35] <c_smith> thanks for the tip. :)
[23:35] <bandit5432> and if its a hp dell etc look up the model #
[23:36] <c_smith> it's a Gigabyte mainboard, that much I know from the BIOS.
[23:36] <bandit5432> gigabytes are easy to look up
[23:37] <bandit5432> look to the left of the first ram slot
[23:37] <c_smith> thanks
[23:37] <bandit5432> np
[23:37] <c_smith> and I am curious, how outdated would PC-3200 RAM be?
[23:38] <c_smith> not that it's essential, just a curiousity.
[23:38] <ohsix> ram doesn't usually go out of date, it goes in the bin with the computer :P
[23:38] <ohsix> but we're to ddr3 now
[23:38] <c_smith> ok
[23:40] <c_smith> yay for tiny text..... having a tough time finding it.... >.<
[23:41] <c_smith> ok, think I found it.
[23:42] <c_smith> yep, found it, would have helped to have the flash light ready from the start,
[23:46] <c_smith> so, it looks like the max supported RAM is what I had, 3GB via 3 DIMM slots.
[23:47] <c_smith> so, mightn't it be the slot even if Memtest86 reported no errors with all 3 slots being occupied?
[23:50] <bandit5432> it could be anything what kernel are you running with it breaks?
[23:52] <c_smith> the latest one in the Oneiric updates, but it also happened with the second latest.
[23:53] <c_smith> let me plug it in to get you the latest one that the desktop is running
[23:54] <bandit5432> search for kernel panics and the kernel ## and see what causes them I had a bad powersupply that caused kernel panics so it could be a lot of things
[23:55] <jMCg> How do I get this string 'lib/x86_64-linux-gnu' from debian build tools?
[23:55] <c_smith> kk
[23:56] <c_smith> what do I search in?
[23:56] <bandit5432> google
[23:56] <c_smith> kk.
[23:56] <bandit5432> uname -r to get the kernel version
[23:57] <bandit5432> in a terminal
[23:57] <c_smith> the kernel version is 3.0.0-16-generic. uname ftw! :)
[23:59] <c_smith> meh, not finding anything useful...... only an Atheros panic that was fixed in 3.0.0-16