<div dir="ltr">Hi,<div><br></div><div>I discussed today with Tristan what's inside of libghdl. There is no code generation and simulation in that shared object. Thus the classification as x86_64 code generator and moving it to <span style="background-color:rgba(129,139,152,0.12);color:rgb(31,35,40);font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:11.9px">/usr/lib/x86_64-linux-gnu </span>is not correct.</div><div><br></div><div>I also checked the contents of <span style="background-color:rgba(129,139,152,0.12);color:rgb(31,35,40);font-family:ui-monospace,SFMono-Regular,"SF Mono",Menlo,Consolas,"Liberation Mono",monospace;font-size:11.9px">ghdl-common</span>: it contains Synopsys code. As far as I know, this is why GHDL was considered non-free - as in Debian terms - some years ago. Has this judgement changed?</div><div><br></div><div>One remark for Debian BTS:<br>All sources somehow redirect to the BTS. This BTS isn't really a bug tracking system. It's a searchable database displaying what bugs have been reported and what state they are in. It doesn't allow <b>reporting </b>bugs. Sorry, that doesn't help me. I need a place where to report my findings.</div><div><br></div><div>I don't see me installing a full blown Debian incl. GUI and adding special tools for reporting a bug. That's asking for too much in 202x. I don't want to become a regular bug reporter at Debian, I'm a once in 5 years reporter.<br><br></div><div>For my side:</div><div>* The findings has been reported to Ubuntu (Launchpad) and to Debian (mailing list)</div><div>* The link to finding summary is this <a href="https://github.com/ghdl/ghdl/issues/2710#issuecomment-2267665515">https://github.com/ghdl/ghdl/issues/2710#issuecomment-2267665515</a></div><div>* You can contact me or Tristan via GHDL's issues or by my private email address.</div><div>* If someone picks this up and works on it, they can reach out to me and I'll be happy to set up a Zoom meeting explaining the finding. We can also discuss possible solutions.</div><div><br></div><div>I still would like to see ghdl be regularly updated. When the packages get fixed, I'll advocate at GHDL for quarterly releases for all platforms instead of once a year updates.</div><div><br></div><div>Kind regards</div><div>    Patrick</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Am Mo., 10. März 2025 um 16:59 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>
Am 09.03.25 um 20:03 schrieb Paebbels:<br>
> Hello Carsten,<br>
> <br>
> Thanks for your quick and detailed response.<br>
> I'm actually a bit lost as to what the official bug tracking system <br>
> (BTS) of Debian is.<br>
<br>
yeah, understandable. Debian is quite conservative about such things. We <br>
don't use Discord or similar, we mostly also don't use the Issue tracker <br>
functionality of our GitLab based instance called Salsa<br>
<br>
<a href="https://salsa.debian.org" rel="noreferrer" target="_blank">https://salsa.debian.org</a><br>
<br>
The system we use in Debian is named BTS (as short for Bug Tracking <br>
System) and an entry to this can be found under <a href="https://www.debian.org/Bugs/" rel="noreferrer" target="_blank">https://www.debian.org/Bugs/</a><br>
<br>
There isn't a classical dashboard as a entry available, but if you know <br>
the (source) package name then you can easily get an overview of all bug <br>
reports for this package, for ghdl this is then<br>
<br>
<a href="https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=ghdl" rel="noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=ghdl</a><br>
<br>
This is linked from the tracker page for each package.<br>
<br>
> There are:<br>
> * email lists to discuss packaging problems (this email list - seems to <br>
> be the wrong place for a real bug and its tracking)<br>
<br>
Yes, basically. The lists are for discussing mostly, but if someone <br>
creates a new bug report for a package the email about will get also <br>
forwarded to the mailing list, so also here for packages which have the <br>
maintainer set to <a href="mailto:pkg-electronics-devel@alioth-lists.debian.net" target="_blank">pkg-electronics-devel@alioth-lists.debian.net</a><br>
<br>
The list archive can be viewed here<br>
<br>
<a href="https://lists.alioth.debian.org/pipermail/pkg-electronics-devel/" rel="noreferrer" target="_blank">https://lists.alioth.debian.org/pipermail/pkg-electronics-devel/</a><br>
<br>
> * there is a special <a href="mailto:bugs@debian.org" target="_blank">bugs@debian.org</a> <mailto:<a href="mailto:bugs@debian.org" target="_blank">bugs@debian.org</a>> email <br>
> address - but this is not a bug tracking system, or?<br>
<br>
Technically not, but to this address all new reports get send, the back <br>
end is reading some specific written lines (these "Control: $foo", <br>
"Version: $bla" ones e.g.) and writes the collected data into a database.<br>
<br>
So no matter if you use the reportbug tool or a hand crafted email, the <br>
data will end in the Debian BTS.<br>
<br>
> * there is a GUI tool (reportbug) that can only be used on Linux / <br>
> Debian - I have a Windows environment and<br>
>    use Debian an CI Server or in WSL, so no GUI to use that specific tool.<br>
<br>
reportbug can be used with a graphical frontend, but it will require a <br>
configured MTA on your system as it is generating a email, or you have <br>
configured it to spawn your MUA. If you are working on Windows you will <br>
need to use your preferred email client or run a Debian within a WSL <br>
setup maybe there you can work on a CLI.<br>
<br>
The typical Debian Developer isn't using a graphical tool here, we can <br>
do the same with CLI tools and mostly quicker than using the mouse to <br>
open a UI tool. And obviously we don't work on a Windows system.<br>
<br>
> * Salsa is a GitLab-CE with issues (<a href="https://salsa.debian.org/groups/" rel="noreferrer" target="_blank">https://salsa.debian.org/groups/</a> <br>
> electronics-team/ghdl/-/issues<br>
<br>
Yes, Salsa is our VCS which is mostly used to work collaborative on <br>
packaging, this includes the option to use the CI that is integrated to <br>
build packages automatically and also to run some QA checks with that.<br>
<br>
> * And in parallel there is launchpad.<br>
>    Here I reported it already some long time ago, but no bug <br>
> classification and reaction.<br>
> <a href="https://bugs.launchpad.net/ubuntu/+source/ghdl" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/ghdl</a> <https:// <br>
> <a href="http://bugs.launchpad.net/ubuntu/+source/ghdl" rel="noreferrer" target="_blank">bugs.launchpad.net/ubuntu/+source/ghdl</a>><br>
<br>
Launchpad is Ubuntu, we or I at least don't look that much into issues <br>
at Launchpad because there is a company above that and is using Debian <br>
packages and offers service around this. That's totally fine for me, but <br>
I've low interest to fix issues in Ubuntu. If the issues get fixed in <br>
Debian than two distros have a win on that.<br>
<br>
I guess Ubuntu has not that much interest in clearing the queue for GHDL <br>
because there are to less costumers who would be willing to pay for service.<br>
I have more problems with Launchpad, people have often some PPAs <br>
configured and this makes it hard to tackle down the real issues because <br>
the PPAs often don't fulfill the QA standards that Debian has.<br>
<br>
> So what's the correct (platform independent) interface to create an <br>
> account in?<br>
<br>
If you want to report issues for Debian, then you will need to use the <br>
Debian BTS, that's the official place to report issues. You can <br>
reference of course to other bug reports that do exist elsewhere, no <br>
need to write down everything again.<br>
<br>
<br>
>> That for sure depends a bit on the point of view. :-)<br>
> I don't want to argue about the Filesystem Hierarchy Standard<br>
> (FHS). There are most likely mistakes inside of GHDL's build and<br>
> installation flow. But that's exactly what I request as a feedback<br>
> to GHDL, so we can improve the build and installation already in<br>
> GHDL. Please help us to improve it so Debian (and Ubuntu, Mint, ..)<br>
> need fewer patches.<br>
<br>
Sure, but I can't help further here, I not even have used GHDL yet. From <br>
here Andreas would need to step in.<br>
<br>
> What I can clearly say is: After restructuring GHDL into multiple<br>
> deb packages and by modifying paths, some parts of GHDL can't find<br>
> all resources and it doesn't work. So that part is very clear. This<br>
> is mainly libghdl..., because it was moved into a x86_64 specific<br>
> directory without adjusting its search paths for the STD and IEEE<br>
> libraries, src directory, etc.<br>
As above, that's up to Andreas to say something to if he wants.<br>
<br>
>> The packaging of GHDL has some testing.<br>
> For testing, the GitHub pipeline of GHDL does such testing and I<br>
> can help to select appropriate parts and scripts from the testsuite<br>
> so Debian can run tests after packaging. There is a test for GHDL<br>
> itself and one for libghdl + pyGHDL.<br>
That would be the best if upstream and Debian can work together!<br>
<br>
> For the other patches. Yes I see Debian specific patches like<br>
> compile flags, but there are patches e.g. for other platforms. I<br>
> think this should be pushed upstream to reduce patches at Debian and<br>
> enable more users who compile from sources.<br>
Yes, absolutely. Feel free to pick up some of them, we wont complain if <br>
the count of patches is getting less. :-)<br>
But upstream has also mostly a better knowledge on some parts, so <br>
sometimes patches would need to get discussed to get them into the <br>
correct form upstream can accept them.<br>
<br>
>> Mostly it's personal resources and lack of time. :-)<br>
<br>
> Maybe my question was a bit unclear... If I understood the history<br>
> of changes correctly, there have been many adoptions of GHDL's<br>
> packaging for various GHDL versions. But, as far as I remember and<br>
> as far as I can see in aptitude, there is no GHDL offered by Debian.<br>
<br>
This is not true I think. It's split up into various packages for good <br>
reasons. The reasons in detail is something again that Andreas would <br>
need to explain.<br>
<br>
In Debian unstable/sid and testing we have these packages atm.<br>
<br>
> $ apt search ghdl<br>
> ghdl/testing 4.1.0+dfsg-4+b1 amd64<br>
>   VHDL compiler/simulator<br>
> <br>
> ghdl-common/testing 4.1.0+dfsg-4+b1 amd64<br>
>   VHDL compiler/simulator (common files)<br>
> <br>
> ghdl-gcc/testing 4.1.0+dfsg-4+b1 amd64<br>
>   VHDL compiler/simulator (GCC backend)<br>
> <br>
> ghdl-llvm/testing 4.1.0+dfsg-4+b1 amd64<br>
>   VHDL compiler/simulator (LLVM backend)<br>
> <br>
> ghdl-mcode/testing 4.1.0+dfsg-4+b1 amd64<br>
>   VHDL compiler/simulator (mcode backend)<br>
> <br>
> ghdl-tools/testing 4.1.0+dfsg-4+b1 amd64<br>
>   VHDL compiler/simulator (tools)<br>
> <br>
> libghdl-4-1-0/testing 4.1.0+dfsg-4+b1 amd64<br>
>   VHDL compiler/simulator (shared library)<br>
> <br>
> libghdl-dev/testing 4.1.0+dfsg-4+b1 amd64<br>
>   VHDL compiler/simulator (library development files)<br>
<br>
For sure at least a Wiki page that could get referred to could help user <br>
to explain the package names and relations of these. It's not that we do <br>
not want this, it's mostly that someones needs to do this!<br>
<br>
> So it looks/feels like GHDL is stuck in sid. It gets updated in sid,<br>
> but it's not in bullseye, bookworm, ... right? So my question was<br>
> more technical, what's missing so it gets moved further than sid?<br>
<br>
In general Debian is using and taking two years time to create a new <br>
release, the intention is that all software in a stable release is <br>
working smoothly together.<br>
This means also that we do not upgrade package versions once a new <br>
stable release is done. This is not always doable and we have exceptions <br>
for this rule. E.g. web browsers, some email clients, firmware packages <br>
and partially the kernel will get regular updated and new versions.<br>
<br>
What you probably want and expect is that GHDL will get updates to more <br>
recent versions for a Debian stable release. You are not alone, people <br>
want to use a newer Libreoffice or a newer printing tool for example to <br>
get their new printer also running with Debian stable.<br>
<br>
We have for this an area in the archive that is called backports, for <br>
bookworm, the current stable release, this is then bookworm-backport.<br>
<br>
What is need here is to find people who are willing to work on packages <br>
that can go into this part of the archive.<br>
As of now I've never seen that a user was requesting a version of GHDL <br>
prepared for backports. So Andreas has for sure refused to work on such <br>
packages, it can make  a lot of work to get them working. And we are <br>
back at the needed resources and willing contributors.<br>
<br>
>  From history:<br>
> * added to testing<br>
> * removed from testing<br>
> * ...<br>
<br>
This happens if the package has some release critical bugs that are not <br>
fixed in time. To not block the whole archive the release team has <br>
decided that such packages will get kicked out of testing after 6 weeks <br>
if the issues are not getting solved. It means only they are not <br>
available and installable from the testing part. The version in stable <br>
isn't affected by this.<br>
<br>
Again, this is a resource issue if the maintainer count is to low to get <br>
issues fixed in time.<br>
<br>
>> I'm mosty biased about upstream are providing such packages<br>
> Compared to MSYS2, the packaging for Debian is quite complicated, so<br>
> I would like to avoid it. At least defining a new packaging recipe.<br>
> I could imagine pulling the packaging code from Debian and providing <br>
> same quality *.deb files, but with a shorter turnaround.<br>
<br>
I've no idea if packaging for Windows is complicated, my experience is <br>
that on Windows companies trying to build one package that fits all. <br>
This has ups and down. I've see far poor packages on Windows, but <br>
Windows is also not using some techniques and standards that are very <br>
common in the Linux world (e.g. symbol versioning). So it's difficult to <br>
compare I think.<br>
<br>
I can image that you can basically pick up the Debian packaging for GHDL <br>
and build nightly packages by a pipeline on GitHub. Would be at least <br>
nice if this all here could and up in doing something like this.<br>
<br>
-- <br>
Regards<br>
Carsten<br>
<br>
</blockquote></div>