Wait, so you installed the system as MBR with the Legacy/CSM turned on in BIOS and UEFI turned off, then went in after the fact (as part of trying to diagnose the issue) and switched UEFI on in BIOS without making any other changes? If so that's going to cause new issues....

Hey buddy, i'm so sorry, I need to work on my documentation and communication skills.  This app, like Nitrogen, will not work on DE's like XFCE and MATE. It is intended for Openbox, Fluxbox etc., not DE's that have their own wallpaper setters. Like all things I imagine there might be some way of hacking it in but that's beyond the scope of this project.

Just for giggles I tried it on Mate last night and yeah it installed fine and worked great up until I hit that Apply button...it was a hoot, it actually tried to apply the paper but only like a quarter of it laid over the previous wallpaper.

Very nice! Welcome to Devuan and the forum!

Hmm, pipewire is not my area of expertise, but off the top of my head i'd open a terminal and type alsamixer to see if I could get an idea of what's available, could be wrong device or maybe a muted channel.

Problem is with a big DE like that not to mention pipewire, you might not get proper output from that command, but it's what i'd do first.

If you mean where to host your iso, i've had really good luck with Sourceforge.

Well chromium is not the only alternative browser. And speaking solely for myself i'm not going to go through that mountain of instructions, but what I, and I think others, would be willing to do, is try out a re-packaged version of FF if you would create one, and test it and report back. That would be a real service to the community if you would do so.

Maybe try a different browser?

Done! First version uploaded to Sourceforge:
https://sourceforge.net/projects/vuu-do … /VuuPaper/

Up on gitea now: https://git.devuan.org/greenjeans/vuupaper

This is the first version, still might have some small bugs and surely could use some polishing, but it seems pretty stable
and very useful even in multi-monitor setups. Some nice features and workflow too, check it out when you have time! To compile yourself:

gcc -o vuupaper22 vuupaper22.c `pkg-config --cflags --libs gtk+-3.0` -Wall -O2

From the readme:

VuuPaper, a simple wallpaper manager/setter for X.

This app was inspired by Nitrogen and is similar in look and feel, this app is built with C and gtk3
and uses the excellent xwallpaper for the backend. Very small and fast, less than 40 kb for the binary.

On first run a dialog is opened that offers quick instructions about the --restore function, and
a Choose Directory button that opens the file-chooser for you to select your default wallpaper
folder, and then opens the app with thumbnails of your images ready to apply. You can add additional
wallpaper folders by using the Add Folder button, to the right of that is a drop-down menu from
which you can select what folder you want to use. The Style menu lets you choose what mode to
apply the wallpaper with (i.e. zoom, center, maximize etc.) The BG Color button lets you choose
what background color is behind your image. On the upper right is the monitor selector drop-down
menu, you can choose from All Monitors (same image/style on all), Span (one image spanning all),
and after that will be listed all monitors connected. And of course the Apply button to use after
you have selected a monitor, wallpaper, and style.

At the top is the infobar which gives you the full path to the wallpaper currently applied, for
multi-monitor setups the monitor drop-down selector also toggles the infobar if you have different
papers applied on different monitors, so you can always know what's currently on each display.

To make your wallpaper choices restore after reboot, you need to add it to your autostart file
similar to the way other wallpaper apps do:
"vuupaper --restore &"
In Openbox this is usually ~/.config/openbox/autostart but there are many ways to do it, consult
the docs for your system/WM/DE to find out what's best.

Well you can say it's not a flaw or a bug or whatever, but when a tool like gparted cannot tell there are 2 partitions on a stick when every other tool and even file managers can, it's an issue, period, for the user. See Mercury's post above.

But there is also a flaw in GDU, one that would be super easy to fix really. As all that's needed is for it to call wipefs on the empty space before creating a new partition.

# Proactively wipe ISO-9660 signatures to prevent Gparted detection issues
wipefs -a -t iso9660 "$USB_DEV" 2>/dev/null || {
    error_dialog "Failed to wipe ISO-9660 signatures on $USB_DEV."
}

It's literally that easy. But GDU doesn't do it, and it leaves 5 bytes that confound gparted. So i'm sticking by what I said, they both need to be fixed.

Sweet! we're almost there, the test tone shouldn't react to most EQ settings as it's just a straight 400 hz tone. What is the output if you open a terminal and type alsamixer?

Downloading the iso you linked to now, will try this in a live-session and see what's what.

EDIT: Well I got sidetracked yesterday and didn't get it done, but just finished downloading it a minute ago, let me get a little more coffee in me and i'll get started, never used anything Void-based so this will be fun for me, I do like exploring new file systems to see how they work.

There ya go, then roll it up with Refracta-Snapshot and you have a nice iso.

Hi, so caps is a dependency for libasound2-plugin-equal so you won't see it in the source code as it's not called directly.
So to clarify, you do have the "/usr/lib/ladspa/caps.so"  file? If so it's pretty puzzling that it can't find it....

I have never worked with Void and don't know much about it, my first thought is there might some differences, package names, methods, etc. in Void, possibly versioning issue, but it would sure be cool to have it up and running in it.

Was your error genned by running it using the .desktop, and have you tried it in terminal?

FYI this was all built on Devuan daedalus libraries, in limited testing it works here for excalibur as well but have not fully tested or re-built the binaries against excalibur/trixie libraries. So that could be an issue with versioning possibly.

caps - 0.9.26-1
libasound2-plugin-equal - 0.6-8
libasound2 - 1.2.8-1+b1