[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: failing packages

From: Ludovic Courtès
Subject: Re: failing packages
Date: Tue, 06 Oct 2015 13:38:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Efraim Flashner <address@hidden> skribis:

> I've been looking at a bit at some of the failing packages to
> see what is causing them to fail. This list is far from complete, and is
> based on eval #107275 on hydra.

Thanks for looking into it!

> bwa:
> fails on non-x86_64 targets.
> This package is part of bioinformatics.scm so it may not be intended for
> non-x86_64 targets.

Pjotr, Ricardo: could you look into this and other bioinfo packages that
Efraim mentions?  Probably just a matter of adjusting

> gprolog:
> armhf: configure: error: unsupported architecture

This one is simple: remove ARM from ‘supported-platforms’.

> guile-ncurses:
> guix refresh -l guile-ncurses: no dependant packages
> The first failure was after ncurses was updated from 5.9 to 6.0. Currently I
> don't see ncurses 5.9 when I search in guix, so we're left with either
> waiting for guile-ncurses 2.7 to be released or reimplementing ncurses 5.9 if
> we want it now.

Yes, this should be reported to address@hidden (I could do it
if nobody beats me.)

> ibus-libpinyin:
> fails on all targets with the following error during the configure phase:
> warning: macro 'AM_GLIB_GNU_GETTEXT' not found in library
> autoreconf:
> running: 
> /gnu/store/7zdchnk3sl66wqf2a7pis7ahwf4f1dr1-autoconf-2.69/bin/autoconf
> --force error: possibly undefined macro: AM_GLIB_GNU_GETTEXT
> I leave it as an exercise to the audience to figure out what's missing :)

Weird.  That macro might be part of GLib.  Ricardo?

> I forget the exact reason I started writing this email, but I think the plan
> was to point out that some build failures on hydra should be not too hard to
> fix, and some just need some extra help on armhf/mips64el to compile
> correctly. If we think of hydra more as a build test system and only
> secondarily for providing binary substitues then checking the failures and
> trying to fix them becomes more obvious, and not just for when its something
> we wanted built.

Yes, we must fight bitrot.  As you note, sometimes it is difficult, but
often it can be fairly simple, so we should all try to address some of
the issues.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]