all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: "Carlos Sánchez de La Lama" <csanchezdll@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Test failure in util-linux
Date: Fri, 10 Apr 2015 15:09:54 +0200	[thread overview]
Message-ID: <87twwom8nx.fsf@gnu.org> (raw)
In-Reply-To: <7t4mop5pdg.fsf@gmail.com> ("Carlos Sánchez de La Lama"'s message of "Thu, 09 Apr 2015 16:48:43 +0200")

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’.

  reply	other threads:[~2015-04-10 13:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-09 14:48 Test failure in util-linux Carlos Sánchez de La Lama
2015-04-10 13:09 ` Ludovic Courtès [this message]
2015-04-13  7:30   ` Carlos Sánchez de La Lama
2015-04-14  9:59     ` Ludovic Courtès
2015-04-14 10:11       ` Carlos Sánchez de La Lama

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87twwom8nx.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=csanchezdll@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.