some minor patches

18 Messages Forum Options Options
Permalink
Fabian Greffrath-6
some minor patches
Reply Threaded More
Print post
Permalink
Dear LAME-developers,

during my attempts to package LAME 3.97 for debian-unofficial.org, I
(and the lintian package checking tool) have encountered several minor
issues that I'd like to discuss with you:

1) First of all, please refrain from providing a debian/ directory.
There are still no official LAME packages in Debian (and will perhaps
never be) and all of the unofficial archives that I know of develop
their own Debian packaging and delete the debian/ directory in the
upstream tarball anyway.

2) Programs that link against libmp3lame complain about missing
symbols from libm if linked with '--as-needed'. The attached patch
02_as-needed.patch solves this issue by explicitely adding '-lm' to
the LIBADD line.

3) The frontends (lame, mp3rtp and mp3x) are linked against the static
libmp3lame.a. The attached patch 03_shared-frontend.patch fixes this
issue by removing the '-static' flag from the frontends' LDFLAGS,
making them robust against rebuilds of the library package and keeping
the number of redundant copies of the same library in one system low,
since libmp3lame.so will be installed anyway on most systems.

4) The manpage doc/man/lame.1 provokes a syntax error from man because
of an additional '.f' in the bottom line. The attached patch
04_manpage-syntax removes this line (although I have to admit I don't
know what it was intended for at all).

5) The last attached patch 05_gcc-4.3 fixes compilation with GCC 4.3
which failed bacause of an invalid '-fforce-mem' statement. However,
this issue seems to be allready fixed in a different way in your CVS,
so please ignore this patch if inappropriate.

Thanks for your time!

Cheers,
Fabian
--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax:     +49 (0)234 / 32-14227
E-Mail:  greffrath@...


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Rogério Brito-2
Re: some minor patches
Reply Threaded More
Print post
Permalink
Hi Fabian.

On May 26 2008, Fabian Greffrath wrote:
> during my attempts to package LAME 3.97 for debian-unofficial.org, I
> (and the lintian package checking tool) have encountered several minor
> issues that I'd like to discuss with you:

I have mostly cleaned up the lintian warnings against the CVS version of
lame and I think that the package is compliant with the Debian Policy
version 3.7.3.

I was talking with Daniel Baumann one to see if he would accept my
packages, but I have received no response...

> 1) First of all, please refrain from providing a debian/ directory.
> There are still no official LAME packages in Debian (and will perhaps
> never be)

Indeed, no compiled versions of lame for any architecture.

> and all of the unofficial archives that I know of develop their own
> Debian packaging and delete the debian/ directory in the upstream
> tarball anyway.

Why develop their own debian/ directory? Why not submit the changes
upstream so that I can create a new module in CVS so that things get
separed?

> 2) Programs that link against libmp3lame complain about missing
> symbols from libm if linked with '--as-needed'. The attached patch
> 02_as-needed.patch solves this issue by explicitely adding '-lm' to
> the LIBADD line.

Please, could you send the patch inline? It seems that the mailing list
software that sourceforge uses ate your patch. :-( I would be interested
in your modifications.

> 3) The frontends (lame, mp3rtp and mp3x) are linked against the static
> libmp3lame.a. The attached patch 03_shared-frontend.patch fixes this
> issue by removing the '-static' flag from the frontends' LDFLAGS,
> making them robust against rebuilds of the library package and keeping
> the number of redundant copies of the same library in one system low,
> since libmp3lame.so will be installed anyway on most systems.

I'm also interested in this patch for the Debian builds, but I'm not
sure that they will be integrated into the 'generic' lame, as most
people use the lame binary on other operating systems (say, MacOS X)
without having to install the libraries (and the shared libraries seem
to be a completely different beast on MacOS X).

Anyway, I would be interested in this for lame. But the same comment
about the mailing list eating patches here. :-( (I don't know if other
members have received the integral patches).

> 4) The manpage doc/man/lame.1 provokes a syntax error from man because
> of an additional '.f' in the bottom line. The attached patch
> 04_manpage-syntax removes this line (although I have to admit I don't
> know what it was intended for at all).

The debian/package that I created still has that thing for the very same
reason that you didn't know what it was meant for. :-)

