Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#23179 closed enhancement (fixed)

Automatically wrap spkg-install scripts with boilerplate

Reported by: embray Owned by:
Priority: major Milestone: sage-8.1
Component: build Keywords:
Cc: vbraun Merged in:
Authors: Erik Bray Reviewers: Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: 9dfaeeb (Commits) Commit:
Dependencies: Stopgaps:

Description

I mentioned this idea in this ticket, but to summarize the purpose of this is to make the spkg-install scripts (as well as spkg-build and spkg-check when they exist) not directly executable on their own outside of package build directories. This is to prevent them from being accidentally executed in any other context. Further, they are wrapped to source the sage-env script from the $SAGE_ROOT the package is being installed into. So if one manually enters a package build directory and runs the spkg-install it will automatically ensure that the correct Sage environment is loaded.

This obviates the need for the guard boilerplate that checks for $SAGE_LOCAL, though it can't hurt to keep, in case sage-env itself is broken somehow.

This ticket changes a ton of files, so let me just summarize the changes briefly:

  • Modifies sage-spkg to write a wrapper containing the boilerplate around each sage-build/install/check script after it is copied into a package build directory.
  • For all existing sage-build/install/check scripts, the executable bit is removed from the copies in the source tree in build/pkgs/, and the shebang lines are removed.
  • For the handful of scripts that were written in Python, the spkg-install becomes just exec sage-python23 sage-install.py, where the original Python-based install script is moved to sage-install.py.

I think it would be good to do something like this, but it's just an idea and not strictly required for any future work.

Change History (68)

comment:1 Changed 3 years ago by embray

  • Status changed from new to needs_review

comment:2 Changed 3 years ago by git

  • Commit changed from 16a51f0dda366c0a66f7da6539cf88c830677d25 to 176356a43391a1d11e34eceac25627e6d01ce657

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

176356aRemove this check as it is no longer needed

comment:3 Changed 3 years ago by git

  • Commit changed from 176356a43391a1d11e34eceac25627e6d01ce657 to d30624b03cc6f62087e0c3c9a820148d46b67616

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

f39f099Mark all spkg-build|install|check as not executable
94d2626Create wrapper script around spkg-build, spkg-check, and spkg-install
7a7424bIn accordance with the new restrictions, strips shebank lines from all spkg-install, spkg-build, and spkg-check
d30624bRemove this check as it is no longer needed

comment:4 Changed 3 years ago by embray

Rebased.

comment:5 follow-up: Changed 3 years ago by jdemeyer

I don't really like this idea.

  1. Having those scripts executable can be useful for debugging.
  1. I would still want to keep the check if [ "$SAGE_LOCAL" = "" ]; then (possibly in a different form) to guard against accidental execution outside of a Sage shell. This is important, since there can be severe consequences if $SAGE_LOCAL is not set.
  1. Too much magic makes the logic harder to understand.

comment:6 in reply to: ↑ 5 Changed 3 years ago by embray

Replying to jdemeyer:

I don't really like this idea.

  1. Having those scripts executable can be useful for debugging.

I'm not aware of any scenario that's impeded by this. Could you give me an example?

  1. I would still want to keep the check if [ "$SAGE_LOCAL" = "" ]; then (possibly in a different form) to guard against accidental execution outside of a Sage shell. This is important, since there can be severe consequences if $SAGE_LOCAL is not set.

Right, as I wrote in the ticket I would still keep this guard, and the goal is not to remove it. That said, I don't see why this is a big deal. I'm not aware of any other packaging system that worries about this. If the consequences can be "severe" that's maybe a bigger problem.

In any case, checking $SAGE_LOCAL isn't always completely sufficient either, to prevent unwanted side-effects. What I'm proposing I believe is a lot safer because it discourages execution of these scripts outside of the appropriate context.

  1. Too much magic makes the logic harder to understand.

I've tried giving this some thought, but to be honest I really don't know what you mean by this at all.

comment:7 Changed 3 years ago by jdemeyer

I'm not aware of any other packaging system that worries about this.

Well, other packaging systems aren't written in a very fragile language like bash :-)

Anyway, let me reconsider this ticket. I am starting to understand better why it's useful.

comment:8 Changed 3 years ago by embray

