Pacman error. I can't update the system

Hi. I can’t update

$ sudo pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
warning: archlinux-keyring: local (20230629-1) is newer than core (20230504-1)
warning: nano-syntax-highlighting: local (2020.10.10+10+g1aa64a8-1) is newer than extra (2020.10.10-1)
warning: plymouth: local (22.02.122-11) is newer than extra (22.02.122-7)
:: Replace qemu-virtiofsd with extra/virtiofsd? [Y/n] 
warning: ranger: local (1.9.3+428+g0b77fb8a-2) is newer than extra (1.9.3-9)
resolving dependencies...
warning: cannot resolve "libicuuc.so=73-64", a dependency of "libphonenumber"
warning: cannot resolve "libicui18n.so=73-64", a dependency of "libphonenumber"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "harfbuzz-icu"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "gspell"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "gspell"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "gspell"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "harfbuzz-icu"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "gspell"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "harfbuzz-icu"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "harfbuzz-icu"
warning: cannot resolve "ncurses=6.4_20230520", a dependency of "lib32-ncurses"
warning: cannot resolve "ncurses=6.4_20230520", a dependency of "lib32-ncurses"
warning: cannot resolve "ncurses=6.4_20230520", a dependency of "lib32-ncurses"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "libphonenumber"
warning: cannot resolve "libicui18n.so=73-64", a dependency of "libphonenumber"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "gspell"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "raptor"
:: The following packages cannot be upgraded due to unresolvable dependencies:
      gspell  harfbuzz-icu  lib32-ncurses  libphonenumber  raptor

:: Do you want to skip the above packages for this upgrade? [y/N] 
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'libicuuc.so=73-64' required by libphonenumber
:: unable to satisfy dependency 'libicui18n.so=73-64' required by libphonenumber
:: unable to satisfy dependency 'libicuuc.so=73-64' required by harfbuzz-icu
:: unable to satisfy dependency 'libicuuc.so=73-64' required by gspell
:: unable to satisfy dependency 'libicuuc.so=73-64' required by gspell
:: unable to satisfy dependency 'libicuuc.so=73-64' required by gspell
:: unable to satisfy dependency 'libicuuc.so=73-64' required by harfbuzz-icu
:: unable to satisfy dependency 'libicuuc.so=73-64' required by gspell
:: unable to satisfy dependency 'libicuuc.so=73-64' required by harfbuzz-icu
:: unable to satisfy dependency 'libicuuc.so=73-64' required by harfbuzz-icu
:: unable to satisfy dependency 'ncurses=6.4_20230520' required by lib32-ncurses
:: unable to satisfy dependency 'ncurses=6.4_20230520' required by lib32-ncurses
:: unable to satisfy dependency 'ncurses=6.4_20230520' required by lib32-ncurses
:: unable to satisfy dependency 'libicuuc.so=73-64' required by libphonenumber
:: unable to satisfy dependency 'libicui18n.so=73-64' required by libphonenumber
:: unable to satisfy dependency 'libicuuc.so=73-64' required by gspell
:: unable to satisfy dependency 'libicuuc.so=73-64' required by raptor

I’m no expert, but this:

… makes me think you’ve recently, or relatively recently, switched branches and didn’t do a sync. Or something like that.

In any case, the way to resolve that is to sync either using:

sudo pacman -Syuu

…or:

pamac upgrade --enable-downgrade

…or just wait for the current branch to catch up.

More info:

