Forum

Bonjour,
J'ai réussi une mise à jour de mageia 6.1 64b sur ce PC vers la dernière version disponible 7(.1) on fait ça avec urpmi et j'ai suivi les conseils en faisant d'abord le test. Tout a l'air OK, un peu long mais je n'ai pas la fibre.

Reste en suspens l'accès au scanner, un "antiquité" à savoir l'epson perfection 4180 photo qui a besoin d'un driver spécifique epson kowa déjà ancien n'existant qu'en 32 bits (à ma connaissance) alors que j'ai un système 64 bits.
J'avais la chaine xsane, sane ... (iscan) driver-epkowa avec mageia 6.1 et les précédents en 32 bits, ce qui m'oblige d'ailleurs à avoir un tas de librairies 32 bits qui vont avec. Pas de pb, mais une de ces dernières à savoir libpango coince à l'appel de xsane.
xsane: symbol lookup error: /lib/libpango-1.0.so.0: undefined symbol: g_log_structured_standard

libpango est en version : 1.43.0-3.1.mga7 en 32 bits (i586) et ne semble pas réclamer de dépendance.
Une recherche web avec /lib/libpango-1.0.so.0: undefined symbol: g_log_structured_standard ne donne pas grand'chose. Un pb de prod cette librairie qui existe en 64 bits en même version : no pb avec ??

Est-il possible d'utiliser xsane64b + sane 64 avec un driver proprio 32bits ?????
C'est un pb récurrent pour moi depuis mageia 4 .....

Merci pour toute aide.
BM

Bonjour bernish

Oui, c'est mon cas avec une imprimante Brother , pilote propriétaire en 32b, et le scanner fonctionne (xsane et simple scan pour ma part – je trouve qu'il fait le travail proprement et simplement, comme son nom l'indique- en 64b)

Ce problème avec pango semble apparaître sur toutes les sortes de distributions Gnu-Linux, de façon récurrente et au gré des mises à jour.

Sans garantie, mais ça ne mange pas de pain, à ta place j'essaierais de réinstaller au moins pango, sane et xsane en ligne de commande ; chez moi après la mise à jour vers Magéia 7, 2-3 logiciels ne fonctionnaient plus, alors qu'ils étaient la dernière version disponible.
Mais la réinstallation a entrainé l'installation des dépendances correctes et ça a réglé les problèmes
Si ça pouvait être ça...

Édité par Girotte Le 20/10/2019 à 16h45

J'ai beau chercher, je ne vois pas l'option pour réinstaller avec urpmi. Il faut dire que ce n'est pas lui que j'utilise couramment.
Avec dnf (installé d'office en principe), c'est tout simple :
Toutes ces commandes sont en root.
dnf reinstall <nom du paquet> <nom du paquet n°2 éventuel>
(autant de paquets qu'on veut)

En revanche, j'ai remarqué qu'avoir paramétré les médias de téléchargement pour urpmi ne suffisait pas pour dnf. On peut faire, pour voir la liste des dépôts avec la mention "activé" ou "désactivé":
dnf repolist all
Puis pour chaque dépôt qu'on veut activer :
dnf config-manager --set-enabled <nom du dépôt>
par exemple :
dnf config-manager --set-enabled mageia-i586
(voir dans les résultats de la commande dnf repolist all, on peut jouer du copié-collé)

(Remarque : pour désactiver un dépôt :
dnf config-manager --set-disabled <dépôt>)

Édité par Girotte Le 20/10/2019 à 17h30

Bon, j'ai beaucoup avancé en suivant un protocole que j'avais mal exécuté jusqqu'ici. il faut :
installer Xsane, sane (plus exactement sane-frontends et sane-backends-iscan) le tout en 32 bits (sane-backends est installé en 64b par la mise à jour 6 ->7 et est utilisé par un tas de programmes mais incompatible avec les autres paquets ici).

Dans /etc/sane.d/dll.conf il faut que epkowa apparaisse non commenté
Dans /etc/sane.d/epkowa.conf il suffit que la directive usb soit présente

On peut alors exécuter sous root

Code TEXT :

# rpm -i iscan-plugin-gt-f600-1.0.0-1.c2.i386.rpm

dans le répertoire où on l'a téléchargé depuis le site proprio des driver epson.

Puis

dernière version de iscan epson toujours téléchargé du site des drivers.

Ce dernier paquet peut demander des dépendances en 32 bits qu'on peut obtenir avec le CCMageia.
Il m'a fallu quand même un peu tâtonner pour pouvoir exécuter "iscan" vu que j'avais quelques résidus de mageia6 - pas trop galère, mais ça prend du temps, et la tête, quelques core dump au passage sans gravité.
iscan aka "image scan for linux" et xScanimage fonctionnent avec des fenêtres style gnome (je suis avec plasma KDE) sans trop de pb.

Xsane 32bits coince toujours pour une histoire de compatibilité 32/64b :



certains paquets sont en 64 et ne peuvent pas cohabiter avec du 32
A suivre, mais c'est en bonne voie. Il se peut que je doive reproduire xsane avec les librairies statiques mais c'est à voir. Je ne sais plus si j'ai dû le faire pour mageia6, mais j'avais bien quelques .devel 32bits dans ma base rpm téléchargés que j'ai enlevés lors de la mise à jour.
CDT
(maj message)
1)
J'ai désinstallé quelques programmes relatifs à sane 64bits. iscan et xscanimage fonctionnent.
Pour xsane : j'ai "transformé" libpixbufloader-xpm.so de lib64 en son homonyme de lib (32) (la manip est osée!) dans ce cas : xsane fonctionne désormais mais on ne peut pas rester ainsi
Cela signifie sans aucun doute que Xsane "32bits" va chercher des librairies 64 bits. Peut-on éviter ça ?

2)
Par contre iscan et xscanimage fonctionnent sans cette manip mais sortent aussi bien que xsane le même tas de warning du genre

