This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
binary packages with a Depends on GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
<https://bugs.debian.org/947713>). It no longer receives any significant
upstream maintenance, and in particular does not get feature development
for new features like UI scaling on high-pixel-density displays (HiDPI)
and native Wayland support. GTK 3 is in maintenance mode and GTK 4 is
approaching release, so it seems like a good time to be thinking about
minimizing the amount of GTK 2 in the archive.

GTK 2 is used by some important productivity applications like GIMP, and
has also historically been a popular UI toolkit for proprietary software
that we can't change, so perhaps removing GTK 2 from Debian will never be
feasible. However, it has reached the point where a dependency on it is
a bug - not a release-critical bug, and not a bug that can necessarily
be fixed quickly, but a piece of technical debt that maintainers should
be aware of.

A porting guide is provided in the GTK 3 documentation:
https://developer.gnome.org/gtk3/stable/migrating.html

Some libraries (for example libgtkspell0) expose GTK as part of their
API/ABI, in which case removing the deprecated dependency requires
breaking API/ABI. For these libraries, in many cases there will already
be a corresponding GTK 3 version (for example libgtkspell3-3-0), in which
case the GTK 2-based library should probably be deprecated or removed
itself. If there is no GTK 3 equivalent, of a GTK 2-based library,
maintainers should talk to the dependent library's upstream developers
about whether the dependent library should break API/ABI and switch
to GTK 3, or whether the dependent library should itself be deprecated
or removed.

A few packages extend GTK 2 by providing plugins (theme engines, input
methods, etc.) or themes, for example ibus and mate-themes. If these
packages deliberately support GTK 2 even though it is deprecated, and
they also support GTK 3, then it is appropriate to mark this mass-filed
bug as wontfix for now. I have tried to exclude these packages from
the mass-bug-filing, but I probably missed some of them.

Regards,
    smcv

The upstream maintainer is not going to work on hexchat anymore:
https://hexchat.github.io/news/2.16.2.html

As announced [1], we are trying to remove gtk2 from forky. Therefore,
I am raising the severity of this issue. Since hexchat has been
unmaintained upstream for 2 years, we will likely need to remove
hexchat from Debian.

I listed some alternative apps in https://bugs.debian.org/1120756

[1] https://lists.debian.org/debian-devel/2026/01/msg00090.html

On behalf of the Debian GNOME team,
Jeremy Bícha

Hi,

I have vibe-coded the gtk3 conversion (see forwarded URL). This also runs in Wayland.
If we decide to import a release of that project into Debian, I am going to maintain it in the long run.

I am not a power user of hexchat, so if you see some dialogs not looking as before, please open an issue and describe
how to get to the dialog. A screenshot is also helpful.

Thanks for your comments,
Bastian

Please see the 3.0.0-0.1 experimental upload if you want to test the
GTK3 version.

There is an active fork now (zoitechat) that has been already ported to
GTK3, so I would remove hexchat in favour of that. It's been packaged by
sney and is currently awaiting review in NEW.

best,

werdahias

Okay, let's promote zoitechat. Should we remove hexchat or make each of
the binary pkgs a transitional package to the zoitechat one?

Is zoitechat able to deal with an existing hexchat configuration? If so,
are manual steps required for an import?

On Fri, 24 Apr 2026 11:54:19 +0200 Bastian Germann <bage@debian.org> wrote:
 > Is zoitechat able to deal with an existing hexchat configuration?

Somewhat. As far as upstream and I can tell, a hexchat config from
2.16.x should be mostly compatible as long as you rename hexchat.conf to
zoitechat.conf but we've advised against doing it blindly in the manual
[1]. Migrating from 2.14.x or older has not been tested and theming is
completely different now too [2].

So I am not sure a transitional package would be appropriate. But I will
(in line with upstream and some other distro packages) make the
description a little more explicit about being a gtk3 hexchat fork.

And once upon a time hexchat was included in some desktop metapackages
with a default configuration in line with debian.org/support, maybe
doing that for zoitechat would be enough of a hint for people to switch?

sney

[1]
https://docs.zoitechat.org/en/latest/faq.html#how-do-i-migrate-my-settings-from-hexchat
[2] https://docs.zoitechat.org/en/latest/appearance.html

ICYMI, zoitechat 2.18.1 is now in sid, forky, and trixie-backports.

Some small bugs remain, but it's mostly as functional as hexchat was,
and upstream development continues.

The updated description reads:

Description: GTK+ IRC Client
  ZoiteChat is a GTK3 IRC client based on HexChat. Features include
  HexChat-compatible Python, Perl and Lua scripting support, a plugin API,
  multiple server/channel windows, spell checking, multiple authentication
  methods including SASL, and customizable notifications. For more
information
  on IRC, see http://irchelp.org/.

sney