On 12/04/2012 01:46 PM, Christoph Wickert wrote:
> Am Dienstag, den 04.12.2012, 08:29 +0100 schrieb Brendan Jones:
>> On 12/02/2012 10:11 PM, Christoph Wickert wrote:
>>> 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?
> Hi Brendan,
> I'm afraid there is no really right way unless it gets configurable in
>> 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.
> It's definitely too late for this release and I doubt such a patch would
> be accepted as it has no use case outside this spin.
>> Or is this something which should
>> go into pam or somewhere else?
> How would you do this in pam?
>> 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
> It is not considered safe in *any* package. You must not own or modify
> files that are owned by another package (unless of course your package
> is a configuration utility and the file in question is a config file)
> and if you absolutely have to, you have to do it in the inscript so that
> the changes only apply to the live system but don't end up on the
> installed system.
I meant creating the group in %post (not editing a file owned by
firstboot). But the problem of assigning group membership still remains.
Alternatively, we could package something which gets kicked off via
xdg/autostart that could detect this and request sudo priveledges to add
the X user to the group. All really messy and too late now.
There is a package realTimeConfigQuickScan which potentially could be
kicked off at start, but having it persist post first log in is really
So yes, we have two problems to solve here the liveuser and the
installed user. liveuser is OK - the installed user is not. How do other
packages handle this? How can a package know to give a particular user
group membership? I can't see a way out of this without user intervention.
For F19 I will submit the firtboot patch based on the config file and
see if I can make a good case for it.
If we do make changes to packages to fix these issues (not specifically
this issue), how can we ensure that the updates are part of the final
buildroot (and not only in updates)
On 5 December 2012 14:45, Christoph Wickert <cwickert(a)fedoraproject.org> wrote:
> Am Mittwoch, den 05.12.2012, 14:16 +0000 schrieb Ian Malone:
>> The general question of how a spin might be customised while still
>> staying within Fedora is perhaps something that needs to go to the
>> devel list.
> I agree, but this is more of a policy question. We had this topic
> already with other spins but most of the time we made exceptions (or
> not) and never really updated the policies. It's too late for this now
I was hoping it might produce some creative ideas, but it sounds like
that grounds already been covered then.
>> I do wonder if there's a systemd / seat based solution to this, will
>> raise that on the devel list.
> I think it's more of a polkit thing. If we only need to execute
> application foo with privileges of user/group bar, we could just ship a
> configuration file that allows users to run this application through
> Bug again, I need more info in order to help you.
Okay, I think Brendan has answered the 'why'. I suspect what we need
to do is check what needs access to those groups. For real-time
privileges it may be that the plugins working with jack need them, or
it might be that just jack does. I'm not sure either what access the
audio group is used for, I think for Jack it may be priorities rather
than just the old purpose of access to audio devices (which pulse for
example now solves through the seat idea afaik). Will check the limits
file Brendan mentions when I get time.
On 12/05/2012 03:41 PM, Christoph Wickert wrote:
> Am Mittwoch, den 05.12.2012, 11:32 +0100 schrieb Brendan Jones:
>> I meant creating the group in %post (not editing a file owned by
> Sorry, now I am lost.
> What group, 'audio' or 'jackuser'? How are these groups created, what
> privileges do they have and are privileges assigned to these groups?
> AFAIK jackuser is created by the jack-audio-connection-kit package, but
> what about audio? What is the reason for this group anyway?
Basically processes run with this group are subject to priority
escalation as described by limits.d file in the
jack-audio-connection-kit package. This is a real concern for audio
users. Another use case for a firstboot patch is the pulse-rt group,
although I'm unsure of the implications.
>> But the problem of assigning group membership still remains.
> Right, but it will continue to remain even with this modification,
> because we only "fix" the very first user that gets created, but not
> subsequent ones.
>> Alternatively, we could package something which gets kicked off via
>> xdg/autostart that could detect this and request sudo priveledges to add
>> the X user to the group.
> That won't help either. Autostart is executed after a user logs in. If
> he then is added to a group, he'd need to log in again to allow all
> running applications picking up the change.
>> All really messy and too late now.
>> There is a package realTimeConfigQuickScan which potentially could be
>> kicked off at start, but having it persist post first log in is really
> What exactly does this package do? I am really trying to help you but in
> order to do so, I need more info. What privileges do we need, what
> applications do we need to run or what devices to access?
It basically is a check to see if the logged in user can do all it needs
for "optimal" audio. By itself it does nothing, does not even need root
privileges to do these checks
>> So yes, we have two problems to solve here the liveuser and the
>> installed user. liveuser is OK - the installed user is not. How do other
>> packages handle this? How can a package know to give a particular user
>> group membership? I can't see a way out of this without user intervention.
> I don't think we have a way to add users to a group, at least not on a
> packaging level. We don't even seem to be able to do this on the
> commandline as /etc/default/useradd can only configure the default group
> but not additional default groups.
Short of adding every user to said package, I agree (and think that is
no solution). I think you an Ian may have something with the seat/polkit
>> For F19 I will submit the firtboot patch based on the config file and
>> see if I can make a good case for it.
> There is not much use if it is not configurable. I'm afraid that more
> people will then come with requests for one or the other group.
> Hardcoding groups in firstboot does not fly.
Sorry, perhaps I wasn't clear. Something like groups=... in the
firstboot config file, a programmatic solution rather than our hack.
On 12/04/2012 01:46 PM, Christoph Wickert wrote:
> But now I realize the problem: We are modifying firstboot and not
> anaconda, so we need the change on the installed system, at least at the
> very first boot after installation. Correct?
Yes - there are two really important points to consider (correct me if
I' wrong here team) everything else can go by the wayside #1 is audio
group membership, number #2 is threadirqs
A VERY nice to have is the themeing because artists tend to be a select
bunch and first impressions count for something. Without the themeing I
guess the kickstart is ready. I can't see why adding the /etc/skel stuff
to a package helps anyone. If anything it adds unexpected config changes...
There will be a short meeting tonight on IRC (#fedora-audio on freenode)
at 23.00 UTC. I will create and add to the agenda on the wiki
throughout the day. Anyone can add to it if the want too. I'm sorry for
the short notice, but hopefully as many as possible can make it.
If there are any questions, don't hesitate to take contact :D
Nestleder Studentutvalget NT-Fak
CS Student University of Tromsø
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
> 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
I cannot see any other package owning these files, so I can add them to
>> - 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
I think the notifications system in the wiki is suspect and is probably
something that needs attention. I should raise a ticket