[PlanetCCRMA] State of Fedora 26 repo

[Fernando Lopez-Lezcano]

On 10/22/2017 01:25 AM, Yury Bulka wrote:
> Let's take SuperCollider as an example. It is included in debian main,
> so it probably wouldn't have any licensing issues with fedora.

I don't think there are any licensing issues. At some point I think 
there was a problem with boost as SC needed its own version (and Fedora 
does not like that, you have to link with existing libraries instead of 
using a different one).

(that is also true for most of the packages I still maintain)

> How the process of moving it into main fedora would look like in
> general?

You need to become a Fedora packager, and for that you need to have a 
mentor (someone who is already a packager and can review what you submit 
and make sure that it fits the packaging guidelines). Probably somebody 
in the Fedora Music mailing list would be able to help. You submit a 
package for review, it gets comments, you fix the issues, etc.

> Take the srpm, adapt it to Fedora's Packaging Guidelines [1] and submit
> to fedora?

Yup...

> Then, I guess, the person doing it would have to take the responsibility
> of maintaining the fedora package.

That is usually the case. It is a service to the community (and a way of 
paying back part of the hard work developers do when creating new 
software).

The problems I usually have with new versions of Fedora is (usually) gcc 
becoming more strict and failing to compile some package. That is what 
happened when I tried to rebuild SC 3.7.x, there was a compilation 
error. At that point you can either create or find a patch that will 
make it compile, or if there is a newer version try that. I tried to 
build 3.8.0 but I hit an error (I forget what it was) but did not have 
time to pursue it.

There's another option, if you or someone else manages to get a missing 
package to compile (basing it, for example, in the spec files already 
written for it and part of Planet CCRMA) and then do some basic testing, 
I could easily (usually) rebuild it in my build server and release it 
(with proper attribution, of course). I have been very busy with other 
projects and have had no time to debug failing builds - once a package 
builds it is relatively easy to release it.

> I could try doing it maybe, although I don't have much experience in
> packaging or C++ development. Is the knowledge of C++ absolutely
> required to be able to maintain a fedora package for SuperCollider?

Not really, just the ability to debug problems with building it, 
programming experience of course helps. Usually an internet search when 
you have problems will have suggestions that you can use. Once it builds 
then you need to do some basic testing to make sure the software works 
out of the box. I personally do not program in c++ but I'm still able to 
fix most of the problems that crop up (but then I have been doing it for 
quite a while :-).

Hope this helps,
Best,
-- Fernando


> Links:
> [1]: https://fedoraproject.org/wiki/Packaging:Guidelines
>
> Martin Tarenskeen <m.tarenskeen at zonnet.nl> writes:
>
>> On Sat, 21 Oct 2017, Yury Bulka wrote:
>>
>>> Dear all,
>>>
>>> I haven't posted here before, but after reading this list for a while
>>> I have an impression that we seem to expect too much work from a
>>> single person (Fernando) - providing -rt packages of the kernel,
>>> maintaining planeccrma repos, as well as maintaining fedora packages for
>>> supercollider and a whole bunch of other software...
>>>
>>> I'm thinking that maybe we could somehow distribute this work?
>>>
>>> For instance by trying to move *some* of the packages (like
>>> supercollider) from planetccrma to main fedora repos?
>>>
>>> How hard may that be? Is there anything about, say, supercollider, that
>>> would not allow it to be included in main fedora?
>>
>> Several packages that used to be part of PlanetCCRMA are now part of
>> the normal Fedora repos already. Due to, among others, Fedora's strict
>> licencing policy not all PlanetCCRMA packages could/can be moved to
>> Fedora though.
>>
>> Fernando does a tremendous job maintaining the PlanetCCRMA packages. I
>> totally agree that it would be great if he got some help from others.
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/planetccrma
>