Package Details: python-jaxlib 0.4.21-1

Git Clone URL: (read-only, click to copy)
Package Base: python-jaxlib
Description: XLA library for JAX
Upstream URL:
Keywords: deep-learning google jax machine-learning xla
Licenses: Apache
Groups: jax
Conflicts: python-jaxlib
Submitter: daskol
Maintainer: daskol
Last Packager: daskol
Votes: 5
Popularity: 0.40
First Submitted: 2021-01-12 12:50 (UTC)
Last Updated: 2023-12-06 08:44 (UTC)

Latest Comments

1 2 3 4 Next › Last »

daskol commented on 2023-10-27 16:42 (UTC) (edited on 2023-10-27 16:50 (UTC) by daskol)

@mane.andrea I'm not sure that prepare/build is a bug. According to Arch Wiki

one rule of thumb is to put in prepare() the steps that should run exactly once after extracting the sources.

Envvars, indeed, should not be placed in prepare(). Anyway reporting an issue to yay could be a good idea to highlight sharp bits once again.

UPD I guess I know why yay runs prepare() and build() in different shell sessions: yay prompts a user to edit or view PKGBUILD.

You accidentally pushed

Sorry for that. I don't know how it could happen.

mane.andrea commented on 2023-10-27 00:15 (UTC)

You accidentally pushed

    pkgrel = 0

in .SRCINFO. I found out when I saw my PKGBUILD was not up-to-date even after I had synced yay.

mane.andrea commented on 2023-10-26 19:36 (UTC)

@daskol I think it's a good idea to submit a bug report to yay. Do you have any additional information that could be useful for the bug report? I.e. which is the specific part of the PKGBUILD that requires prepare and build be invoked sequentially? (Sorry if my understanding of the issue is superficial)

rekman commented on 2023-10-24 19:36 (UTC)

@daskol uggghhh....

daskol commented on 2023-10-24 19:32 (UTC)

@rekman Yes, it is. LLVM is transitive dependency via XLA and both XLA and LLVM are pinned by commit hashes. I tried to build with system's LLVM (bad idea).

daskol commented on 2023-10-24 19:30 (UTC)

@h3ss Indeed. @Henry-ZHR mentioned the issues regarding to yay. I consulted with some core packages and PKGBUILD docs and it turns out that prepare and build can be invoked separately in general. But some core packages ignore this rule since makepkg in contrast to yay runs all stages sequentially.

rekman commented on 2023-10-24 19:20 (UTC)

Is it really necessary to build llvm from source to build this package?

h3ss commented on 2023-10-21 13:47 (UTC)

@daskol I believe I have found the root cause of the lingering errors that myself and others have reported.

From what I can tell, the prepare function in the PKGBUILD is either not consistently being run with AUR helpers, or it is being run separately from the build, such that the environment variables don't carry over. This function doesn't necessarily get run anyway, for example if somebody were to pass the --noextract argument to makepkg it will not be run (and I see this being passed in the yay source code).

Would you please try moving the export JAXLIB_RELEASE=$pkgvar into the build function?

To test this, I used paru -U in the package directory. Initially, before I moved the export from the prepare to the build function, this failed with the same error that was seen when updating from the AUR. After I moved the export, it built successfully with the same command.

h3ss commented on 2023-10-21 04:05 (UTC) (edited on 2023-10-21 12:27 (UTC) by h3ss)

@daskol Every single time there's an update I have to manually do the install because of the error that @65a pointed out. It's pretty frustrating when these updates hit, and I watch it build for 15 minutes, only to have the perfectly fine .whl file get discarded, and have to start the build over again manually.

What's strange is I don't even have to modify the PKGBUILD, I just have to git clone and makepkg -si and it builds and installs fine. BUT, any attempt to install it using an AUR helper (I tried both Paru & Yay) fails with the error that people have been pointing out to you. Based on your previous comment, I also tried deleting the bazel cache (rm -rf ~/.cache/bazel/) before trying an install and that didn't help.

Can we please get a persistent reliable fix for this that works with AUR helpers like yay and paru?!

65a commented on 2023-10-16 21:10 (UTC) (edited on 2023-10-16 21:10 (UTC) by 65a)

I am still seeing this. Is there a packaging encapsulation leak or something that is preventing the new way from working?

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/lib/python3.11/site-packages/installer/", line 98, in <module>
    _main(sys.argv[1:], "python -m installer")
  File "/usr/lib/python3.11/site-packages/installer/", line 86, in _main
    with as source:
  File "/usr/lib/python3.11/", line 137, in __enter__
    return next(self.gen)
  File "/usr/lib/python3.11/site-packages/installer/", line 162, in open
    with zipfile.ZipFile(path) as f:
  File "/usr/lib/python3.11/", line 1284, in __init__
    self.fp =, filemode)
FileNotFoundError: [Errno 2] No such file or directory: '/nfs/home/65a/.cache/yay/python-jaxlib/src/jax-jaxlib-v0.4.18/dist/jaxlib-0.4.18-*.whl'