[10:57] <StevenK> Hi, can I bleat at someone to update LBM so that -5 can be removed from Karmic, and to also update linux-meta so that -7 can be removed from Karmic? No fair having 4 different versions of the kernel in the archive.
[10:58] <smb> StevenK, meta proably just waits for me to upload
[10:58] <smb> apw, have you got a new lbm?
[10:59] <StevenK> Last person to touch LBM was rtg
[10:59] <apw> smb, no i'll have a look now
[10:59] <smb> Look like it. 
[10:59] <apw> i presume all i need to do is change the abi number
[10:59] <smb> Probably just needs the abi version bump and be done
[10:59] <smb> apw, ack
[10:59] <apw> will give that poke now
[11:00] <apw> then we can upload that, and meta
[11:00] <apw> we like having lots of kernels in the archive, makes its nice a full
[11:00] <smb> apw, poke me with that
[11:00] <apw> will do
[11:02] <smb> apw, btw. got a jaunty-pre-proposed ppa set up now. So someone needs the Jaunty with all the stable updates now can do so
[11:02]  * StevenK grumbles at apw
[11:02] <apw> smb, sounds good
[11:02] <smb> https://launchpad.net/~stefan-bader-canonical/+archive/jaunty
[11:03] <apw> smb, ok seems rtg didn't push his changes for lbm, will reconstruct
[11:04] <smb> apw, Oh dear. Well I am away for an hour anyway... ;-)
[11:04] <apw> _thanks_
[13:57] <lamont> Jun  3 12:08:09 foo kernel: [482756.764829] [drm:i915_getparam] *ERROR* Unknown parameter 6 
[13:58] <lamont> wassat? ^^
[14:05] <smb> lamont, something asking the i915 driver an inappropriate question
[14:05] <lamont> heh
[14:05] <lamont> ok
[14:06] <smb> Its from i915_getparam. It return EINVAL but prints also this msg. I'd say forgotten debug code or so.
[14:35] <apw> from discussions with bryce it seems to be a benign missmatch between the kernel and mesa
[18:04] <Notch-1> hi all
[18:04] <Notch-1> news about CONFIG_BLK_DEV_LOOP ?
[18:07] <nigelp> apw, the mainline kernel you pointed me to is a huge improvement.. not had a single kernel panic since I installed it this morning.
[18:13] <Notch-1> so there is somebody in there, hello nigelp :D
[19:14] <Notch-1> guyyyyyys? how can we talk with you if you do not reply on the channel nor on the mailing list?
[19:14] <Notch-1> (nor on launchpad)
[19:48] <manjo> Notch-1, what help are you looking for ? 
[19:55] <Notch-1> oh thank you manjo, i'm so desperate, there is this problem with CONFIG_BLK_DEV_LOOP=y
[19:56] <manjo> Notch-1, which kernel ? jaunty/karmic ?
[19:56] <Notch-1> all loop-aes module users need CONFIG_BLK_DEV_LOOP=m or better =n, instead we need to recompile the kernel every update to use the loop module (that i use for the root filesystem, for instance)
[19:56] <Notch-1> since jaunty
[19:58] <manjo> Notch-1, let me look at the config... did u mail the ubuntu kernel list about it ? Most ppl were out last week for UDS so everyone is just catching up on backlog of mail
[20:00] <manjo> Notch-1, your requirement looks fair, let me see if that can be resolved...
[20:01] <mjg59> Notch-1: The issue was brought up on the mailing list, and a kernel dev asked why this code wasn't just upstream
[20:01] <mjg59> I didn't see a response to that question
[20:01] <Notch-1> yeah, i know, but is on launchpad since 3 month, and it's really difficult to talk to you guys :D anyway there is already a post: http://archives.free.net.ph/message/20090524.121638.72482e0d.en.html
[20:01] <mjg59> Notch-1: Right. Amit then asked why it wasn't upstream.
[20:02] <mjg59> And nobody replied to him
[20:02] <Notch-1> mjg59: yes, i talk to them, i'm about to search info to answer on that question, but our question is different, it was just a second question...
[20:02] <Notch-1> talked to him, sorry :P
[20:03] <smb> It's already late, so I hopefully don't sound too grumpy. If I understood the things correctly you need loop to be a module to replace it with another module?
[20:03] <mjg59> Notch-1: The answer is likely to be "It's not a priority to support out of tree kernel modules"
[20:03] <Notch-1> i don't know why loop-aes is not upstream, i just know that many people use it
[20:04] <Notch-1> yes but this configuration change is a big deal to us, and it's very simple to get back...
[20:04] <mjg59> The main reason to build the loop module in is that it can't be easily autoloaded
[20:05] <smb> The change was also to reduce module loads in favour of boot speed
[20:05] <Notch-1> as i told to amitk i think that some peoples just don't like loop-aes and jari ruusu (his creator), i've got strange comments to them on some channel...
[20:06] <Notch-1> yes, but we can't use a new custom module instead of loop
[20:07] <mjg59> Notch-1: So?
[20:07] <mjg59> Notch-1: Every configuration change is a tradeoff between different usecases
[20:08] <Notch-1> so we need to recompile the whole kernel every update, to use a module
[20:08] <mjg59> The aim isn't to break loop-aes, the aim is to reduce complexity, ensure that loopback devices are always available and slightly increase boot speed
[20:08] <smb> If aes-loop completely replaces loop I wonder why it isn't a completely separate module. But maybe I did not understand that correctly
[20:08] <Notch-1> yes but this change cutts off many people, and what is the time advantage? 1/100 sec?
[20:09] <mjg59> Anyway, Fedora is configured in exactly the same way now
[20:09] <mjg59> loop-aes should either stop conflicting with standard kernel functionality or get merged upstream
[20:10] <Notch-1> smb: i don't know this, but i suggest to set CONFIG_BLK_DEV_LOOP to n and force anybody who needs the loop module to just install loop-aes... so more boot speed, and less throubles for everybody
[20:11] <smb> Just to put off all users of the standard loop device?
[20:11] <Notch-1> mjg59: you are right, but i'm just a user... and now i can't upgrade to jaunty....
[20:11] <mjg59> Oh, right, I remember
[20:11] <Notch-1> smb: with loop-aes they don't need the original loop module anymore...
[20:11] <mjg59> Jari refuses to submit it upstream because he thinks the kernel developers are inept
[20:12] <Notch-1> so only who needs loop gets the less boot speed... seems best for all
[20:12] <Notch-1> mjg59: hahahahaha :D
[20:12] <smb> But it would require all to get aes-loop instead of having the in-kernel one. 
[20:12] <Notch-1> so it's personal, as i tought
[20:12] <mjg59> Notch-1: No. That's why it's not upstream.
[20:12] <mjg59> Notch-1: I should point out that I'm not an Ubuntu kernel developer
[20:12] <Notch-1> smb: yes, but it's better to recompile the kernel every update
[20:13] <smb> I am with mjg59 here. It should get upstreamed or stop being a conflicting module
[20:13] <mjg59> But if you filed this against Fedora I'd close it WONTFIX
[20:13] <Notch-1> smb: me too
[20:13] <Notch-1> but you guys should stop conflicting :D
[20:14] <mjg59> Notch-1: Uh. The project outside the kernel gets to avoid conflicting with the kernel.
[20:14] <mjg59> Not the other way around.
[20:14] <Notch-1> anybody should do his part :D
[20:15] <Notch-1> with this system now me, a user, need to talk to the creator of a package that i need to convince him to get his module upstrem... it does not sounds right
[20:15] <mjg59> Notch-1: No, that's exactly how it should be
[20:16] <Notch-1> :D
[20:16] <mjg59> Notch-1: If the developer of that external code refuses to work with the upstream kernel developers then it's his fault that users end up unhappy
[20:16] <Notch-1> sure, easy
[20:16] <mjg59> So the issue here is Jari
[20:17] <Notch-1> or you should let us load any module without throubles, even if with a microsecond of boot delay
[20:17] <mjg59> He needs to either change loop-aes so that it doesn't conflict with loop, or he needs to get his code upstream
[20:17] <Notch-1> the issue is that your new configuration does not allow me to load a custom module
[20:17] <Notch-1> the kernel HAS to allow anybodys code without throubles, that's democracy
[20:17] <mjg59> Notch-1: The kernel isn't a democracy
[20:18] <mjg59> Notch-1: It's better - if someone does something you don't like, then you get to change it as much as you want
[20:18] <Notch-1> mjg59: so that's why it does not work :D
[20:18] <Notch-1> the road it's not so easy if you change the configuration like this :D
[20:19] <manjo> Notch-1, I think for now you are stuck recompiling the kernel 
[20:19] <Notch-1> manjo: me too :°
[20:20] <Notch-1> congrats guys, a very clean and usable system...
[20:20] <Notch-1> linus would be proud :D
[20:22] <mjg59> Linus would ask you why the code's not upstream
[20:23] <Notch-1> :D
[20:23] <Notch-1> still being proud of you :D
[20:29] <Notch-1> anyway the loop-aes-source package description still says "It can be used with module-assistant, make-kpkg or stand-alone to build loop-AES module packages."...
[20:29] <mjg59> Notch-1: That sounds like a bug in the loop-aes-source package
[20:29] <Notch-1> yes, with this configuration now this is a bug