[02:55] <pwp> Hello
[02:55] <pwp> Is anyone here?
[02:58] <RAOF> !ask
[02:58] <ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
[03:00] <RAOF> Hm.  With an added side order of “It's about 3AM in England where much of the kernel team are”
[03:05] <ikepanhc> or it is still weekend for west coast of US?
[03:10] <bdrung> https://wiki.ubuntu.com/Kernel/Dev/UKMLPatchSubmission says: "After you push your changes to your remote git tree use git request-pull to generate a pull request". I have no remote git tree for the kernel. Where should I push it?
[03:11] <bdrung> here's the patch that I want to get included: http://pastebin.com/6qrs71kt
[03:12] <RAOF> bdrung: You probably want to git-send-email that, rather than to generate a pull request.
[03:13] <ikepanhc> bdrung: if you dont have a public git server, just post the patch on mailing list
[03:13] <bdrung> do you have a git-send-email command example for me?
[03:14] <RAOF> “git send-email --to=xorg-devel@lists.x.org HEAD~1” - sends the last commit to xorg-devel@lists.x.org
[03:14] <bdrung> is it enough to ask to apply the patch also to lucid?
[03:14] <ikepanhc> https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide#Sending your patch to mail list
[03:17] <ikepanhc> I need to update the wiki someday...
[03:18] <bdrung> ikepanhc: are the params mention in https://wiki.ubuntu.com/KernelTeam/KernelSimpleGuide#Sending safe to use?
[03:18] <ikepanhc> bdrung: for one patch, yes. for patches, maybe not
[03:19] <bdrung> ikepanhc: i haven't msmtp installed.
[03:19] <mjg59> ikepanhc: Off-topic, but do the docs you have for the VPC2004 interface include the rfkill interface?
[03:19] <mjg59> I'd really prefer that the driver not use the direct EC setting calls
[03:20] <ikepanhc> bdrung: you can install it
[03:20] <ikepanhc> mjg59: yes. can you tell me why you not prefer that?
[03:21] <bdrung> ikepanhc: hm, now i have to configure it...
[03:21] <mjg59> ikepanhc: I may have been unclear. I was ok with dwmw2's code because reverse engineering the VPC2004 calls didn't seem straightforward, but I'd prefer that ideapad driver use methods that are under the VPC device rather than explicitly calling functions under _SB
[03:22] <mjg59> ikepanhc: So your one seems fine, except for it not supporting rfkill :)
[03:23] <ikepanhc> mjg59: oh, there are two acpi method in VPC2004 that help writing to ec register, I will use the method not ec_write()
[03:23] <ikepanhc> mjg59: the doc tells me I shall use the acpi method to access ec register
[03:25] <mjg59> ikepanhc: Argh, sorry, I'm confusing everything now
[03:25] <mjg59> ikepanhc: David Woodhouse was using \_SB_.GECN
[03:25] <mjg59> Whereas I suspect he should be using something that's within the VPC device
[03:26] <ikepanhc> mjg59: yes, but only s10-3 has  GECN, but other ideapads not
[03:26] <mjg59> Exactly
[03:26] <mjg59> So if you know how to control the radios using the VPC methods, it'd be a huge help if you could implement that so we don't have it relying on the GECN method
[03:26] <ikepanhc> mjg59: yes, there are two method within VPC2004 that we can read/write two ec registers
[03:27] <mjg59> ikepanhc: Right. If those can be used to control the radio, that would be awesome.
[03:27] <ikepanhc> mjg59: they can :)
[03:27] <mjg59> ikepanhc: Awesome. If you could write the code to do so, that would be even better :)
[03:28] <ikepanhc> mjg59: that's my plan
[03:28] <mjg59> Great
[03:34] <bdrung> ikepanhc: i defeated msmtp, the mail is send.
[03:35] <ikepanhc> IIRC I spent almost one day on msmtp when first time use it
[03:36] <bdrung> google was my friend
[03:36] <bdrung> time to go to bed...
[03:36] <ikepanhc> bdrung: good night
[04:42] <MTecknology> So 2.6.36-rc1 is finally here. AppArmor support is now in mainline. :D
[09:02]  * apw yawns
[09:02]  * smb slurps some more coffee
[09:03] <cooloney> moring apw and smb 
[09:03] <smb> cooloney, morning
[09:05] <RAOF> Morning all.
[09:06] <JFo> :-P
[09:06]  * JFo longs for the sleep that should have been last night
[09:06] <JFo> morning cooloney 
[09:06] <JFo> morning RAOF 
[09:06] <smb> JFo, Sounds like you could be ultra-wake later on the call
[09:07]  * RAOF wonders if many people are worried about the “conflicting fb, removing generic driver” messages in dmesg.
[09:07] <cooloney> JFo and RAOF morning guys
[09:07] <JFo> smb, no call today
[09:08] <smb> JFo, Ah ok
[09:08] <JFo> I should have sent e-mail, but it is likely that it didn't get out
[09:08] <smb> Oh right, you are away
[09:08] <smb> In the "wrong" tz
[09:08] <JFo> was having issues with my mail :(
[09:08] <JFo> or the right one :)
[09:08] <smb> Heh, yeah
[09:08] <smb> What happened to Friday? Not that I would have been any prepared
[09:09] <JFo> I forgot about it
[09:09] <JFo> naturally
[09:09] <JFo> plus it took forever to get my glasses from the store
[09:09] <JFo> so I would have been extremely late anyway had I remembered
[10:06] <ikepanhc> new installer for maverick looks interesting - asking infomation and copy file in the same time
[10:06] <apw> yeeks
[10:13] <amitk> ikepanhc: I should try it out. I've alway wondered why I can't play tic-tac-toe during an install :)
[10:14] <ikepanhc> amitk: give the machine ethernet connection - seems will install fail if no connection
[10:18] <ikepanhc> ah, installer do not ask me the computer name..
[10:58] <ericm_> apw, how debian.mvl-dove/d-i/kernel-versions is generated?
[10:58] <apw> ericm, fdr clean generates it
[10:59] <ericm> apw, it looks like a package list - where's the list generated?
[11:00] <apw> ericm, kernel-versions is generated from kernel-versions.in in the debian/rules file
[11:01] <ericm> apw, ah - I see
[11:01] <ericm> apw, so what are the purpose of those debian.mvl-dove/d-i/exclude-* files?
[11:01] <ericm> the modules listed will be excluded from the udeb for installer?
[11:02] <apw> they adjust which debian-installer .udebs are generated as compared to the 'default' list
[11:03] <ericm> apw, but the file name is prefixed with 'exclude' ??
[11:03] <apw> yes, they 'adjust' the list, in this case negativly
[11:04] <ericm> apw, so they 'adjust' the list by removing those .udebs from the 'default' list?
[11:04] <apw> yep
[11:04] <ericm> apw, got you
[11:07] <bdrung> my lirc patch mail doesn't appear on https://lists.ubuntu.com/archives/kernel-team/2010-August/thread.html - do you received the mail?
[11:17] <xampart> i have 2.6.32-24-server. when i try to create lvm-snapshot, it hangs. known bugs concerning this kind of behavior?
[11:19] <apw> smb, ok the LBM package change looks ok, but it does imply that the meta packages are updated, which tim is not wanting to do
[11:19] <apw>   You likely do not want to install this package directly. Instead, install
[11:19] <apw>   the linux-backports-modules-compat-wireless-2.6.34-generic meta-package, which will ensure
[11:19] <apw> thats the note on the 34 package, but there is no linux-backports-modules-compat-wireless-2.6.34-generic meta package currently
[11:21] <smb> apw, Ok, I will need to make that consistent before I push out things
[11:21] <apw> well its not really a show stopper and can be corrected as a second patch if he decides not to fix meta i guess
[11:22] <smb> Yeah, I'd do it as separate update to the initial ones
[11:22] <apw> so yeah i'll ack the LBM update, and leave comments on the meta
[11:22] <smb> ok, ta
[11:24] <apw> smb, done
[11:24] <smb> cool
[12:16] <xampart> getting http://pastebin.com/WQ8xLSwH when trying to lvcreate and system hangs. using 2.6.32-24-server. need fix.
[12:19] <smb> Hm, had no reports yet that this would affect lvcreate. Is snapshot involved?
[12:21] <xampart> yes
[12:21] <smb> Ok. There is a fix. Trying to find where kernels with that might be
[12:25] <smb> Normal proposed updates are waiting on finalizing the point release. You might try -25 kernels from: https://launchpad.net/~kernel-ppa/+archive/pre-proposed
[12:27] <xampart> smb: assuming that when normal updates are released, they get installed when doing update && safe-upgrade?
[12:29] <smb> Normal updates should always supersede pre-proposed. So when you remove the source to the ppa later you will come back to the normal updates kernels
[12:39] <apw> lool, have you filed a bug already for the purge issue?
[12:39] <lool> apw: Yes, it's the last one on my list
[12:39] <lool> LP #618591
[12:39] <ubot2> Launchpad bug 618591 in linux (Ubuntu) "Leaves modules.devname and modules.softdep behind in /lib/modules (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/618591
[12:54] <bdrung> i send a lirc patch mail (lirc - Fix Hauppauge TV Card is detected as Leadtek IR) but it doesn't appear on https://lists.ubuntu.com/archives/kernel-team/2010-August/thread.html - Can a kernel-team subscriber check if he/she got the mail?
[12:56] <JFo> bdrung, when did you send it?
[12:56] <JFo> I don't see it
[12:57] <bdrung> 8 hours ago
[12:57] <JFo> yeah, I don't see it
[13:02] <bdrung> JFo: ok, i have sent it manually now. do you get it and is the format still correct?
[13:02] <JFo> bdrung, one moment... I will check
[13:03] <bdrung> ups, my signature was added
[13:05] <JFo> still not seeing it bdrung but it takes a while for me to get things on occasion
[13:05] <JFo> I'll check again after lunch :)
[13:05] <bdrung> thanks
[13:29] <diwic> JFo, you have an automated script that ask people to try mainline kernels.
[13:29] <diwic> JFo, I'm wondering whether that is the best test option
[13:30] <diwic> JFo, I usually ask people to test the c-o-d builds instead
[13:31] <diwic> JFo, this is all about kernel-sound bugs, of course
[13:32] <apw> diwic, which c-o-d builds do you ask them to test?
[13:32] <diwic> apw, https://wiki.ubuntu.com/Audio/InstallingLinuxAlsaDriverModules
[13:33] <apw> JFo, its possible we should be asking for those as well for 'sound' bugs
[13:35] <bdrung> JFo: ok
[13:35] <bdrung> this time the mail is in the log
[13:40] <JFo> bdrung, now I see 2 of them
[13:41] <JFo> diwic, I ask them to test mainline so we can bisect what upstream stable has versus what we have in development
[13:41] <JFo> are the items in the link you provided different from those 2?
[13:42]  * JFo checks the link
[13:42] <bdrung> JFo: strange... both appeared on https://lists.ubuntu.com/archives/kernel-team/2010-August/thread.html
[13:42] <bdrung> JFo: you can use one for maverick and the other for lucid ;)
[13:43] <diwic> JFo, I don't think we have much delta sound-wise so I don't know if that makes sense
[13:43] <diwic> JFo, or, it does make sense, but question is if anything else makes even more sense
[13:43] <JFo> bdrung, looks like one has a PGP sig and the other does not... only difference between them that I see
[13:44] <bdrung> JFo: yes - it's the same. it applied on both :)
[13:44] <JFo> :)
[13:44] <JFo> diwic, I am open to suggestion if you think it is useful enough
[13:45] <diwic> JFo, right, so I'm asking users to try c-o-d to know if upstream has fixed the bug (or hardware enabled...) recently.  
[13:46] <diwic> JFo, and this is possible because c-o-d builds are relatively stable 
[13:46] <diwic> JFo, Takashi does a good job in keeping them fairly stable, but of course, that could change.
[13:47] <apw> diwic, i assume those packages are de-installable also ... so not the end o fthe world
[13:47] <diwic> apw, yes, they are as uninstallable as <random other package> 
[13:48] <apw> diwic, on a related note, that page could do with updating with "uninstall instructions" for those who don't know how packages work
[13:48] <apw> i believe there is a 'ppa-purge' thing you can use
[13:48] <diwic> apw, sounds interesting. Yeah, I guess updating those pages falls on me now
[13:49] <apw> :)
[13:49] <apw> well as you know that that one exists, and are the one pointing to it, you are uniquly qualified to check it
[13:51] <diwic> apw, it's on my TODO list
[13:55] <apw> http://bigbrovar.aoizora.org/index.php/2010/01/10/how-to-safely-remove-ppa-repository-from-ubuntu/
[13:55] <apw> diwic, ^^ seems to document it
[13:57] <diwic> apw, cool
[13:58] <diwic> apw, hmm, seems like you have to install that from another ppa 
[13:59] <apw> yeah not so cool.  sounds like something which should be moved to the apt-add-repository package
[13:59] <diwic> apw, my thought exactly
[14:07] <apw> diwic, seems the package is at least an official package from lucid
[14:09] <diwic> apw, good enough, but merging into add-repo would be even better
[14:27] <diwic> apw, from maverick, unfortunately
[14:28] <apw> diwic, yeah seems to be in -backports only on lucid
[14:28] <diwic> aha
[14:28] <apw> but as its an LTS, i am thinking that might be short-sighted
[14:28] <diwic> apw, how to you easiest check what releases have a particular package?
[14:29] <apw> either rmadison <package> or i use the 'versions' page
[14:29] <apw> https://edge.launchpad.net/ubuntu/+source/ppa-purge
[14:31] <apw> smb, so the pre-proposed build of LBM seems to have made its way into the PPA ok
[14:31] <apw> i therefore declare LBM support working in cod
[14:31] <smb> Yes. Saw that a bit ago. Ok, wfm
[14:31] <diwic> apw, hmm, I use http://packages.ubuntu.com/ppa-purge , but that one shows no results.
[14:32] <apw> diwic, never used that one
[14:34]  * diwic notices that a rmadison search on google results in, excepts for the correct ones, also "A vintage 1969 Mercedes", "A chill individual"
[14:34] <diwic> and a few others
[14:53] <apw> diwic, heh ... well the service itself is called madison
[14:54] <apw> the cmdline app is rmadison
[14:55] <diwic> apw, anyway, I added uninstalling without removing the ppa for now.
[14:55] <apw> diwic, sounds good
[14:56] <apw> i'd say if its well documented, adding it in jfo's call in the bug is appropriate
[14:58] <KE1HA> sri to both you guys, know your very busy atm, but Im testing 10.04.1 ISO's, is there a fix for the Intel i855 chipset black screen issue in this release ?
[14:58] <KE1HA> Bother*
[14:58] <JFo> apw, I agree. It can't help bug be beneficial
[14:59] <diwic> apw, JFo, I'd like if we would replace "test mainline builds" with this. Testing mainline wouldn't give me/us much more information    
[14:59] <diwic> compared to the additional effort 
[14:59] <apw> in principle we should be doing whatever the area expert recommends we ask for ... imo
[14:59] <diwic> of the user
[15:00] <JFo> apw, indeed
[15:00]  * diwic looks around for an area expert... ;-)
[15:00]  * JFo looks pointedly at diwic 
[15:00] <JFo> :)
[15:01] <diwic> "Audio area expert",  that might be something for a business card. 
[15:01] <JFo> I'll check and see what will be needed to get this going along with bjf as he is expert on the scripts. It may be simple, but if it is not then we shall put it in the todo for later
[15:01] <JFo> rather a bit later
[15:01] <JFo> not just later
[15:01] <diwic> Sure, it's nothing urgent.
[15:01] <apw> i think we get a sound tag from apport 
[15:01] <diwic> There aren't that many kernel-sound bugs anyway, as most of them go to alsa-driver
[15:02] <JFo> apw, we do
[15:02] <apw> so perhaps we can be conditional on that
[15:03] <JFo> oh yes, that is the plan
[15:05] <bjf> JFo, diwic, i've read the scrollback and can't really tell what you'd like changed in the arsenal scripts, can you educate me
[15:05] <diwic> bjf, if the linux bug is a sound bug, change "please test mainline build" to "please test takashi's c-o-d"
[15:09] <diwic> bjf, I think that makes more sense, what do you think?
[15:13] <bjf> diwic, i'm staring at the auto reply messages now
[15:13] <bjf> diwic, i'm going to send the file that contains the text to you and JFo, it should be trivial to change the text
[15:14] <diwic> bjf, btw, I saw the c-o-d builds ftbfs today but I believe that is fixed by Takashi so tomorrow's one will work
[15:14] <bjf> diwic, was it the i386?
[15:14] <JFo> bjf, this needs to only be for the 'kernel-sound' tagged bugs. Do we do a specific message for those now?
[15:15] <JFo> sorry for the late response, I'm in a meeting. :-/
[15:15] <bjf> JFo, there are sound specific messages in the message file, and I _think_ we use them
[15:15] <JFo> ok cool
[15:15] <diwic> bjf, yes, it was an old isa driver which was not enabled in amd64 
[15:15]  * JFo needs to look over the script again
[15:15] <diwic> bjf, so the error only occurred on i386
[15:25] <apw> sconklin, is there a dead-give-away to knowing if a machine is an aarandale
[15:26] <sconklin> apw: cking would probably know which bits in the processor ID give it away
[15:27] <apw> sconklin, he is off for two weeks, so you are in the frame as expert :)
[15:27] <sconklin> hmm. let me check
[15:28] <sconklin> apw i7's all are I'm just not sure about any other IDs
[15:30] <diwic> bjf, so I saw arsenal_reply.py you sent me, and I think the test_upstream reply needs to be split in two, one for sound bugs and one for non-sound-bugs
[15:30] <sconklin> as well as i5 5xx aparently. I'll look for something more definitive
[15:30] <apw> sconklin, isn't there a known issue with aarrondale in gneeral with suspend not working
[15:30] <apw> smb, ^^
[15:31] <apw> where you use something like nolapic or nohpet can help
[15:31] <sconklin> Well, there were several I think, and some have been fixed by cking. But I don't know what they are.
[15:31] <bjf> diwic, did you see the "sound_bug" and "alsa_old_bug" entries?
[15:31] <diwic> bjf, yeah perhaps change the text in those as well 
[15:32] <smb> apw, hm, I am a bit out of context. There were probably various things. Including incorrect timer irq override...
[15:32] <bjf> diwic, I accept patches :-)
[15:32] <apw> smb, i am scrabbling without contxt myself, but i did think we had a slew of issues with suspend/resume on those puppies
[15:33] <apw> and i thought we were fixing them by quirking
[15:33] <sconklin> apw http://www.cpu-world.com/Cores/Arrandale.html
[15:33] <apw> sconklin, ta
[15:33] <sconklin> for IDs
[15:34] <smb> apw, Hm yeah. Wasn't there tsc jumps after resume....
[15:34]  * smb tries to remember how that could be quirked
[15:34] <apw> smb, yeah that period .... wern't some of the expidited patches for that sort of thing?
[15:35] <smb> There was something... to handle warps... somewhere...
[15:35] <apw> smb, you wouldn't be able to find that one for me would you
[15:35]  * smb tries
[15:36] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374
[15:36] <ubot2> Ubuntu bug 532374 in linux (Ubuntu Lucid) (and 3 other projects) "Lenovo Thinkpads with Core i5 and i7 suspend/resume (with kernel oops) once then fail horribly on next suspend (affects: 58) (dups: 4) (heat: 229)" [Critical,Invalid]
[15:39] <sconklin> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/477106
[15:39] <ubot2> Ubuntu bug 477106 in linux (Ubuntu) "[regression] lucid alpha-2 and earlier freeze upon suspend with sd card plugged in with some hardware (affects: 147) (dups: 25) (heat: 539)" [Medium,In progress]
[15:41] <diwic> bjf, bug #596882 is an example where I should have preferred c-o-d testing, but the text is neither alsa_old_bug or sound_bug, but test_upstream
[15:41] <ubot2> Launchpad bug 596882 in linux (Fedora) (and 1 other project) "[ALC888] No Sound - used a clean Install of Maverick 10.10 (affects: 5) (heat: 88)" [Undecided,New] https://launchpad.net/bugs/596882
[15:43] <bjf> diwic, that's more than a text change, i'd have to look at why that text string was being applied and "fix" the logic to use one of the sound text messages instead
[15:45] <diwic> bjf, exactly, so I could probably give you a text (which someone with native English language could proofread), but I don't know anything about the logic behind.
[15:45] <bjf> diwic, ack, I was hoping it was just a text change
[15:46] <apw> pgraner, which model is your lenovo?
[15:50] <pgraner> apw, t410
[15:51] <apw> pgraner, ta, not that then
[15:59] <JFo> I have a t410s
[16:00] <JFo> the S is for Special ;)
[16:00] <smb> Rather Small
[16:01] <smb> Its the netbooks
[16:02] <JFo> if it is on i7 then I have a desktop at the house I can test on when I get home
[16:02] <smb> I would guess the Sxx are rather atom based
[16:31] <Kano> hi, when is .36-rc1 in mainline
[16:33] <apw> Kano, normally a few hours after release, its queued ... 
[16:36] <Kano> ok
[16:37] <apw> Kano in fact it didn't build, and won't as its broken
[17:12] <GrueMaster> JFo: Bug 618738.  Anything else I need to add?
[17:19]  * JFo looks
[17:25] <Sarvatt> apw: is disabling comedi so mainline post 1685e633b396b0f3dabbc9fa5d65dfefe6435250 builds an option? 
[17:26]  * Sarvatt doesn't know how much of a pain in the butt that is with the build infrastructure
[17:26] <apw> Sarvatt, depends if they have fixed it up stream already i guess
[17:26] <apw> there is no simple way to turn it off in an automated way
[17:26] <GrueMaster> but without comedi, there won't be any humour.
[17:27] <apw> arf
[17:30] <tgardner> Sarvatt, the easiest way is to comment out the line in drivers/staging/Makefile 
[17:30] <apw> i suspect he wants it in the mainline archive
[17:30] <Sarvatt> I dont see any fixes in any of the staging trees or on the lists :(
[17:31] <tgardner> apw, ah, you might have to add some hackage in yuor mainline build scripts.
[17:31] <apw> tgardner, i can fix the -rc1 build, but its not obvious how one automates fixing that other than always turning off COMEDI
[17:31] <apw> tgardner, and it sounds like it might be more than comedi
[17:32] <tgardner> apw, well, shuold we bother building staging for mainline?
[17:32] <apw> tgardner, we do use a fair number of the drivers in released kerenls, so not enabling staging drops those and renders the kernels useless for some users
[17:33] <Sarvatt> it'd be a shame not to since stuff like nouveau is still in there
[17:33] <apw> and there i was just thinking of some of the wireless drivers ... 
[17:36] <apw> hrm ... what a pain thats going to be
[17:39] <Sarvatt> how about just allowing arbitrary patches and disabling it in one?
[17:40] <apw> well i can do that, but how do i know when to drop it
[17:40] <apw> its not a technology issue as much a maintenance issue
[17:42] <Sarvatt> check to see if drivers/staging/comedi/drivers/das08_cs.c has changed before patching? next time it's updated it'll probably be fixed
[17:42] <apw> see now thats not an arbiray patch, thats a patch with a really complex trigger
[17:44]  * Sarvatt adds http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=rss;f=drivers/staging/comedi/drivers/das08_cs.c to his rss feed to tell you when its fixed?
[17:44] <pgraner> smb, can you  look into https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/405544   There's some evidence that it /may/ be kernel related, but I need your opinion.
[17:44] <ubot2> Ubuntu bug 405544 in linux (Ubuntu Lucid) (and 4 other projects) "Kernel does not recognize blank optical media (affects: 87) (dups: 13) (heat: 404)" [Undecided,New]
[17:48] <smb> pgraner, I could but atm I am a bit covered by multiple layers of things. how critical is it
[17:49] <pgraner> smb, not critical, sometime next week when you have some spare cycles, or kick it to one of your minions either way not critical at all
[17:49] <Sarvatt> i set up an email alert for the rss feed for that file in git
[17:51] <apw> Sarvatt, heh thanks
[17:51] <smb> pgraner, ok I add it to my list then and see who when 
[17:52] <pgraner> smb, cool this was a request from robbiew, so if you have any questions that are foundations related you can ping him
[17:52] <smb> ack
[18:01] <tgardner> apw, do you know how I can tell if ureadahead has done its job correctly? I've a patch proposed in https://bugs.edge.launchpad.net/bugs/491943, but I'm not sure if it just doesn't paper over the problem.
[18:01] <ubot2> Ubuntu bug 491943 in ureadahead (Ubuntu) (and 2 other projects) "Kernel trace buffer should be set to less unrealistic value (affects: 16) (dups: 2) (heat: 88)" [High,In progress]
[18:02] <apw> tgardner, you could dump the pack it generates before and after the change and see if they are similar ?
[18:02] <apw> tgardner, there is a textual dump option
[18:03] <tgardner> apw, k, I'll try that
[18:04] <apw> smb, that bug that robbiew is referring, its not clear that the kernel errors there are meaningful, in that somone is opening the drive to identify the contents and there is blank disk in there so block 0 is missing wihch its reading to acertain itstype ... and the last comment shows it being recognised at a udev level as a blank disk
[18:05] <apw> smb, and my machine recognises blank cd's and asks to write to them
[18:05] <apw> pgraner, ^^
[18:05] <robbiew> apw: yeah...and the fact that k3B works
[18:05] <apw> that too
[18:06] <apw> whats the default cd writer in gnome, as thats waking up for me
[18:06] <robbiew> I think nautilus has some sort of basic feature for it
[18:06] <robbiew> but brasero is the default app
[18:06] <smb> well it might be something related to ioctls that the drive does. there have been fw issues on drives as well
[18:07] <apw> and the bug is a usless dogpile started when karmic was in development
[18:07] <smb> apw, We might chat about it tomorrow if that is still a question by then
[18:07] <robbiew> apw: I'm only interested in Lucid...I declined the others
[18:08] <robbiew> (Maverick and Karmic)
[18:08] <apw> yep, but the info in the bug is mostly older, as always
[18:10] <apw> robbiew, works with brasero here ... though its a terrible app to understand and not the one that comes up by default
[18:11] <robbiew> apw: yeah...as the bug says, some people don't see it...probably hardware related
[18:12] <apw> so we should really close the bug and get everyone seeing it to file a bug with their h/w info
[18:12] <robbiew> apw: works for me
[18:15] <apw> or perhaps as we don't know its a kernel bug, or indeed h/w related in fact, perhaps get them to open bugs each against linux and add the numbers to that original bug ... hrm
[18:33] <smb> apw, ogasawara Does Maverick already use an orig.tar.gz 
[18:34] <apw> smb, it should by now in theory
[18:35] <apw> smb, but it doesn't look like it does
[18:35] <apw> we should get the 2.6.35 virgin tarball from linus for the next upload
[18:36] <smb> apw, Ok, that answers my next question
[18:37] <apw> thats what we've done for the previous releases, as anyone can get that from linus too
[18:37] <smb> Because I was remembered that back in Hardy it was not a virgin release but sort of a virgin stable 
[18:48] <apw> cnd, you may need to encourage them to come talk ...
[19:09]  * tgardner lunches
[19:35]  * smb drops into a hole
[20:31]  * jjohansen -> lunch
[21:36]  * ogasawara lunch
[21:38] <cnd> apw, cjwatson says the balls in your court, regarding the radeon gfxpayload issues
[21:38] <cnd> have fun with it :)
[21:40] <apw> deep joy
[21:58] <akgraner> jjohansen, give me 10 minutes (if the Ubuntu User site doesn't kick me out *again*) - the AppArmor stuff will be up - I'll drop you a link in just a few - Thanks again!!!
[22:35] <akgraner> jjohansen, here is the link to your interview - http://www.ubuntu-user.com/Online/Blogs/Amber-Graner-You-in-Ubuntu/AppArmor-makes-it-into-the-2.6.36-Upstream-Kernel
[22:35] <akgraner> Thanks!
[22:39] <jjohansen> akgraner: thanks, for putting it together
[23:00] <MTecknology> akgraner: The sucky thing is that it seems with the addition of apparmor - ecryptfs is breaking
[23:01] <jjohansen> MTecknology: how/where? pointers please
[23:01] <jdstrand> uhh, not here
[23:02] <jdstrand> I use both extensively every day
[23:02] <jjohansen> jdstrand: well its not like it hasn't happened in the past so I would like to make sure we are on top of it
[23:03] <MTecknology> I'm pulling it up
[23:03] <jdstrand> jjohansen: oh absolutely, I just meant I've not seen it and more info is needed
[23:06] <jjohansen> jdstrand: right I haven't seen the breakage either, but then thats always the way for me.  Otherwise I would have fixed the bug before the code got pushed :)
[23:06] <MTecknology> jjohansen: When I log in I do ls -l I see d????????? ? ?      ?      ?        ? Desktop
[23:07] <MTecknology> Also  ls: cannot access Desktop: No such file or directory
[23:07] <jjohansen> heh?  Your shell outputs that?
[23:07] <MTecknology> yup
[23:08] <jjohansen> MTecknology: do you have AppArmor rejects in your logs?
[23:11] <MTecknology> jjohansen: <date/name> kernel: apparmor_parser[372]: segfault at 0 ip 00007f075a1ac5d6 sp 00007fff44310868 sd error 4 in libc-2.11.1.so[7f075a1a07f000+17a000]
[23:14] <jjohansen> MTecknology: strange? are there any other apparmor messages around that?  From the error I would say its completely user space.  This means that the loaded policy may be looser than what was intended but definitely not tighter
[23:15] <MTecknology> jjohansen: there's two about the same but that's it
[23:15] <jjohansen> hrmm, can you run >sudo /etc/init.d/apparmor restart
[23:16] <jjohansen> and tell me if those errors show up in your logs
[23:16] <MTecknology> jjohansen: errors are just output by restart..
[23:16] <jjohansen> what type of errors?
[23:16] <MTecknology> xargs: /sbin/apparmor_parser: terminated by signal 11
[23:16] <jjohansen> MTecknology: what kernel are you running?
[23:17] <MTecknology> cat: /sys/kernel/security/apparmor/profiles: so such file or directory
[23:17] <MTecknology> v2.6.36-rc1
[23:17] <jjohansen> right
[23:17] <jjohansen> So you need to wait for the updated tools
[23:17] <MTecknology> oh..
[23:18] <jjohansen> Basically what is upstream is not fully compatible without some additional patches
[23:18] <jjohansen> For example the profiles virtual file went away as it is not very sysfs like
[23:19] <jjohansen> MTecknology: I am working on a wiki page explaining the details
[23:20] <MTecknology> jjohansen: Please send me a link when you get that wiki up
[23:20] <jjohansen> MTecknology: will do
[23:22] <MTecknology> jjohansen: anything I could do now - like disable the apparmor module?
[23:23] <jjohansen> MTecknology: you can do that if you would like.  You can pass apparmor=0 as a kernel command line parameter and then user space should even try to load policy
[23:26] <MTecknology> jjohansen: Where would I set that in grub2? That thing is still a confusing beast for me
[23:31] <MTecknology> jjohansen: heh.. look at grub.cfg instead and it gets easier :P
[23:31] <MTecknology> Except what I did didn't work - I just added it to the kernel line
[23:32] <MTecknology> I suppose I should run off though