Bug 797418

See rpmfusion bug: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2193

Diff from rpmfsuiom

fedora16:~/rpmbuild/SPECS $ diff qtractor-rpmfusion.spec qtractor.spec 
14c14
< Release:       1%{?dist}
---
> Release:       2%{?dist}
26d25
< BuildRequires: libmad-devel
32c31,32
< BuildRequires: slv2-devel
---
> BuildRequires: suil-devel
> BuildRequires: lilv-devel
52a53
>    --enable-mad=no --enable-lilv --enable-suil \
59a61
> rm -rf %{buildroot}
87a90,92
> * Wed Feb 22 2012 Brendan Jones <brendan.jones.it> - 0.5.3-2
> - Copied from rpmfusion, add suil, lilv suppport, remove mad and slv2
> 
90,92d94
< 
< * Sun Dec 25 2011 Orcan Ogetbil <oget [DOT] fedora [AT] gmail [DOT] com> - 0.5.2-1
< - Update to 0.5.2

Hi, 
- a diff -u would be easier to read.

- Did you intend to delete Orcan's most recent changelog entry, or add an extra entry ?

- The spec could carry comments about why: eg remove mad and slv2 since they support mp3 which can't be included in Fedora.


- In the audacity-freeworld spec is currently included:
http://cvs.rpmfusion.org/viewvc/rpms/audacity-freeworld/F-17/audacity-freeworld.spec?revision=1.22&root=free&view=markup

%define realname audacity
Conflicts: %{realname}

It uses realname in place of name in the remainder of the spec.

Since both audacity and audacity-freeworld are using the same layout on disk, with the same file names, this makes sense as it ensures the user can't install both; they need to decide which one, and remove the other first. It also means that updates keep you with the one you chose.

Is that how we propose the -freeworld version to work for qtractor ?

Thanks David,

I wasn't going to provide the necessary changes for rpmfusion at first, but have now. This spec can be used for both.

I've also updated the comments.

SRPM: http://bsjones.fedorapeople.org/qtractor-0.5.3-3.fc16.src.rpm 
SPEC: http://bsjones.fedorapeople.org/qtractor.spec

Hi Brendan, David,

I know this would make you feel like a tennis ball bouncing back and forth, and I know I once made an analogy with audacity, but (in case we are also making a qtractor-freeworld package) how easy is it to make the rpmfusion package parallelly installable? From what I can tell, what need a change are:

- The binary name
- The icon name 
- The name and contents of the .desktop file so that it uses the new binary and the icon
- The .mo locale file names, and possibly we need to patch the source to use these new locale files.

Is there anything else? I am not saying that we should do it this way, please don't take this as an obligation. It is merely a brain exercise at this point.

