libflac4: wrong soname on binary package (should be libflac6)

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

Message-ID: <email address hidden>
Date: Wed, 5 Jan 2005 23:52:58 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: libflac4: wrong soname on binary package (should be libflac6)

Package: libflac4
Version: 1.1.1-1
Severity: grave
Tags: sid
Justification: renders package unusable

libFLAC 1.1.1 has soname 6. libflac4 should contain old libFLAC 1.0,
and be on section old-libs. libFLAC 1.1.1 should be in a libflac6 package.

I can atest that the soname change is necessary, I've been waiting for this
upload for a long time (to get proper seekable ogg-flac support routines for
TiMidity++...)

As it stands, this package breaks all packages that depend on libflac4.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.28-rc1-debian5+skas+lmsensors+3c59xvlan+lmlbt4x
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1)

Versions of packages libflac4 depends on:
ii debconf 1.4.41 Debian configuration management sy
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an

-- no debconf information

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

James, please ensure that we get either 1.1.0-11 or 1.1.1-2 in Hoary at the time
of the upstream version freeze; 1.1.1-1 is horribly broken.

Message-ID: <email address hidden>
Date: Wed, 5 Jan 2005 18:35:45 -0800
From: Matt Zimmerman <email address hidden>
To: Henrique de Moraes Holschuh <email address hidden>,
 <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#288876: libflac4: wrong soname on binary package (should be libflac6)

On Wed, Jan 05, 2005 at 11:52:58PM -0200, Henrique de Moraes Holschuh wrote:

> Package: libflac4
> Version: 1.1.1-1
> Severity: grave
> Tags: sid
> Justification: renders package unusable
>
> libFLAC 1.1.1 has soname 6. libflac4 should contain old libFLAC 1.0,
> and be on section old-libs. libFLAC 1.1.1 should be in a libflac6 package.
>
> I can atest that the soname change is necessary, I've been waiting for this
> upload for a long time (to get proper seekable ogg-flac support routines for
> TiMidity++...)
>
> As it stands, this package breaks all packages that depend on libflac4.

Yes, an unfortunate error of uploading the wrong .changes. Fixed packages
arrived in queue/new shortly afterward.

It would be greatly appreciated if an ftpmaster could accelerate its
acceptance in order to undo my mess.

--
 - mdz

Message-ID: <email address hidden>
Date: Thu, 6 Jan 2005 13:27:44 -0800
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Subject: Re: Bug#289028: libflac4 makes amarok choke

severity 289028 grave
merge 289028 288876
thanks

--
 - mdz

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

Message-ID: <email address hidden>
Date: Thu, 6 Jan 2005 19:02:02 -0800
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Subject: Re: Bug#289077: apt-get -u dist-upgrade error with libflac4

severity 289077 grave
merge 289077 289028
thanks

--
 - mdz

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

Message-Id: <email address hidden>
Date: Fri, 07 Jan 2005 11:09:00 +0100
From: Sebastien Bacher <email address hidden>
To: Vincent Neyen <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#289112: easytag: Required library libFLAC.so.4 doesn't
 exist

reassign 289112 libflac4
merge 288876 289112
thanks

Le vendredi 07 janvier 2005 =E0 09:52 +0100, Vincent Neyen a =E9crit :
> Package: easytag
> Version: 1.0-1
> Severity: grave
> Justification: renders package unusable
>=20
> Easytag needs library libFLAC.so.4 while libflac4 package only provides
> libFLAC.so.6 .

Hi,

As indicated by the name, libflac*4*, this package is supposed to
contains a .so.4 (the policy naming is libnamesoname). If the soname has
changed to 6, the binary package containing it should be renamed to
libflac6, this is a libflac. BTW there is already some duplicates of
this bug:
#288876: libflac4: wrong soname on binary package (should be libflac6)
#289028: libflac4 makes amarok choke
#289077: apt-get -u dist-upgrade error with libflac4

I've reassign to flac and merging the bugs.

> Workaround: ln -s /usr/lib/libFLAC.so.6 /usr/lib/libFLAC.so.4

The soname has probably changed for a reason, don't forget to remove the
link when the package will be fixed to not create other bugs on your
system due to this.

Cheers,

Sebastien Bacher=20

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

Message-ID: <email address hidden>
Date: Fri, 7 Jan 2005 04:19:20 -0800
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Subject: unmerge

# Actually a different bug
unmerge 289077
thanks

--
 - mdz

Fixed in 1.1.1-2:
      flac | 1.1.1-2 | http://archive.ubuntu.com hoary/main Packages

