Arch Linux User Repository

But 91725e is 2 days newer than v5.1.1 tag. Why should I move it backwards? The only option I see is, we had v5.1.1 at ba3386, but then discovered 2 small problems on the next day and we fixed it immediately. Then v5.1.1 was moved to 91725e, which you used for packaging.

The only possibility I see for the current setup is that v5.1.1 was then overwritten back to an older state ?!?

Usually, I only do such critical adjustments, when a pipeline or release process failed to retrigger a build on GitHub. The fix is 91725e is needed for pacman packages.

This shouldn't happen again, or we need to create a v5.1.2 in such a case.

Yes, they are commits - Based on the old copy I have of the v5.1.1 source code, it would appear that v5.1.1 at some point pointed to commit 91725e47fdded6a3ac2e4e5ee5fa1adb4b8b4f6f (or a commit with the same source code).

The github activity log shows you deleted a v5.1.1 tag right around June (when I last built this package for me). I'm guessing that's where the checksum I first put in came from.

I don't think there's anything to do on your side now, just be careful not to reassign tags after making a release in the future. I've been guilty of doing this myself, too :P

Are these hashes referring to the ghdl/ghdl repository on GitHub?

v5.1.1 is at ba3368ed3ff7235650169a5f3c98f391199b411c (17.06.2025 - 21:06 UTC+02:00).

8fb617d744a974dcc03970500aeaf15315b07b64 is one commit ahead of v5.1.1

91725e47fdded6a3ac2e4e5ee5fa1adb4b8b4f6f is two commits ahead of v5.1.1

The fix if for packaging for MSYS2. These packages are released as nightly builds for MSYS2/MinGW64 and MSYS2/UCRT64.