$ sudo pacman -Syuu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
warning: archlinux-keyring: downgrading from version 20230629-1 to version 20230504-1
warning: nano-syntax-highlighting: downgrading from version 2020.10.10+10+g1aa64a8-1 to version 2020.10.10-1
warning: plymouth: downgrading from version 22.02.122-11 to version 22.02.122-7
:: Replace qemu-virtiofsd with extra/virtiofsd? [Y/n] 
warning: ranger: downgrading from version 1.9.3+428+g0b77fb8a-2 to version 1.9.3-9
resolving dependencies...
warning: cannot resolve "libicuuc.so=73-64", a dependency of "libphonenumber"
warning: cannot resolve "libicui18n.so=73-64", a dependency of "libphonenumber"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "harfbuzz-icu"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "gspell"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "gspell"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "gspell"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "harfbuzz-icu"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "gspell"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "harfbuzz-icu"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "harfbuzz-icu"
warning: cannot resolve "ncurses=6.4_20230520", a dependency of "lib32-ncurses"
warning: cannot resolve "ncurses=6.4_20230520", a dependency of "lib32-ncurses"
warning: cannot resolve "ncurses=6.4_20230520", a dependency of "lib32-ncurses"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "libphonenumber"
warning: cannot resolve "libicui18n.so=73-64", a dependency of "libphonenumber"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "gspell"
warning: cannot resolve "libicuuc.so=73-64", a dependency of "raptor"
:: The following packages cannot be upgraded due to unresolvable dependencies:
      gspell  harfbuzz-icu  lib32-ncurses  libphonenumber  raptor

:: Do you want to skip the above packages for this upgrade? [y/N] 
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'libicuuc.so=73-64' required by libphonenumber
:: unable to satisfy dependency 'libicui18n.so=73-64' required by libphonenumber
:: unable to satisfy dependency 'libicuuc.so=73-64' required by harfbuzz-icu
:: unable to satisfy dependency 'libicuuc.so=73-64' required by gspell
:: unable to satisfy dependency 'libicuuc.so=73-64' required by gspell
:: unable to satisfy dependency 'libicuuc.so=73-64' required by gspell
:: unable to satisfy dependency 'libicuuc.so=73-64' required by harfbuzz-icu
:: unable to satisfy dependency 'libicuuc.so=73-64' required by gspell
:: unable to satisfy dependency 'libicuuc.so=73-64' required by harfbuzz-icu
:: unable to satisfy dependency 'libicuuc.so=73-64' required by harfbuzz-icu
:: unable to satisfy dependency 'ncurses=6.4_20230520' required by lib32-ncurses
:: unable to satisfy dependency 'ncurses=6.4_20230520' required by lib32-ncurses
:: unable to satisfy dependency 'ncurses=6.4_20230520' required by lib32-ncurses
:: unable to satisfy dependency 'libicuuc.so=73-64' required by libphonenumber
:: unable to satisfy dependency 'libicui18n.so=73-64' required by libphonenumber
:: unable to satisfy dependency 'libicuuc.so=73-64' required by gspell
:: unable to satisfy dependency 'libicuuc.so=73-64' required by raptor

The first observation got stolen by our Legendary poster.

However, my second observation is rather more trivial.

  • Option 1. Reboot and restore a snapshot from before you started messing

  • Option 2. If no snapshot is available, then restore from an rsync backup.

  • Option 3. If you don’t have that option, then spend some time learning about how to set up your Snapshots, and also your Backups (separate things).

I have hourly snapshots and daily backups - the only way I notice that they’re running is that I have a conky window appear to tell me the last backup…
2023-07-01 @ 20.29-47
was at Noon today.

But yes, try going with sudo pacman-mirrors --fasttrack && sudo pacman -Syyu after a mirror switch.

  • Just run ‘pacman-mirrors’ to see the status.
1 Like

Well, My crystal ball won’t tell me anything, so I don’t know what’s going on. And your silence and lack of explanation isn’t helping, either.

Please see:

But, do as @Ben said, and sync the mirrors after switching branches:

sudo pacman-mirrors --fasttrack && sudo pacman -Syyuu

this helped me

$ sudo pacman -Syyuu

Thanks for help :wink:

1 Like

What does it do by repeating y,u?

Passing two –refresh or -y flags will force a refresh of all package databases, even if they appear to be up-to-date.

and about u

