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

Sun Mar 9 18:03:38 GMT 2025

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. There are:
* email lists to discuss packaging problems (this email list - seems to be
the wrong place for a real bug and its tracking)
* there is a special bugs at debian.org email address - but this is not a bug
tracking system, or?
* 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.
* Salsa is a GitLab-CE with issues (
https://salsa.debian.org/groups/electronics-team/ghdl/-/issues)
* 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

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

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

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.

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

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.

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

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

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

Kind regards
    Patrick Lehmann

Am So., 9. März 2025 um 08:07 Uhr schrieb Carsten Schoenert <
c.schoenert at t-online.de>:

> Hello Patrick,
>
> I'm not the primary maintainer of GHDL, that's Andreas Bombe (added to
> the recipients). But I'll try to give some feedback in general to your
> email.
>
> Thanks for reaching out to the Debian Electronics Team to talk about the
> packaging of GHDL! Debian in general has always an interest to have a
> good relationship to the upstream projects and maintainers.
>
> Am 08.03.25 um 16:28 schrieb Paebbels:
> > Hi,
> >
> > I would like to get in contact with the person(s) responsible for
> packaging
> > GHDL, so it can be updated and fixed for a v5.0.1 release. Currently the
> > packaging instructions produce broken installations on Ubuntu, Debian,
> ...
> > I assume any OS that uses apt has broken GHDL installations.
>
> That for sure depends a bit on the point of view. :-)
> Andreas is a long time Debian Developer and he has of course reasons why
> he is doing the packaging in Debian in the way it is.
> If I'm looking at your pointed issue on GH I can image for some of the
> points why you think what Debian/Ubuntu is doing is wrong Andreas has a
> different POV. I will not go into details here, that is best handled in
> my eyes by creating various issues in the Debian BTS, but based on my
> experiences where I had similar situations in and with other upstream
> projects it was often the case that upstream did not fully understand
> the FHS hierarchy and did only partially respecting the differences
> between the target platforms.
>
> Autotools and also CMake can be tricky I don't think I know every part
> and intention of these build toolchains ;-), in summary I strongly
> believe we have in Debian well experienced people who are also willing
> help to solve issues in regard of different target platforms and also in
> supporting multi architecture installations.
>
> > I suspect that installations are not tested, otherwise a test should have
> > discovered that problem.
>
> That again depends on what you/upstream think is a problem. The
> packaging of GHDL has some testing. For sure this can get improved, as
> mostly always it can. But writing tests has limitations (for me), I'm
> and also Andreas is doing the packaging in our free time.
>
> Debian has build up a CI infrastructure that is triggered always once a
> new version is uploaded to the archive, or some other package, like a
> build dependency, is going to change within the Debian archive. An
> failing test run in GHDL is then preventing the migration of the other
> package(s) that did trigger the test.
>
> We have within the debian/ folder the subfolder debian/tests/ which is
> holding all the data for these tests. GHDL has a rather small script
> right now.
>
> >
> https://salsa.debian.org/electronics-team/ghdl/ghdl/-/blob/master/debian/tests/ghdl-tests?ref_type=heads
>
> I believe Andreas is happy to get some help or suggestion what to add or
> how to improve the tests here.
>
> > I'm here to help the package maintainers understand how GHDL gets
> > configured, compiled, and tested so he/here/them can create a correct
> > package description. I can also explain GHDL's backend variants mcode,
> > llvm, llvm-jit and gcc.
> >
> > I would also like to understand how a new version can be triggered, so
> GHDL
> > could potentially release 4 times a year.
>
> We have a service in Debian named 'uscan' which will run I think once a
> day to check for new upstream versions. This service has already
> detected there is a new version of GHDL available. It's integrated into
> the package tracker website about GHDL. Have look at the main window in
> the middle, it's the first line there.
>
> > https://tracker.debian.org/pkg/ghdl
>
> I've upstreams who contact me privately to inform me about new versions
> of there project, which is nice. And often I get some extra news too by
> such emails.
>
> Another way you can walk is to open a bug issue with severity wishlist
> and the hint that a new version is available to get packaged. The
> package maintain will get then an email about a new bug report was raised.
> I think the most comfortable way is to use the tool 'reportbug' to do
> this, but this requires a running Debian system as the tool is specific
> to Debian. But you can also use a classical email to open a bug report.
>
> This is in principle writing an email to bugs at debian.org with some
> needed entries. You would need at least these entries in the body so the
> report gets connected to the src:ghdl package.
>
> > Source: ghdl
> > Version: 4.1.0+dfsg-4
> > Severity: wishlist
> >
> > Dear Maintainer,
> > your writing goes here...
>
> ....
> > I noticed many patches to GHDL. I would like to understand if GHDL
> > should integrate these changes e.g. into ./configure or ./Makefile.in.
> > Therefore
> > GHDL needs feedback from package maintainers, who report bugs and
> > suggestions.
>
> In general often some patches are specific to Debian, some other patches
> are something that should go to upstream. Most of the maintainers do
> write some explanation why the patch is needed and if the patch is from
> upstream or is only needed within Debian.
>
> Andreas has written so far I can see always some lines of explanation
> what the patch is about, what patches are good for upstream I can not
> judge. That's something Andreas would need to speak up. You can see all
> patches atm here.
>
> >
> https://salsa.debian.org/electronics-team/ghdl/ghdl/-/tree/master/debian/patches?ref_type=heads
>
> ...
> > The problems are summarized here:
> > https://github.com/ghdl/ghdl/issues/2710#issuecomment-2267471733
>
> These details are probably interesting for Andreas. As Matthias from
> Ubuntu also mentioned the interessting ones from your POV should get an
> bug report in the Debian BTS. So we can keep track of the issues in
> detail and an solved issue also would get documented if referenced in
> the Debian changelog.
>
> > I also noticed GHDL was packaged multiple times also for previous GHDL
> > releases, but none made it into official release repositories. What's
> > missing or failing to make GHDL available?
>
> Mostly it's personal resources and lack of time. :-)
> As Debian is a project based on volunteers it's always the question if
> we have enough volunteers with enough time.
> And GHDL is definitely some very specific software that requires good
> knowledge. This makes it even more difficult to find co-maintainers.
>
> > Should GHDL's pipeline provide *.deb files via nightly builds?
> > Currently, all apt based OS get a GHDL update once a year, if even.
>
> I'm mosty biased about upstream are providing such packages. For to
> often I'v seen a to poor quality of such *.deb packages and people do
> then complain within Debian that they have problems wich such packages
> as the think they are provided by Debian.
>
> But you are free to provide such packages! I think ideally Debian/Ubuntu
> can create something with you together so you as upstream and
> Debian/Ubuntu too have a winning situation!
>
> --
> Regards
> Carsten
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20250309/c6cf303a/attachment.htm>