#887649 cdebconf-gtk-terminal: Please don't depend on unmaintained vte

Package:
cdebconf-gtk-terminal
Source:
cdebconf-gtk-terminal
Submitter:
Jeremy Bicha
Date:
2026-01-27 18:45:03 UTC
Severity:
serious
Tags:
#887649#5
Date:
2018-01-18 17:11:23 UTC
From:
To:
cdebconf-gtk-terminal Depends and Build-Depends on vte. In fact, it's
now the only package keeping vte in Debian Testing. The Debian GNOME
team does not intend to release Debian 10 "Buster" with vte since the
old 0.28 series has not had a release since GNOME3's release in 2011.

Please port to the vte2.91 source. That also means porting to gtk3.
gtk3 was declared stable over a year ago with the 3.22 series. (There
also have not been any gtk2 maintenance releases
since that time, although I guess someone will do a gtk2 maintenance
release eventually this year.)

On behalf of the Debian GNOME team,
Jeremy Bicha
#887649#10
Date:
2018-01-18 23:51:00 UTC
From:
To:
Hi,

Jeremy Bicha <jbicha@debian.org> (2018-01-18):

OK. I've considered switching a couple of times since 2012, but I've
been hitting various issues. But now that we have (almost, see below)
all components in place for gtk3 (including at-spi* and friends), and
now that old libraries are to be gotten rid of, I guess it's reasonable
for us to finally bite the bullet.

A few things need to happen, besides porting cdebconf to gtk3 (there
have been preliminary patches for many years already):
 - vte2.91 needs to build an installable udeb; I think I've reported a
   few issues already, but I don't tend to do so in a timely fashion
   since it's not used yet. Right now, libpcre2-8-0 is the issue.
 - theme support needs to be ported to gtk3.


Cheers,
#887649#15
Date:
2018-01-19 00:11:36 UTC
From:
To:
Control: block -1 by 887674

Ok, I filed a bug asking for a pcre2 udeb.

Thanks,
Jeremy Bicha
#887649#22
Date:
2018-01-19 01:24:35 UTC
From:
To:
Hi,

Jeremy Bicha <jbicha@debian.org> (2018-01-18):

No need to have a serious bug there, adjusting severity; the attached
patch seems to do the job for src:pcre2. An extra one makes it build
way faster (tested on 8 cores without stumbling upon any issues).

Getting back to src:vte2.91 though, that's not sufficient, as the
resulting udeb depends (right now or after a rebuild against a patched
pcre2) on libstdc++6. We don't do c++ in d-i.


Cheers,
#887649#29
Date:
2018-01-19 01:38:58 UTC
From:
To:
Cyril Brulebois <kibi@debian.org> (2018-01-19):

Wow, that was incredibly stupid, sorry. (Blaming this on headache.)

I meant to add this: for some reason dose-debcheck doesn't detect this
issue, I only happened to stumble upon it when checking the updated
Depends line. :(


Cheers,
#887649#36
Date:
2018-01-19 02:02:28 UTC
From:
To:
What about gnutls28?
objdump -x /usr/lib/x86_64-linux-gnu/libvte-2.91.so.0.5000.2 | grep NEEDED
lists

  NEEDED               libgnutls.so.30
#887649#41
Date:
2018-01-19 02:04:01 UTC
From:
To:
Am 19.01.2018 um 03:02 schrieb Michael Biebl:

nvm...

CONFFLAGS_udeb = \
       --disable-gtk-doc \
       --without-gnutls
#887649#51
Date:
2018-01-21 20:27:47 UTC
From:
To:
Hi guys,

Unfortunately this sounds really problematic. As of version 0.42 vte
has been using (more and more) C++. This is not like Ubuntu's PCRE2
hack which is a matter of a few hours of work reverting and merging a
few commits. It's reasonably impossible to revert to plain C and
maintain that as a fork, and upstream has no intention to revert to C
either.

You might want to have a special libvte2.91 0.40 package, or revive
libvte2.90 0.36 for the installer. These are also abandoned by
upstream, but already significantly less buggier than 0.28, probably
good enough for the installer (after all, 0.28 was good enough until
now), and allow you to drop the gtk2 dependencies, potentially buying
you many more years (perhaps you'll be good until you decide to
replace gtk3 by gtk4 in the installer).

I understand it's far from ideal. Other possibilities include ditching
the "no c++" policy (pulling in a 1.5M lib for the sake of a 400k one,
sigh), maybe seeing if there's a good enough "minimal" replacement for
libstdc++ providing just the basics that are sufficient for VTE; or
finding a different terminal emulator solution.

cheers,
egmont
#887649#62
Date:
2020-09-03 09:44:06 UTC
From:
To:
One way to resolve this might be to build the vte2.91 udeb with
-static-libstdc++, which makes it about 200K larger than it would
otherwise have been, but avoids needing a 1.5M shared libstdc++. vte
exports a C ABI, and only uses C++ internally.

We need to upload a new vte2.91 to experimental anyway, so I'm going
to try this - d-i doesn't currently use that udeb anyway, so there's
nothing to lose by trying it.

    smcv
#887649#67
Date:
2020-09-03 09:46:56 UTC
From:
To:
Hi Simon,

Simon McVittie <smcv@debian.org> (2020-09-03):

This looks like a nice plan, thanks for the heads-up!


Cheers,
#887649#74
Date:
2021-02-26 16:12:01 UTC
From:
To:
However, since we're already in soft freeze, a GTK 3 port of the graphical
installer interface is clearly not something to start on right now -
so I think this has to slip to Debian 12.

Release team: I think #887649 is going to need to be bullseye-ignore.

    smcv
#887649#83
Date:
2022-10-16 10:02:37 UTC
From:
To:
Unfortunately it doesn't look like there was progress on #887649 this
cycle either. So I fear that we'll end up needing to tag both #887649
and #885563 bookworm-ignore. :(

Kind regards
Philipp Kern
#887649#88
Date:
2022-10-16 14:29:09 UTC
From:
To:
Philipp Kern <pkern@debian.org> (2022-10-16):

I'm keeping an open mind but given the remaining time, and the otherwise
important workload on firmware and other things, it looks to me working
on this is likely to trigger more immediate questions/problems than
we'll have time to figure out before it's time to release.


Cheers,
#887649#113
Date:
2026-01-27 18:08:01 UTC
From:
To:
Do I see it correctly that gtk3 support was already implemented for this
project in 2016 and just needs to be activated in d/control and d/rules?
Because when I do, the package compiles fine.

Additionally to #1061121, what needs to be done to get installer support
for gtk3 implemented?
#887649#118
Date:
2026-01-27 18:43:09 UTC
From:
To:
Bastian Germann, le mar. 27 janv. 2026 19:08:01 +0100, a ecrit:

Most probably, actually testing it and see the bugs that we get :)

Samuel