Test failure in util-linux

Test failure in util-linux

[Carlos Sánchez de La Lama]

Hi all,

I am trying to "guix system build" a smallish configuration (most
settings at their default values). I have installed guix on a freshly
new i686 gNewSense 3.1 (which uses kernel 2.6.32).

The system build fails during "check" phase of util-linux-2.25.2. I have
dug a little on and found the error comes from the fscanf in
util-linux-2.25.2/sys-utils/ipcutils.c:113
expecting 16 values in /proc/sysvipc/shm, while min having only 14. My
impression is util-linux checks have a dependency on the kernel being
fairly recent.

My points:

1) should check phase be disabled for util-linux depending on some
kernel version check?

2) I tried adding "#:tests? #f" to my own modified ~/guix/linux.scm
(copied from system-wide
/usr/local/share/guile/site/2.0/gnu/packages/linux.scm).
This allowed building with
"guix package -L $HOME/guix build util-linux"
but system build still fails during the tests (would seem guix system
ignores -L flag and takes system-wide recipe).

I am fairly new to Guix so might be missing some obvious point. Any
clues?

Thanks,

Carlos

-- 
'También hay ríos metafísicos, Horacio. Vos te vas a tirar a uno de esos ríos.'

Julio Cortázar, "Rayuela" (1963)

Re: Test failure in util-linux

[Ludovic Courtès]

Hello,

csanchezdll@gmail.com (Carlos Sánchez de La Lama) skribis:

> I am trying to "guix system build" a smallish configuration (most
> settings at their default values). I have installed guix on a freshly
> new i686 gNewSense 3.1 (which uses kernel 2.6.32).
>
> The system build fails during "check" phase of util-linux-2.25.2. I have
> dug a little on and found the error comes from the fscanf in
> util-linux-2.25.2/sys-utils/ipcutils.c:113
> expecting 16 values in /proc/sysvipc/shm, while min having only 14. My
> impression is util-linux checks have a dependency on the kernel being
> fairly recent.

Oh, OK.  We could work around it, but since that requires a full
rebuild, we’ll have to schedule it for the next core update cycle.

That said, 2.6.32 is really old, so we probably don’t want to invest too
much in that.

> My points:
>
> 1) should check phase be disabled for util-linux depending on some
> kernel version check?

Yes, we could patch this specific test or code snippet.

> 2) I tried adding "#:tests? #f" to my own modified ~/guix/linux.scm
> (copied from system-wide
> /usr/local/share/guile/site/2.0/gnu/packages/linux.scm).
> This allowed building with
> "guix package -L $HOME/guix build util-linux"
> but system build still fails during the tests (would seem guix system
> ignores -L flag and takes system-wide recipe).

Right.  “guix build” now sees your ‘util-linux’ package, but the whole
package DAG uses explicit references to the <package> objects, and so
yours is ignored.

You may be able to get around it by defining your own (gnu packages
linux) package.  The downside is that it would have to basically be a
copy of the original one with just #:tests? #f added.

If Guile had a #:use-module-next form (akin to #include_next in C), we
could do something better here.

I hope this makes sense!

Ludo’.

Re: Test failure in util-linux

[Carlos Sánchez de La Lama]

Hi,

>> The system build fails during "check" phase of util-linux-2.25.2.
>
> Oh, OK.  We could work around it, but since that requires a full
> rebuild, we’ll have to schedule it for the next core update cycle.
>
> That said, 2.6.32 is really old, so we probably don’t want to invest too
> much in that.

Ok, I will try to do it myself in a proper "clean" to get hands dirty
with package definitions. Then it can be included upstream if you find
it appropiate.

>> 2) I tried adding "#:tests? #f" to my own modified ~/guix/linux.scm
>> (copied from system-wide
>> /usr/local/share/guile/site/2.0/gnu/packages/linux.scm).
>> This allowed building with
>> "guix package -L $HOME/guix build util-linux"
>> but system build still fails during the tests (would seem guix system
>> ignores -L flag and takes system-wide recipe).
>
> Right.  “guix build” now sees your ‘util-linux’ package, but the whole
> package DAG uses explicit references to the <package> objects, and so
> yours is ignored.
>
> You may be able to get around it by defining your own (gnu packages
> linux) package.  The downside is that it would have to basically be a
> copy of the original one with just #:tests? #f added.

