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

[Daniel Gröber]

Hi Patrick,

On Sun, Mar 09, 2025 at 07:03:38PM +0100, Paebbels wrote:
> I'm actually a bit lost as to what the official bug tracking system (BTS)
> of Debian is. 

That would be https://bugs.debian.org.

See https://www.debian.org/Bugs/Reporting for a step by step howto.

> * there is a GUI tool (reportbug) that can only be used on Linux / Debian -
> I have a Windows environment and

reportbug is a commandline tool. You may be thinking of reportbug-gtk which
is a GUI frontend to the former AFAIK. I've never used it myself TBH.

>   use Debian an CI Server or in WSL, so no GUI to use that specific tool.

You can use reportbug on a server (over SSH) or in WSL no problem. Should
just-work^TM.

If you like using the GUI frontend remotely via SSH X11 forwarding is also
an option. See ssh(1) -X option.

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

Ignore the Salsa issue tracker (and MRs) when it comes to reporting unless
you know for a fact the people that feel responsible for a given package
use and respond to them.

Unfortunately the defaults are such that not everyone that should even gets
notification emails from Salsa.

OTOH you can expect maintainers/teams to actually get BTS reports. For the
most part anyway :D.

> * And in parallel there is launchpad.

Launchpad is almost exclusively an Ubuntu thing these days. Ignore it for
reporting unless the a problem is happening on an Ubuntu system.

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

You'll be shocked to learn that Ubuntu doesn't do that much work on their
own other than slapping their brand all over our work :-).

> > That for sure depends a bit on the point of view. :-)
> 
> I don't want to argue about the Filesystem Hierarchy Standard (FHS).

Aww, you'll learn to love it yet if you hang out with more Debian people :P

> 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.

I did some work to that end that landed in 3.0.0 to enable libghdl in
Debian for my yosys-plugin-ghdl package:

  https://github.com/ghdl/ghdl/issues?q=is%3Apr%20involves%3ADanielG%20

  https://salsa.debian.org/electronics-team/ghdl/ghdl/-/merge_requests/3

Andreas spun his own 2.0.0 upload in the end, unfortunately not
incorporating my debian/ changes that were tightly coupled to what I got
merged upstream. So when 3.0.0 rolled around Simon and I did an NMU upload
for 3.0.0 fixing some of that up again, but I haven't kept close tabs on
what Andreas/ghdl have been up to since.

> 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.

Gah. libghdl's path fiddlyness is the bane of my existence. I guess we need
at least a simple libghdl build-test here.

> > 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.

We already run GHDL's testsuite.sh. See debian/tests/ghdl-tests.

I don't think we have any of the pyGHDL stuff enabled so testing for that
is moot until someone musters the motivation to enable and maintain that
;-)

Whether libghdl works at all should ideally already be covered by
yosys-plugin-ghdl's autopkgtests blocking ghdl's testing migration.

Autopkgtest is a distro-wide testing mechanism we have in Debian, it can
prevent changes in dependent packages such as ghdl from breaking users such
as yosys-plugin-ghdl by blocking migration of the offending package (ghdl
in this example) from unstable to testing. Thereby keeping testing working
overall.

Trouble is yosys-plugin-ghdl isn't in testing since I haven't been keeping
up with it and so this mechanism is currently not engaging.

Adding a dedicated test directly in ghdl is another option. We could just
try to build a trivial libghdl test program.

> 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.

Debian is a constitutional do-ocracy. If you think it out to be done then

  Do It.

However don't tell others they "should". You "should" ask nicely for their
help in Doing It instead ;-)

This idea of no obligation is quite central to how Debian functions to the
point where it's literally the first rule in the project's constitution:

> 2.1. General rules
> 
> 1. Nothing in this constitution imposes an obligation on anyone to do work
> for the Project. A person who does not want to do a task which has been
> delegated or assigned to them does not need to do it. However, they must
> not actively work against these rules and decisions properly made under
> them.

https://www.debian.org/devel/constitution

Nobody is stopping you from reading and understading our existing patches
and submitting them upstream for review if you think that's the right thing
to do.

I don't understand the rationale for many of them and don't have the
capacity and motivation to work it out in a way that I'd be comfortable
asking for those changes upstream, but maybe you're brighter and more
tenacious than me :-).

>  > 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. So it
> looks/feels like GHDL is stuck in sid.

