backends can't be managed under nixos

[fsnkty]

issue as I now understand it.

backend processes couldn't be managed by rwpspread as it relied on killall which isn't included by default with nixos.
realistically I should have simply made this a dependency of the package on nixos. but given the dependency is now removed I guess thats for the better .. 😅

oops! turns out this effected both back ends!

below is my first comment for this issue.

this goes for the directory an image may be in, or the image it self, if either start with the typical . rwpspread will fail to read it in.

~/Repos/rwpspread % ./result/bin/rwpspread -b swaybg --image ~/Downloads/.test.jpg
rwpspread: No such file or directory (os error 2)

where renaming the file to test.jpg works as expected.
images within directorys such as .config are similarly inaccessible.

happy to close if another distro cant replicate and I'll take a better look at fixing it myself.

built from main using the flake for nix build, getting version rwpspread 0.2.1-1
can't see how this would relate to how its built with nix specifically but worth mentioning regardless.

[0xk1f0]

Can't replicate this, have been using this in my autostart.sh since the day I started developing this:

rwpspread -b swaybg -spdi "/home/$USER/.wallpaper" &

Just tried it manually again

~ ❯ rwpspread --image ~/Downloads/.test/image.png
~ ❯ ls *.png
rwps_41f3d1da0227c1fe_DP-1.png
rwps_41f3d1da0227c1fe_DP-2.png
~ ❯ mv Downloads/.test/image.png Downloads/.test/.image.png 
~ ❯ rwpspread --image ~/Downloads/.test/.image.png
~ ❯ ls *.png
rwps_7fc2e3a2fde152d9_DP-1.png
rwps_7fc2e3a2fde152d9_DP-2.png

So at least it seems to work fine on Arch.

Can't say if this is related to rwpspread, don't close the issue yet though, worth investigating.

[fsnkty]

I'll update this issue when I get around to looking into it better.
just didn't want to bring up concern if this is only an issue for me.
its worked in the past with the rwpspread from nixpkgs, I should have noted this is with building from main.

[0xk1f0]

Can you try running just with --image and without -b? Does that also fail?

Edit:
just tried using nix build from master, also seems to work fine:

../rwpspread on  master ❯ result/bin/rwpspread --image ~/Downloads/.test/.image.png 
../rwpspread on  master ❯ ls *.png
rwps_7fc2e3a2fde152d9_DP-1.png
rwps_7fc2e3a2fde152d9_DP-2.png
../rwpspread on  master ❯ result/bin/rwpspread -b swaybg --image ~/Downloads/.test/.image.png 
../rwpspread on  master ❯ 

[fsnkty]

interesting.. seems it doesn't like how swaybg is installed with nix.
ns here is an alias for nix shell it loads an environment where swaybg is available.

~/Repos/rwpspread % nix build
~/Repos/rwpspread % ./result/bin/rwpspread --image ~/Downloads/test.jpg
~/Repos/rwpspread % ./result/bin/rwpspread -b swaybg --image ~/Downloads/test.jpg
rwpspread: No such file or directory (os error 2)
~/Repos/rwpspread % swaybg
2024-03-01 14:10:46 - [main.c:289] Could not find config for output DP-1 (Lenovo Group Limited G27-20 U6331D78)
2024-03-01 14:10:46 - [main.c:289] Could not find config for output HDMI-A-1 (Samsung Electric Company S24E390 0x00005E55)
^C
~/Repos/rwpspread % ns swaybg
~/Repos/rwpspread % ./result/bin/rwpspread -b swaybg --image ~/Downloads/test.jpg
~/Repos/rwpspread %

but even before that.. swaybg was available to my shell? so unsure why rwpspread had an issue with it.
will take a better look soon.

looking at the source breifly id have thought the error for swaybg being missing to be different?
will have to look into that as well as getting something other than a generic os error would be nice

[0xk1f0]

Alright this narrows it down a bit.

Interesting that this is triggered only with dots in file paths, let me know when you find more about this.

[devhell]

Also on NixOS, can also confirm that there's something funky going on:

> rwpspread --backend swaybg --image ~/Pictures/.wallpaper.png                                                 
rwpspread: No such file or directory (os error 2)

> rwpspread --backend swaybg --image ~/Pictures/.wallpaper.png

Executed in sequence, first time it'll fail, second time it won't fail. Though, I'm still unable to set the wallpaper. Nothing changes, but that's a separate issue.

[0xk1f0]

Also on NixOS, can also confirm that there's something funky going on:

> rwpspread --backend swaybg --image ~/Pictures/.wallpaper.png                                                 
rwpspread: No such file or directory (os error 2)

> rwpspread --backend swaybg --image ~/Pictures/.wallpaper.png

Executed in sequence, first time it'll fail, second time it won't fail. Though, I'm still unable to set the wallpaper. Nothing changes, but that's a separate issue.

Is this the latest release build and if not could you try with latest master? I overhauled some of the path checking recently.

If the issue still persists I might need to spin up a NixOS instance myself, since I can't reproduce this on Arch it seems.

[0xk1f0]

Quick Update::

I was able to reproduce, by uninstalling the which utility, which is used by rwpspread for checking if a program exists in $PATH and it throws an incorrect error on v0.2.1

../rwpspread ❯ target/release/rwpspread -b swaybg -i "/home/$USER/.wallpaper"
rwpspread: No such file or directory (os error 2)
../rwpspread ❯ target/release/rwpspread --version
rwpspread 0.2.1-1

