Bug#482509: idjc: FTBFS: Nonexistent build-dependency: liblame-dev
reopen 482509 found 482509 0.8.2-3 retitle 482509 Please build against libtwolame, instead of libmp3lame severity 482509 wishlist tags 482509 + patch thanks Hi, the following change has been introduced for the 0.8.1-1 upload: * Change order of the toolame/mp3lame build dependency (Closes: #482509, #534076) However, as already stated in the bug report, both toolame and twolame are command line encoders that do not add any functionality to idjc, especially not in their current role as build-depends. So this change is rather pointless. Please change the build-depends from "twolame | libmp3lame-dev" to "libtwolame-dev" and apply the patch provided by peter green so that we can at least have MP2 encoding in Debian. Users who aim to rebuild idjc against libmp3lame in order to get MP3 support should be warned to disable this patch before, though. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#482509: idjc: FTBFS: Nonexistent build-dependency: liblame-dev
Kurt Roeckx schrieb: It now build-depends on libmp3lame-dev | toolame and the autobuilders only attempt the first alternative, so your package is failing to build. toolame will be removed from the archive in the short term, so please change this b-d to twolame. -- 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: greffr...@leat.ruhr-uni-bochum.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#482509: idjc: FTBFS: Nonexistent build-dependency: liblame-dev
It now build-depends on libmp3lame-dev | toolame and the autobuilders only attempt the first alternative, so your package It's not my package, i'm just someone commenting on the bug report. I have mentioned two different possibilities for fixing this bug in the bug report. The package now just needs a dd to pick one of them and upload it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#482509: idjc: FTBFS: Nonexistent build-dependency: liblame-dev
On Fri, May 30, 2008 at 09:26:25PM +0100, peter green wrote: > The ftbfs on autobuilder issue could be fixed by switching the order of > the optional build-dependencies. It now build-depends on libmp3lame-dev | toolame and the autobuilders only attempt the first alternative, so your package is failing to build. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#482509: idjc: FTBFS: Nonexistent build-dependency: liblame-dev
tags 482509 +patch
thanks
IMO it is a very bad idea to have a package build against a legally
dubious library just because the system it was built on happened to
have it installed.
lame itself is not legally dubious, it's just unfortunate in being
liable to software patent enforcement on MP3 encoding. That's reason
enough not to include lame in Debian, of course.
That is what I meant by legally dubious
It should be possible to build idjc without lame, thereby making it
suitable for encoding Ogg Vorbis streams only. It would still be a
useful application in that context.
Indeed and I think it is do better than that providing a form of
psuedo-mp3 support.
The only change between -3 and -4 was adding liblame-dev | toolame to
the build-dependencies.
It seems that the upstream build scripts decide what mp3 encoding
options to use based on what is installed.
Previously there were no "mp3" libraries in the build-depends at all
meaning the code was built without mp3 support.
Installing toolame does not seem to make any difference (perhaps Free
Ekanayaka mixed up toolame and twolame, toolame unlike twolame doesn't
seem to provide a liblame equivilent),
Installing libtwolame-dev also does not seem to make any difference to
the build
A little more research shows that the twolame api is pretty much the
same as the lame api but with all the functions/structures renamed. I
have put together a patch that will make the code build with twolame and
give an option to encode to mp3 but i do not have an appropriate server
handy to test it with. If you accept this patch then the build-depends
should be changed to reflect it.
If you do not want to accept my patch (or if you test it and it doesn't
work) then I would suggest reverting the build-depends in -4 change
which will leave a package that is releasable but lacks mp3 support.
diff -ur idjc-0.7.5/c/live_mp3_encoder.c idjc-0.7.5-new/c/live_mp3_encoder.c
--- idjc-0.7.5/c/live_mp3_encoder.c 2008-04-19 14:52:17.0 +
+++ idjc-0.7.5-new/c/live_mp3_encoder.c 2008-06-03 19:36:06.0 +
@@ -124,24 +124,26 @@
fprintf(stderr, "live_mp3_encoder_main: malloc failure\n");
goto bailout;
}
- if (!(s->gfp = lame_init()))
+ if (!(s->gfp = twolame_init()))
{
fprintf(stderr, "live_mp3_encoder_main: failed to initialise LAME\n");
free(s->mp3buf);
goto bailout;
}
- lame_set_num_channels(s->gfp, encoder->n_channels);
- lame_set_brate(s->gfp, encoder->bitrate);
- lame_set_in_samplerate(s->gfp, encoder->target_samplerate);
- lame_set_out_samplerate(s->gfp, encoder->target_samplerate);
- lame_set_mode(s->gfp, s->lame_mode);
- lame_set_quality(s->gfp, s->lame_quality);
- lame_set_free_format(s->gfp, s->lame_freeformat);
- lame_set_bWriteVbrTag(s->gfp, 0);
- if (lame_init_params(s->gfp) < 0)
+ twolame_set_num_channels(s->gfp, encoder->n_channels);
+ twolame_set_brate(s->gfp, encoder->bitrate);
+ twolame_set_in_samplerate(s->gfp, encoder->target_samplerate);
+ twolame_set_out_samplerate(s->gfp, encoder->target_samplerate);
+ twolame_set_mode(s->gfp, s->lame_mode);
+ //some settings that lame has but toolame doesn't
+ //don't look too important
+ //twolame_set_quality(s->gfp, s->lame_quality);
+ //twolame_set_free_format(s->gfp, s->lame_freeformat);
+ //twolame_set_bWriteVbrTag(s->gfp, 0);
+ if (twolame_init_params(s->gfp) < 0)
{
fprintf(stderr, "live_mp3_encoder_main: LAME rejected the parameters given\n");
- lame_close(s->gfp);
+ twolame_close(s->gfp);
free(s->mp3buf);
goto bailout;
}
@@ -161,7 +163,8 @@
if (encoder->flush || !encoder->run_request_f)
{
encoder->flush = FALSE;
- mp3bytes = lame_encode_flush_nogap(s->gfp, s->mp3buf, s->mp3bufsize);
+ //twolame seems to lack a _flush_nogap, hopefully _flush will do
+ mp3bytes = twolame_encode_flush(s->gfp, s->mp3buf, s->mp3bufsize);
fprintf(stderr, "live_mp3_encoder_main: flushing %d bytes\n", mp3bytes);
live_mp3_write_packet(encoder, s, s->mp3buf, mp3bytes, PF_MP3 | PF_FINAL);
encoder->encoder_state = ES_STOPPING;
@@ -179,7 +182,7 @@
*l++ *= 32768.0F;
*r++ *= 32768.0F;
}
-mp3bytes = lame_encode_buffer_float(s->gfp, id->buffer[0], id->buffer[1], id->qty_samples, s->mp3buf, s->mp3bufsize);
+mp3bytes = twolame_encode_buffer_float32(s->gfp, id->buffer[0], id->buffer[1], id->qty_samples, s->mp3buf, s->mp3bufsize);
encoder_ip_data_free(id);
s->lame_samples += id->qty_samples;
live_mp3_write_packet(encoder, s, s->mp3buf, mp3bytes, PF_MP3 | s->packetflags);
@@ -197,7 +200,7 @@
}
if (encoder->encoder_state == ES_STOPPING)
{
- lame_
Bug#482509: idjc: FTBFS: Nonexistent build-dependency: liblame-dev
On fredagen den 30 maj 2008, you stated the following: > The ftbfs on autobuilder issue could be fixed by switching the order of > the optional build-dependencies. However, toolame is a stand-alone command-line encoder; it's hardly of any use when building idjc. Free may really have meant libtwolame-dev, but that's not a drop-in replacement for liblame-dev either; TwoLAME has a different API and ABI and at any rate, IDJC's ./configure doesn't look for it. > but IMO it is a very bad idea to have a package build against a legally > dubious library just because the system it was built on happened to have > it installed. Well, if it's installed it gets used whether or not it is listed as a build dependency. You'd have to list all such undesirable libraries in Build-Conflicts to prevent building against them, but IMHO that's merely inconvenient to everyone living outside the relatively few countries where software can be patented, who wants to rebuild the package with full functionality. Since there is no LAME in Debian there is no possibility that a package linked against LAME will make it to stable. -- Magnus Holmgren[EMAIL PROTECTED] Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#482509: idjc: FTBFS: Nonexistent build-dependency: liblame-dev
Hi Peter, IMO it is a very bad idea to have a package build against a legally dubious library just because the system it was built on happened to have it installed. lame itself is not legally dubious, it's just unfortunate in being liable to software patent enforcement on MP3 encoding. That's reason enough not to include lame in Debian, of course. It should be possible to build idjc without lame, thereby making it suitable for encoding Ogg Vorbis streams only. It would still be a useful application in that context. Cheers! Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#482509: idjc: FTBFS: Nonexistent build-dependency: liblame-dev
The ftbfs on autobuilder issue could be fixed by switching the order of the optional build-dependencies. but IMO it is a very bad idea to have a package build against a legally dubious library just because the system it was built on happened to have it installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#482509: idjc: FTBFS: Nonexistent build-dependency: liblame-dev
Package: idjc Version: 0.7.5-4 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080522 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3 is now the default on most architectures (even if it's not the case on i386 yet). Consequently, many failures are caused by the switch to gcc 4.3. If you determine that this failure is caused by gcc 4.3, feel free to downgrade this bug to 'important' if your package is only built on i386, and this bug is specific to gcc 4.3 (i.e the package builds fine with gcc 4.2). Relevant part: > ** Using build dependencies supplied by package: > Build-Depends: debhelper (>= 5.0.38), cdbs (>= 0.4.43), python-all-dev (>= > 2.3.5-11), python-central (>= 0.5.6), libjack-dev, python-gtk2-dev, > libvorbis-dev, libxine-dev, libsamplerate0-dev, libflac-dev, libshout3-dev, > libsndfile1-dev, libmad0-dev, libavcodec-dev, libavformat-dev, liblame-dev | > toolame > Checking for already installed source dependencies... > W: Unable to locate package liblame-dev > debhelper: missing > Using default version 7.0.9 > cdbs: missing > Using default version 0.4.52 > python-all-dev: missing > Using default version 2.5.2-1 > python-central: missing > Using default version 0.6.6 > libjack-dev: missing > python-gtk2-dev: missing > libvorbis-dev: missing > libxine-dev: missing > libsamplerate0-dev: missing > libflac-dev: missing > libshout3-dev: missing > libsndfile1-dev: missing > libmad0-dev: missing > libavcodec-dev: missing > libavformat-dev: missing > liblame-dev: missing > toolame: missing > Checking for source dependency conflicts... > Reading package lists... > Building dependency tree... > Reading state information... > E: Couldn't find package liblame-dev The full build log is available from: http://people.debian.org/~lucas/logs/2008/05/22 A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing a sid i386 environment. Internet was not accessible from the build systems. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