GHDL is currently in stable, testing and unstable
(cf. https://tracker.debian.org/pkg/ghdl "versions" box) and has been in
every release going back to at least buster.

I'm not sure what you're looking at. Are you sure you're on a Debian system
or is this Ubuntu? Check `cat /etc/os-release`. Maybe you just last checked
before [2024-12-07]. See below.

> 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?

Time and elbow—, eeeer, keyboard grease :D

https://debian-handbook.info/browse/stable/sect.release-lifecycle.html

Usually tracker.debian.org will list the reasons for why a package isn't
migrating in the "testing migrations" box in a section called
"excuses". For a fun zoo of reasons a look at
https://tracker.debian.org/pkg/yosys-plugin-ghdl might be instructive (gosh
I really have to get that updated before the trixie freeze :D).

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

[2023-02-13] ghdl 2.0.0+dfsg-6.2 MIGRATED to testing
[2023-09-16] ghdl REMOVED from testing
...
[2024-12-07] ghdl 4.1.0+dfsg-4 MIGRATED to testing

So? Just normal Debian things. Packages can fall out of testing when
updates of dependencies happen in unstable, break the package, someone (or
an automatism) reports the breakage as a release critical bug and no fixing
upload happens within a certain amount of in time (1-2w, depends on the
circumstances).

In this case (see
https://tracker.debian.org/news/1463719/ghdl-removed-from-testing/) the
reason for ghdl being removed was
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042276 "ghdl: FTBFS:
/bin/sh: 1: g++-12: not found". This particular bug was (trivially) fixed
by Simon and yours truly in 3.0.0+dfsg-1. I'm not sure why ghdl didn't
migrate again at that point but there are many possible reasons from the
trivial to the weeks of work.

Checking build logs

https://buildd.debian.org/status/logs.php?pkg=ghdl&arch=amd64
https://buildd.debian.org/status/logs.php?pkg=ghdl&arch=arm64
https://buildd.debian.org/status/logs.php?pkg=ghdl&arch=armel
https://buildd.debian.org/status/logs.php?pkg=ghdl&arch=ppc64el
https://buildd.debian.org/status/logs.php?pkg=ghdl&arch=ppc64

Our 3.0.0+dfsg2-1 upload seems to have been problematic on arm64
https://buildd.debian.org/status/fetch.php?pkg=ghdl&arch=arm64&ver=3.0.0%2Bdfsg2-1&stamp=1696867561&raw=0
(gna testsute failure) which would explain the blocked testing migration.

Andreas (or upstream) seems to have fixed this in 4.1.0+dfsg-1/-2 but I'm
sure in the meantime three more RC bugs popped up and he needed time to fix
them. You can read the d/changelog and referenced bug for details. ghdl is
very suseptible to toolchain breakage as changes in *either* gcc or llvm
can break all of it. Just read some of the old severity:serious bugs
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;include=severity%3Aserious;src=ghdl
(bottom is newer).

Anyway. Maintainers tend to be busy people so how long it takes for someone
to find the time and motivation to work on getting a package fixed and back
into testing can vary wildly.

Sending a friendly "I'd like to have $package, need any help?" report when
you notice this state of affairs tends to grease the wheels by providing
some motivation and urgency.

I like to think of Debian not so much as product to be consumed, but as
neverending collaboration between users and developers. Maybe that
perspective helps you see more clearly what's going on.

> > 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.

The value of Debian packages lies not in the snapshot-in-time packaging
code and it's quality but in continuance and maintainance over time as
external changes happen. That just naturally creates challenges and
compelxity.

You should consider that Debian solves a harder technical problem than many
toy upstream packages do because we require releases to be
self-contained. If a package doesn't build with the toolchain(s) from that
very same release it gets kicked out of testing to provide strong
motivation to maintainers for fixing it before the next release.

This is in stark contrast to what upstream packages usually do: Just pin
the build container to, say, Debian 9, make the binary packages compatible
with many distros/releases (easy'ish) and only upgread if the hurt of
legacy build environment becomes too much.

Yes you can have faster turnaround times, less fixing work and provide
value to users that need bleeding-edge features with that approach, but
fewer people will feel comfortable installing them (and rightfully
so). Whereas many more people (and organizations!) don't blink an eye at
the prospect of a `apt install` call for a very long list of reasons.

Personally I feel my unpaid effort is better spend, more rewarding and more
readily applicable to my goals doing the harder work that benefits more
people. You should ask yourself who you want to do your packaging work for
and why (and why they aren't paying you unless they==you :P).

I'd say maybe that's just me, but hey look at all those other people
actively working on Debian https://contributors.debian.org/. We may be
crazy but at least we're crazy together :D

--Daniel <3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20250310/7b533571/attachment.sig>