On latest release I get a "correct" error, which is the inability to find swaybg since which is missing:

../rwpspread ❯ rwpspread -b swaybg -i "/home/$USER/.wallpaper"
rwpspread: swaybg is not installed
../rwpspread ❯ rwpspread --version
rwpspread 0.2.2-1

This is clearly an overlook on my side, since I'm used to Arch and most distros having which installed by default. Since this is not really a good approach going forward, I'll switch to using command -v, which should work anywhere and is a more POSIX compliant way of checking this. I'll switch to a standalone Rust implementation of checking $PATH, which should work everywhere.

Done in 0bd233a

I'll draft a Hotfix release for this.

Done in v0.2.3

[fsnkty]

sorry I've been absent after making this.
on 0.2.3-1
I can now get rwpspread: wpaperd backend is not installed when wpaperd is unavailable.
using nix shell to get wpaperd and everything simply just works.

attempting to use swaybg (which is available in my users shell which i am running rwpspread from )
when running the same command twice I get

1. rwpspread: No such file or directory (os error 2)
2. no console output, no wallpaper set.

could this be to do with the cache of images once split? using a different image will get the first line to happen again and then no output until a different image is tried.
eitherway, not likely to be the root cause of the issue, just a cause of potentially misleading errors?

the idea that a . in the path caused this can seemingly be ruled out.

[0xk1f0]

attempting to use swaybg (which is available in my users shell which i am running rwpspread from )
when running the same command twice I get

1. rwpspread: No such file or directory (os error 2)
2. no console output, no wallpaper set.

Ah this is a bit weird, now I am back at the point where I can't reproduce.

could this be to do with the cache of images once split?

Going through my logic, caching should not be an issue on the first run, since we basically skip the whole caching entirely if no files a present. Returning nothing is a "good" sign since it correlates to a zero exit status and that nothing went wrong, which is clearly not the case here.

The implementation for wpaperd and swaybg is not that much different other than wpaperd needing a generated config file, so it is interesting that wpaperd doesn't show any issues here.

When you have the time, could you try running with --force-resplit, since that bypasses all things related caching and check if a similar error occurs. And for good measure, try setting a different output directory with -o, since that is also supported now. Would be interesting to see. I'll dig through my code once again in the meantime to see where this originates.

UPDATE:

Ok so what I found is that we still used two external utilites for process management, namely pidof and killall. I spun up a NixOS minimal image and found that killall is not available, so I switched to using pkill, which is. I could write the functionality of these utilities into rwpspread itself, but that is just me being lazy I guess.

The swaybg implementation used the force restart, which used killall, as soon as no caches were present. This is likely where the error comes from since the wpaperd backend only does that when its own config is missing.

So, please try building from master, the relevant commits are 92a1685 and 326670f. Hopefully this fixes it. Quick reminder that we now only rely on pidof and pkill to be available to the shell.

[fsnkty]

ahhh glad you were able to find this, I was off both times xD sorry..
using current master I was unable to get rwpspread to kill an existing instance of swaybg ( that it hadn't spawned ) so it was unable to set anything.
it was able to update the wallpaper when it was the one to spawn the initial instance of swaybg though.

wpaperd backends seem to have been fine this whole time and can change the wallpaper even if it rwpspread isnt the one to start it.

if you don't want to consider this behavior an issue this issue can be closed.

I'm going to update the lock file here and create a PR to fix the nixpkgs instance and get it up to date.
done, once that's merged ryantm should be fine to handle future updates on its own so it should be faster than just me.

I really hope that wasnt my issue here from the beginning that sure would be embarrassing..

UPDATE:
never mind I managed to get wpaperd to fail on an attempt to set a wallpaper if wpaperd was already running.. ( this is on 0.2.3-1 ) even if it was the one to start it originally so i guess this effects both in some ways, doesn't happen with master, swaybg backend still fails this way (if it didn't start swaybg itself? ) on master though.

[0xk1f0]

Interesting to see that it fails to kill swaybg, would be interesting to see why this happens though. Could it be a permission error maybe? Although it shouldn't, considering that it is also started in user-space.

Other than that I'm glad we got to the root of this, I might just add another flag that bypasses the force-killing process and just starts its own instance regardless if another one is running or not. Would not be too much of a hassle to implement. If that isn't desired, I'll close, bump the version and call it a day.

[fsnkty]

Interesting to see that it fails to kill swaybg, would be interesting to see why this happens though. Could it be a permission error maybe? Although it shouldn't, considering that it is also started in user-space.

Other than that I'm glad we got to the root of this, I might just add another flag that bypasses the force-killing process and just starts its own instance regardless if another one is running or not. Would not be too much of a hassle to implement. If that isn't desired, I'll close, bump the version and call it a day.

honestly a flag would be more hacky than just a notice that rwpspread should be left to start swaybg itself imho.
i personally would find it less useful than a warning to say as much.

thank you for working at this, my pr here should mean that ryantm will keep the package up to date automatically as the cargolock isn't kept separately anymore :)

[0xk1f0]

Cool, I'll bump this up to 0.2.4-1 and mention this in the README. I'll close this after, thanks for reporting. :)

[0xk1f0]

Closing with 0.2.4.

[devhell]

Sorry for not getting back to this sooner. Just wanted to say thank you, rwpspread behaves as expected now on NixOS. :)

[0xk1f0]

Sorry for not getting back to this sooner. Just wanted to say thank you, rwpspread behaves as expected now on NixOS. :)

Glad to hear that, thanks for reporting back. :)