> 5) The last attached patch 05_gcc-4.3 fixes compilation with GCC 4.3
> which failed bacause of an invalid '-fforce-mem' statement. However,
> this issue seems to be allready fixed in a different way in your CVS,
> so please ignore this patch if inappropriate.

I have problems compiling lame with Apple's GCC 4.0.x (or whatever they
ship that may have backported patches) when I compile with expopts.


Regards, Rogério Brito.

--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Fabian Greffrath-6
Re: some minor patches
Reply Threaded More
Print post
Permalink
Hello Rogério,

Rogério Brito schrieb:
> I was talking with Daniel Baumann one to see if he would accept my
> packages, but I have received no response...

Daniel is no longer active in the debian-unofficial.org project at the
moment, so I have taken over his packages - among them LAME

> Why develop their own debian/ directory? Why not submit the changes
> upstream so that I can create a new module in CVS so that things get
> separed?

You can find my packaging efforts in the Debian restricted SVN:
http://svn.debian.org/wsvn/restricted/dists/trunk/lame/debian/

I do not like upstream tarballs allready providing debian/
directories, because I don't want to create a native Debian package. I
want source code in the orig.tar.gz separated from the packaging code
in the diff.gz.

> Please, could you send the patch inline? It seems that the mailing list
> software that sourceforge uses ate your patch. :-( I would be interested
> in your modifications.

Yes, it seems my attached patches were not properly submitted. :(

Well, hereÄs the patch (it can also be found in SVN, though). However,
I believe it would be a cleaner solution to substitute '-lm' with some
variable like $(LIBM) or @LIBM@.

--- lame-3.97/libmp3lame/Makefile.am
+++ lame-3.97.new/libmp3lame/Makefile.am
@@ -18,7 +18,7 @@
  decoder_ldadd =
  endif

-libmp3lame_la_LIBADD = $(nasm_ldadd) $(decoder_ldadd)
+libmp3lame_la_LIBADD = $(nasm_ldadd) $(decoder_ldadd) -lm
  libmp3lame_la_LDFLAGS = -version-info
@LIB_MAJOR_VERSION@:@LIB_MINOR_VERSION@ \
  -no-undefined


--- lame-3.97/libmp3lame/Makefile.in
+++ lame-3.97.new/libmp3lame/Makefile.in
@@ -228,7 +228,7 @@
  @HAVE_NASM_TRUE@nasm_ldadd =
$(top_builddir)/libmp3lame/@CPUTYPE@/liblameasmroutines.la
  @LIB_WITH_DECODER_FALSE@decoder_ldadd =
  @LIB_WITH_DECODER_TRUE@decoder_ldadd =
$(top_builddir)/mpglib/libmpgdecoder.la
-libmp3lame_la_LIBADD = $(nasm_ldadd) $(decoder_ldadd)
+libmp3lame_la_LIBADD = $(nasm_ldadd) $(decoder_ldadd) -lm
  libmp3lame_la_LDFLAGS = -version-info
@LIB_MAJOR_VERSION@:@LIB_MINOR_VERSION@ \
  -no-undefined


> Anyway, I would be interested in this for lame. But the same comment
> about the mailing list eating patches here. :-( (I don't know if other
> members have received the integral patches).

--- lame-3.97/frontend/Makefile.am
+++ lame-3.97.new/frontend/Makefile.am
@@ -52,7 +52,7 @@
  endif

  CFLAGS = @CFLAGS@ @GTK_CFLAGS@ @FRONTEND_CFLAGS@
-LDFLAGS = @LDFLAGS@ @FRONTEND_LDFLAGS@ -static
+LDFLAGS = @LDFLAGS@ @FRONTEND_LDFLAGS@

  INCLUDES = -I$(top_srcdir)/libmp3lame -I$(top_srcdir)/include
-I$(top_builddir)


--- lame-3.97/frontend/Makefile.in
+++ lame-3.97.new/frontend/Makefile.in
@@ -156,7 +156,7 @@
  $(top_builddir)/libmp3lame/libmp3lame.la \
  @FRONTEND_LDADD@

-LDFLAGS = @LDFLAGS@ @FRONTEND_LDFLAGS@ -static
+LDFLAGS = @LDFLAGS@ @FRONTEND_LDFLAGS@
  LIBOBJS = @LIBOBJS@
  LIBS = @LIBS@
  LIBTOOL = @LIBTOOL@


> I have problems compiling lame with Apple's GCC 4.0.x (or whatever they
> ship that may have backported patches) when I compile with expopts.

Sorry, I have absolutely no idea about Mac OS X at all.

Cheers,
Fabian

--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax:     +49 (0)234 / 32-14227
E-Mail:  greffrath@...

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Alexander Leidinger
Re: some minor patches
Reply Threaded More
Print post
Permalink
Quoting Fabian Greffrath <greffrath@...> (from Wed, 11 Jun  
2008 09:34:29 +0200):

>> Why develop their own debian/ directory? Why not submit the changes
>> upstream so that I can create a new module in CVS so that things get
>> separed?
>
> You can find my packaging efforts in the Debian restricted SVN:
> http://svn.debian.org/wsvn/restricted/dists/trunk/lame/debian/
>
> I do not like upstream tarballs allready providing debian/
> directories, because I don't want to create a native Debian package. I
> want source code in the orig.tar.gz separated from the packaging code
> in the diff.gz.

How do other projects handle this (projects which provide binary  
debian packages themself)?

>> Please, could you send the patch inline? It seems that the mailing list
>> software that sourceforge uses ate your patch. :-( I would be interested
>> in your modifications.
>
> Yes, it seems my attached patches were not properly submitted. :(
>
> Well, hereÄs the patch (it can also be found in SVN, though). However,
> I believe it would be a cleaner solution to substitute '-lm' with some
> variable like $(LIBM) or @LIBM@.

Yes, that would be better. In fact we have something like this already  
in configure.in. I don't remember ATM how it is done, but I'm a little  
bit surprised that the libm is not handled correctly on debian. I try  
to get some time to have a look at this.

> --- lame-3.97/frontend/Makefile.in
> +++ lame-3.97.new/frontend/Makefile.in
> @@ -156,7 +156,7 @@
>   $(top_builddir)/libmp3lame/libmp3lame.la \
>   @FRONTEND_LDADD@
>
> -LDFLAGS = @LDFLAGS@ @FRONTEND_LDFLAGS@ -static
> +LDFLAGS = @LDFLAGS@ @FRONTEND_LDFLAGS@

This was a design decision. When I converted LAME to the autotools, I  
had it use dyn libs in the beginning. The request was to make lame  
link statically, so that it is enough to copy one file to another  
system to get lame working. Personally I don't care about this, but  
because of this I'm a little bit reluctant to just change this.

Someone out there objecting to change it?

Bye,
Alexander.

--
On a clear day, U.C.L.A.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Fabian Greffrath-6
Re: some minor patches
Reply Threaded More
Print post
Permalink
Alexander Leidinger schrieb:
> How do other projects handle this (projects which provide binary debian
> packages themself)?

In most cases (let's take libquicktime as an example) we remove the
Debian directory and repackage the source tarball with a version
suffix, e.g. 1.0.2+debian.

Dont' get me wrong, we do this in good faith and not because we have
too much time to spend on rebuilding tarballs. The main reasons are
(1) the overall bad quality of many of the provided debian/
directories (this is not directly against LAME, but the one in e.g.
libquicktime has not been maintained since ~2004) and (2) because we
want to distinguish between upstream source code and Debian-specific
packaging code.

> Yes, that would be better. In fact we have something like this already
> in configure.in. I don't remember ATM how it is done, but I'm a little
> bit surprised that the libm is not handled correctly on debian. I try to
> get some time to have a look at this.

It's not a Debian-related problem. It occurs whenever you try to link
against libmp3lame with '-Wl,--as-needed' to avoid unecessary
dependencies.

> This was a design decision. When I converted LAME to the autotools, I
> had it use dyn libs in the beginning. The request was to make lame link
> statically, so that it is enough to copy one file to another system to
> get lame working. Personally I don't care about this, but because of
> this I'm a little bit reluctant to just change this.

Nowadays most unixoid systems should provide a package management that
can handle dependencies properly, so I see no reason in installing the
same library code in three binaries on one system. If you want to
manually  move the tools between two systems, copy the library as well
and you're done. ;)

Cheers,
Fabian

--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax:     +49 (0)234 / 32-14227
E-Mail:  greffrath@...

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Alexander Leidinger
Re: some minor patches
Reply Threaded More
Print post
Permalink
Quoting Fabian Greffrath <greffrath@...> (from Wed, 11 Jun  
2008 10:36:50 +0200):

> Alexander Leidinger schrieb:
>> How do other projects handle this (projects which provide binary debian
>> packages themself)?
>
> In most cases (let's take libquicktime as an example) we remove the
> Debian directory and repackage the source tarball with a version
> suffix, e.g. 1.0.2+debian.
>
> Dont' get me wrong, we do this in good faith and not because we have
> too much time to spend on rebuilding tarballs. The main reasons are
> (1) the overall bad quality of many of the provided debian/
> directories (this is not directly against LAME, but the one in e.g.
> libquicktime has not been maintained since ~2004) and (2) because we

Do you also have an example of a tarball with a well maintained debian  
directory? Basically that's what we offer, incorporating patches to  
make the debian directory well maintained. Based upon my experience on  
FreeBSD (I'm a FreeBSD developer in the past I had some packages with  
extensive FreeBSD specific changes): as less changes you have to do  
locally (for "your own" package management system), the better. If you  
have a package where the upstream author (in this case we, the LAME  
authors) are listening to the needs of the package maintainer, then it  
is great, push as much local stuff upstream (in a way which doesn't  
hurt other platforms) and you have less work to do during updates.

> want to distinguish between upstream source code and Debian-specific
> packaging code.
>
>> Yes, that would be better. In fact we have something like this already
>> in configure.in. I don't remember ATM how it is done, but I'm a little
>> bit surprised that the libm is not handled correctly on debian. I try to
>> get some time to have a look at this.
>
> It's not a Debian-related problem. It occurs whenever you try to link
> against libmp3lame with '-Wl,--as-needed' to avoid unecessary
> dependencies.

Ok, let's use a different description: I'm wondering why libm is not  
automatically added to the frontend ldflags already.

Hmmm... in configure.in we have
  FRONTEND_LDADD="${FRONTEND_LDADD} ${CONFIG_MATH_LIB}"
which should already contain -lm.

Is lame compiled with libsoundfile on debian? Have you tried to move  
the sndfile libs in front of the frontend ldflags stuff?

>> This was a design decision. When I converted LAME to the autotools, I
>> had it use dyn libs in the beginning. The request was to make lame link
>> statically, so that it is enough to copy one file to another system to
>> get lame working. Personally I don't care about this, but because of
>> this I'm a little bit reluctant to just change this.
>
> Nowadays most unixoid systems should provide a package management that
> can handle dependencies properly, so I see no reason in installing the
> same library code in three binaries on one system. If you want to

BTW: the only executable a lame package should install is lame itself.

The mp3x is a pure developer program, if you don't want to modify the  
lame mp3 algorithms, this program is completely useless for you (and  
you can get rid of the gtk1 and x11-lib dependency completely). If you  
want to modify the mp3 algorithms, you should use the CVS version of  
lame anyway.

The mp3rtp one is not really maintained and there is other software  
which is better suited, e.g. icecast or shoutcast or something like  
this. mp3rtp is more a development tool for rare use cases than really  
something which should be used in production.

> manually  move the tools between two systems, copy the library as well
> and you're done. ;)

This does not work for unix-beginners, they don't know about  
LD_LIBRARY_PATH or may have root access. Again: personally I don't  
object to the change, I'm all for your proposal to remove the -static  
switch. I agree on the dependency tracking part of package management  
systems.

Bye,
Alexander.

--
Edna: "Excuse me, I've got to powder my mouth flaps."

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Rogério Brito-2
Re: some minor patches
Reply Threaded More
Print post
Permalink
Hi, Alexander and Fabian (and Alexandre and Gerfried on CC).

On Jun 11 2008, Alexander Leidinger wrote:

> Quoting Fabian Greffrath <greffrath@...> (from Wed, 11 Jun  
> 2008 10:36:50 +0200):
> > Alexander Leidinger schrieb:
> > Dont' get me wrong, we do this in good faith and not because we have
> > too much time to spend on rebuilding tarballs. The main reasons are
> > (1) the overall bad quality of many of the provided debian/
> > directories (this is not directly against LAME, but the one in e.g.
> > libquicktime has not been maintained since ~2004) and (2) because we
>
> Do you also have an example of a tarball with a well maintained debian  
> directory?

I am a maintainer of other 3 Debian packages that *are* in the official
repository. Even though I am mostly the only one who changed the debian
directory for lame (which may mean that I am biased myself), I think
that the job that I've done isn't bad. I have updated the packaging with
the most recent Debian policy (well, actually, one has *just* been
released, but I think that almost no changes (or little ones, at most)
would be needed to be on the bleeding edge of things).

And you should have a shining Debian package. I have even actively hunt
and incorporated changes of the most widely distributed binary package
for lame (which is Christian Marillat's from www.debian-multimedia.org)
and chose which ones are worth keeping and I think that, in some
respects, my package is better than his (for instance, the name of the
library package is actually libmp3lame0, *not* liblame0), but I provide
a dummy package so that what people get is a drop-in replacement for his
package.

> Basically that's what we offer, incorporating patches to make the
> debian directory well maintained. Based upon my experience on FreeBSD
> (I'm a FreeBSD developer in the past I had some packages with
> extensive FreeBSD specific changes): as less changes you have to do
> locally (for "your own" package management system), the better.

No questions about that. And changes should always be offered upstream.

> If you have a package where the upstream author (in this case we, the
> LAME authors) are listening to the needs of the package maintainer,
> then it is great, push as much local stuff upstream (in a way which
> doesn't hurt other platforms) and you have less work to do during
> updates.

ACK.

> > It's not a Debian-related problem. It occurs whenever you try to link
> > against libmp3lame with '-Wl,--as-needed' to avoid unecessary
> > dependencies.
>
> Ok, let's use a different description: I'm wondering why libm is not  
> automatically added to the frontend ldflags already.
>
> Hmmm... in configure.in we have
>   FRONTEND_LDADD="${FRONTEND_LDADD} ${CONFIG_MATH_LIB}"
> which should already contain -lm.
>
> Is lame compiled with libsoundfile on debian?

The package that I provide in our own repository is. This was the saga
where I kept asking you to see the auto* stuff, so that the package
today works AT LEAST with the following 3 architectures under Debian:
i386 (ia32), x86-64, and powerpc. I have fed .flac compressed files
(which lame gets via libsndfile) (as well as ordinary .wav) to lame and
the result was superb.

It also builds fine on MacOS X (on ia32). I still have not installed the
Apple developer tools on my MacOS X on PowerPC. So, as you can see, I
can test lame on 5 different environments.

> Have you tried to move the sndfile libs in front of the frontend
> ldflags stuff?

I didn't have to do that with the package we create: I just selected,
during the configure phase, the option saying that I want libsndfile and
have the development things of libsndfile1 installed on the Debian
system.

BTW, the current tarball that is released (3.97) doesn't have all the
goodness that CVS HEAD has (like libsndfile support, fractional VBR
quality setting, much improved encoding---even on arches that don't have
asm coded computationally intensive routines, like powerpc).

> > Nowadays most unixoid systems should provide a package management that
> > can handle dependencies properly, so I see no reason in installing the
> > same library code in three binaries on one system. If you want to
>
> BTW: the only executable a lame package should install is lame itself.

The way that I packaged lame on our repository creates 4 different
packages (sorry for not communicating this before, but I think that you
guys would be bored with long descriptions of that):

* the lame package, which, indeed, only contains the lame executable and
  copyright files and other similar things required by Debian;
* the libmp3lame0 package, which is a dynamically library on which other
  packages can depend (like, say, ffmpeg or mencoder);
* the libmp3lame0-dev package, which contains the header files needed
  for compiling things with lame;
* the liblame0 to fulfill the gap for people whose installation uses
  Marillat's repository.

> The mp3x is a pure developer program, if you don't want to modify the  
> lame mp3 algorithms, this program is completely useless for you (and  
> you can get rid of the gtk1 and x11-lib dependency completely). If you  
> want to modify the mp3 algorithms, you should use the CVS version of  
> lame anyway.

Yes, I thought about packaging these, but Debian has since phased out
gtk1 from the current versions of the repository (everything has to
compile with gtk2 or other modern graphical toolkit).

> The mp3rtp one is not really maintained and there is other software  
> which is better suited, e.g. icecast or shoutcast or something like  
> this. mp3rtp is more a development tool for rare use cases than really  
> something which should be used in production.

Again, not packaged.

> > manually  move the tools between two systems, copy the library as well
> > and you're done. ;)
>
> This does not work for unix-beginners, they don't know about  
> LD_LIBRARY_PATH or may have root access.

Not only that, but you have to have shared libraries that work with the
libc installed on the new system, which we can't guarantee. I think that
the audacity sound editor relies, on Mac systems, on having a shared
object that is callable to export your sound project to MP3.

> Again: personally I don't object to the change, I'm all for your
> proposal to remove the -static switch. I agree on the dependency
> tracking part of package management systems.

Couldn't we leave this static linking in for the default builds from the
project and leave this minor thing for packagers? I don't know how Red
Hat systems work here regarding package dependencies (they used to have
*file* dependencies instead of package dependencies and that's the last
time when I touched one of these systems).

OTOH, if there is realy a desire to remove -static, I can test our
packaging and see if we improve on things.

But, in principle, I'm all for a minimal system.



Regards, Rogério Brito.

--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Fabian Greffrath-6
Re: some minor patches
Reply Threaded More
Print post
Permalink
Alexander Leidinger schrieb:

> Do you also have an example of a tarball with a well maintained debian
> directory? Basically that's what we offer, incorporating patches to make
> the debian directory well maintained. Based upon my experience on
> FreeBSD (I'm a FreeBSD developer in the past I had some packages with
> extensive FreeBSD specific changes): as less changes you have to do
> locally (for "your own" package management system), the better. If you
> have a package where the upstream author (in this case we, the LAME
> authors) are listening to the needs of the package maintainer, then it
> is great, push as much local stuff upstream (in a way which doesn't hurt
> other platforms) and you have less work to do during updates.

Of source I see the need to submit patches against the source code to
upstream, that's not the question. Distributions should definitely
diverge from upstream sources as least as possible.

But I don't see a reason why upstream should care about the Debian
packaging which is done downstream anyway. However, I would appreciate
your decision to provide a debian/ directory if you provided binary
Debian packages on your homepage, which were created exactly this way
(you would play both the role of source code upstream and distributor
downstream here). But I guess this is not likelike to happen...

As an example for tarballs which contain ready-to-use debian/
directories, there are the native Debian packages, e.g. dpkg or apt.
There is no need to distinguish between original source and
packaging-related source since these programs are Debian-specific
anyway. For any other software, this distinction should be done IMHO.

> Ok, let's use a different description: I'm wondering why libm is not
> automatically added to the frontend ldflags already.

The patch I proposed does not fix the frontend linking, but the
linking of the *library* itself!

> Is lame compiled with libsoundfile on debian? Have you tried to move the
> sndfile libs in front of the frontend ldflags stuff?

Please don't mix things up: LAME isn't compiled in Debian at all.
There is nothing like an official LAME package in Debian, but there
are several inofficial packages which all differ in marginal ways -
one of those packaging efforts can be found at debian-multimedia.org,
another one at debian-official.org and there's even one in the LAME
source tarball. ;)

I have build my packjages against LAME 3.97 which does not offer an
option to link against libsndfile IIRC.

> BTW: the only executable a lame package should install is lame itself.

Allright, I believe this and your following explanations about mp3x
and mp3rtp should be explicitely documented somewhere in the source
code. My current package design installs both of them into a
lame-utils package which may be installed seperately.

> This does not work for unix-beginners, they don't know about
> LD_LIBRARY_PATH or may have root access. Again: personally I don't
> object to the change, I'm all for your proposal to remove the -static
> switch. I agree on the dependency tracking part of package management
> systems.

You are right. It may be left to the distributors to decide if they
want the frontend(s) the be linked against the static or shared
library. How about a configuration flag, e.g. --shared-frontend?!


Cheers,
Fabian

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Fabian Greffrath-6
Re: some minor patches
Reply Threaded More
Print post
Permalink
Fabian Greffrath schrieb:
> I have build my packjages against LAME 3.97 which does not offer an
> option to link against libsndfile IIRC.

Argh, please forget about this statement.

I have compiled my packages with '--with-fileio=lame'. That's why I
have not bothered about libsndfile so far...

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Fabian Greffrath-6
Re: some minor patches
Reply Threaded More
Print post
Permalink
Rogério Brito schrieb:
> I think
> that the job that I've done isn't bad.

I did never want to assume this in the first place.

> respects, my package is better than his (for instance, the name of the
> library package is actually libmp3lame0, *not* liblame0), but I provide
> a dummy package so that what people get is a drop-in replacement for his
> package.

Daniel Baumann and myself were not very happy with many of the
packages that are provided from this source; this is one of the reason
why debian-unofficial.org was created at all.

Personally I believe you should better let your packages
Conflicts/Replaces/Provides: liblame0 than providing a transitional
package.

> No questions about that. And changes should always be offered upstream.

Same here! ;)

> * the lame package, which, indeed, only contains the lame executable and
>   copyright files and other similar things required by Debian;

How about another seperate package 'lame-utils' to contain the
additional utilities?

> * the libmp3lame0 package, which is a dynamically library on which other
>   packages can depend (like, say, ffmpeg or mencoder);

As mentioned above, how about Conflicts/Replaces/Provides: liblame0?

> * the libmp3lame0-dev package, which contains the header files needed
>   for compiling things with lame;

I believe that development packages should *not* contain the shared
library's SONAME in their names, i.e. libmp3lame-dev.

> Not only that, but you have to have shared libraries that work with the
> libc installed on the new system, which we can't guarantee.

You're right, I forgot about possible libc incompatibilities. However,
software packaged by a distributor shouldn't be treated this way (i.e.
copied around manually) so dynamic linking should be allright.

However, maybe I have changed my mind about the debian/ directory
issue. For software like LAME, that do *not* have an official package
in the Debian archive, it should be OK to provide packaging code
within the source tarball. But please keep in mind that you create a
*native* Debian package this way, i.e. no '-1' in the package version
(lintian will complain about this anyway). This means, each change in
the packaging must lead to another source tarball, e.g. lame-3.97.1,
and I don't know if this is in the interest of the LAME maintainers.

Cheers,
Fabian

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Rogério Brito-2
Re: some minor patches
Reply Threaded More
Print post
Permalink
On Jun 12 2008, Fabian Greffrath wrote:
> Fabian Greffrath schrieb:
> > I have build my packjages against LAME 3.97 which does not offer an
> > option to link against libsndfile IIRC.
>
> Argh, please forget about this statement.
>
> I have compiled my packages with '--with-fileio=lame'. That's why I
> have not bothered about libsndfile so far...

I'm not sure if LAME 3.97 was released with Erik de Castro Lopo's
(libsndfile upstream) kind contribution to use sndfile1, which seems to
be leaps and bounds better than sndfile0.

I was at a conference on theoretical computer science in September 2006
(when this happened/from memory) that time and I could only think of
mathematical objects. :-)

I don't know if we were discussing LAME 3.96 by that time or not
(I'm too lazy to look up the history right now).

Unfortunately, the packaging there was not up-to-date as it is nowadays:
it used an ancient Standards Version (3.5.4, IIRC), it had some other
problems with packaging etc.

Despite the fact that Robert, Takehiro, Gabriel, and Alexander might not
agree, I would package/offer LAME 3.98 beta 8 on your site (with a date
appended or with the use of a "~", which dpkg now supports), since it is
so much better in many aspects from 3.97.


Regards, Rogério Brito.

--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Rogério Brito-2
Re: some minor patches
Reply Threaded More
Print post
Permalink
On Jun 12 2008, Fabian Greffrath wrote:
> > Ok, let's use a different description: I'm wondering why libm is not
> > automatically added to the frontend ldflags already.
>
> The patch I proposed does not fix the frontend linking, but the
> linking of the *library* itself!

There seems to be something fishy here, as I never needed to add libm
support for the library myself.

And my system is not an odd-ball one where gcc just includes it by
default: I was compiling software this week that *needed* me to include
add libm to the command line.

> > This does not work for unix-beginners, they don't know about
> > LD_LIBRARY_PATH or may have root access. Again: personally I don't
> > object to the change, I'm all for your proposal to remove the -static
> > switch. I agree on the dependency tracking part of package management
> > systems.
>
> You are right. It may be left to the distributors to decide if they
> want the frontend(s) the be linked against the static or shared
> library. How about a configuration flag, e.g. --shared-frontend?!

You know what? I was thinking late last night about a good compromise
between duplication of code (a static build) and fat reduction on the
system :) and I came to the same idea about a configure option. :-)


Regards, Rogério Brito.

--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Fabian Greffrath-6
Re: some minor patches
Reply Threaded More
Print post
Permalink
Rogério Brito schrieb:
> There seems to be something fishy here, as I never needed to add libm
> support for the library myself.

It is only needed when compiling with LDFLAGS="-Wl,--as-needed".
Please try to compile LAME again with this environment set.

I haven't tried yet, but it may be possible this only occurs when
linking against the shared libmp3lame.so, so you should remove the
'-static' flag for linking of the frontend.

> You know what? I was thinking late last night about a good compromise
> between duplication of code (a static build) and fat reduction on the
> system :) and I came to the same idea about a configure option. :-)

Hehe, great minds think alike. ;)

