Am 01.12.2012 20:45, schrieb Dave Reisner:

While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).

I'd still like to know the history of why this was split in the first place, and not just optdep'd...

IIRC, optdep didn't exist when this was split.

On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote:

While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).

Please don't fix that file, but just kill it. It's the xinitrc.d file right? Nowadays dbus autoloads itself, and for situations where dbus still needs to be launched by hand, you don't want to do that from a weird scriptlet but straight from ~/.xinitrc. I removed the file from my system a while ago, haven't seen any of the problems that it tried to solve in the past.

On Mon, Dec 3, 2012 at 11:55 AM, Dave Reisner wrote:

On Mon, Dec 03, 2012 at 10:07:06AM +0100, Jan de Groot wrote:

...

On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote:

...

While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).

Please don't fix that file, but just kill it. It's the xinitrc.d file right? Nowadays dbus autoloads itself, and for situations where dbus still needs to be launched by hand, you don't want to do that from a weird scriptlet but straight from ~/.xinitrc. I removed the file from my system a while ago, haven't seen any of the problems that it tried to solve in the past.

Good point, actually. I've been doing the same myself.

$ grep NoExtract /etc/pacman.conf NoExtract = etc/X11/xinit/xinitrc.d/30-dbus

For the record: removing this file caused some issues, so I reinstated it. I expect it will all become redundant in the not too distant future (due to systemd --user), but let's just leave it alone for now. -t

On 03/12/12 21:34, Tom Gundersen wrote:

On Mon, Dec 3, 2012 at 10:07 AM, Jan de Groot wrote:

...

On za, 2012-12-01 at 14:45 -0500, Dave Reisner wrote:

...

While we're touching the PKGBUILD, why do we "fix" the configuration file in the package function? Would be nice if we could cleanup the 30-dbus file as well to simply use shell builtins rather than an external (yes, 'which' is in base, but it bothers me).

Please don't fix that file, but just kill it. It's the xinitrc.d file right? Nowadays dbus autoloads itself, and for situations where dbus still needs to be launched by hand, you don't want to do that from a weird scriptlet but straight from ~/.xinitrc. I removed the file from my system a while ago, haven't seen any of the problems that it tried to solve in the past.

I'll make this and the other changes and push to testing.

Some fun here... (1/1) removing dbus-core [######################] 100% userdel: user dbus is currently used by process 336 groupdel: cannot remove the primary group of user 'dbus' error: command failed to execute correctly Obviously nothing to be concerned about...

On Dec 3, 2012 7:06 AM, "Tom Gundersen" wrote:

On Mon, Dec 3, 2012 at 12:57 PM, Allan McRae wrote:

...

Some fun here...

(1/1) removing dbus-core [######################] 100% userdel: user dbus is currently used by process 336 groupdel: cannot remove the primary group of user 'dbus' error: command failed to execute correctly

Obviously nothing to be concerned about...

Oh, nice... I don't know why I didn't get that message.

Anyway, it is not a problem. If for some reason the removal should work, then the user/group will be added back immediately by the dbus upgrade.

Any suggestions on how these messages can be avoided?

-t

I do hate our filesystem upgrades since /sys was made RO and pacman tries to remove it, but perhaps we should move the dbus user there. I think as a general rule, packages in [core] should probably avoid creating users and groups to avoid problems we've seen recently.

On Dec 3, 2012 2:43 PM, "Jan de Groot" wrote:

On ma, 2012-12-03 at 13:05 +0100, Tom Gundersen wrote:

...

Any suggestions on how these messages can be avoided?

You can't, unless you push an update for dbus-core first...

There is no way to enforce that people update dbus-core first, so I think we'll just have to live with the warning. To make sure this is the last time this happens, I'll move the user/group to filesystem as Dave suggested. Cheers, Tom