Change known-broken new-style packages to "experimental"

[jdemeyer]

Packages which are known to fail optional doctests or which do not install on all supported platforms should be "experimental", not "optional".

Packages moved to experimental:

• 4ti2: doesn't pass optional doctests
• autotools: breaks installation of Singular if xz is not installed
• compilerwrapper: totally breaks building Sage on OS X
• fricas: doesn't pass optional doctests
• gap_packages: doesn't pass optional doctests
• latte_int: doesn't pass optional doctests
• topcom: doesn't pass doctests, even breaks non-optional tests
• valgrind: doesn't build on OS X 10.10

Other problematic packages, not changed here:

• arb: doesn't build on OS X: fixed by Upgrade arb to 2.6.0 #18560
• dot2tex: see Non-functioning dot2tex breaks poset creation in an unclear way #18124
• gdb: does not work properly on OS X: live with it
• tides: see Fix build of tides package #18573

Component: packages: experimental

Author: Jeroen Demeyer

Branch/Commit: 245ab15

Reviewer: Nathann Cohen

Issue created by migration from https://trac.sagemath.org/ticket/18563

[jdemeyer]

Branch: u/jdemeyer/change_known_broken_packages_to__experimental_

[nathanncohen]

Commit: ef11087

[nathanncohen]

New commits:

ef11087

Change known-broken packages to "experimental"

[nathanncohen]

comment:3

needs review ?

[jdemeyer]

Replying to @jdemeyer:

NOTE replicate the changes on Sage's mirrors (ask Harald) when this patch is merged

I plan to consider only new-style packages in this ticket, is the mirror thing still relevant?

[nathanncohen]

comment:5

I plan to consider only new-style packages in this ticket, is the mirror thing still relevant?

Indeed, in this case you don't need to.

Nathann

[sagetrac-git]

Changed commit from ef11087 to 37fd689

[sagetrac-git]

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

37fd689

Valgrind doesn't build on OS X 10.10

[nathanncohen]

comment:8

What's wrong with Valgrind? I just compiled it on this machine:

simulote:valgrind-3.10.0 ncohen$ uname -a
Darwin simulote 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

Did you keep the log? I'd be interested to look at them.

[jdemeyer]

comment:9

Replying to @nathanncohen:

What's wrong with Valgrind? I just compiled it on this machine:

simulote:valgrind-3.10.0 ncohen$ uname -a
Darwin simulote 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

That's OS X 10.9 which is indeed fine. The problem is that it explicitly does not work on OS X 10.10:

checking for a supported OS... ok (darwin14.3.0)
checking for the kernel version... unsupported (14.3.0)
configure: error: Valgrind works on Darwin 10.x, 11.x, 12.x and 13.x (Mac OS X 10.6/7/8/9)
Error configuring Valgrind

See also http://stackoverflow.com/questions/26564125/yosemite-and-valgrind for example.

[nathanncohen]

comment:10

That's OS X 10.9 which is indeed fine. The problem is that it explicitly does not work on OS X 10.10:

Funny. Well, anyway they seem to say that the latest svn version handles it. Good news.

Oh, by the way I am about write a ticket so that sage -i <experimental_package> shows the same warning we have when the package is a new-style package.

Nathann

[nathanncohen]

comment:11

Oh, by the way I am about write a ticket so that sage -i <experimental_package> shows the same warning we have when the package is a new-style package.

Done at #18566

Nathann

[jdemeyer]

comment:12

Something else: I think we should invent a new category "alternative" for packages python2, python3, gmp, mpir which are essentially standard but shouldn't be installed at the same time. If you agree, I will create a new ticket for this.

[jdemeyer]

comment:13

Aargh... I installed compilerwrapper on OS X and it totally broke everything. Another package to move to "experimental". Restarting after make distclean...

[nathanncohen]

comment:14

Something else: I think we should invent a new category "alternative" for packages python2, python3, gmp, mpir which are essentially standard but shouldn't be installed at the same time. If you agree, I will create a new ticket for this.

I cannot say that I like this much. We already have base/standard/optional/experimental packages, old-style spkgs and new-style spkgs. What would be the advantage of alternative packages?

Nathann

[jdemeyer]

comment:15

Replying to @nathanncohen:

What would be the advantage of alternative packages?

I want to be able to install all optional packages without breaking anything.

[nathanncohen]

comment:16

I want to be able to install all optional packages without breaking anything.

What about adding a couple of lines in their spkg-install script to detect when that happens?

[sagetrac-git]

Changed commit from 37fd689 to 3a3fe9e

[sagetrac-git]

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

3a3fe9e

Compilerwrapper and custom GCC don't go well together

[sagetrac-git]

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

245ab15

Newer libtool versions require xz

[sagetrac-git]

Changed commit from 3a3fe9e to 245ab15

[nathanncohen]

Reviewer: Nathann Cohen

[vbraun]

Changed branch from u/jdemeyer/change_known_broken_packages_to__experimental_ to 245ab15