Inaccurate.

Files only need to end in .pref if there is another . in the filename, but it is acceptable to have no extension.

Also, it is not guaranteed Apt will complain - if a file is called something.disabled or something.bak it will be ignored without complaint.

To clarify, use [code]PASTE TERMINAL OUTPUT HERE[/code] tags, (because it preserves formatting, making it easier to read).

For short/inline commands, use [c]inline code[/c] tags.

Do not use quote tags.

-

(p.s. Since apt policy accepts multiple package names, one can use apt policy default-dbus-session-bus dbus-session-bus xfconf instead of three distinct commands. It also supports wildcards, so one could use apt policy '*dbus-session*' to see all matching packages.)

I write concise posts. They can take time.

(Thinking is good for you. More people should try it.)
-

However, I also tick the checkbox on the login page, which changes the timeout from its default (30m) to 20,160 minutes. Two weeks may be annoying when returning from holiday or occasionally using a second machine, but is plenty long enough to compose a single reply.

If using one's own device, there is no good reason not to tick that checkbox.

If on someone else's machine, a majority can still tick it, then simply logout manually and/or close the private browsing windows to end the session.

... is contrary to...

In any case, if running e2fsck on Tumbleweed is changing the filesystems options to enable an otherwise disabled feature, that is either a Tumbleweed issue and/or operator error. (If running the command regularly is actually necessary, try doing it from a system that preserves compatibility, i.e. Daedalus.)

Devuan does not modify Debian packages unless they are systemd-entangled; since e2fs is unrelated to systemd, Devuan uses Debian's packages directly, as can be seen at pkginfo.devuan.org/e2fsprogs and the lack of "-devuan" in any of the versions.

Devuan team members have repeatedly pointed out that the Devuan devs have enough work keeping up with in-scope changes, so increasing their workload with out-of-scope tasks is simply not going to happen.

Not being a developer isn't relevant. Security issues aside, the potential way for getting a new version of a package into Chimaera/Bullseye repos is via Backports. If one doesn't have the ability/time/whatever to do that oneself, they must find someone who does.

Of course, given there is already a backported version for Bullseye/Chimaera, asking on the debian-backports mailing list about getting that updated would seem to be appropriate.

Um... anyone who has trouble seeing red and/or green will probably already have reconfigured their terminal colours accordingly, so they can adequately see/discern those colours in everything that isn't Apt, no?

If they haven't, or if they need Apt to be different, they can set APT::Color::Red and/or APT::Color::Green as appropriate.

Not only that, but this change has only just entered Unstable - which is where such things are tested and changed if needed, long before making it to an actual release, so if this change is detrimental then something can be done about it.

Maybe it's just me, but I feel a real journalist should have bothered to do the small amount of research it took to confirm the configurability? Maybe they simply had a minimum word count to reach and couldn't be arsed...

Check the maintainer field when you look at "apt info PACKAGENAME".

Does it mention Devuan? (No, it doesn't.)

If the v8 packages are not backwards compatible, then it's a Debian bug, which you should raise via Debian's bug tracking system.

Forums truncating URLs is a common annoying anti-feature.

With the (poorly written) FluxBB software this forum uses, it is hard-coded to occur above 55 characters. (The internal forum links are 53 characters, so do not trigger it.)

The auto-linking functionality can be bypassed by deleting the entire protocol, which means also avoiding the truncating functionality, is less ugly than deleting just one letter, and can be either screenshotted or copy-pasted without issue, and without need to manually add h to the start.

It can be done by holding ctrl whilst tapping del twice - compared to deleting a single letter it's a tiny amount of extra work for the author, and removes the need for readers to add a letter.

(Also, if an unlinked URL is the only thing on a line, it can be quickly selected by triple-clicking.)

There is no radicale package maintainer in Devuan because there is no radicale package in Devuan - Devuan uses the Debian package unmodified.

Devuan only modifies a relatively small number of Debian packages (to remove systemd entanglement - usually when a package has "Depends: systemd"), the majority of packages are unmodified from Debian repositories.

(In addition to searching as you did, you can tell when you have a Devuan-modified package by looking for "devuan" in the Version, and checking for "pool/DEVUAN/" at the start of the filename. The radicale package does not have these, because it comes from Debian.)

So, if Debian's radicale package supplies a sysvinit script (which it appears to here), and you've identified a problem with that script, then the report should go via Debian's bug tracker  (i.e. not direct to Radicale's bug tracker).

*bump*

The Debian seatd source at //sources.debian.org/src/seatd/0.7.0-6~bpo11+1/ indicates the upstream sourcecode repository is //git.devuan.org/devuan/seatd

The list of tags has "debian/0.7.0-6" but no "devuan/anything" since 0.5.0-1 (despite daedalus,ceres,excalibur having newer versions), and also no tag matching the bullseye backport 0.7.0-6~bpo11+1.

So I'm assuming that from 0.5.0-2 onwards both Debian and Devuan have been using the same version, and the only actual difference between seatd_0.7.0-6_amd64.deb and seatd_0.7.0-6~bpo11+1_amd64.deb are different libc versions used when compiling the binaries.

Is there any reason installing seatd_0.7.0-6~bpo11+1_amd64.deb from bullseye-backports repo on a chimaera system will cause issues?

I don't see shortcut preference changes in the v1.1.2 changelog (at //gitlab.xfce.org/apps/xfce4-terminal/-/tags), but v1.1.0 appears to have a bunch of potentially-relevant changes.

Since Devuan Testing has v1.1.1, a sensible first step would be to test that in a VM and see if it does have the desired functionality. If so, looking into what it might take to get that version backported would be worth checking.

Devuan is an OS for people that want stable well-tested software NOT the latest versions - it is not a rolling source distro (like Artix/Gentoo/Slackware/etc).

Further, trying to install packages from GitHub is liable to cause problems - if one has a good reason to install from source (for a newer version than "apt-get source" will give), the correct location to obtain the source code is either git.devuan.org/devuan or sources.debian.org (depending on whether Devuan has modified that package or not), but again there's no guarantee that compiling newer source will work.

Finally, if gcc is actually installed then the binary will be at /usr/bin/gcc - which is in the path - and if you're not aware of things like that, it's a good sign you need to do more learning before trying to install from source (or that you shouldn't bother because you probably don't need the latest version, or if you really do need it then go with an OS that provides it out of the box, like those mentioned above).

> the tomcat start script is very complex

No, it's not. It's about 260 lines long, and most of that is boilerplate.

//sources.debian.org/src/orphan-sysvinit-scripts/0.16/scripts/tomcat9/

The difference between running Tomcat 9 and Tomcat 10 is that some previously optional stuff might no longer be optional:

//tomcat.apache.org/tomcat-9.0-doc/setup.html
//tomcat.apache.org/tomcat-10.1-doc/setup.html

That aside, adapting the script may be as simple as search-replace "tomcat9" with "tomcat10".