Opened 4 years ago

Closed 4 years ago

#18563 closed defect (fixed)

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

Reported by: jdemeyer Owned by:
Priority: major Milestone: sage-6.8
Component: packages: experimental Keywords:
Cc: Merged in:
Authors: Jeroen Demeyer Reviewers: Nathann Cohen
Report Upstream: N/A Work issues:
Branch: 245ab15 (Commits) Commit: 245ab151fe517da0eb2a982494376a20441304f4
Dependencies: Stopgaps:

Description (last modified by 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 #18560
  • dot2tex: see #18124
  • gdb: does not work properly on OS X: live with it
  • tides: see #18573

Change History (22)

comment:1 Changed 4 years ago by jdemeyer

  • Branch set to u/jdemeyer/change_known_broken_packages_to__experimental_

comment:2 Changed 4 years ago by ncohen

  • Commit set to ef11087ea5d80f77d3d783abcc3301f8d41755ab
  • Description modified (diff)

New commits:

ef11087Change known-broken packages to "experimental"

comment:3 Changed 4 years ago by ncohen

needs review ?

comment:4 in reply to: ↑ description ; follow-up: Changed 4 years ago by jdemeyer

  • Summary changed from Change known-broken packages to "experimental" to Change known-broken new-style packages to "experimental"

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?

comment:5 in reply to: ↑ 4 Changed 4 years ago by ncohen

  • Description modified (diff)

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

Last edited 4 years ago by ncohen (previous) (diff)

comment:6 Changed 4 years ago by git

  • Commit changed from ef11087ea5d80f77d3d783abcc3301f8d41755ab to 37fd68966756365cd330e1eeba3b9beb332d6f81

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

37fd689Valgrind doesn't build on OS X 10.10

comment:7 Changed 4 years ago by jdemeyer

  • Description modified (diff)

comment:8 follow-up: Changed 4 years ago by ncohen

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.

Last edited 4 years ago by ncohen (previous) (diff)

comment:9 in reply to: ↑ 8 ; follow-up: Changed 4 years ago by jdemeyer

Replying to ncohen:

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.

comment:10 in reply to: ↑ 9 ; follow-up: Changed 4 years ago by ncohen

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

comment:11 in reply to: ↑ 10 Changed 4 years ago by ncohen

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

comment:12 follow-up: Changed 4 years ago by jdemeyer

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.

comment:13 Changed 4 years ago by jdemeyer

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

comment:14 in reply to: ↑ 12 ; follow-up: Changed 4 years ago by ncohen

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

comment:15 in reply to: ↑ 14 ; follow-up: Changed 4 years ago by jdemeyer

Replying to ncohen:

What would be the advantage of alternative packages?

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

Last edited 4 years ago by jdemeyer (previous) (diff)

comment:16 in reply to: ↑ 15 Changed 4 years ago by ncohen

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?

comment:17 Changed 4 years ago by git

  • Commit changed from 37fd68966756365cd330e1eeba3b9beb332d6f81 to 3a3fe9e7429959af51f45a0767720d4830239ba7

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

3a3fe9eCompilerwrapper and custom GCC don't go well together

comment:18 Changed 4 years ago by git

  • Commit changed from 3a3fe9e7429959af51f45a0767720d4830239ba7 to 245ab151fe517da0eb2a982494376a20441304f4

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

245ab15Newer libtool versions require xz

comment:19 Changed 4 years ago by jdemeyer

  • Description modified (diff)

comment:20 Changed 4 years ago by jdemeyer

  • Description modified (diff)
  • Status changed from new to needs_review

comment:21 Changed 4 years ago by ncohen

  • Reviewers set to Nathann Cohen
  • Status changed from needs_review to positive_review

comment:22 Changed 4 years ago by vbraun

  • Branch changed from u/jdemeyer/change_known_broken_packages_to__experimental_ to 245ab151fe517da0eb2a982494376a20441304f4
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.