#30546 closed defect (fixed)

python3 spkg-configure: Only search for "python3", implement "configure --with-python=/PATH/TO/PYTHON"

Reported by: dimpase Owned by:
Priority: critical Milestone: sage-9.2
Component: build: configure Keywords:
Cc: mkoeppe, embray, mjo Merged in:
Authors: Matthias Koeppe, Dima Pasechnik Reviewers: Dima Pasechnik, Matthias Koeppe
Report Upstream: N/A Work issues:
Branch: f19d9a4 (Commits, GitHub, GitLab) Commit: f19d9a4a356da5e4b068dc52c321e703c2648da3
Dependencies: #30576, #29500 Stopgaps:

Status badges

Description (last modified by mkoeppe)

We make the configure search for a suitable python3 more straightforward.

Instead of searching for various names such as python3.8, python3.7 etc., we only look for python3.

As is standard practice, users will set their PATH so that the python3 that is accessible from the PATH is the desired Python version.

As an additional mechanism, we add configure --with-python=/PATH/TO/PYTHON. In contrast to the (undocumented) configure PYTHON3=/PATH/TO/PYTHON, it runs the usual tests whether this python is actually suitable.

Change History (77)

comment:1 Changed 12 months ago by dimpase

  • Status changed from new to needs_review

perhaps copypasted comments in .m4 file may be trimmed.

comment:2 Changed 12 months ago by dimpase

  • Report Upstream changed from N/A to Reported upstream. No feedback yet.

comment:3 Changed 12 months ago by mkoeppe

I don't know if this is a defect. If you have a directory containing python3 in the front of your path, shouldn't that be the python we are using?

comment:4 Changed 12 months ago by mkoeppe

  • Status changed from needs_review to needs_info

comment:5 follow-up: Changed 12 months ago by dimpase

Why is that the case? It's perfectly fine to have different fully-featured python3.x installed. It works on Homebrew to use its python3.8 in Sage, while python3 still is python3.7 It works on Gentoo, which may have python3.6-9 installed all at the same time. (Python plays an important role on Linux, one can't easily bump the version)

E.g. that's what I have on a Gentoo box, without doing anything special:

# python3 <tab>
python3            python3.7-config   python3.7m-config  python3.8-config   python3.9-config   
python3.7          python3.7m         python3.8          python3.9          python3-config 

