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

[Paebbels]

Hi,

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 /usr/lib/x86_64-linux-gnu is not
correct.

I also checked the contents of ghdl-common: 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?

One remark for Debian BTS:
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 *reporting *bugs.
Sorry, that doesn't help me. I need a place where to report my findings.

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.

For my side:
* The findings has been reported to Ubuntu (Launchpad) and to Debian
(mailing list)
* The link to finding summary is this
https://github.com/ghdl/ghdl/issues/2710#issuecomment-2267665515
* You can contact me or Tristan via GHDL's issues or by my private email
address.
* 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.

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.

Kind regards
    Patrick


Am Mo., 10. März 2025 um 16:59 Uhr schrieb Carsten Schoenert <
c.schoenert at t-online.de>:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20250315/346ab971/attachment-0001.htm>