Message-Id: <email address hidden>
Date: Fri, 07 Jan 2005 17:28:20 +0100
From: Sebastien Bacher <email address hidden>
To: WaVeR <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#289137: easytag: fails to start

reassign 289137 libflac4
severity 289137 grave
merge 288876 289137
thanks

Le vendredi 07 janvier 2005 =E0 13:10 +0100, WaVeR a =E9crit :
> Package: easytag
> Version: 1.0-1
> Severity: normal
>=20
>=20
> fails to start easytag:
> easytag: error while loading shared libraries: libFLAC.so.4: cannot ope=
n shared object file: No such file or directory

Hi,

That's a flac issue. there is already some duplicates of this bug:
#288876: libflac4: wrong soname on binary package (should be libflac6)
#289028: libflac4 makes amarok choke
#289077: apt-get -u dist-upgrade error with libflac4
#289112: easytag: Required library libFLAC.so.4 doesn't exist

I've reassign to flac and merging the bugs.

Cheers,

Sebastien Bacher

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

Message-Id: <email address hidden>
Date: Sat, 08 Jan 2005 02:31:59 +0100
From: =?ISO-8859-1?Q?J=E9r=F4me?= Warnier <email address hidden>
To: Debian BTS Control Interface <email address hidden>
Subject: Reassign to libflac4

reassign 288845 libflac4
severity 288845 grave
merge 288845 288876
quit

Message-ID: <email address hidden>
Date: Sun, 9 Jan 2005 02:03:28 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: Matt Zimmerman <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#288876: libflac4: wrong soname on binary package (should be libflac6)

Hi Matt!

On Wed, 05 Jan 2005, Matt Zimmerman wrote:

> On Wed, Jan 05, 2005 at 11:52:58PM -0200, Henrique de Moraes Holschuh wrote:
>
> > Package: libflac4
> > Version: 1.1.1-1
> > Severity: grave
> > Tags: sid
> > Justification: renders package unusable
> >
> > libFLAC 1.1.1 has soname 6. libflac4 should contain old libFLAC 1.0,
> > and be on section old-libs. libFLAC 1.1.1 should be in a libflac6 package.
> >
> > I can atest that the soname change is necessary, I've been waiting for this
> > upload for a long time (to get proper seekable ogg-flac support routines for
> > TiMidity++...)
> >
> > As it stands, this package breaks all packages that depend on libflac4.
>
> Yes, an unfortunate error of uploading the wrong .changes. Fixed packages
> arrived in queue/new shortly afterward.
>
> It would be greatly appreciated if an ftpmaster could accelerate its
> acceptance in order to undo my mess.

Hmm... now we need a old-flac source package to generate the old libflac4,
*AND* there is a major problem with liboggflac1.

liboggflac1 did not change the soname (better check this, it might require a
soname change, check the seekable ogg-flac support stuff). If it does, a
new upload fixes it, and liboggflac1 should be generated by the old-flac
package. If it doesn't, then what should we do? libflac4 would be mostly
useless in that case.

I will switch timidity to libflac6 in unstable, so that doesn't bother me
much, but flac is used by a lot of other stuff...

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message-ID: <email address hidden>
Date: Sat, 8 Jan 2005 20:31:47 -0800
From: Matt Zimmerman <email address hidden>
To: Henrique de Moraes Holschuh <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: liboggflac1 soname

On Sun, Jan 09, 2005 at 02:03:28AM -0200, Henrique de Moraes Holschuh wrote:

> *AND* there is a major problem with liboggflac1.
>
> liboggflac1 did not change the soname (better check this, it might require a
> soname change, check the seekable ogg-flac support stuff).

CCing upstream on this. Josh, did 1.1.1 change interfaces in liboggflac?
If so, it needs a soname change.

> If it does, a new upload fixes it, and liboggflac1 should be generated by
> the old-flac package. If it doesn't, then what should we do? libflac4
> would be mostly useless in that case.
>
> I will switch timidity to libflac6 in unstable, so that doesn't bother me
> much, but flac is used by a lot of other stuff...

I think it's best to just transition everything to current flac; it seems at
least mostly backward-API-compatible (I haven't had to change anything so
far, only recompile), and there aren't that many packages which use it.

--
 - mdz

Message-ID: <email address hidden>
Date: Sat, 8 Jan 2005 22:41:10 -0800
From: Ralph Giles <email address hidden>
To: Henrique de Moraes Holschuh <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Sat, Jan 08, 2005 at 08:31:47PM -0800, Matt Zimmerman wrote:

> > liboggflac1 did not change the soname (better check this, it might require a
> > soname change, check the seekable ogg-flac support stuff).
>
> CCing upstream on this. Josh, did 1.1.1 change interfaces in liboggflac?
> If so, it needs a soname change.

