Arch Linux User Repository

@carlosal1015 Thanks.

xtensor is not longer a dependency.

» You shouldn't put that in a PKGBUILD ...

Thank you for your opinion

» If you read the AUR guidelines

Yes, I read them.

» This package is tied to the 0.6.0 release

No, it isn't. It is tied to the Git sources of the release branch

» even if from a release tarball

That is the difference between what you call a "tied" version and Git sources

» so this on adds nothing to the AUR (sic)

Thank you for your opinion.

» This final gripe is what's bothering me

Don't be bitter. Be creative! there was another basix package before mine (I guess it's gone now...). Here is a name for you: fenics-basix-main-git. It's that simple. What's more: basix-git. Or: my-flavour-basix-git. Whatever you want. Another one fenicsx-basix-git. Sooo many options.

Just a few notes then:

In this particular case, it's the locale that I like.

You shouldn't put that in a PKGBUILD, the locale you prefer should be in /etc/locale.conf. Otherwise you're overriding users' personal preferences, making the PKGBUILD less useful.

As for the CFLAGS, they should be set in your makepkg.conf. In some particular cases (if the package compilation is brittle) it's acceptable to override them, but in this case it doesn't make sense: the package compiles just fine without that.

From the description of this package: "...(C++ and Python from git release)"

If you read the AUR guidelines, the -git suffix is reserved for "Packages that build from a version control system and are not tied to a specific version". This package is tied to the 0.6.0 release, isn't updated since Jan 11, and so it shouldn't have the suffix. Tt's also redundant because there's already a basix package building from the exact same sources (even if from a release tarball), so this on adds nothing to the AUR.

This final gripe is what's bothering me, because I have a PKGBUILD ready to submit under this name, which unfortunately is already taken.

First of all, sorry if I came out as a snob.

Not really.

I just can't understand what's that doing in the PKGBUILD

Yes, I feel you: There are so many things that I don't understand about other packages as well. In this particular case, it's the locale that I like.

The same applies to the CFLAGS stuff

(bis)

Shouldn't it be tracking main?

From the description of this package: "...(C++ and Python from git release)"

Would you accept a revised PKGBUILD for this package, tracking main? I don't mind maintaining it.

I would try a package like that myself, but this one in particular is for a more "stable" version. I warmheartedly invite you to create a package to track main.

I need to get the git version (0.7.x)

Good luck. Seems that you are doing cool stuff! [EDIT] In the meantime, you can try changing

git checkout origin/release

into

git checkout origin/main

I got: ==> Finished making: fenics-basix-git 0.1.0.324.g983747fa-1

First of all, sorry if I came out as a snob.

Dolfinx version 0.6 is broken in archlinux (because of python 3.11), and I need to get the git version (0.7.x) of the package working.

Would you accept a revised PKGBUILD for this package, tracking main? I don't mind maintaining it.

Ah sorry, the pybind11 problem was because I was building inside a conda env..

I'm now hitting the int32_t problem though.

I won't create a patch, because I'm sure that it will be fixed very soon upstream.

About that, the PKGBUILD is checking out origin/release, which hasn't been touched since Jan 11... Shouldn't it be tracking main?

I've submitted a PR upstream: https://github.com/FEniCS/basix/pull/691

EDIT: which probably isn't needed now, because the header got implicitly included

I have pybind11 installed, and the numpy.h header seems to be present:

$ pacman -Ss pybind11
extra/pybind11 2.11.1-1 [installed]
    A lightweight header-only library that exposes C++ types in Python and vice versa

$ pacman -Ql pybind11|grep numpy
pybind11 /usr/lib/python3.11/site-packages/pybind11/include/pybind11/numpy.h

Now regarding the "irish setup", I know I can change it. I just can't understand what's that doing in the PKGBUILD.

The same applies to the CFLAGS stuff, most of it should be in makepkg.conf. Some of the CFLAGS in the PKGBUILD are even more aggressive than what I have in my own makepkg.conf.

I'm sorry I can't reproduce your error. Make sure that you have pybind11 installed (it's part of the requirements). Good luck.

If anyone is having issues with int32_t, add #include <cstdint> to basix/cpp/basix/finite-element.h. I won't create a patch, because I'm sure that it will be fixed very soon upstream.

(makepkg -oC && makepkg -ef): ==> Finished making: fenics-basix-git 0.6.0-3

You are right. It's also failing for me. I don't promise to fix it in the next couple of weeks, but I will. In the meantime, you can always resort to the other packages in AUR for FEniCSx.

About the Irish setup... it's payback time! (kidding: just change it).