Bug#885786: gnustep-back: Please drop art backend package

[Yavor Doganov]

tags 885786 + pending
thanks

Bastian Germann wrote:
> Please drop the art backend package.  dia is in the process of being
> adopted and will also drop its art dependency, so we should make
> this happen as soon as possible so that bookworm can come without
> libart.

Will do in a few weeks; in any case it'll definitely happen well
before the freeze for the bookworm release.

Bug#885786: gnustep-back: Please drop art backend package

[Bastian Germann]

On Mon, 15 Jan 2018 12:24:45 +0200 Yavor Doganov  wrote:

2) The xlib backend comes with an additional tool: font_cacher.  It's
   launched automatically by the backend and generates the cache as
   archived data in ~/GNUstep/Library/Fonts/Cache.  It has the same
   problem as the gnustep-back-common's postinst: the cache must be
   updated manually when a font package is installed or removed.
   While this can be solved for art by fixing the fontconfig bug, I
   don't see a way to do it here.  Slightly archaic even for me.

   There's a manpage to be written; that's easy.  The font_cacher tool
   must be shipped in the -common package as the -xlib package will be
   versioned.


The xlib backend is now packaged for some years. Please drop the art backend 
package.
dia is in the process of being adopted and will also drop its art dependency,
so we should make this happen as soon as possible so that bookworm can come 
without libart.

Bug#885786: gnustep-back: Please drop art backend package

[Yavor Doganov]

[ Dropping Jeremy from CC; I guess this message doesn't concern him. ]

On Sat, 30 Dec 2017 02:59:18 +0200,
Yavor Doganov wrote:
> There are several options:
> 
>   1) Wait for the opal or wayland backends to be labelled "ready for
>  release".  We can drop art immediately then.
> 
>   2) Package the old xlib backend.  This is even more deprecated; the
>  only good news is that Xlib is not going away soon.
> 
>   3) Take libart under our umbrella.  (Provided it's a viable option
>  in the first place.)
> 
>   4) Just leave the cairo backend.

Here are some details:

1) The opal backend depends on the Opal library which requires GNUstep
   CoreBase.  I filed an ITP for it some time ago (#752553) but it was
   not uploaded as I found out some issues.  IIRC, the SVN trunk (back
   then) has had some ABI-incompatible changes but the SONAME was not
   bumped, so I had doubts about upstream's plans regarding longterm
   API/ABI stability.  Some symbols which were exported in 0.1.1 were
   marked as private and I was going to ask if they were
   unintentionally exported in the initial release or there's
   something else into it.  There was an ABI break between 0.1 and
   0.1.1, if I'm not mistaken.  And there hasn't been a new upstream
   release since a very long time.

   The Opal library will clash with src:opal in Debian, something I
   have reported upstream in 2014 [1].  While the source package name
   can be src:gnustep-opal, the issue with the binary package names
   and the actual library SONAME remains.  Additionally, Opal requires
   an old version of the lcms library (src:lcms was removed from
   Debian in 2014) so it can't be packaged anyway.  Finally, there
   have been no upstream releases at all.

   [1] https://savannah.gnu.org/bugs/?42606

2) The xlib backend comes with an additional tool: font_cacher.  It's
   launched automatically by the backend and generates the cache as
   archived data in ~/GNUstep/Library/Fonts/Cache.  It has the same
   problem as the gnustep-back-common's postinst: the cache must be
   updated manually when a font package is installed or removed.
   While this can be solved for art by fixing the fontconfig bug, I
   don't see a way to do it here.  Slightly archaic even for me.

   There's a manpage to be written; that's easy.  The font_cacher tool
   must be shipped in the -common package as the -xlib package will be
   versioned.

3) It looks like a completely dead project indeed.  I was surprised by
   the low bug count.  This doesn't mean it has no bugs, most probably
   it is because the library is basically unused these days.  There
   are some patches floating around which might be worth
   incorporating should we decide to go that route.

   As more distros are going to remove libart in the near future, if
   we adopt it we must do so with the state of mind that we're
   completely on our own and must fix all issues ourselves.

