failing packages

failing packages

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]

I've been looking at hydra.gnu.org 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.


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.

chicken:
guix refresh -l chicken: no dependant packages.
Has not built successfully since early May.
x86_64: http://hydra.gnu.org/build/701776/nixlog/1 (~1900 lines) runtime tests
timed out
armhf: http://hydra.gnu.org/build/701673/nixlog/1 (~4300 lines) tests pass
(including runtime tests) until ports test
Error: (line 294) invalid escape-sequence '\x o' => Embedded NUL bytes in
filenames are rejected.
mips64el: http://hydra.gnu.org/build/699177/nixlog/1 same as arm
i686: http://hydra.gnu.org/build/698575/nixlog/1 same as x86_64

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

eigen:
fails on non-x86_64 targets.
As per their website http://eigen.tuxfamily.org/index.php?title=Main_Page
this package may need special attention for compile flags for non-x86 targets.

fastcap:
fails on all hardware targets.
has not built successfully since August 1st. 

gnurl:
fails on all targets.
test 46 fails. updating to 7.40.0 also fails at test 46. 7.43.0 is missing
install.sh, so it doesn't build. currently waiting on 7.44.0 from gnunet.

gprolog:
armhf: configure: error: unsupported architecture

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.

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

opam:
fails on all target with the following error during the configure phase:
configure: error: You must install the Camlp4 pre-processor. On some
operating systems, these are separate packages from the main OCaml compiler,
such as camlp4-extra on Debian.

python-urwid:
fails on all targets, during the check phase.


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.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: failing packages

[Ludovic Courtès]

Efraim Flashner <efraim@flashner.co.il> skribis:

> I've been looking at hydra.gnu.org 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
‘supported-platforms’.

> 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 bug-guile-ncurses@gnu.org (I could do it
if nobody beats me.)

> ibus-libpinyin:
> fails on all targets with the following error during the configure phase:
> configure.ac:130: warning: macro 'AM_GLIB_GNU_GETTEXT' not found in library
> autoreconf:
> running: /gnu/store/7zdchnk3sl66wqf2a7pis7ahwf4f1dr1-autoconf-2.69/bin/autoconf
> --force configure.ac:130: 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.

Thanks,
Ludo’.

Re: failing packages

[Pjotr Prins]

On Tue, Oct 06, 2015 at 01:38:32PM +0200, Ludovic Courtès wrote:
> > 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
> ‘supported-platforms’.

Sure. I am actually amazed that some do work :). It would be really
nice if we could view passing and failing builds on hydra in the
package list. It is on my TODO list.

Pj.

-- 

Re: failing packages

[Ricardo Wurmus]

Efraim Flashner <efraim@flashner.co.il> writes:

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

Yes, I think it makes sense to just declare x86_64 as the only supported
system.  Unfortunately, most bioinfo packages pretend that x86_64 is the
only system.

> eigen:
> fails on non-x86_64 targets.
> As per their website http://eigen.tuxfamily.org/index.php?title=Main_Page
> this package may need special attention for compile flags for non-x86 targets.

This has bit me too as it makes it impossible to use Guitarix on i686.

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

I have a fix for this locally which I will submit/push soon.  This broke
after a change to the gtk-or-glib-build-system in core-updates and I
haven’t yet found the time to polish the patch for submission.

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

Agreed!

I would like to note that I find it quite hard to use the hydra
interface as it doesn’t seem to support filtering.  (Do we have an Emacs
mode for displaying hydra tables?)  Currently it’s a bit discouraging to
work go through the list of failures without a convenient way to
restrict the list to certain architectures or failure type.

~~ Ricardo

Re: failing packages

[Andreas Enge]

On Tue, Oct 06, 2015 at 02:25:44PM +0200, Ricardo Wurmus wrote:
> I would like to note that I find it quite hard to use the hydra
> interface as it doesn’t seem to support filtering.  (Do we have an Emacs
> mode for displaying hydra tables?)  Currently it’s a bit discouraging to
> work go through the list of failures without a convenient way to
> restrict the list to certain architectures or failure type.

I would say that the aim is to have such a short list of failures that there
is no need for filtering :-)

At some point in time, I thought that zero failing packages would be a good,
if unrealistic target... But maybe just a list that holds on one page without
the need for clicking on "... more builds omitted" would be good to have and
actually achievable.

Andreas

Re: failing packages

[Alex Kost]

Ricardo Wurmus (2015-10-06 15:25 +0300) wrote:

> I would like to note that I find it quite hard to use the hydra
> interface as it doesn’t seem to support filtering.  (Do we have an Emacs
> mode for displaying hydra tables?)  Currently it’s a bit discouraging to
> work go through the list of failures without a convenient way to
> restrict the list to certain architectures or failure type.

After reading
<http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00442.html> I
added "Emacs UI for Hydra" to my TODO.  So I hope it will appear some
day.

-- 
Alex

Re: failing packages

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Ricardo Wurmus (2015-10-06 15:25 +0300) wrote:
>
>> I would like to note that I find it quite hard to use the hydra
>> interface as it doesn’t seem to support filtering.  (Do we have an Emacs
>> mode for displaying hydra tables?)  Currently it’s a bit discouraging to
>> work go through the list of failures without a convenient way to
>> restrict the list to certain architectures or failure type.
>
> After reading
> <http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00442.html> I
> added "Emacs UI for Hydra" to my TODO.  So I hope it will appear some
> day.

\o/

Ludo’.

Re: failing packages

[Ben Woodcroft]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On 06/10/15 21:52, Ben Woodcroft wrote:
> On 06/10/15 19:48, Efraim Flashner wrote:
>> diamond:
>> fails on non-x86_64 targets.
>> This package is part of bioinformatics.scm so it may not be intended for
>> non-x86_64 targets.
> I imagine it is safe to say so for diamond, but I've asked the authors 
> just in case.
> https://github.com/bbuchfink/diamond/issues/18
The author agrees. Patch attached.

ben

[-- Attachment #2: 0001-gnu-diamond-Restrict-supported-systems-to-x86_64-lin.patch --]
[-- Type: text/x-patch, Size: 1157 bytes --]

From 9ec17df08fef730c415935e6dabf1a161511382c Mon Sep 17 00:00:00 2001
From: Ben Woodcroft <donttrustben@gmail.com>
Date: Wed, 14 Oct 2015 20:21:43 +1000
Subject: [PATCH] gnu: diamond: Restrict supported systems to x86_64-linux.

* gnu/packages/bioinformatics.scm (diamond) [supported-systems]: Restrict to
  x86_64-linux.
---
 gnu/packages/bioinformatics.scm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gnu/packages/bioinformatics.scm b/gnu/packages/bioinformatics.scm
index 4b7f76b..74a738e 100644
--- a/gnu/packages/bioinformatics.scm
+++ b/gnu/packages/bioinformatics.scm
@@ -970,6 +970,9 @@ translated DNA query sequences against a protein reference database (BLASTP
 and BLASTX alignment mode).  The speedup over BLAST is up to 20,000 on short
 reads at a typical sensitivity of 90-99% relative to BLAST depending on the
 data and settings.")
+    ;; diamond fails to build on other platforms
+    ;; https://github.com/bbuchfink/diamond/issues/18
+    (supported-systems '("x86_64-linux"))
     (license (license:non-copyleft "file://src/COPYING"
                                    "See src/COPYING in the distribution."))))
 
-- 
2.4.3

Re: failing packages

[Andreas Enge]

On Wed, Oct 14, 2015 at 08:41:13PM +1000, Ben Woodcroft wrote:
> The author agrees. Patch attached.

Looks good, please push, and thanks for enquiring!

Andreas

Re: failing packages

[Ben Woodcroft]

On 14/10/15 23:29, Andreas Enge wrote:
> On Wed, Oct 14, 2015 at 08:41:13PM +1000, Ben Woodcroft wrote:
>> The author agrees. Patch attached.
> Looks good, please push, and thanks for enquiring!
Cool. Only, would you mind pushing please? I don't have rights.

Re: failing packages

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Wed, 14 Oct 2015 23:37:56 +1000
Ben Woodcroft <b.woodcroft@uq.edu.au> wrote:

> 
> On 14/10/15 23:29, Andreas Enge wrote:
> > On Wed, Oct 14, 2015 at 08:41:13PM +1000, Ben Woodcroft wrote:
> >> The author agrees. Patch attached.
> > Looks good, please push, and thanks for enquiring!
> Cool. Only, would you mind pushing please? I don't have rights.

pushed. thanks for doing the legwork Ben :)

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: failing packages

[Andreas Enge]

On Tue, Oct 06, 2015 at 12:48:12PM +0300, Efraim Flashner wrote:
> chicken:
> guix refresh -l chicken: no dependant packages.
> Has not built successfully since early May.
> x86_64: http://hydra.gnu.org/build/701776/nixlog/1 (~1900 lines) runtime tests
> timed out
> armhf: http://hydra.gnu.org/build/701673/nixlog/1 (~4300 lines) tests pass
> (including runtime tests) until ports test
> Error: (line 294) invalid escape-sequence '\x o' => Embedded NUL bytes in
> filenames are rejected.
> mips64el: http://hydra.gnu.org/build/699177/nixlog/1 same as arm
> i686: http://hydra.gnu.org/build/698575/nixlog/1 same as x86_64

Should we simply drop this? Or would someone like to try an update to the
most recent version 4.10.0?

> fastcap:
> fails on all hardware targets.
> has not built successfully since August 1st. 

Does the software really date from 1992 as the filename suggests?!
Here only the documentation does not build; maybe the fix-doc phase should
be modified? Is anybody interested in the package, or should we drop it?

> gnurl:
> fails on all targets.
> test 46 fails. updating to 7.40.0 also fails at test 46. 7.43.0 is missing
> install.sh, so it doesn't build. currently waiting on 7.44.0 from gnunet.

I reported this already before your message in a private e-mail to upstream,
and will try to report it in some bug tracker.

Andreas

Re: failing packages

[Andreas Enge]

How about non-sequencer?
   http://hydra.gnu.org/build/725259/nixlog/1/tail-reload

It fails with messages
g++: error: unrecognized command line option ‘-msse2’
g++: error: unrecognized command line option ‘-mfpmath=sse’
g++: error: unrecognized command line option ‘-msse2’
g++: error: unrecognized command line option ‘-mfpmath=sse’
g++: error: unrecognized command line option ‘-msse2’
g++: error: unrecognized command line option ‘-mfpmath=sse’
g++: error: unrecognized command line option ‘-msse2’
g++: error: unrecognized command line option ‘-mfpmath=sse’

Shall we disable everything but x86_64?

Andreas
                                                                            
~              

Re: failing packages

[Ricardo Wurmus]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]


Andreas Enge <andreas@enge.fr> writes:

> How about non-sequencer?
>    http://hydra.gnu.org/build/725259/nixlog/1/tail-reload
>
> It fails with messages
> g++: error: unrecognized command line option ‘-msse2’
> g++: error: unrecognized command line option ‘-mfpmath=sse’
> g++: error: unrecognized command line option ‘-msse2’
> g++: error: unrecognized command line option ‘-mfpmath=sse’
> g++: error: unrecognized command line option ‘-msse2’
> g++: error: unrecognized command line option ‘-mfpmath=sse’
> g++: error: unrecognized command line option ‘-msse2’
> g++: error: unrecognized command line option ‘-mfpmath=sse’
>
> Shall we disable everything but x86_64?

No.  How about the attached patch?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-non-sequencer-Disable-SSE-when-not-building-on-x.patch --]
[-- Type: text/x-patch, Size: 1196 bytes --]

From dfde69d64fa16b653d87283930cddb2082e8fa49 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus <rekado@elephly.net>
Date: Sat, 17 Oct 2015 10:10:07 +0200
Subject: [PATCH] gnu: non-sequencer: Disable SSE when not building on x86_64.

* gnu/packages/music.scm (non-sequencer)[arguments]: Add "--disable-sse"
  flag when not building on x86_64.
---
 gnu/packages/music.scm | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
index fe8e6f1..a72f754 100644
--- a/gnu/packages/music.scm
+++ b/gnu/packages/music.scm
@@ -274,7 +274,13 @@ Guile.")
       (build-system waf-build-system)
       (arguments
        `(#:tests? #f ;no "check" target
-         #:configure-flags '("--project=sequencer")
+         #:configure-flags
+         (list "--project=sequencer"
+               ;; Disable the use of SSE unless on x86_64.
+               ,@(if (not (string-prefix? "x86_64" (or (%current-target-system)
+                                                       (%current-system))))
+                     '("--disable-sse")
+                     '()))
          #:python ,python-2))
       (inputs
        `(("jack" ,jack-1)
-- 
2.5.0

Re: failing packages

[Pjotr Prins]

Anything bioinformatics is not really used on non Intel architectures.
It may change later but, yes, defaulting to x86_64 is the quick option
for failing packages. I prefer we change them that way.

Pj.

On Fri, Oct 16, 2015 at 11:02:06PM +0200, Andreas Enge wrote:
> How about non-sequencer?
>    http://hydra.gnu.org/build/725259/nixlog/1/tail-reload
> 
> It fails with messages
> g++: error: unrecognized command line option ‘-msse2’
> g++: error: unrecognized command line option ‘-mfpmath=sse’
> g++: error: unrecognized command line option ‘-msse2’
> g++: error: unrecognized command line option ‘-mfpmath=sse’
> g++: error: unrecognized command line option ‘-msse2’
> g++: error: unrecognized command line option ‘-mfpmath=sse’
> g++: error: unrecognized command line option ‘-msse2’
> g++: error: unrecognized command line option ‘-mfpmath=sse’
> 
> Shall we disable everything but x86_64?
> 
> Andreas
>                                                                             
> ~              
> 

-- 

Re: failing packages

[Federico Beffa]

Andreas Enge <andreas@enge.fr> writes:

> On Tue, Oct 06, 2015 at 12:48:12PM +0300, Efraim Flashner wrote:
>> chicken:
>> guix refresh -l chicken: no dependant packages.
>> Has not built successfully since early May.
>> x86_64: http://hydra.gnu.org/build/701776/nixlog/1 (~1900 lines) runtime tests
>> timed out
>> armhf: http://hydra.gnu.org/build/701673/nixlog/1 (~4300 lines) tests pass
>> (including runtime tests) until ports test
>> Error: (line 294) invalid escape-sequence '\x o' => Embedded NUL bytes in
>> filenames are rejected.
>> mips64el: http://hydra.gnu.org/build/699177/nixlog/1 same as arm
>> i686: http://hydra.gnu.org/build/698575/nixlog/1 same as x86_64
>
> Should we simply drop this? Or would someone like to try an update to the
> most recent version 4.10.0?
>
>> fastcap:
>> fails on all hardware targets.
>> has not built successfully since August 1st.
>
> Does the software really date from 1992 as the filename suggests?!
> Here only the documentation does not build; maybe the fix-doc phase should
> be modified? Is anybody interested in the package, or should we drop it?

Yes, the software dates 1992 and works great. Electromagnetism has not
changed since then.

Why would you want to drop it? The documentation was broken by the
last texlive update, it didn't break by itself. It's just a matter to
fix some LaTeX macro.

Dropping the documentation is a bad idea, because without it, you will
not know how to use this complex piece of software.

I will look into fixing the documentation of this package.

Regards,
Fede

Re: failing packages

[Federico Beffa]

The problem appears to be with TeXLive 2015 and its 'dvips' command
being unable to handle some .ps files:
https://www.tug.org/pipermail/tex-live/2015-June/037013.html

Could you please look into this?

Thanks,
Fede

On Sat, Oct 17, 2015 at 1:14 PM, Federico Beffa <beffa@ieee.org> wrote:
> Andreas Enge <andreas@enge.fr> writes:
>
>> On Tue, Oct 06, 2015 at 12:48:12PM +0300, Efraim Flashner wrote:
>>> chicken:
>>> guix refresh -l chicken: no dependant packages.
>>> Has not built successfully since early May.
>>> x86_64: http://hydra.gnu.org/build/701776/nixlog/1 (~1900 lines) runtime tests
>>> timed out
>>> armhf: http://hydra.gnu.org/build/701673/nixlog/1 (~4300 lines) tests pass
>>> (including runtime tests) until ports test
>>> Error: (line 294) invalid escape-sequence '\x o' => Embedded NUL bytes in
>>> filenames are rejected.
>>> mips64el: http://hydra.gnu.org/build/699177/nixlog/1 same as arm
>>> i686: http://hydra.gnu.org/build/698575/nixlog/1 same as x86_64
>>
>> Should we simply drop this? Or would someone like to try an update to the
>> most recent version 4.10.0?
>>
>>> fastcap:
>>> fails on all hardware targets.
>>> has not built successfully since August 1st.
>>
>> Does the software really date from 1992 as the filename suggests?!
>> Here only the documentation does not build; maybe the fix-doc phase should
>> be modified? Is anybody interested in the package, or should we drop it?
>
> Yes, the software dates 1992 and works great. Electromagnetism has not
> changed since then.
>
> Why would you want to drop it? The documentation was broken by the
> last texlive update, it didn't break by itself. It's just a matter to
> fix some LaTeX macro.
>
> Dropping the documentation is a bad idea, because without it, you will
> not know how to use this complex piece of software.
>
> I will look into fixing the documentation of this package.
>
> Regards,
> Fede

Re: failing packages

[Federico Beffa]

Looking further: A macro was removed from TeXLive 2015 because of a
license problem.

I've pushed a fix to generate the fastcap documentation using a different macro.

Regards,
Fede

On Sat, Oct 17, 2015 at 5:20 PM, Federico Beffa <beffa@ieee.org> wrote:
> The problem appears to be with TeXLive 2015 and its 'dvips' command
> being unable to handle some .ps files:
> https://www.tug.org/pipermail/tex-live/2015-June/037013.html
>
> Could you please look into this?
>
> Thanks,
> Fede
>
> On Sat, Oct 17, 2015 at 1:14 PM, Federico Beffa <beffa@ieee.org> wrote:
>> Andreas Enge <andreas@enge.fr> writes:
>>
>>> On Tue, Oct 06, 2015 at 12:48:12PM +0300, Efraim Flashner wrote:
>>>> chicken:
>>>> guix refresh -l chicken: no dependant packages.
>>>> Has not built successfully since early May.
>>>> x86_64: http://hydra.gnu.org/build/701776/nixlog/1 (~1900 lines) runtime tests
>>>> timed out
>>>> armhf: http://hydra.gnu.org/build/701673/nixlog/1 (~4300 lines) tests pass
>>>> (including runtime tests) until ports test
>>>> Error: (line 294) invalid escape-sequence '\x o' => Embedded NUL bytes in
>>>> filenames are rejected.
>>>> mips64el: http://hydra.gnu.org/build/699177/nixlog/1 same as arm
>>>> i686: http://hydra.gnu.org/build/698575/nixlog/1 same as x86_64
>>>
>>> Should we simply drop this? Or would someone like to try an update to the
>>> most recent version 4.10.0?
>>>
>>>> fastcap:
>>>> fails on all hardware targets.
>>>> has not built successfully since August 1st.
>>>
>>> Does the software really date from 1992 as the filename suggests?!
>>> Here only the documentation does not build; maybe the fix-doc phase should
>>> be modified? Is anybody interested in the package, or should we drop it?
>>
>> Yes, the software dates 1992 and works great. Electromagnetism has not
>> changed since then.
>>
>> Why would you want to drop it? The documentation was broken by the
>> last texlive update, it didn't break by itself. It's just a matter to
>> fix some LaTeX macro.
>>
>> Dropping the documentation is a bad idea, because without it, you will
>> not know how to use this complex piece of software.
>>
>> I will look into fixing the documentation of this package.
>>
>> Regards,
>> Fede

Re: failing packages

[Andreas Enge]

On Sat, Oct 17, 2015 at 01:14:22PM +0200, Federico Beffa wrote:
> Yes, the software dates 1992 and works great. Electromagnetism has not
> changed since then.

Well, maybe the physics have not, but compilers and language standards have;
it is rare to see very old code compiling without problems today.
(Pure and proper C code usually does, but this is no contradiction to my
previous sentence.)

> Why would you want to drop it?

As long as there is interest in the package, and someone with interest
volunteers to fix it, then I do not want to drop anything!

On Sat, Oct 17, 2015 at 05:20:07PM +0200, Federico Beffa wrote:
> The problem appears to be with TeXLive 2015 and its 'dvips' command
> being unable to handle some .ps files:
> https://www.tug.org/pipermail/tex-live/2015-June/037013.html

This looks really nasty - so the bitrot problem does not concern the code,
but its documentation! It appears that there is some non-free tex file
that was only discovered as such recently and consequently taken out from
texlive.

Actually, such a non-free file is distrubuted with the fastcap source:
   doc/psfig sty
has the following license:
% Permission is granted for use and non-profit distribution of psfig/tex
% providing that this notice be clearly maintained, but the right to
% distribute any portion of psfig/tex for profit or as part of any commercial
% product is specifically reserved for the author.

The offending macro "startTexFig" is used there, and it was probably defined
in some other non-free file of the psfig universe that was removed from
texlive.

So clearly we need to remove psfig.sty from the tarball, and then all
inclusions of ps figures of the form
   ug-run.tex:\psfig{figure=\figuredir/cubes.eps}
from the .tex files. Potentially replacing "\psfig" by "\includegraphics"
is enough, more likely, some other parameters will have to be adapted as well.

There is one more dubious file in the doc directory: ieee.sty, which comes
without any license. There is a latex class ieetran on CTAN:
   http://www.ctan.org/pkg/ieeetran
and another one ieeeconf.

Do you have some (la-)tex experience and could have a look?
Unfortunately the software does not seem to be in debian, from where we
might have taken a patch.

Andreas

Re: failing packages

[Andreas Enge]

On Sat, Oct 17, 2015 at 10:11:52AM +0200, Ricardo Wurmus wrote:
> No.  How about the attached patch?

Much better, of course, thanks! Maybe upstream could be convinced to include
some detection of the availability of sse.

Andreas

Re: failing packages

[Andreas Enge]

On Sat, Oct 17, 2015 at 06:21:24PM +0200, Andreas Enge wrote:
> Do you have some (la-)tex experience and could have a look?

Apparently you do and could!

> So clearly we need to remove psfig.sty from the tarball

This is still valid, we need a snippet...

> There is one more dubious file in the doc directory: ieee.sty, which comes
> without any license.

...whereas this may simply be a custom made file by the fastcap authors
and as such not pose a problem; I did not find it anywhere on the web.

Andreas

Re: failing packages

[Federico Beffa]

On Sat, Oct 17, 2015 at 6:33 PM, Andreas Enge <andreas@enge.fr> wrote:
> On Sat, Oct 17, 2015 at 06:21:24PM +0200, Andreas Enge wrote:
>> Do you have some (la-)tex experience and could have a look?
>
> Apparently you do and could!
>
>> So clearly we need to remove psfig.sty from the tarball
>
> This is still valid, we need a snippet...

Done.

>
>> There is one more dubious file in the doc directory: ieee.sty, which comes
>> without any license.
>
> ...whereas this may simply be a custom made file by the fastcap authors
> and as such not pose a problem; I did not find it anywhere on the web.

This is part of the ieeetran LaTeX package.

Regards,
Fede

Re: failing packages

[Andreas Enge]

On Sat, Oct 17, 2015 at 06:45:46PM +0200, Federico Beffa wrote:
> This is part of the ieeetran LaTeX package.

I do not think so; the current file is called IEEEtran.cls, and according to
   http://www.michaelshell.org/tex/ieeetran/
the first version dates from 1993 (so after fastcap) and was called
IEEEtran.sty.

But well, it looks like we can keep things as they are now, thanks for your
commits!

Andreas

Re: failing packages

[Federico Beffa]

On Sat, Oct 17, 2015 at 6:53 PM, Andreas Enge <andreas@enge.fr> wrote:
> On Sat, Oct 17, 2015 at 06:45:46PM +0200, Federico Beffa wrote:
>> This is part of the ieeetran LaTeX package.
>
> I do not think so; the current file is called IEEEtran.cls, and according to
>    http://www.michaelshell.org/tex/ieeetran/
> the first version dates from 1993 (so after fastcap) and was called
> IEEEtran.sty.

You're right, it's a custom file. I've been fooled by the name.

Regards,
Fede

Re: failing packages

[Andreas Enge]

On Sat, Oct 17, 2015 at 12:52:53PM +0200, Pjotr Prins wrote:
> Anything bioinformatics is not really used on non Intel architectures.
> It may change later but, yes, defaulting to x86_64 is the quick option
> for failing packages. I prefer we change them that way.

How about ngs-sdk, which fails on armhf with the slightly surprising error
message:
Configuring NGS-SDK package
checking system type... Linux
checking machine architecture... armv7l
configure: error: unsupported architecture 'Linux'
(and similarly on mips).

Is it okay to take out mips and arm from the supported architectures?

Andreas

Re: failing packages

[Ricardo Wurmus]

Andreas Enge <andreas@enge.fr> writes:

> On Sat, Oct 17, 2015 at 12:52:53PM +0200, Pjotr Prins wrote:
>> Anything bioinformatics is not really used on non Intel architectures.
>> It may change later but, yes, defaulting to x86_64 is the quick option
>> for failing packages. I prefer we change them that way.
>
> How about ngs-sdk, which fails on armhf with the slightly surprising error
> message:
> Configuring NGS-SDK package
> checking system type... Linux
> checking machine architecture... armv7l
> configure: error: unsupported architecture 'Linux'
> (and similarly on mips).
>
> Is it okay to take out mips and arm from the supported architectures?

NGS-SDK has a custom build system with custom checks.  I don’t know on
what architectures it is supposed to run.  Building it on x86_64 was
quite hard because I had to go around the many invalid assumptions.

It’s a bioinfo library, so I don’t think MIPS (or ARM) is officially
supported, but personally I would like to resist the urge to declare all
bioinfo tools unsupported on non-Intel.  (Unfortunately, I don’t have
time to check if NGS-SDK could be build on other platforms at the
moment.)

~~ Ricardo

Re: failing packages

[Andreas Enge]

There is a new version upstream (1.2.2); is it safe to try an update,
or do the bioinformaticians need to keep the old version?

Andreas

Re: failing packages

[Andreas Enge]

On Sat, Oct 17, 2015 at 10:04:34PM +0200, Ricardo Wurmus wrote:
> It’s a bioinfo library, so I don’t think MIPS (or ARM) is officially
> supported, but personally I would like to resist the urge to declare all
> bioinfo tools unsupported on non-Intel.

In this case, they are:
print "checking machine architecture... " unless ($AUTORUN);
println $MARCH unless ($AUTORUN);
unless ($MARCH =~ /x86_64/i || $MARCH =~ /i?86/i) {
    println "configure: error: unsupported architecture '$OSTYPE'";
    exit 1;
}

in ngs-sdk/setup/konfigure.perl. I will add a supported-system statement.

Andreas

Re: failing packages

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

On Sat, 17 Oct 2015 21:56:05 +0200
Andreas Enge <andreas@enge.fr> wrote:

> On Sat, Oct 17, 2015 at 12:52:53PM +0200, Pjotr Prins wrote:
> > Anything bioinformatics is not really used on non Intel architectures.
> > It may change later but, yes, defaulting to x86_64 is the quick option
> > for failing packages. I prefer we change them that way.  
> 
> How about ngs-sdk, which fails on armhf with the slightly surprising error
> message:
> Configuring NGS-SDK package
> checking system type... Linux
> checking machine architecture... armv7l
> configure: error: unsupported architecture 'Linux'
> (and similarly on mips).
 
I checked the source over at github
(https://github.com/ncbi/ngs/blob/master/ngs-sdk/setup/konfigure.perl), and in
the configure script is (at line 205):

print "checking machine architecture... " unless ($AUTORUN);
println $MARCH unless ($AUTORUN);
unless ($MARCH =~ /x86_64/i || $MARCH =~ /i?86/i) {
    println "configure: error: unsupported architecture '$OSTYPE'";
    exit 1;
}

and then at 292:

print "checking for supported architecture... " unless ($AUTORUN);

my $BITS;

if ($MARCH =~ /x86_64/i) {
    $BITS = 64;
} elsif ($MARCH eq 'fat86') {
    $BITS = '32_64';
} elsif ($MARCH =~ /i?86/i) {
    $BITS = 32;
} else {
    die "unrecognized Architecture '$ARCH'";
}
println "$MARCH ($BITS bits) is supported" unless ($AUTORUN);

so it looks like x86_64 and i686 are pretty much hardcoded in.

> Is it okay to take out mips and arm from the supported architectures?

I'm curious if they would build with modifications to the configure files,
but I don't have a machine to test it on.

> Andreas
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: failing packages

[Andreas Enge]

As far as I can tell, we can disable hisat on arm and mips. There is a
file sse_util.h that seems to be included unconditionally.

Andreas

Re: failing packages

[Ricardo Wurmus]

Andreas Enge <andreas@enge.fr> writes:

> There is a new version upstream (1.2.2); is it safe to try an update,
> or do the bioinformaticians need to keep the old version?

We could update.  If someone needs an older version they could easily
create a variant, I suppose.

(I cannot make the update myself as I’ll be mostly offline for the next
couple of days.)

~~ Ricardo