search

cschwan / sage-on-gentoo

(Unofficial) Gentoo Overlay for Sage- and Sage-related ebuilds
84 stars 26 forks source link

Palp-2.1 Source link broken #514

Closed askme765cs closed 6 years ago

askme765cs commented 6 years ago

The website containing archive with palp-2.1 http://hep.itp.tuwien.ac.at/ is down and I can't emerge it. It's not the issue of sage-on-gentoo, but how can the problem with the ebuid be solved? As is mentioned in #178 A mirror of http://hep.itp.tuwien.ac.at/ as well as ebuild update may be needed.

kiwifb commented 6 years ago

Thanks for the report. I will check if I can use a sage mirror instead for the tarball. That should be more reliable.

kiwifb commented 6 years ago

Hum, the sage tarball has "non-automated" changes compared to upstream so I will have to host the tarball for safety.

kiwifb commented 6 years ago

Should be fine now. Re-open if there is a further issue.

dimpase commented 2 years ago

Any reason palp is not in main Gentoo repo yet?

kiwifb commented 2 years ago

It is a rather original case of multibuild usage but that shouldn't be an obstacle. So, mainly laziness?

dimpase commented 2 years ago

If you can guide me how to contribute an e-build, I can try doing this.

kiwifb commented 2 years ago

Sorry, I had to have a snooze (or at least try) and then I forgot about your question. If you are ready to be a proxy maintainer, then sure. Otherwise me or @orlitzky should do it. There are a few guides to look at and you need to have a PGP key.

orlitzky commented 2 years ago

Any reason palp is not in main Gentoo repo yet?

I'm just not willing to put my name on it with the existing build procedure (see e.g. https://trac.sagemath.org/ticket/29672#comment:2). I cut corners here and there like everyone else, but building palp four times and installing four copies of the executables just to make one out-of-tree program (sage) happy is IMO an unacceptable amount of technical debt to dump in an initial commit.

The upstream build system could be taught to produce all of the executable variants, at which point it wouldn't be an issue. Or (smarter) the single executable could dispatch to an optimized implementation based on the size of the input. But compared to some other pending projects (linbox, maxima; zn_poly removal...) palp is small and thus at the bottom of my priority list.

Note: palp-2.20 is out.