4) This is straightforward but not a viable option IMHO.


I think at this point we should do 2) as it does no harm.  The package
is going to pass through NEW anyway so we can do it right now for the
fortchoming transition.  The xlib backend can be dropped anytime if we
find out that it's too buggy for a stable release, if opal is packaged
or we decide to retain the art backend (by adopting the libart-lgpl
package).

Comments?

Bug#885786: gnustep-back: Please drop art backend package

[Yavor Doganov]

Jeremy Bicha wrote:
> On Fri, Dec 29, 2017 at 7:59 PM, Yavor Doganov  wrote:
> >   3) Take libart under our umbrella.  (Provided it's a viable option
> >  in the first place.)
> 
> As you can see, libart has had zero maintenance since 2010:

It doesn't bother me much.  Almost half of the GNUstep stack (non-core
packages and libraries) is unmaintained, some of them since 2001.
We're used to it.  As long as we can cope with security and other
important bugs, it is manageable.  But it's a last resort.

> But if we can remove libgnome, then it probably makes sense to
> remove libgnomecanvas too and if we can remove that, then this is
> one of the only packages left using libart.

Right, that's ironclad logic and I don't dispute your effort to get
rid of libraries that you have to maintain but have no future and/or
are abandoned upstream.  I'm just sharing our concerns.

> https://bugs.debian.org/885800 (and dia is unmaintained).

Dia was a flagman package once upon a time, I'm surprised to see it
unmaintained.  I'll take a look to see if I can help with this bug or
at least get some QA job done.  It's a real pity.

Ivan Vučica wrote:
> > On 30 Dec 2017, at 00:59, Yavor Doganov  wrote:
> > 
> >  1) Wait for the opal or wayland backends to be labelled "ready for
> > release".  We can drop art immediately then.
> 
> It would be nice if Opal (Core Graphics) would be packaged anyway (a
> requirement for the -back opal). I’m not aware of apps that require
> it, but it would not be terrible to have a dev package either.

Some time ago I filed an ITP bug for CoreBase but discovered some
ABI-related issues and couldn't upload the package back then.
Afterwards I went MIA and probably haven't even reported it upstream.
It has always been my intention to package Opal.

 > Wayland backend has not been merged at this time, and it’d be a
 > “windowing” backend, not a “drawing” backend anyway. That is: I
 > think it still uses Cairo.

Right.  It's still useful to have it as a separate backend.  There's a
truckload of windowing and rendering issues, different behavior,
different code paths and different font choices between the backends.

Bug#885786: gnustep-back: Please drop art backend package

[Jeremy Bicha]

On Fri, Dec 29, 2017 at 7:59 PM, Yavor Doganov  wrote:
>   3) Take libart under our umbrella.  (Provided it's a viable option
>  in the first place.)

As you can see, libart has had zero maintenance since 2010:

https://git.gnome.org/browse/archive/libart_lgpl/

You are correct that libart was not mentioned in that email. But if we
can remove libgnome, then it probably makes sense to remove
libgnomecanvas too and if we can remove that, then this is one of the
only packages left using libart. If you're really curious, the only
other issues I am aware of for libart's removal are
https://bugs.debian.org/885787 and https://bugs.debian.org/885800 (and
dia is unmaintained).

Anyway, we'll check in again later once more of the libgnome stack is
removed. Consider this to be early warning. :)

Thanks,
Jeremy Bicha

Bug#885786: [Debian GNUstep maintainers] Bug#885786: gnustep-back: Please drop art backend package

[Ivan Vučica]

> On 30 Dec 2017, at 00:59, Yavor Doganov  wrote:
> 
>  1) Wait for the opal or wayland backends to be labelled "ready for
> release".  We can drop art immediately then.

It would be nice if Opal (Core Graphics) would be packaged anyway (a 
requirement for the -back opal). I’m not aware of apps that require it, but it 
would not be terrible to have a dev package either.

Wayland backend has not been merged at this time, and it’d be a “windowing” 
backend, not a “drawing” backend anyway. That is: I think it still uses Cairo.

>  2) Package the old xlib backend.  This is even more deprecated; the
> only good news is that Xlib is not going away soon.

