Sigh...

Passive-agressive response still fails to answer question.

Or other question for that matter.

Is it any wonder I said "fsck it then", and moved over to Gentoo? Why would I care? The horse is at the water, but it's not drinking.

Perhaps, if it's less painfull than pulling proverbial teeth. Are you on the Recruiters Team? Where is the IRC channel to find a mentor and who should I ask? Are there tests I would need to take? Where do I find documentation on this process?
Does this project actually have an organised development process, or is it just a collection of random personal-project warts on Debian's backside?

You want contributors? Make it easy, make it organised. "Why don't YOU $whatever" is pointless if you don't also set out what, how, and who to contact.

Ahh yes, Mr. Pot turns up to shout at Mr. Kettle, right on queue.

Right back at you^. I don't see any code or package contributions at all in your history on git.devuan.org...

... Twiddling with documentation, web-infra and theming. Not fixing broken packages or implementing solutions for systemd-dependent components.

Four months ago I asked:

And I still don't have an answer. How do you expect "users to step up" when there is nothing but radio-silence from the supposed leadership?

To take Gentoo as an example: There's an established mentorship program and a well documented pathway to moving from "random packages in user overlay" to "peer-reviewed packages in guru" to "dev reviewed packages in official repo" to "dev comitting directly to official repo".
There's a whole set of documentation and guidelines on the subject, and right from the beginning there are active developers in the user IRC channel when we have random questions. Hell, asking there often gets official packages fixed in minutes.
Where is any of this stuff for Devuan?

No, it (all 3 daemons, in the right order) is supposed to be started as systemd user-units, with dependency management and supervision. Most distros without systemd ship a variety of (usually shell) hacks to do the same, with varying degrees of reliability...
Devuan ships nothing, and just leaves the mess for the end-user to figure out.

It is not.

You don't "start" alsa, alsa is kernel drivers and doesn't include any daemons to start. Do you actually have any idea what you are talking about?

Imagination does nothing toward Devuan shipping a pipewire package that works out of the box, or solving the OP's problem.

All of this has been discussed thoroughly in the thread I linked above, why are you "imagining" instead of reading that?

Personally I'd prefer no out-of-tree drivers be included by default at all, but given how lazy some users are these days (note the celebration when images with non-free enabled by default were released, because apparently installing nvidia-kernel-dkms is hard), I can see why they do this.

The alternative to removing the package is using dkms to exclude it from being built for whichever $kernel_version is problematic - i.e. dkms remove [module] [-k kernel/arch]. The drawback is that you need to remember you did that, and remember to do it again when your shiny-new kernel is updated.
Better, just backport drivers that work as I mentioned earlier. It takes 5 minutes.

In this case though, you don't need tp-smapi unless you have a thinkpad, and one of a limited set of models at that... Debian with the kitchen-sink thing again.

That's nothing to do with liquorix specifically, the tp_smapi driver version you are trying to build is using an obsolete function name and will break with any kernel >6.14, because:
https://github.com/torvalds/linux/commi … 5ec856c916

This is fixed in tp_smapi v0.45, which is in unstable. If you want to run a kernel newer than the de[bi|vu]an release you're tracking ships, expect that you will need to backport any dkms modules as well.
The process is not particularly complicated, but it is manual work. Do not be lazy and just add the unstable repos to sources.list, without very careful per-package pins this will bork things sooner or later.

Sure it is

Those conflicting packages appear to be from stable and unstable, respectively... So you have an incomplete dist-upgrade you need to finish, or you tried upgrading from stable to unstable directly (which is unsupported), or you have created a franken[debi/devu]an (again) by enabling sources for multiple releases.

All of the those are liable to break apt in fun ways, but you don't listen when people tell you why things like this are a bad idea, so, uhh, enjoy?

1: Pin your target release at priority 1001.
2: Dist-upgrade and --fix-broken, see if it works. If it doesn't (it probably won't), try aptitude's solver first, then resolve remaining conflicts manually (directly with dpkg if needs be).
3: Remove any remaining installed packages from any other release, and any mention of other releases from sources.list.
4: Dist-upgrade and autoremove.
5: Remove your pin.
6: Hope you found all the mess, so it doesn't bite you again later.

You mean everyone hasn't been setting 'browser.ml.enable == false' since this garbage first rolled out? The mind boggles.

Yeah, this is pretty much expected behaviour given the purpose of that plugin. Auto-translating the X11 primary selection is a little unusual, but  understandable if the intent is to provide live translation in a tooltip.
The only real problem I see here is that this behaviour doesn't appear to be mentioned in the project documentation... But then the website is a mess and I only read English, so it's entirely possible I just missed it.

In any case, this is a clipboard-monitoring online auto-translation tool sending clipboard content to a translation service. So what? How else would it work, magic?
If anyone is actually concerned, consider this a wakeup to exercise some garden-variety due-diligence with the software you run. The source code is right there in plain sight.

All the noise here is really because it's using the "insecure" X clipboard functionality (which must be demonised wherever possible), and the servers in question are in China (which is the current political boogeyman). Boring, predictable, yawn, etc.

No shit, Sherlock.
The guy is still a muppet, and his videos are still all shallow clickbait devoid of any interesting technical merit. They range from "look, controversy" to "shiny new thing released"... Both kinds of "news" I can get elsewhere without the hype and hyperbole.

It's blindingly obvious what he's getting at from the title, no need to watch it.
I'll go out on a limb and guess that this is just a "reaction video" clicking through some website he found, the "joke" probably isn't even his... As usual.

Hate to break it to you, but both eudev and elogind are systemd, or at least "liberated" parts of it. What both those (Gentoo, hence the "e") projects do is split out systemd components that we want into standalone packages.

Sure, for some definition of "functioning".

AFAIK X only needs [e]udev for video and input device permissions, you could set those up manually (and fool apt with equivs)...

[e]udev doesn't create the devtmpfs at /dev, the kernel does. What udev does do is handle dynamic creation of nodes there for device hotplug.

Way back when, /dev was a static directory and we made device nodes by hand when we installed new hardware (also automatic module loading when the corresponding node was accessed).
Then came devfs, where /dev was a virtual filesystem managed by the kernel and you mostly didn't need to think about mknod (unless you were fancy and had USB).
Finally udev (now absorbed into systemd) was created to deal with all the newfangled hotplug stuff, so now nobody even knows what it is they just plugged in or what driver it uses .

I know of people running Gentoo and Slackware systems with static /dev, but how well that works for Devuan is a good question. I see no reason it shouldn't, but you will obviously give up (most) hotplug functionality and anything else in the udev rules.

TPM functionality isn't necessarily anti-freedom in itself, but it does provide some fairly obvious mechanisms for abuse... Personally I am almost as sceptical of Canonical's motives as I am of IBM/Redhat, and I suspect this will be yet another attempt to get a foot in the door in for something more unpleasant in the future.

IOW, same shit, different day. Same sub-optimal solutions.
The general public doesn't think enough to see through the "for your safety" bullshit or care enough to resist, and the legislators are either completely tech-illiterate or bought-and-paid-for.
So aside from (futile IME) "education", the only real answer is the same as it has always been: Reject these technologies, wear the "less safe convenient" hair-shirt, and when things get really screwed up - help build something that is less so.

Also, like, give the FSF and DBD some money or something. You get fun badges and stuff.

Your input website is without value visitors unless you can provide an alternative solution.

FTFY.