[02:41] <duncanm> amitk: hey
[05:08] <duncanm> ssbar
[05:08] <duncanm> bar
[05:08] <duncanm> eek
[11:11] <Kano> hi, when do you merge 2.6.24.6?
[11:12] <maks_> 2.6.25.1 is the interesting target :D
[11:13] <Kano> i mean for hardy
[11:13] <Kano> security issues if you dont know
[11:14] <Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=c1838f1600cc7196363a23da1f76869600e17da1
[11:14] <Kano> can you show me where you see 0x1430, 0x4748 in upstream?
[11:15] <amitk> Kano: check the kernel-team mailing list. smb posted a list of patches that are being considered from the stable series
[11:19] <Kano> with a pure 2.6.25 it definitely does not work
[11:21] <amitk> Kano: I am not sure, wait for rtg to come online or ask on the mailing list
[11:21] <Kano> well i can compile your git code too, then i know it, but it did not work with standard 2.6.25
[11:22] <Kano> will you revert the usb gpl only code?
[11:27] <Kano> or do you just drop the usb modules from avm?
[15:33] <rtg> tjaalton: I just upload LRM -17.35 with a simple ABI bump.
[15:39] <tjaalton> rtg: ok, cool
[15:58] <gnomefreak> tjaalton: you have a minute?
[15:58] <gnomefreak> tjaalton: is there a way for X to work around nvidia crashing X?
[16:01] <rtg> tjaalton: speaking of LRM, can you build a package for Intrepid? See http://ppa.launchpad.net/kernel-ppa/ubuntu for headers and stuff. I'm going to announce the Intrepid daily build pretty soon.
[16:02] <amitk> rtg: can new drivers be added to .1?
[16:03] <amitk> I am thinking specifically about ov51x-jpeg instead of the ov511 that we have in LUM
[16:05] <amitk> ...even with the evil in-kernel jpeg
[16:05] <amitk> compression
[16:08] <tjaalton> rtg: no problem, I'll probably have time to do it later this evening
[16:08] <tjaalton> gnomefreak: dunno, how does it crash?
[16:09] <gnomefreak> tjaalton: scrolling on a page well 1 confirmed page and all crashes have 8600 or 8800 nvidia card with our drivers
[16:09] <gnomefreak> tjaalton: see bug 224966
[16:09] <gnomefreak> tjaalton: im wondering if xul is involed atm but i will ping asac about that later when i have something to base it on
[16:10] <gnomefreak> noone can give me a backtrace just a couple of errors 
[16:11] <tjaalton> gnomefreak: I have a 8600GT.. :)
[16:12] <gnomefreak> tjaalton: can you please get me one lol
[16:12] <tjaalton> they are cheap ;)
[16:14] <rtg> amitk: perhaps. it is going to change current jpeg compression behavior in the general case?
[16:17] <Kano> rtg: hi, does anybody want to add 2.6.26.6 to hardy kernel?
[16:18] <laga> 2.6.26?
[16:18] <tjaalton> gnomefreak: yep, crashes here too
[16:18] <rtg> Kano: only on a case by case basis.
[16:18] <Kano> err 2.6.24.6
[16:18] <rtg> Kano: I knew what yuou meant :)
[16:18] <gnomefreak> tjaalton: thought it would something with nvidia drivers have never been good with 6200 and up cards
[16:18] <Kano> can you tell me how to merge that correctly? when i get an error that it cant be merged?
[16:19] <rtg> Kano: well, you have to resolve the merge issues. git pretty much tells you what to do when the merge fails.
[16:20] <Kano> well then the file hals [16:21] <rtg> Kano: right. Start your search for '<<<', which is where the offending entries begin.
[16:21] <Kano> well then i commited the change, i guess i made it right then
[16:22] <Kano> for .5 there was only 1 wrong file
[16:22] <Kano> did not try .6 yet
[16:22] <tseliot> ﻿gnomefreak: it doesn't crash here (Geforce 7300) however I'm using my own (customised) packages based on the lrm
[16:23] <Kano> rtg: will you revert the usb gpl only patch?
[16:23] <Kano> from 2.6.25
[16:24] <rtg> Kano: I do not know about this issue.
[16:24] <Kano> try to compile avm usb modules
[16:25] <Kano> like fwlan
[16:25] <Kano> you have got those in lrm
[16:25] <Kano> and every other avm usb module
[16:26] <rtg> Kano: I haven't the foggiest idea what you are talking about.  To my knowledge the Hardy LRM has no build issues.
[16:26] <Kano> rtg: 2.6.25 is in your intrepid git
[16:27] <rtg> Kano: for which we don yet have an LRM package.
[16:27] <Kano> well does not matter, the drivers will not compile
[16:27] <rtg> tjaalton: is just now starting to think about LRM for Intrepid.
[16:28] <Kano> for testing i added a patch for fglrx 2.6.25 (x64) and a revert patch for usb
[16:31] <rtg> Kano: you're on your own there. Its gonna be July before I get really interested in Intrepid problems.
[16:32] <maks_> using fglrx is stupid enough
[16:33] <tseliot> ﻿maks_: no flame-baits, please
[16:47] <Kano> rtg: also it seems that the dmraid in lum does not work, at least Rabiddog has problems
[16:48] <Kano> the module is there but it is not recognized
[16:49] <rtg> Kano: which lum? Hardy or Intrepid?
[16:49] <Kano> hardy
[16:49] <Kano> i would like to test it myself, but i only have got 2 similar drives, not 3
[18:03] <mdomsch> rtg: http://lkml.org/lkml/2008/5/2/205
[18:03] <mdomsch> will be needed for the server kernel
[18:04] <rtg> mdomsch: backported for Hardy I assume?
[18:04] <mdomsch> rtg, yeah
[18:05] <mdomsch> soon as ingo pushes it to linus for .26 and -stable picks it up
[18:05] <rtg> mdomsch: I'm working on SRUs, so this is a good time to git 'er done.
[18:06] <mdomsch> I'm filing a bug in LP now
[18:06] <rtg> mdomsch: I'll watch the .7 stable updates for this (when they appear).
[18:06] <mdomsch> to track
[18:06] <mdomsch> hmm, I read on lwn that there wouldn't be .7
[18:06] <mdomsch> or did I misread?
[18:06] <rtg> mdomsch: oh, thats right. 
[18:07] <rtg> mdomsch: well, even if it goes into 25.y it ought to work.
[18:07] <rtg> mdomsch: lemme know the LP number and I'll assign myself to it so I don't forget.
[18:09] <SEJeff> Is CONFIG_VERSION_SIGNATURE an ubuntu specific config option?
[18:09] <rtg> SEJeff: yeah, I think so.
[18:10] <SEJeff> rtg, Ok so in Re: the btrfs failing miserably on ubuntu thread... could we do like SUSE and use CONFIG_VERSION_SIGNATURE instead of CONFIG_SUSE?
[18:11] <rtg> SEJeff: that doesn't mean the AA patches exist. Intrepid won't get them for awhile. I still think the CONFIG search is the best approach.
[18:12] <mdomsch> rtg, LP 225811
[18:12] <SEJeff> Ok so how about an explicit test for the hardy kernel version? If it is a user built kernel, they will know enough to apply a patch manually?
[18:14] <rtg> SEJeff: I don't spend a lot of time supporting user built kernels. Its not that I don't care, I just don't have time. So, if they know enough to apply the patches, then more power to them. Otherwise, they are on their own.
[18:14] <SEJeff> rtg, something like: http://pastebin.com/m64b6a4dc
[18:15] <SEJeff> rtg, That was my point. You are agreeing with me. If it is a stock ubuntu hardy kernel, that would catch it. A stock hardy kernel has apparmor applied
[18:15] <rtg> SEJeff: that definitely works for Hardy. 
[18:16] <SEJeff> Ok well then I'll respond to that thread, Chris can put that in btrfs, and we can happily test the next get linux filesystem. Thanks
[18:16] <rtg> SEJeff: np.
[18:18] <SEJeff> rtg, One last thing. Would it be a better idea to do a version check for each official ubuntu kernel with apparmor?
[18:22] <rtg> SEJeff: I can't remember when the AA patches appeared. with Feisty? You know, I'm still not sure why CONFIG_SECURITY_APPARMOR isn't sufficient? If the AA patches have been applied, then the Ubuntu kernel won't compile unless CONFIG_SECURITY_APPARMOR=y. So, I can guarantee the AA code is compiled.
[18:23] <SEJeff> Is that because it is such an invasive patch and doesn't ifdef everything out?
[18:24] <rtg> SEJeff: pretty much. I think remove_suid() is a good example. The prototype is changed, but not guarded by an AA ifdef.
[18:25] <rtg> SEJeff: it would take long to verify that for sure.
[18:25] <rtg> s/wwould/wouldn't/
[18:25] <SEJeff> rtg, Alright, I'll do a few compile tests with CONFIG_SECURITY_APPARMOR disabled on hardy kernels
[18:25] <SEJeff> rtg, Thanks
[18:25] <rtg> SEJeff: ok, let me know if I'm completely wrong.
[18:52] <SEJeff> rtg, compile test without APPARMOR builds, tried it twice. make -j8 is a great thing
[18:52] <SEJeff> It gives some nasty warnings so I'm not sure how well it would work
[18:56] <Rabiddog> re: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/220493
[18:56] <Rabiddog> does anyone know what changed from kernel 2.6.24-12 to 2.6.24-16 that affected dmraid?
[19:00] <rtg> SEJeff: drat. All I can say is that Ubuntu isn't gonna apply the AA patches without also compiling them. I think its safe to assume CONFIG_SECURITY_APPARMOR will always be 'y'
[19:00] <SEJeff> And upstream will likely also agree with that. It is a safe assumption to assume the user is smart if the case is otherwise
[19:01] <rtg> SEJeff: The user best be smart :)
[19:01] <Rabiddog> The following error "ERROR: device-mapper target type "raid45" not in kernel" is occuring
[19:02] <smb> Rabiddog: Might be just a naming problem
[19:02] <calc> rtg: do you recall which bug number is about the key stuck scheduler related bug?
[19:03] <calc> i'm seeing 188226 but that doesn't appear to be the one i saw before
[19:03] <smb> Rabiddog: I just got a PPA ready for testing https://launchpad.net/~stefan-bader-canonical/+archive
[19:03] <Rabiddog> smb, any idea how to fix it? my raid array is no longer recognized, in gutsy and buddy of mine compiled a new kernel for me
[19:03] <Rabiddog> k looking at that
[19:04] <Rabiddog> PPA stand for what?
[19:04] <smb> Rabiddog: Personal Package Archive
[19:04] <Rabiddog> I see...does it have a fix for that in it?
[19:05] <smb> Rabiddog: IOW someplace to put stuff to try. I hope so. MAinly I just made sure the module is named in a more standard way
[19:05] <rtg> calc: I think it was this one: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=4b7c68904bf9ada8c4770ce5927e8ec71769ed92
[19:05] <Rabiddog> Well I'm willing to test, I'll add those sources to apt
[19:05]  * Rabiddog flips screens
[19:05] <calc> rtg: yea :)
[19:06] <calc> bug 218516 was the one i saw before :)
[19:06] <smb> Rabiddog: Great. Let me know whether this helps
[19:06] <calc> a user was mentioning they were bitten by what sounds like that bug
[19:06] <Rabiddog> gimme a few gotta manually copy the sources
[19:06] <calc> rtg: is it fixed in hardy-proposed/hardy-updates yet?
[19:06] <rtg> calc: its an SRU in -proposed. I'll upload -meta in a bit (which should complete the whole ABI bump process)
[19:07] <calc> rtg: ok
[19:14] <Rabiddog> smb
[19:14] <smb> Rabiddog: yo
[19:14] <Rabiddog> inux-ubuntu-modules-2.6.24 - 2.6.24-16.23ubuntu4 <--- is this the package I should upgrade?
[19:14] <smb> Rabiddog: yes
[19:14] <Rabiddog> k
[19:14] <Rabiddog> sec
[19:19] <Rabiddog> rebooting the box now :)
[19:21] <Rabiddog> The following error "ERROR: device-mapper target type "raid45" not in kernel" is still occuring, smb 
[19:21] <Rabiddog> hmm however
[19:21] <smb> Rabiddog: Thats bad
[19:22] <smb> Rabiddog: does lsmod show a dm-raid45 or dm_raid45
[19:22] <smb> ?
[19:22] <mdomsch> rtg: LP 225811 if you'd take it please
[19:23] <Rabiddog> sec...it gave the error but my hdd array loaded
[19:23] <Rabiddog> checking lsmod
[19:24] <smb> Rabiddog: likewise "dmsetup targets" should list it as well. If yes, maybe the msg is just an initial warning before loading the module
[19:28] <Rabiddog> shows dm_raid45
[19:29] <Rabiddog>  is that bad or good, smb 
[19:30] <smb> Rabiddog: I would count is as good. If dmsetup shows dmraid45 as target as well, well then it should work
[19:30] <Rabiddog> sec checking that
[19:31] <smb> Rabiddog: And one final thing: "dmsetup table" should list something with dmraid45 as well (if that is used)
[19:32] <Rabiddog> dmsetup targets shows just "raid45"
[19:32] <Rabiddog> raid45 as well
[19:32] <Rabiddog> for tables
[19:32] <smb> Rabiddog: Not linear? 
[19:32] <Rabiddog> huh
[19:33] <smb> Rabiddog: linear is a built in target of device-mapper. Should normally be there
[19:33] <Rabiddog> sec
[19:34] <Rabiddog> yep its there first line
[19:34] <Rabiddog> forgive me I may have compiled kernels but I'm still a bit of a noob :)
[19:34] <smb> Rabiddog: So that looks good setup wise.  No prob. 
[19:35] <smb> Rabiddog: So before, there were the messages and the array was not created and now we still have the message but it is
[19:35] <Rabiddog> ok.... now this adventure broke my nvidia drivers for sum reason....lol
[19:36] <Rabiddog> smb, k
[19:36] <Rabiddog> thanx...is that all that needs testing smb?
[19:38] <smb> Rabiddog: Hm, strange. I guess one thing. I would put some updates to bud 22ß403. Maybe you could add some coments from your test
[19:38] <smb> bug 220493
[19:40] <Rabiddog> doh tat links to bugzilla of mozilla
[19:41] <smb> Rabiddog: launchpad. https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/220493
[19:43] <Rabiddog> k as soon as I get my video drivers working, dang thing is launching a bad video mode when I log into gnome
[19:43] <Rabiddog> can't figure out how to delete the default setting
[19:49]  * Rabiddog sighs and runs off to another channel to figure out his next issue
[20:52] <Rabiddog> smb: I added a comment https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/220493/comments/4
[20:55] <smb> Rabiddog: Ok, thanks. Hopefully this helps others as well. And then maybe that qualifies as simple quirk... Let's see
[20:56] <Rabiddog> k
[20:58] <Kano> btw. the dmraid should be patched too
[20:59] <Kano> in 3 positions
[20:59] <Kano> init script, then the module should be added to initramfs, then it should be loaded in initramfs
[21:02] <Rabiddog> looks at smb
[21:02] <smb> Kano: That would be a different story (domain). 
[21:04] <Rabiddog> heh, I forgot I still have have modprobe -Q dm-raid4-5 in my initramfs script
[21:05] <smb> Rabiddog: That was the old name. Should not do anything now
[21:05] <Rabiddog> ah k
[21:07] <Rabiddog> bah dc ftw
[21:13] <Rabiddog_Biteme> hmm
[21:13] <Rabiddog> hmm
[21:14] <Rabiddog> woot :)
[21:14] <Rabiddog> thanx for your help smb
[21:14] <smb> Rabiddog: ur welcome :)
[21:15] <Rabiddog> and now u know it works except for the quirk
[21:18] <smb> Rabiddog: Yup. Thanks for trying
[21:21] <Kano> btw. the dm name is correct
[21:21] <Kano> no need to change that
[21:22] <Kano> dm-raid4-5 is the name from the official patch too
[21:22] <smb> Kano: But that was the only change I made between not working and working.
[21:23] <Kano> it never had a differnet name..
[21:23] <smb> Kano: Most other modules keep their names close to the target name. So autoload works. 
[21:24] <Kano> well you need to put it in the initrd anyway 
[21:24] <Kano> or you need to use another hd for booting
[21:25] <smb> Kano: sure. Though I don't see this likely for Hardy after it is now released.
[21:27] <Kano> maybe fast enough for a service relase
[21:27] <Kano> as you want to support it serveral years ;)
[21:27]  * Rabiddog eyes the gnome Ui windows bug that cropping up
[21:28] <Kano> btw. the lum for intrepid does not compile, missing unionfs include
[21:28]  * Rabiddog eyes the hal mod and its bugs
[21:29] <Kano> can i copy the aufs folder to the hardy lum?
[21:32] <Rabiddog> kano whats is lum btw?
[21:34] <Kano> also it was 100% wrong to drop my patch for the guitar, it does not work with your intrepid git
[21:34] <Kano> nothing in upstream
[21:35] <Kano> at least not the guitar
[22:05] <pwnguin> guitar?
[22:05] <pwnguin> in kernel?
[22:05] <Kano> the xbox guitar
[22:06] <pwnguin> Kano: why isn't it in the kernel.org?
[22:06] <Kano> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=c1838f1600cc7196363a23da1f76869600e17da1
[22:06] <Kano> thats my patch
[22:06] <pwnguin> that seems like a simple patch to pass upstream
[22:06] <Kano> and the guitar does not work with 2.6.25
[22:07] <pwnguin> 2.6.25 would work with the extra identifier though?
[22:08] <Kano> did not try yet, i only added some other patches to fix build problems
[22:08] <Kano> tested it before with the debian trunk kernel
[22:08] <pwnguin> I'm just saying if it works, you might as well get it included in kernel.org
[22:09] <pwnguin> its The Right Thing To Do
[22:09] <Kano> well i made it for 2.6.24
[22:09] <Kano> and there it works
[22:09] <pwnguin> its a two line patch that almost certainly didn't change
[22:10] <Kano> it is cool to play frets on fire with that guitar
[22:10] <pwnguin> sure
[22:11] <pwnguin> but wherever possible I think the kernel team should be providing changes upstream as well
[22:11] <pwnguin> and this is... very possible I think
[22:13] <Kano> why is alsaconf removed in ubuntu?
[22:15] <pwnguin> wait
[22:15] <pwnguin> kano
[22:15] <pwnguin> it IS in linus's tree
[22:15] <crimsun> Kano: known to break audio configuration and/or freeze the machine.
[22:15] <pwnguin> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/input/joystick/xpad.c;h=b29e3affb805a97126ccee39dcc867cd6e40dfe3;hb=b66e1f11ebc429569a3784aaf64123633d9e3ed1
[22:15] <Kano> crimsun: well i need that
[22:16] <crimsun> Kano: the correct method is to fix the ISA drivers.
[22:16] <Kano> crimsun: i need it to unload drivers when they have been loaded in wrong order
[22:16] <crimsun> Kano: err...
[22:17] <crimsun> you should never have to use alsaconf to reorder indices
[22:17] <Kano> so what do you use
[22:18] <crimsun> you can either use the index module parameter for each ALSA driver, or you can use the slots parameter for snd.ko (requires alsa-kernel >=1.0.16)
[22:18] <Kano> options snd-emu10k1 index=0
[22:18] <crimsun> you'd place them in a modprobe conffile, e.g., options snd slots=snd-usb-audio,snd-emu10k1,snd-hda-intel
[22:19] <Kano> when this is set it still loads the other as 0
[22:19] <crimsun> that's why I recommend using snd.ko's slots parameter instead of each driver's index parameter.
[22:20] <Kano> but as hotfix alsaconf is really good to use
[22:20] <crimsun> with slots, index 0 is reserved for snd-usb-audio, index 1 for snd-emu10k1, index 2 for snd-hda-intel
[22:21] <crimsun> there's no real reason to use alsaconf for that.  One can script the above sequence for an arbitrary set.
[22:21] <Kano> how about putting it in an extra package for those who really want it?
[22:22] <crimsun> I would strongly recommend against doing so, but I certainly won't stand in the way of other core-devs changing debian/rules.
[22:23] <crimsun> blah, I'll just write a script to do what you need
[22:23] <crimsun> (and stash it in alsa-utils)
[22:24] <Rabiddog> lol
[22:25] <Rabiddog> crimsun, I saw your tip on the bug report for me I'll try it later
[22:25] <crimsun> Rabiddog: err, sorry, which bug report?
[22:25] <Rabiddog> the dmraid
[22:26] <Rabiddog> regression
[22:26] <crimsun> Rabiddog: hmm, I don't remember commenting...  Which bug #?
[22:26] <Kano> regession is the wrong word as i patched it before for you ;)
[22:26] <Rabiddog> lol
[22:28] <Rabiddog> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/220493 crimsun if crimson fox is u
[22:29] <crimsun> Rabiddog: no, I'm strictly crimsun and/or appended underscore variants, sorry.
[22:29] <Rabiddog> heh
[22:29] <pwnguin> there are far too few bugs associated with crimson-fox for that ;)
[22:31] <Rabiddog> heh
[22:40] <Rabiddog> woot samba fixed
[23:54] <mkrufky> Steve Langasek in here?
[23:55] <laga> mkrufky: slangasek is in #ubuntu-motu for example
[23:55] <mkrufky> thank you