=== zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [12:21] heylo [06:14] morning === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-kernel === lamont [~lamont@mix.mmjgroup.com] has joined #ubuntu-kernel === zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [03:09] hey === hakGER [~hak@ip191.13.1411N-CUD12K-02.ish.de] has joined #ubuntu-kernel [03:30] fabbione: for #8189 have a look at http://marc.theaimsgroup.com/?l=linux-scsi&m=109638967308598&w=2 [03:31] but it might break abi === hakGER [~hak@ip191.13.1411N-CUD12K-02.ish.de] has left #ubuntu-kernel ["Verlassend"] [04:34] moo [04:36] fabbione: are you using baz mv for the abi files, or add /delete? [04:38] looks like baz mv, if I'm understanding the cryptic output from baz update [06:04] fabbione: uh never mind its alrady applied [06:15] hi guys [06:15] baz mv :-) [06:15] hey fabbione how is it going? [06:15] it's going finr thanks and you? [06:15] good...just enjoying a day off [06:17] some bugs have bounced to kernel-team [06:18] yeah noticed that [06:21] so uh i take it we are going to be using 2.6.11 for breezy/bender [06:23] nope [06:24] i am planning 2.6.12 [06:24] ok [06:24] i don't think we should spend too much time on 2.6.11 for 2 reasons [06:24] 2.6.12 is already at RC stage [06:24] that means it will be out in final pretty soon [06:25] and.... [06:25] 2.6.11 has a lot of security holes phone... sec. [06:25] k [06:25] sorry i was saying.. [06:26] 2.6.11 has a lot of security holes that are fixed in 2.6.12 and we have as patches for 2.6.10 [06:26] that means a lot of extra work in portforwarding the patches [06:27] sounds reasonable i was thinking about version numbering last night [06:27] i started looking into the XEN patch [06:27] and how to build the debs for it [06:27] at least the kernel side [06:28] i say let schweeb handle the user side [06:28] yes [06:28] userland is very simple [06:28] i could package it in half day probablu [06:28] for the kernel version stuff i was thinking something 2.6.12.abi.patchlevel [06:29] our plan is to drop the patch level completely [06:29] MEH [06:29] the abi [06:29] and use what? [06:30] nothing. s/abi//g [06:30] dilinger did a proposal on debian-kernel that sounds interesting [06:30] ok...then how are you going to keep track if they are using for example different acpi snapshots [06:30] ill have to see [06:30] we still track the package version [06:30] that cannot be removed [06:31] but we can kill the ABI [06:31] ok [06:31] we need to see how complex would be to manage without [06:33] do have a url for dilinger's proposal [06:34] it should be somewhere here in channel logs [06:34] from yesterday iirc [06:34] k [06:34] heh i wont be lazy and ill find it myself ;) [06:37] so you would have a base kernel-image and you would have the user compile the modules themselves ? [06:38] with module-assitant? [06:38] something like that, but using a new standard hook where to store the sources of the external modules [06:38] so that they can be compiled at postinst time [06:38] given that there is an ABI change [06:39] so what if they have a slow ass system? [06:39] nasty, eh? [06:39] yeah reminds me of gentoo kind of [06:39] well in all cases if they use thirdy part modules they will have to recompile them anyway [06:39] we can still do in such a way to ensure that the modules we provide are always in sync [06:40] true but what if the kernel-headers are mixed up, for example if someone who thinks they are know what they are doing but they dont messes up and files a bug report [06:41] hmm. How about always triggering a recompile of l-r-m whenever a new linux-source is uploaded? True, more space, but more transparent to the end-user [06:41] or is that precisely what we're trying to avoid? [06:41] zul: i am not sure i understand... [06:41] crimsun: we are avoiding 2 things here: [06:42] 1) random recompilation of l-r-m and thirdy part modules [06:42] 2) having to deal with ABI changes, since they are embedded in the package name [06:42] both of them are not easy [06:42] well lets say they have a vanilla kernel-headers installed and they have our kernel-headers installed and something messes up [06:43] zul: our kernel headers lands alwys in a predictable place. [06:43] if they fuck up the system is kinda of not our problem [06:43] ok...but what if the user puts it in the same place... [06:43] plus we can add sanity checks before performing operations [06:43] im just trying to play devio advocate here [06:43] true.. [06:43] zul: sure.. i appreciate that :-) [06:44] that's why we need really brainstorm a lot face2face [06:44] no gentoo here ;) [06:44] it's really difficult to evaluate all the corner cases on IRC [06:44] yeah too bad i wont be at udu :) [06:44] we can also make it an option [06:44] fabbione: ok, I see regarding (1). So that means we avoid automatically triggering a rebuild on the buildds whenever a new l-s is uploaded? === svenl_ [~luther@AStrasbourg-251-1-52-128.w82-126.abo.wanadoo.fr] has joined #ubuntu-kernel [06:45] crimsun: there are a lot of implication in hiding an ABI change. l-r-m is really the last of our problems [06:45] since we have control of it [06:45] fabbione: right, gotcha [06:46] our problem is to find an efficent way to detect external modules (out of Ubuntu), and do in such a way that if there is an ABI change, print a big fat warning to the user in the first place [06:46] and provide an automatic system to manage recompilation of these modules on request [06:47] of course there would be the nice config file with: do_everything_for_me=[yes|no|ask] [06:47] well why not have a list of base modules that we support like ipw2200, hostap, and then inform the users that they abi has changed we are going to break shit now [06:47] er...list of 3rd party modules [06:48] zul: i am not talking about 3dy part modules in our tree. [06:48] for example i compile the quickcam module myself [06:48] duh..oops [06:48] that is not part of either linux-source or l-r-m [06:48] how can i make it so that if i change the ABI i can tell the user: hey dude.. this module you compiled yourself will not load.... [06:48] and so on... [06:48] + [06:49] hey dude: if you put the source in this dir [06:49] it will be recompiled automatically for you [06:49] sounds reasonable [07:06] we can't use a Xen kernel as our default kernel... yet [07:06] so that means that we to create 386-xen, 686-xen, k7-xen [07:06] SMP is not supported in 2.6.10 [07:06] but it might in 2.6.11.. not sure yet [07:06] in linux-sources? cool [07:07] well, that's the idea [07:07] so that would add 6 more linux-images on i386 [07:07] that will differ of one option [07:07] + we lose ACPI and CPUFREQ [07:08] still not supported by xen [07:08] ah and >4GB mem support.. but i don't know that many people using that much anyway [07:09] may i add a royal mess to build the package? ;) [07:09] since ARCH=xen :-) [07:09] that might attempt to create _xen.deb [07:09] ++ [07:11] i think im going to go watch the incredibles ill be back later [07:12] have fun [07:12] i will [07:12] it's a nice movie [07:12] :-) [07:12] especillay the extras for the dvd [07:20] heheh === lamont_r [~lamont@phantom.acmeps.com] has joined #ubuntu-kernel [11:18] that was a good movie