gworkspace.app: Loader error when launching GWorkspace

[Debian Bug Importer]

Automatically imported from Debian bug report #314385 http://bugs.debian.org/314385

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.8.14
reassign 314385 gnustep-back

[Hubert Chathi (uhoreg)]

On Sat, 18 Jun 2005 11:57:59 +0200, "Jose A. Ortega Ruiz" <email address hidden> said:

> Hi. I am running Debian unstable on an iBook and, recently, GNUstep
> packages have stop working. When I try to launch any GNUstep app, I
> get an error like this one:

> /usr/lib/GNUstep/System/Applications/Cynthiune.app/Cynthiune:
> relocation error:
> /usr/lib/GNUstep/System/Library/Bundles/libgnustep-back.bundle/./libgnustep-back:
> undefined symbol: FTC_Manager_Lookup_Size

As a temporary workaround, downgrade libfreetype6 to something before
2.1.10-1, and it should work fine. (I'm using libfreetype6 2.1.7-2.4.)

It looks like freetype renamed that function to FTC_Manager_LookupSize
(removed the last `_'). The FTC_Manager_Lookup_Face function was
renamed similarly.

--
Hubert Chan <email address hidden> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.

[Steve Langasek (vorlon)]

reassign 314385 libfreetype6
thanks

On Sat, Jun 18, 2005 at 01:41:17PM -0400, Hubert Chan wrote:
> On Sat, 18 Jun 2005 11:57:59 +0200, "Jose A. Ortega Ruiz" <email address hidden> said:

> > Hi. I am running Debian unstable on an iBook and, recently, GNUstep
> > packages have stop working. When I try to launch any GNUstep app, I
> > get an error like this one:

> > /usr/lib/GNUstep/System/Applications/Cynthiune.app/Cynthiune:
> > relocation error:
> > /usr/lib/GNUstep/System/Library/Bundles/libgnustep-back.bundle/./libgnustep-back:
> > undefined symbol: FTC_Manager_Lookup_Size

> As a temporary workaround, downgrade libfreetype6 to something before
> 2.1.10-1, and it should work fine. (I'm using libfreetype6 2.1.7-2.4.)

> It looks like freetype renamed that function to FTC_Manager_LookupSize
> (removed the last `_'). The FTC_Manager_Lookup_Face function was
> renamed similarly.

Arrrrrrgh. Reassigning to libfreetype6.

Will, please readd the dropped symbols, or get this package renamed.

--
Steve Langasek
postmodern programmer

[Lenin (gagarin)]

# Automatically generated email from bts, devscripts version 2.8.1
merge 314385 320958

[Lenin (gagarin)]

# Automatically generated email from bts, devscripts version 2.8.4
merge 314385 321646

[Vincent Danjean (vincent-danjean)]

# Automatically generated email from bts, devscripts version 2.9.2
merge 321912 314385

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #314385 http://bugs.debian.org/314385

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 16 Jun 2005 02:33:49 +0200
From: Jose Antonio Ortega Ruiz <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: gworkspace.app: Loader error when launching GWorkspace

Package: gworkspace.app
Version: 0.7.0-1
Severity: grave
Justification: renders package unusable

Hi. When trying to launch GWorkspace (or, in fact, most GNUstep apps), I
get the following error:

/usr/lib/GNUstep/System/Applications/GWorkspace.app/GWorkspace:
relocation error:
/usr/lib/GNUstep/System/Library/Bundles/libgnustep-back.bundle/./libgnustep-back:
undefined symbol: FTC_Manager_Lookup_Size

which seems to be related with the freetype library version installed in
the system.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages gworkspace.app depends on:
ii gnustep-back 0.9.5-1 The GNUstep GUI Backend
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libgnustep-base1.10 1.10.3-1 GNUstep Base library
ii libgnustep-gui0.9 0.9.5-1 GNUstep Gui Library
ii libobjc1 1:4.0.0-9 Runtime library for GNU Objective-
ii pdfkit.framework 0.8-2 Imaging-related GNUstep framework

Versions of packages gworkspace.app recommends:
ii cynthiune.app 0.9.4-2 A free software and romantic music
ii preferences 1.2.100.0-1 GNUstep Preferences application
ii preview.app 0.7.5-1 General purpose image viewer for G
ii textedit.app 4.0-1 Basic text editor for GNUstep
ii viewpdf.app 0.9-1 Portable Document Format (PDF) vie
ii wrapperfactory.app 0.1.0-1 Application wrappers configuration
ii zipper.app 1.0-1 Tool for inspecting the contents o

Versions of packages gworkspace.app is related to:
ii reportbug 6763.13 reports bugs in the Debian distrib
pn totem-gstreamer <none> (no description available)

-- no debconf information

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 15 Jun 2005 18:07:54 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: reassign 314385 to gnustep-back

# Automatically generated email from bts, devscripts version 2.8.14
reassign 314385 gnustep-back

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 18 Jun 2005 13:41:17 -0400
From: Hubert Chan <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: Loading error in GNUstep apps

On Sat, 18 Jun 2005 11:57:59 +0200, "Jose A. Ortega Ruiz" <email address hidden> said:

> Hi. I am running Debian unstable on an iBook and, recently, GNUstep
> packages have stop working. When I try to launch any GNUstep app, I
> get an error like this one:

> /usr/lib/GNUstep/System/Applications/Cynthiune.app/Cynthiune:
> relocation error:
> /usr/lib/GNUstep/System/Library/Bundles/libgnustep-back.bundle/./libgnustep-back:
> undefined symbol: FTC_Manager_Lookup_Size

As a temporary workaround, downgrade libfreetype6 to something before
2.1.10-1, and it should work fine. (I'm using libfreetype6 2.1.7-2.4.)

It looks like freetype renamed that function to FTC_Manager_LookupSize
(removed the last `_'). The FTC_Manager_Lookup_Face function was
renamed similarly.

--
Hubert Chan <email address hidden> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 18 Jun 2005 11:03:19 -0700
From: Steve Langasek <email address hidden>
To: Hubert Chan <email address hidden>, <email address hidden>
Subject: Re: Bug#314385: Loading error in GNUstep apps

--IpbVkmxF4tDyP/Kb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

reassign 314385 libfreetype6
thanks

On Sat, Jun 18, 2005 at 01:41:17PM -0400, Hubert Chan wrote:
> On Sat, 18 Jun 2005 11:57:59 +0200, "Jose A. Ortega Ruiz" <email address hidden> s=
aid:

> > Hi. I am running Debian unstable on an iBook and, recently, GNUstep
> > packages have stop working. When I try to launch any GNUstep app, I
> > get an error like this one:

> > /usr/lib/GNUstep/System/Applications/Cynthiune.app/Cynthiune:
> > relocation error:
> > /usr/lib/GNUstep/System/Library/Bundles/libgnustep-back.bundle/./libgnu=
step-back:
> > undefined symbol: FTC_Manager_Lookup_Size

> As a temporary workaround, downgrade libfreetype6 to something before
> 2.1.10-1, and it should work fine. (I'm using libfreetype6 2.1.7-2.4.)

> It looks like freetype renamed that function to FTC_Manager_LookupSize
> (removed the last `_'). The FTC_Manager_Lookup_Face function was
> renamed similarly.

Arrrrrrgh. Reassigning to libfreetype6.

Will, please readd the dropped symbols, or get this package renamed.

--=20
Steve Langasek
postmodern programmer

--IpbVkmxF4tDyP/Kb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCtGHmKN6ufymYLloRAhjLAKDAh3dXvWcA8sqHf3QTPkmkIAS9TgCgwF3X
99hfD0BuewioKxtetPAT2Es=
=1Cn5
-----END PGP SIGNATURE-----

--IpbVkmxF4tDyP/Kb--

[Debian Bug Importer (debzilla)]

Message-Id: <1123360317.205610.3666.nullmailer@debian>
Date: Sat, 6 Aug 2005 22:31:57 +0200
From: Gürkan Sengün <email address hidden>
To: <email address hidden>
Subject: merging 314385 320958

# Automatically generated email from bts, devscripts version 2.8.1
merge 314385 320958

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 7 Aug 2005 13:02:20 +0200
From: Gürkan Sengün <email address hidden>
To: <email address hidden>
Subject: merging 314385 321646

# Automatically generated email from bts, devscripts version 2.8.4
merge 314385 321646

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 9 Aug 2005 14:19:39 +0200
From: Vincent Danjean <email address hidden>
To: <email address hidden>
Subject: merging 321912 314385

# Automatically generated email from bts, devscripts version 2.9.2
merge 321912 314385

[Debian Bug Importer (debzilla)]

*** Bug 19893 has been marked as a duplicate of this bug. ***

[Debian Bug Importer (debzilla)]

*** Bug 19905 has been marked as a duplicate of this bug. ***

[Debian Bug Importer (debzilla)]

*** Bug 19914 has been marked as a duplicate of this bug. ***

[Michael Vogt (mvo)]

This bug does not affect us because we are using "libfreetype6
2.1.7-2.4ubuntu1" and the trouble starts with 2.1.10-1

[Lenin (gagarin)]

# Automatically generated email from bts, devscripts version 2.8.14
merge 320958 329223

[Debian Bug Importer (debzilla)]

*** Bug 22126 has been marked as a duplicate of this bug. ***

[Michael Vogt (mvo)]

Just as a additional note, gworkspace.app works fine in ubuntu

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 20 Sep 2005 23:24:42 +0200
From: Gürkan Sengün <email address hidden>
To: <email address hidden>
Subject: merging 320958 329223

# Automatically generated email from bts, devscripts version 2.8.14
merge 320958 329223

[Filipus Klutiero (ido)]

merge 337143 314385
thanks

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 10 Nov 2005 06:48:58 -0500
From: Filipus Klutiero <email address hidden>
To: <email address hidden>
Subject: Merge

merge 337143 314385
thanks

[Debian Bug Importer (debzilla)]

*** Bug 24952 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

A quick scan of the diff reveals at least the following API and ABI changes:

Functions:
FTC_Image_Cache_New -> FTC_ImageCache_New
FTC_Image_Cache_Lookup -> FTC_ImageCache_Lookup
FTC_SBit_Cache_New -> FTC_SBitCache_New
FTC_SBit_Cache_Lookup -> FTC_SBit_Cache_Lookup
FTC_Manager_Lookup_Face -> FTC_Manager_LookupFace
FTC_Manager_Lookup_Size -> FTC_Manager_LookupSize

Types:
FTC_Image_Desc -> FTC_ImageTypeRec
FTC_Image_Cache -> FTC_ImageCache
FTC_SBit -> FTC_SBitRec
FTC_SBit_Cache -> FTC_SBitCache

As a special bonus, FTC_ImageTypeRec, though it is said to obsolete
FTC_Image_Desc, has completely different members.

--
 - mdz

[Matt Zimmerman (mdz)]

On Thu, Nov 17, 2005 at 06:45:14PM -0800, Matt Zimmerman wrote:
> FTC_SBit_Cache_Lookup -> FTC_SBit_Cache_Lookup

This should be:

FTC_SBit_Cache_Lookup -> FTC_SBitCache_Lookup

of course.

--
 - mdz

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 17 Nov 2005 18:45:14 -0800
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Subject: Freetype mess

A quick scan of the diff reveals at least the following API and ABI changes:

Functions:
FTC_Image_Cache_New -> FTC_ImageCache_New
FTC_Image_Cache_Lookup -> FTC_ImageCache_Lookup
FTC_SBit_Cache_New -> FTC_SBitCache_New
FTC_SBit_Cache_Lookup -> FTC_SBit_Cache_Lookup
FTC_Manager_Lookup_Face -> FTC_Manager_LookupFace
FTC_Manager_Lookup_Size -> FTC_Manager_LookupSize

Types:
FTC_Image_Desc -> FTC_ImageTypeRec
FTC_Image_Cache -> FTC_ImageCache
FTC_SBit -> FTC_SBitRec
FTC_SBit_Cache -> FTC_SBitCache

As a special bonus, FTC_ImageTypeRec, though it is said to obsolete
FTC_Image_Desc, has completely different members.

--
 - mdz

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 17 Nov 2005 18:48:15 -0800
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Subject: Re: Freetype mess

On Thu, Nov 17, 2005 at 06:45:14PM -0800, Matt Zimmerman wrote:
> FTC_SBit_Cache_Lookup -> FTC_SBit_Cache_Lookup

This should be:

FTC_SBit_Cache_Lookup -> FTC_SBitCache_Lookup

of course.

--
 - mdz

[Matt Zimmerman (mdz)]

*** Bug 25790 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

This is breaking all sorts of things; please make it a priority

[magilus (magilus)]

I can verify this in Dapper Drake.

[Daniel Holbach (dholbach)]

Hello,

without checking the exported symbols, I synced 2.1.10-1 into Ubuntu.
Feeling slightly guilty, I felt responsible to work on getting the
situation 'fixed'. To solve this problem, (I read that it'll be a long
way to freetype 2.2), I'd like to come to an agreement here.

With the information that Matt revealed, I think it'd make sense to
rename the package to libfreetype6a (or whatever) and treat this like a
'normal' transition, that other libraries do as well.

I'd just like to come to an agreement, so we have minimal delta between
Debian and Ubuntu (and get over the problem soon).

Hope to hear from your soon. Have a nice day,
 Daniel

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 21 Nov 2005 08:54:50 +0100
From: Daniel Holbach <email address hidden>
To: <email address hidden>
Subject: Agreement?

--=-RPUXjaXKPUixhAPS+RXQ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hello,

without checking the exported symbols, I synced 2.1.10-1 into Ubuntu.
Feeling slightly guilty, I felt responsible to work on getting the
situation 'fixed'. To solve this problem, (I read that it'll be a long
way to freetype 2.2), I'd like to come to an agreement here.=20

With the information that Matt revealed, I think it'd make sense to
rename the package to libfreetype6a (or whatever) and treat this like a
'normal' transition, that other libraries do as well.

I'd just like to come to an agreement, so we have minimal delta between
Debian and Ubuntu (and get over the problem soon).

Hope to hear from your soon. Have a nice day,
 Daniel

--=-RPUXjaXKPUixhAPS+RXQ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDgX1Kr3O2CKlAUK8RAltIAJ0eU3r5tYnyu6fIucmfUFfFnZf2SwCfdLiF
i+7IhNrcntNZTIOOylG2QHQ=
=91Ja
-----END PGP SIGNATURE-----

--=-RPUXjaXKPUixhAPS+RXQ--

[Loïc Minier (lool)]

        Hi,

On Mon, Nov 21, 2005, Daniel Holbach wrote:
> With the information that Matt revealed, I think it'd make sense to
> rename the package to libfreetype6a (or whatever) and treat this like a
> 'normal' transition, that other libraries do as well.

 I think you should reupload a fixed package exactly at the same time
 you do the transition, to permit applications linked against the
 previous package to continue working. Something like the libssl
 situation:
 - contact ftpmasters + release to warn them
 - prepare a freetype2.1.9 source package providing the same binary
   packages as in the past
 - prepare a freetype source package with the transitionned package
   names you described
 - upload freetype
 - when it gets accepted (out of NEW), upload freetype2.1.9

 This is a proposal, release or ftpmasters should agree with this first.

--
Loïc Minier <email address hidden>
"What do we want? BRAINS! When do we want it? BRAINS!"

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 21 Nov 2005 10:14:03 +0100
From: Loic Minier <email address hidden>
To: Daniel Holbach <email address hidden>
Cc: <email address hidden>
Subject: Re: Agreement?

        Hi,

On Mon, Nov 21, 2005, Daniel Holbach wrote:
> With the information that Matt revealed, I think it'd make sense to
> rename the package to libfreetype6a (or whatever) and treat this like a
> 'normal' transition, that other libraries do as well.

 I think you should reupload a fixed package exactly at the same time
 you do the transition, to permit applications linked against the
 previous package to continue working. Something like the libssl
 situation:
 - contact ftpmasters + release to warn them
 - prepare a freetype2.1.9 source package providing the same binary
   packages as in the past
 - prepare a freetype source package with the transitionned package
   names you described
 - upload freetype
 - when it gets accepted (out of NEW), upload freetype2.1.9

 This is a proposal, release or ftpmasters should agree with this first.

--=20
Lo=EFc Minier <email address hidden>
"What do we want? BRAINS! When do we want it? BRAINS!"

[Steve Langasek (vorlon)]

On Mon, Nov 21, 2005 at 08:54:50AM +0100, Daniel Holbach wrote:

> without checking the exported symbols, I synced 2.1.10-1 into Ubuntu.
> Feeling slightly guilty, I felt responsible to work on getting the
> situation 'fixed'. To solve this problem, (I read that it'll be a long
> way to freetype 2.2), I'd like to come to an agreement here.

> With the information that Matt revealed

We already knew that the ABI had been broken; I'm not sure why Matt's
follow-up is a deciding factor here...

> I think it'd make sense to rename the package to libfreetype6a
> (or whatever) and treat this like a 'normal' transition, that other
> libraries do as well.

The issue is that it's very nasty to do this without coordinating with
upstream regarding an soname change.

The *other* issue is that this bit of brokenness has lingered long enough
that freetype is now the main blocker for package updates in testing.
Having to go through a package name change at this point will further block
progress in testing (including, at this point, the revised C++ ABI
transition).

So given that the current upstream 2.1.10 version can't go into testing as
libfreetype6, I favor figuring out how to restore this library to the proper
libfreetype6 interface. This may be doable with 2.1.10 and minimal changes,
or it might require epoching and reverting to 2.1.7/9 in the interest of
sanity.

From my POV then, the options are, in decreasing order of preference:

- restore ABI compatibility with libfreetype6 to freetype 2.1.10, in
  cooperation with upstream
- restore ABI compatibility with libfreetype6 to freetype 2.1.10, without
  upstream's cooperation :/
- downgrade to a compatible version of freetype using an epoch
- talk upstream into reissuing freetype 2.1.10 as libfreetype7 instead of
  libfreetype6, and transition
- (worst option) repackage freetype 2.1.10 as libfreetype6debian1

Will, your thoughts on this as maintainer (and liaison to upstream) are most
welcome; this will all run much better if we get upstream on-board with
whatever's decided...

Loic Minier wrote:

> I think you should reupload a fixed package exactly at the same time
> you do the transition, to permit applications linked against the
> previous package to continue working. Something like the libssl
> situation:
> - contact ftpmasters + release to warn them
> - prepare a freetype2.1.9 source package providing the same binary
> packages as in the past
> - prepare a freetype source package with the transitionned package
> names you described

This procedure should be avoided except in cases where the library is
important enough to keep around for binary compatibility with software
external to Debian. I don't have reason to believe this is the case for
libfreetype; do you?

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Loïc Minier (lool)]

On Mon, Nov 21, 2005, Steve Langasek wrote:
> This procedure should be avoided except in cases where the library is
> important enough to keep around for binary compatibility with software
> external to Debian. I don't have reason to believe this is the case for
> libfreetype; do you?

 I'm not sure of what you mean, but I thought the rdeps of libfreetype
 (mostly via gtk) made it important enough to warrant such care.

 Anyway, your preferred option seems saner, and quite doable given the
 limited amount of API / ABI changes as listed by mdz.

   Bye,
--
Loïc Minier <email address hidden>

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 21 Nov 2005 02:35:41 -0800
From: Steve Langasek <email address hidden>
To: Daniel Holbach <email address hidden>, <email address hidden>, Loic Minier <email address hidden>
Subject: Re: Bug#314385: Agreement?

--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 21, 2005 at 08:54:50AM +0100, Daniel Holbach wrote:

> without checking the exported symbols, I synced 2.1.10-1 into Ubuntu.
> Feeling slightly guilty, I felt responsible to work on getting the
> situation 'fixed'. To solve this problem, (I read that it'll be a long
> way to freetype 2.2), I'd like to come to an agreement here.=20

> With the information that Matt revealed

We already knew that the ABI had been broken; I'm not sure why Matt's
follow-up is a deciding factor here...

> I think it'd make sense to rename the package to libfreetype6a
> (or whatever) and treat this like a 'normal' transition, that other
> libraries do as well.

The issue is that it's very nasty to do this without coordinating with
upstream regarding an soname change.

The *other* issue is that this bit of brokenness has lingered long enough
that freetype is now the main blocker for package updates in testing.
Having to go through a package name change at this point will further block
progress in testing (including, at this point, the revised C++ ABI
transition).

So given that the current upstream 2.1.10 version can't go into testing as
libfreetype6, I favor figuring out how to restore this library to the proper
libfreetype6 interface. This may be doable with 2.1.10 and minimal changes,
or it might require epoching and reverting to 2.1.7/9 in the interest of
sanity.

=46rom my POV then, the options are, in decreasing order of preference:

- restore ABI compatibility with libfreetype6 to freetype 2.1.10, in
  cooperation with upstream
- restore ABI compatibility with libfreetype6 to freetype 2.1.10, without
  upstream's cooperation :/
- downgrade to a compatible version of freetype using an epoch
- talk upstream into reissuing freetype 2.1.10 as libfreetype7 instead of
  libfreetype6, and transition
- (worst option) repackage freetype 2.1.10 as libfreetype6debian1

Will, your thoughts on this as maintainer (and liaison to upstream) are most
welcome; this will all run much better if we get upstream on-board with
whatever's decided...

Loic Minier wrote:

> I think you should reupload a fixed package exactly at the same time
> you do the transition, to permit applications linked against the
> previous package to continue working. Something like the libssl
> situation:
> - contact ftpmasters + release to warn them
> - prepare a freetype2.1.9 source package providing the same binary
> packages as in the past
> - prepare a freetype source package with the transitionned package
> names you described

This procedure should be avoided except in cases where the library is
important enough to keep around for binary compatibility with software
external to Debian. I don't have reason to believe this is the case for
libfreetype; do you?

Thanks,
--=20
Steve Langa...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 21 Nov 2005 11:45:05 +0100
From: Loic Minier <email address hidden>
To: Steve Langasek <email address hidden>
Cc: Daniel Holbach <email address hidden>,
 <email address hidden>
Subject: Re: Bug#314385: Agreement?

On Mon, Nov 21, 2005, Steve Langasek wrote:
> This procedure should be avoided except in cases where the library is
> important enough to keep around for binary compatibility with software
> external to Debian. I don't have reason to believe this is the case fo=
r
> libfreetype; do you?

 I'm not sure of what you mean, but I thought the rdeps of libfreetype
 (mostly via gtk) made it important enough to warrant such care.

 Anyway, your preferred option seems saner, and quite doable given the
 limited amount of API / ABI changes as listed by mdz.

   Bye,
--=20
Lo=EFc Minier <email address hidden>

[Steve Langasek (vorlon)]

On Mon, Nov 21, 2005 at 11:45:05AM +0100, Loic Minier wrote:
> On Mon, Nov 21, 2005, Steve Langasek wrote:
> > This procedure should be avoided except in cases where the library is
> > important enough to keep around for binary compatibility with software
> > external to Debian. I don't have reason to believe this is the case for
> > libfreetype; do you?

> I'm not sure of what you mean, but I thought the rdeps of libfreetype
> (mostly via gtk) made it important enough to warrant such care.

I mean that the only reason to ship an old freetype in etch is for
compatibility with other software that we don't control; so if that's not an
issue, we should be transitioning Debian as quickly as possible to the new
version, rather than carrying two versions around (which, btw, would
probably cause segfaults).

> Anyway, your preferred option seems saner, and quite doable given the
> limited amount of API / ABI changes as listed by mdz.

Other symbols removed since 2.1.7, btw:

FTC_Manager_Register_Cache -> FTC_Manager_RegisterCache
FT_LruList_Destroy -> FTC_MruList_Done?
FT_LruList_Lookup -> FTC_MruList_Lookup?
FT_LruList_New -> FTC_MruList_New?
FT_LruList_Remove -> FTC_MruList_Remove?
FT_LruList_Remove_Selection -> FTC_MruList_RemoveSelection?
FT_LruList_Reset -> FTC_MruList_Reset?
ftc_cache_clear -> FTC_Cache_Clear
ftc_cache_done -> FTC_Cache_Done
ftc_cache_init -> FTC_Cache_Init
ftc_cache_lookup -> FTC_Cache_Lookup
ftc_family_done -> ?
ftc_family_init -> FTC_Family_Init ?
ftc_family_table_alloc -> ?
ftc_family_table_free -> ?
ftc_glyph_family_done -> ?
ftc_glyph_family_init -> ?
ftc_glyph_node_compare -> ?
ftc_glyph_node_done -> ?
ftc_glyph_node_init -> ?
ftc_node_done -> FTC_GNode_Done ?

Symbols that are removed and are not mentioned in the headers for 2.1.7, but
who knows whether that means they were part of the interface earlier :/ :

BitOrderInvert -> ?
FourByteSwap -> ?
RepadBitmap -> ?
TwoByteSwap -> ?

Even worse, though, is the number of symbols *added* -- 75 new symbols, vs.
32 removed. Since the maintainer did not bump the shlibs when uploading,
either, there's no way to determine which packages are using the new ABI
except by looking at upload dates.

I'm afraid that a library transition may be the only sane option after
all... :/

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 21 Nov 2005 03:33:49 -0800
From: Steve Langasek <email address hidden>
To: Loic Minier <email address hidden>
Cc: Daniel Holbach <email address hidden>,
 <email address hidden>
Subject: Re: Bug#314385: Agreement?

--phCU5ROyZO6kBE05
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 21, 2005 at 11:45:05AM +0100, Loic Minier wrote:
> On Mon, Nov 21, 2005, Steve Langasek wrote:
> > This procedure should be avoided except in cases where the library is
> > important enough to keep around for binary compatibility with software
> > external to Debian. I don't have reason to believe this is the case for
> > libfreetype; do you?

> I'm not sure of what you mean, but I thought the rdeps of libfreetype
> (mostly via gtk) made it important enough to warrant such care.

I mean that the only reason to ship an old freetype in etch is for
compatibility with other software that we don't control; so if that's not an
issue, we should be transitioning Debian as quickly as possible to the new
version, rather than carrying two versions around (which, btw, would
probably cause segfaults).

> Anyway, your preferred option seems saner, and quite doable given the
> limited amount of API / ABI changes as listed by mdz.

Other symbols removed since 2.1.7, btw:

FTC_Manager_Register_Cache -> FTC_Manager_RegisterCache
FT_LruList_Destroy -> FTC_MruList_Done?
FT_LruList_Lookup -> FTC_MruList_Lookup?
FT_LruList_New -> FTC_MruList_New?
FT_LruList_Remove -> FTC_MruList_Remove?
FT_LruList_Remove_Selection -> FTC_MruList_RemoveSelection?
FT_LruList_Reset -> FTC_MruList_Reset?
ftc_cache_clear -> FTC_Cache_Clear
ftc_cache_done -> FTC_Cache_Done
ftc_cache_init -> FTC_Cache_Init
ftc_cache_lookup -> FTC_Cache_Lookup
ftc_family_done -> ?
ftc_family_init -> FTC_Family_Init ?
ftc_family_table_alloc -> ?
ftc_family_table_free -> ?
ftc_glyph_family_done -> ?
ftc_glyph_family_init -> ?
ftc_glyph_node_compare -> ?
ftc_glyph_node_done -> ?
ftc_glyph_node_init -> ?
ftc_node_done -> FTC_GNode_Done ?

Symbols that are removed and are not mentioned in the headers for 2.1.7, but
who knows whether that means they were part of the interface earlier :/ :

BitOrderInvert -> ?
FourByteSwap -> ?
RepadBitmap -> ?
TwoByteSwap -> ?

Even worse, though, is the number of symbols *added* -- 75 new symbols, vs.
32 removed. Since the maintainer did not bump the shlibs when uploading,
either, there's no way to determine which packages are using the new ABI
except by looking at upload dates.

I'm afraid that a library transition may be the only sane option after
all... :/

--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

--phCU5ROyZO6kBE05
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDgbCdKN6ufymYLloRArYhAJ48vyNE36CHV0OK+6ZGnArdgmr+NgCfW...

[Will Newton (will-misconception)]

On Monday 21 November 2005 10:35, Steve Langasek wrote:

> - restore ABI compatibility with libfreetype6 to freetype 2.1.10, in
> cooperation with upstream
> - restore ABI compatibility with libfreetype6 to freetype 2.1.10, without
> upstream's cooperation :/
> - downgrade to a compatible version of freetype using an epoch
> - talk upstream into reissuing freetype 2.1.10 as libfreetype7 instead of
> libfreetype6, and transition
> - (worst option) repackage freetype 2.1.10 as libfreetype6debian1

I would agree with this ordering.

> Will, your thoughts on this as maintainer (and liaison to upstream) are
> most welcome; this will all run much better if we get upstream on-board
> with whatever's decided...

Last time I talked to upstream about this it was suggested that the 2.2.0
release may be quite imminent. That was a couple of months ago however, so
I'll check back with upstream.

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 21 Nov 2005 13:10:46 +0000
From: Will Newton <email address hidden>
To: Steve Langasek <email address hidden>,
 <email address hidden>
Cc: Daniel Holbach <email address hidden>,
 Loic Minier <email address hidden>
Subject: Re: Bug#314385: Agreement?

On Monday 21 November 2005 10:35, Steve Langasek wrote:

> - restore ABI compatibility with libfreetype6 to freetype 2.1.10, in
> cooperation with upstream
> - restore ABI compatibility with libfreetype6 to freetype 2.1.10, without
> upstream's cooperation :/
> - downgrade to a compatible version of freetype using an epoch
> - talk upstream into reissuing freetype 2.1.10 as libfreetype7 instead of
> libfreetype6, and transition
> - (worst option) repackage freetype 2.1.10 as libfreetype6debian1

I would agree with this ordering.

> Will, your thoughts on this as maintainer (and liaison to upstream) are
> most welcome; this will all run much better if we get upstream on-board
> with whatever's decided...

Last time I talked to upstream about this it was suggested that the 2.2.0
release may be quite imminent. That was a couple of months ago however, so
I'll check back with upstream.

[Matt Zimmerman (mdz)]

On Mon, Nov 21, 2005 at 03:33:49AM -0800, Steve Langasek wrote:
> On Mon, Nov 21, 2005 at 11:45:05AM +0100, Loic Minier wrote:
> > Anyway, your preferred option seems saner, and quite doable given the
> > limited amount of API / ABI changes as listed by mdz.
>
> Other symbols removed since 2.1.7, btw:
>
> [lots]

I'm afraid I probably won't find time to do an exhaustive search, but I
think it would be worthwhile to directly test each package depending on
libfreetype6 and find the set of now-missing symbols which are important in
Debian. Even if it isn't practical for us to restore 100% compatibility
with 2.1.7, we may be able to achieve something which is close enough, with
a relatively small deltia to 2.1.10.

> Even worse, though, is the number of symbols *added* -- 75 new symbols, vs.
> 32 removed. Since the maintainer did not bump the shlibs when uploading,
> either, there's no way to determine which packages are using the new ABI
> except by looking at upload dates.

Anything which has started using new symbols from 2.1.10 is extremely likely
to still be API-compatible with previous versions, and can simply be
recompiled, no?

--
 - mdz

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 21 Nov 2005 07:51:56 -0800
From: Matt Zimmerman <email address hidden>
To: Steve Langasek <email address hidden>, <email address hidden>
Cc: Loic Minier <email address hidden>, Daniel Holbach <email address hidden>
Subject: Re: Bug#314385: Agreement?

On Mon, Nov 21, 2005 at 03:33:49AM -0800, Steve Langasek wrote:
> On Mon, Nov 21, 2005 at 11:45:05AM +0100, Loic Minier wrote:
> > Anyway, your preferred option seems saner, and quite doable given the
> > limited amount of API / ABI changes as listed by mdz.
>
> Other symbols removed since 2.1.7, btw:
>
> [lots]

I'm afraid I probably won't find time to do an exhaustive search, but I
think it would be worthwhile to directly test each package depending on
libfreetype6 and find the set of now-missing symbols which are important in
Debian. Even if it isn't practical for us to restore 100% compatibility
with 2.1.7, we may be able to achieve something which is close enough, with
a relatively small deltia to 2.1.10.

> Even worse, though, is the number of symbols *added* -- 75 new symbols, vs.
> 32 removed. Since the maintainer did not bump the shlibs when uploading,
> either, there's no way to determine which packages are using the new ABI
> except by looking at upload dates.

Anything which has started using new symbols from 2.1.10 is extremely likely
to still be API-compatible with previous versions, and can simply be
recompiled, no?

--
 - mdz

[Steve Langasek (vorlon)]

On Mon, Nov 21, 2005 at 07:51:56AM -0800, Matt Zimmerman wrote:
> On Mon, Nov 21, 2005 at 03:33:49AM -0800, Steve Langasek wrote:
> > On Mon, Nov 21, 2005 at 11:45:05AM +0100, Loic Minier wrote:
> > > Anyway, your preferred option seems saner, and quite doable given the
> > > limited amount of API / ABI changes as listed by mdz.

> > Other symbols removed since 2.1.7, btw:

> > [lots]

> I'm afraid I probably won't find time to do an exhaustive search, but I
> think it would be worthwhile to directly test each package depending on
> libfreetype6 and find the set of now-missing symbols which are important in
> Debian. Even if it isn't practical for us to restore 100% compatibility
> with 2.1.7, we may be able to achieve something which is close enough, with
> a relatively small deltia to 2.1.10.

For the record, I have a problem with "close enough" when it comes to ABIs
of libraries as exported in the library's own header files. When upstreams
break an ABI without changing the soname, it breaks local binaries, which is
bad; when Debian follows suit and leaves the ABI broken without changing the
package name, it breaks local packages, which (IMHO) is worse.

> > Even worse, though, is the number of symbols *added* -- 75 new symbols, vs.
> > 32 removed. Since the maintainer did not bump the shlibs when uploading,
> > either, there's no way to determine which packages are using the new ABI
> > except by looking at upload dates.

> Anything which has started using new symbols from 2.1.10 is extremely likely
> to still be API-compatible with previous versions, and can simply be
> recompiled, no?

Well, one known exception is libcairo, which has explicitly added a
dependency on the newer libfreetype6-dev. Any other packages, if they
exist, are lost in the muddle of new packages that have already been let
into testing.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 22 Nov 2005 16:20:37 -0800
From: Steve Langasek <email address hidden>
To: Matt Zimmerman <email address hidden>
Cc: <email address hidden>, Loic Minier <email address hidden>, Daniel Holbach <email address hidden>
Subject: Re: Bug#314385: Agreement?

--pf9I7BMVVzbSWLtt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 21, 2005 at 07:51:56AM -0800, Matt Zimmerman wrote:
> On Mon, Nov 21, 2005 at 03:33:49AM -0800, Steve Langasek wrote:
> > On Mon, Nov 21, 2005 at 11:45:05AM +0100, Loic Minier wrote:
> > > Anyway, your preferred option seems saner, and quite doable given the
> > > limited amount of API / ABI changes as listed by mdz.

> > Other symbols removed since 2.1.7, btw:

> > [lots]

> I'm afraid I probably won't find time to do an exhaustive search, but I
> think it would be worthwhile to directly test each package depending on
> libfreetype6 and find the set of now-missing symbols which are important =
in
> Debian. Even if it isn't practical for us to restore 100% compatibility
> with 2.1.7, we may be able to achieve something which is close enough, wi=
th
> a relatively small deltia to 2.1.10.

For the record, I have a problem with "close enough" when it comes to ABIs
of libraries as exported in the library's own header files. When upstreams
break an ABI without changing the soname, it breaks local binaries, which is
bad; when Debian follows suit and leaves the ABI broken without changing the
package name, it breaks local packages, which (IMHO) is worse.

> > Even worse, though, is the number of symbols *added* -- 75 new symbols,=
 vs.
> > 32 removed. Since the maintainer did not bump the shlibs when uploadin=
g,
> > either, there's no way to determine which packages are using the new ABI
> > except by looking at upload dates.

> Anything which has started using new symbols from 2.1.10 is extremely lik=
ely
> to still be API-compatible with previous versions, and can simply be
> recompiled, no?

Well, one known exception is libcairo, which has explicitly added a
dependency on the newer libfreetype6-dev. Any other packages, if they
exist, are lost in the muddle of new packages that have already been let
into testing.

--=20
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

--pf9I7BMVVzbSWLtt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDg7XVKN6ufymYLloRAowqAJ0dxZdFYjHyDpOr1UrTE91HAxetzACgz2V8
ErSc8yIXfI31mm7wg1uSKPc=
=QPah
-----END PGP SIGNATURE-----

--pf9I7BMVVzbSWLtt--

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.9.8
block 340878 with 314385

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sat, 26 Nov 2005 15:59:10 -0800
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: block 340878 with 314385

# Automatically generated email from bts, devscripts version 2.9.8
block 340878 with 314385

[Wolfgang Sourdeau (was)]

tag 314385 + fixed
tag 314823 + fixed
tag 320958 + fixed
tag 321646 + fixed
tag 329223 + fixed
tag 337143 + fixed
tag 340878 + fixed

quit

This message was generated automatically in response to a
non-maintainer upload. The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 29 Nov 2005 16:50:32 -0500
Source: gnustep-back
Binary: gnustep-back
Architecture: source i386
Version: 0.9.5-1.1
Distribution: unstable
Urgency: low
Maintainer: Debian GNUstep maintainers <email address hidden>
Changed-By: Wolfgang Sourdeau <email address hidden>
Description:
 gnustep-back - The GNUstep GUI Backend
Closes: 314385 314823 320958 321646 329223 337143 340878
Changes:
 gnustep-back (0.9.5-1.1) unstable; urgency=low
 .
   * NMU
   * Rebuilt against libfreetype6 (>= 2.1.10) (Closes: #314823, #314385,
     #320958, #321646, #329223, #337143, #340878)
Files:
 41315ca317bbfe847f2e94d15ba5113b 913 devel optional gnustep-back_0.9.5-1.1.dsc
 9ab3bc525d86ebd46a061b59945ffb46 7803 devel optional gnustep-back_0.9.5-1.1.diff.gz
 cc47731581ab16cac2a9020c8436b37f 266288 libs optional gnustep-back_0.9.5-1.1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjM6GUP8yyofKtg8RAqAhAKDf0zTFPmgtdYMg5EyhpDbpAqGB7wCbBk4x
ae3NtWhW8JtLzQHPde3t1/w=
=Mfyh
-----END PGP SIGNATURE-----

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 29 Nov 2005 14:02:27 -0800
From: Wolfgang Sourdeau <email address hidden>
To: <email address hidden>
Cc: Wolfgang Sourdeau <email address hidden>,
 Debian GNUstep maintainers <email address hidden>
Subject: Fixed in NMU of gnustep-back 0.9.5-1.1

tag 314385 + fixed
tag 314823 + fixed
tag 320958 + fixed
tag 321646 + fixed
tag 329223 + fixed
tag 337143 + fixed
tag 340878 + fixed

quit

This message was generated automatically in response to a
non-maintainer upload. The .changes file follows.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 29 Nov 2005 16:50:32 -0500
Source: gnustep-back
Binary: gnustep-back
Architecture: source i386
Version: 0.9.5-1.1
Distribution: unstable
Urgency: low
Maintainer: Debian GNUstep maintainers <email address hidden>
Changed-By: Wolfgang Sourdeau <email address hidden>
Description:
 gnustep-back - The GNUstep GUI Backend
Closes: 314385 314823 320958 321646 329223 337143 340878
Changes:
 gnustep-back (0.9.5-1.1) unstable; urgency=low
 .
   * NMU
   * Rebuilt against libfreetype6 (>= 2.1.10) (Closes: #314823, #314385,
     #320958, #321646, #329223, #337143, #340878)
Files:
 41315ca317bbfe847f2e94d15ba5113b 913 devel optional gnustep-back_0.9.5-1.1.dsc
 9ab3bc525d86ebd46a061b59945ffb46 7803 devel optional gnustep-back_0.9.5-1.1.diff.gz
 cc47731581ab16cac2a9020c8436b37f 266288 libs optional gnustep-back_0.9.5-1.1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDjM6GUP8yyofKtg8RAqAhAKDf0zTFPmgtdYMg5EyhpDbpAqGB7wCbBk4x
ae3NtWhW8JtLzQHPde3t1/w=
=Mfyh
-----END PGP SIGNATURE-----

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.9.9
tags 314385 - fixed
tags 340878 - fixed
unblock 340878 with 314385
block 314309 with 314385
merge 340878 314385

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 29 Nov 2005 19:00:22 -0800
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: tagging 314385, tagging 340878, unblock 340878 with 314385, block 314309 with 314385 ...

# Automatically generated email from bts, devscripts version 2.9.9
tags 314385 - fixed
tags 340878 - fixed
unblock 340878 with 314385
block 314309 with 314385
merge 340878 314385

[Steve Langasek (vorlon)]

# Automatically generated email from bts, devscripts version 2.9.9
unblock 314309 with 314385
block 341309 with 314385
merge 340878 314385

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 29 Nov 2005 19:40:10 -0800
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: unblock 314309 with 314385, block 341309 with 314385, merging 340878 314385

# Automatically generated email from bts, devscripts version 2.9.9
unblock 314309 with 314385
block 341309 with 314385
merge 340878 314385

[Debian Bug Importer (debzilla)]

*** Bug 26312 has been marked as a duplicate of this bug. ***

[Stephan Frank (sfrank)]

Hallo everybody,

concerning this problem:

I don't know if you guys read freetype-devel. While searching for hints
on another problem I stumbled across these references on that list:

http://turnerdavid.neuf.fr/freetype/freetype-2.2.0-safe-install.html
http://turnerdavid.neuf.fr/freetype/rogue-patches.html

maybe this helps to clarify the situation a bit more...

Sorry, if you already knew about these documents.

Kind regards,
Stephan

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 03 Jan 2006 13:32:00 +0100
From: Stephan Frank <email address hidden>
To: <email address hidden>
CC: <email address hidden>, <email address hidden>, <email address hidden>
Subject: Bug#314385: freetype's take

Hallo everybody,

concerning this problem:

I don't know if you guys read freetype-devel. While searching for hints
on another problem I stumbled across these references on that list:

http://turnerdavid.neuf.fr/freetype/freetype-2.2.0-safe-install.html
http://turnerdavid.neuf.fr/freetype/rogue-patches.html

maybe this helps to clarify the situation a bit more...

Sorry, if you already knew about these documents.

Kind regards,
Stephan

[Steve Langasek (vorlon)]

Hi Werner,

On Sun, Jan 22, 2006 at 09:12:46AM +0100, Werner LEMBERG wrote:

> I've read your very interesting mail at

> http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html

> What's your recommendation in the light of

> http://freetype.org/freetype2/freetype-2.2.0.html

Thanks for writing! I applaud the FreeType developers for making this
effort to clean up the exported interface of the library. I know that
proper handling of library ABIs has been an evolutionary process for most of
us in the Free Software community, and by switching to -export-symbols,
you guys appear to be ahead of the curve.

At the same time, I'm dismayed that this page talks about how badly people's
desktops are going to break, and *not* about a library soname change; and
there's no indication that the -version-info "age" argument has been reset
in freetype2 cvs; even though the -export-symbols change is being made
*explicitly because you know people have been using private interfaces*.
Appropriate or not, there is still software in the wild that's using these
interfaces; intended or not, this software was built against headers that
were installed by default by the *upstream* install target, and linked
against libraries with the exact ABI that you as upstream exported.

And GNU/Linux distributions are caught in the middle. We certainly didn't
choose for this software to use internal freetype interfaces, but we will
have to deal with the fact that an unspecified number of applications and
libraries -- some that we distribute, perhaps many more installed on users'
systems that we did not -- will break when they upgrade to the new freetype,
simply because you opted not to change a number to acknowledge this reality.
Please don't do this to us! It is not worth the pain to millions of users
just to continue calling the library "libfreetype.so.6"!

If for whatever reason you decide not to change the SONAME for 2.2, it will
still be my recommendation to the Debian freetype maintainer that he change
the *package* name; this is the only option that stands a chance at
providing a smooth upgrade path for our users with a change in such an
important library. Even then I'm not sure it's much of a chance.

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Ming Hua (minghua)]

Hello libxft maintainers and release managers,

I've been following the development of font related library packages in
Debian, as some of the new features in the recent upstream releases are
important for rendering CJK fonts. So I'm quite happy to see xft
2.1.8.2 entered unstable a few days ago.

However I also noticed that with the current library dependency
handling, the API/ABI changes in the new libxft2 library (the new
features I was looking at) could break testing soon. So I feel I should
raise the alarm here. As I have the tendency of being overly verbose,
let me show the problem first:

On unstable with libfreetype6 2.1.10-1 and libxft2 2.1.8.2-1:
    $ objdump -T /usr/lib/libXft.so.2.1.2 | grep "FT_GlyphSlot"
    00000000 DF *UND* 0000016b FT_GlyphSlot_Embolden
    $ objdump -T /usr/lib/libfreetype.so.6.3.8 | grep "FT_GlyphSlot"
    00013d50 g DF .text 0000016b Base FT_GlyphSlot_Embolden
    00013cf0 g DF .text 0000005d Base FT_GlyphSlot_Oblique

On sarge with libfreetype6 2.1.7-2.4 and libxft2 2.1.7-1 (testing has
the same versions):
    $ objdump -T /usr/lib/libXft.so.2.1.2 | grep "FT_GlyphSlot"
    $ objdump -T /usr/lib/libfreetype.so.6.3.5 | grep "FT_GlyphSlot"
(no such symbols in both libraries)

As everybody should already know, freetype's ABI has been changing
wildly from release to release. In this case the related are two new
public functions "FT_GlyphSlot_*" (not in private header, which means
endorsed by upstream) added after freetype 2.1.7. From what I heard,
xft 2.1.7 already had functions that use this API, but it's optional,
and as libxft2 2.1.7-1 was compiled against libfreetype6 2.1.7 (or
earlier), it didn't end up using it. Now unstable has the new
libfreetype6 2.1.10 with such API, when the new xft 2.1.8.2 is built, it
picked up the new API and start using it (it would also happen if we
rebuild the same 2.1.7, as I understand).

So far, no big deal. However besides all the problem libfreetype6 has
(exporting symbols that was intended for private use only, then dropping
and renaming these functions), it also doesn't handle the shlibs
correctly. The currenly libfreetype6 package still has only >= 2.1.5-1,
but it's ABI has changed a lot since 2.1.5-1 (I mentioned this in
#316031). Now libfreetype6 2.1.10-1 is held out of testing for good
reason, libxft2 can slip into testing because of this broken shlibs, but
it uses symbols only available in libfreetype6 2.1.10-1.

I don't know if any other packages are using this feature in libxft2,
but I suppose there is, as the Chinese users are constantly discussing
about the changes this new feature brings. I am even not sure it's as
serious as I think it is, but I believe you are more knowledgable than I
am to decide this, I just want to bring it to your attention. I also
remember similar thing happend for cairo before.

I'm cc:ing #314385 as that seems to be the "libfreetype6 is broken"
blanket bug now. There probably should be a bug filed against libxft2,
but as I said I am not quite sure what sure be done here, I'm not doing
it yet.

(An unrelated issue: it seems strange to me that both 2.1.7 and 2.1.8.2
version of xft ...

[Otaylor-redhat (otaylor-redhat)]

On Sun, 2006-01-22 at 03:57 -0800, Steve Langasek wrote:
> Hi Werner,
>
> On Sun, Jan 22, 2006 at 09:12:46AM +0100, Werner LEMBERG wrote:
>
> > I've read your very interesting mail at
>
> > http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html
>
> > What's your recommendation in the light of
>
> > http://freetype.org/freetype2/freetype-2.2.0.html
>
> Thanks for writing! I applaud the FreeType developers for making this
> effort to clean up the exported interface of the library. I know that
> proper handling of library ABIs has been an evolutionary process for most of
> us in the Free Software community, and by switching to -export-symbols,
> you guys appear to be ahead of the curve.
>
> At the same time, I'm dismayed that this page talks about how badly people's
> desktops are going to break, and *not* about a library soname change; and
> there's no indication that the -version-info "age" argument has been reset
> in freetype2 cvs; even though the -export-symbols change is being made
> *explicitly because you know people have been using private interfaces*.

The issue that a soname changed as been mentioned elsewhere in this
thread. If the FreeType soname is changed and you provide both
libfreetype6 and libfreetype7 for Debian (as is the normal practice),
then most of the 583 packages you've identified will be linking
against *both* libfreetype6 and libfreetype7 until they are rebuilt,
because one of their dependent libraries (fontconfig, libgd, pango,
whatever), links against the new freetype.

The only thing that is predictable about what that will cause is that
it is bad.

If you made libfreetype7 conflict with libfreetype6, then the you
wouldn't have that problem, and you'd just have a massive rebuild
job.

For this reason, it is less of an issue for distributions that
don't provide compat packages ... a soname change just causes a big
rebuild that is pointless for 98% of all packages and catches the
2% that have problems. (That 2% is pretty well known, however.)

But beyond the world of nicely managed systems and distributions,
there are a whole lot of systems with random libfreetypes floating
around in one directory or another, which will also be subject
to the two-versions problem.

It's not a pretty situation either way ... but a soname change isn't
a magic fix here.

Regards,
      Owen

[Steve Langasek (vorlon)]

On Fri, Jan 27, 2006 at 02:20:54PM -0500, Owen Taylor wrote:
> On Sun, 2006-01-22 at 03:57 -0800, Steve Langasek wrote:
> > Hi Werner,

> > On Sun, Jan 22, 2006 at 09:12:46AM +0100, Werner LEMBERG wrote:

> > > I've read your very interesting mail at

> > > http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html

> > > What's your recommendation in the light of

> > > http://freetype.org/freetype2/freetype-2.2.0.html

> > Thanks for writing! I applaud the FreeType developers for making this
> > effort to clean up the exported interface of the library. I know that
> > proper handling of library ABIs has been an evolutionary process for most of
> > us in the Free Software community, and by switching to -export-symbols,
> > you guys appear to be ahead of the curve.

> > At the same time, I'm dismayed that this page talks about how badly people's
> > desktops are going to break, and *not* about a library soname change; and
> > there's no indication that the -version-info "age" argument has been reset
> > in freetype2 cvs; even though the -export-symbols change is being made
> > *explicitly because you know people have been using private interfaces*.

> The issue that a soname changed as been mentioned elsewhere in this
> thread. If the FreeType soname is changed and you provide both
> libfreetype6 and libfreetype7 for Debian (as is the normal practice),
> then most of the 583 packages you've identified will be linking
> against *both* libfreetype6 and libfreetype7 until they are rebuilt,
> because one of their dependent libraries (fontconfig, libgd, pango,
> whatever), links against the new freetype.

Yes, that is an issue. We're working on getting as many of these
double-linkages fixed in Debian as possible, since it's not a sane
assumption that libraries will never undergo ABI changes; but that doesn't
directly benefit the rest of the world so long as Debian's libtool fixes
aren't integrated upstream.

One change that *would* mitigate the problems for other distributors (and
Debian) is, since freetype 2.2 will already include a linker script, to add
symbol versions to that linker script. This would give, um... a 50-50
chance of avoiding segfaults (or other corruption) with both libfreetype6
and libfreetype7 loaded in memory, assuming that the package upgraded to the
libfreetype7 version is chosen randomly. I don't know if you consider those
odds good enough to forgo a conflict between libfreetype6 and libfreetype7
in Red Hat; they seem good enough for me given that we would not want to
ship libfreetype6 at all in etch and therefore the problems would be wholly
limited to partial upgrades from sarge.

> If you made libfreetype7 conflict with libfreetype6, then the you
> wouldn't have that problem, and you'd just have a massive rebuild
> job.

We'll have a massive rebuild job for etch either way, since we're already
caught on ABI changes with 2.1.10 in Debian unstable; it's just deferred
pending the release of freetype 2.2 upstream and a "final" ABI to rebuild
against. If freetype 2.2 is released with the same libfreetype.so.6 soname,
we will still have to provide a transition for packages by renaming the
package itself to...

[Werner Lemberg (wl)]

> One change that *would* mitigate the problems for other distributors
> (and Debian) is, since freetype 2.2 will already include a linker
> script, to add symbol versions to that linker script. [...]

According to this excellent document (everybody involved into this
discussion should read it!)

  http://people.redhat.com/drepper/dsohowto.pdf

which describes all aspects of writing DLLs, symbol versioning isn't
portable. Consequently, this must be hidden with macros. If someone
comes up with an elegant macro solution which doesn't uglify the
source code and which are easy to use I don't object to add this to
the CVS. In case we introduce that we should do it right, this is,
support symbol versioning in the source code too. Takers? Comments?

    Werner

[Steve Langasek (vorlon)]

On Sun, Feb 19, 2006 at 07:06:05PM -0500, David Nusinow wrote:
> Hi all,
> The broken shlibs in freetype is causing huge issues for testing right
> now because xft migrated in without the correct freetype. There are two
> options that I'm aware of: to have freetype migrate in or to upload the old
> version of xft with an epoch bump, let it migrate in to testing, and then
> upload the new version with a shlibs.local. I'd prefer the former option,
> but I'm also not willing to maintain freetype :-) I have an NMU prepared
> for freetype that bumps its shlibs and also fixes its build-dep on
> xlibs-dev. I'd be happy to upload this if the release team deems it the
> right move.

This really ought to have been dealt with by blocking xft in unstable until
freetype was sorted. I'm not sure why there was no RC bug on xft about
this... too late now, though.

So the situation now is that upstream has decided to restore the libfreetype
ABI to compatibility with version 2.1.7, even though this means keeping
their internal functions exposed. In theory this means there will not be an
ABI change for etch. But upstream hasn't yet released this ABI-compatible
version, so it doesn't much help us at the moment.

In the meantime, I'm going ahead and pushing freetype 2.1.10 into testing.
The trade-off is that this will break the old version of gnustep, and the
new gnustep isn't ready to go in. But it fixes all the other packages that
depend on libxft2 et al., so this is still the better option. The gnustep
maintainers will just need to get their act together and finish their own
ABI transition.

Incidentally, the latest gnustep-back *still* uses internal interfaces from
freetype, so it's going to break again when freetype reinstates
compatibility with 2.1.7. That's a gnustep-back bug; it needs to be fixed
to not use these internal interfaces, which will *not* be supported by
freetype upstream in the long term.

> I know no one wants to deal with freetype, but we should resolve this
> issue somehow...

Er, not at all; it's just not something that can be dealt with very easily
before upstream makes their move.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Loïc Minier (lool)]

reassign #354233 uim-gtk2.0
block #354233 by #314385
stop

        Hi,

On Fri, Feb 24, 2006, Jonas Koelker wrote:
> Setting up libgtk2.0-bin (2.8.12-1) ...
> Updating the IM modules list for GTK+-2.4.0...Cannot load module /usr/lib/gtk-2.0/2.4.0/immodules/im-uim.so: /usr/lib/libXft.so.2: undefined symbol: FT_GlyphSlot_Embolden
> /usr/lib/gtk-2.0/2.4.0/immodules/im-uim.so does not export GTK+ IM module API: /usr/lib/libXft.so.2: undefined symbol: FT_GlyphSlot_Embolden

 This is a bug with libfreetype which borke its backward compatibility
 and hence im-uim.so. I'm reassigning to the IM package for other
 people to see the issue, but the bug is in freetype.

   Cheers,

--
Loïc Minier <email address hidden>
Current Earth status: NOT DESTROYED

[Filipus Klutiero (ido)]

tags 314385 upstream
block 316752 by 314385
block 341309 by 316031
block 354233 by 316031
merge 316031 314385

[Steve Langasek (vorlon)]

Version: 2.2~rc4-1

These two bugs have been fixed now with the upload of 2.2.1-1 to unstable,
but I passed the wrong option when building so they didn't get closed
automatically. The full changelog for this upload is:

freetype (2.2.1-1) unstable; urgency=low

  * New upstream release
    - Supersedes patches freetype-2.1.10-cvsfixes.patch,
      freetype-2.1.10-fixaliasing.patch, freetype-2.1.10-fixautofit.patch,
      freetype-2.1.10-fixkerning.patch, freetype-2.1.10-memleak.patch,
      freetype-2.1.10-xorgfix.patch

 -- Steve Langasek <email address hidden> Sat, 13 May 2006 13:57:54 -0700

freetype (2.2~rc4-1) unstable; urgency=low

  * New upstream release
    - this version should restore binary compatibility with version
      2.1.7. Closes: #314385.
    - use the old ft2demos and freetype-docs for now; patch ft2demos
      (temporarily only!) to still use the internal headers, which are
      now no longer exported as part of the API
  * Patch to handle empty short metrics, as seen in BitStream Vera.
  * Bump shlibs to 2.2~rc4-1. Closes: #316031.
  * Replace debian/rules patch handling with quilt; thanks to Jurij
    Smakov <email address hidden> for the patch.

 -- Steve Langasek <email address hidden> Sat, 4 Mar 2006 22:06:38 -0800

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
<email address hidden> http://www.debian.org/

[Barry deFreese (bddebian)]

This is resolved in Debian, was it also fixed in Dapper? Thank you.

[Michael Vogt (mvo)]

This is fixed in edgy by using freetype 2.2.1 that restores binary compatiblity (this is still a issue in dapper, also gworkspace.app loads fine in dapper).