[00:04] <jsalisbury> bjf, I'm pinging bdmurray and the landscape team now.
[00:05] <jsalisbury> bjf, s/landscape/launchpad/ :-)
[00:05] <bdmurray> about what?
[00:06] <jsalisbury> bdmurray, do you know whether the lp expiration bot is running? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/399911 looks like it should have expired a while ago.
[00:06] <ubot2> Launchpad bug 399911 in linux "samsung x360 fn-keys work incorrectly" [Medium,Incomplete]
[00:06] <jsalisbury> bdmurray, from my understanding launcpad itself expires bugs, versus manual bots.
[00:06] <jsalisbury> bdmuarry, s/manual bots/bots we create/
[00:06] <bdmurray> jsalisbury: yes the launchpad janitor expires bug reports
[00:07] <bdmurray> jsalisbury: I'd expect to see "This bug can expire in xyz days" on the page
[00:08] <bdmurray> jsalisbury: for example in bug 846652 you can see this
[00:08] <ubot2> Launchpad bug 846652 in xserver-xorg-video-intel "Screen shifted right and incorrect refresh rate when switching VTs and unsuspending" [High,Incomplete] https://launchpad.net/bugs/846652
[00:08] <jsalisbury> bdmurray, could there be a bug in the expiration janitor?  Does it only trigger off of an incomplete status
[00:08] <bdmurray> jsalisbury: it must be incomplete and a not match a few other criteria
[00:09] <jsalisbury> bdmurray, yeah, maybe the number of affected people has something to do with it?
[00:09] <bdmurray> jsalisbury: that criteria is listed at https://help.launchpad.net/BugExpiry
[00:09] <bdmurray> jsalisbury: no its not that I'm thinking / looking at it
[00:09] <jsalisbury> bdmurray, thanks for the link, I'll take a look at that page.
=== zz_bigbash is now known as bigbash
[00:10] <bdmurray> jsalisbury: I don't see anything my only thought is it might be because date_incomplete is so old
[00:12] <jsalisbury> bdmurray, you think because it was set to incomplete back on 2009-12-10, and maybe the expiration logic was different then?
[00:14] <bdmurray> jsalisbury: no that maybe the janitor only looks at date_incomplete within the past 90 days ... I'm grasping at straws though
[00:15] <jsalisbury> bdmurray, I wonder what would happened if I marked the bug as confirmed then incomplete again?
[00:15] <bdmurray> jsalisbury: there is a bug.isExpirable method that returns False
[00:15] <bdmurray> well you'd have to wait 90 days for the actual expiration to happen
[00:16] <jsalisbury> bdmurray, I also noticed the background for Incomplete in bug 399911 is a brighter yellow compared to incomplete say in bug 846652, not sure if that actually means anything
[00:16] <ubot2> Launchpad bug 399911 in linux "samsung x360 fn-keys work incorrectly" [Medium,Incomplete] https://launchpad.net/bugs/399911
[00:16] <ubot2> Launchpad bug 846652 in xserver-xorg-video-intel "Screen shifted right and incorrect refresh rate when switching VTs and unsuspending" [High,Incomplete] https://launchpad.net/bugs/846652
[00:17] <bdmurray> jsalisbury: don't think so
[00:18] <jsalisbury> bdmurray, do you have a script, or is that one in arsenal that you used to pull the bug.isExpirable method?
[00:18] <jsalisbury> bdmurray, I guess I could just write a quick one.
[00:19] <bdmurray> jsalisbury: I just used ipython to check on that bug
[00:20] <jsalisbury> bdmurray, ahh, ok.  I wonder if it has anything to do with being assigned to someone, then reassigned to nobody.
[00:21] <jsalisbury> bdmurray, bjf, I'll dig further and maybe see if someone on the launchpad team knows.
[00:21] <bdmurray> oh, I've an idea now
[00:21] <jsalisbury> :-)
[00:23] <bdmurray> jsalisbury: I'm pretty sure its because the status for 846652 is "Incomplete w/o response" and the status for 399911 is just "Incomplete"
[00:24] <bdmurray> jsalisbury: and the API only tells you that they are Incomplete
[00:25] <jsalisbury> bdmurray, I'm not sure I understand the "Incomplete w/o response", Are comments in the bug not responses?
[00:25] <jsalisbury> bdmurray, or is it comments added after the bug was marked Incomplete?
[00:26] <bdmurray> the latter
[00:26] <jsalisbury> bdmurray, ahh, ok.  
[00:28] <jsalisbury> bdmurray, and once a bug has a response after marked incomplete, it looks like it can't be forced to expire.  For bug 399911, I marked it confirmed, then incomplete again, and the message "This bug report will be marked for expiration in N" did not show up.
[00:28] <ubot2> Launchpad bug 399911 in linux "samsung x360 fn-keys work incorrectly" [Medium,Incomplete] https://launchpad.net/bugs/399911
[00:29] <jsalisbury> bdmurray, oh wait, I also see that that bug has a duplicate!
[00:30] <jsalisbury> bdmurray, but the Expiry page says that the bug must be a duplicate itself not to expire :-/
[00:30] <bdmurray> jsalisbury: having a duplicate isn't a factor
[00:30] <jsalisbury> right
=== bigbash is now known as zz_bigbash
[01:17] <martijn> Quick question, forgive the newbie on this, I'm trying to get the ubuntu kernel to diagnose a USB driver issue I'm having, but I run into "fatal: The remote end hung up unexpectedly" when git clone'ing from kernel.ubuntu.com - is this something really obvious I should know about?
[01:18] <martijn> (cmd was: git clone git://kernel.ubuntu.com/ubuntu/ubuntu-oneiric.git lixsrc )
[01:18] <martijn> (now trying git clone http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-oneiric.git -- will post here when/if that fails, not aware of any firewall issues between me and the inet)
[01:27] <martijn> (USB issue in question is isochronous URB reception seems to not work from userland, my suspicion is a problem in drivers/usb/core/devio.c line 1347 processcompl() and I'd like to add some printk's there to diagnose.. but that requires the kernel.)
=== mfisch is now known as Guest83317
=== ericm-Zzz is now known as ericm
[01:43] <bjf> martijn: there is something wrong with kernel.ubuntu.com right now
[01:44] <martijn> bjf: Thanks for the response! does the http request have any hope of succeeding or should I retry tomorrow?
[01:45] <bjf> martijn: i think there is no hope right now
[01:46] <martijn> Assuming that statement is limited to kernel.ubuntu.com, I'll try again tomorrow - thanks for the info & good luck to who is working on fixing it.
[01:59] <martijn> (http also failed as expected, tomorrow!)
[02:07] <T3CHKOMMIE> hey guys. i need some help with a kernel project im doing. Im having the hardest time and ive spent well over 40 hours trying to figure this crap out. i feel like I am missing just a small piece of the puzzel.... can someone help me?
[02:17] <T3CHKOMMIE> maybe someone can help me. i downloaded ubuntu kernel from source. did a make menuconfig and tweaked it how i liked. then did a make...
[02:17] <T3CHKOMMIE> im pretty sure that compiled the kernel. now im just trying to get it to an install CD so i can install it on my test machine. can anyone help me?
[03:15] <T3CHKOMMIE> hey guys, i still cant figure out how to "use" a kernel. i compiled one and cant figure out how to get it working. i tried using UCK and that was a miserable failure. has anyone compliled their own kernel?
[03:29] <T3CHKOMMIE> anyone?
[06:09] <semitones> hello, valorie suggested I come here from #kubuntu to ask about my bug
[06:09] <semitones> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/888415
[06:09] <ubot2> Launchpad bug 888415 in pulseaudio "Speakers do not mute when headphone jack is in use. Multimedia keys unmute speakers." [Undecided,New]
[06:09] <semitones> she said it ended up being a kernel problem for her
[06:12] <semitones> let me know if that sounds familiar -- I can idle here for a while :)
=== ericm is now known as ericm-Zzz
=== ericm-Zzz is now known as ericm-afk
=== ericm-afk is now known as ericm
[10:44] <diwic> bjf, if you're awake - I'm trying out your kernel scripts (the alsa cod), but when try to "make source", it fails with "file not found: source/debian/control". What is the correct way to fix this problem? I notice that there is no debian/control, but debian/control.stub.in, debian/control-scripts, and control.d/ 
[10:44] <diwic> all exists in the debian directory
[10:48] <diwic> aha, "fakeroot debian/rules debian/control" did the trick
[11:48] <apw> diwic, likely you really wanted fakeroot debian/rules clean
[11:48] <apw> that creates all the transient debian stuff
[11:48] <diwic> apw, aha, thanks
[11:48] <apw> else you won't have a changelog later in the process
[11:49] <apw> semitones, yep that is likely a kernel issue
[11:49] <apw> diwic, do we have a good debugging guide for jack problems
[11:50] <diwic> apw, eh 
[11:50] <diwic> apw, could you specify "jack problems" a little
[11:51] <apw> diwic, classic is "i insert headphones and speakers don't turn off"
[11:51] <apw> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/888415
[11:51] <ubot2> Launchpad bug 888415 in pulseaudio "Speakers do not mute when headphone jack is in use. Multimedia keys unmute speakers." [Undecided,New]
[11:51] <apw> is one we got asked about in scrollback last night
[11:51] <diwic> apw, only one of 84 open bugs for pulseaudio :-/
[11:52] <apw> heh yeah, i assume its more likely a kernel issue in this case right ?
[11:52] <apw> semitones, is this machine reallly running maverick ?
[11:52] <diwic> apw, probably, but determing that is non-trivial
[11:53] <apw> diwic, so pulse also takes a hand in jack handling ?
[11:53] <diwic> apw, hmm, since oneiric it does, but if this is maverick, it's definitely kernel
[11:54] <apw> oh ... thats news, i am unsure i want to know how pulse is involved ... yeeks
[11:54] <apw> diwic, i'll shove it over to kernel anyhow, then it can be 1/6k bugs and even more lost
[11:54] <diwic> telling user to try https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS
[11:56]  * apw tells them to test an oneiric liveCD
[11:57] <diwic> heh
[11:57] <diwic> either should be just fine.
[11:57] <apw> diwic, thanks
[11:58] <apw> man maverick seems like so long ago, and yet its only a year
[12:01] <apw> diwic, i note that all of those dkms packages failed to build on i386
[12:02] <diwic> apw, fixed today, but yeah, maybe I should trigger a new build
[12:02] <diwic> apw, is this something to worry about: "package linux-alsa-driver-modules-oneiric-generic in control file but not in files list"
[12:03] <apw> its poor on our behalf but likely not an issue that stops you, thats an lbm package
[12:03] <apw> oh are you trying to start up auto builds of alsa for oneiric ?
[12:04] <apw> i suspect lbm doesn't have an alsa backport in it yet which would lead to that error
[12:04] <apw> it'd all be commented out, still in there but off
[12:08] <diwic> apw, yeah, I started off with bjf's tree for cod-natty and trying to make something launchpad based for oneiric
[12:08] <diwic> apw, as bjf's stuff is non-existent for oneiric and broken for the older
[12:18] <apw> diwic, nice, so yeah it may well be we have no alsa in lbm if that is what you are using
[12:18] <apw> though how would that differ from your dkms package ?
[12:18] <apw> if you used that against the crack of the day alsa tree ?
[12:19] <diwic> they use the same source, the dkms package is for snd-hda-* modules only and is dkms based
[12:19] <diwic> if you need all modules (i e testing something different than HDA Intel cards you'll need the full sound tree
[12:19] <apw> ahh yes, there is a lot more poo in there
[13:13] <brendand> smb - sorry to bother you, but if i were to use 'skipabi' where would i put it?
[13:14] <smb> brendand, depends a bit on what command you use to run the build I believe
[13:15] <smb> I use it rarely so it is easy to forget. Would skipabi=true dpkg-buildpackage -b ... work?
[13:15] <brendand> the instructions i am using use debian/rules
[13:16]  * smb thinks there both "skipabi=true debian/rules ..." and "debian/rules skipabi=true ..." may work
[13:19] <smb> brendand, Seems right. You can use debian/rules printenv to check what settings get used
[13:25] <brendand> smb - great, trying that now
=== yofel_ is now known as yofel
=== zz_bigbash is now known as bigbash
=== bigbash is now known as zz_bigbash
=== zz_bigbash is now known as bigbash
=== chuck__ is now known as zul
=== BenC__ is now known as BenC
[14:45] <ogasawara> apw, tgardner: I'm trying to remember bits from UDS, wasn't there discussion about building in SATA_AHCI?
[14:46] <tgardner> ogasawara, yep, in fact that is what I set out to do, but got confused with xhci instated.
[14:46] <apw> ogasawara, there was confusingly conversations about XHCI for usb3 and ahci as its the common sata.  they got conflated at times
[14:46] <tgardner> instead*
[14:46] <apw> ogasawara, overall though i think we should move that one boot essential
[14:46] <apw> tgardner, indeed :)
[14:47] <tgardner> ogasawara, i did build in xhci in precise though. we'll need to make sure it doesn't break suspend
[14:47] <ogasawara> tgardner: ack
[14:47]  * apw is just doing some of those annotations as it happens
[14:47] <ogasawara> apw: I'll add it as a work item so we don't forget
[14:47] <apw> ogasawara, cool thanks
[15:14]  * tgardner pours gas into ubuntu-devel
[15:15] <Kiall> Hiya - I'm trying to figure out the cause of a kernel panic, anyone about to understand the logs? ;) http://dl.dropbox.com/u/1400487/panic/IMG_20111026_040053.jpg
[15:17]  * ogasawara back in 20
[15:17] <apw> Kiall, from the log that looks like a problem in a combination use of bridging and netfilter
[15:17] <apw> Kiall, what release is this on as the kernel version is off the top on that dump
[15:18] <apw> smb, didn't we have a problem in a stable update recently in this area ?
[15:18] <apw> tgardner, ^
[15:18] <Kiall> apw: Mine is running 3.0.0-13-server on oneiric
[15:18] <smb> apw, Nothing I know of...
[15:19] <tgardner> Kiall, you have bridging enabled with iptables rules ?
[15:20] <Kiall> tgardner: yes
[15:20] <tgardner> apw, IIRC it was netfilter and lxc that had issues
[15:20] <Kiall> Its a server running OpenStack, So a combination of VLAN's, NF, Bridging and KVM (ie .. everything)
[15:21] <tgardner> Kiall, a VPN with tun/tap ?
[15:21] <Kiall> No - no VPN involved
[15:21] <Kiall> I think the tap is KVM
[15:21] <apw> its the bridge for kvm then in this case
[15:21] <tgardner> Kiall, right. I haven't setup KVM in awhile
[15:22] <tgardner> Kiall, what net filters are you using ?
[15:23] <apw> Kiall, was this the host or the VM that dumped
[15:23] <Kiall> apw: the host
[15:23] <tgardner> apw, only yhte host can see the bridge
[15:23] <apw> tgardner, point
[15:24] <Kiall> tgardner: DNAT, SNAT, and standard accept/deny rules..
[15:24] <tgardner> Kiall, nothing particularly dangerous there
[15:24] <apw> so this is a NAT bridge not a native one (that how virtmanager talks about it)
[15:25] <apw> so ... he is running a v3.0.6 base, so it'd be worth a scan of everything in stable after
[15:25] <tgardner> Kiall, is this a recent change in behavior ? and how often does it happen ?
[15:26] <Kiall> I've seen it twice, and I've just found another person who's its just happened to..
[15:26] <Kiall> Obviously, Oneiric installs so they haven’t had very long lives yet
[15:26] <apw> cirtianly worth getting a bug filed with that on it, we are bound to see it plenty as well
[15:29] <Kiall> yea, will do
[15:31] <apw> if you can reproduce it i'd like to know if its there in -12, though i suspect it is
[15:32]  * smb wonders wehter the 200+ patches pending on 3.0.y will help or do worse...
[15:32] <Kiall> Standard traffic seems to trigger it, but I haven't figured out what traffic in particular :(
[15:33] <apw> smb, yeah
[15:56] <tgardner> ogasawara, did 3.1 compat-wireless for Lucid stay on your list ?
[15:57] <ogasawara> tgardner: it did, was planning to get to it today or tomorrow.
[15:57] <tgardner> ogasawara, np, thanks
[15:57] <smb> Wasn't tomorrow a holiday over there?
[15:57] <apw> ogasawara, also do we have an alsa backport in oneiric yet ?
[15:58] <ogasawara> smb: it is, but I'm planning to swap it for another day
[15:58] <tgardner> smb, yep
[15:58] <smb> ah ok
[15:59] <ogasawara> apw: we don't
[15:59] <apw> i assume we should now/soon, i wonder if thats on -stable's radar
[16:01] <ogasawara> apw: do we have a strong need for an updated alsa in oneiric?
[16:01] <apw> a good question indeed
[16:05] <bjf> apw, did we have a backported alsa for maverick or natty ?
[16:06] <tgardner> I'm thinking we should only bother with backports to the current release and Lucid.
[16:06] <tgardner> backports being compat-wireless and possible alsa
[16:06] <tgardner> possibly*
[16:07] <apw> so current == oneiric right now ?
[16:07] <apw> bjf, another good question
[16:07] <bjf> tgardner: my question was more along the lines of, "do we regularly backport alsa to N-1?"
[16:07] <tgardner> on the other hand, with the LTS kernels, does it make sense to backport anything to Lucid ?
[16:07]  * apw was thinking the same as tgardner on lucid
[16:10] <tgardner> apw, thats one more bit of maintenance that we could shed
[16:11] <apw> if we are doiing the work to support backports then they should be sufficient in theory
[16:11] <apw> i guess the only question is whether we get alsa/wireless backports sooner than the 'next' kernel
[16:12] <apw> as they are synced to upstream releases and not ours
[16:12] <tgardner> apw, I'm sure I care about a 3 month gap
[16:12] <tgardner> I'm *not* sure
[16:12]  * apw has assumed sarcasm
[16:13]  * ppisati bails for a bit
[16:13]  * smb would be using alsa backports at least on his media pc... I could probably change to an LTS backports kernel. But assumes much whining about any support that gets dropped
[16:20] <tgardner> apw, ogasawara: whats the story on powerpc flavours ? can we drop support for the old Apple G4 ?
[16:21] <ogasawara> tgardner: I think we were meant to chat with lifeless and jk about it
[16:21] <apw> tgardner, is that the 32bit non-smp job?  didn't jk do some work to confirm we didn't really need that
[16:21] <apw> ogasawara, get a WI made perhaps then we won't forget
[16:21] <ogasawara> tgardner: bah, not lifeless, luke
[16:22] <tgardner> can you guys run that ground ?
[16:22] <apw> ogasawara, i am thinking we want to resurect our power blueprint so that cking's work is visible
[16:22] <tgardner> that to ground *
[16:22] <apw> ogasawara, also i suspect we are going to have some work on boot speed which i suspect i'll want to make a new bleuprint to track; see any problems with me doing that
[16:23] <ogasawara> apw: sounds fine
[16:23] <cking> apw, that sounds like a good idea - needs to be trackable
[16:23] <apw> cking, have you done your WIs for your stuff yet ?
[16:23] <ogasawara> cking: let me see if I can find that blueprint
[16:23] <apw> ogasawara, it was power-management or something
[16:23] <cking> apw, nope, I'm draining my HWE worklist this week
[16:23] <apw> cking, ok
[16:23] <cking> all 37 mins left of it
[16:24] <apw> cking, :)
[16:24] <cking> not that I'm counting ;-)
[16:24] <apw> rm HWE-TODO
[16:24] <cking> oh yeah
[16:24] <apw> sleep 2160; rm HWE-TODO
[16:40] <ogasawara> cking: I couldn't find the existing one so I just made you a new blueprint.  I'll let you fill it in accordingly.  https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-power-management
[16:49] <cnd> bjf, do we still pull everything from upstream stable releases?
[16:49] <cnd> I've got a patch that is working its way through stable for macbook trackpads
[16:50] <tgardner> cnd, yes
[16:50] <bjf> cnd, yes
[16:50] <cnd> ok, thanks
[16:50] <bjf> cnd, which release you hoping it gets into ?
[16:50] <cking> ogasawara, thanks
[16:50] <cnd> bjf, it's in the review for the next one
[16:50] <cnd> 3.0.9 I think?
[16:50] <bjf> cnd, ok, oneiric then, yes we will pick that up
[16:51] <cnd> ok
[17:06] <bullgard4> http://kernelnewbies.org/Linux_2_6_26: "2.6.26 adds support for ... BDI statistics and parameters exposure in /sys/class/bdi, ... Linux 2.6.24 merged per-device dirty thresholds: The limits that the kernel put to the amount of memory that a process can "dirty" changed from being global to be per-device. 2.6.26 exposes a interface in /sys/class/bdi that allow to set several parameters....
[17:06] <bullgard4> ...There's another set of read-only parameters that are exposet in debugfs (debug/bdi/<bdi>/stats) " What does »BDI« stand for?
[17:14] <tgardner> bullgard4, block device interface ?
[17:14] <cnd> bullgard4, probably a debugger used for doing low level hardware bringup
[17:14] <cnd> wait, nm, that doesn't make sense given the rest of the comment
[17:14] <cnd> unless they are unrelated
[17:27] <smb> Documentation/ABI/testing/sysfs.class-bdi: "Provide a place in sysfs for the backing_dev_info object." 
[17:31] <bullgard4> tgardner, cnd, smb: Thank you very much for your help. --  I will continue snooping. 
[17:44] <broder> how frozen is the upstream kernel during the rc period? i have a patch i'd like to see get in (http://paste.ubuntu.com/734424/, based on https://lkml.org/lkml/2010/3/10/188), but i've never interacted with the lkml before and don't really know what i'm doing
[17:46] <broder> err, http://paste.ubuntu.com/734429/ would be the one actually rebased onto master, but whatever
[17:55] <tgardner> broder, you'll likely need to run it past the list and the maintainer.
[17:55] <tgardner> rtg@lochsa:~/proj/linux/linux-2.6$ scripts/get_maintainer.pl -f drivers/leds/led-class.c
[17:55] <tgardner> Richard Purdie <rpurdie@rpsys.net> (maintainer:LED SUBSYSTEM)
[17:55] <tgardner> linux-kernel@vger.kernel.org (open list)
[17:56] <broder> so just send it off and hope for the best? :)
[17:56] <tgardner> broder, you should check with Samuel Thibault that it hasn't already been reviewed
[17:57] <broder> tgardner: ok, thanks for the pointers
=== smb` is now known as smb
=== kamalmostafa is now known as kamal
[18:52]  * tgardner -> lunch
[19:23] <tgardner> apw, ogasawara: can you remember any reason why CONFIG_MEMSTICK_R592 is not enabled in either Oneiric or Precise ?
[19:23] <ogasawara> tgardner: no idea
[19:24] <apw> tgardner, nothing jumps out at me, its not in any of our groups we check regularly
[19:24] <tgardner> seems like it should have popped up in our config review
[19:24] <apw> it may be one we have on our list for review
[19:24] <tgardner> apw, well, we clearly missed it in oneiric
[19:25] <tgardner> bug #238208
[19:25] <apw> we didn't have the same tooling in oneiric, but ogasawara lets add a wi to investifate it
[19:25] <ubot2> Launchpad bug 238208 in linux "Need MemoryStick driver Ricoh R5C592 (part of R5C832/822chipset)" [Wishlist,Confirmed] https://launchpad.net/bugs/238208
[19:25] <ogasawara> apw: ack
[19:25] <tgardner> apw, I'm just gonna write a patch to enable it.
[19:29] <GrueMaster> bjf: Erm, arm Lucid is EOL.  No need for Bug 888698 .
[19:29] <ubot2> Launchpad bug 888698 in linux-fsl-imx51 "linux-fsl-imx51: <version to be filled> -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/888698
[19:29] <apw> || CONFIG_MEMSTICK_R592 || n || n || n || - || - || n || n || n || n || n || n ||  '''EXPERIMENTAL''' ||
[19:29] <apw> GrueMaster, until the buildd's are transitioned off on to panda we are stuck with supporting them
[19:29] <GrueMaster> grmbl.
[19:30] <apw> GrueMaster, they have _told_ me 'weeks', we shall see
[19:30] <tgardner> apw, isn't that inconsistent with policy ?
[19:30] <apw> tgardner, its experimental and not special cased
[19:31] <apw> if the option is dependent on EXPERIMENTAL then our normal policy is to not enable it,
[19:31] <tgardner> apw, oh, I thought we _were_ turning on experimental options if they were modules.
[19:31] <tgardner> we sure seem to have turned on a bunch so far
[19:31] <apw> we have tended to if they are very definatly only going to pop up with hardware
[19:32] <tgardner> well, this one counts then
[19:32] <apw> yep, and it sounds like MEMSTICK_* is a class of exceptions
[19:33] <apw> tgardner, its a bit frightening if that option has been available since jaunty and still EXP
[19:34] <tgardner> if it breaks, I'll let 'em keep both pieces
[19:35] <apw> yep
[19:35] <apw> i'm going through the annotations so i'll look see if there are any more patterns
[19:36] <apw> ogasawara, as we'll nearly be on final kernel by rally, do we want to have a re-config review, as we already have new problems introduced by -rc2.  i'll be adding WIs for them shortly
[19:36] <apw> (at rally)
[19:36] <ogasawara> apw: sounds like a good idea
[19:37] <apw> ogasawara, added to the agenda
[19:37] <ogasawara> apw: thanks
[19:38] <bjf> apw, have we reached out to upstream stable to see if they have any plans to support 3.2 ?
[19:38] <bjf> apw, also, have you heard anything about bugzilla.kernel.org coming back ?
[19:39] <apw> bjf, the only thing i've heard in that space is what jjohansen said about 'one per year' and i think that means we miss
[19:40] <apw> bjf, not heard a thing on bugzilla, though as people are only just getting back on at all i am not supprised
[19:40] <jjohansen> apw: I don't know that is really 1 per year, but that is the talk I heard
[19:41]  * jjohansen can't remember where he heard it though
[19:44]  * herton -> eod
[20:04] <apw> jjohansen, yeah, i was likely tipsy during that conv.
[20:08] <tgardner> apw, do you have some kvm runes that work on precise ? testdrive seems to have stopped working for me
[20:08] <kirkland> tgardner: hmm, what's wrong with testdrive?
[20:09] <tgardner> kirkland, can't find a display, -vga cirrus
[20:09] <kirkland> tgardner: hrmf?  how odd
[20:09] <kirkland> tgardner: you can edit that, fwiw
[20:09] <kirkland> tgardner: sudo vi /etc/testdriverc
[20:10] <tgardner> Running the Virtual Machine...
[20:10] <tgardner> 	kvm -m 1024 -smp 2 -cdrom /home/rtg/precise-server-i386-daily.iso -drive file=/home/rtg/.cache/testdrive/img/testdrive-disk-iZzs3g.img,if=virtio,cache=writeback,index=0,boot=on -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 -vga cirrus
[20:10] <tgardner> Could not initialize SDL(No available video device) - exiting
[20:10] <kirkland> tgardner: find the line that says "-vga cirrus"
[20:10] <kirkland> tgardner: and change it
[20:10] <kirkland> hallyn: ^
[20:10] <tgardner> to what?
[20:10] <kirkland> hallyn: what would be wrong with tgardner's kvm invocation?
[20:10] <kirkland> tgardner: you can try -vga std|vmware|cirrus
[20:10] <tgardner> I also had to figure out the pxe-virtio.bin problem
[20:10] <kirkland> tgardner: honestly, though, we need to figure out why cirrus isn't working
[20:11] <kirkland> tgardner: sudo apt-get install kvm-pxe ?
[20:12] <hallyn> kirkland, dunno "kvm -cdrom /iso/precise-mini-amd64.iso -boot d -vga cirrus" at least works for me
[20:12] <hallyn> i do have ipxe installed of course
[20:12] <tgardner> kirkland, lemme check if that fixes kvm-pxe
[20:13] <tgardner> kirkland, kvm-pxe is already the newest version. the issue is that qemu wants pxe-virtio.rom, not pxe-virtio.bin
[20:13] <kirkland> hallyn: mind troubleshooting that for tgardner ?
[20:15] <tgardner> kirkland, so hallyn's command works.
[20:15] <tgardner> even over 'ssh -X'. I also tried testdrive on the physical console.
[20:16] <hallyn> tgardner, can you remove 'boot=on' from your drive spec for hard drive in your command?
[20:17] <tgardner> hallyn, on the war kvm command? or testdrive ?
[20:17] <tgardner> raw*
[20:17] <hallyn> kvm command
[20:17] <hallyn> kvm -m 1024 -smp 2 -cdrom /home/rtg/precise-server-i386-daily.iso -drive file=/home/rtg/.cache/testdrive/img/testdrive-disk-iZzs3g.img,if=virtio,cache=writeback,index=0, -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 -vga cirrus
[20:17] <hallyn> uh, (sigh)
[20:18] <hallyn> kvm -m 1024 -smp 2 -cdrom /home/rtg/precise-server-i386-daily.iso -drive file=/home/rtg/.cache/testdrive/img/testdrive-disk-iZzs3g.img,if=virtio,cache=writeback,index=0 -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 -vga cirrus
[20:18] <hallyn> that
[20:18] <hallyn> tgardner, is this on an oneiric host?
[20:18] <tgardner> hallyn, precise host
[20:18] <hallyn> ok, i'm on oneiric host but with precise's kvm...
[20:19] <tgardner> so I reran 'sudo testdrive -u file://`pwd`/precise-server-i386-daily.iso' to populate the COW image and now its working.
[20:19] <tgardner> etf ?
[20:19] <tgardner> wtf?
[20:20] <hallyn> tgardner, i'll blame it on the kernel :)
[20:20] <tgardner> lemme go rerun this on the console.
[20:21] <hallyn> oh, i hadn't seen some of the history
[20:21] <hallyn> 'could not initialize SDL" - sounds like it may be an sdl lib problem then
[20:22] <hallyn> or weird perms
[20:23] <tgardner> hallyn, the console hates me, but I can run it over an 'ssh -X' session.
[20:23] <hallyn> i can try to reproduce on my precise laptop.  you just ran 'testdrive' and chose precise-i386?
[20:23] <tgardner> it paints a little slow, but its a server install so I don't really care
[20:24] <tgardner> hallyn, yes
[20:24] <tgardner> clean install from today
[20:24] <hallyn> ok, thanks. 
[20:24] <tgardner> plus archive updates
[20:24] <hallyn> I really do wish I could live my live without having to itneract with SDL
[20:24] <kirkland> sdl blows
[20:25] <kirkland> tgardner: thanks for the info;  when/if you ever find testdrive broken, poke hallyn and roaksoax
[20:25] <kirkland> tgardner: hallyn maintains the kvm pieces, roaksoax testdrive itself
[20:25] <tgardner> can do
[20:25] <kirkland> tgardner: it's *supposed* to be working at all times;  if it ain't, we wanna get it fixed ;-)
[20:26] <tgardner> kirkland, I was actually trying it out in order to verify that generic-pae still worked. next I'll try the same combo on a 64 bit host
[20:26] <kirkland> k
[20:26] <tgardner> still worked in kvm-qemu taht is
[20:27] <hallyn> tgardner, oh, right, i saw that thread, was curious myself
[20:55] <matthias_> Hi there. I'd like to report a kernel problem, however the command "ubuntu-bug -p linux" does not do anything :)
[20:57] <matthias_> Should I manually file a report or is there another recommended way?
[20:57] <tgardner> matthias_, thats a good start. would the nature of your kernel bug cause ubuntu-bug to stop working?
[20:58] <matthias_> No, I do not think so.
[20:58] <matthias_> My system is running. The problem is that I frequently see a bunch of annoying messages in my syslog. I wonder whether it is a hardware problem or a kernel problem.
[20:59] <tgardner> matthias_, seems like it ought to work. what release ? oneiric ?
[20:59] <matthias_> 11.10, fresh install
[21:00] <tgardner> matthias_, other folks have been using it.
[21:00] <matthias_> The problem is: I bought a new Laptop (Thinkpad T520) and received it today. Ubuntu runs, however I see the following errors:
[21:00] <matthias_> kernel: [  781.456768] ata4: irq_stat 0x00000040, connection status changed
[21:00] <matthias_> kernel: [  781.456775] ata4: SError: { CommWake DevExch }
[21:01] <matthias_> kernel: [  781.456787] ata4: limiting SATA link speed to 1.5 Gbps
[21:01] <matthias_> kernel: [  781.456794] ata4: hard resetting link
[21:01] <matthias_> kernel: [  782.177920] ata4: SATA link down (SStatus 0 SControl 310)
[21:01] <matthias_> kernel: [  782.193880] ata4: EH complete
[21:02] <tgardner> matthias_, one time, or repeating ?
[21:02] <matthias_> repeating frequently
[21:02] <matthias_> say every 20 seconds
[21:02] <matthias_> btw, thanks for your help!
[21:03] <tgardner> you could try the 3.1 kernel: http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-3.1.0-2-generic_3.1.0-2.3_amd64.deb
[21:03] <matthias_> So if it was a hardware problem I'd return the laptop to the dealer. But somehow I guess that it is a kernel problem (since the system is running)
[21:04] <tgardner> it might be power management messing with your link. 
[21:05] <matthias_> tgardner, software or hardware related?
[21:05] <tgardner> software
[21:06] <matthias_> Would you think it is worth to report a bug?
[21:06] <tgardner> matthias_, yep
[21:07] <matthias_> The interesting thing is that someone with another T520 reported a similar problem: http://comments.gmane.org/gmane.linux.kernel/1207661
[21:10] <matthias_> tgardner, would you recommend me to file the bug manually or do you have an idea how to get the "ubuntu-bug" running?
[21:10]  * ogasawara lunch
[21:10] <tgardner> matthias_, manually
[21:11] <matthias_> thanks, and sorry for the many questions ;)
[21:32] <matthias_> ok, filed the bug (#888764)
[21:37] <hallyn> tgardner, yeah i386 precise starts fine for me on just-upgraded precise
[21:37] <hallyn> (boy that was a slow iso sync)
[21:41] <tgardner> hallyn, well, I'm installing a 64bit precise host, so I'll see if that is any different
[22:05] <apw> tgardner, i have a precise install but that was an oneiric-i386 which i think upgraded it to precise
[22:06] <apw> (in a KVM i mean)
[22:06] <tgardner> apw, I've now a 64bit precise host installing a PAE server ISO
[22:06] <apw> ahh, i see
[22:06] <apw> i guess i have an early enough kernel to have generic anyhow
[22:06] <tgardner> apw, I believe this combo addresses cjwatson's concerns about qemu not working with PAE
[22:07] <apw> ahh is 32 bit only really only 32bit not pae capable, interesting
[22:07] <tgardner> apw, you've just bent my mind
[22:08] <apw> is 32bit kvm not actually pae
[22:08] <tgardner> I was really only concerned that PAE work in all cases
[22:10]  * tgardner is outta here
[23:15] <ppisati> have we ever released a kernel for the n900?
[23:32] <jjohansen> ppisati: nothing official that I know of
[23:34] <ppisati> uhm