That’s a totally separate error… It can happen that the keyring itself is so out of date that it blocks the update, and with it the upgrade to a newer keyring. For this reason it’s often safer after a long time to do pacman -Syu cachyos-keyring (pretending I guesse right and that’s the name of the package) first to avoid the whole update getting blocked by signature with an out-of-date-key. Yet that should not apply here.

But Ignoring the warnings you get for now… This looks like vulkan-mesa-implicit-layers did not replace vulkan-mesa-device-select but now the 32bit library version lib32-vulkan-mesa-device is supposed to be replaced by cachyos/lib32-vulkan-mesa-implicit-layers, which would in turn need vulkan-mesa-implicit-layers as a dependency.

What happens when you answer ‘no’ to that first question? Alternatively, is there anything keeping you from installing vulkan-mesa-implicit-layers (thus replacing vulkan-mesa-device-select)?

Not using CachyOS but Arch… but after a long break from updates you should probably start by checking if your mirror is still up-to-date (doesn’t look like it when you local stuff is newer…).

Again… not my OS but this seems to be the file you could use to manually replace the mirrorlist in your /etc/pacman.d/ directory.

Edit: Also just to be sure… -Syyu will force a refresh of all databases (doubling the u would force “upgrading” even it’s an actual downgrade from your local version). You normally don’t do it because it puts extra load on the mirror, but in case of problems it won’t hurt.

PS: For the future (and although partial upgrades are normally to be avoided)… after a long break in updating the key breaking points are mirrors, then keyfile (they can be so out of date that you can’t start the update; so do them separately first - If CachyOS keeps with its usually sane naming structure the package you should first update, just to be sure, will named cachyos-keyring, but no guarantees there…), then pacman itself…

The latter is very rare but there have been a handful of major changes in pacman’s lifetime that broke down compatibility after a long time. Arch keeps a static pacman version available for these cases, so you can still do a proper update to fix it, but don’t know where CachyOS keeps it’s equivalent.

2nd Edit for sake of completion: A quick searched seems to indicate that CachyOS does not have a separate static pacman. So if everything else fails and it’s an actual problem of pacman itself (and only then, so please don’t try that just now) https://pkgbuild.com/~morganamilo/pacman-static/x86_64/bin/pacman-static has the static standalone version of pacman. So you can download this file, make it executable and run it.

It’s worse than useless.

There is barely a lack of third party video evidence. And in cases where we don’t have those, a body cam is useless… unless there is a guarantee a) they are running and b) the footage is accessible.

So handing out body cams will not help in any way. I won’t be a deterrence for officers if they have control when to activate it. It will rarely produce footage incriminating officers and if it does that footage will be held back anyway.

There is however a reasonable chance to capture enough footage that can be framed (or straight out manipulated) to show those violent protesters they crave for their narrative.

💀 Manjarno

That’s creative way of USdefaultism for once…

Given the 4% Lizardman’s Constant (and the additional 7% of the US who don’t know where they stand on the matter of Lizardman ruling the world…) that’s actually quite low.

The ‘O’ stands for manipulation…

Being lazy and having update-related issues with nextcloud too often for my taste I went back to the basics (as that’s all I actually use 99% of the time) with Syncthing for file syncing and Radicale for caldav/carddav.

rolling release (for gaming)

Seriously… after all these years without some pesky version upgrade screwing things up I couldn’t bring myself to install a non-rolling distro on any device I actively use.

And I only recently learned that a separate vimdiff command exists (not that it makes a difference over vim -d)…

Arch live ISO gives you arch-chroot which does all the binds automatically

That isn’t neccessary. nvidia-open automatically replaced nvidia (same for nvidia-open-dkms, nvidia-open-utils etc) when 590 hit and installing any of those nvidia-580xx packages will ask to remove them because they conflict.

It should be illegal to use pacman without pacman-contrib installed for checkupdates (no risk of partial upgrades) and for comparing and merging .pacnew-files with pacdiff…

While the distinction can be important, the snapshots from right before the update are exactly what you want in this case over some actual but always somewhat outdated real backup

“Doesn’t help” is a bit unspecific for an actual answer.

I simply installed nvidia-580xx-dkms and nvidia-580xx-utils and that was all. If you did not already use the dkms-driver package before you of course also need <your kernel>-headers and dkms (but the latter should be pulled as a dependency for nvidia-580xx-dkms anyway)…

Which automatically asks for the removal of nvidia-open (the standard package for the base linux kernel) or nvidia-open-dkms and nvidia-open-utils that replaced the earlier nvidia, nvidia-dkms, nvidia-utils packages when 590 hit.

PS: If you still have stuff using 32bit add (you might have guessed the scheme by now…) lib32-nvidia-580xx-utils to replace lib32-nvidia-open-utils

nvidia was automatically replaced with nvidia-open (also nvidia-open-lts, nvidia-open-dkms etc).

Simply installing nvidia-580xx-dkms, nvidia-580xx-utils (and lib32-nvidia-580xx-utils because Steam still needs all that 32bit stuff), which automatically removes the 590-open stuff because of conflicts, should be all you need to do.

PS: And of course your kernel’s header package if you did not use dkms before… (dkms should be pulled as a dependency automatically)

“We want to show the automotive industry that sustainable and practical design really is achievable”

Funny to think they don’t know already. But sustainable isn’t the goal, maximising profits is.

Sure, there is a usecase for this. But sperate buffers and varying (and often unintuitive) behavior of software and which buffer is used how is a much bigger hurdle for people not used to it than that “middle-click pasting is confusing” bullshit…

No, what actually makes sense is a proper unification of different copy/paste buffers that is nowadays still mostly improvised and only achieved through very different 3rd party tools (for me using the panel from xfce it’s xfce4-clipman for example that keeps highlighting text and middle-click buffers synchronised with ctrl-c/ctrl-v or ctrl-insert/shift-insert…).

The problem is not accidently pasting something with a middle-click, but not knowing what is in one buffer, what is in another one and which one a program is using.

Look up “jurisdiction”…