<div dir="ltr"><div>Hello Carsten,</div><div><br></div><div>Thanks for your quick and detailed response.</div><div>I'm actually a bit lost as to what the official bug tracking system (BTS) of Debian is. There are:<br>* email lists to discuss packaging problems (this email list - seems to be the wrong place for a real bug and its tracking)</div><div>* there is a special <a href="mailto:bugs@debian.org">bugs@debian.org</a> email address - but this is not a bug tracking system, or?</div><div>* there is a GUI tool (reportbug) that can only be used on Linux / Debian - I have a Windows environment and<br>  use Debian an CI Server or in WSL, so no GUI to use that specific tool.</div><div>* Salsa is a GitLab-CE with issues (<a href="https://salsa.debian.org/groups/electronics-team/ghdl/-/issues">https://salsa.debian.org/groups/electronics-team/ghdl/-/issues</a>)</div><div>* And in parallel there is launchpad.<br>  Here I reported it already some long time ago, but no bug classification and reaction.<br>  <a href="https://bugs.launchpad.net/ubuntu/+source/ghdl">https://bugs.launchpad.net/ubuntu/+source/ghdl</a></div><div><br></div><div>So what's the correct (platform independent) interface to create an account in?</div><div>------------</div><div><br></div><div>> That for sure depends a bit on the point of view. :-)</div><div>I don't want to argue about the Filesystem Hierarchy Standard (FHS). There are most likely mistakes</div><div>inside of GHDL's build and installation flow. But that's exactly what I request as a feedback to GHDL,</div><div>so we can improve the build and installation already in GHDL. Please help us to improve it so Debian</div><div>(and Ubuntu, Mint, ..) need fewer patches.</div><div><br></div><div>What I can clearly say is: After restructuring GHDL into multiple deb packages and by modifying paths,</div><div>some parts of GHDL can't find all resources and it doesn't work. So that part is very clear. This is mainly</div><div>libghdl..., because it was moved into a x86_64 specific directory without adjusting its search paths for</div><div>the STD and IEEE libraries, src directory, etc.</div><div><br></div><div>> The packaging of GHDL has some testing.</div><div>For testing, the GitHub pipeline of GHDL does such testing and I can help to select appropriate parts</div><div>and scripts from the testsuite so Debian can run tests after packaging. There is a test for GHDL itself</div><div>and one for libghdl <a class="gmail_plusreply" id="plusReplyChip-0">+</a> pyGHDL.</div><div><br>For the other patches. Yes I see Debian specific patches like compile flags, but there are patches e.g. for</div><div>other platforms. I think this should be pushed upstream to reduce patches at Debian and enable more</div><div>users who compile from sources.</div><div><br></div><div> > Mostly it's personal resources and lack of time. :-)</div><div>Maybe my question was a bit unclear... If I understood the history of changes correctly, there have been</div><div>many adoptions of GHDL's packaging for various GHDL versions. But, as far as I remember and as far</div><div>as I can see in aptitude, there is no GHDL offered by Debian. So it looks/feels like GHDL is stuck in sid.</div><div>It gets updated in sid, but it's not in bullseye, bookworm, ... right?</div><div>So my question was more technical, what's missing so it gets moved further than sid?<br><br>From history:<br>* added to testing<br>* removed from testing<br>* ...</div><div><br></div><div>> I'm mosty biased about upstream are providing such packages</div><div>Compared to MSYS2, the packaging for Debian is quite complicated, so I would like to avoid it. At least</div><div>defining a new packaging recipe. I could imagine pulling the packaging code from Debian and providing</div><div>same quality *.deb files, but with a shorter turnaround.</div><div><br></div><div>Kind regards</div><div>    Patrick Lehmann</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Am So., 9. März 2025 um 08:07 Uhr schrieb Carsten Schoenert <<a href="mailto:c.schoenert@t-online.de">c.schoenert@t-online.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Patrick,<br>
<br>
I'm not the primary maintainer of GHDL, that's Andreas Bombe (added to <br>
the recipients). But I'll try to give some feedback in general to your <br>
email.<br>
<br>
Thanks for reaching out to the Debian Electronics Team to talk about the <br>
packaging of GHDL! Debian in general has always an interest to have a <br>
good relationship to the upstream projects and maintainers.<br>
<br>
Am 08.03.25 um 16:28 schrieb Paebbels:<br>
> Hi,<br>
> <br>
> I would like to get in contact with the person(s) responsible for packaging<br>
> GHDL, so it can be updated and fixed for a v5.0.1 release. Currently the<br>
> packaging instructions produce broken installations on Ubuntu, Debian, ...<br>
> I assume any OS that uses apt has broken GHDL installations.<br>
<br>
That for sure depends a bit on the point of view. :-)<br>
Andreas is a long time Debian Developer and he has of course reasons why <br>
he is doing the packaging in Debian in the way it is.<br>
If I'm looking at your pointed issue on GH I can image for some of the <br>
points why you think what Debian/Ubuntu is doing is wrong Andreas has a <br>
different POV. I will not go into details here, that is best handled in <br>
my eyes by creating various issues in the Debian BTS, but based on my <br>
experiences where I had similar situations in and with other upstream <br>
projects it was often the case that upstream did not fully understand <br>
the FHS hierarchy and did only partially respecting the differences <br>
between the target platforms.<br>
<br>
Autotools and also CMake can be tricky I don't think I know every part <br>
and intention of these build toolchains ;-), in summary I strongly <br>
believe we have in Debian well experienced people who are also willing <br>
help to solve issues in regard of different target platforms and also in <br>
supporting multi architecture installations.<br>
<br>
> I suspect that installations are not tested, otherwise a test should have<br>
> discovered that problem.<br>
<br>
That again depends on what you/upstream think is a problem. The <br>
packaging of GHDL has some testing. For sure this can get improved, as <br>
mostly always it can. But writing tests has limitations (for me), I'm <br>
and also Andreas is doing the packaging in our free time.<br>
<br>
Debian has build up a CI infrastructure that is triggered always once a <br>
new version is uploaded to the archive, or some other package, like a <br>
build dependency, is going to change within the Debian archive. An <br>
failing test run in GHDL is then preventing the migration of the other <br>
package(s) that did trigger the test.<br>
<br>
We have within the debian/ folder the subfolder debian/tests/ which is <br>
holding all the data for these tests. GHDL has a rather small script <br>
right now.<br>
<br>
> <a href="https://salsa.debian.org/electronics-team/ghdl/ghdl/-/blob/master/debian/tests/ghdl-tests?ref_type=heads" rel="noreferrer" target="_blank">https://salsa.debian.org/electronics-team/ghdl/ghdl/-/blob/master/debian/tests/ghdl-tests?ref_type=heads</a><br>
<br>
I believe Andreas is happy to get some help or suggestion what to add or <br>
how to improve the tests here.<br>
<br>
> I'm here to help the package maintainers understand how GHDL gets<br>
> configured, compiled, and tested so he/here/them can create a correct<br>
> package description. I can also explain GHDL's backend variants mcode,<br>
> llvm, llvm-jit and gcc.<br>
> <br>
> I would also like to understand how a new version can be triggered, so GHDL<br>
> could potentially release 4 times a year.<br>
<br>
We have a service in Debian named 'uscan' which will run I think once a <br>
day to check for new upstream versions. This service has already <br>
detected there is a new version of GHDL available. It's integrated into <br>
the package tracker website about GHDL. Have look at the main window in <br>
the middle, it's the first line there.<br>
<br>
> <a href="https://tracker.debian.org/pkg/ghdl" rel="noreferrer" target="_blank">https://tracker.debian.org/pkg/ghdl</a><br>
<br>
I've upstreams who contact me privately to inform me about new versions <br>
of there project, which is nice. And often I get some extra news too by <br>
such emails.<br>
<br>
Another way you can walk is to open a bug issue with severity wishlist <br>
and the hint that a new version is available to get packaged. The <br>
package maintain will get then an email about a new bug report was raised.<br>
I think the most comfortable way is to use the tool 'reportbug' to do <br>
this, but this requires a running Debian system as the tool is specific <br>
to Debian. But you can also use a classical email to open a bug report.<br>
<br>
This is in principle writing an email to <a href="mailto:bugs@debian.org" target="_blank">bugs@debian.org</a> with some <br>
needed entries. You would need at least these entries in the body so the <br>
report gets connected to the src:ghdl package.<br>
<br>
> Source: ghdl<br>
> Version: 4.1.0+dfsg-4<br>
> Severity: wishlist<br>
> <br>
> Dear Maintainer,<br>
> your writing goes here...<br>
<br>
....<br>
> I noticed many patches to GHDL. I would like to understand if GHDL<br>
> should integrate these changes e.g. into ./configure or ./Makefile.in.<br>
> Therefore<br>
> GHDL needs feedback from package maintainers, who report bugs and<br>
> suggestions.<br>
<br>
In general often some patches are specific to Debian, some other patches <br>
are something that should go to upstream. Most of the maintainers do <br>
write some explanation why the patch is needed and if the patch is from <br>
upstream or is only needed within Debian.<br>
<br>
Andreas has written so far I can see always some lines of explanation <br>
what the patch is about, what patches are good for upstream I can not <br>
judge. That's something Andreas would need to speak up. You can see all <br>
patches atm here.<br>
<br>
> <a href="https://salsa.debian.org/electronics-team/ghdl/ghdl/-/tree/master/debian/patches?ref_type=heads" rel="noreferrer" target="_blank">https://salsa.debian.org/electronics-team/ghdl/ghdl/-/tree/master/debian/patches?ref_type=heads</a><br>
<br>
...<br>
> The problems are summarized here:<br>
> <a href="https://github.com/ghdl/ghdl/issues/2710#issuecomment-2267471733" rel="noreferrer" target="_blank">https://github.com/ghdl/ghdl/issues/2710#issuecomment-2267471733</a><br>
<br>
These details are probably interesting for Andreas. As Matthias from <br>
Ubuntu also mentioned the interessting ones from your POV should get an <br>
bug report in the Debian BTS. So we can keep track of the issues in <br>
detail and an solved issue also would get documented if referenced in <br>
the Debian changelog.<br>
<br>
> I also noticed GHDL was packaged multiple times also for previous GHDL<br>
> releases, but none made it into official release repositories. What's<br>
> missing or failing to make GHDL available?<br>
<br>
Mostly it's personal resources and lack of time. :-)<br>
As Debian is a project based on volunteers it's always the question if <br>
we have enough volunteers with enough time.<br>
And GHDL is definitely some very specific software that requires good <br>
knowledge. This makes it even more difficult to find co-maintainers.<br>
<br>
> Should GHDL's pipeline provide *.deb files via nightly builds?<br>
> Currently, all apt based OS get a GHDL update once a year, if even.<br>
<br>
I'm mosty biased about upstream are providing such packages. For to <br>
often I'v seen a to poor quality of such *.deb packages and people do <br>
then complain within Debian that they have problems wich such packages <br>
as the think they are provided by Debian.<br>
<br>
But you are free to provide such packages! I think ideally Debian/Ubuntu <br>
can create something with you together so you as upstream and <br>
Debian/Ubuntu too have a winning situation!<br>
<br>
-- <br>
Regards<br>
Carsten<br>
<br>
</blockquote></div></div>