True, but as far as I can tell the problem here is not that what language the packaging system itself, however you define that, is written in.

The way I see it, on most systems, the danger of accidentally installing outside SAGE_LOCAL is mitigated by permissions--you wouldn't be running these scripts with sudo. And if you are doing anything with sudo it sort of becomes your responsibility what happens.

I think at the end of the day this makes our scripts safer because they are no executable by default (if you really wanted to you could still run them with bash <filename>), and the wrapped scripts will always source the correct sage-env for the Sage that you're installing into.

comment:9 follow-up: Changed 3 years ago by jdemeyer

  1. Instead of this:
    if [ -f "/usr/local/src/sage-config/src/bin/sage-env" ]; then
        . "/usr/local/src/sage-config/src/bin/sage-env"
    else
        echo >&2 "Error: sage-env not found; is /usr/local/src/sage-config the correct SAGE_ROOT?"
        exit 1
    fi
    

I would prefer something more like

source "/usr/local/src/sage-config/src/bin/sage-env"
if [ $? -ne 0 ]; then
    echo >&2 "Error: failed to source sage-env; is /usr/local/src/sage-config the correct SAGE_ROOT?"
    exit 1
fi

At the very least, you need to check for errors when sourcing sage-env.

  1. If you really want to make the spkg-install script be usable outside of a Sage shell, starting with a cd statement into the correct directory would be good too. Otherwise you get
    $ /usr/local/src/sage-config/local/var/tmp/sage/build/patch-2.7.5/spkg-install 
    /usr/local/src/sage-config/local/var/tmp/sage/build/patch-2.7.5/spkg-install: line 45: ./configure: No such file or directory
    Error configuring GNU patch
    
  1. grep -q -x -m 1: I have some doubts about the portability of these options. GNU grep may have them, but we should support other grep implementations too.
  1. For readability, assign ".tmp-$script" to a variable: tmpscript=".tmp-$script".
  1. In sage-spkg, there is a check for a spkg-install implemented in Python. That is obsolete now.

comment:10 Changed 3 years ago by jdemeyer

  • Status changed from needs_review to needs_work

comment:11 follow-up: Changed 3 years ago by jdemeyer

  1. I find it a bit strange that you are treating a #! line in the spkg-install file as a hard error, while the executable bit is only a warning. I think the executability is something that we explicitly do not want, so that should be an error.

comment:12 in reply to: ↑ 11 ; follow-up: Changed 3 years ago by embray

Replying to jdemeyer:

  1. I find it a bit strange that you are treating a #! line in the spkg-install file as a hard error, while the executable bit is only a warning. I think the executability is something that we explicitly do not want, so that should be an error.

That can be a problem on Cygwin where, depending on how permission emulation is configured, all files may be treated as executable even if they aren't really (annoying, yes). My configuration isn't like that but it's not guaranteed.

comment:13 in reply to: ↑ 9 ; follow-up: Changed 3 years ago by embray

Replying to jdemeyer:

  1. grep -q -x -m 1: I have some doubts about the portability of these options. GNU grep may have them, but we should support other grep implementations too.

These options are available on BSD grep as well, including on OSX. If someone can point out a specific implementation where they're not then I can change it.

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

Replying to embray:

If someone can point out a specific implementation where they're not then I can change it.

Since you challenged me, OpenBSD grep does not have -m. But really, there is no reason to use -m, you can use head -1 | grep. And instead of using -x, you can match a whole line with ^regex$. And instead of using -q, use > /dev/null.

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

comment:15 in reply to: ↑ 14 Changed 3 years ago by embray

Replying to jdemeyer:

Replying to embray:

If someone can point out a specific implementation where they're not then I can change it.

Since you challenged me, OpenBSD grep does not have -m. But really, there is no reason to use -m, you can use head -1 | grep. And instead of using -x, you can match a whole line with ^regex$. And instead of using -q, use > /dev/null.

Okay, that's fine--obviously all of these alternatives are possible just annoying.

comment:16 in reply to: ↑ 12 Changed 3 years ago by embray

Replying to embray:

Replying to jdemeyer:

  1. I find it a bit strange that you are treating a #! line in the spkg-install file as a hard error, while the executable bit is only a warning. I think the executability is something that we explicitly do not want, so that should be an error.

