9:31 a.m.
Michael / All,
With regard to audacity-nonfree and normalize, I don't wish to step on
anyones toes. You are definitely welcome to assume primary ownership of
both of them if that is your intent. I sure the person who has spent a
lot of time understanding the software, tracking bugs, etc is going to
have a much easier and more effective task to maintain them.
Can you let me know ?
Cheers, David Timms.
5:17 p.m.
On Tue, 12 Aug 2008 19:31:47 +1000, David Timms wrote:
Michael / All,
With regard to audacity-nonfree and normalize, I don't wish to step on
anyones toes. You are definitely welcome to assume primary ownership of
both of them if that is your intent. I sure the person who has spent a
lot of time understanding the software, tracking bugs, etc is going to
have a much easier and more effective task to maintain them.
Can you let me know ?
Well, Audacity is also in Fedora. It has been sort of upstream for the
Livna package. Except that the Livna package ships two releases in one pkg
to escape from stagnation. It's unclear how long that will be necessary.
Theoretically, the pkg could return to be slightly modified Fedora pkg.
More comaintainers (also testers!) for the Fedora pkg would be helpful. So
far we are two who usually try to agree on whether to upgrade to just
another beta release which [once again] bears the risk of breaking
features in many ways (such as would have been the case with the previous
two beta releases). If Fedora still offered only the more than two years
old stable 1.2.x release, that would be different from other popular
distributions. Users would not understand that. On the contrary, if recent
1.3.x-beta releases are offered, some of the Fedora users with real
interest in Audacity still go and build their own binaries instead of
testing the Fedora rpms.
And "normalize", it's a simple package. It could be passed on to
any beginner packager with a bit of interest in a review and the
software. Interest in old XMMS could be beneficial.
10:25 p.m.
Michael Schwendt wrote:
On Tue, 12 Aug 2008 19:31:47 +1000, David Timms wrote:
> Michael / All,
>
> With regard to audacity-nonfree and normalize, I don't wish to step on
> anyones toes. You are definitely welcome to assume primary ownership of
> both of them if that is your intent. I sure the person who has spent a
> lot of time understanding the software, tracking bugs, etc is going to
> have a much easier and more effective task to maintain them.
>
> Can you let me know ?
Well, Audacity is also in Fedora. It has been sort of upstream for the
Livna package. Except that the Livna package ships two releases in one pkg
to escape from stagnation. It's unclear how long that will be necessary.
Theoretically, the pkg could return to be slightly modified Fedora pkg.
More comaintainers (also testers!) for the Fedora pkg would be
helpful.
I'll request watchcommits, comaintain in fedora. I use it a bit, and
have been trying more recently to record from two sound cards
simultaneously, so when I saw that lack of maintainer for rpmfusion
thought I would put up my hand. Only had a short look at the code a few
years back to consider it as a basis for something I was tinkering with.
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 ?
So
far we are two who usually try to agree on whether to upgrade to just
another beta release which [once again] bears the risk of breaking
features in many ways (such as would have been the case with the previous
two beta releases). If Fedora still offered only the more than two years
old stable 1.2.x release, that would be different from other popular
distributions. Users would not understand that. On the contrary, if recent
1.3.x-beta releases are offered, some of the Fedora users with real
interest in Audacity still go and build their own binaries instead of
testing the Fedora rpms.
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.
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 ?
Is there a different level of QA here, where the package doesn't get
released at all unless we are really sure it's good to go ?
And "normalize", it's a simple package. It could be
passed on to
any beginner packager with a bit of interest in a review and the
software. Interest in old XMMS could be beneficial.
I'm fairly beginner'ish
myself {just glglobe in fedora, but working on
others}. But perhaps it would be worthwhile leaving it to be an easy way
in for new packagers ?
DaveT.
12:16 a.m.
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.
6:47 p.m.
On 13.08.2008 02:16, Michael Schwendt wrote:
On Wed, 13 Aug 2008 08:25:12 +1000, David Timms wrote:
[...]
> 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.
I'd say it quite similar to epel style. It's just that the plan is to
have a additionally release repo (for spins and to use in anaconda
during install if you don't enable the updates repo). But those are
afaics outside the scope of the push scripts; my plan is to simply
create them with something like this
$ cp -l developemnt/<arch>/ releases/10/Everything/<arch>/os/
and maybe a few other commands.
Builds are put into "updates/testing" first and
moved to updates after some time.
Just like in EPEL, yes. But I'd say we'll have more relaxed rules and
will do those moves way more often then once a month. And I'd assume
that pushing directly to stable will happen more then just "now and then".
Whether it is built against
fedora updates-testing, I don't know. I have doubts that it is done.
I've thought about it and for the start chose to not include
updates-testing in the builders mock configs. Chances are IMHO way to
big to build against a Fedora updates-testings package and then pushing
the RPM Fusion package to stable before the Fedora testing update it was
build against hits Fedora stable.
But we of course can enable updates-testing quickly if we want to.
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. [...]
Agreed. It's likely a lot of work that is not worth the trouble.
Especially as the packagers would need to put a lot of effort and
thoughts into their work to not break things accidentally...
CU
knurd
2:47 p.m.
This is only a bit related to this thread, but has anyone approached
PlanetCCRMA to see if they are interested in joining rpmfusion? They have a
number of excellent packages/builds.
-Jeff
3:13 p.m.
2008/8/13 jeff <moe(a)blagblagblag.org>:
This is only a bit related to this thread, but has anyone approached
PlanetCCRMA to see if they are interested in joining rpmfusion? They have a
number of excellent packages/builds.
PlanetCCRMA is being integrated in Fedora:
https://fedoraproject.org/wiki/FWN/Issue103#PlanetCCRMA_Packages_For_Audi...
Bye,
Andrea.
5947
days inactive
5948
days old
rpmfusion-developers@lists.rpmfusion.org
6 comments
5 participants
participants (5)
-
Agnes Jones -
Andrea Musuruane -
jeff -
Michael Schwendt -
Thorsten Leemhuis