(In reply to comment #4)
> It is merely a brain exercise at this point.
Would it be reasonable / acceptable to replace the /usr/bin/executable with a script that checks for the freeworld exec and if present runs it, otherwise runs the fedora one .. ?

(Any of this really defeats rpmfusion http://rpmfusion.org/FoundingPrinciples of add-on packages and not replacements of fedora packages.)

I sort of think conflicts make most sense:
1. either you want one or the other for whatever reason (eg fedora audio spin)
  - any use case for having both installed, having 2x exes, 2x desktop icons etc ?

2. you dont want to be upgraded between the two variants as updates are released.

ps. by the way, and from distant memory, Fedora has a guideline mentioning something a long the lines of:
adding stuff to support out of fedora packages isn't kosher (but I can't find the exact mention of this).

I can't see we you'd want them to be parallel installable unless they're fundamental differences in how they're built and/or function. Apart from the absence of mp3 read/playback the only other difference is suil/lilv support which will need to be reviewed here and whether its determined to be appropriate.

Is it difficult to rename the package in rpmfusion and if we do is the conflicts enough? (I'm thinking of the scenario where people have qtractor from rpmfusion and it is suddenly updated by the one from Fedora minus mp3? Might surprise a few people out there)

(In reply to comment #5)
> (In reply to comment #4)
> > It is merely a brain exercise at this point.
> Would it be reasonable / acceptable to replace the /usr/bin/executable with a
> script that checks for the freeworld exec and if present runs it, otherwise
> runs the fedora one .. ?
> 
> (Any of this really defeats rpmfusion http://rpmfusion.org/FoundingPrinciples
> of add-on packages and not replacements of fedora packages.)
> 

Yes, replacing Fedora packages is against the principles of RPMFusion. It can be argued that adding a "Conflicts:" effectively violates this principle.

> I sort of think conflicts make most sense:
> 1. either you want one or the other for whatever reason (eg fedora audio spin)
>   - any use case for having both installed, having 2x exes, 2x desktop icons
> etc ?
> 

Well, to be honest, I cannot think of a reason other than some convenience for us maintainers, and the above violation argument (but audacity lived this way for a long time, so I don't expect an objection should we add the Conflicts)

> 2. you dont want to be upgraded between the two variants as updates are
> released.
> 
> ps. by the way, and from distant memory, Fedora has a guideline mentioning
> something a long the lines of:
> adding stuff to support out of fedora packages isn't kosher (but I can't find
> the exact mention of this).

Hmm, I remember seeing counterexamples, however this is really not the case here. We only need to change things on the RPMFusion side. The Fedora qtractor package will not be modified in any way to accommodate the RPMFusion qtractor no matter what path we choose. 


(In reply to comment #6)
> I can't see we you'd want them to be parallel installable unless they're
> fundamental differences in how they're built and/or function. Apart from the
> absence of mp3 read/playback the only other difference is suil/lilv support
> which will need to be reviewed here and whether its determined to be
> appropriate.
> 

Hi, please see above.

> Is it difficult to rename the package in rpmfusion and if we do is the
> conflicts enough? (I'm thinking of the scenario where people have qtractor from
> rpmfusion and it is suddenly updated by the one from Fedora minus mp3? Might
> surprise a few people out there)

I don't think it is any more difficult than in Fedora. As the rules are the same, we need to retire the old qtractor and file a new review request.

Hi Brendan,
Could you update this to 0.5.4? We can then do the review.

Of course. Been running it locally here as per this build for a week or so now with no obvious issues.

SRPM: http://bsjones.fedorapeople.org/qtractor-0.5.4-1.fc16.src.rpm 
SPEC: http://bsjones.fedorapeople.org/qtractor.spec

We're still blocked on bug 783825. Thanks

suil is now available in rawhide, but the latest lilv update is blocked by new package sratom

I made a full review on this package from rpmfusion. It feels weird to review your own stuff. But anyway...

- built fine on rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4032335

- rpmlint says:
   qtractor.x86_64: W: spelling-error Summary(en_US) multi -> mulch, mufti
   qtractor.x86_64: W: spelling-error %description -l en_US multi -> mulch, mufti
   qtractor.x86_64: W: no-manual-page-for-binary qtractor
   qtractor-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/qtractor-0.5.4/src/lv2/lv2_uri_unmap.h
   qtractor-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/qtractor-0.5.4/src/lv2/lv2_event_helpers.h
   qtractor-debuginfo.x86_64: W: hidden-file-or-dir /usr/src/debug/qtractor-0.5.4/src/.moc
   qtractor-debuginfo.x86_64: W: hidden-file-or-dir /usr/src/debug/qtractor-0.5.4/src/.ui
These can be ignored.

-------------------------------------------
This package (qtractor) is APPROVED by oget
-------------------------------------------

Thanks for the review!

New Package SCM Request
=======================
Package Name: qtractor
Short Description: Audio/MIDI multi-track sequencer
Owners: bsjones
Branches: f16 f17
InitialCC:

Git done (by process-git-requests).

Orcan, please take ownership of review BZs, thanks!

Sorry, I pushed the wrong "take" button.

Hey Orcan, I have not seen anything come through from rpmfusion on qtractor-freeworld. 

Should I wait before pushing to f17?

I don't think you need to wait. Fedora's qtractor has higher version-release, so there won't be any undesired results if you push.

qtractor-0.5.4-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/qtractor-0.5.4-1.fc17

For the record, this mutilated package has replaced a fully functional qtractor provided by a known 3rd part repository. One could have avoided that by creating a qtractor-free.

I am afraid that would have violated Fedora package naming guidelines.

Um, so what's up with this? The push to f17 updates was cancelled without any apparent reason that I can see, and as it stands there's no qtractor for f17 in either rpmfusion or fedora, presumably because of this transfer-in-progress :(

Please follow:
https://lists.rpmfusion.org/pipermail/rpmfusion-developers/2012-May/012520.html
https://lists.rpmfusion.org/pipermail/rpmfusion-developers/2012-June/012735.html

Long story short, I ended up writing a patch to separate the libmad support into an optional plugin. Both the Fedora package and the RPMFusion plugin package need to use this patch. I am guessing, at some point, Brendan will submit a freeworld package review at RPMFusion with my patch. Until then, please use the either RPMFusion's qtractor or the SRPM above.

The problem is that for F17, there's no qtractor in RPMFusion either. Its not much of an issue for me personally (already rolled my own) but that might be quite a hurdle for a less hacking-oriented musician. Seems like the attempted cross-repo coordination ended up only hurting everybody (for the short term) :-/

Anyway, big kudos to you Orcan for working on modularizing the libmad part, that path really is a win-win situation for everybody. I'll try to give your patch a bit of testing in hopes of getting this situation resolved soon.

I will sort this out on Monaday. Apologies, have been extremely busy these last few weeks. Preliminary tests on Orcans patch look fine (thanks!)

I'm unsure why you think qtractor is not available in rpmfusion? I can see it fine (0.5.3) albeit not the latest version

qtractor-0.5.5-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/qtractor-0.5.5-1.fc18

qtractor-0.5.5-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/qtractor-0.5.5-1.fc17

Package qtractor-0.5.5-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing qtractor-0.5.5-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-13206/qtractor-0.5.5-1.fc18
then log in and leave karma (feedback).

qtractor-0.5.5-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

qtractor-0.5.5-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.