Is there any mistake on our side (GHDL) or is this on your side (AUR package's code reference)?

That's... peculiar. I have an old copy of the v5.1.1 source code lying around (with the correct hash) and the only diff is:

diff -r old-ghdl-5.1.1/.github/workflows/Parameters.yml new-ghdl-5.1.1/.github/workflows/Parameters.yml
446c446
<             pacghdl_version="${ghdl_version}-1"
---
>             pacghdl_version="${ghdl_version}"
diff -r old-ghdl-5.1.1/NEWS.md new-ghdl-5.1.1/NEWS.md
4d3
< - Add llvm-jit build

So someone seems to have moved the v5.1.1 tag on the ghdl github back two commits for whatever reason? The following commits are no longer included in 5.1.1, but they were when I last updated the PKGBUILD:

• 8fb617d744a974dcc03970500aeaf15315b07b64
• 91725e47fdded6a3ac2e4e5ee5fa1adb4b8b4f6f

I'll just update the checksum with the same pkgrel for new installs, no reason to force rebuild of old ones.

TL;DR: Try again now, it should work.

NB: If you're using a helper such as paru, you'd need to do paru -S ghdl --redownload. Same for yay. I assume others have similar options.

Hi. I was trying to install the package using the Git clone URL, but the hash of the package didn't match the one from the PKGBUILD. I think the correct one is: aca5d20522ef9b8e273e95c9157d2d3f77f6e40a4fdeee431fa330885bd78f7f

I'm new to this stuff, so I'm not sure if this is the right way to report it.

My reasoning for ghdl vs ghdl-mcode is that ghdl configure defaults to mcode.

OK.

The python-pytooling dependency is a check dependency.

Maybe my explanation wasn't good enough.

As libghdl isn't needed by GHDL itself and libghdl being like GHDL but as a shared object file, pyTooling is only needed when building libghdl.so and then running the tests in testsuite/pyunit. Which makes only sense if your packages deploys libghdl.

Packaging GHDL could be simplified as follows:

• do not build libghdl (because not needed by ghdl itself). It also has no header file.
• remove pyTooling dependency
• do not run testsuite/pytest testcases, because these test the Python bindings using libghdl.

Somewhen later, if you like to provide a pyGHDL package, you could:

• build libghdl (unfortunately, there is no configure switch to disable building GHDL)
• require pyTooling as dependency
• run testsuite/pyunit as a standalone test

This is how I currently run the pipeline on GitHub.

But I hadn't noticed they didn't even link each other - that's... odd.

I know ... but that's how Tristan provides it today. I'm willing to support you and others, if maintainers create an issue at GHDL and request a structural change, so the GHDL executable becomes more like a frontend and all algorithms are inside of libghdl for shared usage (by the CLI frontende and by Python).

If there are any other patches or modification you need to have it easier in packaging, please report these too. I noticed Debian / APT applies patches as hell and there is no feedback to the orignal source. So if GHDL makes your maintainer life more complicated, please report it, and we check what we can do in ./configure or Makefile.in for Arch Linux.

• My reasoning for ghdl vs ghdl-mcode is that ghdl configure defaults to mcode. Also, as long as this package is in the AUR and users have to compile it, it is the one they should install to try out ghdl given the current state of packaging & ghdl.
• Thanks for the additional background info, that's all good to know for (near) future efforts.
• Package groups don't really make sense for conflicting packages - they also don't work on the AUR.
• All ghdl variants should be conflicting already, though I consider this to be less than ideal. I was planning to give building compatible packages a shot. Possibly something like what's done with java versions, possibly providing differently named binaries. idk yet.

The python-pytooling dependency is a check dependency. This means that you do not need it to install the package, but you do need it to build the package (albeit you can skip the test suite during makepkg with --nocheck).

I'll dig into what's possible with the current configure script some more before I have an opinion on ghdl/libghdl. But I hadn't noticed they didn't even link each other - that's... odd.

I haven't looked much into pyGHDL yet, but noted for the future.

Here are my hints:

• Arch should provide ghdl-mcode, ghdl-llvm and ghdl-llvm-jit
• ghdl-gcc can be obsoleted, because GCC backend will be dropped.
  The last missing feature (code coverage) was implemented in the mcode backend for 64 bit.
• LLVM-JIT is a new backend supporting LLVM compilation in-memory like mcode. (experimental)
• It looks like a package group /could/ be used to select which ghdl variant to install.
  https://wiki.archlinux.org/title/Meta_package_and_package_group
  Alternatively, a meta package could be used to refer to the preferred ghdl backend variant.
• All variants of ghdl should be marked as conflicting towards the other variants.

GHDL (mcode, llvm, llvm-jit, gcc) does not depend on python-pytooling nor python-pyghdl. GHDL itself as a binary doesn't need any Python.

The shared library (libghdl) created by GHDL is a standalone file, containing like 90% of the GHDL's executable. Please consider ghdl and libghdl two different products. In future, the ghdl executable /could/ be dependent on libghdl, but that's currently not the case.

For the usecase of Python (pyGHDL), I suggest this dependency chain:

• pyGHDL -> pyTooling
• pyGHDL -> libghdl -> (libgnat, libllvm if llvm backend)
• pyGHDL -> pyVHDLModel -> pyTooling

The best way to deploy pyghdl is a wheel file (or similar) that installs pyGHDL Python files, pyTooling + other Python dependencies and the so-file into site-packages. This also allows independent maintenance of pyGHDL and GHDL itself.

pyGHDL as a Python binding is tightly coupled to the shared object file.

I never considered your comment to be an attack. I was merely responding and disagreeing. There were never any hurt feeling involved ¯_(ツ)_/¯.

You were right to be confused, I should have referenced mcode. I'd originally set out to make a generic ghdl package, but then I found out that you cannot compile all ghdl backends together. So I then made it into a sane default but forgot to update the description.

On the conflicts part: I like the status quo. I think it makes more sense for other packages to declare conflicts (maybe someone would like to make a package that is not in conflict if that is even possible).

My comment was definitely not ment as an attack. I just spotted your package yesterday and was confused for a suprisingly long time about what backend this used and if ghdl-gcc was even relevant anymore. That is why I made the comment at all. Feel free to leave the name of the package as-is.

On the conflicts part: until yesterday you could install both ghdl and ghdl-gcc, and the first complaints would arrive very late (when Pacman tries to install some files owned by the other package). So ghdl and ghdl-gcc are definitely in conflict. I updated the conflicts array of ghdl-gcc to fix it, and looking at the example in https://wiki.archlinux.org/title/PKGBUILD#conflicts I am no longer sure if your package should conflict with ghdl or not. You could indeed argue that this is the default GHLD (Netbeans in the example), and ghdl-gcc is then like netbeans-cpp, and should provide ghdl and conflict with ghdl.

Anyhow, ghdl and ghdl-gcc are in conflict now as they should be.