[Pkg-electronics-devel] Packaging GHDL v5.0.1

[Carsten Schoenert]

Hello Patrick,

Am 09.03.25 um 20:03 schrieb Paebbels:
> Hello Carsten,
> 
> Thanks for your quick and detailed response.
> I'm actually a bit lost as to what the official bug tracking system 
> (BTS) of Debian is.

yeah, understandable. Debian is quite conservative about such things. We 
don't use Discord or similar, we mostly also don't use the Issue tracker 
functionality of our GitLab based instance called Salsa

https://salsa.debian.org

The system we use in Debian is named BTS (as short for Bug Tracking 
System) and an entry to this can be found under https://www.debian.org/Bugs/

There isn't a classical dashboard as a entry available, but if you know 
the (source) package name then you can easily get an overview of all bug 
reports for this package, for ghdl this is then

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=ghdl

This is linked from the tracker page for each package.

> There are:
> * email lists to discuss packaging problems (this email list - seems to 
> be the wrong place for a real bug and its tracking)

Yes, basically. The lists are for discussing mostly, but if someone 
creates a new bug report for a package the email about will get also 
forwarded to the mailing list, so also here for packages which have the 
maintainer set to pkg-electronics-devel at alioth-lists.debian.net

The list archive can be viewed here

https://lists.alioth.debian.org/pipermail/pkg-electronics-devel/

> * there is a special bugs at debian.org <mailto:bugs at debian.org> email 
> address - but this is not a bug tracking system, or?

Technically not, but to this address all new reports get send, the back 
end is reading some specific written lines (these "Control: $foo", 
"Version: $bla" ones e.g.) and writes the collected data into a database.

So no matter if you use the reportbug tool or a hand crafted email, the 
data will end in the Debian BTS.

> * there is a GUI tool (reportbug) that can only be used on Linux / 
> Debian - I have a Windows environment and
>    use Debian an CI Server or in WSL, so no GUI to use that specific tool.

reportbug can be used with a graphical frontend, but it will require a 
configured MTA on your system as it is generating a email, or you have 
configured it to spawn your MUA. If you are working on Windows you will 
need to use your preferred email client or run a Debian within a WSL 
setup maybe there you can work on a CLI.

The typical Debian Developer isn't using a graphical tool here, we can 
do the same with CLI tools and mostly quicker than using the mouse to 
open a UI tool. And obviously we don't work on a Windows system.

> * Salsa is a GitLab-CE with issues (https://salsa.debian.org/groups/ 
> electronics-team/ghdl/-/issues

Yes, Salsa is our VCS which is mostly used to work collaborative on 
packaging, this includes the option to use the CI that is integrated to 
build packages automatically and also to run some QA checks with that.

> * And in parallel there is launchpad.
>    Here I reported it already some long time ago, but no bug 
> classification and reaction.
> https://bugs.launchpad.net/ubuntu/+source/ghdl <https:// 
> bugs.launchpad.net/ubuntu/+source/ghdl>

Launchpad is Ubuntu, we or I at least don't look that much into issues 
at Launchpad because there is a company above that and is using Debian 
packages and offers service around this. That's totally fine for me, but 
I've low interest to fix issues in Ubuntu. If the issues get fixed in 
Debian than two distros have a win on that.

I guess Ubuntu has not that much interest in clearing the queue for GHDL 
because there are to less costumers who would be willing to pay for service.
I have more problems with Launchpad, people have often some PPAs 
configured and this makes it hard to tackle down the real issues because 
the PPAs often don't fulfill the QA standards that Debian has.

> So what's the correct (platform independent) interface to create an 
> account in?

If you want to report issues for Debian, then you will need to use the 
Debian BTS, that's the official place to report issues. You can 
reference of course to other bug reports that do exist elsewhere, no 
need to write down everything again.


>> That for sure depends a bit on the point of view. :-)
> I don't want to argue about the Filesystem Hierarchy Standard
> (FHS). There are most likely mistakes inside of GHDL's build and
> installation flow. But that's exactly what I request as a feedback
> to GHDL, so we can improve the build and installation already in
> GHDL. Please help us to improve it so Debian (and Ubuntu, Mint, ..)
> need fewer patches.

Sure, but I can't help further here, I not even have used GHDL yet. From 
here Andreas would need to step in.

> What I can clearly say is: After restructuring GHDL into multiple
> deb packages and by modifying paths, some parts of GHDL can't find
> all resources and it doesn't work. So that part is very clear. This
> is mainly libghdl..., because it was moved into a x86_64 specific
> directory without adjusting its search paths for the STD and IEEE
> libraries, src directory, etc.
As above, that's up to Andreas to say something to if he wants.

>> The packaging of GHDL has some testing.
> For testing, the GitHub pipeline of GHDL does such testing and I
> can help to select appropriate parts and scripts from the testsuite
> so Debian can run tests after packaging. There is a test for GHDL
> itself and one for libghdl + pyGHDL.
That would be the best if upstream and Debian can work together!

> For the other patches. Yes I see Debian specific patches like
> compile flags, but there are patches e.g. for other platforms. I
> think this should be pushed upstream to reduce patches at Debian and
> enable more users who compile from sources.
Yes, absolutely. Feel free to pick up some of them, we wont complain if 
the count of patches is getting less. :-)
But upstream has also mostly a better knowledge on some parts, so 
sometimes patches would need to get discussed to get them into the 
correct form upstream can accept them.

>> Mostly it's personal resources and lack of time. :-)

> Maybe my question was a bit unclear... If I understood the history
> of changes correctly, there have been many adoptions of GHDL's
> packaging for various GHDL versions. But, as far as I remember and
> as far as I can see in aptitude, there is no GHDL offered by Debian.

This is not true I think. It's split up into various packages for good 
reasons. The reasons in detail is something again that Andreas would 
need to explain.

In Debian unstable/sid and testing we have these packages atm.

> $ apt search ghdl
> ghdl/testing 4.1.0+dfsg-4+b1 amd64
>   VHDL compiler/simulator
> 
> ghdl-common/testing 4.1.0+dfsg-4+b1 amd64
>   VHDL compiler/simulator (common files)
> 
> ghdl-gcc/testing 4.1.0+dfsg-4+b1 amd64
>   VHDL compiler/simulator (GCC backend)
> 
> ghdl-llvm/testing 4.1.0+dfsg-4+b1 amd64
>   VHDL compiler/simulator (LLVM backend)
> 
> ghdl-mcode/testing 4.1.0+dfsg-4+b1 amd64
>   VHDL compiler/simulator (mcode backend)
> 
> ghdl-tools/testing 4.1.0+dfsg-4+b1 amd64
>   VHDL compiler/simulator (tools)
> 
> libghdl-4-1-0/testing 4.1.0+dfsg-4+b1 amd64
>   VHDL compiler/simulator (shared library)
> 
> libghdl-dev/testing 4.1.0+dfsg-4+b1 amd64
>   VHDL compiler/simulator (library development files)

For sure at least a Wiki page that could get referred to could help user 
to explain the package names and relations of these. It's not that we do 
not want this, it's mostly that someones needs to do this!

> So it looks/feels like GHDL is stuck in sid. It gets updated in sid,
> but it's not in bullseye, bookworm, ... right? So my question was
> more technical, what's missing so it gets moved further than sid?

In general Debian is using and taking two years time to create a new 
release, the intention is that all software in a stable release is 
working smoothly together.
This means also that we do not upgrade package versions once a new 
stable release is done. This is not always doable and we have exceptions 
for this rule. E.g. web browsers, some email clients, firmware packages 
and partially the kernel will get regular updated and new versions.

What you probably want and expect is that GHDL will get updates to more 
recent versions for a Debian stable release. You are not alone, people 
want to use a newer Libreoffice or a newer printing tool for example to 
get their new printer also running with Debian stable.

We have for this an area in the archive that is called backports, for 
bookworm, the current stable release, this is then bookworm-backport.

What is need here is to find people who are willing to work on packages 
that can go into this part of the archive.
As of now I've never seen that a user was requesting a version of GHDL 
prepared for backports. So Andreas has for sure refused to work on such 
packages, it can make  a lot of work to get them working. And we are 
back at the needed resources and willing contributors.

>  From history:
> * added to testing
> * removed from testing
> * ...

This happens if the package has some release critical bugs that are not 
fixed in time. To not block the whole archive the release team has 
decided that such packages will get kicked out of testing after 6 weeks 
if the issues are not getting solved. It means only they are not 
available and installable from the testing part. The version in stable 
isn't affected by this.

Again, this is a resource issue if the maintainer count is to low to get 
issues fixed in time.

>> I'm mosty biased about upstream are providing such packages
> Compared to MSYS2, the packaging for Debian is quite complicated, so
> I would like to avoid it. At least defining a new packaging recipe.
> I could imagine pulling the packaging code from Debian and providing 
> same quality *.deb files, but with a shorter turnaround.

I've no idea if packaging for Windows is complicated, my experience is 
that on Windows companies trying to build one package that fits all. 
This has ups and down. I've see far poor packages on Windows, but 
Windows is also not using some techniques and standards that are very 
common in the Linux world (e.g. symbol versioning). So it's difficult to 
compare I think.

I can image that you can basically pick up the Debian packaging for GHDL 
and build nightly packages by a pipeline on GitHub. Would be at least 
nice if this all here could and up in doing something like this.

-- 
Regards
Carsten