From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Linux-libre Date: Thu, 29 May 2014 23:37:51 +0200 Message-ID: <87lhtk8dw0.fsf@gnu.org> References: <20140529143026.GA12567@debian> <87wqd48tth.fsf@gnu.org> <20140529170800.GA14924@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wq81O-000080-IV for guix-devel@gnu.org; Thu, 29 May 2014 17:38:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wq81J-0004RU-MG for guix-devel@gnu.org; Thu, 29 May 2014 17:37:58 -0400 Received: from hera.aquilenet.fr ([2a01:474::1]:48361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wq81J-0004R1-FA for guix-devel@gnu.org; Thu, 29 May 2014 17:37:53 -0400 In-Reply-To: <20140529170800.GA14924@debian> (Andreas Enge's message of "Thu, 29 May 2014 19:08:00 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andreas Enge Cc: guix-devel@gnu.org Andreas Enge skribis: > On Thu, May 29, 2014 at 05:53:46PM +0200, Ludovic Court=C3=A8s wrote: >> The problem is that the headers are what libc builds against. It >> doesn=E2=80=99t need the latest version (in fact, we build it with >> --enable-kernel=3D2.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=E2=80=99t do that, because changing linux-libre-headers entails a fu= ll rebuild. Thus, we want a stable linux-libre-headers. Also, libc is decoupled from the actual kernel version, so we don=E2=80=99t 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 inde= ed > 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? Th= en > if kmod requires the kernel headers, my suggestion of the previous paragr= aph > would not work. Oh, I see. That vaguely rings a bell. Using kmod looks like the better long-term solution, so we=E2=80=99ll 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=C3=ADrio? :-) > > 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 kdelib= s; > my bug report that it does not require udev according to its configure ph= ase, > but does not compile without it, has not seen a resolution so far. Recursive troubleshooting. :-) Ludo=E2=80=99.