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