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

[Simon McVittie]

On Thu, 03 Sep 2020 at 11:46:56 +0200, Cyril Brulebois wrote:
> Simon McVittie  (2020-09-03):
> > One way to resolve [needing a libstdc++ udeb]
> > 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.
> 
> This looks like a nice plan, thanks for the heads-up!

This happened a while ago.

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

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

[Cyril Brulebois]

Hi Simon,

Simon McVittie  (2020-09-03):
> On Sun, 21 Jan 2018 at 21:27:47 +0100, Egmont Koblinger wrote:
> > > We don't do c++ in d-i.
> > 
> > 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.
> 
> 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.

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


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

[Simon McVittie]

On Sun, 21 Jan 2018 at 21:27:47 +0100, Egmont Koblinger wrote:
> > We don't do c++ in d-i.
> 
> 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.

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

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

[Egmont Koblinger]

Hi guys,

> We don't do c++ in d-i.

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

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

[Michael Biebl]

On Fri, 19 Jan 2018 02:24:35 +0100 Cyril Brulebois  wrote:
> 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.

That's going to be hard:
https://git.gnome.org/browse/vte/commit/?id=958859d14ef4d94fc4735c700f550b57739f31ac

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Michael Biebl]

Am 19.01.2018 um 03:02 schrieb Michael Biebl:
> On Thu, 18 Jan 2018 19:11:36 -0500 Jeremy Bicha  wrote:
>> Control: block -1 by 887674
>>
>> On Thu, Jan 18, 2018 at 6:51 PM, Cyril Brulebois  wrote:
>>>  - 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.
>>
>> Ok, I filed a bug asking for a pcre2 udeb.
> 
> 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
> 

nvm...

CONFFLAGS_udeb = \
   --disable-gtk-doc \
   --without-gnutls


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Michael Biebl]

On Thu, 18 Jan 2018 19:11:36 -0500 Jeremy Bicha  wrote:
> Control: block -1 by 887674
> 
> On Thu, Jan 18, 2018 at 6:51 PM, Cyril Brulebois  wrote:
> >  - 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.
> 
> Ok, I filed a bug asking for a pcre2 udeb.

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

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Cyril Brulebois]

Control: severity 887674 important
Control: tag 887674 patch
Control: tag 887649 - patch

Cyril Brulebois  (2018-01-19):
> Control: severity -1 887674
> Control: tag -1 patch

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

> 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.

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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

[Cyril Brulebois]

Control: severity -1 887674
Control: tag -1 patch

Hi,

Jeremy Bicha  (2018-01-18):
> On Thu, Jan 18, 2018 at 6:51 PM, Cyril Brulebois  wrote:
> >  - 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.
> 
> Ok, I filed a bug asking for a pcre2 udeb.

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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
From 7b92f426899bf42311546d898c37e83ff9806389 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Fri, 19 Jan 2018 01:03:32 +
Subject: [PATCH 1/2] Add a libpcre2-8-0-udeb, needed by vte2.91 (Closes:
 #887674)

---
 debian/changelog | 6 ++
 debian/control   | 8 
 debian/libpcre2-8-0-udeb.install | 1 +
 debian/rules | 3 +++
 4 files changed, 18 insertions(+)
 create mode 100644 debian/libpcre2-8-0-udeb.install

diff --git a/debian/changelog b/debian/changelog
index b0de24f..0afc8f8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+pcre2 (10.22-6) UNRELEASED; urgency=medium
+
+  * Add a libpcre2-8-0-udeb, needed by vte2.91 (Closes: #887674)
+
+ -- Cyril Brulebois   Fri, 19 Jan 2018 01:00:12 +
+
 pcre2 (10.22-5) unstable; urgency=medium
 
   * Add Vcs-{Git,Browser} fields to debian/control
diff --git a/debian/control b/debian/control
index db57fd3..5478f42 100644
--- a/debian/control
+++ b/debian/control
@@ -22,6 +22,14 @@ Description: New Perl Compatible Regular Expression Library- 8 bit runtime files
  .
  This package contains the 8 bit runtime library.
 
+Package: libpcre2-8-0-udeb
+Package-Type: udeb
+Section: debian-installer
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: New Perl Compatible Regular Expression Library- 8 bit runtime files (udeb)
+ This package contains the 8 bit runtime library, for the Debian Installer.
+
 Package: libpcre2-16-0
 Section: libs
 Architecture: any
diff --git a/debian/libpcre2-8-0-udeb.install b/debian/libpcre2-8-0-udeb.install
new file mode 100644
index 000..1a38dd6
--- /dev/null
+++ b/debian/libpcre2-8-0-udeb.install
@@ -0,0 +1 @@
+debian/tmp/usr/lib/*/libpcre2-8.so.*
diff --git a/debian/rules b/debian/rules
index 66c4b28..07bd4b3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -25,5 +25,8 @@ endif
 override_dh_auto_configure:
 	dh_auto_configure -- $(deb_maint_conf_args)
 
+override_dh_makeshlibs:
+	dh_makeshlibs -V --add-udeb=libpcre2-8-0-udeb
+
 override_dh_strip:
 	dh_strip --dbg-package=libpcre2-dbg
-- 
2.11.0

From 74b118609c5715d6ec913c3a610cbaedc936693d Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Fri, 19 Jan 2018 02:23:44 +0100
Subject: [PATCH 2/2] Enable parallel building.

---
 debian/changelog | 1 +
 debian/rules | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 0afc8f8..0ffbc97 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
 pcre2 (10.22-6) UNRELEASED; urgency=medium
 
   * Add a libpcre2-8-0-udeb, needed by vte2.91 (Closes: #887674)
+  * Enable parallel building.
 
  -- Cyril Brulebois   Fri, 19 Jan 2018 01:00:12 +
 
diff --git a/debian/rules b/debian/rules
index 07bd4b3..614ac4a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,7 +20,7 @@ deb_maint_conf_args +=--disable-jit
 endif
 
 %:
-	dh $@
+	dh $@ --parallel
 
 override_dh_auto_configure:
 	dh_auto_configure -- $(deb_maint_conf_args)
-- 
2.11.0



signature.asc
Description: PGP signature

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

[Jeremy Bicha]

Control: block -1 by 887674

On Thu, Jan 18, 2018 at 6:51 PM, Cyril Brulebois  wrote:
>  - 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.

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

Thanks,
Jeremy Bicha

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

[Cyril Brulebois]

Hi,

Jeremy Bicha  (2018-01-18):
> Package: cdebconf-gtk-terminal
> Version: 0.31
> Severity: serious
> Tags: sid buster
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs vte
> 
> 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.

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.

> 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.)

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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

[Jeremy Bicha]

Package: cdebconf-gtk-terminal
Version: 0.31
Severity: serious
Tags: sid buster
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs vte

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