Hm, thats exactly what I had done (I had copied while linux.scm file,
which AFAIU is there (gnu packages linux) is defined, and modified the
util-linux package inside it just to ass #:tests? #f. And still guix
system does not see it.

I just worked it around by modifying base linux.scm directly. I will try
to replicate the problem again and provide more info.

Thanks for your help! :)

Carlos

-- 
'También hay ríos metafísicos, Horacio. Vos te vas a tirar a uno de esos ríos.'

Julio Cortázar, "Rayuela" (1963)

Re: Test failure in util-linux

[Ludovic Courtès]

csanchezdll@gmail.com (Carlos Sánchez de La Lama) skribis:

>>> The system build fails during "check" phase of util-linux-2.25.2.
>>
>> Oh, OK.  We could work around it, but since that requires a full
>> rebuild, we’ll have to schedule it for the next core update cycle.
>>
>> That said, 2.6.32 is really old, so we probably don’t want to invest too
>> much in that.
>
> Ok, I will try to do it myself in a proper "clean" to get hands dirty
> with package definitions. Then it can be included upstream if you find
> it appropiate.

Sounds good!

>>> 2) I tried adding "#:tests? #f" to my own modified ~/guix/linux.scm
>>> (copied from system-wide
>>> /usr/local/share/guile/site/2.0/gnu/packages/linux.scm).
>>> This allowed building with
>>> "guix package -L $HOME/guix build util-linux"
>>> but system build still fails during the tests (would seem guix system
>>> ignores -L flag and takes system-wide recipe).
>>
>> Right.  “guix build” now sees your ‘util-linux’ package, but the whole
>> package DAG uses explicit references to the <package> objects, and so
>> yours is ignored.
>>
>> You may be able to get around it by defining your own (gnu packages
>> linux) package.  The downside is that it would have to basically be a
>> copy of the original one with just #:tests? #f added.
>
> Hm, thats exactly what I had done (I had copied while linux.scm file,
> which AFAIU is there (gnu packages linux) is defined, and modified the
> util-linux package inside it just to ass #:tests? #f. And still guix
> system does not see it.

Was the module called (gnu packages linux)?  And was GUIX_PACKAGE_PATH
set when ‘guix system’ was invoked (if ‘sudo’ was used, it could have
unset it, for instance)?

Thanks,
Ludo’.

Re: Test failure in util-linux

[Carlos Sánchez de La Lama]

>>>> 2) I tried adding "#:tests? #f" to my own modified ~/guix/linux.scm
>>>> (copied from system-wide
>>>> /usr/local/share/guile/site/2.0/gnu/packages/linux.scm).
>>>> This allowed building with
>>>> "guix package -L $HOME/guix build util-linux"
>>>> but system build still fails during the tests (would seem guix system
>>>> ignores -L flag and takes system-wide recipe).
>>>
>>> Right.  “guix build” now sees your ‘util-linux’ package, but the whole
>>> package DAG uses explicit references to the <package> objects, and so
>>> yours is ignored.
>>>
>>> You may be able to get around it by defining your own (gnu packages
>>> linux) package.  The downside is that it would have to basically be a
>>> copy of the original one with just #:tests? #f added.
>>
>> Hm, thats exactly what I had done (I had copied while linux.scm file,
>> which AFAIU is there (gnu packages linux) is defined, and modified the
>> util-linux package inside it just to ass #:tests? #f. And still guix
>> system does not see it.
>
> Was the module called (gnu packages linux)?  And was GUIX_PACKAGE_PATH
> set when ‘guix system’ was invoked (if ‘sudo’ was used, it could have
> unset it, for instance)?

The package was called (gnu packages linux) as original the linux.scm
file itself was copied in my ~/guix directory., and only #:tests line
added. So the name (and everything else) was the same.

I have a slightly different set-up working so I can not recheck right now,
but I am sure I was not using GUIX_PACKAGE_PATH. I was using the -L
parameter, in both "guix package" (where it worked) and "guix system"
(where it didn't). I tried in both cases passing it directly in the
command line and using the GUIX_BUILD_OPIONS environment variable. That
is what my original guess was that "guix system" did not honor that
parameter.

I had missed GUIX_PACKAGE_PATH in the manual, BTW. Much easier that way.

BR

Carlos

-- 
'[...] es muy distinto lo que una persona quiere, a lo que una persona necesita,
a lo que una persona dice que quiere.'

Javier Castillo, "El día que se perdió la cordura" (2014)