Upgrade bliss package to 0.73 with Debian patches; install header files in location expected by polymake

[mkoeppe]

New upstream archive: ​http://www.tcs.hut.fi/Software/bliss/bliss-0.73.zip (we have 0.72)

Upstream bliss does not have a proper build system (in particular no 'make install'). "spkg-install" installs header files with generic names such as "graph.hh" flat into $SAGE_LOCAL/include/

Debian has ​https://packages.debian.org/sid/math/bliss which autotoolizes the package and adjust the include file location. This matches where Polymake (#20892) expects the header files.

On ​https://github.com/mkoeppe/bliss in branch sage_package I have applied the Debian patches and a few more patches for Sage. The spkg-src script clones from there and builds a distribution. The result is available here:

tarball: ​https://github.com/mkoeppe/bliss/releases/download/sage_package%2F0.73%2Bdebian-1%2Bsage-2016-08-02/bliss-0.73.debian-1.sage-2016-08-02.tar.gz (rename to bliss-0.73+debian-1+sage-2016-08-02.tar.gz)

[mkoeppe]

New commits:

​3837a48

bliss: Use autotoolized package from Debian

[mkoeppe]

Needs review. Prerequisite for polymake (#20892).

[dimpase]

what are the new goodies? a shared library?

[mkoeppe]

Replying to dimpase:

what are the new goodies? a shared library?

A shared library, proper include files location, and as a result works as a prerequisite for polymake. New upstream version -- but upstream is silent about what has changed compared to 0.72.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​225755e

bliss: Add more info in SPKG.txt

[jdemeyer]

The usual way to ship packages in Sage is to start from the original unmodified sources and then apply patches (either at packaging time or at build time). Here, you are instead forking upstream for no clear reason.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​4b22211

bliss: Use upstream tarball and patches

[mkoeppe]

Replying to jdemeyer:

The usual way to ship packages in Sage is to start from the original unmodified sources and then apply patches (either at packaging time or at build time). Here, you are instead forking upstream for no clear reason.

OK, I've changed it to using upstream + a patch. Unfortunately our patches cannot be as elegant as Debian's because we cannot rely on the availability of autotools. So my patch has to ship the whole autogenerated build system.

[fbissey]

Learn to write a spkg-src file like for ecl ​https://github.com/sagemath/sage/blob/master/build/pkgs/ecl/spkg-src or glpk at #20710. It will require you to produce a new tarball and host it somewhere until the ticket is merged.

[dimpase]

yeah, spkg-src is important, as you don't want to become the only one in state to perform an update...

[mkoeppe]

Unfortunately this update causes some tests to fail with segfault.

age:             sage: g3 = polytopes.hypercube(3).vertex_graph(); g3
Graph on 8 vertices
sage:             sage: g3.automorphism_group().cardinality()
python(2197,0x7fff7b8f9000) malloc: *** error for object 0x1001d3fff: pointer being realloc'd was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
0x00007fff8b2cff06 in __pthread_kill () from /usr/lib/system/libsystem_kernel.dylib
(gdb) where
#0  0x00007fff8b2cff06 in __pthread_kill () from /usr/lib/system/libsystem_kernel.dylib
#1  0x00007fff92ea14ec in pthread_kill () from /usr/lib/system/libsystem_pthread.dylib
#2  0x00007fff8ec5c6e7 in abort () from /usr/lib/system/libsystem_c.dylib
#3  0x00007fff933d879d in realloc () from /usr/lib/system/libsystem_malloc.dylib
#4  0x0000000107284ddd in __pyx_f_4sage_3ext_6memory_sage_sig_realloc () from /Users/mkoeppe/cvs/sage/local/lib/python2.7/site-packages/sage/ext/memory.so
#5  0x0000000106afca01 in __gmpz_realloc () from /Users/mkoeppe/cvs/sage/local/lib/libgmp.16.dylib
#6  0x0000000106af8c0e in __gmpz_mul_si () from /Users/mkoeppe/cvs/sage/local/lib/libgmp.16.dylib
#7  0x00000001aefad6f0 in ?? () from /Users/mkoeppe/cvs/sage/local/lib/libbliss.2.dylib
#8  0x00000001aefaf43c in ?? () from /Users/mkoeppe/cvs/sage/local/lib/libbliss.2.dylib
#9  0x00000001aef96e13 in __pyx_pw_4sage_6graphs_5bliss_1automorphism_group(_object*, _object*, _object*) ()
   from /Users/mkoeppe/cvs/sage/local/lib/python2.7/site-packages/sage/graphs/bliss.so
#10 0x00000001000e92a4 in PyEval_EvalFrameEx () from /Users/mkoeppe/cvs/sage/local/lib/libpython2.7.dylib
#

I could use some help here.

[fbissey]

Well known problem. Disable gmp in bliss that's the culprit.

[mkoeppe]

Replying to fbissey:

Well known problem. Disable gmp in bliss that's the culprit.

Thanks!

[dimpase]

Why would bliss need gmp? Looks strange to me.

[fbissey]

It's a build option, ask the author.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​3111091	Merge tag '7.3.beta9' into t/20901/upgrade_bliss_package_to_0_73_with_debian_patches__install_header_files_in_location_expected_by_polymake
​1c398a3	Merge tag '7.3.rc0' into t/20901/upgrade_bliss_package_to_0_73_with_debian_patches__install_header_files_in_location_expected_by_polymake
​1d2707c	Use repackaged archive instead of huge patch

[mkoeppe]

Replying to fbissey:

Learn to write a spkg-src file

Thanks, done.

Ready for review.

[dimpase]

there is something funny with tarball name: if I do sage -i bliss it looks for bliss-0.73+debian-1+sage-2016-08-02.tar.gz, while wget with your URL gives bliss-0.73.debian-1.sage-2016-08-02.tar.gz.

OK, I renamed the tarball, and was able to run sage -i bliss, but the following make fails:

[sagelib-7.3.rc0] building 'sage.graphs.bliss' extension
[sagelib-7.3.rc0] Executing 1 command (using 1 thread)
[sagelib-7.3.rc0] [1/1] gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -fPIC -I/home/scratch/dimpase/sage/sage/local/include -I/home/scratch/dimpase/sage/sage/local/include/python2.7 -I/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/numpy/core/include -I/home/scratch/dimpase/sage/sage/src -I/home/scratch/dimpase/sage/sage/src/sage/ext -I/home/scratch/dimpase/sage/sage/src/build/cythonized -I/home/scratch/dimpase/sage/sage/src/build/cythonized/sage/ext -I/home/scratch/dimpase/sage/sage/local/include/python2.7 -c /home/scratch/dimpase/sage/sage/src/build/cythonized/sage/graphs/bliss.cpp -o build/temp.linux-x86_64-2.7/home/scratch/dimpase/sage/sage/src/build/cythonized/sage/graphs/bliss.o -fno-strict-aliasing
[sagelib-7.3.rc0] /home/scratch/dimpase/sage/sage/src/build/cythonized/sage/graphs/bliss.cpp:317:20: fatal error: graph.hh: No such file or directory
[sagelib-7.3.rc0] compilation terminated.
[sagelib-7.3.rc0] error: command 'gcc' failed with exit status 1

This is on Fedora23, Sage 7.3.rc0, with gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC).