Pass this option twice to enable package downgrades; in this case, pacman will select sync packages whose versions do not match with the local versions.

All acording to: pacman(8) — Arch manual pages

Then there is:

And also:

https://wiki.archlinux.org/title/pacman

4 Likes

Your error you see are caused by the package database is not matching the mirror - usually it appears when the mirrorlist is recreated by pamac-mirrorlist.timer - but a subsequent syncronization has not been executed.

You do not ever need use the doubled u - as it is a downgrade - and downgrades should only be used under rare circumstances and only if you really know what you are doing.

Some members like to throw the downgrade into every comment they make - I think they believe it is some kind of magic wand - it is not. I think their usage may stem from lack of understanding of the process executed by the package manager library.

If you get error like the one causing this topic the only valid command is

sudo pacman -Syyu
1 Like

But thats simply not true.
There have been packages … for example manjaro-hello that were reverted and hence would never be in sync with the repositories until the user added the extra u.
Theres nothing wrong with that flag - it simply enables downgrades in order to match the mirror.
(this is not the same as performing something like /usr/bin/downgrade)

1 Like

It is me. I recommend that. I’m that forum member. And my reason is simple:

It syncs you system with the packages in the repositories, decreasing the chances of problems occurring.

As I said - there is rare circumstance which warrants it - the manjaro-hello package is one of them.

But it is not necessary with daily usage.

It does - it would be more prudent to update the mirrorlist and run a full system sync.

It is not a problem solver unless a very specific case warrants it - using it as part of regular maintenance or as a troubleshooting tool - is not the intended use.

Any member are free to use the routines that make sense for them - but understanding the cause and the effective fix is important in troubleshooting and in helping other members with their problems.

It might not have meant to be. However, it works. It helps in that it resets everything to know working defaults. If you want to change it after, sure - go ahead. But for “resetting” everything to known, working defaults, it works well.

And let’s face it, I’m not an expert, but I’ve been here just about every day for the last 3+ years now. In that time, I’ve picked up some patterns. Both of questions asked, as well as accepted answers.

I know it’s not a general problem solver. However, I have also found it eliminates user mistakes and found it does wonders.

But, @linux-aarhus, I really respect you, your opinion and your experience, so I guess I’ll stop trying to help, because my way and reasons are upsetting and incorrect.

I think what L-A is saying is if a Syuu “fixes” the system, it’s fixed with tape and glue rather than the actual problem (like pacman-mirrors out of sync) except for a VERY few rare situations.

So. I now NEVER use Syuu or Syyu. I always do them both, Syyuu, every time I ever do anything with pacman… (this is obviously a joke to lighten the mood, I do not)

…how?

2 y’s forces refresh of database regardless of whether it is required (dont use this constantly)

2 u’s allows downgrade when your system package is newer than the one offered by the repos.

Theres no tape, glue, or problem with using either one when required.

You should avoid doing 2 y’s when it is unnecessary … if only to save time and server stress.

2 u’s … really has no downside unless somehow your local version is more stable than the one in the mirrors - rarely the case if a package has been rolled back and you arent specifically using some special 3rd party PKGBUILD in which case it shouldnt be affected by the same package lineage because it would ostensibly use a different name.

Users including 2 u’s with their upgrade who dont have any weird packages will not create a problem … it will not even do anything at all in the vast majority of cases.

(we can maybe create a hypothetical where the naming/version convention becomes warped and so a downgrade is accidentally triggered … though this would indicate a problem with the packaging/distro)

It is, if the problem is that all the mirrors you are connected to are out of sync f ex.
Lets say someone ended up with one single server after doing dumb stuff, and that was out of sync while your system was ahead of it (the removed servers were synced).
That someone was me.

I’m not trying to argue, but this is an example of when the statement is true.

I suppose the above assumes you have a good working mirror - not a faulty or out of date one … but for that matter … so does upgrading … syncing in all forms is an action taken after sorting mirrors. :person_shrugging: