Afaiui a destination phrase rsync://groucho@192.168.1.3:/stuff tells the rsync server to become user groucho and then interpret what the "stuff" module is. As man rsync tells me at (my) lilne 202: the first word of the "path" is actually a module name.

To that end rsync will want a declaration in the applicable rsyncd.conf at the server end which in particular would provide the desired path prefix /stuff for the stuff module, but presumably that doesn't exist. But from the log file, it looks like it results in the /stuff bit (the module bit) is consumed and then a destination path prefix / is used.

In short, you might have some luck using rsync://groucho@192.168.1.3:/stuff/stuff as destination path, on the idea that the first /stuff bit nominates the module and the second /stuff bit nominates the path suffix relative to the default module path prefix, /. Of course, if the server is happy with more random module name, you should use something else than /stuff just to reduce the confusion, maybe rsync://groucho@192.168.1.3:/X/stuff

Your sources.list point should have been fine for finding broadcom-sta-dkms in chimaera/non-free. It would be wrong to add deb http://deb.devuan.org/merged chimaera/non-free amd64 and apt-get would have told so upon update. So I'm afraid I cannot explain why the package seemingly appeared following your addition of that and not before-hand; possibly it was that you hadn't actually updated before or something.

Anyhow I think your previous idea about the source list points was more workable, and there is no difference in format or interpretation or use between Devuan and Debian.

As to architectures, normally apt will keep meta information for all installed architectures; most usually the single installed architecture, but nowadays many systems are of "multiarch" kind and thus having software for multiple architectures. If you would want it to keep meta information about other architectures than the installed one(s), you either mangle architecture parameters (in a square-bracketed phrase just after deb) on the source list lines, or you set up an APT::Architectures apt configuration setting.

It is also a point that Devuan offers all of Debian's packages except those that are noted in https://pkgmaster.devuan.org/bannedpackages.txt and in most cases the actual package files (the .deb) are directly retrieved from Debian's repositories. Only a few packages are rebuilt and repackaged so as to make them usable on systems without systemd, and only those packages are provided from Devuan's repository pool.

Your "long-winded install command" collapses into requesting 3 packages for installation. The command should work on a Devuan system in the same way as a Debian system; it installs:

• package linux-image-$ARCH for the architecture $ARCH of the running kernel,

• package linux-headers-$ARCH for the $ARCH of the running kernel, and

• broadcom-sta-dkms

I would suggest that it's not exactly the right thing to do, since it builds a broadcom kernel module for the default kernel version rather than for the current kernel version, and it also forces installations of those default image and header meta packages. If you e.g. would run a back-ported kernel, then the command wont install the headers for that and the subsequent kernel module building may find itself being in trouble.

Rather, you would use uname -r to print out the exact version $VERSION and then install the linux-header-$VERSION package for that before installing broadcom-sta-dkms.

Firstly, I have to assume that you prepared that startfvwm95 script/program to run the binary, which by default installs into /usr/local/bin/fvwm95. Probably fine.

Next you are obviously entering a software maintenance mode which involves fixing "bugs" in the software to adapt it to the current X11 environment, and that's not something I want to commit to be involved in. I see there is a readme file regarding FvwmTaskbar; possibly related.

Good luck.

???
So the second option is that "if the argument $1 matches xfce4 or matches * (aka anything), then use startxfce4". That makes the remaining ones mere decoration.

For sure you meant them to be in a different order.

Good idea. The next steps towards that would be to

1. get the software held as a project at the Devuan Git Store, https://git.devuan.org, and

2. enjoy and digest https://git.devuan.org/devuan/documenta … aintainers

The old devuan/setnet project is still there but it hasn't been touched for some 3 years and it sure needs a new, active maintainer. I would suggest you discuss details with LeePen over IRC at #devuan-dev on libera.chat.

Firstly, when building you should use "make |& tee LOG" so that all output is captured in LOG. That makes it possible to review it all in more details.

In this case you will need to find the "error: ..." lines to figure out what the main problems are. All the warnings should really be tended to as well, but they doesn't stop the compilation.

I mostly got missing include files and needed to install:

# apt-get install libx11-dev libxpm-dev libxext-dev libxt-dev xbitmaps libxmu-headers

plus a light manual touch to remove some misplaced "##", and

now it looks like the link recipe of the Makefile needs polishing as well.

Yes.
You download that linux tar.gz, android-studio-2021.1.1.22-linux.tar.gz
un-tar it at your favourite place, then follow its instruction (to run studio.sh)
You can do all this as "normal user", i.e. you don't need to be root.
And then it'll keep downloading stuff .. some 6G maybe.
Seems to work fine (on chimaera).

Yes I think there was a mistake on that link;
the OP had this link: https://imgur.com/8MA5SQK which does include the "swosh"

Well, it operates on the current display, as known in the DISPLAY variable or given as command parameter, and it's typically run as the logged in user (not root) in a terminal window. I.e., open your terminal window and type the command there.

The program is xrandr, on the command line.

First just

$ xrandr

so you can see what your monitor outlets are called.

Second some configuration adjustment, e.g. like:

$ xrandr --output $mon2 --auto --right-of $mon1

which would enable $mon2 in its default resolution and logically place it top aligned to the right of $mon1.

Use man xrandr for information.

I've had some luck using "-pix_fmt yuyv422" and "scale=-1:720"

It's not unusal to get all sort of such problem if you happen to omit or forget to set up the virtual filesystems (esp. proc, sysfs and devpts) and device nodes in the chroot.

grub, for instance, will want to access both the disk device as a whole as well as the boot partition on that device, and it also wants that boot directory to be present on that disk device.

But you probably don't want that installation to mess with your "outside" boot so you should refrain from bind-mounting /dev. Rather you set up the appropriate device node for the target disk image under an alias name within the chroot; i.e., for example, use mknod naming it "sda" but with major/minor identifying the actual device (perhaps "sdf" for a removable, or "loop0" for a  duly set up disk image file).