[mkoeppe]

Replying to dimpase:

there is something funny with tarball name: if I do sage -i bliss it looks for bliss-0.73+debian-1+sage-2016-08-02.tar.gz, while wget with your URL gives bliss-0.73.debian-1.sage-2016-08-02.tar.gz.

It's a limitation of github, it renames + to .

OK, I renamed the tarball, and was able to run sage -i bliss, but the following make fails:

[sagelib-7.3.rc0] building 'sage.graphs.bliss' extension
[sagelib-7.3.rc0] Executing 1 command (using 1 thread)
[sagelib-7.3.rc0] [1/1] gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -fPIC -I/home/scratch/dimpase/sage/sage/local/include -I/home/scratch/dimpase/sage/sage/local/include/python2.7 -I/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/numpy/core/include -I/home/scratch/dimpase/sage/sage/src -I/home/scratch/dimpase/sage/sage/src/sage/ext -I/home/scratch/dimpase/sage/sage/src/build/cythonized -I/home/scratch/dimpase/sage/sage/src/build/cythonized/sage/ext -I/home/scratch/dimpase/sage/sage/local/include/python2.7 -c /home/scratch/dimpase/sage/sage/src/build/cythonized/sage/graphs/bliss.cpp -o build/temp.linux-x86_64-2.7/home/scratch/dimpase/sage/sage/src/build/cythonized/sage/graphs/bliss.o -fno-strict-aliasing
[sagelib-7.3.rc0] /home/scratch/dimpase/sage/sage/src/build/cythonized/sage/graphs/bliss.cpp:317:20: fatal error: graph.hh: No such file or directory
[sagelib-7.3.rc0] compilation terminated.
[sagelib-7.3.rc0] error: command 'gcc' failed with exit status 1

This is on Fedora23, Sage 7.3.rc0, with gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC).

Thanks for catching this. Fix coming shortly.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​c0c0427

Adjust to changed bliss header file locations

[mkoeppe]

Fixed.

[dimpase]

OK, this works. In order to keep the release manager happy, I suggest that you put the tarball somewhere where it can be wget'ed without renaming hassle...

[mkoeppe]

Is this a "positive_review"?

[dimpase]

I trust you are able to put the tarball somewhere where the name mangling does not happen. :-)

[mkoeppe]

Thanks, Dima.

Volker - does the upload location of the tarball work for you?

[chapoton]

some patchbots meet compilation problems:

[sagelib-7.4.beta1] /home/worker/sage-patchbot/src/build/cythonized/sage/graphs/bliss.cpp:317:26: fatal error: bliss/graph.hh: No such file or directory
[sagelib-7.4.beta1]  #include "bliss/graph.hh"
[sagelib-7.4.beta1]                           ^
[sagelib-7.4.beta1] compilation terminated.

[mkoeppe]

Well, the install location of this header file changed with this upgrade, so the patchbots will have to reinstall the package.

[jdemeyer]

I hope that #21288 will fix this.