It sounds like a decent alternative for people that want ‘as simple backend as 
possible’, too.

>  3) Take libart under our umbrella.  (Provided it's a viable option
> in the first place.)

To reiterate what you mentioned earlier in your email, on upstream mailing 
lists there were recently some voices saying they prefer font rendering of 
libart. For reader’s reference, emails were from 2017-11-27 on gnustep-dev@.

>  4) Just leave the cairo backend.



signature.asc
Description: Message signed with OpenPGP

Bug#885786: gnustep-back: Please drop art backend package

[Yavor Doganov]

Control: tags -1 - patch

Jeremy Bicha wrote:
> Source: gnustep-back

> Could you please help by removing the art backend package? It doesn't
> have any reverse-depends in Debian.

I'm afraid we'll have to postpone this request.  Thanks for the patch,
but I'm formally removing the patch tag because it is incomplete: it
doesn't take into account the alternatives system and the maintainer
scripts.  However, this is not an issue at all; dropping the art
backend is straightforward and would be an easy thing to do -- we
certainly don't need patches to carry out this trivial job.

> [1] https://lists.debian.org/debian-devel/2017/10/msg00299.html

I don't see gnustep-back in the list of packages here; it's probably
because libart is (was) way down the (old) GNOME stack and isn't
really a GNOME library, although it has always been under the GNOME
umbrella.

It is very important for us to have at least two GNUstep backends
available in Debian.  That way, we can distinguish GUI vs. Back bugs
and also backend-specific bugs that only apply to a particular
backend.  We always invite bug reporters to try to reproduce with the
other backend, it sometimes helps to narrow down the problem.

The art backend has been deprecated upstream (GNUstep) for a long
time, but it's still useful and in some situations provides better
rendering of fonts in particular.  It has its issues (mostly #749233)
but cairo has other problems as well.

There are several options:

  1) Wait for the opal or wayland backends to be labelled "ready for
 release".  We can drop art immediately then.

  2) Package the old xlib backend.  This is even more deprecated; the
 only good news is that Xlib is not going away soon.

  3) Take libart under our umbrella.  (Provided it's a viable option
 in the first place.)

  4) Just leave the cairo backend.

Bug#885786: gnustep-back: Please drop art backend package

[Jeremy Bicha]

Source: gnustep-back
Version: 0.25.0-2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Tags: sid buster patch

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. These libraries have been
deprecated and unmaintained for several years.

Could you please help by removing the art backend package? It doesn't
have any reverse-depends in Debian.

