[01:11] <toocool>   I need some help compiling and packaging a custom kernel flavour for an i386 target ona amd64 host 
[01:14] <toocool> i have 3.2.0 source via git for precise 12.04, but debian/rules is not aware of i386 binary target
[01:19] <toocool> i was able to compile and package a custom flavour kernel based on generic on the i386 machine but can not duplicate it on my amd64 laptop
[01:25] <toocool> is there something simple i'm missing- to target a 32bit target on a 64bit system? i was hoping to do so would be quicker
[01:33] <BenC> toocool: make a 32-bit chroot environment with deboostrap
[01:34] <BenC> There's another way using dpkg-cross or something, but I'm not familiar with that route
[01:34] <toocool> thank you, i'll start reading
[08:01] <ppisati> moin
[08:03] <smb> morning
[08:14] <apw> moin
[08:47] <brendand> cking, what to do about this one? http://paste.ubuntu.com/1053912/
[08:48] <cking> I believe fwts also generates some advice with this, which points me to the specification - do you keep that info, if not  I will look it up by hand
[08:50] <cking> brendand, I'll look it up in section 7.21 of the spec, bear with me
[08:51] <brendand> cking, we have the full log. i can pastebinit to you
[08:51] <brendand> cking, http://paste.ubuntu.com/1053916/
[08:52] <brendand> yes, i should have done that in the first place ;)
[08:52] <cking> no worries
[08:56] <cking> brendand, so I doubt it will screw anything up, but it is definitely not matching the specification. the value 0 is reserved, so should not be used, I expect values like 1 or 2 in this field, or 0xff if unknown.
[08:58] <brendand> cking, i'll raise a bug against ubuntu and subscribe you and the project managers as vanhoof requested
[08:59] <cking> brendand, I will put in my notes to the bug and we should forward it to the BIOS vendor if they can be bothered to fix it
[08:59] <cking> which I doubt
[09:00] <brendand> cking, so this is an enabled system. don't we have bios engineers?
[09:00] <cking> brendand, sorry, I don't understand your question
[09:01] <brendand> cking, neither do i, to some extent :/
[09:01] <cking> brendand, we can't fix this issue, it's up to the BIOS vendor to fix it
[09:01] <brendand> cking, right
[09:02] <cking> but I doubt they will do since it's not breaking anything and it's costly to fix it. however, we can tell them not to do this again in next releases
[09:02] <brendand> cking, of course. 
[09:11] <brendand> cking, https://bugs.launchpad.net/ubuntu/+bug/1016436
[09:11] <ubot2> Ubuntu bug 1016436 in ubuntu "[Lenovo E325] DMIIllegalMappedAddrRange error when running FWTS" [Undecided,New]
[09:16] <cking> brendand, thanks, I've updated the bug report, upto somebody else to figure out what to do with it though :-/
[09:34] <brendand> something of a critical issue we've found here in quantal: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1016444
[09:34] <ubot2> Ubuntu bug 1016444 in linux "Broadcom NetXtreme II detect network hardware fails due to can't find bnx2 firmware" [Undecided,New]
[12:22]  * ppisati -> lunch
[12:26] <apw> cking, ok i may have some quantal lowlatency kernels if you are interested in them, no idea if they work of course :)
[12:27] <cking> apw, I'd like to give them a spin
[12:27] <apw> arges, it was you who had some idea why we might care about lowlatency and have a usecase for it right?
[12:27] <arges> apw, yea i can help test
[12:28] <apw> ok they are just uploading now, will point you at 'em when they are done
[12:28] <cking> ta
[12:29] <arges> apw, i'll also try to get some numbers 
[12:29] <arges> apw, in terms of how it affects audio recording (since that's a big usecase for me)
[12:30] <apw> rtg, i think i've put together a lowlatency branch using a new 'just override these configs' approach
[12:30] <apw> so it should be a straight rebase with no tweaking
[12:30] <cking> arges, so how do you propose to get some figures for that?
[12:31] <rtg> apw, is it _just_ config changes ?
[12:31] <apw> rtg, right now the branch still has your patch, though that could become config changes.  the point was that there is no manual handling of the configs for the branch so maintenance of it is simplified massivly
[12:32] <apw> and if it works well for quantal it would likely make sense for P too
[12:32] <apw> as right now one has to handle the config delta and all changes in the config, by hand, nnng
[12:35] <apw> http://people.canonical.com/~apw/lowlatency-quantal/ <-- cking, arges 
[12:36] <arges> downloading
[12:39] <arges> apw, whats the appropriate patch format if. An original ubuntu patch was modified by another author, and wants to contribute it back? Should From: be changed, and just credit the original patch? 
[12:40] <rtg> arges add a second patch that modifies code touched by the first ?
[12:41] <cking> apw, it boots
[12:44] <BenC> rtg: Any chance of some feedback on the newer patch set I sent to kernel-team@?
[12:45] <rtg> BenC, yep, though the answer hasn't changed. I'll send it out on the list.
[12:45] <BenC> rtg: That set doesn't change any relevant code though
[12:46] <BenC> rtg: And you do realize it's difficult to maintain a community driven port when the community has such a hard time getting support from the kernel-team...
[12:47] <BenC> I've put in over 100 hours of work getting failed builds down to a reasonable level on powerpc (and 25%+ of that helped arm by extension) over the past few weeks
[12:48] <rtg> BenC, look, its not my call. Rick said no, so you're gonna have to convince someone higher then my pay grade.
[12:48] <BenC> So how about ya throw me a bone here...
[12:48] <BenC> Rick who?
[12:49] <rtg> Rick Spencer, our director of engineering. 
[12:49] <apw> BenC, why is it hard to maintain a derivative kernel, we have many of them
[12:49] <BenC> And it would be nice if the person actually making the call was the one responding to my emails on the list
[12:49] <BenC> apw: derivatives go into universe
[12:49] <BenC> universe == no installer
[12:50] <apw> the destination of a derivative kernel is not fixed is it?  lowlatency goes into main as it is the default kerenl for the ubuntu-studio CD ?
[12:50] <BenC> I don't think so…ubuntu-studio is a derivative of ubuntu, so it can pull in different components
[12:50] <BenC> I don't want to have to start going through MIRs just to get this thing going either
[12:51] <BenC> The new flavor isn't anything but another configuration, and one arguably more usable than powerpc-smp being currently built
[12:52] <BenC> rtg: And for the record, and I know it's not you at all, but Canonical has been extremely slow getting us any response on our OEM partnership paperwork we sent in several weeks ago
[12:54] <BenC> We put in our partnership requests with Redhat and Suse well after we started the process with Canonical, and we already have logo rights back to us and developer channels open with them, in less time
[12:55] <BenC> So you can imagine my frustration at how difficult this process is with the dist/company that I have such an affinity for :)
[12:56] <apw> cking, can you tell what hz is from the running kernel there?
[12:57] <rtg> BenC, well, this isn't the right channel. I guess you need to keep talking to vanhoof, but I know he's on vacation this week.
[13:02] <apw> BenC, i have not found kernel MIRs particularly onerous, as a kernel is a known shape, and we know where CVE fixes are coming from
[13:03] <apw> though i assuem you want installer bit bacause you want CDs built, and those tend to be a problem due to space
[13:05] <cking> apw, apart from the following, I'm not sure how to figure that out easily. grep CONFIG_HZ= /boot/config-`uname -r`
[13:05] <cking> CONFIG_HZ=1000
[13:06] <apw> cking, well thats something at least :)  does PREEMPT appear in uname -a
[13:06] <apw> cking, next to SMP, have the feeling its exposed in the same place
[13:06] <cking> grep PREEMPT= /boot/config-`uname -r`
[13:06] <cking> CONFIG_PREEMPT=y
[13:07] <arges> apw, getting some numbers for comparison with the generic-amd64 kernel frist btw
[13:07] <cking> arges, how are you instrumenting that?
[13:07] <arges> cking, i knew you'd ask : )
[13:07] <arges> cking, basically just using qjackctl to set the latency lower and checking for xruns
[13:08] <arges> its not as scientific as i'd like it
[13:08] <BenC> apw: Do you really want security guys to have to worry about another package that needs to get built for kernel CVEs and processing those ABIs and relevant meta packages?
[13:08]  * cking using cyclictest and other tests
[13:08] <BenC> Sounds like way more work than just adding the config/meta to the existing packages
[13:08] <arges> cking,  can you point me at that
[13:08] <cking> arges, http://people.redhat.com/williams/latency-howto/rt-latency-howto.txt
[13:08] <cking> but I need to faff around and see if it's useful or not
[13:09] <BenC> rtg: I know you say Rick said not to do it, but I tend to think you didn't do much to try to convince him, but most likely just wanted his confirmation of your decision :)
[13:10] <BenC> Anyways, I'm out of San Antonio heading back home from the Freescale conference where Canonical actually has a booth, so again, my confusion when we can't get a Freescale product line supported...
[13:12] <rtg> BenC, I did my homework with the biz-dev types. I'm not gonna commit to a another flavour until I'm sure its gonna stick, so keep talking to them.
[13:15] <cking> arges, http://elinux.org/Realtime_Testing_Best_Practices
[13:16] <cking> arges, and audio related: http://www.gardena.net/benno/linux/audio/
[13:20] <cking> arges, http://www.alsa-project.org/~iwai/suselabs2003-audio-latency.pdf
[13:42] <cking> arges, can you write up how you are measuring the audio on your machine?
[13:56] <arges> cking, yes doing that now
[14:17] <arges> rtg, apw : pad.lv/669641
[14:17] <apw> [email@bar: desctription]       
[14:25] <ming_lei> ppetraki, I have seen the boot hang just one time
[14:25] <ming_lei> ppetraki, looks it is very difficult to reproduce it on my board
[14:25] <ming_lei> ppisati,  I have seen the boot hang just one time
[14:25] <ming_lei> ppisati, looks it is very difficult to reproduce it on my board
[14:26] <ppisati> ming_lei: cool
[14:26] <ppisati> ming_lei: so, with a brand new card i don't see it at all
[14:27] <ppisati> ming_lei: so fat
[14:27] <ppisati> far
[14:27] <ppisati> ming_lei: but it has been just one day that i'm trying with it
[14:27] <ppisati> ming_lei: now there's a problem with video output
[14:27] <ppisati> ming_lei: so i won't test it anymore
[14:27] <ppisati> ming_lei: i'll have to fix video first
[14:28] <ming_lei> ppisati, I mean the problem of 'omap2_set_init_voltage: unable to set vdd_mpu_iva'
[14:29] <ppisati> ming_lei: yes, i understood what you mean
[14:29] <ppisati> ming_lei: but at least you reproduced it one time
[14:30] <ming_lei> ppisati, yes, just one time
[14:37]  * ppisati -> reboot
[15:23] <diwic> if the same patch solves more than one bug, will it work to have two "BugLink:" lines in the patch header?
[15:32] <bjf> diwic, yes
[15:34] <diwic> bjf, thanks
[15:35] <rtg> diwic, is one a dupe of the other ?
[15:36] <diwic> rtg, not really. I was thinking of adding three similar quirks (for three different machines) in the same patch for efficiency.
[15:39] <bjf> diwic, as long as all three bugs have the sru text, i think you are fine with a single commit that fixes them all
[15:39] <diwic> bjf, ok. These will all go through upstream, so they won't need any SRU text.
[15:40] <diwic> probably they will hit quantal and not precise
[15:40] <bjf> diwic, ah!, that's cool
[15:40] <diwic> still good to have them autoclosed though :-)
[15:43] <bjf> diwic, yup
[16:04] <bjf> rtg, http://pastebin.ubuntu.com/1054497/
[16:04] <bjf> rtg, it's working just fine
[16:04] <rtg> bjf, that looks better.
[17:59] <cking> arges, I'll get back to you on tools to try - I'm experimenting with a bunch of broken old of date tools that seem to not be very useful at the moment :-/
[17:59] <arges> cking, ok thanks
[18:10]  * cking --> EOD
[18:10] <cking> ...and mutters to himself about broken tools..
[18:55]  * ppisati ->EOD
[19:20] <bjf> cnd, how do you simulate a middle mouse click on the MB?
[19:57]  * rtg calls it a week.
[20:08] <cnd> bjf, you don't
[20:08] <bjf> cnd, oh
[20:08] <cnd> you can manually configure it to be a three-touch tap if you want
[20:08] <cnd> but it's limited
[20:09] <cnd> the reason is that the unity multitouch gesture spec conflicts with three-touch tap
[20:09] <cnd> so the default is to not provide middle button emulation
[20:10] <cnd> I'm trying to find the bug about this
[20:10] <cnd> it has some info on how to enable it manually
[20:11] <cnd> but it doesn't to stick after suspend/resume or reboot
[20:13] <cnd> bjf, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/754000/comments/64
[20:13] <ubot2> Ubuntu bug 754000 in xserver-xorg-input-synaptics "Running Unity disables Xorg's 3-finger click support (middle click)" [Low,Won't fix]
[20:14] <bjf> reading
[20:17] <cnd> bjf, note that if you enable middle click emulation, you lose the three-touch gestures in unity
[20:17] <cnd> which may not be a big deal to you :)
[20:17] <bjf> cnd, ack thanks for the explaination
[20:17] <cnd> it's just an unfortunately reality of X being architected as it is
[20:17] <infinity> Don't we map some keyboard shortcuts to right and middle by default on Macs?
[20:18] <cnd> maybe the option key for right click?
[20:18] <cnd> I would be surprised for middle click, but I could be wrong
[20:18] <infinity> F11 and F12 or something?  I dunno.  I buy hardware with mouse buttons.
[20:19] <infinity> Ubuntu bug 754000 in xserver-xorg-input-synaptics "My MacBook isn't a ThinkPad" [Low,Won't fix]
[20:19] <ubot2> Ubuntu bug 754000 in xserver-xorg-input-synaptics "Running Unity disables Xorg's 3-finger click support (middle click)" [Low,Won't fix] https://launchpad.net/bugs/754000
[20:19] <infinity> ubot2: Shut it.
[20:19] <ubot2> Factoid 'Shut it.' not found
[21:06] <genii-around> Hello.. Perhaps someone may know offhand.. if there is some known bug with 3.4,3.5 64 bit kernels and Atom N450. I get odd messages like bad rss-counter state