Bug#1039051: Bug#1125294: gforth: Should gforth be removed from unstable?
Control: tags -1 moreinfo
Thanks
Hi Anton,
thank you for your prompt response. This is very much appreciated and
I'm hereby use this as a good reason to tag the bug moreinfo to prevent
any removal action for the moment.
Am Mon, Jan 12, 2026 at 02:19:18PM +0100 schrieb Anton Ertl:
> > I suggest removing gforth from Debian for the following reasons:
> >
> > * It accumulated one RC-bug:
> > #1067376 gforth: FTBFS: make[1]: *** [Makefile:655: build-libcc-named] Error 1
> > * Another bug report claims
> > #935487 gforth: Packaged gforth version is very old.
> > which makes me wonder whether our package is helpful for gforth users
>
> Gforth as distributed with Debian 12 or earlier has the following uses
> for Gforth users:
>
> 1) If they just want to run or develop some Forth programs while using
> Gforth documentation from the web, or other Forth documentation.
>
> 2) If they want to build the bleeding edge Gforth from git (for
> bootstrapping; building from the tarball works without an installed
> gforth, and tarballs for snapshots are typically released every few
> weeks).
If you talk about Debian 12: The removal of packages is happening in
unstable and would not affect Debian 12. So users of Debian 12 can keep
on doing what they did before - bit we need to care for gforth migrating
to testing (for the next release Debian 14) and to make sure it will
remain there without RC bugs.
> As upstream I see a number of people who are using the Debian gforth
> package.
>
> If you want a more up-to-date release, you could use one of the recent
> snapshots (the most recent one is always at
> http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.tar.xz).
> The only reason why it has not been released as Gforth 1.0 yet is that
> the documentation is not yet completely up-to-date, but given that
> Debian distributes Gforth without documentation, this should not be a
> concern. There are a few changes made to functionality while updating
> the documentation, but they are only in parts that are still
> experimental and not widely used.
I've seen the comment+patch that was added to bug #1067376 about the
documentation. Its not fully clear to me why it was removed. I think
it is more sensible to discuss this in a separate bug report.
> OTOH, as someone who invests a lot of time in writing the
> documentation, I am of two minds about the benefits and drawbacks of
> the official Debian package, which comes without the documentation.
As someone who has checked the package today for the first time I can
only say that I consider the documentation valuable for our users and
it should be provided if possible.
> I have also invested a lot of time in the performance of Gforth, and
> Debian's default use of --no-dynamic disables much of that work; but
> that affects only people who use Gforth for programs that consume
> significant time.
Can you please be more verbose about thiis option? I have migrated
the packaging repository of gforth to salsa.debian.org and enabled
Salsa CI. Thus you can see a build log there[1].
I do not see any sign of "Debian's default use of --no-dynamic".
What exactly do you mean?
> > In case the package should be kept in unstable, please evaluate the
> > RC-bug listed above.
> > * If the bug no longer applies, please close it. If it is closed, check
> > whether the fixed version is correct and adjust if necessary.
>
> Bernd Paysan (also upstream) wrote an answer to this bug report, where
> he indicates that the development version contains a solution to this
> bug, so one fix may be to switch to a recent snapshot.
Im perfectly fine in using some snapshot if you as upstream consider
this in the interest of your users.
> > * Is the bug really release-critical? If not, please downgrade.
>
> People can do and do a lot of stuff in Gforth without using libcc, so
> I would not classify it as release-critical.
>From a Debian point of view release-critical means: The package builds
from source. This is currently not the case - even not with Bernd's
patch I applied[2]. (Bernd, thanks a lot for the patch anyway.)
> But I do not know what
> criteria Debian uses for this classification.
As I said this is perfectly easy: The source package fails to build and
since we only release the package is neither part of the last release
(Debian 13) nor is the package in current testing.
> Bottom line:
>
> Gforth users on Debian can build Gforth from the tarball or use one of
> the .deb packages that Bernd Paysan builds (see https://gforth.org/).
I guess many users are happy about this service. We should decide
whether we should rather build the official Debian package by using the
source package which is used to build these *.debs. Unfortunately I
only found binary packages but no source.
> The benefits are:
>
> 1) You get documentation.
> 2) You get the new features (albeit some are experimental).
> 3) You get the full speed of Gforth.
I'm fine to bring those advantages also to the Debian package and I
offer to work together with you on this goal. The original Debian
Maintainer requested adoption anyway so you are free to maintain the
package inside Debian. If you create a login on Alioth I'd happily
give you permissions on the repository there.
> If Gforth is removed from Debian, users will be forced to take this
> path.
>
> If Gforth on Debian continues as before, and users do not need the
> advantages outlined above, they can use the Debian gforth package.
As I tried to explain: Only users of old-stable (Debian 12) or Debian
unstable can easily use the packages and we should fix this somehow.
> If Debian switches to a recent snapshot, you get advantage 2), and,
> depending on how you do it, maybe also 3) and 1) (but probably not 1,
> because the lack of documentation is intentional on the part of
> Debian).
I would love to enable *you* to do it. As I said, the former Debian
maintainer stepped back, I personally will not take over the maintenance
since I have way to much on my desk. But I'd happily enable you shaping
the official package in a manner you consider optimal for a typical
user. We have the principle of sponsoring in Debian. So if you
maintain the package in Salsa and ping me about uploading I will verify
the packaging, check whether Salsa CI is passing and can sponsor
(=upload) the package for you as an official package.
If you consider this a good idea I would be really happy. If you
think users might be served better with your snapshots and prefer if
someone else might spent some time into the official Debian package
we can see whether someone might step up.
Kind regards
Andreas.
[1] https://salsa.debian.org/debian/gforth/-/jobs/8878227
[2] https://salsa.debian.org/debian/gforth/-/commit/f5a52fdfaca64ac1cb7ca5293dfde95b0684fc44
--
https://fam-tille.de
Reply to: