[PlanetCCRMA] Problem with qjackctl in Fedora 14

[Orcan Ogetbil]

On Thu, Dec 30, 2010 at 1:17 PM, Fernando Lopez-Lezcano wrote:
> On 12/30/2010 09:59 AM, Orcan Ogetbil wrote:
>>
>> Hello all,
>>
>> Sorry I have been busy lately with real life and my upstream projects,
>> and I didn't spend much time on packaging lately (except I built the
>> new qjackctl-0.3.7 recently). I hope you figured things out by now.
>>
>> On Thu, Dec 30, 2010 at 7:15 AM, Oded Ben-Tal wrote:
>>>>
>>>> You can add this file (name it "90-jack.conf") to the
>>>> /etc/security/limits.d/:
>>>>
>>>> ---- CUT HERE
>>>> # Planet CCRMA, jack-audio-connection-kit
>>>> #
>>>> # Allow processes access to rt priority and memory locking
>>>> # without limits, needed by the rt kernel and jackd
>>>> *     -       rtprio  99
>>>> *     -       memlock 4194304
>>>
>>> Possibly silly questions. Perhaps because I upgraded from an earlier
>>> version I have two files in /etc/security/limits.d/
>>> 90-nproc.conf  99-jack.con
>>>
>>
>> Typo? It should be 99-jack.conf. Otherwise pam won't read it.
>>
>>> questions:
>>> 1) do the number matter (i.e. is it important that the jack one is 90)?
>>>
>>
>> The documentation says: "The files are parsed one after another in the
>> order of "C" locale."
>>
>> That means 99 beats 90. Unfortunately, I did set the conf file that
>> comes with jack to 99. I was probably assuming the other way around.
>> Should I pull that number down in the jack package so the
>> corresponding PlanetCCRMA package can override?
>
> It would be nice to have that option, 99 precludes anyone else from changing
> the priority (I had not noticed that).
>
>> Of course, you can
>> give RT priorities to all users, then 99-jack.conf file won't do
>> anything. But this would be insecure, right?
>
> Yes, it would open the door to denial of service attacks, for example. But
> for a "normal" audio workstation with trusted users that would be of little
> consequence (others surely will disagree).
>
> I have to see what I can do to change things in the rt patched kernel and
> rtirq so that it is possible to use it with the reduced (arbitrary) priority
> of 20.
>

Let me know what comes out. I might get yelled at if I update the F-14
jack package just with this change, because of these new updates
policies. Is there any other fixes, patches that I can throw in and
that would be nice to have?

By the way I am glad that our utsname.version "PREEMPT RT" hack works
for everyone.

Orcan