On 12/02/2012 10:11 PM, Christoph Wickert wrote:
Hi Brendan, hi Jorn,
sorry again for the late reply.
Am Samstag, den 01.12.2012, 20:04 +0100 schrieb Brendan Jones:
- we have added a kernel boot parameter 'threadirqs' - prerequisite of
the rtirq package to prioritize software IRQs (very useful for dealing with latency of audio devices)
This is controversial, but I see nothing wrong with it. As long as there is no guideline that explicitly forbids it, I am willing to allow it.
- we have packaged out own background and our own KDE theme. The
background is simply the Spherical Cow them with a wave form superimposed (fedora-jam-backgrounds).
- we have packaged our own KDE theme - this has spherical cow as a
direct dependency and is only required so we can use the background image by default (for the desktop and splash) The package is fedora-jam-kde-theme
As long as everything is packaged, I see nothing wrong with it. This being said I would rather like to have the files you add to /etc/skel/.kde/ in %post as part of a package. I am not a KDE user, so I don't know if it is possible or would it collide with other packages.
I cannot see any other package owning these files, so I can add them to fedora-jam-kde-theme.
- you can see the hack where we've made the logged in user a member of
the audio group by default. This is required by jack-audio-connection-kit - it prioritizes processes running under this group. Again very improtant for latency issues.
I see your point, but the modifications to /usr/share/firstboot/modules/create_user.py are a no-go. You need to move the sed commands to the livesys init script, so the changes will only be applied to the live system but not to the installed packages. Even this is controversial (think of translations), but again as long as it not explicitly forbidden, I'll turn a blind eye to it.
Is there a right way to do this? I tried to find one but I couldn't see an option in kickstart to make this happen. I could probably provide a patch to firstboot (I think this would be really useful) but obviously it will be too late for this release. Or is this something which should go into pam or somewhere else?
Alternatively we could add this to %post in jack-audio-connection-kit but I'm not sure if this is considered safe in a critical-path package
jack-audio-connection-kit packages a limits.d/ file to do this
No problem, everything form a package is fine.
anyway - the rest is a stock standard KDE kickstart - we haven't even deleted any packages.
You probably should to save some space. I doubt that musicians are interested in all the stuff KDE offers and be eliminating everything irrelevant applications, , you could in fact shift the focus more to music. But that's up to you.
Anyway, please keep me updated.
I have just approved your ks and wiki page. Please make the modifications to the ks ASAP.
Next steps: 1. Get the ks into the nightlies 2. Get the ks into the spins-kickstart package. Fortunately the deadline is 2012-12-11. 3. Call for a meeting of the spins SIG for approval 4. Get board approval 5. I will add this to the board meeting agenda on Wednesday.
I have to apologize to the two of you. I am incredibly busy with my dayjob and have failed horribly as a spins wrangler, but I am trying my best to get your spin in F18.
Thankyou! Hopefully all the changes you've requested should be done by Wednesday.
I think the notifications system in the wiki is suspect and is probably something that needs attention. I should raise a ticket
regards,
Brendan
Some thoughts in case they're useful:
On 4 December 2012 07:29, Brendan Jones brendan.jones.it@gmail.com wrote:
On 12/02/2012 10:11 PM, Christoph Wickert wrote:
Am Samstag, den 01.12.2012, 20:04 +0100 schrieb Brendan Jones:
- we have added a kernel boot parameter 'threadirqs' - prerequisite of
the rtirq package to prioritize software IRQs (very useful for dealing with latency of audio devices)
This is controversial, but I see nothing wrong with it. As long as there is no guideline that explicitly forbids it, I am willing to allow it.
- we have packaged out own background and our own KDE theme. The
background is simply the Spherical Cow them with a wave form superimposed (fedora-jam-backgrounds).
- we have packaged our own KDE theme - this has spherical cow as a
direct dependency and is only required so we can use the background image by default (for the desktop and splash) The package is fedora-jam-kde-theme
As long as everything is packaged, I see nothing wrong with it. This being said I would rather like to have the files you add to /etc/skel/.kde/ in %post as part of a package. I am not a KDE user, so I don't know if it is possible or would it collide with other packages.
I cannot see any other package owning these files, so I can add them to fedora-jam-kde-theme.
I think that might be a solution, alternatively a sub-package (...-theme-default) could deliver them, the theme package is single-use enough that it probably doesn't matter either way. But I wonder:
- you can see the hack where we've made the logged in user a member of
the audio group by default. This is required by jack-audio-connection-kit - it prioritizes processes running under this group. Again very improtant for latency issues.
I see your point, but the modifications to /usr/share/firstboot/modules/create_user.py are a no-go. You need to move the sed commands to the livesys init script, so the changes will only be applied to the live system but not to the installed packages. Even this is controversial (think of translations), but again as long as it not explicitly forbidden, I'll turn a blind eye to it.
Is there a right way to do this? I tried to find one but I couldn't see an option in kickstart to make this happen. I could probably provide a patch to firstboot (I think this would be really useful) but obviously it will be too late for this release. Or is this something which should go into pam or somewhere else?
Alternatively we could add this to %post in jack-audio-connection-kit but I'm not sure if this is considered safe in a critical-path package
Again maybe a sub-package to jack could do this, so it's not on critical path but could be added to the .ks? There are actually two changes, one is in /etc/rc.d/init.d/livesys which is already done and makes the change for the live system, it sounds like that's okay. The other is the install one, I'm not sure I understand the exact implications of Christoph's request: is it the case that we will get away with doing those sed against create_user.py on the live system and does create_user get run from the live system during install or from the installed system?