If you plough through the first pages so far as I can tell it seems like actually it won't be removed.
Certainly not FPC, because the hard dependency on GTK2 was a misunderstanding.
For Lazarus it seems like dependency on GTK2 is considered a bug and not a fundamental incompatibility, because there are too many GTK2 applications to completely remove it from Debian.
That's the curse on the Unix world. At least FreeBSD, NetBSD (OpenBSD not by design, but that's understandable because of security) have their compat libraries on plus some of them (even GTK1) in their ports. On 9front, I just adapted Russ Cox' Xword (some crossword player for XWord files, it has a converter from Across Lite Puz files to Xword) for modern times, barely a few lines changes in some drawing function for software made for Plan9 4ed or close.
PD: Guix can do the same as fbsd and nbsd because, well, setting up an isolated environment with time-bound tools it's basically what Guix was born for, reproducibility. Scientific repo for a paper must be run point to point as we had a Slackware setup with Slackbuilds in 2007? That's the point of Guix. You would say... docker. But docker it's overkill.
Didn't FreeBSD recently dropped their 32 bits x86 version ? At some point every open source OS will remove the parts for which no one is willing to put the work on maintaining it.
maybe the best and simplest solution would be to not remove gtk2 from debian. the last release is stable and there's no technical reason to remove it (as it still works and compiles just fine), only political ones.
I don't like how political debian has been becoming in a number of facets, I've moved all of my machines over to Ubuntu and Arch and am happier because of it
You don't like decisions being based on political factors (rather than technical merit I assume, but feel free to correct me) yet you moved to Ubuntu?
I don't like it either, but that's not the direction I would go. I haven't looked into Arch yet in enough detail to have an informed opinion, but maybe I should.
Well that's a bummer. There's a whole generation of barely-if-at-all-maintained but still perfectly working utils that will probably be forever lost to obscurity with that.
Does gtk2 still have Debian maintainers? Whatever is in Debian's official repository is effectively endorsed by Debian. If they don't have enough capacity it's wiser to drop support than to sign off on something of unknown quality.
I hate losing access to software just because it is "unmaintained".
If module is "endorsed" now, since it is included in current version, and there is no maintenance, so no changes made to it, why is it suddenly not good enough to "endorse" in the future?
No, security issues do not count as they don't magically appear, either they are in there now and debian is fine with distributing "insecure" code or they don't matter.
Debian is fine with shipping broken version of software for years as long as they consider it "stable" so why drop working "stable" software just because no one is making changes to it?
The maintainer driving this in Debian explicitly said:
> That being said I would not object if someone wants to take over the maintenance of GTK2, though I believe keeping it for beyond duke is beating a dead horse.
You can step up and be the maintainer of GTK2 (or anything else that would keep the 'deletionists' at bay) any time you want. Go on...I'm sure you have unlimited time and resources like all the other Debian maintainers.
Flatpak is basically running an isolated separate distro. A software inside a Flatpak has to communicate with the outside world to do anything useful which is yet another API surface that needs to be maintained and it will be dropped just like gtk2 when people just don't want to maintain it.
I think the way the Linux ecosystem works is fundamentally against maintaining old binaries unless they are a text-only program.
I covered this on the Reg:
https://www.theregister.com/2026/02/26/debian_14_will_drop_g...
There's an active fork of Gtk2 used in Ardour.
There's also an active fork of Gtk1 used in CinePaint:
https://gitlab.com/robinrowe/gtk1
He's been maintaining this for a long time, too:
https://gtk1-win.sourceforge.net/
The developer appeared on El Reg recently:
https://www.theregister.com/2026/01/26/trapc_claude_c_memory...
If you plough through the first pages so far as I can tell it seems like actually it won't be removed.
Certainly not FPC, because the hard dependency on GTK2 was a misunderstanding.
For Lazarus it seems like dependency on GTK2 is considered a bug and not a fundamental incompatibility, because there are too many GTK2 applications to completely remove it from Debian.
That's the curse on the Unix world. At least FreeBSD, NetBSD (OpenBSD not by design, but that's understandable because of security) have their compat libraries on plus some of them (even GTK1) in their ports. On 9front, I just adapted Russ Cox' Xword (some crossword player for XWord files, it has a converter from Across Lite Puz files to Xword) for modern times, barely a few lines changes in some drawing function for software made for Plan9 4ed or close.
PD: Guix can do the same as fbsd and nbsd because, well, setting up an isolated environment with time-bound tools it's basically what Guix was born for, reproducibility. Scientific repo for a paper must be run point to point as we had a Slackware setup with Slackbuilds in 2007? That's the point of Guix. You would say... docker. But docker it's overkill.
Didn't FreeBSD recently dropped their 32 bits x86 version ? At some point every open source OS will remove the parts for which no one is willing to put the work on maintaining it.
NetBSD still supports 32 bit, and VAX 780 from 1979. Best OS ever, highest quality and probability.
2 replies →
maybe the best and simplest solution would be to not remove gtk2 from debian. the last release is stable and there's no technical reason to remove it (as it still works and compiles just fine), only political ones.
I don't like how political debian has been becoming in a number of facets, I've moved all of my machines over to Ubuntu and Arch and am happier because of it
Ubuntu is Debian with an additional layer of awkward decision making.
2 replies →
Debian has always been political, since its inception.
You don't like decisions being based on political factors (rather than technical merit I assume, but feel free to correct me) yet you moved to Ubuntu?
I don't like it either, but that's not the direction I would go. I haven't looked into Arch yet in enough detail to have an informed opinion, but maybe I should.
But! But! Unmaintained >:(!!1!!11!!!1
Bigger issue here is they're removing everything that depends on gtk2.
This has been reported here but got not enough attention:
"Debian GNOME team announces intent to remove GTK 2 in Debian 14" (08.01.2026)
https://news.ycombinator.com/item?id=46548257
P.S. Still hope GNOME maintainers let other volunteers maintain GTK 2.
> P.S. Still hope GNOME maintainers let other volunteers maintain GTK 2.
They already said this is fine: https://lists.debian.org/debian-devel/2026/01/msg00146.html
Well that's a bummer. There's a whole generation of barely-if-at-all-maintained but still perfectly working utils that will probably be forever lost to obscurity with that.
Recently I wish Debian was more Debian.
With the possible exception of Hexchat, I'd wager any such tools were already lost to obscurity.
Does gtk2 still have Debian maintainers? Whatever is in Debian's official repository is effectively endorsed by Debian. If they don't have enough capacity it's wiser to drop support than to sign off on something of unknown quality.
I hate losing access to software just because it is "unmaintained". If module is "endorsed" now, since it is included in current version, and there is no maintenance, so no changes made to it, why is it suddenly not good enough to "endorse" in the future? No, security issues do not count as they don't magically appear, either they are in there now and debian is fine with distributing "insecure" code or they don't matter. Debian is fine with shipping broken version of software for years as long as they consider it "stable" so why drop working "stable" software just because no one is making changes to it?
3 replies →
- GTK2 is only one of the supported widget sets for Lazarus. It supports Qt5 & 6 too. I feel Lazarus should switch to Qt5 or 6 until GTK3 is mature.
- Hexchat IRC client is another popular application that is still stuck with GTK2.
Considering we're on GTK 4, I think GTK 3 is as mature as it's gonna get.
1 reply →
It seems no distro is safe from deletionists.
The maintainer driving this in Debian explicitly said:
> That being said I would not object if someone wants to take over the maintenance of GTK2, though I believe keeping it for beyond duke is beating a dead horse.
Source: https://lists.debian.org/debian-devel/2026/01/msg00146.html
If you really need things others are no longer willing to maintain, then it’s time to learn how to help yourself.
The Nix or Guix package managers are likely your easiest bet. See
https://nixos.wiki/wiki/Lazarus
https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
You can step up and be the maintainer of GTK2 (or anything else that would keep the 'deletionists' at bay) any time you want. Go on...I'm sure you have unlimited time and resources like all the other Debian maintainers.
3 replies →
I'm sure they can be easily ported to GTK3, GTK4 and then GTK5 /s
Meanwhile, slackware-current has the good old gtk1 and I believe it's only for xmms.
How is the experience of running Slackware these days? With stable releases too far apart, is everyone running current as a rolling release distro?
Is this the sort of thing that Flatpak would be useful for? Or are there sandbox-related complications when using it to package a compiler?
Flatpak is basically running an isolated separate distro. A software inside a Flatpak has to communicate with the outside world to do anything useful which is yet another API surface that needs to be maintained and it will be dropped just like gtk2 when people just don't want to maintain it.
I think the way the Linux ecosystem works is fundamentally against maintaining old binaries unless they are a text-only program.
Not an expert but i don't see a problem. I use Snap-packaged compilers on Ubuntu all day, and have used Flatpak'd IDEs
The site seem slashdotted by us.
https://web.archive.org/web/20260227192142/https://forum.laz...
looks like slashdot effect is ongoing for the site.