| 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:57 |
|---|---|---|
| smb | StevenK, meta proably just waits for me to upload | 10:58 |
| smb | apw, have you got a new lbm? | 10:58 |
| 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 | 10:59 |
| 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:00 |
| 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:02 |
| apw | smb, ok seems rtg didn't push his changes for lbm, will reconstruct | 11:03 |
| smb | apw, Oh dear. Well I am away for an hour anyway... ;-) | 11:04 |
| apw | _thanks_ | 11:04 |
| lamont | Jun 3 12:08:09 foo kernel: [482756.764829] [drm:i915_getparam] *ERROR* Unknown parameter 6 | 13:57 |
| lamont | wassat? ^^ | 13:58 |
| smb | lamont, something asking the i915 driver an inappropriate question | 14:05 |
| lamont | heh | 14:05 |
| lamont | ok | 14:05 |
| smb | Its from i915_getparam. It return EINVAL but prints also this msg. I'd say forgotten debug code or so. | 14:06 |
| apw | from discussions with bryce it seems to be a benign missmatch between the kernel and mesa | 14:35 |
| === thunderstruck is now known as gnomefreak | ||
| === bjf is now known as bjf__afk | ||
| Notch-1 | hi all | 18:04 |
| Notch-1 | news about CONFIG_BLK_DEV_LOOP ? | 18:04 |
| 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:07 |
| Notch-1 | so there is somebody in there, hello nigelp :D | 18:13 |
| 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:14 |
| manjo | Notch-1, what help are you looking for ? | 19:48 |
| Notch-1 | oh thank you manjo, i'm so desperate, there is this problem with CONFIG_BLK_DEV_LOOP=y | 19:55 |
| 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:56 |
| 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 | 19:58 |
| manjo | Notch-1, your requirement looks fair, let me see if that can be resolved... | 20:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| Notch-1 | yes, but we can't use a new custom module instead of loop | 20:06 |
| mjg59 | Notch-1: So? | 20:07 |
| mjg59 | Notch-1: Every configuration change is a tradeoff between different usecases | 20:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| manjo | Notch-1, I think for now you are stuck recompiling the kernel | 20:19 |
| Notch-1 | manjo: me too :° | 20:19 |
| Notch-1 | congrats guys, a very clean and usable system... | 20:20 |
| Notch-1 | linus would be proud :D | 20:20 |
| mjg59 | Linus would ask you why the code's not upstream | 20:22 |
| Notch-1 | :D | 20:23 |
| Notch-1 | still being proud of you :D | 20:23 |
| 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 | 20:29 |
| === bjf is now known as bjf_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!