Hi! The issue is quite simple: With xserver-1.8, hal isn't necessary anymore and is considered deprecated. I did a fresh install on my laptop (2-3 days ago) and left out hal as it wasn't needed by any program. But I became error messages of dbus as the plugdev group was non-existant [due to hal being never installed, the group is created right at the beginning of the hal merge]. I think it would be wise to check in the dbus ebuild if the plugdev group is existant and to create it - or maybe better in udev. Reproducible: Always
Presumably, every ebuild that uses the plugdev group (for something other than allowing access to hal policy) needs to create it itself. That's not a hal bug, that's a bug in other packages.
I think it would be best to create the plugdev user in udev or udisk/upower and cie (best place imho is udev).
(In reply to comment #1) > Presumably, every ebuild that uses the plugdev group (for something other than > allowing access to hal policy) needs to create it itself. That's not a hal > bug, that's a bug in other packages. > Exactly, for example: /etc/udev/rules.d/70-libgphoto2.rules:ATTRS{idVendor}=="04fc", ATTRS{idProduct}=="504b", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary", GROUP="plugdev" So we have: libgphoto2-2.4.9.ebuild: enewgroup plugdev Ie. It should be in the packages making use of it. I suggest to close this bug as NEEDINFO -> Point out the package using plugdev group, but not creating it.
I don't believe there's a problem with multiple ebuilds creating it, so add it to udev, by all means.
I've hit this issue before in a new box I was purposely trying to avoid having to install hal. Unless someone has any information about udev being planned to be deprecated, I'd suggest moving the creation of the plugdev group to udev and removing it from hal.
hello @udev maintainers, would you please read this bug report and give us your opinion on moving plugdev creation to udev ebuild ? Otherwise, we would have to move it to each ebuild using it.
I don't agree with udev creating the plugdev group, it should be created by the applications that need it like most already does The group is generally useless with modern systems using PolicyKit (including all the major desktops we have) Should be closed as INVALID/NOTABUG -> Bug in the applications needing it, but missing enewgroup
agreed, this is what I ended up doing with gnome-bluetooth.
