Re: Packaging current lame CVS snapshot for Debian -- good or bad idea?

[email protected]
Newsgroups gmane.comp.audio.mp3.lame
Message-ID <CAOtrxKP8YUW_TQ74TrBtwJsWP1tOdx76Ufqtj--RRSJE7j34AA@mail.gmail.com>
Hi, Fabian and others.

On Fri, May 8, 2015 at 4:32 AM, Fabian Greffrath <[email protected]> wrote:
> We are currently packaging the latest stable release 3.99.5 and over
> time, we have added more and more patches to our package, most of them
> have already been applied in the lame CVS repository as well (thanks
> rbrito):

Thanks. I have been applying some patches that people have sent me,
but I still have quite a bit of work to do, as we have to triage
contributions from a lot of people and sourceforge's interface is not
entirely manipulable by e-mail or other convenient ways.

Anyway, as I have already talked privately with Fabian, I think that
the best person to answer about packaging a snapshot of LAME would be
Robert (in CC), since he has some patches fine-tuning the audio parts
of the project. Robert, is generating a package from the current
HEAD/master branch of CVS likely to have negative effects in
comparison with lame 3.99.5?

If so, what if we released a small bug fix of 3.99, say, 3.99.6? This
way, I think that we could address things that other people want and
we would save people from patching their local copies of lame.

> http://anonscm.debian.org/cgit/pkg-multimedia/lame.git/tree/debian/patches
>
> Now that Debian "jessie" has been released, I'd like to prepare a new
> Debian package for lame based on a current CVS snapshot, so I can get
> rid of most of the patches we currently apply.

Now, this is a question to Fabian: can you remind me why you are
repackaging lame instead of using the tarball that we ship?

Also, I saw that debian/rules uses two switches:

* --enable-expopt=full: I am not really sure if this has been touched
in the last decade or not, but I recall a discussion from a few years
ago that we had developers using (for the sake of simplicity) one of
the ready made Makefile that are in the repository.
* --with-fileio=lame: any reason to not use sndfile? It allows feeding
a considerable greater amount of file types into lame (including
FLAC). I personally use a local copy of lame recompiled with sndfile
just for transcoding mp3 and flac files into files with lower bitrate
(yes, file size is still something that matters).

OK, I will stop here. I hope that Robert can give everybody a position
on what he considers the status of HEAD.


Regards,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Lame-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lame-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.