Back to the topic of Shelly: When I had Shelly check for updates a little while ago just for the sake of it, it indicated that the pacman-contrib package needed updating. A cross-check using sudo pacman -Syu revealed that NO updates were available. I went ahead and updated the package in Shelly anyway, since I had explicitly installed it during the initial setup. Strange, where do these discrepancies come from?
what package and source do you have in pacman now? That package hasn’t been updated since December.
I assume it didn’t install the AUR (git) version because that would be absolutely wild.
pacman-contrib 1.13.1-1.2
The version # on the cachyos repo package is a little weird.
But pacman.conf should place the architecture specific repos above cachyos if you have a processor that uses them.
I assume you have at least a v3 capable processor. If not, you would’ve always been on the cachyos version anyway.
Did Shelly try to install that version over the optimized repo version?
And just now, another update is being offered to me in Shelly: from pacman-contrib 1.13.1-1.2 to pacman-contrib 1.13.1-2.1
Does Shelly report from which repo these updates are coming from?
yes, it does
So either Shelly is disobeying your pacman.conf or something in there is misconfigured.
Or I’m misunderstanding how repository priority works. As far as I know, if a package is present in two or more repositories, then the package from the highest repo in your pacman.conf should be installed regardless of version number. In which case, your v3 capable processor should prioritize cachyos-extra-v3.
Might as well take a look inside your /etc/pacman.conf to make sure everything is good.
[cachyos-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos-extra-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos-core-v3]
Include = /etc/pacman.d/cachyos-v3-mirrorlist
[cachyos]
SigLevel = Optional TrustAll
Include = /etc/pacman.d/cachyos-mirrorlist
# The testing repositories are disabled by default. To enable, uncomment the
# repo name header and Include lines. You can add preferred servers immediately
# after the header, and they will be used before the default mirrors.
#[core-testing]
#Include = /etc/pacman.d/mirrorlist
[core]
Include = /etc/pacman.d/mirrorlist
#[extra-testing]
#Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
# If you want to run 32 bit applications on your x86_64 system,
# enable the multilib repositories as required here.
#[multilib-testing]
#Include = /etc/pacman.d/mirrorlist
[multilib]
Include = /etc/pacman.d/mirrorlist
# An example of a custom package repository. See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#SigLevel = Optional TrustAll
#Server = file:///home/custompkgs
I haven’t seen SigLevel = Optional TrustAll applied to cachyos before.
Do you know how that got there?
Can you comment that out and attempt the Shelly update again?
I have no idea how SigLevel = Optional TrustAll got in there. Maybe I overlooked something when merging with a .pacnew file in the past… I commented it out, and now Shelly is quiet. Couldn’t I just delete the line entirely?
Yes, I don’t see the harm in getting rid of it. Would be nice to know how it got there. Mostly harmless but it’s interesting that it was causing Shelly to prioritize that repo over your v3 one.
If I find a second I guess I’ve got something to learn about in the pacman.conf man page.
I am very curious how it got there.
Warning
The SigLevelTrustAlloption exists for debugging purposes and makes it very easy to trust keys that have not been verified. You should useTrustedOnlyfor all official repositories.
This installation is just over three weeks old, and I haven’t changed anything in /etc/pacman.conf myself so far (there was no reason to, either). I have no idea how that line got in there.
SigLevel = ...
Set the signature verification level for this repository. For more information, see Package and Database Signature Checking below.
When to Check
These options control if and when signature checks should take place.
Never
All signature checking is suppressed, even if signatures are present.
Optional
Signatures are checked if present; absence of a signature is not an error. An invalid signature is a fatal error, as is a signature from a key not in the keyring.
Required (default)
Signatures are required; absence of a signature or an invalid signature is a fatal error, as is a signature from a key not in the keyring.
What is Allowed
These options control what signatures are viewed as permissible. Note that neither of these options allows acceptance of invalid or expired signatures, or those from revoked keys.
TrustedOnly (default)
If a signature is checked, it must be in the keyring and fully trusted; marginal trust does not meet this criteria.
TrustAll
If a signature is checked, it must be in the keyring, but is not required to be assigned a trust level (e.g., unknown or marginal trust).
Options in both groups can additionally be prefixed with either Package or Database, which will cause it to only take effect on the specified object type. For example, PackageTrustAll would allow marginal and unknown trust level signatures for packages.
The built-in default is the following:
SigLevel = Required TrustedOnly
Just adding some info to the thread if needed for future reference.
So, simply commenting out that line would be the wrong approach. Any other suggestions?
I assume commenting it out reverts it to the default behaviour, so I would keep it commented out until someone who knows more about this can chime in. I am sadly not that person. 
thanks @Dirge , @Privacy_Goblin
Just wanted to add that a quick search found a few cases where guides for Omarchy and Asus laptops/motherboards recommend making this change to add some janky 3rd party repo.
It would be easy for someone to accidentally make this change by copy-pasting terminal commands (or for it to be included in the install instructions by an oblivious package dev).