You're running Ceres - the unstable development version.

One should not be using unstable developer tools if they are not willing+able to debug simple package dependency issues.

Since the two problem packages do currently exist in ceres repository, it's possible the error message is correct - that this was a local issue caused by held packages - but it's also possible it was a temporary issue caused by the fact that Ceres is an unstable development version.

Which isn't a surprise, because there is no separate non-free-firmware repo in Chimaera.

This thread is about Daedalus, not Chimaera.

Ah ok, so it has some of the packages but not all of them - cockpit-system is the dashboard/frontend (basically a bunch of HTML/JS).

The cockpit package is the top-level package, and it's blocked in Devuan because it depends on cockpit-ws which depends on systemd:

cockpit
    cockpit-bridge
    cockpit-system
    cockpit-ws
        systemd

The cockpit-ws package contains login/authentication code, so even with the backend server (cockpit-bridge) and the UI, it presumably wont work without that.

Worth adding that one can search for any package at https://pkginfo.devuan.org to confirm which repos it exists in.

If there are Devuan-specific patches then the version string will include "devuan" (suffixed by a number, and possibly prefixed by "+" or "-" or "~"), and also the "Filename" field on info page will start with "pool/DEVUAN/" instead of "pool/DEBIAN/".

To discover what the changes are, goto https://git.devuan.org/explore/repos and search for the package name.

Neither appending an end-of-line anchor nor doing a second negative grep are guaranteed "lossless" solutions - they both have potential to exclude valid lines. (Might not be very likely with the latter, but is still possible.)

Wrapping one of the characters in a character class will never exclude anything except the specific unwanted grep line, and is only two extra key presses.

And again, an even better solution is to ensure procps is installed, and use pgrep, which never includes itself in its output and defaults to just the pid; if one needs the extra detail ps provides, ps u $(pgrep cron) will do that.

On the unasked adjacent question, the common solution to grep appearing in ps|grep output is to alter the pattern so it doesn't match itself, e.g. ps aux | grep 'cro[n]'

Another solution is pgrep.

That information would be at the same place it always is, https://www.devuan.org/os/releases:

-

Where do you get "Usually" and "few weeks" from?

With Bullseye/Chimaera it took two months, which is the fastest it has been (presumably due to continued automation of previously manual tasks).

Assuming the effort required is equivalent between Bullseye and Bookworm, is there a reason to expect Daedalus before August?

Of course, it's also possible there's extra complexity that pushes things back further - I would assume the splitting of non-free and non-free-firmware, or the usr-merge stuff, both have potential to create extra work for the Devuan team which may mean things end up taking longer.

Unstable (Ceres/Sid) is on 114 too, it's Testing (Daedalus/Bookworm) that is on 113.

Stable (Chimaera/Bullseye) is on 112, except there's a 114 in the Stable security repo - but not for the locale package.

This can be seen at https://pkginfo.devuan.org/chromium and https://pkginfo.devuan.org/chromium-l10n

Since Chromium is not a Devuan-specific package, this is not a Devuan issue.

Specific versions can be seen in Debian's tracker, as can the fact that v114 entered stable-security yesterday:
https://tracker.debian.org/pkg/chromium

The page also mentions a bug in the chromium-l10n package, which is about this issue:
https://bugs.debian.org/cgi-bin/bugrepo … ug=1037087

In other words, it seems for whatever reason only 5 of the 6 binary packages have been built/deployed - once the Debian Maintainer for Chromium sees the issue they will presumably rectify that.

The reason they exist is described here: http://lists.busybox.net/pipermail/busy … 74114.html

Attempts to rationalise it are described here: https://refspecs.linuxfoundation.org/FH … index.html

-

Sounds like they've deferred the merge because they're continuing to have problems one small part of the process.

edit: updated after reading https://lwn.net/Articles/932158/#CommAnchor932182

Here's a summary from a year ago: https://lwn.net/Articles/890219/

Why do you say "there is nothing for Chimaera"? That is demonstrably not true - Chimaera has the exact same version as the current Debian Stable release. (Likewise, the version for Devuan Testing is the same as for Debian Testing, and same with Devuan Unstable and Debian Unstable.)

https://packages.debian.org/xtables-addons-dkms
https://pkginfo.devuan.org/xtables-addons-dkms

The package is not modified by Devuan, so (unless you can demonstrate a Devuan-specific bug) it's not a Devuan issue and you need to report that to the Debian; any fixes there will filter through to Devuan.

If you need a newer version in Chimaera, and you're not willing to build it yourself, then you need to find/convince a volunteer to backport it to Debian Bullseye, and again the backported version will filter through to Devuan.

Visual Studio is a development environment (IDE) - wouldn't surprise me if it can open it, but hopefully there will be simpler options.

It might be that, either instead or in addition to mounting it as fsmithred suggests, you need one of the tools listed here:
https://en.wikipedia.org/wiki/COM_Struc … mentations

Seems plausible that it's relating to Microsoft Teams crashing and writing everything in memory to disk, or something like that.

Another thing you could look for is if there are other files on disk with similar modification times. (Or if you still have any log files from back then, grep those to see if there's any relevant messages.)

For example, find can identify files modified within 5 minutes either side, like so:

find START_PATH -newermt '2020-07-06 17:21' -not -newermt '2020-07-06 17:31'

Replace START_PATH with a suitable directory, e.g. /home/user and maybe also try with switching -newermt to -newerct (or -newerat), as per -newerXY in find docs.

Entering file xyz.db will not give that output!

It looks like ls -l output (with filename removed), and ls doesn't give a file's creation date - it gives mtime (modification) but can be requested to give atime (access) or ctime (file status change).

Running stat xyz.db will give all three times precisely - along with a value for file creation called "birth" if the filesystem supports it - likely mtime and ctime are the same, but if they differ then this may indicate if/when the file was copied to that system from elsewhere.