That can be a problem on Cygwin where, depending on how permission emulation is configured, all files may be treated as executable even if they aren't really (annoying, yes). My configuration isn't like that but it's not guaranteed.

Perhaps for Cygwin I could just output a warning, but make it an error everywhere else, where presumably we can rely on permissions being sane.

comment:17 Changed 3 years ago by git

  • Commit changed from d30624b03cc6f62087e0c3c9a820148d46b67616 to 01e3c0398e9eac74eadab95ee8e199de48d376f4

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

d5399f7Don't use not entirely portable GNU grep features
3c34582Instead of looking before we leap, always try sourcing sage-env, and handle any errors that might occur
38647dcPass write_script_wrapper the absolute path to the script it's writing
8cd0049Use a variable for the path to the temporary file for clarity's sake
01e3c03Remove this check from sage-spkg since spkg-installs will no longer be written in Python

comment:18 Changed 3 years ago by embray

  • Reviewers set to Jeroen Demeyer
  • Status changed from needs_work to needs_review

I think this addresses all your comments so far. If this needs any further tweaks that's fine, but even if not please set this back to needs work so that I can work on updating the developer documentation, assuming there are no further objections to this in principle.

comment:19 Changed 3 years ago by embray

  • Status changed from needs_review to needs_work

Sorry, I think there's a bug somewhere.

comment:20 Changed 3 years ago by git

  • Commit changed from 01e3c0398e9eac74eadab95ee8e199de48d376f4 to e2362e1c2cc93293f1e206f8a95169995e9e4ea3

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

b05f707Instead of looking before we leap, always try sourcing sage-env, and handle any errors that might occur
d22768dPass write_script_wrapper the absolute path to the script it's writing
84cbd4eUse a variable for the path to the temporary file for clarity's sake
e2362e1Remove this check from sage-spkg since spkg-installs will no longer be written in Python

comment:21 Changed 3 years ago by embray

  • Status changed from needs_work to needs_review

Seems fine now; just had a stupid typo.

comment:22 Changed 3 years ago by git

  • Commit changed from e2362e1c2cc93293f1e206f8a95169995e9e4ea3 to 1d8b94e22b6e501139e4efcf7992a1bce467ec62

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

9c34d45Don't use not entirely portable GNU grep features
e677e4eInstead of looking before we leap, always try sourcing sage-env, and handle any errors that might occur
a426c02Pass write_script_wrapper the absolute path to the script it's writing
1b66b8cUse a variable for the path to the temporary file for clarity's sake
1d8b94eRemove this check from sage-spkg since spkg-installs will no longer be written in Python

comment:23 Changed 3 years ago by jdemeyer

To be clear: I have no further objections to the principle (you convinced me).

comment:24 Changed 3 years ago by embray

Okay, thanks--I'll work on the documentation updates then.

comment:25 Changed 3 years ago by jdemeyer

I just built Sage from scratch with this branch and it worked.

comment:26 Changed 3 years ago by embray

  • Status changed from needs_review to needs_work

Thanks; I'll work on updating the documentation.

comment:27 Changed 3 years ago by git

  • Commit changed from 1d8b94e22b6e501139e4efcf7992a1bce467ec62 to 66888230ed1976e7ca075464499ae3ce4e9a4951

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

6688823Make it a mere warning on Cygwin if any of the scripts in build/pkgs are executable, but a hard error on other platforms

comment:28 Changed 3 years ago by jdemeyer

So your plan is to change only the documentation and nothing else?

I am asking because I want to give the final version of the code another round of testing. But that is only meaningful if you are not going to change the code.

comment:29 Changed 3 years ago by embray

I don't plan to make any further updates to the code on this ticket, unless you or someone else comes up with a suggestion.

comment:30 Changed 3 years ago by jdemeyer

$? should be quoted otherwise you get

#!/usr/bin/env bash

source "/opt/sage/sage-test/src/bin/sage-env"
if [ 0 -ne 0 ]; then
    echo >&2 "Error: failed to source sage-env; is /opt/sage/sage-test the correct SAGE_ROOT?"
    exit 1
fi

