[05:28] <osmosis> is there still a xen kernel supported ?
[05:29] <cooloney> osmosis, for official release, the answer is no
[05:29] <cooloney> osmosis, no such xen flavor
[05:30] <osmosis> cooloney: then why does jaunty have a xen-hypervisor package ?
[05:30] <osmosis> http://packages.ubuntu.com/jaunty/xen-hypervisor-3.3
[05:32] <cooloney> osmosis, sorry, no idea about that package
[05:32] <cooloney> osmosis, but for Jaunty kernel, there is no such -xen kernel
[05:34] <cooloney> osmosis, it looks like this package can only run on Hardy 2.6.24-xen kernel
[05:34] <cooloney> osmosis, intrepid is 2.6.27 and Jaunty is 2.6.28
[05:38] <osmosis> strange that is still in the jaunty repo
[08:58] <smb> As far as I can see the patch for the image flipping would at least be limited to the quirked cams. So, the impact is rather small. On the other hand it is a deviation from upstream. Debatable it is some sort of hardware issue... Not really convinced nor opposed on that. Which series is that asked for?
[08:59] <smb> bug 224559 for reference
[08:59] <ubot3> Malone bug 224559 in linux-ubuntu-modules-2.6.24 "Image on webcam is upside-down" [Undecided,Invalid] https://launchpad.net/bugs/224559
[09:00] <amitk> smb: for Hardy and perhaps Intrepid/Jaunty
[09:04] <smb> Likely if given in for Hardy, it is expected for all of them...
[10:26] <cooloney> apw, one question about bug 302509
[10:26] <ubot3> Malone bug 302509 in linux "Dell Digital TV Receiver DVB-T devices based on sms1xxx are not correctly identified" [Medium,Fix released] https://launchpad.net/bugs/302509
[10:27] <apw> cooloney, hi
[10:27] <cooloney> it was set to fixed release
[10:27] <cooloney> why change it back to triage?
[10:27] <cooloney> and you set it's importance to medium
[10:28] <apw> cooloney, it was set to fix-released by the janitor, and it still is, in Intrepid
[10:28] <apw> the Triaged task is the development task, the what was Jaunty and now is Karmic task
[10:28] <cooloney> so that means for jaunty is triage?
[10:28] <apw> yep.  implies it may or may not be fixed in jaunty and later, noone has checked
[10:29] <cooloney> thanks, i understand.
[10:29] <apw>   * sms1xxx: identify "Dell Digital TV Receiver" devices correctly
[10:29] <apw>     - LP: #302509
[10:29] <apw> that was the fix which triggered it to move in the Intrepid upload.  so you could check if that is in Jaunty and Karmic
[10:29] <apw> if it is then we can just move that fix-released too
[10:30] <apw> cooloney, i can't see that in the jaunty tree so its likely not there.  have fun :)
[10:31] <cooloney> apw, right,
[10:31] <cooloney> no problem -:))
[10:31] <apw> i would look at that change in intrepid and see which id's it adds, and then see if they are in jaunty etc
[10:34] <cooloney> i assure the right process is to close the intrepid bug as fixed-release, then when they find the bug on Jaunty, open a new for jaunty
[10:35] <apw> well that one is open against development currently, and that tells us its not known if its in devel at the moment
[10:36] <apw> cooloney, we really want one bug for a problem.  and a task for each release we are fixing it in, as the problem and fix and analysis is the same so you want it all togeher
[10:36] <cooloney> but since the fixing is in intrepid kernel, it should be in Jaunty and karmic. otherwise it is a regression
[10:37] <apw> right, but the fix is in intrepid, and somehow not in jaunty or later ...
[10:37] <cooloney> apw, OK, i understand
[10:37] <cooloney> thanks
[10:37] <cooloney> i will take a look
[10:38] <apw> looking at it i would say you need to talk to the upstream contributer and ask why its not gone upstream (which it does not appear to have done)
[10:41] <cooloney> yes, i will. it seems the reporter is the upstream contributer
[10:41] <cooloney> it is much easier to communicate
[10:47] <cooloney> apw, for jaunty, it is in SRU, need I port this patch to Jaunty release?
[11:29]  * apw looks at his bug-day list ...
[11:31] <apw> if people are helping out with the kernel bug day we are hanging out here (as always) if you want any advice as to how one might respond to those bugs on the community list
[11:51] <cooloney> apw, yes, back to the party
[11:51] <cooloney> apw, a question for you was missed because you dropped
[11:52]  * apw gets the streamers out
[11:52] <cooloney> apw for jaunty, it is in SRU, need I port that Dell patch to Jaunty release?
[11:54] <apw> generally we don't sru things without a user to test them.  so its probabally not worth it unless someone is activly noticing this problem
[11:54] <apw> though with jaunty being new, they are likely to be asking soo
[11:54] <apw> soon i would think
[12:03] <cooloney> apw, right, this patch is for some hardware which are pretty new
[12:04] <cooloney> ok, i will keep eyes on the feedback from Michael
[12:04] <cooloney> thanks
[12:18] <apw> as he is the upstream contributer, he is likely to ahve the thing and will be able to help decide if its worth doing or not
[12:19]  * apw pokes cking ... hows your list going ... we need some competition in here!
[12:20]  * apw is nearing the hump in his list
[12:20] <apw> ikepanhc, hows your list going?
[12:22]  * apw feels lonely
[12:22]  * laga hugs asac 
[12:22] <laga> err, apw 
[12:23] <ikepanhc> apw: ah? I still look at the list and feel its getting longer and longer
[12:23] <apw> laga, thanks thats better
[12:23] <apw> ikepanhc, know the feeling
[12:24] <ikepanhc> This afternoon I work with DRI patch for G41 chips
[12:25] <ikepanhc> I insist to add "Test-by: David Chen", and david insist to test again :P
[12:25] <infinity> laga: Man, that's a pretty harsh way to add insult to injury.
[12:26] <infinity> laga: If I ever say I'm lonely, I hope you're not around to hug random people who aren't me. :P
[12:26] <apw> heheh
[12:28] <laga> infinity: you're welcome
[12:38] <cking> apw: my list is chuggling along slowly but surely.
[12:40] <apw> cking, does the list appear to be a live list in some sense to you.  i am sure fewer of my bugs were assigned to me before i started this
[12:48]  * cking takes a peek
[12:49] <smb> Seems to me as long as before...
[12:51] <apw> smb, still as long, but the status updated to fixed or whatever
[12:51] <apw> i had about 5 assigned to me on my list at the start.  now most are
[12:53] <apw> and like cking's list the last three are Won't Fix you must have changed those, i assume
[12:53] <apw> else i need to assign you some new one :)
[12:53] <smb> That has not changed, but mostly this couls be because I have not changed much yet. But I would believe it is generated
[12:53] <cking> it appears the status changes in real-ish time
[13:10] <tjaalton> hrm, lspci doesn't find my new dvb-t card (nova-t 500), should I be worried? it should be supported since ages ago
[13:15] <tjaalton> uh, so the tuners are actually usb versions, and the card registers as a usb hub
[13:15] <tjaalton> no wonder lspci didn't show them
[13:19] <amitk> tjaalton: if only computers could do what we mean, not what we do ;)
[13:20] <tjaalton> amitk: right!
[13:21] <tjaalton> and if only the box had a newer kernel than 2.6.27-2 (old intrepid) I wouldn't have noticed a thing ;)
[13:21] <tjaalton> (since support for this card appeared in -3.4)
[13:21] <tjaalton> moving is pain
[13:25]  * amitk nods
[13:25] <amitk> tjaalton: as long as it isn't premature Vappu celebrations :-p
[13:33] <cooloney> morning, rtg 
[13:34] <rtg> cooloney: mornig
[13:35] <cooloney> i have one question about the rtl8187se driver.
[13:35] <cooloney> you might have some better idea about that wireless things
[13:35] <tjaalton> amitk: hehe, I've been too busy to actually think about it yet :)
[13:35] <cooloney> that is bug 246141
[13:35] <rtg> I know little about that particular driver
[13:35] <ubot3> Malone bug 246141 in linux "no support for realtek rtl8187se" [High,Confirmed] https://launchpad.net/bugs/246141
[13:36] <cooloney> the story is rtl8187se driver is in Jaunty stage tree
[13:36] <cooloney> and it works fine
[13:36] <cooloney> but users are asking for hardy or intrepid supporting
[13:37] <rtg> cooloney: ain't gonna happen
[13:37] <cooloney> i found that driver is big and need lots of modification of ieee80211 stack
[13:37] <rtg> cooloney: just say no
[13:37] <cooloney> rtg, so i think we have to nak their request
[13:37] <cooloney> rtg, ok understand
[13:38] <cooloney> rtg, OK, i will try to close that bug and ask them to fire new bug if they find in Jaunty
[13:38] <cooloney> rtg, thx
[13:57] <tcpsyn> Hello. I'm looking for a guide to package a new kernel.
[13:57] <tcpsyn> For ubuntu studio. I read the ubuntu packaging guide, but it's confusing the hell out of me.
[13:57] <tcpsyn> can someone help me out? I want to package from the latest source on kernel.org
[13:58] <tcpsyn> with ingo's realtime patch.
[13:58] <tcpsyn> I have the .debs, but I want to upload this to a PPA
[13:58] <tcpsyn> and I need some help
[14:00] <apw> tcpsyn, what up
[14:01] <tcpsyn> I have my source all ready to go.. I just don't know how to build the .dsc and such
[14:01] <tcpsyn> to upload it to a ppa
[14:01] <tcpsyn> I just ran dh_make, and I need to know if its a single or a multi binary
[14:02] <tcpsyn> and if thats even what I'm supposed to do
[14:02] <tcpsyn> heh
[14:02] <apw> debuild -S makes everything:  dpkg-buildpackage -S -rfakeroot -I.git -I.gitignore -i'\.git.*'
[14:03] <tcpsyn> that's all? just go into the sourcedir and run debuild?
[14:03] <apw> well that makes the source .deb and the changes and dsc files
[14:03] <apw> you then use the changes file for the upload
[14:03] <tcpsyn> but I started from scratch
[14:04] <tcpsyn> I didn't use the source from the repos
[14:06] <apw> tcpsyn, started from scratch in what sense.  you have no debian directory you mean?
[14:06] <tcpsyn> I mean I started from scratch by grabbing the source from kernel.org, not the source tarball
[14:06] <tcpsyn> there is a debian directory though
[14:06] <apw> then its not from kernel.org
[14:07] <amitk> bug 190281 is assigned to you
[14:07] <ubot3> Malone bug 190281 in linux "Segfault in initrd with 2.6.24-7 on intel x86_64" [Medium,Incomplete] https://launchpad.net/bugs/190281
[14:07] <amitk> cking: ^
[14:07] <tcpsyn> it is from kernel.org
[14:07] <tcpsyn> but I built 
[14:07] <tcpsyn> with make-kpgs
[14:07] <tcpsyn> kpkg even
[14:07] <amitk> I am not sure why it is on my list
[14:07] <apw> cking, swap one with him :)
[14:07] <amitk> apw: evil man!
[14:07] <apw> tcpsyn, that is presumably the debian kernel packager
[14:08] <cking> amitk: I'll attend to that. I'd pretty well dead
[14:08] <tcpsyn> It made .debs
[14:08] <tcpsyn> And I installed them, and it's all good.
[14:08] <tcpsyn> But I cant upload a .deb to a ppa
[14:08] <amitk> cking:  no worries, no response for over a year. I'll mark it Won't Fix
[14:08] <apw> tcpsyn, well you should be able to make a source deb from it with debuild -S
[14:08] <amitk> cking: I didn't read all the way to the end
[14:09] <cking> amitk: yep - I was waiting for a response and then it fell off the radar
[14:10] <tcpsyn> This package has a Debian revision number but there does not seem to be
[14:10] <tcpsyn> an appropriate original tar file or .orig directory in the parent directory;
[14:10] <tcpsyn> I gotta tar up the directory first?
[14:10] <apw> you need the option to say i haven't got a .orig
[14:10] <apw> as you don't have one
[14:11] <apw> check the man for debuild
[14:11] <apw> -sn or something i think
[14:11] <tcpsyn> it asked if I wanted to continue anyway. looks like its working
[14:15] <amitk> apw: could you send me your mutt scripts that automagically add SoB lines to a patch
[14:15] <apw> the sob stuff was all .exrc stuff
[14:19] <tcpsyn> I ran debuild -S in the source tree. 
[14:19] <tcpsyn> it deleted the debian directory
[14:19] <tcpsyn> and failed
[14:20] <apw> no idea why it would delete the debian directory, thats a bit mad
[14:20] <apw> amitk, http://people.ubuntu.com/~apw/misc/patch-handling/
[14:21] <apw> amitk, in there is an exrc-sob which shows you how my sob handling is done
[14:21] <apw> there is an =<digit> for each of you sort of thing
[14:21] <apw> =A<n> adds ack, =S<n> adds sob ... =<n> does the default for that person
[14:22] <apw> mostly that is sign for me and ack for the rest
[14:24] <amitk> apw: splendid
[14:24] <apw> amitk, there is now a second file there exrc-email-acks
[14:24] <apw> which shows you how i do the applied stuff
[14:25] <apw> i do a global reply (gy) then i hit '=y<letter>' to get an APPLIED to Karmic email message
[14:25] <amitk> apw: the exrc-email-acks has some strange chars in there...
[14:25] <apw> yep its not pastable
[14:25] <apw> they are mostly raw newlines and raw escape characters
[14:25]  * amitk nods
[14:26] <amitk> is ex the default editor in mutt?
[14:26] <apw> in essence it finds the Subject and mangles it, then zaps the body and replaces it with Applied ... and then signs (in my case '-apw')
[14:26] <apw> i think it uses the default editor
[14:27] <apw> which is vi, which that file applies to
[14:27] <apw> ie .exrc == vi/vim config
[14:27]  * amitk didn't know that
[14:27] <amitk> ohh look, man ex == man vim
[14:27] <apw> amitk, oh hrm ... possibly it has a built in editor
[14:28] <apw> which i may have turned off
[14:28] <apw> # Set me up so the sender goes straight into the editor with the headers
[14:28] <apw> # at the top to edit too, use vi dammit.
[14:28] <apw> set editor=vi
[14:28] <apw> set edit_headers=yes
[14:28] <apw> set autoedit=yes
[14:28] <apw> set fast_reply=yes
[14:28] <apw> i apparently have that incantation in my .muttrc to say ... well ... Use VI dammit
[14:29] <amitk> and how do you toggle between the two exrc
[14:30] <apw> those are two fragments from my .exrc.  they are benign as those bindings are not normally made
[14:30] <apw> so i have them always in every edit
[14:30] <apw> its all pretty primative
[14:34] <amitk> apw: ok, let me try it to use it
[14:34]  * apw find an album on manatune called Jackalope
[14:36] <apw> it _is_ terrible
[14:52] <amitk> smb: Do you pull all ack'ed SRU patches?
[14:52] <smb> amitk, yes
[14:54] <amitk> great
[14:54] <smb> amitk, If you would just update the bug reports when you see the applied message, that would be helpful
[14:55] <amitk> smb: sure, I have all those bug pages open. Waiting for your pushed messages :)
[14:56] <manjo> today is our kernel bug triage day right / 
[14:56] <manjo> ? 
[14:57] <amitk> manjo: get on it! 
[14:57] <amitk> ;)
[14:57] <apw> manjo, our bug day yes, not just triage
[14:58] <amitk> rtg: bug 224559 has a patch that is rejected by upstream with comment that it should happen in userspace. Your view?
[14:58] <ubot3> Malone bug 224559 in linux-ubuntu-modules-2.6.24 "Image on webcam is upside-down" [Undecided,Invalid] https://launchpad.net/bugs/224559
[14:59] <amitk> this would likely become a SRU against H/I/J
[14:59] <rtg> amitk: I'm not in favor of fixing desktop issues for Hardy unless required for an OEM project. Tell 'em top upgrade to Jaunty.
[15:00] <amitk> rtg: even J would require it. It is a case of the camera being mounted upside down (physically)
[15:01] <amitk> upstream things this should be handled in userspace...
[15:01] <amitk> *thinks
[15:03] <rtg> amitk: does upstream have a good reason for doing this in user space? It seems like the kernel is where device specific issues should be handled.
[15:04] <rtg> amitk: in any case, the patch looks fine. you'll be able to tell right away if it works.
[15:06] <apw> cking, you got any e-sata things?
[15:06] <cking> apw: 'fraid not
[15:06] <apw> hrm.  wondering how e-sata hotplug is handled
[15:06] <amitk> rtg: the patch seems good. I don't have an actual link on upstream discussion yet except for the reporter's comment that it was rejected by Linus saying that it should be handled in userspace
[15:08] <rtg> amitk: but that means propagating a bunch of device into user space. I wonder if there is an existing API that would suffice? Anyways, I think its fine for an SRU 'cause we're unlikely to change user space.
[15:08] <mjg59> The patch puts image processing into the kernel, while there's a general agreement that that shouldn't be the case in v4l2
[15:09] <mjg59> The right thing to do would be to add a hal quirk and let userspace consume that
[15:09] <rtg> mjg59: agreed, but its not gonna happen for older releases.
[15:10] <amitk> mjg59: in this case, shouldn't the kernel atleast guarantee that the image is made available the right side up?
[15:10] <mjg59> Right, but that would be why it's rejected upstream
[15:10] <mjg59> amitk: No
[15:10] <mjg59> amitk: The kernel doesn't make any guarantees about what format is provided by the camera
[15:12] <amitk> mjg59: is there a single library in userspace where all video goes through?
[15:12] <mjg59> Yes, libv4l2
[15:16] <apw> interestingly cheese has an option for verticle and horizontal flip
[15:16] <mjg59> I think those are just the normal gstreamer filters
[15:19] <amitk> apw: I guess kopete, pidgin and skype are the main complaints for these users
[15:22] <apw> does pidgin do video now?
[15:23] <amitk> apw: there is a branch with video support that they plan to integrate soon I think
[15:24] <apw> cool.  as my camera works i will be happy
[15:58] <bukharin> hello.  i had disabled ahci in intrepid as per this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/352197 but now this module is built-in. is there any way to disable it?
[15:58] <ubot3> Malone bug 352197 in linux "ata timeout exception with ahci libata driver (was with 2.6.28-11, but i confirmed it affewcts previous kernels too)" [High,Triaged] 
[16:00] <hyperair> hi. does anyone notice jaunty's kernel not releasing disk cache?
[16:01] <hyperair> Mem:          1978       1898         79          0         35       1054
[16:01] <hyperair> that's the output of free -,
[16:01] <hyperair> -m*
[16:01] <hyperair> and my swap's filling up, and from previous experiences, it begins to thrash once my swap's full
[16:01] <hyperair> even when the actual RAM usage is somewhere around 50%
[16:19] <scapor> Installing both debian or ubuntu on a usb flash drive, after some/one reboot(s) the filesystem gets corrupt, both with ext2/3/reiser ...leading to loss of system files.  Is this a known issue ? Is there some fix/workaround ?
[16:41] <amitk> hyperair: what does /proc/sys/vm/swappiness say?
[16:43] <apw> hyperair, i would not expect any cache to get freed until the memory is completly full.  thats normal
[16:45] <hyperair> apw: cache isn't freed even when it begins thrashing
[16:45] <hyperair> amitk: i just set it to 0. it was at some other value earlier (jaunty's default?)
[16:45] <apw> cache is the first thing freed when something needs space and there is none
[16:45] <amitk> default is 60 IIRC
[16:45] <hyperair> apw: yeah, and there wasn't memory. it began thrashing
[16:46] <apw> define thrashing
[16:46] <hyperair> 100% swap, 50% RAM, but cache included, there was only 5MB remaining
[16:46] <hyperair> hang, hard disk light on unblinking
[16:46] <apw> there will always be 5m free thats how the world is
[16:46] <apw> the system works to remain at that boundary.  keeping the max useful stuff in ram rather than it sit empty
[16:47] <hyperair> right, but i doubt it's supposed to begin thrashing at that level
[16:47] <apw> thrashing would be non-normal.  you would want to prove its swap using something like vmstat
[16:47] <hyperair> i use conky
[16:47] <apw> whatever, did it say it was swapping
[16:47] <hyperair> swapping.. eh
[16:47] <hyperair> i don't know, everything hung
[16:47] <apw> swap being means nothing.  was it actually swapping
[16:47] <hyperair> i couldn't move a thing
[16:48] <apw> did it ever recover
[16:48] <hyperair> no it didn't
[16:48] <hyperair> i left it for half an hour
[16:48] <apw> could you tell if the disk was activly doing anything, other than the light being on
[16:48] <hyperair> eh?
[16:48] <amitk> like updatedb
[16:48] <apw> the disk light being on tells you a transaction to the disk is ongoing does not tell you that anything is happening
[16:49] <hyperair> most certainly not
[16:49] <apw> it flickering sometimes or you hearing the rattle of the heads tells you its doing something in reality
[16:49] <hyperair> i didn't really listen
[16:49] <apw> si t
[16:50] <apw> so the machine could just have been completly stopped rather than thrashing
[16:50] <hyperair> i doubt it
[16:50] <apw> based on what information
[16:50] <hyperair> i recognize the symptoms on my notebook. i ran a fork bomb once to prove a point
[16:51] <apw> and did that ever recover
[16:51] <hyperair> also, i tried opening a 1G svg file
[16:51] <hyperair> no it didn't
[16:51] <hyperair> i walked to the toilet, and when i came back, RAM 100%, swap 100%, hard disk light unblinking, on
[16:51] <apw> and how much ram do you have
[16:51] <hyperair> 2G
[16:51] <hyperair> swap 2G
[16:52] <apw> so that SVG could easily have a memory footprint in the 2-4GB range when loaded into memory
[16:52] <hyperair> probably
[16:52] <apw> so it could well have turned your machine into a heap
[16:52] <apw> and it should be reprooducible
[16:52] <hyperair> i run with ~25-50% swap and ~50% RAM under normal circumstances
[16:53] <hyperair> in intrepid.
[16:53] <hyperair> in jaunty, swap steadily rises to 100%, while RAM stays at around 50%
[16:54] <hyperair> by ~24h uptime, it's thrashing.
[16:54] <amitk> hyperair: have you checked your CPU usage at this time?
[16:54] <apw> sounds like an application is leaking memory from that behaviour
[16:54] <apw> memory that it is not using as it is getting swapped out
[16:54] <hyperair> apw: i don't think it is.
[16:55] <apw> once your swap is full you will slowly run our of system ram and life becomes hard for the kernel
[16:55] <hyperair> apw: my conky config shows top 5 apps in terms of mem usage
[16:55] <apw> and it swaps like a madman
[16:55] <hyperair> apw: the top remains Xorg, 5%
[16:55] <apw> well the kernel can't use swap for itself
[16:55] <apw> so if something is in swap its most likely app related
[16:55] <apw> not sure i know of any way to find out what the swap belongs too ... hrm
[16:56] <hyperair> i think it's more of something like.. disk cache refuses to be released, and so everything gets shoved into swap
[16:56] <apw> everyone would be affected if the diskcache was never released
[16:56] <apw> my jaunty boxes are all fine
[16:57] <apw> and according to your stats the machine thrashes with 50% ram free
[16:57] <apw> so i assume something is wrong with those numbers somehow
[16:57] <hyperair> or ~1G
[16:57] <hyperair> things thathave changed in my config since intrepid...
[16:57] <apw> is this 32 or 64 bit
[16:57] <hyperair> 3 partitions from ext3 to ext4
[16:57] <hyperair> and intel
[16:58] <hyperair> also from 32bit to 64bit
[16:58] <apw> you are now 64 bit?
[16:58] <hyperair> yes
[16:58] <hyperair> i understnad that it will take more memory
[16:58] <hyperair> but
[16:58] <apw> so you are in the same position as me
[16:58] <hyperair> the last time i tried filling up my memory, it hit 100% RAM and 100% swap before thrashing
[16:58] <hyperair> now it's at 50% RAM and 100% swap
[16:58] <apw> and that would be reasonable
[16:58] <hyperair> my disk cache likes to stay around ~1G
[16:59] <hyperair> i suppose for experimental purposes i could try creating another 1G svg
[16:59] <apw> i have about 1gb of cache, but i do a lot of kernel work
[16:59] <apw> though thats only 1/4 of my overall ram
[16:59] <hyperair> heh this is half of mine
[17:00] <apw> once swap is full life gets hard for the kernel as it cannot follow the normal priority rules
[17:00] <apw> so an application can take over the machine much more easily once swap is exhausted
[17:01] <apw> i have about 200mb in my swap
[17:01] <apw> which would seem reasonable for a machine which has this much crud running on it
[17:01] <hyperair> heh
[17:02] <hyperair> well if i doin't push it too much on intrepid, my swap stays at around 100-500MB
[17:02] <hyperair> it only hits 1G after a few hibernate/resumes
[17:02] <hyperair> or if i run a VM
[17:03] <hyperair> oh maybe i should also mention that my swap's on LVM, which is on dm-crypt
[17:03] <apw> so the key to solving this is to get a trace of the memory split at the failure point
[17:03] <hyperair> uh what?
[17:03] <apw> hyperair, ok i just fired up conky and its talking rubbish to me
[17:03] <apw> it says i have 1gb of ram free
[17:04] <hyperair> it doesn't count disk cache
[17:04] <apw> 1.2 in fact.  when i actually have 200m
[17:04] <apw> what a stupid measure
[17:04] <hyperair> heh
[17:05] <hyperair> i prefer the measurement without disk cache. then i know if i have to free up stuff before attempting to hibernate
[17:05] <hyperair> otherwise resuming takes a damn long time
[17:05] <apw> yeah hibernate is just plain slow compared to just rebooting these days
[17:05] <apw> if you have more than a teacup of ram
[17:05] <hyperair> yeah
[17:05] <hyperair> well it depends on how much you have actually used
[17:06] <hyperair> i'm going to try swapoff -a and leave it be for 15 minutes
[17:06] <hyperair> if i disconnect, it means it failed.
[17:06] <hyperair> current stats: 14MB free (with cache), 1331MB free (without cache)
[17:06] <hyperair> swap usage: 904MB
[17:06] <apw> you are asking for trouble for sure turning off swap
[17:31]  * hyperair is back!
[17:31] <hyperair> okay.. the swapoff didn't work, but was ^C-able, but then iwlagn decided to go bonkers on me
[17:33] <apw> heh nice
[17:33] <hyperair> well nothing a suspend-resume couldn't fix
[17:34] <hyperair> but the kernel's oops'd before on me 
[17:34] <hyperair> or so dmesg sayss
[17:34] <hyperair> says*
[17:34] <hyperair> heh
[17:34] <hyperair> i don't remember having so much problem swapoff'ing though
[17:35] <hyperair> in intrepid, x86, it was fairly quick and never hung
[17:35] <kirkland> rtg: it seems that the -virtual kernel is missing a couple of important bits which are present in the server kernel
[17:35] <kirkland> rtg: hoping you can get those turned on for karmic
[17:35] <kirkland> rtg: <aliguori> <smoser> from what i can see, linux-image-virtual kernels contain a subset of what is packaged by linux-image-server kernels
 <smoser> and one of the things present in -server that is not present in -virtual is acpiphp.ko
 <smoser> the result is that you can't do hotplug of block devices
 <smoser> i went ahead and replaced the -virtual with -server to get it and then had some success... at very least to get block device hotplug, you need that and then "remove virtio" commit mentioned from https://bugzilla.redhat.com/show_bug.cgi?id=490479
[17:35] <ubot3> bugzilla.redhat.com bug 490479 in kernel "error when hot-unplugging a file-backed virtio disk" [Medium,New] 
[17:35] <Seito> hi! could anyone suggest me with installing fresh kernel from kernes.org? I'm truing to build it with default settings (from make menuconfig) but it exits with errors.
[17:36] <rtg> kirkland: email on k-t list so I don't forget
[17:36] <kirkland> rtg: okay
[17:36] <smoser> for hotplug remove of virtio devices you will also need http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=29f9f12ec7
[17:36] <kirkland> rtg: is that prefered over a bug?
[17:36] <kirkland> smoser: what upstream release is this in?
[17:36] <smoser> https://bugzilla.redhat.com/show_bug.cgi?id=490479 is fedora 10 bug on that
[17:36] <manjo> lieb, that does not make sense if ppl are still reporting that the mouse is inverted
[17:36] <ubot3> bugzilla.redhat.com bug 490479 in kernel "error when hot-unplugging a file-backed virtio disk" [Medium,New] 
[17:37] <smoser> kirkland, i have to look...
[17:37] <rtg> kirkland: either is fine. I just don't usually open bug reports on development kernel quite this early in the process.
[17:37] <kirkland> smoser: ie, we might get that automatically when we rebase karmic
[17:37] <smoser> commit is from 12/10/2008
[17:37] <kirkland> smoser: so probably in 2.6.29
[17:37] <smoser> i dont have the git tree locally, so dont know for sure
[17:39] <manjo> ogasawara, I have a bug on my list that is in the fixcommited state ... 
[17:40] <smb> manjo, happy bugger
[17:40] <smb> ogasawara, give manjo 10 more :)
[17:40]  * manjo takes more asprin
[17:42] <lieb> manjo, true except at the time that seemed to be what made sense.  I cut a patch and it's probably still in my git repo branch.  it got no ack
[17:42] <ogasawara> manjo: bug 78684?  seems I closed that one yesterday
[17:42] <lieb> so I closed it
[17:42] <ubot3> Malone bug 78684 in linux "AGP not detected on Intel 8285P and E7205 chipsets using kernels higher than 2.6.17" [Undecided,Fix released] https://launchpad.net/bugs/78684
[17:42] <manjo> ogasawara, 283126 also
[17:44] <ogasawara> manjo: I can give you 2 more bugs if you like :)
[17:45] <manjo> ogasawara, ok np 
[17:45] <manjo> ogasawara, just take that away from my list then and add 2 more 
[17:50] <cooloney> manjo, bugger hero, i think apw should give you his playboy cup as an award.
[17:52] <cooloney> ogasawara, for bug like this bug 29789
[17:52] <ubot3> Malone bug 29789 in linux "tv card audio not working" [Unknown,Fix released] https://launchpad.net/bugs/29789
[17:52] <cooloney> ogasawara, it is too old and a long story, it is possible to just set it won't fix?
[17:53] <ogasawara> cooloney: sure
[17:53] <tcpsyn> ok, I started over with my kernel package. I patched the source, and made debs with make-kpkg
[17:53] <tcpsyn> now I'm afraid if I run debbuild -S, it'll delete my debian directory
[17:53] <ogasawara> cooloney: especially since it looks like there was never feedback for testing Intrepid
[17:54] <cooloney> ogasawara, exactly, 
[17:54] <cooloney> or need i keep it open for karmic, just set won't fix for other release
[17:55] <cooloney> i prefer to set won't fix to all
[17:55] <ogasawara> cooloney: I'd just mark the "linux (Ubuntu)" task as won't fix and tell them they can reopen the bug if they can confirm against the latest jaunty
[17:55] <cooloney> ogasawara, got it, agree with you
[20:45] <tcpsyn> ok.
[20:46] <tcpsyn> I really need help packing this kernel
[20:46] <tcpsyn> I'm not getting anywhere
[20:46] <tcpsyn> I downloaded the source from kernel.org. patched it. and now I want to upload it to a ppa.
[20:46] <tcpsyn> debuild -S complains because theres no orig.tar.gz
[20:49] <calc> tcpsyn: er does it have a debian dir at all?
[20:49] <calc> it doesn't magically create debian packages from nothing :)
[20:51] <tcpsyn> calc, I made the debian package with make-kpkg
[20:51] <calc> but as far as the orig.tar.gz is concerned that is usually the original tarball from upstream
[20:51] <tcpsyn> that made a debian directory
[20:51] <calc> eg foo.tar.gz -> foo.orig.tar.gz
[20:52] <tcpsyn> I didn't get it from upstream though
[20:52] <tcpsyn> I got it from kernel.org
[20:52] <calc> kernel.org is upstream for kernels
[20:52] <tcpsyn> oh
[20:52] <calc> just openoffice.org is upstream for OOo (well it is a bit of special case for it)
[20:53] <tcpsyn> so. I ran make-kpkg .. which made the debian directory
[20:53] <tcpsyn> and then I ran debuild -S
[20:53] <tcpsyn> which deleted the debian directory
[20:53] <tcpsyn> and then failed
[20:53] <tcpsyn> what am I supposed to do
[20:53] <tcpsyn> what's the way to do this
[20:53] <calc> not sure i haven't worked with make-kpkg
[20:53] <tcpsyn> Because I'm out of ideas and confused as shit.
[20:54] <calc> i guess wait for one of the kernel guys to respond if any are around
[20:54] <tcpsyn> thanks anyway
[20:55] <tcpsyn> kernel guys: Please help.
[21:46] <WimV> someone can give me some hints about howto build a kernel for the live-cd ? with unionfs, squashfs etc.. didn't really find anything about in on the kernelteam wiki
[22:44] <Ng> if someone with an Acer Aspire laptop (not the One netbook thingy) wanted to boot with wifi/bluetooth radios off, is there a way they could do that?
[22:48] <dtchen> Ng: blacklisting is a rather crude hackaround. also, if the modules expose an option to enable/disable, you could pass modulename.enable=0 to grub/lilo
[22:49] <dtchen> (replacing "enable" with the appropriate module parameter(s))
[22:58]  * Ng nods, I figured that was probably going to be the best option
[22:58] <Ng> I'm used to thinkpad luxury where this stuff is all very easily controlled ;)
[23:26] <LLStarks> hi
[23:27] <LLStarks> is kms disabled in the new karmic kernel?