On Wed, Feb 26, 2025 at 1:26 PM Dima Pasechnik <[email protected]> wrote: > > On Wed, Feb 26, 2025 at 11:27 AM Marc Culler <[email protected]> wrote: > > > > What about just checking the return status of nm piped to grep, as we were > > just doing? (Once you know which function you need to look for). > > the function name is correct, the mangled name is dgeqrf_, as reported > by AC_FC_FUNC, > with this value, AC_CHECK_FUNC passes. > > However, I found something that looks like an upstream (Homebrew?) > error: "-fopenmp" is pushed into CFLAGS > from the pkg-config, but this causes C compilations (with clang) fail, > as Apple clang does not support openmp, > as far as I can tell (and Sage's tests on gcc agree with me here). > > It's probably due to Homebrew using a compiler which can ignore such > an unknown option. > > % pkg-config -cflags openblas > -I/opt/homebrew/Cellar/openblas/0.3.29/include -fopenmp > > Note that without OpenMP openblas is much, much less performant than with it. > According to the great R project: https://mac.r-project.org/openmp/, > on XCode clang openmp is supported with > -Xclang -fopenmp > and one also needs an openmp dylib - which Apple doesn't ship (thanks > Apple, as usual - of course they want us to use their propriatory > stuff), > but it is available from R project at the URL above, or from > https://formulae.brew.sh/formula/libomp > > I have yet to try the latter. Probably the flags in openblas.pc still > need to be corrected.
I have filed https://github.com/Homebrew/homebrew-core/issues/209091 to report incorrect CFLAGS in openblas.pc Here is a patch for build/pkgs/openblas/spkg-configure.m4 I came up with: --- a/build/pkgs/openblas/spkg-configure.m4 +++ b/build/pkgs/openblas/spkg-configure.m4 @@ -23,12 +23,11 @@ SAGE_SPKG_CONFIGURE([openblas], [dnl CHECK ]) dnl Check all name manglings that AC_FC_FUNC could check based on the dnl characteristics of the Fortran compiler - m4_foreach([dgeqrf_mangled], [dgeqrf, dgeqrf_, DGEQRF, DGEQRF_], [dnl - AC_CHECK_FUNC(dgeqrf_mangled, [dnl - AS_VAR_SET([HAVE_DGEQRF], [yes]) - ]) - ]) - AS_IF([test x$HAVE_DGEQRF = xyes], [dnl openblas works as lapack + + AC_MSG_CHECKING([for the mangled name for dgeqrf]) + AC_FC_FUNC([dgeqrf]) + AC_MSG_RESULT($dgeqrf) + AC_CHECK_FUNC($dgeqrf, [dnl openblas works as lapack sage_install_lapack_pc=yes ], [dnl openblas does not work as lapack; try to use system lapack as is PKG_CHECK_MODULES([LAPACK], [lapack], [], [sage_spkg_install_openblas=yes]) But it won't work on Homebrew, without fixing openblas.pc I've tried adding the correct -Xclang prefix to -fopenmp in openblas.pc, but it led to trouble building fflas_ffpack. Then I just removed -fopenmp from openblas.pc, and everything builds (with openblas from Homebrew) I'll report test results... Dima > > Dima > > > > > - Marc > > > > On Wed, Feb 26, 2025 at 11:14 AM Dima Pasechnik <[email protected]> wrote: > >> > >> On Wed, Feb 26, 2025 at 10:44 AM Marc Culler <[email protected]> wrote: > >> > > >> > The code that is rejecting openblas 0.3.29 appears to be in > >> > build/pkgs/openblas/spkgconfigure.m4. > >> > > >> > That file includes tests for the existence of the symbol dgeqrf_ for the > >> > purpose of deciding whether a version of openblas also provides lapack. > >> > According to github blame, that seems to have been Dima's idea 5 or 6 > >> > years ago. Given that LAPACK appears so many times when searching for > >> > dgeqfr in the output of nm, I would guess that version 0.3.29 does in > >> > fact provide lapack. But the tests in that m4 file need to be revised. > >> > >> yes, right, that's exactly what I'm doing now. However, the test is > >> very tricky and complicated, as > >> a standard way to check that a Fortran function is available is to call > >> Fortran > >> (something what autoconf macro AC_FC_FUNC would do) > >> Instead, the test is done with C++, is much more complicated, and > >> fails on macOS arm64 for reasons > >> not yet known to me. > >> > >> I'm trying to see if at least AC_FC_FUNC can do the job, in the > >> presence of gfortran... > >> > >> Dima > >> > >> > > >> > - Marc > >> > > >> > On Wednesday, February 26, 2025 at 7:45:36 AM UTC-6 [email protected] > >> > wrote: > >> >> > >> >> indeed, I get > >> >> > >> >> MAC-04017247:sage dcoudert$ nm > >> >> /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.dylib | grep > >> >> dgeqrfp > >> >> > >> >> 0000000000d84dbc T _LAPACKE_dgeqrfp > >> >> > >> >> 0000000000d84eec T _LAPACKE_dgeqrfp_work > >> >> > >> >> 00000000008f4120 T _dgeqrfp_ > >> >> > >> >> > >> >> > >> >> On Tuesday, February 25, 2025 at 11:11:21 PM UTC+1 [email protected] > >> >> wrote: > >> >>> > >> >>> The symbol which is reported as missing from openblas 0.3.29 (dgeqrf_) > >> >>> is defined in openblas 0.3.28 (which is the version built by the Sage > >> >>> openblas spkg). > >> >>> % nm local/lib/libopenblas.dylib | grep dgeqrf > >> >>> 00000000007fcb64 T _LAPACKE_dgeqrf > >> >>> 00000000007fcca0 T _LAPACKE_dgeqrf_work > >> >>> 00000000007fce58 T _LAPACKE_dgeqrfp > >> >>> 00000000007fcf94 T _LAPACKE_dgeqrfp_work > >> >>> 0000000000364c60 T _dgeqrf_ > >> >>> 00000000003651a0 T _dgeqrfp_ > >> >>> > >> >>> If you run that nm command on the Homebrew version of > >> >>> libopenblas.dylib it will probably not show that symbol. > >> >>> > >> >>> The configure script author seemed to think that dgeqrf_ is a good > >> >>> symbol to check for when deciding whether an openblas library is > >> >>> acceptable. But that symbol was apparently removed from 0.3.29. So > >> >>> maybe that was just a bad choice and the script should be checking for > >> >>> something else instead. > >> >>> > >> >>> - Marc > >> >>> > >> >>> On Tuesday, February 25, 2025 at 3:22:00 PM UTC-6 [email protected] > >> >>> wrote: > >> >>>> > >> >>>> > >> >>>> MAC-04017247:sage dcoudert$ otool -TV > >> >>>> /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.dylib > >> >>>> > >> >>>> /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.dylib: > >> >>>> > >> >>>> Table of contents (0 entries) > >> >>>> > >> >>>> module name symbol name > >> >>>> > >> >>>> MAC-04017247:sage dcoudert$ otool -TV > >> >>>> /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.a | grep dgeqrf > >> >>>> > >> >>>> /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.a(dgeqrf.o): > >> >>>> > >> >>>> /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.a(dgeqrfp.o): > >> >>>> > >> >>>> /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.a(lapacke_dgeqrf.o): > >> >>>> > >> >>>> /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.a(lapacke_dgeqrf_work.o): > >> >>>> > >> >>>> /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.a(lapacke_dgeqrfp.o): > >> >>>> > >> >>>> /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.a(lapacke_dgeqrfp_work.o): > >> >>>> > >> >>>> > >> >>>> and yes, I'm trying with https://github.com/sagemath/sage/pull/39571 > >> >>>> > >> >>>> On Tuesday, February 25, 2025 at 8:59:05 PM UTC+1 Dima Pasechnik > >> >>>> wrote: > >> >>>>> > >> >>>>> On Tue, Feb 25, 2025 at 1:01 PM [email protected] > >> >>>>> <[email protected]> wrote: > >> >>>>> > > >> >>>>> > my homebrew install of openblas (0.3.29) is not accepted, as can > >> >>>>> > be seen in the config.log file. > >> >>>>> > >> >>>>> can you find anything like "dgeqrf" in the output of > >> >>>>> > >> >>>>> otool -TV /opt/homebrew/Cellar/openblas/0.3.29/lib/libopenblas.dylib > >> >>>>> > >> >>>>> not 100% sure about the exact name of the dylib , but you get the > >> >>>>> idea, right? > >> >>>>> The issue comes from > >> >>>>> https://github.com/sagemath/sagetrac-mirror/commit/71ac6a5e18ad2e08383a122ef305df593a34aa3a > >> >>>>> which is a very hacky way to avoid the use of gfortran. We can > >> >>>>> re-work > >> >>>>> it if needed. > >> >>>>> > >> >>>>> Dima > >> >>>>> > > >> >>>>> > ## --------------------------------------------------------- ## > >> >>>>> > ## Checking whether SageMath should install SPKG openblas... ## > >> >>>>> > ## --------------------------------------------------------- ## > >> >>>>> > configure:18884: checking whether any of gfortran is installed as > >> >>>>> > or will be installed as SPKG > >> >>>>> > configure:18894: result: no > >> >>>>> > configure:18908: checking for openblas >= 0.2.20 openblas < 0.3.99 > >> >>>>> > configure:18915: $PKG_CONFIG --exists --print-errors "openblas >= > >> >>>>> > 0.2.20 openblas < 0.3.99" > >> >>>>> > configure:18918: $? = 0 > >> >>>>> > configure:18932: $PKG_CONFIG --exists --print-errors "openblas >= > >> >>>>> > 0.2.20 openblas < 0.3.99" > >> >>>>> > configure:18935: $? = 0 > >> >>>>> > configure:19931: result: yes > >> >>>>> > configure:19940: $PKG_CONFIG --exists --print-errors "openblas" > >> >>>>> > configure:19943: $? = 0 > >> >>>>> > configure:19963: checking for cblas_dgemm > >> >>>>> > configure:19963: g++ -std=gnu++11 -std=gnu++11 -o conftest > >> >>>>> > conftest.cpp -L/opt/homebrew/Cellar/openblas/0.3.29/lib -lopenblas > >> >>>>> > -lbz2 -lglpk -lgmp -lm >&5 > >> >>>>> > configure:19963: $? = 0 > >> >>>>> > configure:19963: result: yes > >> >>>>> > configure:20044: checking for dgeqrf > >> >>>>> > configure:20044: g++ -std=gnu++11 -std=gnu++11 -o conftest > >> >>>>> > conftest.cpp -L/opt/homebrew/Cellar/openblas/0.3.29/lib -lopenblas > >> >>>>> > -lbz2 -lglpk -lgmp -lm >&5 > >> >>>>> > Undefined symbols for architecture arm64: > >> >>>>> > "_dgeqrf", referenced from: > >> >>>>> > _main in conftest-e6c8b5.o > >> >>>>> > ld: symbol(s) not found for architecture arm64 > >> >>>>> > clang++: error: linker command failed with exit code 1 (use -v to > >> >>>>> > see invocation) > >> >>>>> > configure:20044: $? = 1 > >> >>>>> > configure: failed program was: > >> >>>>> > | /* confdefs.h */ > >> >>>>> > | #define PACKAGE_NAME "Sage" > >> >>>>> > | #define PACKAGE_TARNAME "sage" > >> >>>>> > | #define PACKAGE_VERSION "10.6.beta7" > >> >>>>> > | #define PACKAGE_STRING "Sage 10.6.beta7" > >> >>>>> > | #define PACKAGE_BUGREPORT "[email protected]" > >> >>>>> > | #define PACKAGE_URL "" > >> >>>>> > | #define PACKAGE "sage" > >> >>>>> > | #define VERSION "10.6.beta7" > >> >>>>> > | #define HAVE_STDIO_H 1 > >> >>>>> > | #define HAVE_STDLIB_H 1 > >> >>>>> > | #define HAVE_STRING_H 1 > >> >>>>> > | #define HAVE_INTTYPES_H 1 > >> >>>>> > | #define HAVE_STDINT_H 1 > >> >>>>> > | #define HAVE_STRINGS_H 1 > >> >>>>> > | #define HAVE_SYS_STAT_H 1 > >> >>>>> > | #define HAVE_SYS_TYPES_H 1 > >> >>>>> > | #define HAVE_UNISTD_H 1 > >> >>>>> > | #define STDC_HEADERS 1 > >> >>>>> > | #define HAVE_LIBM 1 > >> >>>>> > | #define HAVE_CXX11 1 > >> >>>>> > | #define HAVE_GMP_H 1 > >> >>>>> > | #define ABSOLUTE_GMP_H "///opt/homebrew/include/gmp.h" > >> >>>>> > | #define HAVE_BOOST /**/ > >> >>>>> > | /* end confdefs.h. */ > >> >>>>> > | /* Define dgeqrf to an innocuous variant, in case <limits.h> > >> >>>>> > declares dgeqrf. > >> >>>>> > | For example, HP-UX 11i <limits.h> declares gettimeofday. */ > >> >>>>> > | #define dgeqrf innocuous_dgeqrf > >> >>>>> > | > >> >>>>> > | /* System header to define __stub macros and hopefully few > >> >>>>> > prototypes, > >> >>>>> > | which can conflict with char dgeqrf (void); below. */ > >> >>>>> > | > >> >>>>> > | #include <limits.h> > >> >>>>> > | #undef dgeqrf > >> >>>>> > | > >> >>>>> > | /* Override any GCC internal prototype to avoid an error. > >> >>>>> > | Use char because int might match the return type of a GCC > >> >>>>> > | builtin and then its argument prototype would still apply. */ > >> >>>>> > | #ifdef __cplusplus > >> >>>>> > | extern "C" > >> >>>>> > | #endif > >> >>>>> > | char dgeqrf (void); > >> >>>>> > | /* The GNU C library defines this for functions which it > >> >>>>> > implements > >> >>>>> > | to always fail with ENOSYS. Some functions are actually named > >> >>>>> > | something starting with __ and the normal name is an alias. */ > >> >>>>> > | #if defined __stub_dgeqrf || defined __stub___dgeqrf > >> >>>>> > | choke me > >> >>>>> > | #endif > >> >>>>> > | > >> >>>>> > | int > >> >>>>> > | main (void) > >> >>>>> > | { > >> >>>>> > | return dgeqrf (); > >> >>>>> > | ; > >> >>>>> > | return 0; > >> >>>>> > | } > >> >>>>> > configure:20044: result: no > >> >>>>> > configure:20051: checking for dgeqrf_ > >> >>>>> > configure:20051: g++ -std=gnu++11 -std=gnu++11 -o conftest > >> >>>>> > conftest.cpp -L/opt/homebrew/Cellar/openblas/0.3.29/lib -lopenblas > >> >>>>> > -lbz2 -lglpk -lgmp -lm >&5 > >> >>>>> > configure:20051: $? = 0 > >> >>>>> > configure:20051: result: yes > >> >>>>> > configure:20058: checking for DGEQRF > >> >>>>> > configure:20058: g++ -std=gnu++11 -std=gnu++11 -o conftest > >> >>>>> > conftest.cpp -L/opt/homebrew/Cellar/openblas/0.3.29/lib -lopenblas > >> >>>>> > -lbz2 -lglpk -lgmp -lm >&5 > >> >>>>> > Undefined symbols for architecture arm64: > >> >>>>> > "_DGEQRF", referenced from: > >> >>>>> > _main in conftest-8dfd93.o > >> >>>>> > ld: symbol(s) not found for architecture arm64 > >> >>>>> > clang++: error: linker command failed with exit code 1 (use -v to > >> >>>>> > see invocation) > >> >>>>> > configure:20058: $? = 1 > >> >>>>> > configure: failed program was: > >> >>>>> > | /* confdefs.h */ > >> >>>>> > | #define PACKAGE_NAME "Sage" > >> >>>>> > | #define PACKAGE_TARNAME "sage" > >> >>>>> > | #define PACKAGE_VERSION "10.6.beta7" > >> >>>>> > | #define PACKAGE_STRING "Sage 10.6.beta7" > >> >>>>> > | #define PACKAGE_BUGREPORT "[email protected]" > >> >>>>> > | #define PACKAGE_URL "" > >> >>>>> > | #define PACKAGE "sage" > >> >>>>> > | #define VERSION "10.6.beta7" > >> >>>>> > | #define HAVE_STDIO_H 1 > >> >>>>> > | #define HAVE_STDLIB_H 1 > >> >>>>> > | #define HAVE_STRING_H 1 > >> >>>>> > | #define HAVE_INTTYPES_H 1 > >> >>>>> > | #define HAVE_STDINT_H 1 > >> >>>>> > | #define HAVE_STRINGS_H 1 > >> >>>>> > | #define HAVE_SYS_STAT_H 1 > >> >>>>> > | #define HAVE_SYS_TYPES_H 1 > >> >>>>> > | #define HAVE_UNISTD_H 1 > >> >>>>> > | #define STDC_HEADERS 1 > >> >>>>> > | #define HAVE_LIBM 1 > >> >>>>> > | #define HAVE_CXX11 1 > >> >>>>> > | #define HAVE_GMP_H 1 > >> >>>>> > | #define ABSOLUTE_GMP_H "///opt/homebrew/include/gmp.h" > >> >>>>> > | #define HAVE_BOOST /**/ > >> >>>>> > | /* end confdefs.h. */ > >> >>>>> > | /* Define DGEQRF to an innocuous variant, in case <limits.h> > >> >>>>> > declares DGEQRF. > >> >>>>> > | For example, HP-UX 11i <limits.h> declares gettimeofday. */ > >> >>>>> > | #define DGEQRF innocuous_DGEQRF > >> >>>>> > | > >> >>>>> > | /* System header to define __stub macros and hopefully few > >> >>>>> > prototypes, > >> >>>>> > | which can conflict with char DGEQRF (void); below. */ > >> >>>>> > | > >> >>>>> > | #include <limits.h> > >> >>>>> > | #undef DGEQRF > >> >>>>> > | > >> >>>>> > | /* Override any GCC internal prototype to avoid an error. > >> >>>>> > | Use char because int might match the return type of a GCC > >> >>>>> > | builtin and then its argument prototype would still apply. */ > >> >>>>> > | #ifdef __cplusplus > >> >>>>> > | extern "C" > >> >>>>> > | #endif > >> >>>>> > | char DGEQRF (void); > >> >>>>> > | /* The GNU C library defines this for functions which it > >> >>>>> > implements > >> >>>>> > | to always fail with ENOSYS. Some functions are actually named > >> >>>>> > | something starting with __ and the normal name is an alias. */ > >> >>>>> > | #if defined __stub_DGEQRF || defined __stub___DGEQRF > >> >>>>> > | choke me > >> >>>>> > | #endif > >> >>>>> > | > >> >>>>> > | int > >> >>>>> > | main (void) > >> >>>>> > | { > >> >>>>> > | return DGEQRF (); > >> >>>>> > | ; > >> >>>>> > | return 0; > >> >>>>> > | } > >> >>>>> > configure:20058: result: no > >> >>>>> > configure:20065: checking for DGEQRF_ > >> >>>>> > configure:20065: g++ -std=gnu++11 -std=gnu++11 -o conftest > >> >>>>> > conftest.cpp -L/opt/homebrew/Cellar/openblas/0.3.29/lib -lopenblas > >> >>>>> > -lbz2 -lglpk -lgmp -lm >&5 > >> >>>>> > Undefined symbols for architecture arm64: > >> >>>>> > "_DGEQRF_", referenced from: > >> >>>>> > _main in conftest-ff1fe7.o > >> >>>>> > ld: symbol(s) not found for architecture arm64 > >> >>>>> > clang++: error: linker command failed with exit code 1 (use -v to > >> >>>>> > see invocation) > >> >>>>> > configure:20065: $? = 1 > >> >>>>> > configure: failed program was: > >> >>>>> > | /* confdefs.h */ > >> >>>>> > | #define PACKAGE_NAME "Sage" > >> >>>>> > | #define PACKAGE_TARNAME "sage" > >> >>>>> > | #define PACKAGE_VERSION "10.6.beta7" > >> >>>>> > | #define PACKAGE_STRING "Sage 10.6.beta7" > >> >>>>> > | #define PACKAGE_BUGREPORT "[email protected]" > >> >>>>> > | #define PACKAGE_URL "" > >> >>>>> > | #define PACKAGE "sage" > >> >>>>> > | #define VERSION "10.6.beta7" > >> >>>>> > | #define HAVE_STDIO_H 1 > >> >>>>> > | #define HAVE_STDLIB_H 1 > >> >>>>> > | #define HAVE_STRING_H 1 > >> >>>>> > | #define HAVE_INTTYPES_H 1 > >> >>>>> > | #define HAVE_STDINT_H 1 > >> >>>>> > | #define HAVE_STRINGS_H 1 > >> >>>>> > | #define HAVE_SYS_STAT_H 1 > >> >>>>> > | #define HAVE_SYS_TYPES_H 1 > >> >>>>> > | #define HAVE_UNISTD_H 1 > >> >>>>> > | #define STDC_HEADERS 1 > >> >>>>> > | #define HAVE_LIBM 1 > >> >>>>> > | #define HAVE_CXX11 1 > >> >>>>> > | #define HAVE_GMP_H 1 > >> >>>>> > | #define ABSOLUTE_GMP_H "///opt/homebrew/include/gmp.h" > >> >>>>> > | #define HAVE_BOOST /**/ > >> >>>>> > | /* end confdefs.h. */ > >> >>>>> > | /* Define DGEQRF_ to an innocuous variant, in case <limits.h> > >> >>>>> > declares DGEQRF_. > >> >>>>> > | For example, HP-UX 11i <limits.h> declares gettimeofday. */ > >> >>>>> > | #define DGEQRF_ innocuous_DGEQRF_ > >> >>>>> > | > >> >>>>> > | /* System header to define __stub macros and hopefully few > >> >>>>> > prototypes, > >> >>>>> > | which can conflict with char DGEQRF_ (void); below. */ > >> >>>>> > | > >> >>>>> > | #include <limits.h> > >> >>>>> > | #undef DGEQRF_ > >> >>>>> > | > >> >>>>> > | /* Override any GCC internal prototype to avoid an error. > >> >>>>> > | Use char because int might match the return type of a GCC > >> >>>>> > | builtin and then its argument prototype would still apply. */ > >> >>>>> > | #ifdef __cplusplus > >> >>>>> > | extern "C" > >> >>>>> > | #endif > >> >>>>> > | char DGEQRF_ (void); > >> >>>>> > | /* The GNU C library defines this for functions which it > >> >>>>> > implements > >> >>>>> > | to always fail with ENOSYS. Some functions are actually named > >> >>>>> > | something starting with __ and the normal name is an alias. */ > >> >>>>> > | #if defined __stub_DGEQRF_ || defined __stub___DGEQRF_ > >> >>>>> > | choke me > >> >>>>> > | #endif > >> >>>>> > | > >> >>>>> > | int > >> >>>>> > | main (void) > >> >>>>> > | { > >> >>>>> > | return DGEQRF_ (); > >> >>>>> > | ; > >> >>>>> > | return 0; > >> >>>>> > | } > >> >>>>> > configure:20065: result: no > >> >>>>> > configure:20157: checking the OpenBLAS version using > >> >>>>> > openblas_get_config > >> >>>>> > configure:20185: gcc -o conftest > >> >>>>> > -I/opt/homebrew/Cellar/openblas/0.3.29/include -fopenmp -g -O2 > >> >>>>> > conftest.c -L/opt/homebrew/Cellar/openblas/0.3.29/lib -lopenblas > >> >>>>> > -lbz2 -lglpk -lgmp -lm >&5 > >> >>>>> > clang: error: unsupported option '-fopenmp' > >> >>>>> > clang: error: unsupported option '-fopenmp' > >> >>>>> > configure:20185: $? = 1 > >> >>>>> > configure: program exited with status 1 > >> >>>>> > configure: failed program was: > >> >>>>> > | /* confdefs.h */ > >> >>>>> > | #define PACKAGE_NAME "Sage" > >> >>>>> > | #define PACKAGE_TARNAME "sage" > >> >>>>> > | #define PACKAGE_VERSION "10.6.beta7" > >> >>>>> > | #define PACKAGE_STRING "Sage 10.6.beta7" > >> >>>>> > | #define PACKAGE_BUGREPORT "[email protected]" > >> >>>>> > | #define PACKAGE_URL "" > >> >>>>> > | #define PACKAGE "sage" > >> >>>>> > | #define VERSION "10.6.beta7" > >> >>>>> > | #define HAVE_STDIO_H 1 > >> >>>>> > | #define HAVE_STDLIB_H 1 > >> >>>>> > | #define HAVE_STRING_H 1 > >> >>>>> > | #define HAVE_INTTYPES_H 1 > >> >>>>> > | #define HAVE_STDINT_H 1 > >> >>>>> > | #define HAVE_STRINGS_H 1 > >> >>>>> > | #define HAVE_SYS_STAT_H 1 > >> >>>>> > | #define HAVE_SYS_TYPES_H 1 > >> >>>>> > | #define HAVE_UNISTD_H 1 > >> >>>>> > | #define STDC_HEADERS 1 > >> >>>>> > | #define HAVE_LIBM 1 > >> >>>>> > | #define HAVE_CXX11 1 > >> >>>>> > | #define HAVE_GMP_H 1 > >> >>>>> > | #define ABSOLUTE_GMP_H "///opt/homebrew/include/gmp.h" > >> >>>>> > | #define HAVE_BOOST /**/ > >> >>>>> > | /* end confdefs.h. */ > >> >>>>> > | #include <string.h> > >> >>>>> > | char *openblas_get_config(void); > >> >>>>> > | int > >> >>>>> > | main (void) > >> >>>>> > | { > >> >>>>> > | if (!strncmp(openblas_get_config(), "OpenBLAS 0.3.22", 15)) > >> >>>>> > return 1; > >> >>>>> > | ; > >> >>>>> > | return 0; > >> >>>>> > | } > >> >>>>> > | > >> >>>>> > configure:20191: result: known bad version > >> >>>>> > configure:20261: no suitable system package found for SPKG openblas > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> > > >> >>>>> > On Tuesday, February 25, 2025 at 7:36:27 PM UTC+1 Dima Pasechnik > >> >>>>> > wrote: > >> >>>>> >> > >> >>>>> >> On Tue, Feb 25, 2025 at 12:03 PM [email protected] > >> >>>>> >> <[email protected]> wrote: > >> >>>>> >> > > >> >>>>> >> > I agree that we should use as many homebrew packages as > >> >>>>> >> > possible, but how can we ensure that we follow the upgrades ? > >> >>>>> >> > For instance the versions of openblas (0.3.29), gsl (2.8), > >> >>>>> >> > numpy (2.2.3), scipy (1.15.2) and pari (2.17.1) are newer on > >> >>>>> >> > homebrew than what we accept. > >> >>>>> >> > >> >>>>> >> Because the update of pari is stalled due to a bug reported? > >> >>>>> >> A Pari expert should step up and tell whether it's an upstream > >> >>>>> >> bug, or not. > >> >>>>> >> https://github.com/sagemath/sage/pull/38749 > >> >>>>> >> > >> >>>>> >> openblas (of any version less than 0.3.99) should be accepted, > >> >>>>> >> provided it is recognised by pkg-config > >> >>>>> >> (you'd need to run source .homebrew-build-env for the latter). > >> >>>>> >> Same applies to gsl. > >> >>>>> >> > >> >>>>> >> numpy and scipy are Python packages, you need > >> >>>>> >> > >> >>>>> >> ./configure --enable-system-site-packages > >> >>>>> >> > >> >>>>> >> to have them from "outside". > >> >>>>> >> There are no version constraints on them imposed. > >> >>>>> >> I have a meanwhile bitrotten PR to upgrade numpy and scipy, and > >> >>>>> >> despite requesting review from 5 people, only two responded. > >> >>>>> >> https://github.com/sagemath/sage/pull/38846, back in Oct 2024. > >> >>>>> >> Then reviewers just disappeared there... > >> >>>>> >> Some of these updates are now in separate PRs. Some need to be > >> >>>>> >> done. > >> >>>>> >> > >> >>>>> >> See, that's what I mean by "Sage has too many vendored packages". > >> >>>>> >> These packages are bog-standard PyPI packages, we could have > >> >>>>> >> followed > >> >>>>> >> the new versions if we didn't have this so beloved by some version > >> >>>>> >> locks. > >> >>>>> >> > >> >>>>> >> Dima > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> >> > > >> >>>>> >> > I'm currently facing the following issue: > >> >>>>> >> > ipykernel fails to compile and reports that it is unable to > >> >>>>> >> > find jupyter_core. But configure says: > >> >>>>> >> > jupyter_core: using system package; SPKG will not be installed > >> >>>>> >> > > >> >>>>> >> > I'm currently trying to compile from scratch with > >> >>>>> >> > --with-system-jupyter_core=no. We'll see if it's better. > >> >>>>> >> > > >> >>>>> >> > On Tuesday, February 25, 2025 at 6:16:24 PM UTC+1 John H > >> >>>>> >> > Palmieri wrote: > >> >>>>> >> >> > >> >>>>> >> >> Maybe this is naive, but if you're testing a change from the > >> >>>>> >> >> old situation, where Python 3.13 was not allowed, to now > >> >>>>> >> >> allowing it, I might imagine that you would test it on > >> >>>>> >> >> standard supported platforms, like OS X with Python 3.13 > >> >>>>> >> >> installed via homebrew. We should back out the change until > >> >>>>> >> >> it's implemented correctly. > >> >>>>> >> >> > >> >>>>> >> >> > >> >>>>> >> >> On Tuesday, February 25, 2025 at 6:46:41 AM UTC-8 Dima > >> >>>>> >> >> Pasechnik wrote: > >> >>>>> >> >>> > >> >>>>> >> >>> > >> >>>>> >> >>> > >> >>>>> >> >>> On 24 February 2025 23:52:36 GMT-06:00, John H Palmieri > >> >>>>> >> >>> <[email protected]> wrote: > >> >>>>> >> >>> >Sage should work out of the box without > >> >>>>> >> >>> >"--enable-system-site-packages". > >> >>>>> >> >>> > >> >>>>> >> >>> > >> >>>>> >> >>> The box has become so heavy that one needs a forklift to do > >> >>>>> >> >>> anything with it :-) > >> >>>>> >> >>> > >> >>>>> >> >>> > >> >>>>> >> >>> > If > >> >>>>> >> >>> >it doesn't, that's a bug in Sage. How about we don't allow > >> >>>>> >> >>> >Python 3.13 if > >> >>>>> >> >>> >it's broken? Why wasn't this caught in testing? > >> >>>>> >> >>> > >> >>>>> >> >>> well, Sage with Python 3.13 works on Linux, > >> >>>>> >> >>> and is default on some. > >> >>>>> >> >>> > >> >>>>> >> >>> It appears that there are dozens of macOS/apple > >> >>>>> >> >>> toolchain/apple hardware combos, and each of them has its > >> >>>>> >> >>> very own set of bugs, misfeatures, multiple dodgy Python > >> >>>>> >> >>> installs, etc. > >> >>>>> >> >>> > >> >>>>> >> >>> We can't possibly test for all of them. > >> >>>>> >> >>> > >> >>>>> >> >>> And please don't force on Sage developers the need to dig up > >> >>>>> >> >>> and reproduce solutions by Homebrew, which has 10 times more > >> >>>>> >> >>> developers and nontrivial funding, solutions which are > >> >>>>> >> >>> already there. > >> >>>>> >> >>> > >> >>>>> >> >>> What's wrong with using the flag above, if it works? > >> >>>>> >> >>> > >> >>>>> >> >>> I hope William S. forgives me if I quote his up to date > >> >>>>> >> >>> opinion on Macs: > >> >>>>> >> >>> > >> >>>>> >> >>> ----- > >> >>>>> >> >>> For me, Macs are reasonable as basically "Chromebooks" that > >> >>>>> >> >>> can also > >> >>>>> >> >>> run Linux VM's pretty well and keep track of photos and > >> >>>>> >> >>> video. Beyond > >> >>>>> >> >>> that it's extremely painful, and I vastly prefer Linux for > >> >>>>> >> >>> all things > >> >>>>> >> >>> dev/server/remote. > >> >>>>> >> >>> ----- > >> >>>>> >> >>> > >> >>>>> >> >>> My opinion is similar - except that the only use of Mac I > >> >>>>> >> >>> have is to cause myself extreme pain by trying to fix never > >> >>>>> >> >>> ending macOS - specific > >> >>>>> >> >>> issues. > >> >>>>> >> >>> > >> >>>>> >> >>> On macOS, either we embrace Homebrew and use it to get > >> >>>>> >> >>> external dependencies, or we use Conda. Current "build > >> >>>>> >> >>> everything from ground up" has become next to impossible in > >> >>>>> >> >>> any reliable way. > >> >>>>> >> >>> > >> >>>>> >> >>> > >> >>>>> >> >>> Dima > >> >>>>> >> >>> > >> >>>>> >> >>> > >> >>>>> >> >>> > > >> >>>>> >> >>> > > >> >>>>> >> >>> >On Monday, February 24, 2025 at 7:34:13 PM UTC-8 Dima > >> >>>>> >> >>> >Pasechnik wrote: > >> >>>>> >> >>> > > >> >>>>> >> >>> >> On Mon, Feb 24, 2025 at 5:44 PM John H Palmieri > >> >>>>> >> >>> >> <[email protected]> > >> >>>>> >> >>> >> wrote: > >> >>>>> >> >>> >> > > >> >>>>> >> >>> >> > On OS X 15.3.1 with many homebrew packages installed, > >> >>>>> >> >>> >> > including both > >> >>>>> >> >>> >> Python 3.12 and Python 3.13: > >> >>>>> >> >>> >> > > >> >>>>> >> >>> >> > - if I use Python 3.13, `pillow` and `cffi` fail to > >> >>>>> >> >>> >> > build. (I used > >> >>>>> >> >>> >> "./configure", and I also tried after applying the patch > >> >>>>> >> >>> >> from #39570) > >> >>>>> >> >>> >> > >> >>>>> >> >>> >> how about using installing pillow and cffi in Homebrew, > >> >>>>> >> >>> >> and doing > >> >>>>> >> >>> >> > >> >>>>> >> >>> >> ./configure --enable-system-site-packages > >> >>>>> >> >>> >> > >> >>>>> >> >>> >> This should pick them from Homebrew. (If it doesn't it's a > >> >>>>> >> >>> >> Sage bug I > >> >>>>> >> >>> >> suppose) > >> >>>>> >> >>> >> > >> >>>>> >> >>> >> Frankly speaking I am less than excited to try to figure > >> >>>>> >> >>> >> out what goes > >> >>>>> >> >>> >> wrong in sdh_pip_install > >> >>>>> >> >>> >> in this case. Homebrew can do it... > >> >>>>> >> >>> >> > >> >>>>> >> >>> >> > - if I use Python 3.12, then `pillow` and `cffi` and > >> >>>>> >> >>> >> > indeed everything > >> >>>>> >> >>> >> builds successfully. (I used "./configure > >> >>>>> >> >>> >> --with-python=`which python3.12`") > >> >>>>> >> >>> >> > > >> >>>>> >> >>> >> > > >> >>>>> >> >>> >> > On Friday, February 21, 2025 at 3:40:17 PM UTC-8 Volker > >> >>>>> >> >>> >> > Braun wrote: > >> >>>>> >> >>> >> >> > >> >>>>> >> >>> >> >> As always, you can get the latest beta version from the > >> >>>>> >> >>> >> >> "develop" git > >> >>>>> >> >>> >> branch. Alternatively, the self-contained source tarball > >> >>>>> >> >>> >> is at > >> >>>>> >> >>> >> http://www.sagemath.org/download-latest.html > >> >>>>> >> >>> >> >> > >> >>>>> >> >>> >> >> > >> >>>>> >> >>> >> >> 9cd86e9596a (tag: 10.6.beta7, github/develop) Updated > >> >>>>> >> >>> >> >> SageMath version > >> >>>>> >> >>> >> to 10.6.beta7 > >> >>>>> >> >>> >> >> c2766d1f625 gh-39541: Remove dead mailing lists. > >> >>>>> >> >>> >> >> 54951498178 gh-39536: Fix a nonfunctional long time > >> >>>>> >> >>> >> >> doctest tag > >> >>>>> >> >>> >> >> 5289298248a gh-39533: build/pkgs: update eclib to > >> >>>>> >> >>> >> >> version 20250122 > >> >>>>> >> >>> >> >> 7420a272382 gh-39530: Improvement to flint_autogen > >> >>>>> >> >>> >> >> reader > >> >>>>> >> >>> >> >> cee1e2b52f9 gh-39527: Test on CI that update-meson is > >> >>>>> >> >>> >> >> properly ran > >> >>>>> >> >>> >> >> a007379b910 gh-39523: multi polynomial element/repr > >> >>>>> >> >>> >> >> 850493472d5 gh-39521: rename also set-like species > >> >>>>> >> >>> >> >> bd626efc02f gh-39518: line_graph for multigraphs > >> >>>>> >> >>> >> >> 72c6188116a gh-39513: Show test failures of ci-meson as > >> >>>>> >> >>> >> >> annotations > >> >>>>> >> >>> >> >> 4f4c1203415 gh-39510: add of the function > >> >>>>> >> >>> >> >> rank_support_of_vector > >> >>>>> >> >>> >> >> 2af3de6fa6e gh-39509: Add a doctest for > >> >>>>> >> >>> >> HomsetsCategory._make_named_class_key > >> >>>>> >> >>> >> >> d8b7cdfcecb gh-39508: Fix some typo > >> >>>>> >> >>> >> >> b567299fbbb gh-39506: New algorithm for cuts of a Poset > >> >>>>> >> >>> >> >> 88672d71a29 gh-39505: Improve handling of strings > >> >>>>> >> >>> >> >> supplied as matrix > >> >>>>> >> >>> >> entries > >> >>>>> >> >>> >> >> 935232df552 gh-39504: Implement im_gens in the class > >> >>>>> >> >>> >> >> fraction_field_FpT > >> >>>>> >> >>> >> >> a01815fda00 gh-39499: Improve sage_getfile by looking > >> >>>>> >> >>> >> >> at __init__ > >> >>>>> >> >>> >> >> b7da8f23c43 gh-39498: Apply sort and filter of > >> >>>>> >> >>> >> >> walk_packages > >> >>>>> >> >>> >> consistently > >> >>>>> >> >>> >> >> 3500f616037 gh-39497: moving random_element to category > >> >>>>> >> >>> >> >> of rings > >> >>>>> >> >>> >> >> e368fa71812 gh-39496: Add deformation cones and > >> >>>>> >> >>> >> >> checking for regularity > >> >>>>> >> >>> >> for Point Configurations and normal fans of Polyhedra > >> >>>>> >> >>> >> >> 8978ff83f52 gh-39495: Add documentation of Gabidulin > >> >>>>> >> >>> >> >> codes in the > >> >>>>> >> >>> >> reference manual > >> >>>>> >> >>> >> >> 98eec5d86fe gh-39494: Fix more doctests in > >> >>>>> >> >>> >> >> meson_editable install > >> >>>>> >> >>> >> >> cfbaaf16be2 gh-39491: fixing doctests failures in > >> >>>>> >> >>> >> >> misc/latex*.py > >> >>>>> >> >>> >> >> a2737325c19 gh-39489: fix several oeis related doctests > >> >>>>> >> >>> >> >> 8a44c7365b7 gh-39488: Fix issue on matrix construction > >> >>>>> >> >>> >> >> over integer mod > >> >>>>> >> >>> >> ring for large coefficients > >> >>>>> >> >>> >> >> 78a3eede92c gh-39487: Improvement of the rendering of > >> >>>>> >> >>> >> >> the documentation > >> >>>>> >> >>> >> in polynomial sequence > >> >>>>> >> >>> >> >> 34b7f9050fb gh-39486: Finish changing Rational's round > >> >>>>> >> >>> >> >> method default > >> >>>>> >> >>> >> rounding to even > >> >>>>> >> >>> >> >> 04afcf71552 gh-39485: Implement conversion from laurent > >> >>>>> >> >>> >> >> series to > >> >>>>> >> >>> >> rational function field > >> >>>>> >> >>> >> >> ae158663847 gh-39482: fix one typo > >> >>>>> >> >>> >> >> 83f7d065286 gh-39481: Fixed issue in list_plot where it > >> >>>>> >> >>> >> >> assumed data > >> >>>>> >> >>> >> had been enumerated when it might not have been > >> >>>>> >> >>> >> >> 8e204dde3b3 gh-39479: Fixed crash when exp(0) of p-adic > >> >>>>> >> >>> >> >> numbers is > >> >>>>> >> >>> >> called > >> >>>>> >> >>> >> >> 11ee7ca4e19 gh-39477: typing and details in tableaux > >> >>>>> >> >>> >> >> files > >> >>>>> >> >>> >> >> c61e562de76 gh-39476: typing annotation for gens method > >> >>>>> >> >>> >> >> in rings and > >> >>>>> >> >>> >> groups (pyx files) > >> >>>>> >> >>> >> >> 85ce297ff2c gh-39474: convert gens method in modular to > >> >>>>> >> >>> >> >> return tuple > >> >>>>> >> >>> >> >> c732c6552e4 gh-39473: add tuple typing to gens methods > >> >>>>> >> >>> >> >> in algebras > >> >>>>> >> >>> >> >> 556d5f0eb80 gh-39466: remove some deprecations in groups > >> >>>>> >> >>> >> >> c22e48480c3 gh-39456: Trivial simplifications for arccos > >> >>>>> >> >>> >> >> 68744be391e gh-39454: remove deprecated stuff in > >> >>>>> >> >>> >> >> permutation.py > >> >>>>> >> >>> >> >> 784ff00867a gh-39449: Magma padics > >> >>>>> >> >>> >> >> 897e722c74e gh-39423: Use import_module instead of > >> >>>>> >> >>> >> >> find_spec > >> >>>>> >> >>> >> >> 870aba20786 gh-39397: details in braid groups > >> >>>>> >> >>> >> >> e6975bebe80 gh-39381: Allow system python 3.13 > >> >>>>> >> >>> >> >> b57e33797cf gh-39366: Add documentation to > >> >>>>> >> >>> >> >> LaurentSeries point to > >> >>>>> >> >>> >> accessors > >> >>>>> >> >>> >> >> 357f95e088c gh-39365: Allow coercion from Frac(QQ[x]) to > >> >>>>> >> >>> >> LaurentSeriesRing(QQ) > >> >>>>> >> >>> >> >> 041336691f6 gh-39266: add parameter immutable to > >> >>>>> >> >>> >> >> generators in > >> >>>>> >> >>> >> `sage/graphs/digraph_generators.py` (part 2) > >> >>>>> >> >>> >> >> e0806107d60 gh-39251: Require Python 3.11 or newer; > >> >>>>> >> >>> >> >> remove outdated > >> >>>>> >> >>> >> workarounds > >> >>>>> >> >>> >> >> ac8406fba6a gh-39248: introduce new apozeta polynomial > >> >>>>> >> >>> >> >> for posets > >> >>>>> >> >>> >> >> 10edc54de0a gh-39215: Class polynomial for Drinfeld > >> >>>>> >> >>> >> >> modules > >> >>>>> >> >>> >> >> 2e0d6d201bf gh-39214: Add keyword prec for exponential > >> >>>>> >> >>> >> >> and logarithm of > >> >>>>> >> >>> >> Drinfeld modules > >> >>>>> >> >>> >> >> b5c26156430 gh-39212: Refactor period lattice > >> >>>>> >> >>> >> >> d0e72a61433 gh-39128: Add note about makeflags and > >> >>>>> >> >>> >> >> ninja parallelism > >> >>>>> >> >>> >> >> 067ebbd0c8c gh-39093: Improve hack used in debug_options > >> >>>>> >> >>> >> >> a89c57b64f8 gh-39092: Remove erroneous member > >> >>>>> >> >>> >> >> declaration in > >> >>>>> >> >>> >> farey_symbol > >> >>>>> >> >>> >> >> cc231ef0353 gh-39061: Fix some errors in documentation > >> >>>>> >> >>> >> >> of cachefunc > >> >>>>> >> >>> >> >> f0581cbe397 gh-39025: Add reseed_rng option to > >> >>>>> >> >>> >> >> p_iter_fork > >> >>>>> >> >>> >> >> 290b261bc4f gh-38986: Allow CRT_list() to be called > >> >>>>> >> >>> >> >> with one argument > >> >>>>> >> >>> >> >> 0a278fc918e gh-38824: Turn some doctests in > >> >>>>> >> >>> >> >> `ell_rational_field.py` > >> >>>>> >> >>> >> into long tests > >> >>>>> >> >>> >> >> c43cd23ee83 gh-38650: Add support for pseudomorphisms > >> >>>>> >> >>> >> >> 6e82ee51eb9 gh-38108: Implicit function solver for lazy > >> >>>>> >> >>> >> >> series > >> >>>>> >> >>> >> >> 42d00ed27b3 gh-37173: Implemented `.ramified_places` > >> >>>>> >> >>> >> >> and modified > >> >>>>> >> >>> >> further methods to extend quaternion algebra functionality > >> >>>>> >> >>> >> to number fields > >> >>>>> >> >>> >> >> 8d7107c1aab gh-37158: use Parent in quotient rings too > >> >>>>> >> >>> >> >> 766c7a0c5b8 (tag: 10.6.beta6) Updated SageMath version > >> >>>>> >> >>> >> >> to 10.6.beta6 > >> >>>>> >> >>> >> > > >> >>>>> >> >>> >> > -- > >> >>>>> >> >>> >> > You received this message because you are subscribed to > >> >>>>> >> >>> >> > the Google > >> >>>>> >> >>> >> Groups "sage-release" group. > >> >>>>> >> >>> >> > To unsubscribe from this group and stop receiving emails > >> >>>>> >> >>> >> > from it, send > >> >>>>> >> >>> >> an email to [email protected]. > >> >>>>> >> >>> >> > To view this discussion visit > >> >>>>> >> >>> >> https://groups.google.com/d/msgid/sage-release/aa27984d-e9b6-4eb4-b4a1-a422672e26a6n%40googlegroups.com > >> >>>>> >> >>> >> . > >> >>>>> >> >>> >> > >> >>>>> >> >>> > > >> >>>>> >> > > >> >>>>> >> > -- > >> >>>>> >> > You received this message because you are subscribed to the > >> >>>>> >> > Google Groups "sage-release" group. > >> >>>>> >> > To unsubscribe from this group and stop receiving emails from > >> >>>>> >> > it, send an email to [email protected]. > >> >>>>> >> > To view this discussion visit > >> >>>>> >> > https://groups.google.com/d/msgid/sage-release/2c938919-99f9-49e2-865e-6bcc011a0098n%40googlegroups.com. > >> >>>>> > > >> >>>>> > -- > >> >>>>> > You received this message because you are subscribed to the Google > >> >>>>> > Groups "sage-release" group. > >> >>>>> > To unsubscribe from this group and stop receiving emails from it, > >> >>>>> > send an email to [email protected]. > >> >>>>> > To view this discussion visit > >> >>>>> > https://groups.google.com/d/msgid/sage-release/c631ea8b-7c97-433f-9aa6-bf39686332b7n%40googlegroups.com. > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "sage-release" group. > >> > To unsubscribe from this group and stop receiving emails from it, send > >> > an email to [email protected]. > >> > To view this discussion visit > >> > https://groups.google.com/d/msgid/sage-release/93906b68-a7ce-40eb-a879-b2978dee1fb0n%40googlegroups.com. > >> > >> -- > >> You received this message because you are subscribed to a topic in the > >> Google Groups "sage-release" group. > >> To unsubscribe from this topic, visit > >> https://groups.google.com/d/topic/sage-release/8u71odPIXD8/unsubscribe. > >> To unsubscribe from this group and all its topics, send an email to > >> [email protected]. > >> To view this discussion visit > >> https://groups.google.com/d/msgid/sage-release/CAAWYfq2MxfW1_XoqtKCdv7Vnp0m4jVAdC68pTwCxAN9WvbN0-w%40mail.gmail.com. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sage-release" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > To view this discussion visit > > https://groups.google.com/d/msgid/sage-release/CALcZXRGRoDSP7DoU8p%3DhyBVxTTHAnB%3DpQzVsjK6hp26mp%2BHz2g%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "sage-release" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-release/CAAWYfq1dJRp69%3DRGBZBhTr2cydchD-LLQ-X7OQK7CQ2jGd4L5Q%40mail.gmail.com.