cd "/opt/sage/sage-test/local/var/tmp/sage/build/pari-2.9.2.p2"
if [ 0 -ne 0 ]; then
    echo >&2 "Error: could not cd to the package build directory /opt/sage/sage-test/local/var/tmp/sage/build/pari-2.9.2.p2"
    exit 1
fi

I wonder why you don't use a here document for this:

cat <<EOF
...
EOF

That way, there would no need to quote ".

comment:31 Changed 3 years ago by embray

Oops, good catch. I don't know why I didn't use a heredoc either. Maybe just because it started out shorter.

comment:32 Changed 3 years ago by git

  • Commit changed from 66888230ed1976e7ca075464499ae3ce4e9a4951 to 932b85910f6ace2d8d2f806865f7ae73699300aa

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

932b859Use a heredoc instead of a quoted variable, for clarity's sake.

comment:33 Changed 3 years ago by jdemeyer

This breaks old-style packages:

$ ./sage -p cluster_seed
Found package cluster_seed in /opt/sage/sage-test/upstream/cluster_seed-1.0.spkg
cluster_seed-1.0
====================================================
Extracting package /opt/sage/sage-test/upstream/cluster_seed-1.0.spkg
-rw-r--r-- 1 jdemeyer jdemeyer 150910 Jul  5 14:26 /opt/sage/sage-test/upstream/cluster_seed-1.0.spkg
Finished extraction
No patch files found in ../patches
************************************************************************
spkg-install should not be marked executable in the                 build/pkgs directory
************************************************************************
Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the log file
  /opt/sage/sage-test/logs/pkgs/cluster_seed-1.0.log
Describe your computer, operating system, etc.
************************************************************************

Now I see two solutions to this: either you need to bypass the boilerplate stuff from this ticket for old-style packages, or we need to drop support for old-style packages completely.

I will write to sage-devel to ask opinions about the latter.

Minor note: this causes excessive whitespace:

            msg="spkg-$script should not be marked executable in the \
                build/pkgs directory"

I would just put this on one line.

comment:34 Changed 3 years ago by embray

Ah, you're right about the whitespace. On the REPL it will strip the leading whitespace but not in a script. Too bad, but okay.

Yeah, I actually wasn't sure what this would do with "old style" packages. I figured if someone cared they would point it out. I've just never actually seen one of these old-style packages and wouldn't know where to find one.

I'd be all for removing support entirely, but obviously that should be a separate issue. In the meantime I make exceptions for them.

comment:35 follow-up: Changed 3 years ago by embray

One idea that came to me while updating the docs, though possibly a bit too surprising: The current docs explicitly state that spkg-install can be either a shell script or a Python script (though I don't think there's anything stopping it from being an arbitrary executable). The Python case, in the very least, could still be supported though. The way I handled the few existing Python scripts is quite mechanical--simply rename the Python spkg-install to spkg-install.py, and run exec sage-python23 spkg-install.py in the actual spkg-install. This mechanism of wrapping Python scripts could just as easily be automated. Not sure if it's worth the trouble though--it's probably simpler to just require it to be a bash script, full stop.

comment:36 Changed 3 years ago by embray

  • Milestone changed from sage-8.0 to sage-8.1

Presumably this won't be in Sage 8.0 since it's already in the release candidate stage...

comment:37 in reply to: ↑ 35 Changed 3 years ago by jdemeyer

Replying to embray:

it's probably simpler to just require it to be a bash script, full stop.

I agree. I think it suffices to mention in the docs how to support a Python install script using sage-python23.

comment:38 Changed 3 years ago by git

  • Commit changed from 932b85910f6ace2d8d2f806865f7ae73699300aa to a6163ce73554a602a484026f700849130d796665

Branch pushed to git repo; I updated commit sha1. This was a forced push. Last 10 new commits:

ff832c4Don't use not entirely portable GNU grep features
4a77569Instead of looking before we leap, always try sourcing sage-env, and handle any errors that might occur
8d19362Pass write_script_wrapper the absolute path to the script it's writing
be6559dUse a variable for the path to the temporary file for clarity's sake
954630fRemove this check from sage-spkg since spkg-installs will no longer be written in Python
1b96a66Make it a mere warning on Cygwin if any of the scripts in build/pkgs are executable, but a hard error on other platforms
b1155ddUse a heredoc instead of a quoted variable, for clarity's sake.
d28f35dAdd an explicit variable indicating if this is an old-style package
4c4941fRestore support old-style packages, for now, by not creating script wrappers
a6163ceUpdated the developer docs to reflect the changes in #23179