Most of the changes were compatible, but it looks like some of the
OggFLAC__StreamDecoderState enum entries changed position, so the
soname should increment.

Also, note that the file format changed to fix the streaming issues.
liboggflac* prior to 1.1.1 is deprecated and debian should not support
it.

 -r

Message-ID: <email address hidden>
Date: Sun, 9 Jan 2005 10:44:16 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: Ralph Giles <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Sat, 08 Jan 2005, Ralph Giles wrote:
> On Sat, Jan 08, 2005 at 08:31:47PM -0800, Matt Zimmerman wrote:
> > > liboggflac1 did not change the soname (better check this, it might require a
> > > soname change, check the seekable ogg-flac support stuff).
> >
> > CCing upstream on this. Josh, did 1.1.1 change interfaces in liboggflac?
> > If so, it needs a soname change.
>
> Most of the changes were compatible, but it looks like some of the
> OggFLAC__StreamDecoderState enum entries changed position, so the
> soname should increment.
>
> Also, note that the file format changed to fix the streaming issues.
> liboggflac* prior to 1.1.1 is deprecated and debian should not support
> it.

Sure. But since there is soname breakage, we need a completely correct
package ASAP, since almost everything compiled against the current ones
[that link to liboggflac*] will have to be recompiled.

I am holding TiMidity in the current [broken] state until we get the new
upstream with the soname fixes. I hope it is released very soon :(

BTW, since the mess is already big enough, please do a sanity check on the
c++ bindings too. Maybe they ought to change the soname to keep in sync
with the c libs they depend on ?

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message-ID: <email address hidden>
Date: Sun, 9 Jan 2005 10:56:09 -0800
From: Ralph Giles <email address hidden>
To: Henrique de Moraes Holschuh <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Sun, Jan 09, 2005 at 10:44:16AM -0200, Henrique de Moraes Holschuh wrote:

> I am holding TiMidity in the current [broken] state until we get the new
> upstream with the soname fixes. I hope it is released very soon :(

Are we talking about the library's soname, or the debian package name?
I compared the 1.1.1 release with 1.0.4, which I think was the last
stable version. The version-info increments acceptably between the two
releases, from 0:1:0 to 2:1:1. Obviously revision hasn't always been
incremented properly, at the very least, and I don't know when we went
throught current=1.

Is the debian mismatch based on a release between these too? Should
flac-1.1.1 release have been 2:1:0? In either case, it seems rebuilding
all the packages against the 1.1.1 library should resolve the issue?

> BTW, since the mess is already big enough, please do a sanity check on the
> c++ bindings too. Maybe they ought to change the soname to keep in sync
> with the c libs they depend on ?

I don't know C++ well enough to evaluate ABI compatibility. The version-
info for libOggFLAC++ moved from 0:1:0 to 1:1:1 between 1.0.4 and 1.1.1.

Can someone else comment on this?

 -r

(not a flac developer, just trying to be helpful.)

Message-ID: <email address hidden>
Date: Sun, 9 Jan 2005 11:05:45 -0800
From: Matt Zimmerman <email address hidden>
To: Ralph Giles <email address hidden>
Cc: Henrique de Moraes Holschuh <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Sun, Jan 09, 2005 at 10:56:09AM -0800, Ralph Giles wrote:

> On Sun, Jan 09, 2005 at 10:44:16AM -0200, Henrique de Moraes Holschuh wrote:
>
> > I am holding TiMidity in the current [broken] state until we get the new
> > upstream with the soname fixes. I hope it is released very soon :(
>
> Are we talking about the library's soname, or the debian package name?

The Debian library package is named after the soname.

> Is the debian mismatch based on a release between these too? Should
> flac-1.1.1 release have been 2:1:0? In either case, it seems rebuilding
> all the packages against the 1.1.1 library should resolve the issue?

If the interfaces changed, the soname (and thus the package) need to be
renamed, and this needs to be done ASAP. If we can agree on the new soname,
I can make that change immediately and upload new packages.

--
 - mdz

Message-ID: <email address hidden>
Date: Sun, 9 Jan 2005 11:23:34 -0800
From: Ralph Giles <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Sun, Jan 09, 2005 at 11:05:45AM -0800, Matt Zimmerman wrote:

> > Is the debian mismatch based on a release between these too? Should
> > flac-1.1.1 release have been 2:1:0? In either case, it seems rebuilding
> > all the packages against the 1.1.1 library should resolve the issue?
>
> If the interfaces changed, the soname (and thus the package) need to be
> renamed, and this needs to be done ASAP. If we can agree on the new soname,
> I can make that change immediately and upload new packages.

I remain confused. You asked if the API had changed, I verified that it
had changed and also pointed out that the soname defined in the makefile
had been correspondingly incremented. Are you asking in addition for a
new upstream release?

 -r

Message-ID: <email address hidden>
Date: Mon, 10 Jan 2005 00:22:18 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: Ralph Giles <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Sun, 09 Jan 2005, Matt Zimmerman wrote:
> > Is the debian mismatch based on a release between these too? Should
> > flac-1.1.1 release have been 2:1:0? In either case, it seems rebuilding
> > all the packages against the 1.1.1 library should resolve the issue?

Well, if something built against 1.0.4 can (even in corner cases)
malfunction with 1.1.1, then yes, it must be 2:1:0. This holds true to
the soname of the C++ libs too if changes on the underlying C libraries are
somehow exported through the C++ ones.

If stuff built against the old lib won't work with the new lib:
  increment soname and zero age ("backward incompatible change")

ELSE If stuff built against the new lib won't work with the old lib:
  increment both soname and age ("forward compatible change")

ELSE:
  leave the soname alone

Simpler said than done, I know :(

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message-ID: <email address hidden>
Date: Sun, 9 Jan 2005 18:57:35 -0800
From: Ralph Giles <email address hidden>
To: Henrique de Moraes Holschuh <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Mon, Jan 10, 2005 at 12:22:18AM -0200, Henrique de Moraes Holschuh wrote:

> Well, if something built against 1.0.4 can (even in corner cases)
> malfunction with 1.1.1, then yes, it must be 2:1:0. This holds true to
> the soname of the C++ libs too if changes on the underlying C libraries are
> somehow exported through the C++ ones.

Ok. One more time.

liboggflac FROM THE 1.0.4 RELEASE has version-info 0:1:0

liboggflac FROM THE 1.1.1 RELEASE has version-info 2:1:1

That means current-age for the 1.1.1 liboggflac is 1. That means
IT WILL NOT BE DYNAMICALLY LINKED to an application built against
1.0.4. THERE IS NO CONFLICT between these two versions.

I don't see an upstream bug here, so if you're trying to report one
you're going to have to be more explicit or I'm not going to be able
to help you. I do appreciate the review of the always confusing
library versioning scheme, but unfortunately it hasn't revealed
any holes in my previous understanding.

If, in fact, the underlying C library is somehow exposed in
liboggflac++ then, as you suggest, we do have a problem there.
Again, I need an authoritative statement if you want something
done upstream.

 -r

Message-ID: <email address hidden>
Date: Mon, 10 Jan 2005 01:36:23 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: Ralph Giles <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Sun, 09 Jan 2005, Ralph Giles wrote:
> On Mon, Jan 10, 2005 at 12:22:18AM -0200, Henrique de Moraes Holschuh wrote:
> liboggflac FROM THE 1.0.4 RELEASE has version-info 0:1:0
> liboggflac FROM THE 1.1.1 RELEASE has version-info 2:1:1

Well, the packages we are having trouble here are:
  flac 1.1.0 (let me check... libOggFLAC version-info 1:2:0)
    debian package: liboggflac1 (matches libtool soname - ok)

  oggflac 1.1.0 not forward or backwards compatible with 1.0.4 -> ok.
  oggflac 1.1.1 not forward or backwards compatible with 1.1.0 -> problem.

So, it looks to me that liboggflac 1.1.1 should have version-info 2:1:0.
This is based on what you told us about the OggFLAC__StreamDecoderState enum
entries changing position.

> If, in fact, the underlying C library is somehow exposed in
> liboggflac++ then, as you suggest, we do have a problem there.

I didn't check for that one. If you believe there is not, then I have no
reason to think there is a leak. It was just a heads'up since we were
talking about such issues anyway...

> Again, I need an authoritative statement if you want something
> done upstream.

There it is: in light of the possible enum problem with liboggflac from
1.1.0 to 1.1.1 you told us about, the version-info of liboggflac 1.1.1
should be changed upstream to 2:1:0, please.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message-ID: <email address hidden>
Date: Sun, 9 Jan 2005 22:56:35 -0800
From: Ralph Giles <email address hidden>
To: Henrique de Moraes Holschuh <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Mon, Jan 10, 2005 at 01:36:23AM -0200, Henrique de Moraes Holschuh wrote:

> Well, the packages we are having trouble here are:
> flac 1.1.0 (let me check... libOggFLAC version-info 1:2:0)
> debian package: liboggflac1 (matches libtool soname - ok)
>
> oggflac 1.1.0 not forward or backwards compatible with 1.0.4 -> ok.
> oggflac 1.1.1 not forward or backwards compatible with 1.1.0 -> problem.
>
> So, it looks to me that liboggflac 1.1.1 should have version-info 2:1:0.
> This is based on what you told us about the OggFLAC__StreamDecoderState enum
> entries changing position.

Thank you. What I said about the enum was between 1.0.4 and 1.1.1. But
you are correct. 1.1.0 has version-info 1:2:0 and also does not include
the new streaming api or the enum reordering. So the update to 2:1:1 in
the 1.1.1 release was incorrect. I should have been 2:0:0. (2:1:0 works
too.)

> > If, in fact, the underlying C library is somehow exposed in
> > liboggflac++ then, as you suggest, we do have a problem there.
>
> I didn't check for that one. If you believe there is not, then I have no
> reason to think there is a leak. It was just a heads'up since we were
> talking about such issues anyway...

As I said, I'm not qualified to evaluate this.

Josh, got a comment on this? Want me to do a 1.1.2 to resolve this?

 -r

Message-ID: <email address hidden>
Date: Tue, 11 Jan 2005 01:27:14 +0100
From: Adrian Bunk <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: This bug is in libflac4

reassign 289746 libflac4
merge 289746 288845
thanks

This is a known problem in libflac4.

As a workaround, either downgrade libflac4 to the version in testing or
upgrade easytag to the current unstable version.

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Message-ID: <email address hidden>
Date: Mon, 10 Jan 2005 16:45:58 -0800
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Subject: Re: Processed: This bug is in libflac4

I've done all that I can do about this bug; all that remains is for packages
depending on libflac4 to be recompiled.

--
 - mdz

Message-Id: <email address hidden>
Date: Tue, 11 Jan 2005 02:25:00 +0100
From: Sebastien Bacher <email address hidden>
To: Marco Guidetti <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#289746: easytag fails to start due to an unmet dep on
 libFLAC.so.4

reassign 289746 libflac4
severity 289746 grave
merge 288876 289746
thanks

Le lundi 10 janvier 2005 =E0 20:34 +0100, Marco Guidetti a =E9crit :
> Package: easytag
> Version: 1.0-1

this is fixed with easytag 1.0-2 which has been rebuilt with libflac6

> since the update of this morning easytag fails to start.
> when try to start it from the terminal i get:
>=20
> $easytag
> easytag: error while loading shared libraries: libFLAC.so.4: cannot ope=
n
> shared object file: No such file or directory
>=20
> hope this is useful.

Hi,

That's a flac issue. there is already some duplicates of this bug:
#288876: libflac4: wrong soname on binary package (should be libflac6)
#289028: libflac4 makes amarok choke
#289077: apt-get -u dist-upgrade error with libflac4
#289112: easytag: Required library libFLAC.so.4 doesn't exist
#289137: easytag: fails to start

I've reassign to flac and merging the bugs.

Cheers,

Sebastien Bacher

Message-ID: <email address hidden>
Date: Tue, 11 Jan 2005 00:01:55 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: <email address hidden>
Subject: Re: Bug#288876 acknowledged by developer (Re: Processed: This bug is in libflac4)

On Mon, 10 Jan 2005, Debian Bug Tracking System wrote:
> I've done all that I can do about this bug; all that remains is for packages
> depending on libflac4 to be recompiled.

And what about liboggflac? It has the wrong soname currently, and upstream
will likely fix it soon. That will require another round of recompiling...

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message-ID: <email address hidden>
Date: Mon, 10 Jan 2005 20:24:49 -0800
From: Matt Zimmerman <email address hidden>
To: Henrique de Moraes Holschuh <email address hidden>,
 <email address hidden>
Cc: <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: Bug#288876: acknowledged by developer (Re: Processed: This bug is in libflac4)

On Tue, Jan 11, 2005 at 12:01:55AM -0200, Henrique de Moraes Holschuh wrote:

> On Mon, 10 Jan 2005, Debian Bug Tracking System wrote:
> > I've done all that I can do about this bug; all that remains is for packages
> > depending on libflac4 to be recompiled.
>
> And what about liboggflac? It has the wrong soname currently, and upstream
> will likely fix it soon. That will require another round of recompiling...

We should open a separate bug about that. There seem to be only 4 packages
which use liboggflac, so it should be a smaller problem.

I'm CCing the maintainers so that they're aware of the situation
(maintainers: the ABI of liboggflac1 was changed upstream without a soname
change, and so liboggflac2 will be coming soon).

--
 - mdz

Message-ID: <email address hidden>
Date: Mon, 10 Jan 2005 21:37:18 -0800 (PST)
From: Josh Coalson <email address hidden>
To: Matt Zimmerman <email address hidden>,
  Henrique de Moraes Holschuh <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

OK, I'm coming to this a little late (been sick) but I'll try
to answer all in one mail:

On Sat, Jan 08, 2005 at 08:31:47PM -0800, Matt Zimmerman wrote:
> > liboggflac1 did not change the soname (better check this, it
> might require a
> > soname change, check the seekable ogg-flac support stuff).
>
> CCing upstream on this. Josh, did 1.1.1 change interfaces in
liboggflac?
> If so, it needs a soname change.

as far as I can piece together, the last releases went like:

FLAC release libOggFLAC went to
------------- ------------------------------------------
1.1.0 1:2:0 from 1:1:0 (code changes only I think)
1.1.1-beta1 2:0:1 from 1:2:0 (some i'faces added, some changed)
1.1.1 2:1:1 from 2:0:1 (code changes only, no
                                 interface changes)

I think this is all according to the libtool rules in
http://www.gnu.org/software/libtool/manual.html#SEC35

the 'enum renumbering' to me implied an 'interface change'
but maybe I misinterpreted.

a more detailed list of what changed between 1.1.0 and 1.1.1
is here (scroll down to the libraries section):

http://flac.sourceforge.net/changelog.html#flac_1_1_1

unfortunately I don't have anything that concise for earlier
versions but I can dig it out of CVS if needed.

--- Ralph Giles <email address hidden> wrote:
> If, in fact, the underlying C library is somehow exposed in
> liboggflac++ then, as you suggest, we do have a problem there.
> Again, I need an authoritative statement if you want something
> done upstream.

hmm... not sure what "exposed" means in the libtool numbering
sense. the libOggFLAC++ includes do #include the libOggFLAC
headers, but I have been (maybe erroneously) adjusting the
libtool numbers strictly by what changed in the C++ side.

--- Ralph Giles <email address hidden> wrote:
> Thank you. What I said about the enum was between 1.0.4 and 1.1.1.
> But
> you are correct. 1.1.0 has version-info 1:2:0 and also does not
> include
> the new streaming api or the enum reordering. So the update to 2:1:1
> in
> the 1.1.1 release was incorrect. I should have been 2:0:0. (2:1:0
> works
> too.)

I don't see how it was wrong... but maybe FLAC 1.1.1-beta1 was
the missing link.

I don't know what the custom on numbering betas is, but
flac-1.1.1-beta1 was public and people tend to live on the edge
linking and shipping beta stuff, so I thought it was safest to
treat it as a real version as far as libtool numbering goes.

Josh

__________________________________
Do you Yahoo!?
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com

Message-ID: <email address hidden>
Date: Mon, 10 Jan 2005 22:22:51 -0800
From: Ralph Giles <email address hidden>
To: Josh Coalson <email address hidden>
Cc: Matt Zimmerman <email address hidden>, Henrique de Moraes Holschuh <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Mon, Jan 10, 2005 at 09:37:18PM -0800, Josh Coalson wrote:

> as far as I can piece together, the last releases went like:
>
> FLAC release libOggFLAC went to
> ------------- ------------------------------------------
> 1.1.0 1:2:0 from 1:1:0 (code changes only I think)
> 1.1.1-beta1 2:0:1 from 1:2:0 (some i'faces added, some changed)
> 1.1.1 2:1:1 from 2:0:1 (code changes only, no
> interface changes)
>
> I think this is all according to the libtool rules in
> http://www.gnu.org/software/libtool/manual.html#SEC35
>
> the 'enum renumbering' to me implied an 'interface change'
> but maybe I misinterpreted.

Yes, it's a change. The libtool manual seems a little incomplete
here. This issue is that the order of items in the enum has
changed in the header. Appending is generally safe, but because
enums are mapped to integers in the object code, an app built
against 1.1.0 would for example misinterpret what the 1.1.1
library uses for OggFLAC__STREAM_DECODER_OGG_ERROR as
OggFLAC__STREAM_DECODER_END_OF_STREAM.

As such it's an incompatible change, for which you should also
zero the 'age' field. So 1.1.1-beta1 should have been 2:0:0,
not 2:0:1.

> http://flac.sourceforge.net/changelog.html#flac_1_1_1

Thanks for the changelog link. That's very clear.

> hmm... not sure what "exposed" means in the libtool numbering
> sense. the libOggFLAC++ includes do #include the libOggFLAC
> headers, but I have been (maybe erroneously) adjusting the
> libtool numbers strictly by what changed in the C++ side.

Hmm. Sounds like the same issue applies unfortunately. The real
question is whether you can upgrade them independently or not.
If not they should probably share libtool versioning numbers.

> I don't know what the custom on numbering betas is, but
> flac-1.1.1-beta1 was public and people tend to live on the edge
> linking and shipping beta stuff, so I thought it was safest to
> treat it as a real version as far as libtool numbering goes.

Yes, I agree. The numbering is all about coexisting installs of the
various versions.

 -r

P.S. Hope you're feeling better!

Message-ID: <email address hidden>
Date: Sat, 15 Jan 2005 09:23:44 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: Ralph Giles <email address hidden>
Cc: Josh Coalson <email address hidden>, Matt Zimmerman <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Mon, 10 Jan 2005, Ralph Giles wrote:
> As such it's an incompatible change, for which you should also
> zero the 'age' field. So 1.1.1-beta1 should have been 2:0:0,
> not 2:0:1.
[...]
> Yes, I agree. The numbering is all about coexisting installs of the
> various versions.

Ok. I need to know what to do about this... is 1.1.2 with fixed sonames
just around the corner? What should we do to fix sonames in Debian?

I really don't want to upload a new timidity linked to liboggflac with
broken sonames, and I really, really don't want to see libraries which will
cause soname headaches make it to the next debian stable (speaking as an
user of said libraries).

Do we have a consensus that:

  1. the C++ libs should increase sonames in SYNC with the C ones because
     some of the ABI is leaked through them. This means that at least
     libOggFLAC++ has a wrong soname in 1.1.1, and that it would be a good
     idea to do an initial sync of all sonames with the non-C++ libs to fix
     this for good. After the initial sync, increasing the C lib sonames
     means the C++ sonames have to be increased as well (and zeroing the C
     lib AGE means the C++ ones need to be zeroed as well). The C++ libs
     can increase soname/zero AGE without increasing the C lib ones in the
     case of C++ specific changes, of course.

  2. the AGE of liboggflack should be zeroed in 1.1.1, and thus if 1.1.2
     shows futher ABI changes, it will increase the soname (and keep AGE 0).

That would mean sonames like this:

  1.1.1 (released with broken sonames):
     libFLAC 6:1:0
     libFLAC++ 4:1:0
     libOggFLAC 2:1:1
     LibOggFLAC++ 1:1:1

  1.1.1a (fixed sonames):
     libFLAC 6:1:0
     libFLAC++ 6:1:0
     libOggFLAC 2:1:0
     LibOggFLAC++ 2:1:0

  1.1.2 (assuming *NO* ABI changes from 1.1.1):
     libFLAC 6:1:0
     libFLAC++ 6:1:0
     libOggFLAC 2:1:0
     LibOggFLAC++ 2:1:0

  1.1.2 (assuming there ARE forward-compatible ABI changes in the C libs,
     and optional also forward-compatible ABI changes to the C++ libs):
     libFLAC 7:1:1
     libFLAC++ 7:1:1
     libOggFLAC 3:1:1
     LibOggFLAC++ 3:1:1

  1.1.2 (assuming there ARE backward-incompatible ABI changes in the C
     libs):
     libFLAC 7:1:0
     libFLAC++ 7:1:0
     libOggFLAC 3:1:0
     LibOggFLAC++ 3:1:0

Can we agree on the above soname plan, so that we can start fixing the
Debian packages (other distros might want to follow this fix, as well...) ?

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message-ID: <email address hidden>
Date: Thu, 20 Jan 2005 09:55:31 -0800 (PST)
From: Josh Coalson <email address hidden>
To: Ralph Giles <email address hidden>
Cc: Matt Zimmerman <email address hidden>, Henrique de Moraes Holschuh <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

--- Ralph Giles <email address hidden> wrote:
> On Mon, Jan 10, 2005 at 09:37:18PM -0800, Josh Coalson wrote:
>
> > as far as I can piece together, the last releases went like:
> >
> > FLAC release libOggFLAC went to
> > ------------- ------------------------------------------
> > 1.1.0 1:2:0 from 1:1:0 (code changes only I think)
> > 1.1.1-beta1 2:0:1 from 1:2:0 (some i'faces added, some changed)
> > 1.1.1 2:1:1 from 2:0:1 (code changes only, no
> > interface changes)
> >
> > I think this is all according to the libtool rules in
> > http://www.gnu.org/software/libtool/manual.html#SEC35
> >
> > the 'enum renumbering' to me implied an 'interface change'
> > but maybe I misinterpreted.
>
> Yes, it's a change. The libtool manual seems a little incomplete
> here. This issue is that the order of items in the enum has
> changed in the header. Appending is generally safe, but because
> enums are mapped to integers in the object code, an app built
> against 1.1.0 would for example misinterpret what the 1.1.1
> library uses for OggFLAC__STREAM_DECODER_OGG_ERROR as
> OggFLAC__STREAM_DECODER_END_OF_STREAM.
>
> As such it's an incompatible change, for which you should also
> zero the 'age' field. So 1.1.1-beta1 should have been 2:0:0,
> not 2:0:1.

I still don't see why it should have been 2:0:0... some interfaces
were added, and some were changed, and none removed, so according
to those doc's steps:

3. code changed => 1:2:0->1:3:0
4. i'faces added&changed => 1:3:0->2:0:0
5. i'faces added => 2:0:0->2:0:1
6. no i'faces removed

so I still don't see how the numbering could have broken something
or how I would fix it in the next release. unless:

> > http://flac.sourceforge.net/changelog.html#flac_1_1_1
>
> Thanks for the changelog link. That's very clear.
>
> > hmm... not sure what "exposed" means in the libtool numbering
> > sense. the libOggFLAC++ includes do #include the libOggFLAC
> > headers, but I have been (maybe erroneously) adjusting the
> > libtool numbers strictly by what changed in the C++ side.
>
> Hmm. Sounds like the same issue applies unfortunately. The real
> question is whether you can upgrade them independently or not.
> If not they should probably share libtool versioning numbers.

...maybe this is what caused the problem? i.e. some underlying
change in libFLAC.

also, just read Henrique's later email... this is probably
what happened. for the next release I will make sure that
the numbers are bumped up enough to be right again. but I
don't have a timeline for the next release... it is mostly
ready but I'm still trying to get time to integrate a bunch
of PPC optimizations.

I'm OK with Matt doing a 1.1.1a just to fix the sonames
though.

Josh

__________________________________________________
Do You Yahoo!?
Tired of spam? Yah...

Message-ID: <email address hidden>
Date: Mon, 24 Jan 2005 17:43:04 -0800 (PST)
From: Josh Coalson <email address hidden>
To: Henrique de Moraes Holschuh <email address hidden>, Ralph Giles <email address hidden>
Cc: Matt Zimmerman <email address hidden>, <email address hidden>, <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

--- Henrique de Moraes Holschuh <email address hidden> wrote:
> On Mon, 10 Jan 2005, Ralph Giles wrote:
> > As such it's an incompatible change, for which you should also
> > zero the 'age' field. So 1.1.1-beta1 should have been 2:0:0,
> > not 2:0:1.
> [...]
> > Yes, I agree. The numbering is all about coexisting installs of the
>
> > various versions.
>
> Ok. I need to know what to do about this... is 1.1.2 with fixed
> sonames
> just around the corner? What should we do to fix sonames in Debian?

OK, I am going to do a 1.1.2 earlier than I wanted in order to
fix this. anyway there are some bug fixes and speedups that will
be of benefit.

because of the mess and since there have been API changes and
additions in both libFLAC and libOggFLAC since 1.1.1 I plan on
bumping all the libtool numbers as follows: current++, revision=0
age=0. if this will cause problems please let me know.

I'll try to get this ready as soon as possible.

Josh

__________________________________
Do you Yahoo!?
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com

Message-ID: <email address hidden>
Date: Tue, 25 Jan 2005 00:00:12 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: Josh Coalson <email address hidden>
Cc: Ralph Giles <email address hidden>, Matt Zimmerman <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Mon, 24 Jan 2005, Josh Coalson wrote:
> OK, I am going to do a 1.1.2 earlier than I wanted in order to
> fix this. anyway there are some bug fixes and speedups that will
> be of benefit.
>
> because of the mess and since there have been API changes and
> additions in both libFLAC and libOggFLAC since 1.1.1 I plan on
> bumping all the libtool numbers as follows: current++, revision=0
> age=0. if this will cause problems please let me know.

That'll be perfect. Thank you!

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message-ID: <email address hidden>
Date: Mon, 24 Jan 2005 18:17:15 -0800
From: Ralph Giles <email address hidden>
To: Josh Coalson <email address hidden>
Cc: Henrique de Moraes Holschuh <email address hidden>, Matt Zimmerman <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: [Flac-dev] liboggflac1 soname

On Mon, Jan 24, 2005 at 05:43:04PM -0800, Josh Coalson wrote:

> because of the mess and since there have been API changes and
> additions in both libFLAC and libOggFLAC since 1.1.1 I plan on
> bumping all the libtool numbers as follows: current++, revision=0
> age=0. if this will cause problems please let me know.

That should resolve the issues. Thanks.

 -r