Andreas Enge <andr...@enge.fr> skribis: > On Thu, May 29, 2014 at 05:53:46PM +0200, Ludovic Courtès wrote: >> The problem is that the headers are what libc builds against. It >> doesn’t need the latest version (in fact, we build it with >> --enable-kernel=2.6.30.) > > I still do not quite get it. If not necessary, it would albeit be allowed to > have the same versions, no?
Yes. > Then why do we not make this choice and maybe update to a long term > kernel in core-updates as suggested in the discussion following > http://bugs.gnu.org/14851 ? How about creating one package > linux-libre with two outputs 'out' and 'headers'? We can’t do that, because changing linux-libre-headers entails a full rebuild. Thus, we want a stable linux-libre-headers. Also, libc is decoupled from the actual kernel version, so we don’t have to worry here. > When I noticed that udev was looking for kmod, I started packaging it. The > debian web page states it is a replacement of module-init-tools, and indeed > it seems to contain the same binaries (lsmod etc.). I tried to configure udev > with module-init-tools as an input, but it still asks for kmod. Our > linux-libre > package has module-init-tools as an input; should we use kmod instead? Then > if kmod requires the kernel headers, my suggestion of the previous paragraph > would not work. Oh, I see. That vaguely rings a bell. Using kmod looks like the better long-term solution, so we’ll have to figure that out. >> I suspect the problem is that linux-libre-headers is build with the >> default config, which may lack some features, and so as a side effect >> some headers are not installed. >> Would you like to look into it? Or maybe Alírio? :-) > > I am having a quick look at it, but I would gladly step back for someone more > knowledgeable! My only interest in all this is actually to compile kdelibs; > my bug report that it does not require udev according to its configure phase, > but does not compile without it, has not seen a resolution so far. Recursive troubleshooting. :-) Ludo’.