Code TEXT :

(iscan:9625): GdkPixbuf-CRITICAL **: 22:58:02.969: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
 

entrcoupés de temps enn temps par

Code TEXT :

WARNING **: 22:58:02.969: Invalid borders specified for theme pixmap:
        /usr/share/themes/Breeze/gtk-2.0/../assets/button.png,
borders don't fit within the image
 

Tout ça donne une bonne salade !
Si vous avez des idées (claires, ce n'est pas trop mon cas) merci de me les faire connaître.

Édité par bermisch Le 22/10/2019 à 23h34

Hello :
Une idée quand même : si on veut télécharger et installer
sane-frontends en i586 on a dans une fenêtre :



ce qui semble être à l'origine du pb de librairie déjà évoqué
A suivre...

Dernières investigations :
De toute évidence on utilise dans xsane, iscan et xscanimage la librairie
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/.....so pour le chargement d'images alors que tous ces programmes sont écrits "en 32 bits".
Si on "s'amuse" à substituer le contenu du répertoire .../loaders de la librairie /lib64 par celui de la libraire /lib en 32 bits tout fonctionne à peu près bien pour les 3 programmes ci-dessus mais pratiquement plus rien en dehors d'eux, si bien qu'il faut rétablir la situation initiale rapidement après un scanning.
Le mystère est "qui est le coupable" probablement dans une des dépendances commune des trois programmes.
Je réfléchis.

Bonjour,
J'ai réussi (à peu près) à résoudre le problème.
Dans le fichier /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache on trouvait des lignes
"/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so"
référençant les binaires à exécuter

Ce qui provoquait une erreur quand le .so devait être chargé pour traiter une image .xpm et exécuté par un programme en 32 bits.
En modifiant les lignes /usr/lib64/... en /usr/lib/.. les erreurs disparaissent et xsane (32 bits) fonctionne correctement et iscan comme xscanimage ne sortent plus des bordées d'erreur.

Comment la référence à /usr/lib64 a pu apparaître dans /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache ?
Le script /usr/bin/gdk-pixbuf-query-loaders semble s'être emmêlé les pinceaux. Il existe d'ailleurs deux versions du binaire gdk-pixbuf-query-loader une dans dans /lib/gdk-pixbuf-2.0 /bin en 32 bits et une autre dans /lib64/gdk-pixbuf-2.0/bin en 64 bits
J'arrête là l'enquête et considère que le pb est (+/-) résolu. A l'origine probablement l'ordre dans lequel on a introduit les différents .rpm "à la main"
"C'était donc ça!"
Je note quand même que corriger ce pb n'est pas à la portée d'un newbie. Il faut dire que je suis déjà vieux dans le métier et que tomber là dessus pour certains peut être impossible à résoudre sans une aide avisée.

Excuses pour le dérangement. Mais la 7.1 est très chouette par ailleurs !

Édité par bermisch Le 28/10/2019 à 11h39

Quel fin limier !
Manifestement, le fichier loaders.cache est, comme tu l'as compris, construit par la commande gdk-pixbuf-query-loaders. Celle-ci est exécutée à la fin de l'installation du paquet, de ce que je comprends du spec :

N'as-tu pas essayé de l'exécuter manuellement ?

Hello papoteur,
J'ai regardé dans mon .bash history et j'ai bien

AMA c'était incorrect, Juste après l'appel d'un xsane (32b?) il y a quelque temps.
Le fait est que xsane crashait avant cela mais ça n'a pas avancé les choses vu que cette commande qui est un script bash a besoin qu'on lui spécifie la librairie en paramètre sinon c'est /lib64 " en dur.

Evidemment, j'ai exécuté le bash et pas le /lib/... d'où mon embrouille.
Peut-être pas la dernière ???
La prochaine fois f'rez attention ! Pas de discussion ! Contravention !
CDT