[00:36] <MTecknology> Is it possible to see what kernel driver is being used for something being listed in lsusb but not in lspci?
[01:01] <paultag_> cnd_swap, poke -- you around?
[01:03] <paultag_> cnd_swap, I've been having a kernel issue with rt2500pci -- reported LP#456977 -- any chance I could bribe you with a few beers to look into it?
[01:05] <jjohansen> paultag_: he isn't around right now, should be in tomorrow
[01:05] <paultag_> jjohansen, cheers, thanks
[01:14] <cnd_swap> paultag_: heh, rt2500pci has some real issues
[01:15] <paultag_> cnd_swap, lucky me, I had it lying around, haha
[01:15] <cnd_swap> I've looked at some of them before, but it seems to be an issue more upstream
[01:15] <paultag_> cnd_swap, aye, well no biggie. I'll work that hack into my init script
[01:15] <paultag_> scripts *
[01:15] <cnd_swap> if you find it works better in the maverick or some mainline kernels, then we could look into getting a fix into lucid
[01:16] <paultag_> cnd_swap, I think it's just a driver issue. This one looks like a power saving mode issue
[01:16] <cnd_swap> but we don't really have anyone on hand with tons of wireless driver experience
[01:16] <paultag_> cnd_swap, yeah, I can understand that for sure
[01:16] <cnd_swap> paultag_: yeah, if you find a patch upstream, we'll definitely take a look
[01:16] <cnd_swap> unfortunately, I'm kinda swamped in the short term with other work
[01:16] <paultag_> cnd_swap, I'll be on the lookout -- thanks Chase :)
[01:16] <paultag_> cnd_swap, don't sweat it
[01:16] <cnd_swap> maybe someone else on the team could take a look?
[01:17] <cnd_swap> paultag_: but I'd recommend testing out the maverick kernel
[01:17] <cnd_swap> just to see if it helps at all
[01:17] <cnd_swap> kamal: you still around?
[01:17] <kamal> cnd_swap: yes, hiya
[01:17] <paultag_> cnd_swap, I'll pull it down and give it a go
[01:17] <cnd_swap> kamal: save me!
[01:18] <cnd_swap> kamal: actually, lets chat on #hwe
[01:18] <paultag_> cnd_swap, shall I join you guys?
[01:27] <ribo> hi guys, I'm having a problem that is killing all my md arrays and generally causing a lot of pain that is fixed here: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commit;h=91b25002bd58f55207e4662a611a6cded4ef9834
[01:27] <ribo> I'm using lucid server, and it's not backported in, apparently
[01:28] <ribo> people here: https://bugzilla.kernel.org/show_bug.cgi?id=13594 say it's fixed in .34
[01:28] <ubot2> bugzilla.kernel.org bug 13594 in SCSI "SMART responses for SATA disks on SAS get interpreted as errors" [Normal,New]
[01:45] <pgraner> ribo: that won't be in Lucid since its a .34 commit, you can open a LP bug and send an email to the kernel-team@lists.ubuntu.com mailing list with the commit id and request that it be added as an SRU along with the LP bug number and it will be considered
[01:47] <pgraner> ribo: https://wiki.ubuntu.com/KernelTeam/StableKernelMaintenance#SRUs/bugs
[01:53] <ribo> ok, thanks; just filed the LP bug
[02:01] <ribo> I guess I'll build from source as a stopgap
[02:19] <jjohansen> ribo: another option is to use the maverick kernel which is currently .34 based
[03:07] <panda|x201> jk-, ping
[03:08] <jk-> hi panda|x201
[03:09] <jk-> so there are two options for fixing 557742 - we either get a fix into the kernel package, or update the alsa code in linux-backports-modules
[03:09] <jk-> updating the kernel package will probably mean that the patch has to go into the upstream stable tree
[03:10] <panda|x201> jk-, what's linux-backports-modules package for? we will stick on current version 2.6.32? so we need to backport from new kernel?
[03:11] <jk-> that's right, it's stuff backported from newer kernels to work with the currently-release .32 kernel
[03:13] <panda|x201> so "updating the kernel package will probably mean that the patch has to go into the upstream stable tree", so upstream here means upstream of ubuntu kernel repository?
[03:13] <jk-> yes
[03:14] <jk-> if you can identify a small non-intrusive fix, then we may be able to use that in the main kernel package - see https://wiki.ubuntu.com/KernelTeam/KernelUpdates
[03:23] <panda|x201> jk-, we put all the audio drivers - alsa code into a separate package linux-backports-modules?
[03:24] <jk-> that's correct
[03:24] <panda|x201> jk-, we always rely on DKMS package to deal with backported module?
[03:25] <jk-> no, DKMS is only used in certain cases, generally only by the OEM team
[03:26] <panda|x201> jk-, em, looks like audio drivers are not part of the kernel package, but they are actually stored in the same repository, but just build separately?
[03:28] <jk-> the audio drivers are part of the kernel package.
[03:30] <jk-> the *backported* audio drivers are in the linux-backports-modules-alsa-$VERSION package
[03:35] <jk-> so the version of the alsa tree in the current linux-backports-modules is 1.0.22.1, but the fix for that bug has gone into 1.0.23
[03:45] <panda|x201> jk-, sounds confusing, then shall we upgrade alsa tree as well on 10.04? or you prefer back port a patch from alsa 1.0.23 to 1.0.22.1?
[03:46] <jk-> we will not upgrade the alsa tree in the main kernel
[03:47] <jk-> depends what the backported patch looks like
[03:47] <jk-> if it is small and unintrusive, it may be able to go into the 10.4 kernel
[03:49] <panda|x201> jk-, ok, so which team take care of alsa? let's forward such a backport requirement to foundation team?
[03:49] <jk-> no, the kernel team maintains the alsa modules
[03:51] <jk-> (the userspace stuff in the alsa-* packages is not related to this bug)
[03:54] <panda|x201> jk-, OK, so not upgrade the alsa tree in the main kernel is because this upgrade might cause other driver stop working?
[03:54] <jk-> it could cause all sorts of other stuff to stop working :)
[03:55] <panda|x201> jk-, well, I will first start from a general diff between two version of alsa-driver and then focus on what have been modify on X201 driver
[03:56] <panda|x201> jk-, if we can figure out a easy-to-fix patch against 1.0.22.1 to fix, then that's our first choice?
[03:56] <jk-> I would suggest looking at Jerone's DKMS file, to see if you can create a small patch based on that
[03:57] <panda|x201> jk-, BTW: think-acpi is also maintained by kernel team?
[03:58] <jk-> it's a kernel module, so yes :)
[03:58] <panda|x201> jk-, OK, let me check with Jerone's DKMS file.
[04:01] <CoolAcid> Good Day - A quick Q (Hope I'm in the right place) regarding a fix to the kernel - specificly getting a PCI device ID added to a driver. I already attempted (last year) to talk the the maintainer but didn't get very far. So I'm looking for 2 things - 1, Get the update into Ubuntu Kernel, 2 get it into mainline stream. 
[04:01] <jk-> panda|x201: there's a few changes in that patch to the patch_conexant.c file, they look interesting
[04:02] <jk-> CoolAcid: try 2) first, then 1) should happen automatically :)
[04:03] <CoolAcid> jk-: Sigh.. I was afraid of that ;)
[04:04] <jk-> CoolAcid: you shouldn't be afraid of that :)
[04:04] <ribo> jj-afk: thanks, I'll do that
[04:04] <CoolAcid> which means I need to build a ubuntu kernel to get working, and then a new kernel for upstream... :)
[04:04] <CoolAcid> Oh - git isn't my friend..
[04:05] <CoolAcid> actually, the patch *should* work on vanila once I build it from ubuntu.. so maybe i'll try that.. 
[04:05] <CoolAcid> any good docs on submitting patches to the tree?
[04:05] <jk-> yeah, I don't think there should be many changes between the two if it's just a PCI ID.
[04:06] <jk-> to the upstream tree? try the Documentation/SubmittingPatches file
[04:06] <CoolAcid> sigh - its been so long since I hacked @ kernel..
[04:10] <jk-> panda|x201: https://patchwork.kernel.org/patch/92496/ looks interesting
[04:14] <jk-> panda|x201: upstream commit here: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff;h=7b2bfdbc0dee5a321b5c02febe157adebd33ab3a
[04:16] <panda|x201> jk-, yeah, thanks, but seems those patches are not submitted from Lenovo themselves?
[04:16] <jk-> panda|x201: that's correct
[04:28]  * panda|x201 start to pull ubuntu-kernel slowly ...
[05:22] <jk-> brb, reboot
[08:22]  * apw waves
[08:24]  * lag moons apw
[08:24] <smb> mmorning
[08:25] <jk-> smb!
[08:25] <lag> Hey smb :)
[08:25] <jk-> apw!
[08:25] <smb> woha
[08:26] <amitk> :)
[08:30]  * smb brings his comm channels online
[09:00] <amitk> lool: Can the versatile flavour use general drivers or only the specific ones the qemu supports? I'm wondering if we should enable all other drivers as modules?
[09:13] <lool> amitk: I think I had enabled a lot of crack in the lucid config already
[09:15] <amitk> lool: well, lots of drivers are disabled. But I'm wondering if it makes sense in a virtual environment
[09:16] <amitk> apw: Meego will use btrfs by default: http://lwn.net/Articles/387196/
[09:16] <apw> yeah a lot of things are going that way amitk 
[09:16] <lool> amitk: I thin kI had enabled a bunch of USB drivers
[09:16] <apw> it cirtainly will be an option for us, depending on how the grub support goes, ie how quick we get it it may yet be default for us
[09:57]  * apw shouts at the wiki ... faster dammit
[10:00] <tankenmate> top - 10:00:18 up 79 days, 20:07, 16 users,  load average: 2293.53, 867.84, 311.58
[10:00] <tankenmate> now... that's a load averge...
[10:01]  * lag shouts at the wiki ... start working search
[10:04]  * lag has been conned by his ISP
[10:05]  * lag is calling his ISP to moan about his outrageously slow internet connection 
[10:06] <amitk> lag: don't judge your ISP too harshly against wiki.ubuntu.com and launchpad.net speeds
[10:08] <lag> amitk: I'm not: http://www.speedtest.net/result/820427581.png
[10:10] <lifeless> check your wifi too
[10:10] <lifeless> can easily cripple things if you have interference
[10:15] <lool> amitk: If you need any change either because you need the driver or because it makes maintenance easier, go for it; in lucid, I did try to enable things which remotely made some sense to me, but I didn't enable buses which versatile didn't have for instannce
[10:19] <amitk> lool: I mostly noticed it while enabling the mainline version of the omap kernel, lots of differences between the versatile and omap configs due to drivers being disabled in the former
[10:34] <popey> JFo: when you get a moment, could you look at bug 572868 . Is it a kernel bug or some other part of the stack?
[10:34] <ubot2> Launchpad bug 572868 in ubuntu (and 1 other project) "Lucid Live CD/USB freezes shortly after start (affects: 19) (heat: 82)" [Undecided,Confirmed] https://launchpad.net/bugs/572868
[10:49] <amitk> lag: that is definitely slow, call the ISP :)
[10:53] <lag> amitk: Yup!
[11:06] <cking> lag, your connection to the internet is it over copper or a wet piece of string?
[11:07] <cking> ;-)
[11:07] <lag> cking: You're meant to dampen the string?
[11:07] <lag> cking: That could be my problem 
[11:07]  * lag fetches the watering can
[11:09] <lag> No joy! Now it just looks like I couldn't make it to the toilet in time, and left a trail 
[11:09] <cking> the mind boggles
[11:09] <lag> Quite
[11:31] <apw> https://wiki.ubuntu.com/Kernel/Debugging/HighTemperatures#preview
[11:31] <apw> smb, cking ^^
[11:39] <amitk> apw: do you know if perf userspace works with arm now?
[11:41] <apw> i do not yet know, i have it on my list for this week to get it enabled and find out, i should know today
[11:43] <apw> lag, git clone --bare /srv/kernel.ubuntu.com/git/ubuntu/ubuntu-lucid.git ubuntu-lucid.git
[11:44]  * lag copies, pastes and closes eyes
[11:52] <apw> lag so you want something like the following locally where you are going to push from:
[11:52] <apw> git remote add zinc ssh+git://ljones@zinc.ubuntu.com/srv/kernel.ubuntu.com/git/lag/ubuntu-lucid.git
[11:54] <cking> lag, http://smackerelofopinion.blogspot.com/2009/08/git-version-control-books.html
[12:26] <lag> apw, cking: git config push.default nothing
[12:37] <apw> cking-afk, the images in that lin arn't working, well one is one not
[12:40]  * smb seems to listen to the soundtrack of it :-P
[12:41] <cking-afk> apw, ta, will fix it
[12:45] <smb> apw, You want to mention sensors and its setup or you think that gets too complicated. Not all ACPI exports a usable thermal zone
[12:46] <smb> apw, Re: wiki previeww
[12:46] <apw> smb, if you have amchines where there is a benefit sure it can be an option
[12:46] <apw> its much more complex and requires s/w installed tho
[12:46] <smb> unfortunately yes
[12:47] <cking> It may be worth adding the sensors info as as foot note
[12:47] <smb> There is the dreaded aa1, though probably that had not any issues
[12:47] <cking> smb, what's the aa1?
[12:48] <smb> cking, acer aspire one
[12:48] <cking> acer awful one
[12:50] <smb> apw, Beside of that it looks good to me
[12:50] <cking> +1 from me too
[12:51] <cking> s/scratch re-install/clean re-install/ perhaps?
[12:52] <smb> Maybe lag needs to review. I am too much used to anglish, I just correct it in my mind. :-P
[13:41] <apw> cking, perhaps full reinstall
[13:44] <apw> smb, cking et al, do any of you remember manjo talking about the new firewire stack and what the outcome was
[13:44] <smb> apw, I remember darkly
[13:45] <apw> dimly or vaguely :)
[13:45] <smb> I believe to remember some note saying its in Maverick
[13:45] <smb> apw, both. :-P
[13:45] <apw> :)
[13:49] <pgraner> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/583099
[13:49] <ubot2> Launchpad bug 583099 in linux (Ubuntu) "Netbook runs hot with Lucid (affects: 1) (heat: 6)" [High,Confirmed]
[13:52] <apw> pgraner, so what was the outcoming
[13:57] <apw> sudo apt-get install ubuntu-desktop^
[14:01] <JFo> pgraner, crap! only 2 features?! we need like 12. :)
[14:02] <smb> lag, Heres JFo. JFo heres lag. He wants to know whats hot in the bug world. :)
[14:03] <JFo> heh, everything ;-)
[14:03] <JFo> lag, what is your specific interest subsystem wise?
[14:03] <JFo> graphics, video, wireless?
[14:03] <lag> JFo: Break me in gently 
[14:03] <JFo> something like that 
[14:03] <JFo> lag, I'll see what I can do ;)
[14:04] <lag> JFo: It's all just code
[14:04] <lag> I'm more interested in the procedures of BUGFIX atm
[14:04] <lag> So something light would be appreciated 
[14:05] <JFo> ok
[14:05] <JFo> so anything you have looked at that interests you?
[14:05] <JFo> you want to do bugfix rather than triage?
[14:06] <tgardner> JFo, sic him on bug #583128
[14:06] <ubot2> Launchpad bug 583128 in linux (Ubuntu) "SMART responses for SATA disks on SAS get interpreted as errors (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/583128
[14:06] <smb> JFo, I guess bugs with patches might be a good training ground
[14:06] <lag> Excuse my ignorance, but what's the difference?
[14:07] <JFo> tgardner, will do :)
[14:07] <lag> Patches == good
[14:07] <JFo> and I think you are right smb, we can do that next :)
[14:07] <JFo> so lag, take a look at the bug tgardner dropped in
[14:07] <JFo> and let us know your questions
[14:08] <smb> lag, Triage is battle with users to get information. bugfix is getting an upstream patch and let it test. ;-P (put a bit over simplified)
[14:08] <lag> Oh, you'll get questions ;)
[14:08] <JFo> heh, I look forward to it
[14:08] <JFo> smb, I think that was perfectly described
[14:15] <apw> pgraner, from the machine as it is in the lucid-upgrade it is looking 'good' ie as good as the lucid-fresh
[14:17] <cking> http://kernel.ubuntu.com/git?p=cking/debug-code/.git;a=commit;h=257d32b05f6dad8c2a1a0726ae2b66aa6f636b9e
[14:21] <apw> Geeqie 1.0beta2, This is an alpha release.
[14:21] <apw> !?!
[14:22] <jk-> soooo, what's the policy on l-b-m? should I poke someone to get alsa upgraded to the latest release?
[14:22]  * smb hides
[14:22] <apw> jk-, lbm for which release
[14:23] <smb> I guess the one of Lucid
[14:23] <smb> The one I have not uploaded yet
[14:23] <jk-> apw: lucid
[14:23] <apw> thats stuck wiating for a preceesding update to go out i think
[14:23] <jk-> smb: so you have an update pending?
[14:23] <jk-> oh, cool
[14:24] <smb> Ok, Given that there seems to be no abi bumper I could prepare and upload now
[14:24] <smb> jk-, Yes there is one pending
[14:25] <tgardner> smb, lucid lbm also needs a compat-wireless update
[14:25] <tgardner> luis announced a 2.6.34 stable yesterday
[14:26] <smb> tgardner, Is there some pull request in the mail? Oh ok maxybe not :)
[14:26] <tgardner> smb, maybe not :)
[14:26] <jk-> smb: is that including alsa 1.0.23?
[14:26] <smb> tgardner, Should I wait for you then? 
[14:26] <smb> jk-, So it says in the log
[14:26] <jk-> smb: you rock
[14:26] <smb> jk-, Nah, I am just the librarian. :)
[14:26] <tgardner> smb, I'm not gonna get to it for a couple days yet. I wanna finish this LTS backport stuff
[14:27] <smb> tgardner, Ok, I guess then I put the current form into proposed. One upload more or less should not matter for lbm
[14:31] <jk-> smb: to prevent future questions, is there a way I could have checked that for myself?
[14:31] <tgardner> jk-, look at the lbm repo?
[14:31] <JFo> apw bug 6290
[14:31] <smb> jk-, You could log at the git web on kernel.ubuntu.com
[14:31] <ubot2> Launchpad bug 6290 in kino (Ubuntu) "DV capture over Firewire is broken (no rights for /dev/raw1394) (affects: 17) (dups: 10) (heat: 226)" [Low,Triaged] https://launchpad.net/bugs/6290
[14:34] <jk-> ok, so is the git repo is synced with what's in the archive manually?
[14:34] <tgardner> jk-, the git repo is the source of what goes into the archive, just like the kernel
[14:35] <jk-> sure, but there may be a delay between stuff hitting the repo and stuff hitting the archive, right?
[14:35] <smb> jk-, As tgardner says. I am just using that content to create the upload package for proposed
[14:35] <jk-> riiiight.
[14:36] <smb> jk-, It hits the repo first
[14:37] <tgardner> jk-, there can be a substantial delay between repo updates and the source package upload. 
[14:37] <apw> JFo, i have a reply in my editior now for that, that i will copy to ubuntu-kernel-team
[14:37] <apw> tgardner, i am replying on the firewire thingy
[14:37] <JFo> apw, cool
[14:37] <JFo> do I need to watch whatever 'kino' packages?
[14:38] <JFo> because as it stands, I have no clue what that is :)
[14:38] <JFo> there are apparently 32 bugs opened on it. Most of them are new
[14:39] <JFo> or rather in the new state
[14:39] <jk-> and is that just the time between the commit and smb uploading the package? or is there some queue in the process there, after smb has done the upload?
[14:40] <apw> JFo, kino is a userspace tool, so no
[14:40] <JFo> ok
[14:40] <apw> jk-, lbm is typically uplaoded in lock step with the kernel and the kernel uploads take time and testing
[14:40] <tgardner> jk-, it mostly has to do with smb's workload, -security updates, etc. its non-deterministic
[14:40]  * JFo moves on :)
[14:41] <apw> and if we have things like security for example in the way it can take much longer
[14:41] <smb> jk-, yep. and there is also the delay between proposed and updates
[14:41] <smb> jk-, If there are other things pending which might lead to require another upload to lbm as well I can decide to delay
[14:42] <jk-> the non-determinism is fine, just wanting to know what's coming without bugging smb :D
[14:43] <smb> jk-, Look in proposed and look into the repo. Everything else requires you bugging me 
[14:43] <jk-> ok
[14:46] <ogra> apw, geeez ! you plan to fix firewire ?!? what are our users supposed to complain about then ?
[14:46] <jk-> ptrace
[14:46] <ogra> ah, k 
[14:46] <ogra> phew
[14:48] <apw> manjo, hey ...
[15:09] <pgraner> JFo: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies
[15:20] <manjo> apw, hi
[15:20] <apw> manjo, do i recall correctly that you were championing the idea of using the new firewire stack for Maverick
[15:20] <manjo> yes
[15:20] <apw> good, i've added a task to the misc blueprint to cover that
[15:21] <manjo> I had created a blueprint
[15:21] <apw> if we are going to make such a large change it needs to really be in place for apl
[15:21] <apw> alpha-1
[15:21] <apw> manjo, whats the blueprint name
[15:21] <apw> i've not seen it on our lists anywhere
[15:22] <manjo> https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-firewire-stack
[15:22] <manjo> I created this and pointed ogasawara to it 
[15:25] <apw> hrm why is this not on the list
[15:26] <apw> manjo, ok thats casue the format was wrong... think i've fixed it up, we'll see in an hour
[15:27] <manjo> ok
[15:27] <apw> manjo, i thought we had both stacks enabled in the kernel already, that it was purely a userspace decision which was in use
[15:29] <manjo> currently the default is old stack, we need to enable the new stack and blacklist the old one , it does not involve much effort todo
[15:29] <manjo> apw, it should take all of 5mts todo this item
[15:30] <apw> i beleive the new is already enabled kernel side
[15:30] <apw> and hidden by modprobe blacklists
[15:30] <apw> so i think the switch is all userspace from our point of view
[15:33] <JFo> pgraner, do you want me to create a blueprint for the Launchpad stuff we discussed with jml since he seemed to think they may not get to everything this cycle?
[15:34] <JFo> or rather since there are only 2 features we can request as a team
[15:35] <apw> manjo, we are on mumble for vcm
[15:35] <manjo> apw, ack
[15:54] <manjo> my mic does not work
[15:56] <cking> http://cgi.ebay.co.uk/PC-Computer-USB-Single-Action-Foot-Switch-Pedal-HID-NEW-/280505820192?cmd=ViewItem&pt=LH_DefaultDomain_3&hash=item414f732420
[15:57] <cking> apw ^^
[15:57] <jk-> new modifier key for emacs?
[15:57] <lag> cking: :D
[15:58] <lag> jk-: Push-to-talk on chatting software :)
[15:59] <jk-> ah :)
[16:02] <manjo> hehe
[16:08] <smb> manjo, You will probably need to remind me of the bug number and subject of the email for your sru
[16:08] <manjo> smb, will do.. just a sec 
[16:09] <smb> manjo, best do it in email. my irc brain is limited
[16:09] <manjo> smb, yep will email reminder you 
[16:36] <cwillu_at_work> I don't suppose anyone has a lucid kernel with CONFIG_DEBUG_PAGE_ALLOC enabled kicking around?
[16:37] <cwillu_at_work> I've been running btrfs as the rootfs on a couple of my machines for 10 months or so;  after updating one of them to lucid and recompiling btrfs from their recommended repo (-unstable), I get instability in that machine
[16:37] <ogasawara> apw: I see alpha1 is nearing (june 3).  how many days before the milestone did you typically do the final kernel upload for the milestone? 2 days minimum?
[16:38] <apw> ogasawara, we are on mumble
[16:38]  * ogasawara joins
[16:38] <cwillu_at_work> cmason in #btrfs suggested that as a next step of debugging it
[16:39] <ogasawara> apw: hrm, mumble doesn't like my password now
[16:40] <apw> ogasawara, switched to SSO instead, change your username to your launchpad _email_
[16:40] <smb> ogasawara, Your email address and launchpad pw
[16:40] <apw> and use that password
[16:40] <ogasawara> ah, thanks
[16:40] <tgardner> ogasawara, be sure to leave your speakers on so we can annoy everyone in your house
[16:41] <ogasawara> heh
[16:47] <JFo> <-lunch
[16:49] <jj-afk> hey smb
[16:50]  * jjohansen is looking for his mike
[16:53] <apw> heh
[17:05] <jjohansen> apw: nope
[17:05] <jjohansen> my wife cleaned up the desk while at uds
[17:05] <jjohansen> hehe :)
[17:30] <jjohansen> hrmm I have lost dns
[17:33]  * jjohansen goes to reboot the router
[17:37] <pmatulis> smb: howdy, any movement on bug 513848 (fix released for jaunty and karmic)?
[17:37] <ubot2> Launchpad bug 513848 in linux (Ubuntu Karmic) (and 1 other project) "[karmic] CPU load not being reported accurately (affects: 1) (heat: 14)" [Low,Fix committed] https://launchpad.net/bugs/513848
[17:37] <smb> pmatulis, Jaunty?
[17:38] <pmatulis> smb: well the bug says nominated for jaunty
[17:38] <smb> pmatulis, I think I have commited something to Karmic. Must check
[17:38] <pmatulis> smb: and then only fix committed for karmic, not released
[17:39] <smb> pmatulis, Give me a second to look, I don't know right out of my head
[17:40] <smb> So from the log I think it is in updates for Karmic
[17:40] <smb> pmatulis, I would not do it for Jaunty if there is not a really pressing reason
[17:40] <pmatulis> smb: so the status should be 'Fix Released' for Karmic
[17:40] <smb> pmatulis, The effect is not really critical
[17:40] <smb> pmatulis, it is
[17:41] <smb> pmatulis, oh bugger
[17:41] <pmatulis> smb: why does it show 'Karmic  Fix Committed' ?
[17:41] <smb> pmatulis, sorry
[17:41] <smb> My fault
[17:41] <smb> I got confused
[17:42] <smb> pmatulis, Ok so it is only committed for Karmic
[17:42] <smb> pmatulis, I did not upload fresh as there is a securtity upload in progress
[17:43] <smb> pmatulis, As soon as that is out I will upload the missing things
[17:43] <smb> pmatulis, Its hard to give a good ETA but hopefully the week after next week
[17:44] <pmatulis> smb: thanks for the update.  just trying to mop up these support cases that are all over the floor here
[17:45] <smb> pmatulis, No worries, there is a lot of stuff lying around after several travels
[17:45] <tgardner> kees, whats a good default group to use when migrating dchroot to Lucid schroot ?
[17:48] <manjo> apw, https://ieee1394.wiki.kernel.org/index.php/Juju_Migration
[18:50] <manjo> apw, did I read the news about suse rebasing their kernel to latest for SLES ?
[18:51] <manjo> SLES 11 SP1, Novell is rebasing the kernel on the Linux 2.6.32 version. 
[18:52] <jjohansen> manjo: where did you see that?
[18:53] <manjo> http://www.serverwatch.com/news/article.php/3883226/Novell-SUSE-Linux-Enterprise-11-Updates-Kernel-Virtualization.htm
[18:58] <jjohansen> manjo: not really all that surprising, the plan a year ago was that they would roll out new kernels for hwe and if certifications required older kernels that they would run them virtualized under the newer kernel
[18:59] <jjohansen> there used to be an awful lot of work backporting features to older kernels which would endup breaking the kernel abi anyway
[18:59] <manjo> ie custom kernel per app :) 
[19:00] <jjohansen> well, just for those whose certifications require it
[19:00] <jjohansen> :)
[19:00] <popey> lastlog popey
[19:00] <popey> bah
[19:01] <popey> JFo: when you get a moment, could you look at bug 572868 . Is it a kernel bug or some other part of the stack?
[19:01] <ubot2> Launchpad bug 572868 in ubuntu (and 1 other project) "Lucid Live CD/USB freezes shortly after start (affects: 19) (heat: 82)" [Undecided,Confirmed] https://launchpad.net/bugs/572868
[19:26] <JFo> looking
[19:27] <JFo> sorry for the delay, was trying to have some chicken soup
[19:31] <JFo> popey, looks like they are affected by several issues
[19:33] <JFo> the nomodeset indicates a potential kernel issue
[19:33] <JFo> but the other issues are something else
[19:34] <JFo> and what is a 'keyboard equals human' icon?
[19:37] <cnd> who has the ability to set blueprint priorities?
[19:37] <cnd> the drafter, the approver, or someone else?
[19:37] <cnd> I'm the assignee for a bp, but I can't change it
[19:37] <JFo> probably ogasawara or pgraner cnd
[19:38] <JFo> more likely pgraner 
[19:38] <cnd> JFo: this is actually a dx bp
[19:38] <JFo> hmmm
[19:38] <JFo> not sure then
[19:38] <cnd> https://blueprints.launchpad.net/ubuntu/+spec/dx-m-multi-touch-and-kernel
[19:38] <cnd> I'll just send a note to both the approver and the drafter then
[19:38] <JFo> pgraner, should still have the authority
[19:38] <JFo> k
[19:38] <ogasawara> cnd: I might have the magic power, what fields do you want set and to whom?
[19:39] <cnd> ogasawara: prio just needs to be set to something reasonable, maybe medium?
[19:39] <ogasawara> cnd: ack, done
[19:39] <cnd> ogasawara: thanks!
[19:40] <cnd> ogasawara: can you set https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-tracing-support to low?
[19:44] <ogasawara> cnd: done
[19:45] <cnd> awesome
[19:45] <ogasawara> cnd: it's odd that you as the assignee can't change those fields
[19:45] <ogasawara> seems like a flaw
[19:45] <cnd> ogasawara: odd that I myself can't for some reason, or odd that launchpad doesn't let assignees in general do it?
[19:45] <ogasawara> cnd: that launchpad in general doesn't allow assignees to change it
[19:46] <cnd> yeah...
[19:57] <apw> its also odd that ogasawara can do it to some degree
[19:58] <ogasawara> apw: agreed, not sure what special privilege I picked up along the way 
[19:58] <ogasawara> apw: as you should also have the same, if not more than I
[19:59] <apw> ogasawara, and i cirtainly don't
[20:05] <JanC> JFo: the "keyboard equals human" icon is a somewhat undecipherable image the live CDs shows to tell users that they need to press a key to get to the bootloader menu where they can change boot options, etc.  ;)
[21:16] <kees> tgardner: I'm not sure I understand what you mean.  which group?  (I've never set up dchroot...)
[21:16] <tgardner> kees, ok, never mind then.
[21:17] <kees> tgardner: heh okay.  :)
[21:17] <kees> tgardner: I just use mk-sbuild to create all my schroot chroots.  generally really fast if you have a local or cached mirror.
[21:18] <tgardner> kees, ok, I'll look into that
[21:29] <apw> tgardner, did you have a recipie for the armel chroot magic using qemu ?
[21:29] <tgardner> apw, yeah, I got that working, but I'm also messing around with the dchroot to schroot migration
[21:30] <tgardner> whilst these damn LTS backport builds are running.  there are no shortcuts when you're mucking with control files
[21:31] <kees> apw: https://wiki.ubuntu.com/ARM/RootfsFromScratch  <- has some notes
[21:31] <kees> apw: but the easiest by far is just "mk-sbuild --arch armel maverick" etc
[21:34] <apw> kees, were does mk-sbuild live
[21:34] <tgardner> ubuntu-dev-tools
[22:36] <ccheney> when updating the kernel and the abi bumps say in a security release, we also need the meta packages updated, right?
[22:41] <ccheney> ogasawara, ping
[22:43] <ogasawara> ccheney: yep, when a security update bumps the abi, the linux-meta package will also get an abi bump
[22:43] <ccheney> ogasawara, ok
[23:41] <wyatt> hi