Libtiiff problem upgrade

Topic: Libtiiff problem upgrade (Read 1572 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Libtiiff problem upgrade

05 January 2023, 23:24:05

Hello, after last update i have a problem. I cannot run apps as firefox

firefox
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
libtiff.so.5: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

and i cannot install some apps

Code: [Select]

 sudo pacman -S imagescan sane-airscan xsane xsane-gimp sane
resolving dependencies...
conflict search...
error: failure to initialize a process (failure to resolve dependencies)
:: installation of libtiff (4.4.0-4) violates the 'libtiff=4.5.0' dependency required by lib32-libtiff

Code: [Select]

yay libtiff
...
5 multilib/lib32-libtiff 4.5.0-1 (215.1 KiB 681.3 KiB) (Installed)
    Library for manipulation of TIFF images (32-bit)
2 extra/libtiff 4.5.0-1 (1.2 MiB 6.2 MiB) (Installed)
    Library for manipulation of TIFF images
1 world/libtiff 4.4.0-4 (879.0 KiB 2.9 MiB) (Installed: 4.5.0-1)
    Library for manipulation of TIFF images
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
...

Any idea to solve this crash?

Re: Libtiiff problem upgrade

Reply #1 – 05 January 2023, 23:39:26

I'm also having problems with libtiff and with two other packages which are lib32-libpcap and lib32-ncurses. I'm not able to -Syu for this reason.

Re: Libtiiff problem upgrade

Reply #2 – 05 January 2023, 23:52:41

i was not able to Syu so
i did sudo pacman -Rdc sane...
after upgrade i have a semi-crashed system.

Re: Libtiiff problem upgrade

Reply #3 – 06 January 2023, 00:02:08

Temporary solution ->

Code: [Select]

sudo downgrade lib32-libtiff
to version  4.4
&
sudo downgrade libtiff
to version 4.4

Re: Libtiiff problem upgrade

Reply #4 – 06 January 2023, 02:40:10

This is an issue of having manually selected the Arch version other the Artix version during the installation with yay. When using yay be sure to select the Artix repository versions if they exist over the Arch ones even if they are older. Otherwise one will get lots of breakages over time due to the fact that Artix follows Arch thus is always a step behind Arch during updates. The delay is usually not too long so be patient. Or get the packages affected and compile them yourself and install them if you are in a hurry.
The yay and other AUR tools are like a double edge sword, it can cut a path for you or it can cut your head off. I think that system updates and almost everything should be done through pacman. The etc/pacman.conf file should have the Artix repositories listed first then the Arch ones. Yay and other AUR helpers should only be used for the purpose of get stuff in AUR and compile Arch community stuff. Using yay to update the main shared system library like libtiff is just asking to have major issues with stuff since one can mistakenly pick the Arch versions causing these type of issues.
Please note neither Arch nor Artix supports the use of AUR helpers of any description. These tools have to used with caution since they can destroy as well as build stuff.

Re: Libtiiff problem upgrade

Reply #5 – 06 January 2023, 03:59:12

Although certainly a little caution and knowledge is required with AUR helpers, because not all AUR packages work in a non-systemd environment, and I'm using Pakku not Yay here, they still in general shouldn't install packages from the wrong repo unless it was explicitly specified by e.g. prepending extra/ or if the repo is enabled above the Artix one in /etc/pacman.conf, but either of those things would equally apply to using pacman alone. Most AUR helpers wrap pacman, not replace it, which is to say they run the pacman binary and pass on the supplied arguments to do the system upgrade (or whatever) so it happens exactly the same as if you wrote pacman -Syu in the terminal yourself, and they only add on the required functionality to work with AUR packages in their own code, providing a similar user experience to that which you have with regular repo packages, except perhaps the wait while they build

Re: Libtiiff problem upgrade

Reply #6 – 06 January 2023, 07:42:56

Quote from: ####### – on 06 January 2023, 03:59:12

and I'm using Pakku not Yay here, they still in general shouldn't install packages from the wrong repo unless it was explicitly specified by e.g. prepending extra/ or if the repo is enabled above the Artix one in /etc/pacman.conf, but either of those things would equally apply to using pacman alone. Most AUR helpers wrap pacman, not replace it,

That's my experience. Somewhat randomly, but at a guess around 50% of the time, I use yay to do full system updates. It don't remember yay ever causing me an issue installing from the wrong repo.
As you say it wraps pacman but updates my AUR stuff as well. Which is convenient.

Re: Libtiiff problem upgrade

Reply #7 – 06 January 2023, 11:46:31

Arch moved libtiff to testing, we haven't yet due to problems with some packages compiling. I expect this problem to be resolved as soon as we get the problem packages to build.

Re: Libtiiff problem upgrade

Reply #8 – 06 January 2023, 11:58:48

How do you search aur packages with pakku?

i have another problem!

Code: [Select]

pakku -Syyu
 :: Synchronizing package bases...
 system 263,7 KiB 172 KiB/s 00:02 [####################################] 100%
 world 2.0 MiB 255 KiB/s 00:08 [####################################] 100%
 galaxy 2.7 MiB 268 KiB/s 00:10 [####################################] 100%
 extra 1746.6 KiB 274 KiB/s 00:06 [####################################] 100%
 community 7.2 MiB 608 KiB/s 00:12 [####################################] 100%
 multilib 163.4 KiB 170 KiB/s 00:01 [####################################] 100%
 universe 123.2 KiB 15.9 KiB/s 00:08 [####################################] 100%
 omniverse 104.3 KiB 30.1 KiB/s 00:03 [####################################] 100%
 moksha 58.0 KiB 29.6 KiB/s 00:02 [####################################] 100%
:: Initiate full system upgrade...
attention: firefox: local (108.0.2-1) newer than [world] (108.0.1-1)
attention: libsndfile: local (1.2.0-1) newer than [world] (1.1.0-3)
caution: wine-staging: package upgrade override (6.22-1 => 7.22-1)
resolving dependencies...
caution: inability to find "libpcap=1.10.2", dependency of "lib32-libpcap"
caution: unable to find "ncurses=6.4", dependency of "lib32-ncurses"
:: Unable to upgrade the following packages due to unresolved dependencies:
      lib32-libpcap lib32-ncurses

:: Omission of the above packages from the upgrade? [y/N] n
Error: failure to initialize the process (failure to resolve dependencies)
:: failure to satisfy 'libpcap=1.10.2' dependency required by lib32-libpcap
:: failure to satisfy dependency 'ncurses=6.4' required by lib32-ncurses

Re: Libtiiff problem upgrade

Reply #9 – 06 January 2023, 12:33:44

Half educated guess. You have the arch, multilib repo, versions of these packages ?

Code: [Select]

sudo pacman -S lib32/lib32-libpcap lib32/lib32-ncurses

If you are ever given a choice between an artix repo or arch repo when installing and updating pick the artix repo unless you have a good reason not to.

Edit:whoops wrong way round ! Fixed

Re: Libtiiff problem upgrade

Reply #10 – 06 January 2023, 12:56:16

jspaces has pretty much nailed it as something has gone distinctly awry when updating previously, hence firefox is on 108.0.2-1 on your machine and that's from arch, but it should be 108.0.1-1 from artix repo (as it is on the machine i'm typing from, which has no issues). That just has a massive knock on effect to such things as the ncurses package etc too. So to get to the core of your issue, nail why and how something simple like firefox got to that version (it was only updated yesterday, so it was between yesterday and you posting this that it happened and would have required a manual intervention to update)

Re: Libtiiff problem upgrade

Reply #11 – 06 January 2023, 15:12:16

i will keep only artix repos...i do not even know why i had added arch repos...
i will come back with news about the above problem with ncurses and libcap

Now I am using
lib32
system
world
galaxy
ps i saw many people use extra and community...is there any reason?

Re: Libtiiff problem upgrade

Reply #12 – 06 January 2023, 15:42:58

Quote from: AntonyZ0 – on 06 January 2023, 15:12:16

ps i saw many people use extra and community...is there any reason?

Artix does not have all the packages in the repo's that Arch does.
So if you need one or more of the Arch packages the easiest solution is enabling Arch.
But if you don't need any of them then there would be no reason to enable the Arch repo's.

Quote from: gavincc – on 06 January 2023, 12:56:16

jspaces has pretty much nailed it as something has gone distinctly awry when updating previously

I'm not sure ? Even with pacman you can be offered a choice between the repo's and if you chose the wrong repo OP's issue can be the result.
Though I have no experience with pakku so I'm not vouching for that. yay, as I said, causes no issue for me. Dumb luck a possibility but I doubt it ?

Re: Libtiiff problem upgrade

Reply #13 – 06 January 2023, 16:31:10

well, as long as the repo's are in a logical order in pacman.conf, even if offered a choice or repo's, the default will always be artix's, so there is no need to manually choose which repo as hitting enter will choose the default for you.

Antony, i have the arch ones enabled due to using a couple of things not in artix (as per what gripped has said), along with octopi and octopi-notifier-qt5 (in aur, i use yay btw) which I've never had an issue with when updating, and it gives a cute little green/red ghost in your systray to inform of updates, (and means i don't bother updating until its well into double figures for pending updates too, reminds me of manjaro years ago, before they went all a bit pamac for some innocuous reason).

Re: Libtiiff problem upgrade

Reply #14 – 06 January 2023, 18:32:59

Quote

I'm not sure ? Even with pacman you can be offered a choice between the repo's and if you chose the wrong repo OP's issue can be the result.

When one uses pacman, one has to specify the whole path to the version if you want to select the Arch versions over the default Artix ones when the Artix repositories listed first. The repository list order is critical.

Code: [Select]

#pacman -S extra/firefox

Thus it is not possible when using "pacman" directly to incorrectly select the Arch version.

Code: [Select]

$ yay -s firefox
13 extra/firefox 108.0.2-1 (64.1 MiB 237.6 MiB) (Installed: 108.0.1-1)
    Standalone web browser from mozilla.org
<Snipped>
4 world/firefox 108.0.1-1 (64.2 MiB 237.7 MiB) (Installed)
    Standalone web browser from mozilla.org
<Snipped>
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==>

So using yay all one has to do is pick the number to do the install. Typing in "13" is much easier to do than typing extra/firefox.
That is why I suggested to first use "pacman -Syu" for system updates and AUR helpers afterwards. I am glad to offer ways that seem logical for the OP to prevent the issue that they posted about. There are many ways to do stuff and everyone is entitled to do as they see fit. In other words, do what works for you.
I just could not but offer my option on this since it just cried out that the OP just did not know any better.