On Wed, Dec 27, 2017 at 04:44:19PM +0100, David Runge wrote:
Do you have an alternative suggestion that is packageable?
It's not entirely clear to me what you understand by 'packageable'... "Packageable" would mean to ship system configuration in a way, that it can be easily used. In this specific case I am referring to the mentioned udev rule and the
On 2017-12-27 16:56:49 (+0000), Fons Adriaensen wrote: limits.conf snippet (which are already packaged, but redundantly). Additionally, when talking about a separate group to be able to map jack's specifically required settings to it, that would also be shipped (i.e. packaged).
But what I mean is this:
- If creating a 'realtime' group (and associated limits) is 'packageable', then so is creating an 'audio' group, it's just a different name. Exactly. In this case "audio" is already created by the systemd package and mainly used for alsa purposes (access to audio devices). The jack/jack2 package then installs additional files (see above) to elevate that group's permissions.
- So if either is done, I'd say the 'audio' option is the better one, because it doesn't interfere with realtime limits required by e.g. video or sdr, which may be different. That is exactly why you would not want to couple it with the audio group though, if you can have a separate group, specifically for realtime and/or jack's required settings.
So my preferred way is that groups should reflect classes of applications or activity (like audio, video,...), and not individual limits. In other words I don't really agree with your [3] which suggest using 'realtime' as the group name. Jack, or audio isn't the only application that may require realtime. What group name should the others use if Jack has already taken 'realtime' ? Which is why I am proposing a separate group, as the "audio" group is already used for access to sound devices. The group name "realtime" might be somewhat too generic though, if not aiming for an "accesss all areas" pass ;-) Something similar to "jackusers", etc. would work too.
Apart from that: There currently is no "realtime" group, so it could be used for generic settings that can be used by jack and/or other packages requiring it.
Something different which you may understand better than I do : I noticed after a recent update that the usb-modeswitch for my Huawei LTE stick didn't work anymore. I now have to do this manually in the script that starts my internet connection using wvdial. Can this be related to systemd-sysuser ? If so, what is the 'official' solution ? Sorry, but I haven't used that package in a long time, so I don't really know any specifics. AFAICS it is not relying on systemd-sysusers [1]. If something doesn't work as expected, you might want to open a bug report for it though, or look at those currently open [2].
Best, David [1] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa... [2] https://bugs.archlinux.org/task/56372?project=5&string=usb_modeswitch -- https://sleepmap.de