[10:57] 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] StevenK, meta proably just waits for me to upload [10:58] apw, have you got a new lbm? [10:59] Last person to touch LBM was rtg [10:59] smb, no i'll have a look now [10:59] Look like it. [10:59] i presume all i need to do is change the abi number [10:59] Probably just needs the abi version bump and be done [10:59] apw, ack [10:59] will give that poke now [11:00] then we can upload that, and meta [11:00] we like having lots of kernels in the archive, makes its nice a full [11:00] apw, poke me with that [11:00] will do [11:02] 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] smb, sounds good [11:02] https://launchpad.net/~stefan-bader-canonical/+archive/jaunty [11:03] smb, ok seems rtg didn't push his changes for lbm, will reconstruct [11:04] apw, Oh dear. Well I am away for an hour anyway... ;-) [11:04] _thanks_ [13:57] Jun 3 12:08:09 foo kernel: [482756.764829] [drm:i915_getparam] *ERROR* Unknown parameter 6 [13:58] wassat? ^^ [14:05] lamont, something asking the i915 driver an inappropriate question [14:05] heh [14:05] ok [14:06] Its from i915_getparam. It return EINVAL but prints also this msg. I'd say forgotten debug code or so. [14:35] from discussions with bryce it seems to be a benign missmatch between the kernel and mesa === thunderstruck is now known as gnomefreak === bjf is now known as bjf__afk [18:04] hi all [18:04] news about CONFIG_BLK_DEV_LOOP ? [18:07] 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] so there is somebody in there, hello nigelp :D [19:14] guyyyyyys? how can we talk with you if you do not reply on the channel nor on the mailing list? [19:14] (nor on launchpad) [19:48] Notch-1, what help are you looking for ? [19:55] oh thank you manjo, i'm so desperate, there is this problem with CONFIG_BLK_DEV_LOOP=y [19:56] Notch-1, which kernel ? jaunty/karmic ? [19:56] 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] since jaunty [19:58] 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] Notch-1, your requirement looks fair, let me see if that can be resolved... [20:01] 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] I didn't see a response to that question [20:01] 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] Notch-1: Right. Amit then asked why it wasn't upstream. [20:02] And nobody replied to him [20:02] 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] talked to him, sorry :P [20:03] 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] Notch-1: The answer is likely to be "It's not a priority to support out of tree kernel modules" [20:03] i don't know why loop-aes is not upstream, i just know that many people use it [20:04] yes but this configuration change is a big deal to us, and it's very simple to get back... [20:04] The main reason to build the loop module in is that it can't be easily autoloaded [20:05] The change was also to reduce module loads in favour of boot speed [20:05] 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] yes, but we can't use a new custom module instead of loop [20:07] Notch-1: So? [20:07] Notch-1: Every configuration change is a tradeoff between different usecases [20:08] so we need to recompile the whole kernel every update, to use a module [20:08] 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] 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] yes but this change cutts off many people, and what is the time advantage? 1/100 sec? [20:09] Anyway, Fedora is configured in exactly the same way now [20:09] loop-aes should either stop conflicting with standard kernel functionality or get merged upstream [20:10] 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] Just to put off all users of the standard loop device? [20:11] mjg59: you are right, but i'm just a user... and now i can't upgrade to jaunty.... [20:11] Oh, right, I remember [20:11] smb: with loop-aes they don't need the original loop module anymore... [20:11] Jari refuses to submit it upstream because he thinks the kernel developers are inept [20:12] so only who needs loop gets the less boot speed... seems best for all [20:12] mjg59: hahahahaha :D [20:12] But it would require all to get aes-loop instead of having the in-kernel one. [20:12] so it's personal, as i tought [20:12] Notch-1: No. That's why it's not upstream. [20:12] Notch-1: I should point out that I'm not an Ubuntu kernel developer [20:12] smb: yes, but it's better to recompile the kernel every update [20:13] I am with mjg59 here. It should get upstreamed or stop being a conflicting module [20:13] But if you filed this against Fedora I'd close it WONTFIX [20:13] smb: me too [20:13] but you guys should stop conflicting :D [20:14] Notch-1: Uh. The project outside the kernel gets to avoid conflicting with the kernel. [20:14] Not the other way around. [20:14] anybody should do his part :D [20:15] 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] Notch-1: No, that's exactly how it should be [20:16] :D [20:16] 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] sure, easy [20:16] So the issue here is Jari [20:17] or you should let us load any module without throubles, even if with a microsecond of boot delay [20:17] 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] the issue is that your new configuration does not allow me to load a custom module [20:17] the kernel HAS to allow anybodys code without throubles, that's democracy [20:17] Notch-1: The kernel isn't a democracy [20:18] 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] mjg59: so that's why it does not work :D [20:18] the road it's not so easy if you change the configuration like this :D [20:19] Notch-1, I think for now you are stuck recompiling the kernel [20:19] manjo: me too :° [20:20] congrats guys, a very clean and usable system... [20:20] linus would be proud :D [20:22] Linus would ask you why the code's not upstream [20:23] :D [20:23] still being proud of you :D [20:29] 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] Notch-1: That sounds like a bug in the loop-aes-source package [20:29] yes, with this configuration now this is a bug === bjf is now known as bjf_away