GNU bug report logs - #52411
[core-updates-frozen] kmod-29 build fails, cross-compiled for i586-pc-gnu

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52411 in the body.
You can then email your comments to 52411 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: bug-guix <bug-guix <at> gnu.org>
Subject: [core-updates-frozen] kmod-29 build fails, cross-compiled for
 i586-pc-gnu
Date: Fri, 10 Dec 2021 07:55:34 -0500

Hello Guix!

I haven't been able to deploy core-updates-frozen on one of my machine,
because it has the childhurd service which needs kmod-29 which fails
building, like so:

--8<---------------cut here---------------start------------->8---
config.status: executing libtool commands

        kmod 29
        =======

        prefix:                 /gnu/store/nw7xs4vv55i2w0yhpb2adq0fghzs7dcw-kmod-29
        sysconfdir:             ${prefix}/etc
        libdir:                 ${exec_prefix}/lib
        rootlibdir:             ${exec_prefix}/lib
        includedir:             ${prefix}/include
        bindir:                 ${exec_prefix}/bin
        Bash completions dir:   ${datarootdir}/bash-completion/completions

        compiler:               i586-pc-gnu-gcc
        cflags:                  -pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=3 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits -Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden -ffunction-sections -fdata-sections -g -O2
        ldflags:                 -Wl,--as-needed -Wl,--no-undefined -Wl,--gc-sections 

        experimental features:  no
        tools:                  yes
        python bindings:        no
        logging:                yes
        compression:            zstd=yes  xz=yes  zlib=yes
        debug:                  no
        coverage:               no
        doc:
        man:                    yes
        test-modules:           no

        features:               +ZSTD +XZ +ZLIB -LIBCRYPTO -EXPERIMENTAL

