[core-updates-frozen] kmod-29 build fails, cross-compiled for i586-pc-gnu

  • Done
  • quality assurance status badge
Details
3 participants
  • Thiago Jung Bauermann
  • Maxim Cournoyer
  • Maxime Devos
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
M
M
Maxim Cournoyer wrote on 10 Dec 2021 13:55
(name . bug-guix)(address . bug-guix@gnu.org)
87zgp8y5yx.fsf@gmail.com
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:

Toggle snippet (92 lines)
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

Thanks,

Maxim
M
M
Maxime Devos wrote on 10 Dec 2021 18:48
c59abe4993912bd7c2b5811953eae9aaf668b023.camel@telenet.be
Maxim Cournoyer schreef op vr 10-12-2021 om 07:55 [-0500]:
Toggle quote (7 lines)
> 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.
M
M
Maxime Devos wrote on 10 Dec 2021 18:55
00552a0a31e0f72c0d0fb3251466fb245dd7fe42.camel@telenet.be
Maxime Devos schreef op vr 10-12-2021 om 17:48 [+0000]:
Toggle quote (14 lines)
> 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:


but it forgot to keep in mind that nix systems != triplets.
Instead of %current-target-system, the 'current-target-nix-system'
(or the hurd-target? procedure).

Greetings,
Maxime.
M
M
Maxim Cournoyer wrote on 16 Dec 2021 20:02
(name . Maxime Devos)(address . maximedevos@telenet.be)
874k78cr0h.fsf@gmail.com
Hello Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

Toggle quote (26 lines)
> 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
M
M
Maxim Cournoyer wrote on 18 Dec 2021 05:11
(name . Maxime Devos)(address . maximedevos@telenet.be)
874k765z7f.fsf@gmail.com
Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

Toggle quote (26 lines)
> 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:

Toggle snippet (11 lines)
(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))
'())

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
T
T
Thiago Jung Bauermann wrote on 18 Dec 2021 05:42
2150305.bgRPiZMkaZ@popigai
Hello,

Em sábado, 18 de dezembro de 2021, às 01:11:48 -03, Maxim Cournoyer
escreveu:
Toggle quote (22 lines)
> > 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
M
M
Maxim Cournoyer wrote on 17 Jan 2022 18:13
(name . Thiago Jung Bauermann)(address . bauermann@kolabnow.com)
87tue2i8uj.fsf@gmail.com
Hello,

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

Toggle quote (30 lines)
> 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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 52411@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 52411
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch