It seems to be available in ascii/contrib (or jessie/contrib).

Good find.

There is also the per-AP settings in /etc/wicd/wireless-settings.conf which have a possible line of automatic = 1 or automatic = 0. That line tells wicd whether to connect to the AP automatically when in range, or not. To be sure, the wicd-curses UI offers a toggle for achieving this (without manual file editing), and I would guess the other UI's do as well.

I think the configuration file for wpa_supplicant that you refer to is created either manually (in a manual networking setting) or by the networking utility software (e.g. network-manager or wicd). E.g., for wicd, I have the configuration files in /var/lib/wicd/configurations/ with some "random" filenames.

No, you don't need to access contrib and/or non-free for this; all those packages (libopencv-core2.4, libavfilter5, libopencv-imgproc2.4, libav-tools, libavdevice55 and libtbb2) are available in jessie/main, and some of them also have upgrades in jessie-security/main.

Your OP warning probably relates to devuan-keyring, and it may help if you (re-)install that first, and then try again to install libav-tools.

Then as an aside: the current advice is that you should use deb.devuan.org instead of pkgmaster.devuan.org in your sources.list, so as to take advantage of the mirroring. But that's a different thing.

It looks like the default font path is compiled into "the actual server" binary, /usr/lib/xorg/Xorg, and even though that font path is simply a null terminated string, it's not for the faint-hearted to edit a binary. It'd be easier to avoid the warning by creating an empty directory, or maybe just have a quick sideways glance at the cat when the harmless warning scrolls past.

Nope.

I suppose, if you choose to stay with the names eth0 and eth2 (i.e. not eth1) it might also work as udev rules.

Almost exactly right, I'd say. Time has blessed us with three different ways of ending a line, all relating back to the use of these characters for printer control, and basically a matter of how it is represented on file. So, nowadays we have:

• the Microsoft line ending idea of using both CR (carriage return) and LF (line feed),

• the Apple idea of ending lines with only CR, and

• the Unix (and Linux) idea of ending lines with LF.

That line ending are characters within the files, to make up the traditional "text file" representation. Obviously the Unix idea is the right way, and the others are merely weak attempts of obfuscation.

For some reason, the fourth option of LF+CR never took hold, even though that's really the mechanical sequence that got implemented in type writers, and probably the "safest" motion for a ribbon printer, which otherwise might smudge the printing.

Regarding that "X days has passed ...", it sounds like the fsck output, telling you that the file system hasn't been checked in X days, and that a check is forced. Nowadays there is a tendency of not showing the startup messages, but rather just showing an image or a black screen until the desktop environment kicks in. This is something you can configure by changing the boot command line.

Regarding your sudo configuration, I suspect the issue is rather the absence or presence of a newline at the end of the line.

is an unusual first line for a script. Or was it a mistake when copying to here? Otherwise you should remove the first 6 characters, so that the very first character is the "#" character. Or equally, make it so to say:

#!/sbin/openrc-run

Looking at my own system (ascii), the story is something like the following.

The process is named udevd.

It's first started by its pre-pivot init-top/udev script, in initramfs. That process is then killed at the end of the pre-pivot init sequence, by its  init-bottom/udev script, still in initramfs.

Next it has its init link /etc/rcS.d/S0?eudev (or possibly /etc/rcS.d/S0?udev) for starting udevd in the post-pivot init sequence.

The pre-pivot start up includes a forced traversal of the /sys tree through a udevadm trigger --action=add command, and then that init-top/udev script also waits for udevadm settle to return, before it "pokes" extra on scsi devices, if any, followed by an optional additional timeout in some circumstances. Further, the init-bottom/udev script at the end of pre-pivot init merely kills the pre-pivot udevd process, and then moves the pre-pivot /dev to be available as post-pivot /dev.

Note that pre-pivot init is a script, usually a copy of /usr/share/initramfs-tools/init, and it ends with an exec run-init ..., which becomes the post-pivot init process (or a panic, if exec fails).

The generation need not be a mystery. It's indeed that "rules" file 75-persistent-net-generator.rules that comes into play whenever some hotplug event occurs, plus the once off initial scanning of /sys. I suppose you need to learn a bit udev-ish to work it out in detail, but essentially:

Afaict the idea is, that any subsequent addition event for the same net device adapter will process 70-persistent-net.rules first, and that will set NAME for the adapter, and thereby disarm 75-persistent-net-generator.rules. It's all at a deplorable level and style of programming, but I'm sure someone is proud of it.

One thing is that the  logic ignores other possibilities of setting NAME before 75-persistent-net-generator.rules. I have a vague memory of various random "solutions" to adapter naming that end up setting NAME early, and thus also disarm the generation of 70-persistent-net.rules, but without them being grounded in their logic. The result is more untouchable udev rules mess, which is good for nothing but clocking consulting time.