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/aece5130-39a8-4db0-b4bb-4680f2db4174n%40googlegroups.com.

Reply via email to