world/bluez-dinit 20211026-3 20250815-1 0.00 MiB
system/dbus-dinit 20240610-2 20250815-3 0.00 MiB
system/dinit 0.19.4-1 0.19.4-6 0.00 MiB
system/dinit-base 0.19.4-1 0.19.4-6 0.00 MiB
system/dinit-rc 0.5.0-1 0.6.0-3 0.00 MiB
system/dinit-user-spawn 1.0.0-5 0.08 MiB
system/python 3.13.5-1 3.13.6-1 0.01 MiB
world/tomlplusplus 3.4.0-1 0.85 MiB
Total Installed Size: 69.02 MiB
Net Upgrade Size: 0.95 MiB
:: Proceed with installation? [Y/n]
(8/8) checking keys in keyring [----------------------------------------------] 100%
(8/8) checking package integrity [----------------------------------------------] 100%
(8/8) loading package files [----------------------------------------------] 100%
(8/8) checking for file conflicts [----------------------------------------------] 100%
error: failed to commit transaction (conflicting files)
dinit-rc: /etc/rc.local exists in filesystem (owned by artix-branding-base)
Errors occurred, no packages were upgraded.
-> error installing repo packages
i post b/c i don't want to break my system applying the fix i think should work
I'm getting a dependency error which cannot be addressed unless the source packages are reconciled and re-released:
error: failed to commit transaction (conflicting files)
dinit-rc: /etc/rc.local exists in filesystem (owned by artix-branding-base)
Errors occurred, no packages were upgraded.
Plus this new dinit-user-spawn messes all up.
Dinit fucked, cannot start linux anymore.
Some error like
Couldn't load service loginready
Remove the branding package.
I added a default rc.local & rc.shutdown since they were in the backup array.
Nope it does not.
If you are one of the people who refuse dbus, this might be a problem on your end.
All user-spawn does is install the binary and the associated service enabled by hook.
No actual user services are started or enabled, that is user business, eg dbus .
I have no problems with dbus, elogind, etc. I'm not using login managers though.
As i said in another subject - it takes forever to load dinit-user-spawn service if using auto startx from .profile.
And what's the reasoning behind using it by default anyway?
Thats not the problem of a new dependency installed frankly.
Do you run a dbus user service?
The only unknown is how turnstile and dinit-user-spawn behave together.
If in doubt, remove and disable turnstile.
I don't have to justify development decisions, but reasoning is that dinit-user-spawn fills a gap required for increasingly desktop related user services .
It is much better than turnstile, since low level and it does precisely what it is supposed to do, limited scope well done.
Turnstile has a different scope, more aiming to replace logind, and it is experimental and not included in a default artix install.
Yes, I run dbus user service and don't use turnstile.
When I manualy startx from tty dinit-user-spawn works fine. It loads the service itself as well as user service instances (dbus, mpd, transmission). But it takes several minutes to load the service with startx from .bash_profile. That's the problem.
I've tested turnstile the same way - no problems.
A possible problem I see, user-spawn isn't a direct replacement of turnstile.
Both coexisting might lead to unknown side effects, since turnstile does the user service thingy too.
I just wasn't gonna hard block turnstile.
Chiming in to say that I've also had problems following the dinit upgrade. First was on my desktop similar to OP where the upgrade would throw an error, I rm'd
rc.local and I could continue with the upgrade.
Now on my laptop, after upgrading dinit, it wouldn't boot into the system because the rclocal service was missing all of a sudden. I also solved this by just manually creating the service:
type = scripted
command = /usr/lib/dinit/rclocal
depends-on = local.target
Hopefully this helps others.
I don't use turnstile at all, I've just tested these 2 utils separately from each other.
This worked for me, thanks.
Is there going to be a release of a new set of packages that will include all the correct dependencies without requiring fiddling with files ?
I'm asking because I have not yet run the update - I need to be sure I will not break the system.
If it is not possible to fix all dependencies by pushing new packages, at least can we have a clear procedure (i.e. install X, remove Y, modify Z) ?
Thank you for your efforts !
I had this recently, just find the service file that uses that line (waits-for = loginready) and either uncomment or remove and it should all work fine. For me it was the mullvad-daemon service file in /etc/dinit.d
@[email protected]
sudo pacman -R artix-branding-base
checking dependencies...
Package (1) Old Version Net Change
artix-branding-base 20250720-1 -0.01 MiB
Total Removed Size: 0.01 MiB
:: Do you want to remove these packages? [Y/n]
:: Processing package changes...
(1/1) removing artix-branding-base [----------------------------------------------] 100%
$ yay -Syu
:: Synchronizing package databases...
system is up to date
world is up to date
galaxy is up to date
lib32 is up to date
omniverse is up to date
extra is up to date
multilib is up to date
:: Searching AUR for updates...
:: Searching databases for updates...
:: 9 packages to upgrade/install.
9 system/dbus-dinit 20240610-2 -> 20250815-3
8 system/dinit 0.19.4-1 -> 0.19.4-6
7 system/dinit-base 0.19.4-1 -> 0.19.4-6
6 system/dinit-rc 0.5.0-1 -> 0.6.0-3
5 system/python 3.13.5-1 -> 3.13.6-1
4 world/bluez-dinit 20211026-3 -> 20250815-1
3 world/librsvg 2:2.60.0-2 -> 2:2.61.0-1
2 aur/libpamac-flatpak 1:11.7.2-1 -> 1:11.7.3-1
1 aur/pamac-flatpak 11.7.2-1 -> 11.7.2-2
==> Packages to exclude: (eg: "1 2 3", "1-3", "^4" or repo name)
-> Excluding packages may cause partial upgrades and break systems
==> 1 2
Sync Dependency (6): dinit-0.19.4-6, dinit-base-0.19.4-6, dinit-rc-0.6.0-3, librsvg-2:2.61.0-1, python-3.13.6-1, dbus-dinit-20250815-3
Sync Explicit (1): bluez-dinit-20250815-1
:: Synchronizing package databases...
system is up to date
world is up to date
galaxy is up to date
lib32 is up to date
omniverse is up to date
extra is up to date
multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Package (9) Old Version New Version Net Change
world/bluez-dinit 20211026-3 20250815-1 0.00 MiB
system/dbus-dinit 20240610-2 20250815-3 0.00 MiB
system/dinit 0.19.4-1 0.19.4-6 0.00 MiB
system/dinit-base 0.19.4-1 0.19.4-6 0.00 MiB
system/dinit-rc 0.5.0-1 0.6.0-3 0.00 MiB
system/dinit-user-spawn 1.0.0-5 0.08 MiB
world/librsvg 2:2.60.0-2 2:2.61.0-1 0.01 MiB
system/python 3.13.5-1 3.13.6-1 0.01 MiB
world/tomlplusplus 3.4.0-1 0.85 MiB
Total Installed Size: 79.68 MiB
Net Upgrade Size: 0.96 MiB
:: Proceed with installation? [Y/n]
(9/9) checking keys in keyring [----------------------------------------------] 100%
(9/9) checking package integrity [----------------------------------------------] 100%
(9/9) loading package files [----------------------------------------------] 100%
(9/9) checking for file conflicts [----------------------------------------------] 100%
(9/9) checking available disk space [----------------------------------------------] 100%
:: Processing package changes...
(1/9) upgrading dinit-base [----------------------------------------------] 100%
(2/9) installing tomlplusplus [----------------------------------------------] 100%
(3/9) installing dinit-user-spawn [----------------------------------------------] 100%
(4/9) upgrading dinit-rc [----------------------------------------------] 100%
warning: /etc/rc.shutdown installed as /etc/rc.shutdown.pacnew
(5/9) upgrading dinit [----------------------------------------------] 100%
(6/9) upgrading dbus-dinit [----------------------------------------------] 100%
(7/9) upgrading bluez-dinit [----------------------------------------------] 100%
(8/9) upgrading librsvg [----------------------------------------------] 100%
(9/9) upgrading python [----------------------------------------------] 100%
:: Running post-transaction hooks...
(1/7) Creating temporary files...
(2/7) Applying kernel sysctl settings...
(3/7) Setting init symlink ...
==> Activated dinit-init
(4/7) Displaying dinit service help ...
==> Add a service:
# dinitctl enable <service>
==> Start/stop/restart a service:
dinitctl <start/stop/restart> <service>
(5/7) Displaying dinit user service help ...
==> Add a user service:
$ dinitctl enable <service>
==> Start/stop/restart a service:
dinitctl <start/stop/restart> <service>
(6/7) Enabling dinit user spawn ...
Service 'dinit-user-spawn' has been enabled.
Service 'dinit-user-spawn' started.
(7/7) Probing GDK-Pixbuf loader modules...
Just as
@artoo said remove artix-branding-base and rerun update
OFC artix-branding-base does not reinstall now though. ;)
sudo pacman -S artix-branding-base
resolving dependencies...
looking for conflicting packages...
Package (1) New Version Net Change
world/artix-branding-base 20250720-1 0.01 MiB
Total Installed Size: 0.01 MiB
:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring [----------------------------------------------] 100%
(1/1) checking package integrity [----------------------------------------------] 100%
(1/1) loading package files [----------------------------------------------] 100%
(1/1) checking for file conflicts [----------------------------------------------] 100%
error: failed to commit transaction (conflicting files)
artix-branding-base: /etc/rc.local exists in filesystem (owned by dinit-rc)
Errors occurred, no packages were upgraded.
can i live without artix-branding-base for a minute?
@artoo
There is a temporary fix for branding base package by now.
But absolutely, the branding package is non essential, more iso related, can be removed.
What is dinit-user-spawn for? I haven't missed it. Do I really need it? Or can I just disable it? I startx from .bash_profile, as someone above had problems with.
I just ran
pacman -Syyu (I refrained from making any changes on the system since the first post this morning); there was no longer a conflict related to
/etc/rc.local (so I did not need to remove
artix-branding-base after all); I rebooted and the system has started without any glitch.
Here is the list of currently running services after opening my KDE session:
# dinitctl list
[[+] ] boot
[{+} ] system
[{+} ] login.target (has console)
[{+} ] local.target
[{+} ] pre-local.target
[{+} ] early-fs-local.target
[{+} ] early-fs-pre.target
[{+} ] early-devices.target
[{+} ] udevd-early
[{+} ] early-prepare.target
[{+} ] root-ro
[{+} ] pseudofs
[{+} ] cgroups
[{+} ] tmpfs
[{+} ] kmod-static-nodes
[{+} ] tmpfiles-dev
[{+} ] udev-settle
[{+} ] udev-trigger
[{+} ] early-root-rw.target
[{+} ] fsck-root
[{+} ] early-fs-fstab.target
[{+} ] fsck
[{+} ] early-console.target
[{+} ] early-keyboard.target
[{+} ] net-lo
[{+} ] hostname
[{+} ] swap
[{+} ] random-seed
[{+} ] early-modules.target
[{+} ] modules
[{+} ] sysctl
[{+} ] binfmt
[{+} ] hwclock
[{+} ] locale
[{+} ] tmpfiles-setup
[{+} ] sysusers
[{+} ] cleanup
[{+} ] network.target
[{+} ] pre-network.target
[{+} ] agetty
[{+} ] udevd (pid: 960)
[{+} ] ufw
[{+} ] acpid (pid: 1064)
[{+} ] ntpd-rs (pid: 1327)
[{+} ] ntpd-rs-pre
[{+} ] fwupd (pid: 1082)
[{+} ] dbus (pid: 1073)
[{+} ] dbus-pre
[{+} ] sddm (pid: 1254)
[{+} ] cupsd (pid: 1081)
[{+} ] colord (pid: 1080)
[{+} ] colord-pre
[{+} ] technitium-dns-server (pid: 1326)
[{+} ] power-profiles-daemon (pid: 1079)
[{+} ] bluetoothd (pid: 1078)
[{+} ] syslog-ng (pid: 1039)
[{+} ] pcscd (pid: 1077)
[{+} ] NetworkManager (pid: 1325)
[{+} ] cronie (pid: 1060)
[{+} ] metalog (pid: 1059)
[{+} ] logind
[{+} ] elogind (pid: 1076)
[{+} ] sddm-pre
[{+} ] fuse
[ {-}] colord-session (exit status: 0)
[{+} ] getty@tty1 (pid: 1286)
[{+} ] getty@tty2 (pid: 1292)
[{+} ] getty@tty3 (pid: 1287)
[{+} ] getty@tty4 (pid: 1288)
[{+} ] getty@tty5 (pid: 1289)
[{+} ] getty@tty6 (pid: 1291)
I find now in /etc the following files related to
rc.local :
-rwxr-xr-x 1 root root 93 20 juil. 16:18 rc.local
-rwxr-xr-x 1 root root 11 15 août 15:00 rc.local.pacnew
-rwxr-xr-x 1 root root 93 20 juil. 22:13 rc.local.pacsave-latest
Thank you for fixing the conflict between the packages!
FWIW, i like your choice and the reasoning for it. TY!
$ dinitctl list
[[+] ] boot
[{+} ] wireplumber (pid: 816)
[{+} ] pipewire (pid: 814)
[{+} ] dbus (pid: 797)
[{+} ] pipewire-pulse (pid: 815)
Makes desktop users happy, since sound works with this eg in plasma.
So this part I figured out, ly service (ly-dm) depends on loginready (which, after upgrade, disappeared). In order to be able to boot I commented out "
depends-on = loginready" in /etc/dinit.d/ly the result being that ly service doesn't work anymore.
Can the developers provide a solution for fixing ly service, please?
Looking at a few commits (https://gitea.artixlinux.org/artix/dinit-rc/commit/67bc745a4d63878c32afab9b0ab4525b5505a48a#diff-df8f5373975e53e674529284906cc1812c35ac7a) for the
dinit-rc package,
loginready was already a deprecated stand-in for what is now
login.target. I assume then that all you'd have to do is replace the former with the latter in the service definition for
ly.
Thanks for replying but that didn't fix it, /etc/dinit.d/ly needs more configuration which I don't know how to do...
For some weird reason
ly started to work although I'm sure I've tried these settings before with no result. In case it might help others:
/etc/dinit.d/config/console.conf
ACTIVE_CONSOLES="/dev/tty[2-6]"
/etc/dinit.d/ly
type = process
restart = true
smooth-recovery = true
command = /usr/bin/ly-dm
depends-on = login.target
termsignal = HUP
options = shares-console
In /etc/ly/config.ini
# TTY in use
tty = 1
Good evening, you can set minimal_environment_handling = true in the configuration file (~/.config/dinit.d/config/dinit-user-spawn.toml), in your configuration file to prevent dinit-user-spawn from inheriting environment variables from your user. dinit-user-spawn runs "su - youusername -c 'env'" in order to get environment variables it should inherit (I assume the env command hangs since it tries to get your env vars from eg. your bash profile), since some services that end-users may write may expect some of those env vars (although they should be using the environment file option in the dinit service they're writing themself). I could change the default to enable minimal_environment_handling = true in future, if requested by others. The reason I enabled it by default is that it more closely mirrors launching dinit manually yourself since that would inherit your environment, but since this isn't really intended behaviour by dinit as they have their own option in services for environment files, perhaps it is best it is minimal_environment_handling is set to true by default.
Beyond that, dinit-user-spawn doesn't really interact with anything else and it just launches dinit for users who have logged in (and cleans it up when requested to), and is hands off after that
Hi.
Yes, changing this option to "true" was the first thing I tried and it did work well for dinit-user-spawn itself, but some services didn't start.
Now it's clear that these services indeed use some vars.
I guess mpd uses $XDG_CONFIG_HOME by default, which isn't inherited with minimal_environment_handling = true.
Yeah, even with minimal_environment_handling disabled only environment variables (usually those that aren't set at runtime), that can be found by running the "su - youusername -c 'env'" command will be set. I considered adding an option in the configuration file to set arbitrary env vars (eg. env_vars = [["key", "value"], ["key2", "value2"]]), but I ultimately decided it wasn't the best idea as dinit services already have a built in method of taking in env vars (https://davmac.org/projects/dinit/man-pages-html/dinit-service.5.html#env), and hence it is replicating existing functionality of upstream and best not to do to avoid scope creep and just functionality duplication (which the existing minimal_environment_handling = false already is since you can provide env vars the dinit way as mentioned, but since it is already implemented not much point removing it).
This all being said, I will look into updating the default configuration to set minimal_environment_handling = true, and to also specify a default environment file in the dinit.d directory, so users will automatically have https://davmac.org/projects/dinit/man-pages-html/dinit.8.html#e. It seems to me that this is the previous way of doing such as I see on the wiki, and hence i'll keep it to the same pattern, but first i'll discuss with artix developers on the IRC.
As of dinit-rc-0.6.4, dinit-user-spawn-1.0.0-9, turnstile-dinit-0.1.10-2, and dbus-dinit-user-20250819-2, there will be changes of how these are handled.
dinit-rc won't hard depend on any user service enabler (turnstile or dinit-user-spawn), so users will have choice whether to enable the user services or not. While by default dinit-user-spawn may be installed, it won't be enabled by default. Some user services (see dbus-dinit-user) may depend on dinit-user-spawn, but existing turnstile-dinit need not to worry since it has provides=('dinit-user-spawn'). dinit-user-spawn will also conflict with turnstile so anyone using turnstile already can uninstall dinit-user-spawn safely.
Please wait for those packages to reach your mirrors, and my apologies for the inconvenience.
Attempting to remove
dinit-user-spawn (version
1.0.0-8 ) results in the following error:
could not satisfy dependencies:
- removing dinit-user-spawn breaks dependency 'dinit-user-spawn' required by dbus-dinit-user
Currently I have
dbus-init-user version
20250819-2. I guess the dependencies are still too strict ?
Currently the
dinit-user-spawn service is active,
turnstile was not enabled previously. Should I remove turnstile or dinit-user-spawn ?
Wait for
-3 to hit your repos. Thanks for the report.
Thank you,
@konimex !
The update I performed a few minutes ago proposed to remove
turnstile-dinit, which I did.
The reboot worked flawlessly.
For now, only the package
turnstile (v 0.10.0-2) remains on the system. Is it recommended to remove it ?
Simple curiosity: is turnstile being deprecated or this is just a readjustment of dependencies to better prepare a stronger integration with turnstile ?
Nothing is being deprecated.