phase `configure' succeeded after 3.0 seconds
starting phase `patch-generated-file-shebangs'
phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
starting phase `build'
Makefile:2516: warning: overriding recipe for target '.log'
Makefile:2509: warning: ignoring old recipe for target '.log'
Makefile:2530: warning: overriding recipe for target '.log'
Makefile:2516: warning: ignoring old recipe for target '.log'
make --no-print-directory all-recursive
Makefile:2516: warning: overriding recipe for target '.log'
Makefile:2509: warning: ignoring old recipe for target '.log'
Makefile:2530: warning: overriding recipe for target '.log'
Makefile:2516: warning: ignoring old recipe for target '.log'
Making all in .
Makefile:2516: warning: overriding recipe for target '.log'
Makefile:2509: warning: ignoring old recipe for target '.log'
Makefile:2530: warning: overriding recipe for target '.log'
Makefile:2516: warning: ignoring old recipe for target '.log'
  GEN      libkmod/libkmod.pc
  CC       tools/kmod.o
  CC       tools/lsmod.o
  CC       tools/rmmod.o
  CC       tools/insmod.o
  CC       tools/modinfo.o
  CC       tools/modprobe.o
  CC       tools/depmod.o
  CC       tools/log.o
  CC       tools/static-nodes.o
  CC       shared/array.lo
  CC       shared/hash.lo
  CC       shared/scratchbuf.lo
  CC       shared/strbuf.lo
  CC       shared/util.lo
  CC       libkmod/libkmod.lo
  CC       libkmod/libkmod-builtin.lo
  CC       libkmod/libkmod-list.lo
  CC       libkmod/libkmod-config.lo
  CC       libkmod/libkmod-index.lo
  CC       libkmod/libkmod-module.lo
  CC       libkmod/libkmod-elf.lo
  CC       libkmod/libkmod-file.lo
  CC       libkmod/libkmod-signature.lo
In file included from tools/kmod.c:26:
./shared/util.h:24:56: error: ‘PATH_MAX’ undeclared here (not in a function)
   24 | int alias_normalize(const char *alias, char buf[static PATH_MAX], size_t *len) _must_check_ __attribute__((nonnull(1,2)));
      |                                                        ^~~~~~~~
In file included from tools/insmod.c:26:
./shared/util.h:24:56: error: ‘PATH_MAX’ undeclared here (not in a function)
   24 | int alias_normalize(const char *alias, char buf[static PATH_MAX], size_t *len) _must_check_ __attribute__((nonnull(1,2)));
      |                                                        ^~~~~~~~
‘
./shared/util.h:24: confused by earlier errors, bailing out
‘
./shared/util.h:24: confused by earlier errors, bailing out
In file included from tools/modinfo.c:30:
./shared/util.h:24:56: error: ‘PATH_MAX’ undeclared here (not in a function)
   24 | int alias_normalize(const char *alias, char buf[static PATH_MAX], size_t *len) _must_check_ __attribute__((nonnull(1,2)));
      |                                                        ^~~~~~~~
‘
./shared/util.h:24: confused by earlier errors, bailing out
--8<---------------cut here---------------end--------------->8---

Thanks,

Maxim

Message #8 received at 52411 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, 52411 <at> debbugs.gnu.org
Subject: Re: bug#52411: [core-updates-frozen] kmod-29 build fails,
 cross-compiled for i586-pc-gnu
Date: Fri, 10 Dec 2021 17:48:10 +0000

Maxim Cournoyer schreef op vr 10-12-2021 om 07:55 [-0500]:
> Hello Guix!
> 
> I haven't been able to deploy core-updates-frozen on one of my
> machine,
> because it has the childhurd service which needs kmod-29 which fails
> building, like so:

kmod is a linux-only thing, it's for doing things with linux kernel
modules, so the childhurd service shouldn't be using kmod. Perhaps look
at why kmod is being built in the first place?

Greetings,
Maxime.

Message #11 received at 52411 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, 52411 <at> debbugs.gnu.org
Cc: Jan Nieuwenhuizen <janneke <at> gnu.org>,
 Thiago Jung Bauermann <bauermann <at> kolabnow.com>
Subject: Re: bug#52411: [core-updates-frozen] kmod-29 build fails,
 cross-compiled for i586-pc-gnu
Date: Fri, 10 Dec 2021 17:55:56 +0000

Maxime Devos schreef op vr 10-12-2021 om 17:48 [+0000]:
> Maxim Cournoyer schreef op vr 10-12-2021 om 07:55 [-0500]:
> > Hello Guix!
> > 
> > I haven't been able to deploy core-updates-frozen on one of my
> > machine,
> > because it has the childhurd service which needs kmod-29 which
> > fails
> > building, like so:
> 
> kmod is a linux-only thing, it's for doing things with linux kernel
> modules, so the childhurd service shouldn't be using kmod. Perhaps
> look
> at why kmod is being built in the first place?

I think I might have found the issue. The following commit made the
existence/absence 'kmod' input of pciutils depend on %current-
system/%current-target-system:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=22ee7209797c023b95e22ced156df62cbff90184

but it forgot to keep in mind that nix systems != triplets.
Instead of %current-target-system, the 'current-target-nix-system'
from ‘https://issues.guix.gnu.org/49672#3’ needs to be used
(or the hurd-target? procedure).

Greetings,
Maxime.

Message #14 received at 52411 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: Thiago Jung Bauermann <bauermann <at> kolabnow.com>, 52411 <at> debbugs.gnu.org,
 Jan Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: bug#52411: [core-updates-frozen] kmod-29 build fails,
 cross-compiled for i586-pc-gnu
Date: Thu, 16 Dec 2021 14:02:22 -0500

Hello Maxime,

Maxime Devos <maximedevos <at> telenet.be> writes:

> Maxime Devos schreef op vr 10-12-2021 om 17:48 [+0000]:
>> Maxim Cournoyer schreef op vr 10-12-2021 om 07:55 [-0500]:
>> > Hello Guix!
>> > 
>> > I haven't been able to deploy core-updates-frozen on one of my
>> > machine,
>> > because it has the childhurd service which needs kmod-29 which
>> > fails
>> > building, like so:
>> 
>> kmod is a linux-only thing, it's for doing things with linux kernel
>> modules, so the childhurd service shouldn't be using kmod. Perhaps
>> look
>> at why kmod is being built in the first place?
>
> I think I might have found the issue. The following commit made the
> existence/absence 'kmod' input of pciutils depend on %current-
> system/%current-target-system:
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=22ee7209797c023b95e22ced156df62cbff90184
>
> but it forgot to keep in mind that nix systems != triplets.
> Instead of %current-target-system, the 'current-target-nix-system'
> from ‘https://issues.guix.gnu.org/49672#3’ needs to be used
> (or the hurd-target? procedure).

Thanks for your answer!  It indeed looks like a related bug.  For some
reason though, I was able to 'guix deploy' the configuration this
morning, using guix at commit 9f955a1cfd8f3b8fe066034878131f0e2518740b.
Odd!

Is someone still able to reproduce it?

Thank you,

Maxim

Message #17 received at 52411 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: Thiago Jung Bauermann <bauermann <at> kolabnow.com>, 52411 <at> debbugs.gnu.org,
 Jan Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: bug#52411: [core-updates-frozen] kmod-29 build fails,
 cross-compiled for i586-pc-gnu
Date: Fri, 17 Dec 2021 23:11:48 -0500

Hi Maxime,

Maxime Devos <maximedevos <at> telenet.be> writes:

> Maxime Devos schreef op vr 10-12-2021 om 17:48 [+0000]:
>> Maxim Cournoyer schreef op vr 10-12-2021 om 07:55 [-0500]:
>> > Hello Guix!
>> >
>> > I haven't been able to deploy core-updates-frozen on one of my
>> > machine,
>> > because it has the childhurd service which needs kmod-29 which
>> > fails
>> > building, like so:
>>
>> kmod is a linux-only thing, it's for doing things with linux kernel
>> modules, so the childhurd service shouldn't be using kmod. Perhaps
>> look
>> at why kmod is being built in the first place?
>
> I think I might have found the issue. The following commit made the
> existence/absence 'kmod' input of pciutils depend on %current-
> system/%current-target-system:
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=22ee7209797c023b95e22ced156df62cbff90184
>
> but it forgot to keep in mind that nix systems != triplets.
> Instead of %current-target-system, the 'current-target-nix-system'
> from ‘https://issues.guix.gnu.org/49672#3’ needs to be used
> (or the hurd-target? procedure).

Looking more closely, I don't see an issue with the current conditional
seleciting kmod?  nix systems != triplets, but in this case, the
conditional is seldom dealing with nix systems, it seems.  Am I missing
something?

*** time passes ... reads sources ***

Ah!  per (guix utils), it seems like %current-system is a nix system,
while %current-target-system is a GNU triplet.  Confusing!

So, I've now made the following change:

--8<---------------cut here---------------start------------->8---
     (native-inputs
      (list which pkg-config))
     (inputs
-     `(,@(if (member (or (%current-target-system)
-                         (%current-system))
-                     (package-supported-systems kmod))
+     `(,@(if (not (hurd-target?))
              `(("kmod" ,kmod))
              '())
--8<---------------cut here---------------end--------------->8---

I'll push it to version-1.4.0 as it causes a big rebuild.  I'm still
curious that this doesn't appear triggered on every guix deploy I've
made though...

Thanks!

Maxim

Message #20 received at 52411 <at> debbugs.gnu.org (full text, mbox):

From: Thiago Jung Bauermann <bauermann <at> kolabnow.com>
To: Maxime Devos <maximedevos <at> telenet.be>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 52411 <at> debbugs.gnu.org, Jan Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: bug#52411: [core-updates-frozen] kmod-29 build fails,
 cross-compiled for i586-pc-gnu
Date: Sat, 18 Dec 2021 01:42:53 -0300

Hello,

Em sábado, 18 de dezembro de 2021, às 01:11:48 -03, Maxim Cournoyer 
escreveu:
> > I think I might have found the issue. The following commit made the
> > existence/absence 'kmod' input of pciutils depend on %current-
> > system/%current-target-system:
> > 
> > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=22ee7209797c023b9
> > 5e22ced156df62cbff90184
> > 
> > but it forgot to keep in mind that nix systems != triplets.
> > Instead of %current-target-system, the 'current-target-nix-system'
> > from ‘https://issues.guix.gnu.org/49672#3’ needs to be used
> > (or the hurd-target? procedure).
> 
> Looking more closely, I don't see an issue with the current conditional
> seleciting kmod?  nix systems != triplets, but in this case, the
> conditional is seldom dealing with nix systems, it seems.  Am I missing
> something?
> 
> *** time passes ... reads sources ***
> 
> Ah!  per (guix utils), it seems like %current-system is a nix system,
> while %current-target-system is a GNU triplet.  Confusing!

Guix’s usage of GNU triplets in some places and nix systems in others is a 
footgun. IMHO we should choose one format and use it everywhere we can, 
converting to the other if necessary...

-- 
Thanks,
Thiago

Message #25 received at 52411-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Thiago Jung Bauermann <bauermann <at> kolabnow.com>
Cc: Maxime Devos <maximedevos <at> telenet.be>, 52411-done <at> debbugs.gnu.org,
 Jan Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: bug#52411: [core-updates-frozen] kmod-29 build fails,
 cross-compiled for i586-pc-gnu
Date: Mon, 17 Jan 2022 12:13:24 -0500

Hello,

Thiago Jung Bauermann <bauermann <at> kolabnow.com> writes:

> Hello,
>
> Em sábado, 18 de dezembro de 2021, às 01:11:48 -03, Maxim Cournoyer 
> escreveu:
>> > I think I might have found the issue. The following commit made the
>> > existence/absence 'kmod' input of pciutils depend on %current-
>> > system/%current-target-system:
>> > 
>> > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=22ee7209797c023b9
>> > 5e22ced156df62cbff90184
>> > 
>> > but it forgot to keep in mind that nix systems != triplets.
>> > Instead of %current-target-system, the 'current-target-nix-system'
>> > from ‘https://issues.guix.gnu.org/49672#3’ needs to be used
>> > (or the hurd-target? procedure).
>> 
>> Looking more closely, I don't see an issue with the current conditional
>> seleciting kmod?  nix systems != triplets, but in this case, the
>> conditional is seldom dealing with nix systems, it seems.  Am I missing
>> something?
>> 
>> *** time passes ... reads sources ***
>> 
>> Ah!  per (guix utils), it seems like %current-system is a nix system,
>> while %current-target-system is a GNU triplet.  Confusing!
>
> Guix’s usage of GNU triplets in some places and nix systems in others is a 
> footgun. IMHO we should choose one format and use it everywhere we can, 
> converting to the other if necessary...

Eh, indeed!  I see Maxime has written neat helpers that should mitigate
it to some extent (in guix build utils).  Thank you!

The bug at hand should now be fixed in master.

Closing.

Thanks!

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.