audacity-nonfree, normalize: ? maintainership ?

[Michael Schwendt]

On Wed, 13 Aug 2008 08:25:12 +1000, David Timms wrote:

[Audacity]

> My first impression of the -nonfreee package was that it had just the 
> non-fedora allowed bits, but I see it conflicts/replaced f version. 
> Seems to be a package that can't dynamically open the 'non-free' bits if 
> they are present ?

Right, it doesn't do that. Only for mp3 encoding with LAME.
There is no powerful plugin technology implemented.
Audacity cvs already contains a lot of work that integrates ffmpeg.
That might get funny in the near future.

> With Fedora we have a update-testing repo. This might be against policy 
> for Fedora: Could we build always the latest version and expect to have 
> it there long term, until a new Beta release or enough feedback says the 
> package is 'good' or at least better than the last updates package.

That's what is being done with F-8 and F-9. Prior to that I've offered
several unofficial builds of betas/snaphots and requested feedback on
fedora-list and fedora-music-list. Some of that is documented in
fedora cvs.

Rawhide has been upgraded to the latest beta, however. In case F-10 users
will report show-stopper bugs, it's always possible to ship an update that
includes multiple releases of audacity. We need to move forward, though,
and give the community something to test on the road to Audacity 1.4.0.

> I don't remember seeing any similar -testing repo for livna, rpmfusion 
> {other than devel, which I expect is for use with fedora-rawhide}, have 
> I missed that ?

-testing at rpmfusion seems to be different from livna/epel style. That
is, there is now a new set of repos: releases, updates, updates/testing,
and development. Builds are put into "updates/testing" first and
moved to updates after some time. Whether it is built against
fedora updates-testing, I don't know. I have doubts that it is done.

Theoretically, Plague can be set up to do real updates-testing builds.
[It can also do scratch builds, btw]. In both cases, however, additional
build targets are needed, so the build slaves pull in the updates-testing
repos. It would require more modifications, e.g. in the pushscripts (a new
method to move pkgs between repos) and something like "make build-testing"
or similar. It would be quite clumsy. For example, also due to the delay
of when packages in bodhi are released to the repos and are synced
by rpmfusion.