Arch Linux User Repository

If using an AUR helper and getting a failing checksum on the most recent update: Clear your cached copy of the source archive.

@keiichiiownsu12 I just tested and this does seem to build fine in a clean chroot so it's most likely something about your python environment.

@kousu yes I was giving those as examples. That is the first time this has happened with this package and using archives is standard practice. Again, Arch packaging guidelines dictate the use of that line for building python packages that have been updated to be in line with PEP 517. AUR packages are custom packages built for your system, the AUR is only here to provide shared PKGBUILDs for convenience and collaboration but builds are not assumed to be fully reproducible and are not isolated from the packager's system. For isolation, the Arch-way is to use a clean chroot.

Also thank you so much for maintaining this package. I'm using it because I need to use fsleyes and it feels cleaner to use pacman than pip to manage that piece of software.

Thanks for filling me in @liamtimms. I hear you. Python packaging is a huge mess, I think we can all agree D:

The checksums for octopi and paru seem to be stable, or at least not have changed since they the last versions:

$ _githubuser=aarnt; _githubrepo=octopi; _pkgtagname=v0.14.0; curl -JL https://github.com/${_githubuser}/${_githubrepo}/archive/refs/tags/${_pkgtagname}.tar.gz | sha256sum
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 1495k    0 1495k    0     0  1099k      0 --:--:--  0:00:01 --:--:-- 12.4M
9b548661807fe8eecc20726a4aefa25658c4ce1bf1bc8f51b54829809d76f12d  -

$ pkgver=1.11.1; curl -JL https://github.com/Morganamilo/paru/archive/v$pkgver.tar.gz | sha256sum
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 7922k  100 7922k    0     0  2001k      0  0:00:03  0:00:03 --:--:-- 2496k
42cefa8cdf48e3aec3f9922235f1e1126a9fe3262f1644494e1be51980e520d8  -

But the checksum that was in the PKGBUILD 844d2ef7c04376068dcc8ac2daaa2842d2a06812c283bc97dd8fe6b0c6dfa03b03f4413e2061feefffcb257396e1481e4419cf82a0e108149cbdca1336e16e64 mismatches what I'm currently getting from GitHub:

$ _pkgname=nibabel; pkgname=python-$_pkgname; pkgver=5.0.0; curl -JL https://github.com/nipy/${_pkgname}/archive/${pkgver}.tar.gz | sha512sum
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 4375k    0 4375k    0     0  2204k      0 --:--:--  0:00:01 --:--:-- 3136k
5f27c03518c47856ecb33b878e9969ea33c7ebb717e6f4f9d89d9fdf415459e47675353051cdb824efea4e6a819759e0bf61cf49caa7212411c63423a77ed0d4  -

I'm sure I've seen GitHub regenerate those source archives and change their checksums before. I see you've switched to using the PyPI archive, that'll help a lot :)

I realized that python -m build is always going to prefer my local env if I have one; since python-build is already in makedepends, I wonder if replacing python -m build with the absolute path /usr/bin/pyproject-build would be more stable?

If using an AUR helper and getting a failing checksum on the most recent update: Clear your cached copy of the source archive.

@kousu

“The checksum needs to be "SKIP" if you're going to download from GitHub's archive links; those links are generated on the fly and then temporarily cached”

That’s not actually true. The vast majority of AUR PKGBUILDs use GitHub archives (ripgrep for it inside pikaur’s cache or look at some of the top AUR packages like Octopi https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=octopi or Paru https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=paru if you don’t believe me). This PKGBUILD has used GitHub archives for over 6 years without issue https://aur.archlinux.org/cgit/aur.git/commit/?h=python-nibabel&id=5241c7ac58fa3a01be91ec137d7fbb6f04639372. However, there are things that can happen upstream to throw it off, it looks like that happened here and upstream recently recommended switching to pypi tar balls. I will do that tonight. edit: took care of it now with modifications for official arch guidelines

As for the --no-isolation flag: this is the recommended flag for Arch’s python packaging guidelines - https://wiki.archlinux.org/title/Python_package_guidelines#Standards_based_(PEP_517)

I am extremely loath to change from the standards-based approach without understanding exactly what is going wrong on the user side, but it’s true we are having some growing pains with changes to python packaging and builds recently. Arch packages are built as simply as possible and can be affected by changes to your local environment very much by design. You may be interested in building in a clean chroot https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot if your local environment is throwing off builds. I think both you and @keiichiiownsu12 may be encountering issues with python paths, python virtual environments, mixing pip with system packages, having multiple python distributions active (eg. Anaconda's python distribution vs Arch's python distribution), or something else of that nature. It's hard to debug from here and pin down which of those might be affecting you as it isn't reproducible on my side.

I did pikaur -S python-nibabel (against this version of the PKGBUILD) and got two problems. These seem to be different in detail but similar in outline to the other problems people reported:

==> Retrieving sources...
  -> Downloading nibabel-5.0.0.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--      0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--      0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 1794k    0 1794k    0     0  1660k      0 --:--:--  0:00:01 --:--:-- 166100 4375k    0 4375k    0     0  2145k      0 --:--:--  0:00:02 --:--:-- 2693k
==> Validating source files with sha512sums...
    nibabel-5.0.0.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!

Command 'makepkg --force' failed to execute.

The checksum needs to be "SKIP" if you're going to download from GitHub's archive links; those links are generated on the fly and then temporarily cached; the timestamps change each time GitHub regenerates those files, e.g. the one I have is dated right now:

$ gzip --verbose --list nibabel-5.0.0.tar.gz 
method  crc     date  time           compressed        uncompressed  ratio uncompressed_name
defla 61dd531b Feb 10 12:19             4480342            69632000  93.6% nibabel-5.0.0.tar

Skipping the checksums, the second problem was:

==> Starting build()...
Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 187, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.10/runpy.py", line 146, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.10/runpy.py", line 110, in _get_module_details
    __import__(pkg_name)
  File "/home/kousu/.local/lib/python3.10/site-packages/build/__init__.py", line 36, in <module>
    import pep517.wrappers
ModuleNotFoundError: No module named 'pep517'
==> ERROR: A failure occurred in build().
    Aborting...

Command 'makepkg --force --skipchecksums' failed to execute.

this seems to be because at some point I did pip install --user build, and that version is. I did

$ rm -r ~/.local/lib/python3.10/site-packages/build*

and that let the build succeed.

But the PKGBUILD shouldn't be looking in ~/.local/lib, because it's building a system package. The --no-isolation flag is probably wrong. But maybe there is more we can do to isolate the build?

@keiichiiownsu12 that's very strange since python -m build is working for both me and @hottea . I can try switching to hatch build and see if it makes a difference on my system later today.

Not building from a clean chroot, but found something interesting.

When building with new dependencies you added, I still get the dependency check error I posted about (all dependencies are installed on system). Adding --skip-dependency check leads to a LookupError: setuptools-vcm cannot detect any version info from nibabel.

Digging around, I found the merge request on nibabel where they switched to hatch / hatchling (which I assumed you also stumbled on). Changing python -m build call to hatch build allowed me to successfully build the package.

You could also check this PKGBUILD, which works great for me.