On Ubuntu 18.04 one can install python3.8 (the system python is 3.6, and I'm not sure if it works well in Sage)

Last edited 12 months ago by dimpase (previous) (diff)

comment:6 Changed 12 months ago by dimpase

  • Status changed from needs_info to needs_review

comment:7 in reply to: ↑ 5 ; follow-up: Changed 12 months ago by mkoeppe

Replying to dimpase:

Why is that the case?

Because the user seems to have expressed a preference for the python3 provided by the directory in the front of the PATH.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 12 months ago by dimpase

Replying to mkoeppe:

Replying to dimpase:

Why is that the case?

Because the user seems to have expressed a preference for the python3 provided by the directory in the front of the PATH.

for this, we should revive --with-python= option, not this kinds of silly hacks.

Besides, as I said, it's not always safe to prepend stuff to your PATH.

comment:9 Changed 12 months ago by mkoeppe

Putting the bin directory of a Python installation in the front of the PATH is the standard way of activating a venv, for example.

comment:10 in reply to: ↑ description ; follow-up: Changed 12 months ago by mkoeppe

Replying to dimpase:

As modifying PATH to put the best python 1st might be error-prone (think about Conda, Homebrew, etc)

I would think this needs some elaboration.

comment:11 in reply to: ↑ 10 ; follow-up: Changed 12 months ago by dimpase

Replying to mkoeppe:

Replying to dimpase:

As modifying PATH to put the best python 1st might be error-prone (think about Conda, Homebrew, etc)

I would think this needs some elaboration.

Say, you build under Homebrew, but want to use system Python, in /usr/bin. Prepending /usr/bin to your PATH will likely break stuff in Hombrew, as some of it depends on /usr/local/bin being first in your PATH.

Same with Conda - it prepends stuff to PATH, and prepending /usr/bin or /usr/local/bin to PATH under active Conda will likely break it.

In general, many Python-dependent environments have the concept of "main" Python. We discussed on sage-devel that Homebrew modifies ~/.zshrc (if the account's shell is zsh)

% cat ~/.zshrc
export PATH="/usr/local/opt/python@3.7/bin:$PATH"

Prepending to the PATH here might open a can of worms.

comment:12 Changed 12 months ago by mjo

I think I agree with Matthias here. Prepending locations to the search path is the "standard" way of encouraging autotools to find your preferred version of something, and our widespread use of e.g. AC_CHECK_PROGS and AC_SEARCH_LIBS relies on that.

In this case maybe it is unexpected that a copy of python-3.6 in /usr/local/bin will be preferred over a copy of python-3.8 in /usr/bin, but... does that cause any real problems? We only detect supported versions, so any version we detect should be OK, right?

comment:13 follow-ups: Changed 12 months ago by dimpase

I don't understand - I have given you an example: prepending /usr/bin to PATH on Homebrew or Conda is basically not possible.

Yet I want to build Sage with Python3.8 in /usr/bin, as opposed to an earlier version which is 1st in the PATH.

comment:14 in reply to: ↑ 11 Changed 12 months ago by mkoeppe

Replying to dimpase:

In general, many Python-dependent environments have the concept of "main" Python.

Yes, it's represented by the unversioned "python3" in the front of the PATH.

comment:15 in reply to: ↑ 13 ; follow-up: Changed 12 months ago by mkoeppe

Replying to dimpase:

I don't understand - I have given you an example: prepending /usr/bin to PATH on Homebrew or Conda is basically not possible.

Why would anyone want to prepend /usr/bin?

comment:16 Changed 12 months ago by mkoeppe

  • Priority changed from critical to major

Sorry, I don't see evidence of a "critical defect" anywhere here

comment:17 in reply to: ↑ 8 Changed 12 months ago by mkoeppe

Replying to dimpase:

we should revive --with-python= option

Yes, I think so. Note that it is already possible to do ./configure PYTHON3=/some/path/to/python3, but this completely disables the check for the suitability of this python.

comment:18 in reply to: ↑ 13 ; follow-up: Changed 12 months ago by mjo

Replying to dimpase:

I don't understand - I have given you an example: prepending /usr/bin to PATH on Homebrew or Conda is basically not possible.

Yet I want to build Sage with Python3.8 in /usr/bin, as opposed to an earlier version which is 1st in the PATH.

I understand. Can you prepend your preferred location to PATH only during ./configure? It's a given that you don't want to prepend it everywhere. We have a problem either way. If we make your change, then it becomes harder to override a newer python in /usr/bin with an older one in e.g. /usr/local/bin.

Bringing back --with-python could address both concerns... but does PATH=whatever ./configure not work?

comment:19 in reply to: ↑ 18 ; follow-ups: Changed 12 months ago by dimpase

Replying to mjo:

Replying to dimpase:

I don't understand - I have given you an example: prepending /usr/bin to PATH on Homebrew or Conda is basically not possible.

Yet I want to build Sage with Python3.8 in /usr/bin, as opposed to an earlier version which is 1st in the PATH.

I understand. Can you prepend your preferred location to PATH only during ./configure?

This is a very fragile solution. There are many things in /usr/bin that might wreak havoc, imagine some foobar-config which has to be called by ./configure

It's a given that you don't want to prepend it everywhere. We have a problem either way.

my solution has one advantage - it makes the outcome independent of the order of things in PATH, which is something that users might - and will - screw up.

If we make your change, then it becomes harder to override a newer python in /usr/bin with an older one in e.g. /usr/local/bin.

Bringing back --with-python could address both concerns... but does PATH=whatever ./configure not work?

it is a bit pointless to discuss whether it works on a box at hand, as it is obviously a very fragile solution, and I explained why.

Last edited 12 months ago by dimpase (previous) (diff)

comment:20 in reply to: ↑ 19 Changed 12 months ago by mjo

Replying to dimpase:

it is a bit pointless to discuss whether it works on a box at hand, as it is obviously a very fragile solution, and I explained why.

We probably don't want normal users doing it to override one specific program (python) and not others, sure. I was just curious. And I had forgotten that PYTHON3=... works by virtue of autotools.

I guess we all agree --with-python is the most robust answer?

comment:21 in reply to: ↑ 19 Changed 12 months ago by mkoeppe

Replying to dimpase:

my solution has one advantage - it makes the outcome independent of the order of things in PATH, which is something that users might - and will - screw up.

But I don't think this is what users want. If there's a python3 in the front of the PATH, we should not prefer a python3.8 from the rear of the PATH. This is incompatible with standard practice of activating a venv.

Last edited 12 months ago by mkoeppe (previous) (diff)

comment:22 follow-up: Changed 12 months ago by mkoeppe

We could perhaps just reduce this list to just python3, and add the --with-python support.

comment:23 in reply to: ↑ 22 Changed 12 months ago by dimpase

Replying to mkoeppe:

We could perhaps just reduce this list to just python3,

But there are cases where python3 is not what one wants - do you mean to bypass the test then all together? This is not a good idea, we still need to test the input provided by --with-python=

and add the --with-python support.

comment:24 follow-up: Changed 12 months ago by mkoeppe

No, just shorten the list of candidate binary names to just python3. Keeping the test and thus the loop over the elements of PATH.

And add --with-python.

Both in the same ticket.

comment:25 Changed 12 months ago by dimpase

I don't understand - isn't prepending to PATH a venv's binary directory about a new directory, only containing (links to) things which aren't in the PATH at all, but nothing else?

comment:26 in reply to: ↑ 15 Changed 12 months ago by dimpase

Replying to mkoeppe:

Replying to dimpase:

I don't understand - I have given you an example: prepending /usr/bin to PATH on Homebrew or Conda is basically not possible.

Why would anyone want to prepend /usr/bin?

if you want to install Sage into a Python that is in /usr/bin, then under the current scheme of things it might not get picked if /usr/bin is not the 1st in PATH.

comment:27 in reply to: ↑ 24 Changed 12 months ago by dimpase

Replying to mkoeppe:

No, just shorten the list of candidate binary names to just python3.

Then only the unversioned python3 would be possible, no?

comment:28 follow-up: Changed 12 months ago by mkoeppe

If a user wants a versioned one, they would be using --with-python=....

comment:29 in reply to: ↑ 28 Changed 12 months ago by dimpase

Replying to mkoeppe:

If a user wants a versioned one, they would be using --with-python=....

naturally one will need to run tests, currently encapsulated in an argument of AC_PATH_PROGS_FEATURE_CHECK() on the input.

comment:30 Changed 12 months ago by mkoeppe

Yes.

comment:31 Changed 12 months ago by mkoeppe

  • Status changed from needs_review to needs_work
  • Summary changed from make sure the newest system python3 is selected to python3 spkg-configure: Only search for "python3", implement "configure --with-python=/PATH/TO/PYTHON"

comment:32 Changed 12 months ago by dimpase

Can we get rid of Python 2 checks here? It's pointless to try to build Sage with Python 3, so why bother with

AS_IF([test $SAGE_PYTHON_VERSION = 2], [
        dnl If we use Python 2 for Sage, we install Python 3...

comment:33 Changed 12 months ago by dimpase

Matthias, please refactor your wall of code in build/pkgs/python3/spkg-configure.m4 into a separate macro that just checks the features (to be put in m4/), and the rest, its too onerous as it is, with setting various ac_*_PYTHON3* variables, very hard for me to proceed here otherwise.

The refactoring should have taken place on #27824, I know...

comment:34 Changed 12 months ago by mkoeppe

Good idea, will do.

comment:35 Changed 12 months ago by mkoeppe

  • Authors Dima Pasechnik deleted
  • Branch u/dimpase/packages/python3conf deleted
  • Commit 3add5ca179ba42ba7c3136eba5b2be674572c09a deleted

comment:36 Changed 12 months ago by mkoeppe

  • Description modified (diff)
  • Report Upstream changed from Reported upstream. No feedback yet. to N/A

comment:37 Changed 12 months ago by mkoeppe

  • Authors set to Matthias Koeppe

comment:38 Changed 12 months ago by mkoeppe

  • Branch set to u/mkoeppe/python3_spkg_configure__only_search_for__python3___implement__configure___with_python__path_to_python_

comment:39 Changed 12 months ago by mkoeppe

  • Authors changed from Matthias Koeppe to Matthias Koeppe, ...
  • Commit set to 3b17cb944885581f7a97b05e8c95e1acf42c0c3f

Here you go


New commits:

3b17cb9m4/sage_check_python_for_venv.m4: New, factored out from build/pkgs/python3/spkg-configure.m4

comment:40 Changed 12 months ago by git

  • Commit changed from 3b17cb944885581f7a97b05e8c95e1acf42c0c3f to 0677e24c2cb26195ef32535d3b1e7b246e6d5d3b

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

0677e24build/pkgs/python3/spkg-configure.m4: Remove dead code for python2 build

comment:41 Changed 12 months ago by dimpase

  • Authors changed from Matthias Koeppe, ... to Matthias Koeppe, Dima Pasechnik
  • Branch changed from u/mkoeppe/python3_spkg_configure__only_search_for__python3___implement__configure___with_python__path_to_python_ to u/dimpase/build/py3x_conf
  • Commit changed from 0677e24c2cb26195ef32535d3b1e7b246e6d5d3b to d8a0bfb3535af622235ff9305b927eb8b02a327e
  • Status changed from needs_work to needs_review

New commits:

2f427d6fixed --with-python
d8a0bfbget rid of SAGE_PYTHON_VERSION (it's always 3 now)

comment:42 follow-up: Changed 12 months ago by mkoeppe

--- a/src/bin/sage-env-config.in
+++ b/src/bin/sage-env-config.in
@@ -46,7 +46,6 @@ CONFIGURED_OBJCXX="@OBJCXX@"
 #######################################
 # Other configuration (exported)
 #######################################
-export SAGE_PYTHON_VERSION=@SAGE_PYTHON_VERSION@
 export PYTHON_FOR_VENV="@PYTHON_FOR_VENV@"

I don't think this is a good idea. User packages' install scripts might depend on it.

comment:43 Changed 12 months ago by mkoeppe

-case "$with_python" in
-    3)  SAGE_PYTHON_VERSION=3;;
-    3*) AC_MSG_WARN([the only allowed value for --with-python is 3; specific Python 3.x versions cannot be requested using --with-python.  For compatibility reasons, this is only a warning.  Use './configure PYTHON3=/path/to/python3' to use a specific Python 3 binary for the Sage venv.])
-        SAGE_PYTHON_VERSION=3;;
-    "") SAGE_PYTHON_VERSION=3;;
-    *)
-        AC_MSG_ERROR([the only allowed value for --with-python is 3.  Support for Python 2 has been removed in Sage 9.2.]);;

And I think the previously allowed argument --with-python=3 should still be allowed and be a no-op; and --with-python=2 should give a specific error message as before.

comment:44 Changed 12 months ago by git

  • Commit changed from d8a0bfb3535af622235ff9305b927eb8b02a327e to fe70ff3743a9e68671d2a1929c2b292d3d002d31

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

fe70ff3correct the use of --with-python in docs and tox

comment:45 Changed 12 months ago by dimpase

there is still one obsolete place, in docker/Dockerfile:

ARG WITH_PYTHON=2
ENV WITH_PYTHON $WITH_PYTHON
ARG MAKEFLAGS="-j2"
ENV MAKEFLAGS $MAKEFLAGS
ARG SAGE_NUM_THREADS="2"
ENV SAGE_NUM_THREADS $SAGE_NUM_THREADS
RUN make configure
RUN ./configure --with-python=$WITH_PYTHON

can it be removed?

comment:46 Changed 12 months ago by git

  • Commit changed from fe70ff3743a9e68671d2a1929c2b292d3d002d31 to 10baeecc00a179e6191458f173a05c8fdaa34edc

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

10baeecrectify README a bit

comment:47 Changed 12 months ago by mkoeppe

Yes, looks like it.

comment:48 Changed 12 months ago by mkoeppe

I think you missed a few places in tox.ini

comment:49 Changed 12 months ago by git

  • Commit changed from 10baeecc00a179e6191458f173a05c8fdaa34edc to 7f20ad1e3e50a667069496c64fa7c7e7bc37ff82

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

7f20ad1more changes for docker and tox

comment:50 Changed 12 months ago by mkoeppe

Need to adjust .ci/build-docker.sh too

comment:51 Changed 12 months ago by mkoeppe

--- a/src/doc/en/developer/portability_testing.rst
+++ b/src/doc/en/developer/portability_testing.rst
@@ -371,7 +371,7 @@ command ``docker build``.  For example::
   [mkoeppe@sage sage]$ docker build . -f Dockerfile \
     --build-arg BASE_IMAGE=ubuntu:latest \
     --build-arg NUMPROC=4 \
-    --build-arg EXTRA_CONFIGURE_ARGS="--with-python=2"
+    --build-arg EXTRA_CONFIGURE_ARGS="--with-python=/usr/opt/python3.42"

better to use an example that looks like a binary, not a directory

comment:52 Changed 12 months ago by git

  • Commit changed from 7f20ad1e3e50a667069496c64fa7c7e7bc37ff82 to 83acd7b0916e66fda4d0998132e69e441fb6c328

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

832da67make the example path looking more like /usr/bin
83acd7bcleaninig up build-docker.sh

comment:53 Changed 12 months ago by dimpase

OK, should we also get rid of SAGE_PYTHON3 ?

comment:54 Changed 12 months ago by git

  • Commit changed from 83acd7b0916e66fda4d0998132e69e441fb6c328 to 7ac00cdd4725a01d53f46dba635e824bb5eb921f

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

b6ddd93a bit on --with-python into installation manual
7ac00cdremove SAGE_PYTHON3

comment:55 Changed 12 months ago by mkoeppe

comments 42, 43

comment:56 in reply to: ↑ 42 Changed 12 months ago by dimpase

Replying to mkoeppe:

--- a/src/bin/sage-env-config.in
+++ b/src/bin/sage-env-config.in
@@ -46,7 +46,6 @@ CONFIGURED_OBJCXX="@OBJCXX@"
 #######################################
 # Other configuration (exported)
 #######################################
-export SAGE_PYTHON_VERSION=@SAGE_PYTHON_VERSION@
 export PYTHON_FOR_VENV="@PYTHON_FOR_VENV@"

I don't think this is a good idea. User packages' install scripts might depend on it.

it was never documented, thus, a fair game.

comment:57 follow-up: Changed 12 months ago by git

  • Commit changed from 7ac00cdd4725a01d53f46dba635e824bb5eb921f to fc6b49d4071a63c83c7ecb2db12b4ff0c43e5568

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

fc6b49dhandle --with-python=2 or 3

comment:58 in reply to: ↑ 57 Changed 12 months ago by dimpase

Replying to git:

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

fc6b49dhandle --with-python=2 or 3

this addesses comment:43

comment:59 Changed 12 months ago by mkoeppe

  • Branch changed from u/dimpase/build/py3x_conf to u/mkoeppe/build/py3x_conf

comment:60 Changed 12 months ago by mkoeppe

  • Commit changed from fc6b49d4071a63c83c7ecb2db12b4ff0c43e5568 to b07596ddaa6e6b36fce4f9b981b9a20aec25adf5

This seems to work well. I have made some small changes.


New commits:

201db18build/pkgs/python3/spkg-configure.m4: Exit with error if python3 provided by --with-python=... is not suitable
2262df0Merge branch 'u/dimpase/build/py3x_conf' of git://trac.sagemath.org/sage into t/30546/build/py3x_conf
b07596dfixup

comment:61 Changed 12 months ago by mkoeppe

  • Reviewers set to Dima Pasechnik, Matthias Koeppe

comment:62 Changed 12 months ago by mkoeppe

If OK with you, feel free to set to positive review

comment:63 Changed 12 months ago by mkoeppe

Actually... this still needs to ensure an absolute path for PYTHON_FOR_VENV

comment:64 Changed 12 months ago by git

  • Commit changed from b07596ddaa6e6b36fce4f9b981b9a20aec25adf5 to b21ed975edf54eff10c22a2298fc6097f5c39317

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

b21ed97build/pkgs/python3/spkg-configure.m4: Ensure that PYTHON_FOR_VENV is a full path

comment:65 Changed 12 months ago by mkoeppe

I think this version is good.

comment:66 Changed 12 months ago by git

  • Commit changed from b21ed975edf54eff10c22a2298fc6097f5c39317 to 8906897f6f752673eaf2c099ec4d398e5a5fc5dd

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

49aa061Revert "build/pkgs/python3/spkg-configure.m4: Use 'python >= 3.7'; keep checking for 'python3.8, python3.7'"
a8b77cdRevert "only test python3, to be 3.7 or 3.8"
9403629build/bin/sage-system-python: Work around LC_ALL=C
ff0dbc6build/sage_bootstrap/uncompress/tar_file.py: Fix encoding to utf-8
f05a110Merge branch 't/30008/after__30053__sphinx_3_1_2_does_not_build_on_ubuntu__trusty_xenial_bionic___debian_jessie__centos_7__again_' into t/30576/public/30576
945c8c5build/bin/sage-site (--docbuild): Set an English locale suuch as C.utf-8, but not the C locale, to ensure correct operation on Python 3.6
8906897Merge branch 't/30576/public/30576' into t/30546/build/py3x_conf

comment:67 Changed 12 months ago by mkoeppe

  • Dependencies set to #30576

Merged #30576 to avoid merge conflict

comment:68 Changed 12 months ago by mkoeppe

  • Dependencies changed from #30576 to #30576, #29500

comment:69 Changed 12 months ago by git

  • Commit changed from 8906897f6f752673eaf2c099ec4d398e5a5fc5dd to a2dbb8d4f4a7cb203fd9ee0b8b2d8d6ca093da9c

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

55993b6build/bin/sage-dist-helpers: Fixup
0a64674build/pkgs/gambit/spkg-install.in: Install via bdist_wheel
ca58693build/pkgs/pillow/spkg-install.in: Install via bdist_wheel
5a747c4build/bin/sage-pip-{install,uninstall}: Remove pip2 support
9ee2110build/bin/sage-dist-helpers: Also use $sudo for storing the wheel file
d7aac84src/doc/en/developer/packaging.rst: Update sdh_... documentation
9b7c7a0build/bin/sage-pip-{install,uninstall}: Fix typo in comment
4135e8bbuild/bin/sage-pip-install: Remove an outdated comment
f2e7075Merge tag '9.2.beta13' into t/29500/install_all_python_packages_via_pip_wheel__create_pep_503_simple_repository_for_wheels
a2dbb8dMerge branch 't/29500/install_all_python_packages_via_pip_wheel__create_pep_503_simple_repository_for_wheels' into t/30546/build/py3x_conf

comment:70 Changed 12 months ago by mkoeppe

Meregd #29500 to avoid merge conflict

comment:71 Changed 12 months ago by dimpase

it is broken:

$ ./configure --with-python=/usr/bin/python3 >/tmp/p
configure: error: the python3 selected using --with-python=/usr/bin/python3 is not suitable

(while just ./configure, using the same python3, but implicitly, works)

It seems you are repeating the error that took me hours to sort out today, you have two AC_PATH_PROGS_FEATURE_CHECK with the same tag. That's why I made sure only to have one call to AC_PATH_PROGS_FEATURE_CHECK - and why do you need more?

Last edited 12 months ago by dimpase (previous) (diff)

comment:72 Changed 12 months ago by dimpase

  • Status changed from needs_review to needs_work

comment:73 Changed 12 months ago by mkoeppe

Perhaps it's just that AC_PATH_PROGS_FEATURE_CHECK does not like it if the searched executable is already an absolute path?

I may only have tested with executable names without directory...

comment:74 Changed 12 months ago by dimpase

  • Branch changed from u/mkoeppe/build/py3x_conf to u/dimpase/build/py3x_conf
  • Commit changed from a2dbb8d4f4a7cb203fd9ee0b8b2d8d6ca093da9c to f19d9a4a356da5e4b068dc52c321e703c2648da3
  • Status changed from needs_work to needs_review

OK, this appears to work. I just convert the name into an absolute one, if needed, by calling AC_PATH_PROG()


New commits:

f19d9a4allow absolute names as arguments to --with-python

comment:75 Changed 12 months ago by mkoeppe

  • Status changed from needs_review to positive_review

comment:76 Changed 12 months ago by dimpase

  • Priority changed from major to critical

I think we really want this in 9.2, not the least as it documents stuff.

comment:77 Changed 12 months ago by vbraun

  • Branch changed from u/dimpase/build/py3x_conf to f19d9a4a356da5e4b068dc52c321e703c2648da3
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.