Re: Linux-libre

[Ludovic Courtès]

Andreas Enge <address@hidden> 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’.