Hm, do you mean you want a Web interface for browsing the remote repositories?

I would believe the "normal" command line access would simply draw upon ssh. Perhaps this "random" page
http://www.startupcto.com/server-tech/s … ing-up-svn
can assist you. Those instructions are for CentOS, but to me it looked like you'll only need some rather thin sanity glasses to make good use of them. I'm not actually familiar with the needs of svn, but at a first glance, you merely need to install the subversion package, which includes the svnserve program that a svn+ssh: client operation will want to run. And then of course maintain the "s" bit on the repository directories.

Though I can see that there exist some "apache-subversion" packages in the distribution, so there probably are ways of having a set up through an apache server as well. I suppose svn has been around long enough to attract a plethora of round-about ways to achieve the thing; perhaps many with useful bells and whistles.

I just replaced my router, which seemed to be a crappy one. Among its brokenness, it "forgot" about the statically configured printer when the printer went into low power mode. But this got resolved with printer restart, rather; I never tried rebooting my computer.

The thought I had now though, was that possibly the DHCP service of the router makes a more forceful broadcast when the computer reclaims its IP in order to confirm that the IP is available, and that it then also address the DHCP registered MAC (not merely its ARP MAC list) with the result to bring the printer out of its economy mode. It's a theory

Hmm, at a glance it looks like package virtualbox is available in jessie/contrib (version 4.3.36), ascii-backports/contrib (version 5.2.24) and ceres/contrib (version 6.0.6).

Please note that packages.devuan.org (and auto.mirror.devuan.org is an alias for that domain name) is the historic repository for Devuan. It still provides it's old repository service, but it should be understood as disconnected from the current packaging workflow, which instead results in populating pkgmaster.devuan.org, and then that is mirrored to the hosts that are identified as deb.devuan.org.

The notion of "using Devuan" is now equivalent with having deb.devuan.org/merged as repository.

In extreme circumstances, one might use pkgmaster.devuan.org; for example during the short periods where mirrors show inconsistency during their sync times. However, it typically works equally well and better to just wait a bit and then repeat the failing update or installation command, having allowed time for the mirror(s) to synchronize. If the problem persists, say a couple of hours, then it is likely to be a source inconsistency at pkgmaster.devuan.org. Please report that, even though the automated work flow may well correct the situation eventually; sometimes a manual touch speeds it up.

Changing to a different repository, such as one of those at the top, is like changing distribution. Don't do that.

@Head_on_a_Stick I can't decide if I should label you stupidly arrogant or arrogantly stupid. In any case I look forward to you growing up.

239.1+20181115-1 is from http://deb.devuan.org/devuan experimental/main.
not sure where 239.3+20190131-1 is from though.

As you know, the file /etc/apt/sources.list and all the files /etc/apt/sources.list.d/*.list together form a configuration for apt-get (or "the apt sub system"), so that it knows which repositories, and which sections in those it should access. Thus, you can't really install such a configuration without already having a configuration, which kind of makes this a circular thought.

But there are utilities that can produce different source.list files for different distribution flavours, and that might be useful initially. Use your favourite WWW search engine to find a good one if you like. Typically you make a few selections of what to include and what not, then, assuming your can trust it, you download the result and place into your sources.list.

However, I would say it is of highest importance security-wise that the machine administrator knows exactly what the "apt sub system" configuration is. There is no escape from putting enough cognitive effort into learning it. This also includes the "pinning" aspect, which is configured in the /etc/apt/preferences.d/* files, and the "general apt parameters" of /etc/apt/apt.conf and the /etc/apt/apt.conf.d/* files.

Unfortunately the apt sub system was devised at a time when the nuances of "trust" were less developed; the ease by which it can be changed, even by vendors as you install their distributed packages, is totally off parity with its importance.

You do know how to leave an audience guessing

Perhaps you should test the waters at the freenode IRC #devuan as well, to increase the chances of running into someone else doing C with ncurses on both freebsd and devuan. It might be a more select group than this one.

@Head_on_a_Stick: You've got that advice backassed. It should be: don't pollute your system with flatpack.

You may find qt5ct in beowulf. However installing it on ascii wants to pull in quite a few upgrades of other packages, and I wouldn't do it before fully dist-upgrading to beowulf (which still is some weeks into the future for me).

Yes it's good to be weary about that. Important, really. Especially if you're unsure about how to recover if things break.

At the same time, avidemux is imo the very best tool for e.g., easily and quickly cutting out the ads in a tv streamed Barbie movie you have captured for your granddaughter. Since I have it installed and verified myself, I decided that the benefit of suggesting this action outweighed the general "badness" of proposing this repo mixing.

But you are right, the rule of thumb is still: "don't mix repos" .

Perhaps you're using an initrd and omitted/forgot you update it after making the black listing?

In any case, the following steps worked fine for me:

# echo blacklist psmouse >> /etc/modprobe.d/psmouse-blacklist.conf
# update-initramfs -u -k all
# reboot

(See man update-initramfs for details about that command)

Note, I know it's a good/better habit to also add a comment into the black listing file, to remind yourself about when/what/why you made that system correction, for the (possible) future day when you pull your hair about not getting psmouse loaded. I'm a bit lazy that way, and leave this as a reader's exercise.