Archlinux32: python & lots of dependent packages out of sync
Hi, in the Archlinux32 repos, a lot of packages that install Python modules need rebuilding. It would be nice, if upgrading Python and such packages could somehow be coordinated, such that a new release of the Python interpreter and these packages are only pushed after all of them have been rebuilt. I don't know how Archlinux handles this, but I never noticed such problem there. A cursory look through the logs seems to show that many of the packages I'm complaining about failed building, because a dependency wasn't built/updated first. For instance Borg failed because of python-jaraco.functools, which failed because the dependency python-setuptools is missing, which should have been pulled in by python-setuptools-scm. Here is part of the build log for python-jaraco.functools:
(2/3) installing python [######################] 100%
Optional dependencies for python python-setuptools python-pip sqlite [installed] mpdecimal: for decimal xz: for lzma [installed] tk: for tkinter (3/3) installing python-more-itertools [----------------------] 0% (3/3) installing python-more-itertools [######################] 100%
[?25h==> Checking buildtime dependencies... ==> Installing missing dependencies... [?25lresolving dependencies... looking for conflicting packages...
Packages (15) perl-error-0.17029-5.0 perl-mailtools-2.21-7.0 perl-timedate-2.33-5.0 python-iniconfig-2.0.0-2.1 python-packaging-23.1-1.1 python-pep517-0.1-1.3 python-pluggy-1.0.0-2.1 python-typing_extensions-4.7.1-1.0 git-2.40.1-1.0 python-build-0.1-1.3 python-installer-0.1-1.3 python-jaraco.classes-3.2.3-1.1 python-pytest-7.4.0-1.0 python-setuptools-scm-7.1.0-4.1 python-wheel-0.1-1.3
Total Installed Size: 49.66 M As you can see, python-setuptools-scm gets installed without its dependency python-setuptools. Could someone please have a look at
this? BR
On Thu, 7 Sep 2023, Markus Schaaf wrote:
Hi,
in the Archlinux32 repos, a lot of packages that install Python modules need rebuilding. It would be nice, if upgrading Python and such packages could somehow be coordinated, such that a new release of the Python interpreter and these packages are only pushed after all of them have been rebuilt. I don't know how Archlinux handles this, but I never noticed such problem there.
A cursory look through the logs seems to show that many of the packages I'm complaining about failed building, because a dependency wasn't built/updated first. For instance Borg failed because of python-jaraco.functools, which failed because the dependency python-setuptools is missing, which should have been pulled in by python-setuptools-scm.
Here is part of the build log for python-jaraco.functools:
(2/3) installing python [######################] 100%
Optional dependencies for python python-setuptools python-pip sqlite [installed] mpdecimal: for decimal xz: for lzma [installed] tk: for tkinter (3/3) installing python-more-itertools [----------------------] 0% (3/3) installing python-more-itertools [######################] 100%
[?25h==> Checking buildtime dependencies... ==> Installing missing dependencies... [?25lresolving dependencies... looking for conflicting packages...
Packages (15) perl-error-0.17029-5.0 perl-mailtools-2.21-7.0 perl-timedate-2.33-5.0 python-iniconfig-2.0.0-2.1 python-packaging-23.1-1.1 python-pep517-0.1-1.3 python-pluggy-1.0.0-2.1 python-typing_extensions-4.7.1-1.0 git-2.40.1-1.0 python-build-0.1-1.3 python-installer-0.1-1.3 python-jaraco.classes-3.2.3-1.1 python-pytest-7.4.0-1.0 python-setuptools-scm-7.1.0-4.1 python-wheel-0.1-1.3
Total Installed Size: 49.66 M As you can see, python-setuptools-scm gets installed without its dependency python-setuptools. Could someone please have a look at this?
BR
Hi Markus, theoretically, this should not happen: Packages are moved together with their dependencies from *-staging to *-testing and from *-testing to *. However, we are forced to relieve this restriction and move packages no-matter-what after a certain time (I think, it's currently 14 days), because: If we would strictly follow the restriction, basically all packages would get stuck in *-staging at some point. The reason for that is, that any no-matter-how-unimportant python package, that fails to compile, will block the transition of the built python, which in turn blocks all python packages. On the other hand, python itself seems to make trouble when compiling, mostly probably due to bootstrap issues. Upstream Archlinux does not have these issues, because they compile all packages manually - but they do not necessarily publish all those versions. I.e. upgrading python may (or may not - I'm not an Arch maintainer) involve some "bootstrap" or "shim" packages along the way, which never make it into the official repositories or - at least - never make it into core or extra. That being said: We're always happy about an additional pair of hands (plus eyes, and a brain), which run our testing repositories, notify us early about problems, send in patches to address compilation troubles, etc. pp. If you want to get started looking into python compilation errors, here is a list of problems: https://archlinux32.org/buildmaster/build-list.php?sort=blocks&q=python If you're more into reading my obscure bash and mysql code, then I challenge you to find (and report) bugs, so we can get rid of them: https://git.archlinux32.org/builder In any case, I'm always happy to hear from someone, that they're using archlinux32 :-D regards, Erich
Am 07.09.23 um 21:03 schrieb Erich Eckner:
Here is part of the build log for python-jaraco.functools:
Optional dependencies for python python-setuptools
I.e. not installed.
==> Installing missing dependencies... [?25lresolving dependencies... looking for conflicting packages...
Packages (15) perl-error-0.17029-5.0 perl-mailtools-2.21-7.0 perl-timedate-2.33-5.0 python-iniconfig-2.0.0-2.1 python-packaging-23.1-1.1 python-pep517-0.1-1.3 python-pluggy-1.0.0-2.1 python-typing_extensions-4.7.1-1.0 git-2.40.1-1.0 python-build-0.1-1.3 python-installer-0.1-1.3 python-jaraco.classes-3.2.3-1.1 python-pytest-7.4.0-1.0 python-setuptools-scm-7.1.0-4.1 python-wheel-0.1-1.3
As you can see, python-setuptools-scm gets installed without its dependency python-setuptools. Could someone please have a look at this?
Packages are moved together with their dependencies from *-staging to *-testing and from *-testing to *. However, we are forced to relieve this restriction and move packages no-matter-what after a certain time (I think, it's currently 14 days), because:
I already guessed that. On the other hand, pushing the new interpreter, without most of its applications working afterwards, seems much worse than skipping a release of Python.
If you want to get started looking into python compilation errors, here is a list of problems: https://archlinux32.org/buildmaster/build-list.php?sort=blocks&q=python
The build log I have quoted is from buildmaster and I believe to have identified a major blocker. I just can't guess what caused this. The original Archlinux package of python-setuptools-scm correctly specifies a dependency on python-setuptools: https://archlinux.org/packages/extra/any/python-setuptools-scm/
Dependencies (11) python-packaging python-setuptools python-typing_extensions python-build (make) python-installer (make) python-wheel (make) git (check) mercurial (check) python-pip (check) python-pytest (check) python-virtualenv (check)
whereas the version that is in pentium4/extra, for instance, looks like a non-working leftover from the bootstrapping you mentioned: https://www.archlinux32.org/packages/pentium4/extra/python-setuptools-scm/
Dependencies (4) (in database only) python-typing_extensions (python-typing_extensions, python-typing_extensions) not satisfiable dependency: "python-bootstrap" (make) python<3.12 (python, python, python) (link) python>=3.11 (python, python, python) (link)
If you're more into reading my obscure bash and mysql code, then I challenge you to find (and report) bugs, so we can get rid of them: https://git.archlinux32.org/builder
I want to keep this in mind, but I have a lot of work now manually building packages to get an old server working again. :-) It's too late already to roll-back the system update.
In any case, I'm always happy to hear from someone, that they're using archlinux32 :-D
And I'm thankful for all your work to keep it running. BR
participants (2)
-
Erich Eckner
-
Markus Schaaf