I am attaching a patch to help with this (it applies against current
0.25.0-2 but you may want to use 'patch -p1' instead of 'git am' to
apply it against git master since I think there's some "fuzz").

[1] https://lists.debian.org/debian-devel/2017/10/msg00299.html

On behalf of the Debian GNOME team,
Jeremy BichaFrom a68505aa75559418a563699df0859a246a1c4913 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Fri, 29 Dec 2017 15:45:42 -0500
Subject: [PATCH] Drop unused libart package

---
 debian/control | 18 --
 debian/rules   | 58 --
 2 files changed, 76 deletions(-)

diff --git a/debian/control b/debian/control
index 1d6c5d9..4ca8b42 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,6 @@ Build-Depends: debhelper (>= 9),
libxft-dev,
libfontconfig1-dev,
libgl1-mesa-dev,
-   libart-2.0-dev,
pkg-config,
libcairo2-dev,
texinfo
@@ -41,23 +40,6 @@ Description: GNUstep GUI Backend
  .
  This is an empty package that depends on the various backends.
 
-Package: gnustep-back0.25-art
-Architecture: any
-Section: libs
-Depends: gnustep-back-common (= ${binary:Version}),
-	 ${shlibs:Depends},
-	 ${misc:Depends}
-Provides: gnustep-back0.25-alt
-Description: GNUstep GUI Backend (art)
- It is a backend component for the GNUstep GUI Library.
- The implementation of the GNUstep GUI Library is designed in two parts.
- The first part is the front-end component which is independent of platform
- and display system.  This front-end is combined with a back-end
- component which handles all of the display system dependent such as
- specific calls to the X Window System.
- .
- This package provides the deprecated libart backend.
-
 Package: gnustep-back0.25-cairo
 Architecture: any
 Section: libs
diff --git a/debian/rules b/debian/rules
index 86034c7..398d299 100755
--- a/debian/rules
+++ b/debian/rules
@@ -43,7 +43,6 @@ sov_gui := $(sov_back)
  PACKAGES NAMES #
 
 p_back  = gnustep-back$(sov_back)
-p_art   = gnustep-back$(sov_back)-art
 p_cairo = gnustep-back$(sov_back)-cairo
 p_common= gnustep-back-common
 p_dbg		= gnustep-back-dbg
@@ -51,7 +50,6 @@ p_dbg		= gnustep-back-dbg
  DIRS ###
 
 # build dirs
-b_art   = $(CURDIR)/build-art
 b_cairo = $(CURDIR)/build-cairo
 b_tools		= $(CURDIR)/build-tools
 
@@ -89,20 +87,6 @@ override_dh_auto_configure:
 	sed -e 's,@DEB_GNUSTEP_FONTSDIR@,$(DEB_GNUSTEP_FONTSDIR),g' \
 	debian/templates/gnustep-back-common.prerm.in > debian/gnustep-back-common.prerm
 	
-	# generate gnustep-backN-art.postinst file
-	sed -e 's:@GNUSTEP_LIBRARY@:$(GNUSTEP_SYSTEM_LIBRARY):g' \
-	-e 's:@IFVER@:$(ifv_back):g' \
-	-e 's:@BACKEND@:art:g' \
-	-e 's:@PRIORITY@:10:g' \
-	debian/templates/gnustep-backN-backend.postinst.in > debian/gnustep-back$(sov_back)-art.postinst
-	
-	# generate gnustep-backN-art.prerm file
-	sed -e 's:@GNUSTEP_LIBRARY@:$(GNUSTEP_SYSTEM_LIBRARY):g' \
-	-e 's:@IFVER@:$(ifv_back):g' \
-	-e 's:@BACKEND@:art:g' \
-	-e 's:@PRIORITY@:10:g' \
-	debian/templates/gnustep-backN-backend.prerm.in > debian/gnustep-back$(sov_back)-art.prerm
-	
 	# generate gnustep-backN-cairo.postinst file
 	sed -e 's:@GNUSTEP_LIBRARY@:$(GNUSTEP_SYSTEM_LIBRARY):g' \
 	-e 's:@IFVER@:$(ifv_back):g' \
@@ -117,24 +101,12 @@ override_dh_auto_configure:
 	-e 's:@PRIORITY@:15:g' \
 	debian/templates/gnustep-backN-backend.prerm.in > debian/gnustep-back$(sov_back)-cairo.prerm
 	
-	# generate gnustep-backN-art.install file
-	sed -e 's:@GNUSTEP_LIBRARY@:$(GNUSTEP_SYSTEM_LIBRARY):g' \
-	-e 's:@IFVER@:$(ifv_back):g' \
-	-e 's:@BACKEND@:art:g' \
-	debian/templates/gnustep-backN-backend.install.in > debian/gnustep-back$(sov_back)-art.install
-	
 	# generate gnustep-backN-cairo.install file
 	sed -e 's:@GNUSTEP_LIBRARY@:$(GNUSTEP_SYSTEM_LIBRARY):g' \
 	-e 's:@IFVER@:$(ifv_back):g' \
 	-e 's:@BACKEND@:cairo:g' \
 	debian/templates/gnustep-backN-backend.install.in > debian/gnustep-back$(sov_back)-cairo.install
 	
-	# generate gnustep-backN-art.links file
-	sed -e 's:@GNUSTEP_LIBRARY@:$(GNUSTEP_SYSTEM_LIBRARY):g' \
-	-e 's:@IFVER@:$(ifv_back):g' \
-	-e 's:@BACKEND@:art:g' \
-	debian/templates/gnustep-backN-backend.links.in > debian/gnustep-back$(sov_back)-art.links
-