Cheers,
Fabian

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Fabian Greffrath-6
Re: some minor patches
Reply Threaded More
Print post
Permalink
Rogério Brito schrieb:
> I'm not sure if LAME 3.97 was released with Erik de Castro Lopo's
> (libsndfile upstream) kind contribution to use sndfile1, which seems to
> be leaps and bounds better than sndfile0.

I don't know either, but there must be a reason why lame was chosen
for fileio instead of libsndfile.

> Despite the fact that Robert, Takehiro, Gabriel, and Alexander might not
> agree, I would package/offer LAME 3.98 beta 8 on your site (with a date
> appended or with the use of a "~", which dpkg now supports), since it is
> so much better in many aspects from 3.97.

I am only maintaining the packages in SVN to not lose track with
upstream. I do not have rights to upload them into any repository. The
sad fact is, that I believe LAME 3.98 will long be stable before
Daniel Baumann resurrects debian-unofficial.org. :(

Cheers,
Fabian

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Alexander Leidinger
Re: some minor patches
Reply Threaded More
Print post
Permalink
Quoting Fabian Greffrath <greffrath@...> (Thu, 12 Jun 2008 14:11:13 +0200):

> Rogério Brito schrieb:
> > There seems to be something fishy here, as I never needed to add libm
> > support for the library myself.
>
> It is only needed when compiling with LDFLAGS="-Wl,--as-needed".
> Please try to compile LAME again with this environment set.
>
> I haven't tried yet, but it may be possible this only occurs when
> linking against the shared libmp3lame.so, so you should remove the
> '-static' flag for linking of the frontend.
>
> > You know what? I was thinking late last night about a good compromise
> > between duplication of code (a static build) and fat reduction on the
> > system :) and I came to the same idea about a configure option. :-)
>
> Hehe, great minds think alike. ;)

I agree... I try to get some time next week to have a look at this. I
will also have a look at adding a math library to the build of the
dynamic lib. On systems with a good run-time linker (and debian is one,
AFAIR), this can make a difference.

Bye,
Alexander.

--
 Earth men are real men!
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Fabian Greffrath-6
Re: some minor patches
Reply Threaded More
Print post
Permalink
Alexander Leidinger schrieb:
> I agree... I try to get some time next week to have a look at this. I
> will also have a look at adding a math library to the build of the
> dynamic lib. On systems with a good run-time linker (and debian is one,
> AFAIR), this can make a difference.

Great, thank you very much!

Cheers,
Fabian


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Lame-dev mailing list
Lame-dev@...
https://lists.sourceforge.net/lists/listinfo/lame-dev
Alexander Leidinger