some minor patches
|
|
Fabian Greffrath-6
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
|