comment:39 Changed 3 years ago by embray

Restored support for old-style packages (still needs to be tested), updated developer docs, and rebased on latest develop branch.

comment:40 Changed 3 years ago by embray

  • Status changed from needs_work to needs_review

comment:41 Changed 3 years ago by embray

(Ran ./sage -p cluster_seed and it worked fine--in short, for old-style packages it just uses the unmodified spkg-install as before).

comment:42 Changed 3 years ago by git

  • Commit changed from a6163ce73554a602a484026f700849130d796665 to 8819114afb5494f4f25231fb183fb75b6209e476

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

8819114Set some variables in the wrapper script itself.

comment:43 follow-up: Changed 3 years ago by embray

I'm researching open package update tickets with patches that could conflict with this (specifically, those that update spkg-install--if they don't then there shouldn't be much conflict).

Tickets with positive review:

Tickets still needing work/review:

The following old tickets conflict with #20136 (or other more recent changes) and will need to be rebased anyways:

Since tickets like this one (and #22509 + #22510) that make mass updates to packages are notoriously unwieldy it would be good to get merged quickly if/when it has a positive review.

To that end, I can make this depend on #23023 and #23357 since they already have positive review. Of the tickets still needing work, it might be nice if some of them added this ticket as a dependency (especially #23325 and #23353 since they were opened later) but if they can be given a positive review quickly, I also have no problem adding them as dependencies to this ticket. Most of the other tickets on that list either haven't been updated for several months, or are still in development, so I would prefer not to wait on them unless I hear otherwise.

comment:44 follow-up: Changed 3 years ago by jdemeyer

There is no need for $PKG_OLD_STYLE since it is simply the negation of $USE_LOCAL_SCRIPTS. So you can replace [ -z "$PKG_OLD_STYLE" ] by [ "$USE_LOCAL_SCRIPTS" = yes ] and then you don't need the PKG_OLD_STYLE variable.

comment:45 in reply to: ↑ 43 ; follow-up: Changed 3 years ago by jdemeyer

Replying to embray:

To that end, I can make this depend on #23023 and #23357

As far as I can see, there should be no conflict with #23357 (it does edit spkg-install but in a way that git should merge cleanly).

There is a conflict with #23023 since that actually adds a new package.

comment:46 in reply to: ↑ 44 ; follow-up: Changed 3 years ago by embray

Replying to jdemeyer:

There is no need for $PKG_OLD_STYLE since it is simply the negation of $USE_LOCAL_SCRIPTS. So you can replace [ -z "$PKG_OLD_STYLE" ] by [ "$USE_LOCAL_SCRIPTS" = yes ] and then you don't need the PKG_OLD_STYLE variable.

Note: I deliberately added this variable because the fact that $USE_LOCAL_SCRIPTS meant this implicitly was unclear. I thought it would help make clearer which bits to remove upon removing support for old-style packages which I guess will happen soon anyways.

comment:47 in reply to: ↑ 45 Changed 3 years ago by embray

Replying to jdemeyer:

Replying to embray:

To that end, I can make this depend on #23023 and #23357

As far as I can see, there should be no conflict with #23357 (it does edit spkg-install but in a way that git should merge cleanly).

Agreed, and same for a few others on the list, but I wanted to be on the safe side.

comment:48 in reply to: ↑ 46 Changed 3 years ago by jdemeyer

Replying to embray:

Note: I deliberately added this variable because the fact that $USE_LOCAL_SCRIPTS meant this implicitly was unclear.

It's pretty explicit:

##################################################################
# Extract the package
##################################################################

if [ "$USE_LOCAL_SCRIPTS" = yes ]; then
    # New-style package
    ...
else
    # Old-style package (deprecated)
    ...
fi

I'm -1 on adding a new variable just because you find that an existing variable has a confusing name. If you don't like the name USE_LOCAL_SCRIPTS, you can just change the name everywhere.

comment:49 Changed 3 years ago by embray

Yeah, I see your point. In retrospect I didn't even understand why it was called "USE_LOCAL_SCRIPTS" but I guess that is actually synonymous with "new-style package".

I'll just remove the commit that added the new variable and the rest should fall into place.

comment:50 Changed 3 years ago by jdemeyer

Good! After that, I'll do a (hopefully) final round of testing and then it should be good to go.

comment:51 Changed 3 years ago by jdemeyer

I don't mind to rebase #23023 on top of this ticket, I think that would be better.

comment:52 Changed 3 years ago by git

  • Commit changed from 8819114afb5494f4f25231fb183fb75b6209e476 to 6e322b8079aa01a9720ebc1b67f6056ba4086b9b

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

c447855Use a heredoc instead of a quoted variable, for clarity's sake.
f53ee4dUpdated the developer docs to reflect the changes in #23179
6e322b8Set some variables in the wrapper script itself.

comment:53 Changed 3 years ago by embray

Okay, done.

I should say, since I wasn't my best self a couple weeks ago, that I always appreciate your meticulous reviews whether or not we agree on everything.

comment:54 Changed 3 years ago by jdemeyer

Typo: neecessarily

comment:55 Changed 3 years ago by jdemeyer

Typo: enforsed

comment:56 Changed 3 years ago by git

  • Commit changed from 6e322b8079aa01a9720ebc1b67f6056ba4086b9b to caf64bfa51ee2d3c9eb3ca9c148bde0ef22e8fd5

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

caf64bfFix typos in this comment

comment:57 Changed 3 years ago by fbissey

For info I have marked #15674 in your list as duplicate since it was superseded by #22817 which was merged.

comment:58 Changed 3 years ago by jdemeyer

  • Status changed from needs_review to positive_review

comment:59 Changed 3 years ago by jdemeyer

  • Cc vbraun added
  • Priority changed from major to blocker

Setting to blocker to get the attention of the release manager.

Volker: since this touches a lot of files, it would be best to merge this early in Sage 8.1 to avoid conflicts.

comment:60 Changed 3 years ago by vbraun

  • Priority changed from blocker to major

comment:61 Changed 3 years ago by vbraun

  • Status changed from positive_review to needs_work
Successfully installed scipy-0.17.1.p0
Running the test suite for scipy-0.17.1.p0...
/mnt/disk/home/buildslave-sage/slave/sage_git/build/local/bin/python2: can't open file 'sage-check.py': [Errno 2] No such file or directory

comment:62 Changed 3 years ago by jdemeyer

Typo: sage-check.py -> spkg-check.py

comment:63 Changed 3 years ago by git

  • Commit changed from caf64bfa51ee2d3c9eb3ca9c148bde0ef22e8fd5 to 9dfaeeb2dcec72608c7cb5eceaecdd554f508132

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

9dfaeebFix obvious typo

comment:64 Changed 3 years ago by embray

  • Status changed from needs_work to positive_review

This was just a typo as confirmed by Jeroen so I'll set it back to positive review.

Last edited 3 years ago by embray (previous) (diff)

comment:65 Changed 3 years ago by vbraun

  • Branch changed from u/embray/build/script-wrappers to 9dfaeeb2dcec72608c7cb5eceaecdd554f508132
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:66 Changed 3 years ago by fbissey

  • Commit 9dfaeeb2dcec72608c7cb5eceaecdd554f508132 deleted

I just flagged #23498 which was merged at the same time for follow up. Do we have a ticket for mopping up any new/upgrade packages that will trickle in until people are fully aware of the new system? We may have to do a bit of spotting and pre-emptive reviewing for a while.

comment:67 Changed 3 years ago by embray

I mean, I made a big list of tickets that are affected by this: https://trac.sagemath.org/ticket/23179#comment:45 But #23498 slipped through the cracks.

comment:68 Changed 3 years ago by fbissey

Yes the list of "older" ticket is fine. I already warned one upgrade (arb) on rebasing on this ticket before 8.1.beta1 was released. But apart from those one, we need to be careful of new package/upgrade ticket for a while as well.

Note: See TracTickets for help on using tickets.