GNU bug report logs -
#75751
Request for merging "python-team" branch
Previous Next
Reported by: Ricardo Wurmus <rekado <at> elephly.net>
Date: Wed, 22 Jan 2025 09:10:03 UTC
Severity: normal
Done: Sharlatan Hellseher <sharlatanus <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75751 in the body.
You can then email your comments to 75751 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
lars <at> 6xq.net, marius <at> gnu.org, me <at> bonfacemunyoki.com, sharlatanus <at> gmail.com, tanguy <at> bioneland.org, jgart <at> dismail.de, guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 22 Jan 2025 09:10:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ricardo Wurmus <rekado <at> elephly.net>:
New bug report received and forwarded. Copy sent to
lars <at> 6xq.net, marius <at> gnu.org, me <at> bonfacemunyoki.com, sharlatanus <at> gmail.com, tanguy <at> bioneland.org, jgart <at> dismail.de, guix-patches <at> gnu.org.
(Wed, 22 Jan 2025 09:10:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Guix,
This marks the beginning of work on the next iteration of the
python-team branch.
Goals:
- add Python 3.11 and make it the default
- update python-numpy and co to the latest 1.x release.
Let's try to keep this a *short* iteration. I'd love to merge this
within a month, i.e. before the end of February 2025.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sun, 26 Jan 2025 09:49:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 75751 <at> debbugs.gnu.org (full text, mbox):
What do you think about adding libxcrypt to python-3.11? The
unmaintained but still influential python-passlib fails to detect
support for some crypt() primitives, and I think we can fix this by
building python-3.11 with libxcrypt support.
We build Python 3.10 (as well as Python 2) with libxcrypt support.
If there are no objections I'll make the change tonight which will
trigger a world rebuild.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sun, 26 Jan 2025 10:32:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I think if it helps fix many builds with less action it's good.
Having attempt to refresh python-frozenlist and fix the build to the latest
failed, slightly bumped it which fix it
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=python-team&id=faa91e1f47ff972359fea9826c796cada61b1828
It complains on missing headers not shipping with 3.11
Oleg
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sun, 26 Jan 2025 11:25:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Hi Oleg,
> It complains on missing headers not shipping with 3.11
What headers are those and how could we provide them?
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sun, 26 Jan 2025 18:35:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ricardo,
This one:
--8<---------------cut here---------------start------------->8---
fatal error: 'longintrepr.h' file not found
--8<---------------cut here---------------end--------------->8---
It was late night, not sure which package I've seen that.
Quick search gave me this hint - it was removed in Python3.11 <https://stackoverflow.com/questions/74979674/gensim-install-in-python-3-11-fails-because-of-missing-longintrepr-h-file>
On the bright side the path to python-astropy is clear and I could build
it on 6.1.7 version, 7.0.0 requires bunch a lot fresh versions of NumPy,
PyYAML, Packaging, Pandas and Matplotlib.
<https://github.com/astropy/astropy/blob/v7.0.0/CHANGES.rst#other-changes-and-additions>
Some action list for the packages with most inputs:
--8<---------------cut here---------------start------------->8---
71 python-pytorch <at> 2.0.1
67 python-pytorch-avx <at> 2.4.0
65 python-pytorch <at> 2.4.0
65 diffoscope <at> 284
64 python-nbconvert <at> 7.16.4
58 python-sphinx <at> 4.5.0
56 python-sphinx <at> 6.2.1
54 calibre <at> 5.44.0
52 python-sphinx <at> 5.3.0
45 gajim-omemo <at> 1.9.3
45 gajim <at> 1.9.3
41 python-matplotlib-documentation <at> 3.8.2
40 xpra <at> 6.2.1
39 synapse <at> 1.29.0
39 python-jwst <at> 1.16.1
36 python-sunpy <at> 6.0.3
34 python-astropy <at> 6.1.6
34 orange <at> 3.32.0
34 beets <at> 2.0.0
33 rapid-photo-downloader <at> 0.9.18
33 python-scanpy <at> 1.9.6
33 poetry <at> 1.8.4
33 conan <at> 2.0.9
32 python-papermill <at> 2.6.0
31 snakemake <at> 7.7.0
31 quodlibet <at> 4.5.0
31 hydrus-network <at> 495
30 python-yt <at> 4.4.0
30 python-scipy <at> 1.12.0
30 python-sanic <at> 23.12.1
30 python-pytorch-lightning <at> 2.3.3-0.2064887
29 snakemake <at> 6.15.5
29 python-huggingface-hub <at> 0.23.2
29 python-angr <at> 9.2.112
29 fanc <at> 0-1.354401e
29 datasette <at> 1.0a7
28 python-rpy2 <at> 3.5.17
28 python-pytorch-geometric <at> 2.4.0
28 python-pyarrow <at> 0.16.0
28 python-moto <at> 4.2.4
28 pyscenic <at> 0.11.2-1.5f170fd
27 python-scrapy <at> 2.11.2
27 python-pyarrow <at> 17.0.0
27 python-nbclassic <at> 1.0.0
27 python-matplotlib <at> 3.8.2
27 python-keystoneclient <at> 5.0.0
27 python-jupyter-server <at> 2.14.0
27 python-hicexplorer <at> 3.7.4
27 python-baltica <at> 1.1.2
27 python-anndata <at> 0.10.7
--8<---------------cut here---------------end--------------->8---
--
Thanks,
Oleg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sun, 26 Jan 2025 20:47:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ricardo Wurmus <rekado <at> elephly.net> writes:
> What do you think about adding libxcrypt to python-3.11? The
> unmaintained but still influential python-passlib fails to detect
> support for some crypt() primitives, and I think we can fix this by
> building python-3.11 with libxcrypt support.
>
> We build Python 3.10 (as well as Python 2) with libxcrypt support.
>
> If there are no objections I'll make the change tonight which will
> trigger a world rebuild.
I'm still building a large number of Rust packages locally to see if
the change has any impact on python-passlib.
The diff I'm testing is here:
[python-xcrypt.patch (text/x-patch, inline)]
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 0c5acfcc98..e2349f0424 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -692,9 +692,9 @@ (define-public python-3.11
(list
#:test-target "test"
#:configure-flags
- #~(list "--enable-shared" ;allow embedding
- "--with-system-expat" ;for XML support
- "--with-system-ffi" ;build ctypes
+ #~(list "--enable-shared" ;allow embedding
+ "--with-system-expat" ;for XML support
+ "--with-system-ffi" ;build ctypes
"--with-ensurepip=install" ;install pip and setuptools
"--with-computed-gotos" ;main interpreter loop optimization
"--enable-unicode=ucs4"
@@ -711,6 +711,20 @@ (define-public python-3.11
"INSTALL=install -c"
"MKDIR_P=mkdir -p"
+ ;; Add a reference to libxcrypt in LIBS so that the
+ ;; sysconfigdata file records it and propagates it to programs
+ ;; linking against Python.
+ (let ((libxcrypt
+ (false-if-exception
+ (dirname
+ (search-input-file %build-inputs
+ "lib/libcrypt.so.1")))))
+ (string-append
+ "LIBS="
+ (if libxcrypt
+ (string-append "-L" libxcrypt)
+ "")))
+
;; Disable runtime check failing if cross-compiling, see:
;; https://lists.yoctoproject.org/pipermail/poky/2013-June/008997.html
#$@(if (%current-target-system)
@@ -790,229 +804,236 @@ (define-public python-3.11
(guix build gnu-build-system))
#:phases
- `(modify-phases %standard-phases
- ,@(if (system-hurd?)
- `((add-after 'unpack
- 'disable-multi-processing
- (lambda _
- (substitute* "Makefile.pre.in"
- (("-j0")
- "-j1")))))
- '())
- (add-before 'configure 'patch-lib-shells
- (lambda _
- ;; This variable is used in setup.py to enable cross compilation
- ;; specific switches. As it is not set properly by configure
- ;; script, set it manually.
- ,@(if (%current-target-system)
- '((setenv "_PYTHON_HOST_PLATFORM" ""))
- '())
- ;; Filter for existing files, since some may not exist in all
- ;; versions of python that are built with this recipe.
- (substitute* (filter file-exists?
- '("Lib/subprocess.py"
- "Lib/popen2.py"
- "Lib/distutils/tests/test_spawn.py"
- "Lib/test/support/__init__.py"
- "Lib/test/test_subprocess.py"))
- (("/bin/sh")
- (which "sh")))))
- (add-before 'configure 'do-not-record-configure-flags
- (lambda* (#:key configure-flags #:allow-other-keys)
- ;; Remove configure flags from the installed '_sysconfigdata.py'
- ;; and 'Makefile' so we don't end up keeping references to the
- ;; build tools.
- ;;
- ;; Preserve at least '--with-system-ffi' since otherwise the
- ;; thing tries to build libffi, fails, and we end up with a
- ;; Python that lacks ctypes.
- (substitute* "configure"
- (("^CONFIG_ARGS=.*$")
- (format #f "CONFIG_ARGS='~a'\n"
- (if (member "--with-system-ffi"
- configure-flags)
- "--with-system-ffi" ""))))))
- (add-before 'check 'pre-check
- (lambda _
- ;; 'Lib/test/test_site.py' needs a valid $HOME
- (setenv "HOME"
- (getcwd))))
- (add-after 'unpack 'set-source-file-times-to-1980
- ;; XXX One of the tests uses a ZIP library to pack up some of the
- ;; source tree, and fails with "ZIP does not support timestamps
- ;; before 1980". Work around this by setting the file times in the
- ;; source tree to sometime in early 1980.
- (lambda _
- (let ((circa-1980 (* 10 366 24 60 60)))
- (ftw "."
- (lambda (file stat flag)
- (utime file circa-1980 circa-1980) #t)))))
- (add-after 'unpack 'remove-windows-binaries
- (lambda _
- ;; Delete .exe from embedded .whl (zip) files
- (for-each (lambda (whl)
- (let ((dir "whl-content")
- (circa-1980 (* 10 366 24 60 60)))
- (mkdir-p dir)
- (with-directory-excursion dir
- (let ((whl (string-append "../" whl)))
- (invoke "unzip" whl)
- (for-each delete-file
- (find-files "." "\\.exe$"))
- (delete-file whl)
- ;; Reset timestamps to prevent them from ending
- ;; up in the Zip archive.
- (ftw "."
- (lambda (file stat flag)
- (utime file circa-1980
- circa-1980) #t))
- (apply invoke "zip" "-X" whl
- (find-files "."
- #:directories? #t))))
- (delete-file-recursively dir)))
- (find-files "Lib/ensurepip" "\\.whl$"))))
- (add-after 'install 'remove-tests
- ;; Remove 25 MiB of unneeded unit tests. Keep test_support.*
- ;; because these files are used by some libraries out there.
- (lambda* (#:key outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "out")))
- (match (scandir (string-append out "/lib")
- (lambda (name)
- (string-prefix? "python" name)))
- ((pythonX.Y)
- (let ((testdir (string-append out "/lib/" pythonX.Y
- "/test")))
- (with-directory-excursion testdir
- (for-each delete-file-recursively
- (scandir testdir
- (match-lambda
- ((or "." "..")
- #f)
- ("support" #f)
- (file (not (string-prefix?
- "test_support."
- file))))))
- (call-with-output-file "__init__.py"
- (const #t))))
- (let ((libdir (string-append out "/lib/" pythonX.Y)))
- (for-each (lambda (directory)
- (let ((dir (string-append libdir "/"
- directory)))
- (when (file-exists? dir)
- (delete-file-recursively dir))))
- '("email/test" "ctypes/test"
- "unittest/test"
- "tkinter/test"
- "sqlite3/test"
- "bsddb/test"
- "lib-tk/test"
- "json/tests"
- "distutils/tests"))))))))
- (add-after 'remove-tests 'move-tk-inter
- (lambda* (#:key outputs inputs #:allow-other-keys)
- ;; When Tkinter support is built move it to a separate output so
- ;; that the main output doesn't contain a reference to Tcl/Tk.
- (let ((out (assoc-ref outputs "out"))
- (tk (assoc-ref outputs "tk")))
- (when tk
- (match (find-files out "tkinter.*\\.so")
- ((tkinter.so)
- ;; The .so is in OUT/lib/pythonX.Y/lib-dynload, but we
- ;; want it under TK/lib/pythonX.Y/site-packages.
- (let* ((len (string-length out))
- (target (string-append tk "/"
- (string-drop (dirname
- (dirname
- tkinter.so))
- len)
- "/site-packages")))
- (install-file tkinter.so target)
- (delete-file tkinter.so))))
- ;; Remove explicit store path references.
- (let ((tcl (assoc-ref inputs "tcl"))
- (tk (assoc-ref inputs "tk")))
- (substitute* (find-files (string-append out "/lib")
- "^(_sysconfigdata_.*\\.py|Makefile)$")
- (((string-append "-L" tk "/lib"))
- "")
- (((string-append "-L" tcl "/lib"))
- "")))))))
- (add-after 'move-tk-inter 'move-idle
- (lambda* (#:key outputs #:allow-other-keys)
- ;; when idle is built, move it to a separate output to save some
- ;; space (5MB)
- (let ((out (assoc-ref outputs "out"))
- (idle (assoc-ref outputs "idle")))
- (when idle
- (for-each (lambda (file)
- (let ((target (string-append idle
- "/bin/"
- (basename
- file))))
- (install-file file
- (dirname target))
- (delete-file file)))
- (find-files (string-append out "/bin")
- "^idle"))
- (match (find-files out "^idlelib$"
- #:directories? #t)
- ((idlelib)
- (let* ((len (string-length out))
- (target (string-append idle "/"
- (string-drop
- idlelib len)
- "/site-packages")))
- (mkdir-p (dirname target))
- (rename-file idlelib target))))))))
- (add-after 'move-idle 'rebuild-bytecode
- (lambda* (#:key outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "out")))
- ;; Disable hash randomization to ensure the generated .pycs
- ;; are reproducible.
- (setenv "PYTHONHASHSEED" "0")
+ #~(modify-phases %standard-phases
+ #$@(if (system-hurd?)
+ `((add-after 'unpack
+ 'disable-multi-processing
+ (lambda _
+ (substitute* "Makefile.pre.in"
+ (("-j0")
+ "-j1")))))
+ '())
+ (add-before 'configure 'patch-lib-shells
+ (lambda _
+ ;; This variable is used in setup.py to enable cross compilation
+ ;; specific switches. As it is not set properly by configure
+ ;; script, set it manually.
+ #$@(if (%current-target-system)
+ '((setenv "_PYTHON_HOST_PLATFORM" ""))
+ '())
+ ;; Filter for existing files, since some may not exist in all
+ ;; versions of python that are built with this recipe.
+ (substitute* (filter file-exists?
+ '("Lib/subprocess.py"
+ "Lib/popen2.py"
+ "Lib/distutils/tests/test_spawn.py"
+ "Lib/test/support/__init__.py"
+ "Lib/test/test_subprocess.py"))
+ (("/bin/sh")
+ (which "sh")))))
+ (add-before 'configure 'do-not-record-configure-flags
+ (lambda* (#:key configure-flags #:allow-other-keys)
+ ;; Remove configure flags from the installed '_sysconfigdata.py'
+ ;; and 'Makefile' so we don't end up keeping references to the
+ ;; build tools.
+ ;;
+ ;; Preserve at least '--with-system-ffi' since otherwise the
+ ;; thing tries to build libffi, fails, and we end up with a
+ ;; Python that lacks ctypes.
+ (substitute* "configure"
+ (("^CONFIG_ARGS=.*$")
+ (format #f "CONFIG_ARGS='~a'\n"
+ (if (member "--with-system-ffi"
+ configure-flags)
+ "--with-system-ffi" ""))))))
+ (add-before 'check 'pre-check
+ (lambda _
+ ;; 'Lib/test/test_site.py' needs a valid $HOME
+ (setenv "HOME"
+ (getcwd))))
+ (add-after 'unpack 'set-source-file-times-to-1980
+ ;; XXX One of the tests uses a ZIP library to pack up some of the
+ ;; source tree, and fails with "ZIP does not support timestamps
+ ;; before 1980". Work around this by setting the file times in the
+ ;; source tree to sometime in early 1980.
+ (lambda _
+ (let ((circa-1980 (* 10 366 24 60 60)))
+ (ftw "."
+ (lambda (file stat flag)
+ (utime file circa-1980 circa-1980) #t)))))
+ (add-after 'unpack 'remove-windows-binaries
+ (lambda _
+ ;; Delete .exe from embedded .whl (zip) files
+ (for-each (lambda (whl)
+ (let ((dir "whl-content")
+ (circa-1980 (* 10 366 24 60 60)))
+ (mkdir-p dir)
+ (with-directory-excursion dir
+ (let ((whl (string-append "../" whl)))
+ (invoke "unzip" whl)
+ (for-each delete-file
+ (find-files "." "\\.exe$"))
+ (delete-file whl)
+ ;; Reset timestamps to prevent them from ending
+ ;; up in the Zip archive.
+ (ftw "."
+ (lambda (file stat flag)
+ (utime file circa-1980
+ circa-1980) #t))
+ (apply invoke "zip" "-X" whl
+ (find-files "."
+ #:directories? #t))))
+ (delete-file-recursively dir)))
+ (find-files "Lib/ensurepip" "\\.whl$"))))
+ (add-after 'install 'remove-tests
+ ;; Remove 25 MiB of unneeded unit tests. Keep test_support.*
+ ;; because these files are used by some libraries out there.
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+ (match (scandir (string-append out "/lib")
+ (lambda (name)
+ (string-prefix? "python" name)))
+ ((pythonX.Y)
+ (let ((testdir (string-append out "/lib/" pythonX.Y
+ "/test")))
+ (with-directory-excursion testdir
+ (for-each delete-file-recursively
+ (scandir testdir
+ (match-lambda
+ ((or "." "..")
+ #f)
+ ("support" #f)
+ (file (not (string-prefix?
+ "test_support."
+ file))))))
+ (call-with-output-file "__init__.py"
+ (const #t))))
+ (let ((libdir (string-append out "/lib/" pythonX.Y)))
+ (for-each (lambda (directory)
+ (let ((dir (string-append libdir "/"
+ directory)))
+ (when (file-exists? dir)
+ (delete-file-recursively dir))))
+ '("email/test" "ctypes/test"
+ "unittest/test"
+ "tkinter/test"
+ "sqlite3/test"
+ "bsddb/test"
+ "lib-tk/test"
+ "json/tests"
+ "distutils/tests"))))))))
+ (add-after 'remove-tests 'move-tk-inter
+ (lambda* (#:key outputs inputs #:allow-other-keys)
+ ;; When Tkinter support is built move it to a separate output so
+ ;; that the main output doesn't contain a reference to Tcl/Tk.
+ (let ((out (assoc-ref outputs "out"))
+ (tk (assoc-ref outputs "tk")))
+ (when tk
+ (match (find-files out "tkinter.*\\.so")
+ ((tkinter.so)
+ ;; The .so is in OUT/lib/pythonX.Y/lib-dynload, but we
+ ;; want it under TK/lib/pythonX.Y/site-packages.
+ (let* ((len (string-length out))
+ (target (string-append tk "/"
+ (string-drop (dirname
+ (dirname
+ tkinter.so))
+ len)
+ "/site-packages")))
+ (install-file tkinter.so target)
+ (delete-file tkinter.so))))
+ ;; Remove explicit store path references.
+ (let ((tcl (assoc-ref inputs "tcl"))
+ (tk (assoc-ref inputs "tk")))
+ (substitute* (find-files (string-append out "/lib")
+ "^(_sysconfigdata_.*\\.py|Makefile)$")
+ (((string-append "-L" tk "/lib"))
+ "")
+ (((string-append "-L" tcl "/lib"))
+ "")))))))
+ (add-after 'move-tk-inter 'move-idle
+ (lambda* (#:key outputs #:allow-other-keys)
+ ;; when idle is built, move it to a separate output to save some
+ ;; space (5MB)
+ (let ((out (assoc-ref outputs "out"))
+ (idle (assoc-ref outputs "idle")))
+ (when idle
+ (for-each (lambda (file)
+ (let ((target (string-append idle
+ "/bin/"
+ (basename
+ file))))
+ (install-file file
+ (dirname target))
+ (delete-file file)))
+ (find-files (string-append out "/bin")
+ "^idle"))
+ (match (find-files out "^idlelib$"
+ #:directories? #t)
+ ((idlelib)
+ (let* ((len (string-length out))
+ (target (string-append idle "/"
+ (string-drop
+ idlelib len)
+ "/site-packages")))
+ (mkdir-p (dirname target))
+ (rename-file idlelib target))))))))
+ (add-after 'move-idle 'rebuild-bytecode
+ (lambda* (#:key outputs #:allow-other-keys)
+ ;; Disable hash randomization to ensure the generated .pycs
+ ;; are reproducible.
+ (setenv "PYTHONHASHSEED" "0")
- (for-each (lambda (output)
- ;; XXX: Delete existing pycs generated by the build
- ;; system beforehand because the -f argument does
- ;; not necessarily overwrite all files, leading to
- ;; indeterministic results.
- (for-each (lambda (pyc)
- (delete-file pyc))
- (find-files output "\\.pyc$"))
+ (for-each (lambda (output)
+ ;; XXX: Delete existing pycs generated by the build
+ ;; system beforehand because the -f argument does
+ ;; not necessarily overwrite all files, leading to
+ ;; indeterministic results.
+ (for-each (lambda (pyc)
+ (delete-file pyc))
+ (find-files output "\\.pyc$"))
- (apply invoke
- `(,,(if (%current-target-system)
- "python3"
- '(string-append out
- "/bin/python3")) "-m"
- "compileall"
- "-o"
- "0"
- "-o"
- "1"
- "-o"
- "2"
- "-f" ;force rebuild
- "--invalidation-mode=unchecked-hash"
- ;; Don't build lib2to3, because it's
- ;; Python 2 code.
- "-x"
- "lib2to3/.*"
- ,output)))
- (map cdr outputs)))))
- (add-before 'check 'set-TZDIR
- (lambda* (#:key inputs native-inputs #:allow-other-keys)
- ;; test_email requires the Olson time zone database.
- (setenv "TZDIR"
- (string-append (assoc-ref (or native-inputs
- inputs) "tzdata")
- "/share/zoneinfo"))))
- (add-after 'install 'install-sitecustomize.py
- ,(customize-site version)))))
+ (apply invoke
+ #$(if (%current-target-system)
+ "python3"
+ #~(string-append #$output "/bin/python3"))
+ `("-m" "compileall"
+ "-o" "0"
+ "-o" "1"
+ "-o" "2"
+ "-f" ;force rebuild
+ "--invalidation-mode=unchecked-hash"
+ ;; Don't build lib2to3, because it's Python
+ ;; 2 code.
+ "-x" "lib2to3/.*"
+ ,output)))
+ (map cdr outputs))))
+ (add-before 'check 'set-TZDIR
+ (lambda* (#:key inputs native-inputs #:allow-other-keys)
+ ;; test_email requires the Olson time zone database.
+ (setenv "TZDIR"
+ (string-append (assoc-ref (or native-inputs
+ inputs) "tzdata")
+ "/share/zoneinfo"))))
+ (add-after 'install 'add-libxcrypt-reference-pkgconfig
+ (lambda* (#:key inputs #:allow-other-keys)
+ (let ((libxcrypt
+ (false-if-exception
+ (dirname
+ (search-input-file inputs "lib/libcrypt.so.1")))))
+ (when libxcrypt
+ (substitute*
+ (find-files (string-append #$output "/lib/pkgconfig")
+ ".*\\.pc")
+ (("Libs:")
+ (string-append "Libs: " "-L" libxcrypt " -lcrypt")))))))
+ (add-after 'install 'install-sitecustomize.py
+ #$(customize-site version)))))
(inputs (list bzip2
expat
gdbm
libffi ;for ctypes
+ libxcrypt ;crypto module slated for removal in 3.13
sqlite ;for sqlite extension
openssl
readline
[Message part 3 (text/plain, inline)]
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Mon, 27 Jan 2025 12:37:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Ricardo Wurmus <rekado <at> elephly.net> writes:
> Ricardo Wurmus <rekado <at> elephly.net> writes:
>
>> What do you think about adding libxcrypt to python-3.11? The
>> unmaintained but still influential python-passlib fails to detect
>> support for some crypt() primitives, and I think we can fix this by
>> building python-3.11 with libxcrypt support.
>>
>> We build Python 3.10 (as well as Python 2) with libxcrypt support.
>>
>> If there are no objections I'll make the change tonight which will
>> trigger a world rebuild.
>
> I'm still building a large number of Rust packages locally to see if
> the change has any impact on python-passlib.
The change did fix python-passlib. I've pushed it to python-team.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 29 Jan 2025 09:15:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 75751 <at> debbugs.gnu.org (full text, mbox):
I have rebased python-team on top of the master branch. Unfortunately,
now maturin fails to build, and I can't tell why.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 29 Jan 2025 15:35:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Ricardo Wurmus <rekado <at> elephly.net> writes:
> I have rebased python-team on top of the master branch. Unfortunately,
> now maturin fails to build, and I can't tell why.
This happened only on my laptop. When I restricted the number of cores
it eventually completed the build.
Today I rebased "python-team" on top of "master" as too many big changes
had since accumulated on the "master" branch.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Fri, 21 Feb 2025 08:33:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 75751 <at> debbugs.gnu.org (full text, mbox):
> Today I rebased "python-team" on top of "master" as too many big changes
> had since accumulated on the "master" branch.
I have rebased "python-team" on top of "master" again.
If any of you are working on anything in particular to get the branch
ready, please let us know here. Thank you!
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Fri, 21 Feb 2025 10:36:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 75751 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-21 09:31, Ricardo Wurmus wrote:
>> Today I rebased "python-team" on top of "master" as too many big changes
>> had since accumulated on the "master" branch.
>
> I have rebased "python-team" on top of "master" again.
>
> If any of you are working on anything in particular to get the branch
> ready, please let us know here. Thank you!
I do, I was trying to update 70858.
Do you have a particular deadline?
--
Best regards,
Nicolas Graves
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 05 Mar 2025 18:01:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I see we are the next after core-packages-team.
Is any larger rebuild planned?
Oleg
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5
… наш разум - превосходная объяснительная машина которая способна найти
смысл почти в чем угодно, истолковать любой феномен, но совершенно не в
состоянии принять мысль о непредсказуемости.
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 06 Mar 2025 16:03:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Sharlatan Hellseher <sharlatanus <at> gmail.com> writes:
> I see we are the next after core-packages-team.
> Is any larger rebuild planned?
I have nothing planned. I only rebased the branch recently.
I don't have a good overview on what big failures remain. Perhaps
your
script could show us what currently failing packages would have
the
biggest impact in removing dependent failures.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 06 Mar 2025 17:02:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 75751 <at> debbugs.gnu.org (full text, mbox):
On 2025-03-06 17:02, Ricardo Wurmus wrote:
> Sharlatan Hellseher <sharlatanus <at> gmail.com> writes:
>
>> I see we are the next after core-packages-team.
>> Is any larger rebuild planned?
>
> I have nothing planned. I only rebased the branch recently.
>
> I don't have a good overview on what big failures remain. Perhaps
> your
> script could show us what currently failing packages would have
> the
> biggest impact in removing dependent failures.
We still have 70858 if we want to merge it in this iteration. I might
have 1/2 patches on top of it for independent failures I could find
and send.
--
Best regards,
Nicolas Graves
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 12 Mar 2025 16:47:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 75751 <at> debbugs.gnu.org (full text, mbox):
On 2025-03-06 17:02, Ricardo Wurmus wrote:
> Sharlatan Hellseher <sharlatanus <at> gmail.com> writes:
>
>> I see we are the next after core-packages-team.
>> Is any larger rebuild planned?
>
> I have nothing planned. I only rebased the branch recently.
>
> I don't have a good overview on what big failures remain. Perhaps
> your
> script could show us what currently failing packages would have
> the
> biggest impact in removing dependent failures.
Hi guys,
We're next on the merge order. We have at least two more candidates
patch series, and at least a broken tensorflow <at> 1.
The two series I'm referring to are 76835 v3 and 70858 (again :)).
76835 is updating patchwork so we might want to check with Chris if
that's OK. How do you want to proceed ?
--
Best regards,
Nicolas Graves
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 12 Mar 2025 22:08:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi team!
@Nicoals thank you for your effortds in #76835, #70858.
I've skimmed #76835 and it looks like quite raw for me some: commit
messages not fully complete, some update/move may squash e.g. snakemake
package would be essentially updated in place and then move, instead of
adding duplicate in python-science and delete in python-xyz.
#70858 sorry to say the full series is failed to apply.
From my side I'd like to merge whatever we have right now as the main
target in this iteration was to refresh Python 3.10->3.11, fixing build
issues, refresh NumPy and related packages.
Let's check what can be fixed on larger scale, enable few more
architectures and prepare for the merge.
How about to queue #76835 and #70858 in the next iteration which we may
open after merge? Otherwise we would block other branches for a longer
time.
WDYT?
--
Oleg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 12 Mar 2025 22:49:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 75751 <at> debbugs.gnu.org (full text, mbox):
On 2025-03-12 22:07, Sharlatan Hellseher wrote:
> Hi team!
>
> @Nicoals thank you for your effortds in #76835, #70858.
>
> I've skimmed #76835 and it looks like quite raw for me some: commit
> messages not fully complete, some update/move may squash e.g. snakemake
> package would be essentially updated in place and then move, instead of
> adding duplicate in python-science and delete in python-xyz.
Sorry, I was quick for this one, maybe I neglected messages a bit. You
might want to select some commits (in the v1 in particular) in this case
: python-h2, and maybe some of the ignoring of failing tests.
tensorflow <at> 1 might be an issue too, I haven't delved into why it fails.
> #70858 sorry to say the full series is failed to apply.
>
> From my side I'd like to merge whatever we have right now as the main
> target in this iteration was to refresh Python 3.10->3.11, fixing build
> issues, refresh NumPy and related packages.
>
> Let's check what can be fixed on larger scale, enable few more
> architectures and prepare for the merge.
>
> How about to queue #76835 and #70858 in the next iteration which we may
> open after merge? Otherwise we would block other branches for a longer
> time.
Both are fine for me, I use a local repo in the meantime. Let's merge,
I'll rebase later, but let's start a new iteration quite quickly to
handle 70858 (or create a GCD for development-inputs as an alternative).
--
Best regards,
Nicolas Graves
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 13 Mar 2025 11:29:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I see Ricardo rebased python-team.
I've pushed a few fixing commits picked from #76835 and #70858.
ae2c103fda * python-team tmp-python-team gnu: python-asyncpg: Update to 0.30.0.
7e5db56ceb * gnu: python-cftime: Fix tests.
65681c6faf * gnu: Remove python-pytest-pep8.
cea68ae2d4 * gnu: Remove python-pep8.
e8062c0d6d * gnu: python-unyt: Avoid deprecation failure in tests.
--
Oleg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 20 Mar 2025 10:37:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've been keeping an eye on QA and it looks like it's finally making
some progress on python-team.
I think there are still some build coordinator bugs holding things up,
but I think there are some package problems that have been
identified. Unfortunately the QA pages aren't ideal at actually showing
the most important things to fix (this needs working on), but in terms
of blocked builds, the data service does have some clearer pages [1], in
particular, it seems like python-numpy plus some other important python
packages are failing on i686-linux.
1: https://data.qa.guix.gnu.org/revision/d43f15f95f0f01d66cbbaf1cc90c10dea211f9cf/blocking-builds?system=i686-linux&target=none&limit_results=50
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 20 Mar 2025 15:35:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Christopher Baines <mail <at> cbaines.net> writes:
> I've been keeping an eye on QA and it looks like it's finally
> making
> some progress on python-team.
>
> I think there are still some build coordinator bugs holding
> things up,
> but I think there are some package problems that have been
> identified. Unfortunately the QA pages aren't ideal at actually
> showing
> the most important things to fix (this needs working on), but in
> terms
> of blocked builds, the data service does have some clearer pages
> [1], in
> particular, it seems like python-numpy plus some other important
> python
> packages are failing on i686-linux.
>
> 1:
> https://data.qa.guix.gnu.org/revision/d43f15f95f0f01d66cbbaf1cc90c10dea211f9cf/blocking-builds?system=i686-linux&target=none&limit_results=50
Thanks for the information and the helpful URL.
I've just fixed python-numpy and llvm 15 on i686-linux, which
should unlock a number of builds.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sun, 23 Mar 2025 12:43:03 GMT)
Full text and
rfc822 format available.
Message #65 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Please also check
https://data.qa.guix.gnu.org/compare/package-derivations?base_commit=1d4ad650661e7e045d3e1d59a17b8da4611884f8&target_commit=6eca6ec8607c903e9d962c37ecd769b4e0bff2ed&system=x86_64-linux&build_change=broken&after_name=&limit_results=40
to see newly failing builds that we may have missed so far. I
don't want us to introduce too many new failures.
I cannot commit much more time to this branch, so it would be very
appreciated if you could convince a friend or two to help out
fixing things, so that we can merge this branch soon.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sun, 23 Mar 2025 22:23:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Ricardo Wurmus <rekado <at> elephly.net> writes:
> Please also check
> https://data.qa.guix.gnu.org/compare/package-derivations?base_commit=1d4ad650661e7e045d3e1d59a17b8da4611884f8&target_commit=6eca6ec8607c903e9d962c37ecd769b4e0bff2ed&system=x86_64-linux&build_change=broken&after_name=&limit_results=40
> to see newly failing builds that we may have missed so far. I
> don't
> want us to introduce too many new failures.
>
> I cannot commit much more time to this branch, so it would be
> very
> appreciated if you could convince a friend or two to help out
> fixing
> things, so that we can merge this branch soon.
I have started work on the tryton packages, but there are too many
for me to fix. Would anyone like to contribute in upgrading them
and fixing their builds? I could share some WIP.
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sun, 23 Mar 2025 22:41:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ricardo,
I can contribute some time, please share your WIPs or
I can take a list from data service
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5
… наш разум - превосходная объяснительная машина которая способна найти
смысл почти в чем угодно, истолковать любой феномен, но совершенно не в
состоянии принять мысль о непредсказуемости.
On Sun, 23 Mar 2025, 22:22 Ricardo Wurmus, <rekado <at> elephly.net> wrote:
> Ricardo Wurmus <rekado <at> elephly.net> writes:
>
> > Please also check
> >
> https://data.qa.guix.gnu.org/compare/package-derivations?base_commit=1d4ad650661e7e045d3e1d59a17b8da4611884f8&target_commit=6eca6ec8607c903e9d962c37ecd769b4e0bff2ed&system=x86_64-linux&build_change=broken&after_name=&limit_results=40
> > to see newly failing builds that we may have missed so far. I
> > don't
> > want us to introduce too many new failures.
> >
> > I cannot commit much more time to this branch, so it would be
> > very
> > appreciated if you could convince a friend or two to help out
> > fixing
> > things, so that we can merge this branch soon.
>
> I have started work on the tryton packages, but there are too many
> for me to fix. Would anyone like to contribute in upgrading them
> and fixing their builds? I could share some WIP.
>
> --
> Ricardo
>
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 26 Mar 2025 09:52:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sharlatan Hellseher <sharlatanus <at> gmail.com> writes:
> Hi Ricardo,
>
> I can contribute some time, please share your WIPs or
> I can take a list from data service
Thanks for volunteering, unfortunately I can't commit any time in the
next couple of weeks.
QA is still super fragile, but looking at python-team currently it has
at least mostly built the branch, and while the information still isn't
as clear as it could be, QA is highlighting at least some of the broken
packages (at least 35 python-... things I think).
Ideally these broken packages would be fixed before merging, but the
current situation is still an improvement over the state of previous
branch merges.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 26 Mar 2025 13:04:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 75751 <at> debbugs.gnu.org (full text, mbox):
On 2025-03-26 09:51, Christopher Baines wrote:
> Sharlatan Hellseher <sharlatanus <at> gmail.com> writes:
>
>> Hi Ricardo,
>>
>> I can contribute some time, please share your WIPs or
>> I can take a list from data service
>
> Thanks for volunteering, unfortunately I can't commit any time in the
> next couple of weeks.
>
> QA is still super fragile, but looking at python-team currently it has
> at least mostly built the branch, and while the information still isn't
> as clear as it could be, QA is highlighting at least some of the broken
> packages (at least 35 python-... things I think).
>
> Ideally these broken packages would be fixed before merging, but the
> current situation is still an improvement over the state of previous
> branch merges.
The issue is that Python development is not as well structured as those
of other languages. I noticed for instance that almost all failing
packages in bioinformatics and astronomy are packages that are simply
not developped anymore. We could remove them or maybe move them to
guix-past, but the effort for making them build again is not bearable in
Guix. That still means we're going to remove at least 15 packages just
because they don't build.
guix-past with an older version of python sounds good to me, but I don't
know if we have a policy on that.
--
Best regards,
Nicolas Graves
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 26 Mar 2025 17:03:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Christopher Baines <mail <at> cbaines.net> writes:
> QA is still super fragile, but looking at python-team currently
> it has
> at least mostly built the branch, and while the information
> still isn't
> as clear as it could be, QA is highlighting at least some of the
> broken
> packages (at least 35 python-... things I think).
I'm a bit confused by the output at
https://qa.guix.gnu.org/branch/python-team/package-changes?x86_64-linux-change=blocked&x86_64-linux-change=still-blocked&x86_64-linux-change=unknown-to-blocked&x86_64-linux-change=new-blocked
I spot checked a few of the packages that are listed as "now
blocked", such as python-pyro-ppl, but they build fine.
Where do you see the 35 or so python-* packages that are broken?
--
Ricardo
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 26 Mar 2025 17:42:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ricardo Wurmus <rekado <at> elephly.net> writes:
> Christopher Baines <mail <at> cbaines.net> writes:
>
>> QA is still super fragile, but looking at python-team currently it
>> has
>> at least mostly built the branch, and while the information still
>> isn't
>> as clear as it could be, QA is highlighting at least some of the
>> broken
>> packages (at least 35 python-... things I think).
>
> I'm a bit confused by the output at
> https://qa.guix.gnu.org/branch/python-team/package-changes?x86_64-linux-change=blocked&x86_64-linux-change=still-blocked&x86_64-linux-change=unknown-to-blocked&x86_64-linux-change=new-blocked
>
> I spot checked a few of the packages that are listed as "now blocked",
> such as python-pyro-ppl, but they build fine.
So, if you click on "Now blocked" for python-pyro-ppl on that page, you
should end up on:
https://data.qa.guix.gnu.org/gnu/store/47fixhcjy0cpqv79gpljkjwqjjnm78cw-python-pyro-ppl-1.9.1.drv
If you click on the blue "Scheduled" build button, you should end up on:
https://data.qa.guix.gnu.org/build-server/2/build?build_server_build_id=116bd413-037a-4960-99f9-13b3b1f23a12
That page should show the failed builds that are blocking the
python-pyro-ppl build, in this case cpp-httplib is failing to build.
Now we're lacking build information from ci.guix.gnu.org, but we do have
substitute information, so if you click on the cpp-httplib derivation,
then on it's output, you can see the output information from
ci.guix.gnu.org, demonstrating that it can be built, and thus yes, it
looks like cpp-httplib shouldn't be blocking python-pyro-ppl.
This cpp-httplib build has failed 3 times across three separate
machines, so even though ci.guix.gnu.org has built it successfully, I'd
say that this is still a problem, although potentially one that hasn't
been introduced by the python-team changes.
> Where do you see the 35 or so python-* packages that are broken?
I'm filtering just by "broken" (e.g. [1]) then roughly counting the
packages prefixed with python- on that page. I also did this for an arm
architecture (e.g. aarch64-linux [2]) since there's a bunch of spurious
failures for x86 and i686. I'm now actually seeing 53 python- things on
that page, so maybe 35 was an undercount.
1: https://qa.guix.gnu.org/branch/python-team/package-changes?x86_64-linux-change=broken
2: https://qa.guix.gnu.org/branch/python-team/package-changes?aarch64-linux-change=broken
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 27 Mar 2025 16:11:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I'm going through build errors for "guix build -P1 python-numpy <at> 1"
On Thu, 27 Mar 2025 at 00:19, Mail Delivery Subsystem <
mailer-daemon <at> googlemail.com> wrote:
> [image: Error Icon]
> Message blocked
> Your message to *ngraves <at> ngraves.fr* has been blocked. See technical
> details below for more information.
> LEARN MORE <https://support.google.com/a/answer/9261504>
> The response was:
>
> The MX host does not match any MX allowed by the STS policy. For more
> information, go to https://support.google.com/a/answer/9261504
>
>
>
> ---------- Forwarded message ----------
> From: Sharlatan Hellseher <sharlatanus <at> gmail.com>
> To: Ricardo Wurmus <rekado <at> elephly.net>
> Cc: 75751 <at> debbugs.gnu.org, Christopher Baines <mail <at> cbaines.net>, Nicolas
> Graves <ngraves <at> ngraves.fr>
> Bcc:
> Date: Sun, 23 Mar 2025 22:40:26 +0000
> Subject: Re: [bug#75751] Request for merging "python-team" branch
> ----- Message truncated -----
>
--
VCS: https://github.incerto.xyz/; https://git.sr.ht/~hellseher/
GPG: 9847 81DE 689C 21C2 6418 0867 76D7 27BF F62C D2B5
… наш разум - превосходная объяснительная машина которая способна найти
смысл почти в чем угодно, истолковать любой феномен, но совершенно не в
состоянии принять мысль о непредсказуемости.
[Message part 2 (text/html, inline)]
[icon.png (image/png, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Tue, 01 Apr 2025 21:16:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Hello Nicolas,
Am Wed, Mar 26, 2025 at 02:03:26PM +0100 schrieb Nicolas Graves:
> The issue is that Python development is not as well structured as those
> of other languages. I noticed for instance that almost all failing
> packages in bioinformatics and astronomy are packages that are simply
> not developped anymore. We could remove them or maybe move them to
> guix-past, but the effort for making them build again is not bearable in
> Guix. That still means we're going to remove at least 15 packages just
> because they don't build.
I also think we should more aggressively remove not building packages
from Guix; this is not particularly a Python issue, I also came across
several such packages by working on science team in the last few days.
Some packages are abandoned upstream for years and also have not been
built in Guix for years; we cannot substitute ourselves for upstream.
And anyway this indicates that probably nobody is using such Guix
packages in the first place.
See
https://guix.gnu.org/manual/devel/en/html_node/Deprecation-Policy.html
for the procedure; essentially, file a bug and wait one month if
somebody objects (and then, ideally, comes up with a plan to rescue the
package).
I do not think that guix-past is a good place; as far as I remember, we
used it for packages so old as to never have been in Guix. Packages from
Guix are in principle still reachable through time-machine.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 03 Apr 2025 17:38:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I've rebased python-team branch on the master HEAD origin/master
20ee284085236992f7df5082511cbd545e61ab44
Will continue to check build chain for python-numpy while core-team is
ahead now.
--
Oleg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 03 Apr 2025 18:06:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Hello Oleg,
Am Thu, Apr 03, 2025 at 06:37:14PM +0100 schrieb Sharlatan Hellseher:
> Will continue to check build chain for python-numpy while core-team is
> ahead now.
we have paused the core-packages-team since we are waiting for an
external patch, so python-team is first in line now. Concerning
rebasing, I see that the "merge base has not been processed by the
data service yet". Instead of rebasing on master, I prefer to rebase on
a slightly older commit that already is available to the data service:
https://data.qa.guix.gnu.org/repository/1/branch/master
I think we "git push" faster than the data service can follow, so some
commits are never processed.
We can wait for this branch building out; but if then you see that it is
not ready, you could leave your place in the queue while working on
getting it in shape. This can be done simply by closing the bug, which
does not prevent continueing the discussion. And once the bug is
reopened, you will take your previous slot in the queue.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 03 Apr 2025 22:17:03 GMT)
Full text and
rfc822 format available.
Message #98 received at 75751 <at> debbugs.gnu.org (full text, mbox):
I have a few patches to send ;)
Will send them tomorrow :)
On 2025-04-03 18:37, Sharlatan Hellseher wrote:
> Hi,
>
> I've rebased python-team branch on the master HEAD origin/master
> 20ee284085236992f7df5082511cbd545e61ab44
>
> Will continue to check build chain for python-numpy while core-team is
> ahead now.
>
> --
> Oleg
--
Best regards,
Nicolas Graves
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Fri, 04 Apr 2025 19:47:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Sent!
Looks like ci is done with x86_64, I think they can be merged now.
--
Best regards,
Nicolas Graves
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sat, 05 Apr 2025 21:13:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
How confident are we to merge it now?
I've got this list of failed derivation which depends on python-numpy in
first level:
--8<---------------cut here---------------start------------->8---
> ./pre-inst-env guix build -P1 -M8 -k python-numpy <at> 1 2>&1 | grep "drv failed"
build of /gnu/store/7j4vs0qmpq4pmp6wv95l633w9wwlb600-atlas-3.10.3.drv failed
build of /gnu/store/2lzkvl7hsgnwbirw1ja0zblxa5yyv3hd-python-lap-0.4.0.drv failed
build of /gnu/store/mr1pl70mgjwh7m1lark373crk5pl1lys-python-django-3.1.14.drv failed
build of /gnu/store/klhxwyshri2ckg3hm7z6f9sx9h554fi7-python-parabam-3.0.1.drv failed
build of /gnu/store/whxf2pjvc66jdkrkqhvmab0mj139vaj3-python-pathy-0.10.1.drv failed
build of /gnu/store/xhd8dzjx784293lgd1b1xrhpk4zkghdv-python-plastid-0.6.1.drv failed
build of /gnu/store/hsgyi7plqyrd0dml79qsa2z32v9mvv56-python-pandera-0.18.0.drv failed
build of /gnu/store/snx43hiwm8r4gdm6j2wwf1nqdr6chbrq-python-shiboken-2-5.15.10.drv failed
build of /gnu/store/6xqkf84q0cfzpb3naqgi04zq9k1x7q6s-python-sip-4.19.25.drv failed
build of /gnu/store/px3030m9ph0ajn7n9swl7a7yqgmmyh1p-python-pyopencl-2021.2.6.drv failed
build of /gnu/store/plc21lnn1kgx61160dc2fr0lna1wh8pa-python-keras-2.3.1.drv failed
build of /gnu/store/famib5w1yim2nkvjzanj1s84j0wm2ff9-python-pyarrow-0.16.0.drv failed
build of /gnu/store/45y49db5kpgn5xlh8ic29b1wj69b6nlw-swftools-0.9.2-1.772e55a.drv failed
build of /gnu/store/bgps1c1n9fmkawsq95pkifbzs3qli3v6-variant-tools-3.1.2.drv failed
build of /gnu/store/5wlg9ax5x7a042l3wh5isk2wpn5f2s8c-python-pomegranate-0.14.8.drv failed
build of /gnu/store/h9vzharh5r52hsg1mqldslvwxinbf0j6-python-django-3.2.21.drv failed
build of /gnu/store/8ra2z99ljnkm3x19x8f1spzsdbv54n68-python-brian2-2.5.1.drv failed
build of /gnu/store/69y4lvscxl9pgq4vkb6v0lkp4fli04vq-python-wxpython-4.2.0.drv failed
build of /gnu/store/qizk4slf6q20x2fbsa8qa9hzq481b8sh-rxcpp-4.1.1.drv failed
build of /gnu/store/x840zdw6x3crf33f4dw4w0fs30yw75fz-python-pandas-1.5.3.drv failed
--8<---------------cut here---------------end--------------->8---
Some of the listed above are quite old and maybe we may withdraw them
while updating dependent packages.
I'll tray to volontaire more time to fix as many as I can.
--
Oleg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sat, 05 Apr 2025 22:24:03 GMT)
Full text and
rfc822 format available.
Message #107 received at 75751 <at> debbugs.gnu.org (full text, mbox):
On 2025-04-05 22:12, Sharlatan Hellseher wrote:
> Hi,
>
> How confident are we to merge it now?
>
> I've got this list of failed derivation which depends on python-numpy in
> first level:
>
> --8<---------------cut here---------------start------------->8---
>> ./pre-inst-env guix build -P1 -M8 -k python-numpy <at> 1 2>&1 | grep "drv failed"
> build of /gnu/store/7j4vs0qmpq4pmp6wv95l633w9wwlb600-atlas-3.10.3.drv failed
> build of /gnu/store/2lzkvl7hsgnwbirw1ja0zblxa5yyv3hd-python-lap-0.4.0.drv failed
> build of /gnu/store/mr1pl70mgjwh7m1lark373crk5pl1lys-python-django-3.1.14.drv failed
> build of /gnu/store/klhxwyshri2ckg3hm7z6f9sx9h554fi7-python-parabam-3.0.1.drv failed
> build of /gnu/store/whxf2pjvc66jdkrkqhvmab0mj139vaj3-python-pathy-0.10.1.drv failed
> build of /gnu/store/xhd8dzjx784293lgd1b1xrhpk4zkghdv-python-plastid-0.6.1.drv failed
> build of /gnu/store/hsgyi7plqyrd0dml79qsa2z32v9mvv56-python-pandera-0.18.0.drv failed
> build of /gnu/store/snx43hiwm8r4gdm6j2wwf1nqdr6chbrq-python-shiboken-2-5.15.10.drv failed
> build of /gnu/store/6xqkf84q0cfzpb3naqgi04zq9k1x7q6s-python-sip-4.19.25.drv failed
> build of /gnu/store/px3030m9ph0ajn7n9swl7a7yqgmmyh1p-python-pyopencl-2021.2.6.drv failed
> build of /gnu/store/plc21lnn1kgx61160dc2fr0lna1wh8pa-python-keras-2.3.1.drv failed
> build of /gnu/store/famib5w1yim2nkvjzanj1s84j0wm2ff9-python-pyarrow-0.16.0.drv failed
> build of /gnu/store/45y49db5kpgn5xlh8ic29b1wj69b6nlw-swftools-0.9.2-1.772e55a.drv failed
> build of /gnu/store/bgps1c1n9fmkawsq95pkifbzs3qli3v6-variant-tools-3.1.2.drv failed
> build of /gnu/store/5wlg9ax5x7a042l3wh5isk2wpn5f2s8c-python-pomegranate-0.14.8.drv failed
> build of /gnu/store/h9vzharh5r52hsg1mqldslvwxinbf0j6-python-django-3.2.21.drv failed
> build of /gnu/store/8ra2z99ljnkm3x19x8f1spzsdbv54n68-python-brian2-2.5.1.drv failed
> build of /gnu/store/69y4lvscxl9pgq4vkb6v0lkp4fli04vq-python-wxpython-4.2.0.drv failed
> build of /gnu/store/qizk4slf6q20x2fbsa8qa9hzq481b8sh-rxcpp-4.1.1.drv failed
> build of /gnu/store/x840zdw6x3crf33f4dw4w0fs30yw75fz-python-pandas-1.5.3.drv failed
> --8<---------------cut here---------------end--------------->8---
>
> Some of the listed above are quite old and maybe we may withdraw them
> while updating dependent packages.
>
> I'll tray to volontaire more time to fix as many as I can.
I managed to fix pomegranate, but I'm working on its dependent cnvkit
now.
I did python-lap, which is definitely doable, will send the test after
merging.
IMO:
- we should drop django <at> 3.2, I had some patches in that direction
in a patch series two weeks ago, I'll take a look. The issue with 3.1
is that archivebox has not updated to a earlier version.
- we should drop the python-sip <at> 4, but some of the changes this requires
are definitely not trivial (graphics / GUI related).
We could split the work Oleg. One big chunk is python-sip/wxpython and its
dependents (several days of work IMO). Figuring out what to do with the
rest could be another big chunk. Hopefully, we'll be ready to merge
after that.
How does that sound? I can try and work my way back with wxpython.
--
Best regards,
Nicolas Graves
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sun, 06 Apr 2025 11:30:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
* Subjected to be withdrawn [0/4]
Packages which are scheduled to be removed or dependent one need to be
refreshed first.
- [ ] atlas-3.10.3.drv failed: https://issues.guix.gnu.org/77321
- [ ] python-django-3.1.14.drv failed:
- A single dependent package: archivebox <at> 0.6.2
- [ ] python-django-3.2.21.drv failed
- Building the following 2 packages would ensure 2 dependent packages
are rebuilt: graphite-web <at> 1.1.10 patchwork <at> 3.1.1
- [ ] python-pandas-1.5.3.drv failed
- It's a leaf package, nothing depending on it, fails to build with
Python 3.11 and NumPy 1.26.
- [ ] python-pomegranate-0.14.8.drv failed
- https://pypi.org/project/pomegranate/, from the project about: "A
temporary repository hosting a pomegranate re-write using PyTorch as
the backend." A single dependent package: cnvkit <at> 0.9.10
- [ ] python-pyarrow-0.16.0.drv failed
- No dependents other than itself: python-pyarrow <at> 0.16.0
* Attempt to fix on python-team
** animamation [0/1]
- [ ] swftools-0.9.2-1.772e55a.drv failed
- Commit 772e55a271f66818b06c6e8c9b839befa51248f4 is from
<2021-12-16>, there is no any tags, the latest activity is from 11
months ago.
** bioinformatics [0/3]
- [ ] python-parabam-3.0.1.drv failed
- Unmaintained https://github.com/cancerit/parabam/issues/10
- [ ] python-plastid-0.6.1.drv failed
- It looks like not maintained project, the last activity on the
master branch 3 yars ago the save as the current version.
- [ ] variant-tools-3.1.2.drv failed
- This repository was archived by the owner on Aug 29, 2023. It is now
read-only.
** machine-learning [0/3]
- [ ] python-lap-0.4.0.drv failed
- The current version (0.4.0) was released 7 years ago, there is a
0.5.12 tag, placed 5 months ago. No dependents other than itself:
python-lap <at> 0.4.0
- [ ] python-brian2-2.5.1.drv failed
- The current version (2.5.1) was released 3 years ago, there is a new
tag 2.8.0.4, placed 3 month ago. A single dependent package:
python-brian2tools <at> 0.3
- [ ] python-keras-2.3.1.drv failed
- The current version (2.3.1) was released 6 years ago, there is a
3.9.2 tag, placed 5 days ago. Building the following 1 package would
ensure 2 dependent packages are rebuilt: python-hicexplorer <at> 3.7.4
- [ ] rxcpp-4.1.1.drv failed
- It's the latest version. Build fails. Building the following 2
packages would ensure 2 dependent packages are rebuilt:
hyperledger-iroha <at> 1.1.1 shogun <at> 6.1.3
** opencl [0/1]
- [ ] python-pyopencl-2021.2.6.drv failed
- The current version (2021.2.6) was released 4 years ago, there is
2025.1 tag, placed 3 month ago. No dependents other than itself:
python-pyopencl <at> 2021.2.6
** python-science [0/1]
- [ ] python-pandera-0.18.0.drv failed
- The current version (0.18.0) was released 2 years ago, there is
0.23.1 tag, placed a month ago. No dependents other than itself:
python-pandera <at> 0.18.0
** python-xyz [0/2]
- [ ] python-pathy-0.10.1.drv failed
- The current version (0.10.1) was released 3 years ago, there is a
0.11.0 tag, placed a year ago, the last activity on the master
branch is the same. A single dependent package: python-spacy <at> 3.6.1
** qt [0/1]
- [ ] python-shiboken-2-5.15.10.drv failed
- The version is confusing, the variable is python-shiboken-2 but it
has 5.15.10 version ¯\_(ツ)_/¯. Building the following 5 packages
would ensure 7 dependent packages are rebuilt:
hydrus-network <at> 495 mygnuhealth <at> 2.2.1 freecad <at> 1.0.0 rfcat <at> 1.9.6 onionshare <at> 2.6
- [ ] python-sip-4.19.25.drv failed
- Building the following 1 package would ensure 6 dependent packages
are rebuilt: cura <at> 4.13.1
** wxwidgets [/]
- python-wxpython-4.2.0.drv failed
- Tests could not find __version__, it's ok on the master
branch ¯\_(ツ)_/¯. Building the following 4 packages would ensure 5
dependent packages are rebuilt: python-sirilic <at> 1.15.12 kicad <at> 9.0.0
qgis <at> 3.42.1 chirp <at> 0.4.0-3.1219bee
> We could split the work Oleg. One big chunk is python-sip/wxpython and its
> dependents (several days of work IMO). Figuring out what to do with the
> rest could be another big chunk. Hopefully, we'll be ready to merge
> after that.
It's a good idea, if you have a plan with python-sip/wxpython (I tried
to fix python-wxpython, but failed to figure out why tests could not
find __version__ now, it's ok on master). I can tak any other dated
packages and hop with refresh they would be fixed.
--
Oleg
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Sun, 06 Apr 2025 12:25:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Just managed to build wxpython!
Trying to build dependents, and I'll send a new patch series.
--
Best regards,
Nicolas Graves
Reply sent
to
Andreas Enge <andreas <at> enge.fr>:
You have taken responsibility.
(Mon, 07 Apr 2025 08:12:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ricardo Wurmus <rekado <at> elephly.net>:
bug acknowledged by developer.
(Mon, 07 Apr 2025 08:12:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 75751-done <at> debbugs.gnu.org (full text, mbox):
Hello all,
from the discussion I deduce that you will still need a week or two
until the branch can be merged. So I am closing it momentarily, so that
the node branch gets a chance of being built on QA.
This does not prevent discussions from continuing on this bug.
Once you think you are ready, just rebase the python-team branch on a
recent commit known to the data service - I think it is one of the
commits shown in green at
https://data.qa.guix.gnu.org/repository/1/branch/master
If you then reopen the bug, the python-team branch should jump back to
its place at the front of the queue and be built again.
Chris, I wonder if we could add some way of interacting more directly on
QA than by closing and opening bugs? In this case, we could add a third
branch to the number of evaluations (which we might want to lower to 2
again once the python-team branch is back). But this would probably mean
reconfiguring one of the machines?
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Tue, 08 Apr 2025 19:48:01 GMT)
Full text and
rfc822 format available.
Message #121 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Hi,
I build/build-deps for 20 of the patches that Nicolas sent in https://issues.guix.gnu.org/77575. Pushed them to python-team.
I will also have a look at https://issues.guix.gnu.org/76835 which is build fixes only.
HTH,
Steve / Futurile
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 09 Apr 2025 14:23:04 GMT)
Full text and
rfc822 format available.
Message #124 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Andreas Enge <andreas <at> enge.fr> writes:
> If you then reopen the bug, the python-team branch should jump back to
> its place at the front of the queue and be built again.
>
> Chris, I wonder if we could add some way of interacting more directly on
> QA than by closing and opening bugs?
QA looking at what issues block each other is intended to provide a way
to tweak the order of branches in the queue, although maybe that's a
little more complicated to tweak than opening and closing issues.
> In this case, we could add a third branch to the number of evaluations
> (which we might want to lower to 2 again once the python-team branch
> is back). But this would probably mean reconfiguring one of the
> machines?
I'm fine with this being tweaked in the code, it's just the number
around here:
https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/tree/guix-qa-frontpage/manage-builds.scm?h=trunk#n446
[signature.asc (application/pgp-signature, inline)]
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 10 Apr 2025 08:30:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 10 Apr 2025 08:37:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Hello all,
since the QA build farm has currently spare capacity, I have taken the
liberty to rebase the python-team branch on master (only one merge
conflict in the copyright headers) and to reopen this issue.
It should be processed by the data service soon.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Thu, 10 Apr 2025 08:39:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Am Wed, Apr 09, 2025 at 03:22:42PM +0100 schrieb Christopher Baines:
> I'm fine with this being tweaked in the code, it's just the number
> around here:
> https://git.savannah.gnu.org/cgit/guix/qa-frontpage.git/tree/guix-qa-frontpage/manage-builds.scm?h=trunk#n446
Okay. It would probably be nicer to have this as a parameter to the
service, so we could just reconfigure bayfront without updating the
qa-frontpage source code itself.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 16 Apr 2025 10:08:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 75751 <at> debbugs.gnu.org (full text, mbox):
Hello,
after the r-team branch was merged, I have rebased python-team and
pushed. There was just one patch that did not apply; related to R and
not Python, so maybe it has ended up on this branch by mistake.
I have dropped it and opened a separate issue:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77839
I will be away for about 10 days, please feel free to merge, close
this bug and delete the branch if everything is ready in the meantime.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75751; Package
guix-patches.
(Wed, 16 Apr 2025 10:30:06 GMT)
Full text and
rfc822 format available.
Message #138 received at 75751 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Andreas,
Thanks for that.
I may be available to park this train to the final destination =)
<https://mail.gnu.org/archive/html/guix-devel/2025-04/msg00112.html>
CCed all participant in discussion on this thread if anyone may
volunteer time just in case.
--
Oleg
[signature.asc (application/pgp-signature, inline)]
Reply sent
to
Sharlatan Hellseher <sharlatanus <at> gmail.com>:
You have taken responsibility.
(Sat, 19 Apr 2025 16:04:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ricardo Wurmus <rekado <at> elephly.net>:
bug acknowledged by developer.
(Sat, 19 Apr 2025 16:04:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 75751-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I've rebased and merged python-team to master, pushed and delete after
that.
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e417d6fe8182c0b42b113490fec6a0297fd68fed
--
Oleg
[signature.asc (application/pgp-signature, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 18 May 2025 11:24:12 GMT)
Full text and
rfc822 format available.
This bug report was last modified 34 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.