Cher ’nal,
J’ai développé pendant quelques années une bibliothèque Python multi‐plate‐forme d’accès aux scanners (SANE sous GNU/Linux, WIA2 sous Windows). L’année dernière, j’ai entrepris de réécrire cette bibliothèque en C : Libinsane. Cette nouvelle bibliothèque inclut un certain nombre de contournements pour divers pilotes de scanners plus ou moins moisis. Et croyez‐moi, il y en a un paquet, aussi bien sous GNU/Linux que Windows. Le problème est aussi d’assurer un comportement cohérent quelque soit l’API ou le scanner utilisé.
À cette fin, j’ai besoin de beaucoup d’informations sur un maximum de scanners et de plates‐formes différentes. J’ai donc créé une base de données de scanners et un programme de test pour y contribuer facilement. L’année dernière, beaucoup d’entre vous ont contribué et je vous en remercie.
Maintenant que Libinsane est prête, j’aimerais vérifier deux choses : qu’il n’y a pas de régression majeure par rapport à l’ancienne bibliothèque et que des scanners qui n’étaient pas pris en charge auparavant le sont maintenant (gestion de TWAIN, code plus propre, etc.). J’aurais donc à nouveau besoin de vous. Si chaque possesseur de scanner ici présent pouvait prendre cinq minutes pour envoyer un rapport, aussi bien sous GNU/Linux que Windows, ça ferait de moi un développeur heureux, encore une fois :-).
# Envoi de rapport
Posté par InfoLibre . Évalué à 3.
J'ai une page "La connexion a échoué" ???
[^] # Re: Envoi de rapport
Posté par Axone . Évalué à 4.
Pareil
[^] # Re: Envoi de rapport
Posté par Jérôme Flesch (site web personnel) . Évalué à 9.
Yep désolé, le serveur s'est pris les pieds dans le tapis. C'est réparé.
# Problème dépendance
Posté par Axone . Évalué à 3. Dernière modification le 06 septembre 2019 à 14:54.
Sous Linux Suse Leap 15, à l'éxécution :
On est sous glibc 2.26
[^] # Re: Problème dépendance
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
Je construit les binaires sur une Debian stable et je ne la teste pas avec des librairies plus vieilles que celles dans Debian stable / Ubuntu LTS. Ça serait trop de travail pour moi.
Dans ton cas, il reste la possibilité de lancer IronScanner à partir des sources.
[^] # Re: Problème dépendance
Posté par Marc Quinton . Évalué à 3.
un container Docker ?faudra juste gérer un lien sur le device USB.
[^] # Re: Problème dépendance
Posté par Benoît Bailleux (Mastodon) . Évalué à 1.
Mince !
Pourtant, j'ai bien l'impression d'être « dans les clous » par rapport à l'environnement que tu décris :
Et effectivement :
Y a-t-il une solution simple, ou reconstruire l'exécutable à partir des sources est-elle la seule ?
[^] # Re: Problème dépendance
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
Je ne vois que deux solutions malheureusement:
# Erreur
Posté par InfoLibre . Évalué à 1.
J'ai cette erreur :
Je dois installer la glibc 2.28 ? J'ai un paquet glibc-source mais pas de glibc.
# Fait
Posté par matteli . Évalué à 3.
Le lien du rapport à la fin n'est pas cliquable chez moi (mais copiable) mais on s'en fout un peu.
En tout cas, bravo pour ce travail.
[^] # Re: Fait
Posté par Marc Quinton . Évalué à 3. Dernière modification le 21 septembre 2019 à 14:17.
fait ; Epson XP-325 ; https://openpaper.work/en-us/scanner_db/report/354/ ; RAS. Merci.
La procédure est on ne peut plus simple (ca peut dépendre des versions de Linux) :
dans l'application : suivant, suivant, suivant ou répondre a des questions triviales.
milles merci !
# Lib Insane
Posté par ted (site web personnel) . Évalué à -10.
Tu comptes garder ce nom? C'est pour concurrencer libcaca?
Un LUG en Lorraine : https://enunclic-cappel.fr
# libsane et libinsane
Posté par matteli . Évalué à 1.
J'ai pas bien compris.
Est-ce que ce que ces deux librairies sont en concurrences ? complémentaires ?
[^] # Re: libsane et libinsane
Posté par Jérôme Flesch (site web personnel) . Évalué à 5.
Elles sont complémentaires.
Libsane = Librairie pour accéder aux scanners sous GNU/Linux (et FreeBSD, etc). Elle fait partie du projet Sane et fait elle-même appel aux sane-backends: les pilotes. Elle a toutefois un défaut: Le design de la libsane fait qu'elle laisse beaucoup de libertés aux pilotes des scanners, ce qui implique des comportements parfois différents d'un pilote de scanner à un autre.
Libinsane = Librairie pour accéder aux scanners GNU/Linux et Windows. Sous GNU/Linux, elle utilise la Libsane (d'où son nom). L'objectif, en plus d'être cross-platform, est de fournir un comportement cohérent quelque-soit le système d'exploitation, l'API (Sane, WIA, TWAIN, etc), ou le pilote utilisé.
[^] # Re: libsane et libinsane
Posté par raphj . Évalué à 2. Dernière modification le 07 septembre 2019 à 21:15.
Qu'est-ce qui fait qu'unifier les comportements des scanners n'est pas intéressant / possible directement dans la libsane ? Compatibilité avec les pilotes existants qu'il n'est pas forcément possible de mettre à jour ?
[^] # Re: libsane et libinsane
Posté par Jérôme Flesch (site web personnel) . Évalué à 3.
En fait il y a une légère différence d'objectif entre libsane et libinsane:
- Libsane cherche à apporter un support pour un maximum de périphériques d'acquisition d'images, sans trop se soucier de quel type de périphériques il s'agit exactement ou de comment les applications vont interagir avec.
- Libinsane cherche à supporter les mange-papiers (et que les mange-papiers) le mieux possible, en fournissant un protocole précis pour interagir avec eux.
De ce que j'en ai vu, la libsane passe les appels des applications quasi-directement aux backends (pilotes). On pourrait rajouter une surcouche directement dans la libsane pour essayer de normaliser tout ça, mais on risquerait de perdre en flexibilité: Parce-qu'elle impose très peu aux pilotes, pratiquement tout ce qui génère une image peu être intégré dans la libsane. Il y a même un backend v4l (video4linux ; support des caméras ; désactivé par défaut dans Sane).
Deux exemples:
- La plupart des backends Sane propose une option
source. Mais la libsane ne normalise pas du tout les valeurs possibles pour ce champs. Cette option acceptera généralement les valeursFlatbedetAutomatic Document Feeder. Mais il y a par exemple les scanners Canon CanoScan N1240U/LiDE30 qui ont pour sources possiblesNormal,TransparencyetNegative. Seule la première valeur est pertinente dans le cas de Libinsane. Les autres marcheront peut-être sur un malentendu mais ne sont pas officiellement supportées.- La plupart des backends Sane propose les options
tl-x,tl-y,br-x,br-ypour définir la zone à scanner. Le backend v4l) ne les proposent pas. La libinsane devrait fonctionner même si ils sont absents, mais c'est plus un coup de bol qu'autre chose.[^] # Re: libsane et libinsane
Posté par raphj . Évalué à 3. Dernière modification le 07 septembre 2019 à 22:36.
Merci pour la réponse.
C'est bien gentil de vouloir tout prendre en charge, mais s'il faut se payer des adaptations spécifiques aux modèles dans l'application utilisant libsane, ça limite l'utilité… Ça donne l'impression que la libsane n'est pas la couche d'abstraction entre le matériel et l'application qu'on voudrait qu'elle soit, et c'est un peu comme si l'application devait implémenter un bout de pilote pour chaque matériel. Finalement qu'est-ce que c'est, la libsane ? Une abstraction, mais pas complète ? Une abstraction qui fuit beaucoup trop pour que ça soit vraiment pratique ??
On pourrait imaginer que la libsane puisse fournir une abstraction uniforme pour tous les matériels qui se ressemble, avec éventuellement des interfaces optionnelles pour accéder aux fonctionnalités spécifiques et des valeurs par défaut pour avoir un fonctionnement de base correct… CUPS semble bien y arriver pour les imprimantes, pourquoi pas un fonctionnement similaire pour les scanners ? Et en fait c'est ce que tu as l'air de faire dans libinsane, donc quelque part c'est que c'est possible, et ça paraît bizarre que ce boulot ne soit pas fait dans la libsane. J'imagine qu'il y a des choix historiques et que ça serait difficile de changer les choses sans tout casser de toute façon.
En tout cas merci pour ce travail sur la libinsane, ça paraît en effet nécessaire. Est-ce q'une interface pour les pilotes pour rendre le passage par la libsane optionnel dans la libinsane aurait du sens ?
# Cinq minutes?!
Posté par Snark . Évalué à 2.
J'ai lancé le programme, il en est à 176 pages scannées… je commence à en avoir un peu marre… il faut que je patiente encore ou il y a un problème?
[^] # Re: Cinq minutes?!
Posté par matteli . Évalué à 1.
Il a scanné une seule page chez moi.
[^] # Re: Cinq minutes?!
Posté par Jérôme Flesch (site web personnel) . Évalué à 6.
Ah, c'est .. gênant. Sur un scanner à plat, il devrait s'arrêter après la première page. Sur un scanner à bac d'alimentation, il devrait s'arrêter une fois le bac vide.
Lorsque IronScanner est lancé depuis un terminal, il indique qu'il met ses traces dans un fichier temporaire. Pourrais-tu m'envoyer ce fichier à jflesch@openpaper.work s'il-te-plaît ? (deux ou trois pages de scans suffiront ;).
# Commentaire supprimé
Posté par Anonyme . Évalué à 7. Dernière modification le 06 septembre 2019 à 18:43.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Vieux problème
Posté par Jérôme Flesch (site web personnel) . Évalué à 6.
Je vais jeter un coup d'œil au code de Gsane, des fois que tu avais des fixs que je n'ai pas encore :)
Il ne me semble pas. Et ce n'est pas une mince affaire parce-que je suppose que ça implique de refaire une passe sur tout les backends/pilotes, et comme il y en a certains qui sont propriétaires (Brother par exemple) …
Arf. Je note que selon la version de PIL, on peut accéder à
PIL.Imagesans faireimport PIL.Image:-)C'est rectifié. Merci de me l'avoir signalé.
# cannot execute
Posté par papap . Évalué à 2.
Chez moi, ça fait ça:
bash: ./ironscanner: cannot execute binary file: Erreur de format pour exec()
[^] # Re: cannot execute
Posté par Jérôme Flesch (site web personnel) . Évalué à 3.
Le binaire IronScanner est construit pour amd64 uniquement. Tu ne serais pas en i386 sur ta machine par hasard ?
Si c'est le cas, il reste la possibilité de lancer IronScanner à partir de ses sources.
[^] # Re: cannot execute
Posté par papap . Évalué à 2.
marche pas non plus, il manque des packages
Tant pis
# Code source
Posté par InfoLibre . Évalué à 1. Dernière modification le 06 septembre 2019 à 19:01.
Bon, pas mieux avec le code source, j'ai l'erreur :
virtualenv -p python3 --system-site-packages venv
make: virtualenv: Command not found
Makefile:79: recipe for target 'venv' failed
make: *** [venv] Error 127
[^] # Re: Code source
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
Effectivement, dans les instructions, il manquait le paquet
virtualenv. Merci de me l'avoir signalé. C'est rectifié.[^] # Re: Code source
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Moi, j'ai ça :
Traceback (most recent call last):
File "launcher.py", line 6, in
File "", line 983, in find_and_load
File "", line 967, in _find_and_load_unlocked
File "", line 677, in _load_unlocked
File "/usr/local/lib/python3.7/dist-packages/PyInstaller/loader/pyimod03_importers.py", line 621, in exec_module
File "ironscanner-2.0-py3.7.egg/ironscanner/main.py", line 19, in
File "gi/init_.py", line 129, in require_version
ValueError: Namespace GdkPixbuf not available
"La première sécurité est la liberté"
[^] # Re: Code source
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
'fectivement, j'avais manqué quelques autres dépendances (GTK, GdkPixbuf notamment). C'est rectifié.
[^] # Re: Code source
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je n'ai pas compris ce que tu as mis à jour. Je dois changer quoi de mon coté ?
"La première sécurité est la liberté"
[^] # Re: Code source
Posté par Jérôme Flesch (site web personnel) . Évalué à 2. Dernière modification le 09 septembre 2019 à 10:31.
En fait j'ai cru que tu avais voulu lancer IronScanner depuis ses sources comme rapido l'avait fait. Je viens de réaliser que toi tu as utilisé le binaire IronScanner.
Toutes les dépendances du binaire devrait être incluses dedans. Cependant il y a visiblement un soucis dans le packaging de IronScanner qui fait qu'il cherche quand même à utiliser quelques librairies du système.
En attendant que je trouve comment régler ça proprement, je pense qu'installer les paquets suivants devrait régler le problème:
[^] # Re: Code source
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
J'utilise mageia. gdkpixbuf et autres sont installés, mais le binaire n'est toujours pas content. La compilation des sources échouent aussi :
alors que sane-backends est installé.
"La première sécurité est la liberté"
[^] # Re: Code source
Posté par joel . Évalué à 1.
Je suis, moi aussi, sous Mageia6.
Après installation de l'executable Linux
./ironscanner répond :
[13840] Error loading Python lib '/tmp/_MEIfGs2po/libpython3.7m.so.1.0': dlopen: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/_MEIfGs2po/libpython3.7m.so.1.0)
glibc est installé.
J'ai installé libpython3.5 (mageia ne me proposant pas libpython3.7), mais ça ne change rien…
[^] # Re: Code source
Posté par InfoLibre . Évalué à 1.
Bon, j'ai passé cette étape mais ça ne scanne pas, il y a d'autres erreurs : https://framabin.org/p/?0fcd62637f6a441d#IsAGDE9hNhA970QxJEGv0SIsGZFWWdgHbfuqlOEqTMo=
[^] # Re: Code source
Posté par anubis . Évalué à 1.
Je ne connais pas bien le fonctionnement mais il semble que ce soit un problème de droits, ton utilisateur est-il bien dans le groupe 'scanner' ?
Est-ce que tu parviens à scanner avec un autre programme type simple-scan ?
aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join
[^] # Re: Code source
Posté par Jérôme Flesch (site web personnel) . Évalué à 3.
J'en profite pour clarifier un truc rapidement: Même si le scan échoue, IronScanner vous laisse soumettre un rapport de scan. Personnellement ça m'arrange si vous le soumettez quand même. Le site openpaper.work présente les informations d'une façon plus pratique pour moi et fournit des statistiques sur ce qui marche et ce qui ne marche pas.
Je suppose que c'est cette trace qui t'as fait pensé ça:
source->get_value() failed: 0x40000008, Access denied? Mais en fait c'est un peu plus fourbe que ça.Si c'était un problème de droit, il ne verrait même pas le scanner.
Là il le voit, mais n'arrive pas à accéder à la valeur de l'option
source. Quand le programme tente de sélectionner la source, un des composants de la Libinsane cherche à s'assurer que la valeur qu'on veut y mettre n'est pas déjà la valeur courante (certains pilotes crash dans ce cas …). Quand il tente d'accéder à la valeur desource, un autre composant vérifie qu'on a le droit de demander cette valeur au pilote (certains pilotes crashent si on cherche à lire une valeur d'option dans une option inactive …). Ici le pilote a indiqué qu'on n'a pas le droit de lire la valeur de l'optionsource(probablement une erreur …), et donc le composant Libinsane qui vérifie les droits renvoie "Access denied".Tout ça pour dire que le problème est après: Faute d'avoir pu consulter la valeur courant de l'option
source, le composant Libinsane autorise l'écriture. Et là paf, le backend répondgenesys:libusb:003:002->source->sane_control_option(SET_VALUE) failed: 0x40000003, Invalid value. Pourtant la valeur passée me semble correcte.Ça c'est toujours une bonne question :-)
Parce-que si ça ne marche pas avec simple-scan, le problème ne vient sûrement pas de la Libinsane.
[^] # Re: Code source
Posté par InfoLibre . Évalué à 1.
J'arrive à scanner avec Simple Scan.
[^] # Re: Code source
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
J'ai commité un possible correctif et IronScanner a été reconstruit avec. Peux-tu le retélécharger et le relancer s'il te plaît ? (si tu l'avais lancé à partir des sources:
git pull && source ./activate_test_env.sh && make clean && make install && ironscanner)Je soupçonne que ce driver n'accepte pas qu'on mette comme valeur la valeur déjà en place (source=Flatbed ; déjà vu ça avec d'autres pilotes) et renvoi EINVAL. Je soupçonne aussi qu'il marque l'option
sourcecomme inactive (non-lisible) alors qu'elle l'est. --> J'ai autorisé la lecture de l'optionsourcemalgré le flag INACTIVE. Je pense que ça devrait débloquer la situation.[^] # Re: Code source
Posté par InfoLibre . Évalué à 1. Dernière modification le 07 septembre 2019 à 18:05.
Je viens de le refaire avec les nouvelles sources, toujours des erreurs, je viens de les transmettre.
[^] # Re: Code source
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
Ça va déjà un peu plus loin, mais ça coince toujours. Que ce soit en voulant consulter la valeur de l'option "source" ou en voulant la modifier, le driver répond INVAL.
J'ai modifié IronScanner pour qu'il active les traces du pilote Genesys. Avec un peu de chance, ça nous dira pourquoi le pilote refuse toute manipulation de l'option 'source'. Pourrais-tu relancer un test avec la dernière version de IronScanner s'il te plaît ? (pour le binaire, le build est encore en cours).
[^] # Re: Code source
Posté par InfoLibre . Évalué à 1.
Fait. Encore des erreurs.
[^] # Re: Code source
Posté par Jérôme Flesch (site web personnel) . Évalué à 3. Dernière modification le 07 septembre 2019 à 23:20.
Bon, rebelote.
Le backend Genesys dit que la Libinsane ne peut pas changer la valeur de l'option
sourceparce-qu'elle est inactive (sauf que c'est lui qui la met inactive, donc ça me fait une belle jambe ..).Pour l'heure, je viens de contourner le problème en acceptant simplement qu'on ne puisse pas changer la valeur de cette option.
Est-ce que tu peux essayer encore une fois s'il te plaît ? (merci pour ta patience)
[^] # Re: Code source
Posté par InfoLibre . Évalué à 2.
Fait, ça a marché. Je vais tester un autre modèle puis la même chose sous Windows. Je suis en mission chez Konica Minolta, je vais tester sur la floppée de MFP qu'on a dans le réseau. Ils seront détectés ?
[^] # Re: Code source
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
\o/
Si ils sont installés sur la machine, ils devraient l'être. Une façon de confirmer qu'ils sont bien installés est de lancer l'application "Numérisation et Fax" de Windows et de voir si elle les trouve.
# Dépendances Debian
Posté par anubis . Évalué à 6.
Pour info sur Debian Stretch, il manque doxygen et python3-dev comme dépendance par rapport à ce qui est indiqué sur le dépôt git.
aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join
[^] # Re: Dépendances Debian
Posté par Jérôme Flesch (site web personnel) . Évalué à 3.
Bien vu. C'est rajouté.
# Serveur HS?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4. Dernière modification le 07 septembre 2019 à 17:23.
Un souci ?
(pour refaire le test de https://openpaper.work/scannerdb/report/51/ depuis une Debian Sid avec la dernière version)
[^] # Re: Serveur HS?
Posté par Jérôme Flesch (site web personnel) . Évalué à 3. Dernière modification le 07 septembre 2019 à 17:41.
Le rapport est incomplet. Il manque les informations concernant le scanner. Et le serveur balance une exception en tentant de chercher les infos du scanner dans le rapport (j'ai codé ça à la va-vite).
La question pour moi, c'est comment est-il possible que le rapport soit incomplet ?
Quand tu lances IronScanner, il indique qu'il met ses traces dans un fichier temporaire. Pourrais-tu m'envoyer ce fichier par email ( jflesch@openpaper.work ) s'il te plaît ?
# Erreur uname
Posté par gwen5484 . Évalué à 2.
Windows 10, imprimante Canon Pixma MG6850, le scanner n'apparait pas dans la liste.
Erreur python dans le rapport :
Apparemment, os.uname ne marche pas sous Windows, il faudrait utiliser platform.uname à la place.
[^] # Re: Erreur uname
Posté par Jérôme Flesch (site web personnel) . Évalué à 3.
Et il marche avec l'application "Numérisation et Fax" de Windows ?
Bonne remarque. Ce warning est non-bloquant mais je vais voir pour corriger ça.
[^] # Re: Erreur uname
Posté par Jérôme Flesch (site web personnel) . Évalué à 3.
Ok en fait cette question est inutile. Je vois bien le scanner dans les traces du rapport donc il marche sûrement avec "Numérisation et Fax. Par contre il manque l'option "resolution", ce qui est sacrément étrange vu que cette option est normalement rajoutée par Libinsane.
Va falloir que je creuse ça.
[^] # Re: Erreur uname
Posté par Jérôme Flesch (site web personnel) . Évalué à 3.
J'ai commité un fix dans la Libinsane et j'ai rebuildé IronScanner. Le fix n'est pas aussi propre que ce que j'aurais voulu, mais ça permettra déjà de confirmer que c'est bien le problème que je pense.
De ce que j'en ai compris, le problème est que le pilote de son scanner founit une source de numérisation
0000\\Root\\Auto. Je suppose que si utilisée, elle sélectionne automatiquement une des sources qui a du papier. Problème: elle ne fournit pas les options requises par Libinsane et IronScanner (resolutionetmode), et ça a l'air de faire planter IronScanner. Donc là j'ai patché Libinsane pour qu'elle l'ignore.Est-ce que tu pourrais retélécharger IronScanner et réessayer s'il te plait ?
[^] # Re: Erreur uname
Posté par gwen5484 . Évalué à 1.
Je teste ça ce soir !
[^] # Re: Erreur uname
Posté par gwen5484 . Évalué à 1.
Alors j'ai un device qui s'appelle "Microsoft 351120000", qui semble bien cibler mon scanner (rapport 337).
Le nom affiché N'est pas le bon par contre (via GIMP, je vois bien le nom TWAIN "Canon MG68000
series Network…");
Bon courage, n'hésite pas si tu veux que je reteste !
[^] # Re: Erreur uname
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
D'après le rapport, c'est l'API WIA2 qui a utilisée. Libinsane n'a pas trouvé la DLL TWAIN.
Et effectivement, ce n'est pas le bon nom qui s'est affiché. C'est un point qu'il faut que je travaille.
# liste des rapports ?
Posté par _kaos_ . Évalué à 1. Dernière modification le 08 septembre 2019 à 08:14.
snip
trouvé
Matricule 23415
[^] # Re: liste des rapports ?
Posté par _kaos_ . Évalué à 2.
Et donc ça juste marche sur un :
HP Envy 4502
Par contre, j'ai modifié l'entrée pour avoir le modèle exact. Il était identifié comme un :
HP Envy 4500 Series
Bref, ça tourne sous debian en prenant le git ;)
Matricule 23415
# Oki
Posté par gUI (Mastodon) . Évalué à 3.
J'ai un combiné imprimante/scanner Oki qui a le scanner qui n'est pas du tout reconnu par Sane ni par Libinsane (j'avais même fait des rapports sur ton précédent appel).
Est-ce que tu as une idée de comment s'y prendre pour reverse engineerer le protocole ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Oki
Posté par Jérôme Flesch (site web personnel) . Évalué à 3. Dernière modification le 08 septembre 2019 à 23:36.
En supposant qu'il s'agit d'un scanner USB, ce que je ferais:
[^] # Re: Oki
Posté par gUI (Mastodon) . Évalué à 3.
Désolé, manque de précisions, scanner réseau. Est-ce que ça change qqchose à la méthode ? Wireshark, toussa…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Oki
Posté par Jérôme Flesch (site web personnel) . Évalué à 3.
Nop, même idée. Il faut juste espérer que le trafic réseau n'est pas chiffré …
# Erreur
Posté par littlebreizhman . Évalué à 3.
je veux bien faire le test mais… (sur Mageia Cauldronet avec le binaire Linux)
j'ai (un peu) cherché et je ne vois pas trop ce qui me manque
[^] # Re: Erreur
Posté par Jérôme Flesch (site web personnel) . Évalué à 2. Dernière modification le 08 septembre 2019 à 18:26.
Bizarre, toutes les dépendances devraient être incluses dans le binaire. Essaye voir en installant ce paquet: libgdk_pixbuf-gir2.0
[^] # Re: Erreur
Posté par littlebreizhman . Évalué à 5.
J'ai donc installé le paquet .586 (la version x64_86 était déjà installé, j'avais vérifié avant de poster
L'erreur change mais reste un problème sur un autre module.
Pour info, j'ai les paquets lib64glib2.0_0 et libglib2.0_0 installés (si c'est bien eux qui fournissent le gmodule requis (si j'ai bien compris).
La cauldron doit être un peu trop exotique par rapport à ta machine de dev.
J'ai voulu compiler ironscanner à l'instant depuis les sources git et le
```
source ./activate_test_env.sh
me réclame sane-backends
Or il est déjà installé (version sane-backends-1.0.27-4.mga7.x86_64)
Je suis maudit avec ton soft et mageia, j'avais déjà eu des trucs bizarres la dernière fois.
[^] # Re: Erreur
Posté par Jérôme Flesch (site web personnel) . Évalué à 3.
Malheureusement, on tape en plein dans le problème de la diversité des distributions Linux … :/. Pour ma part, je ne teste que sur Debian, Ubuntu, et plus rarement sur Fedora. Comme je fais ça sur mon temps libre, je peux difficilement assurer le support des autres distributions :(
[^] # Re: Erreur
Posté par littlebreizhman . Évalué à 2. Dernière modification le 09 septembre 2019 à 08:18.
L'écosystème des distribs est immense.
Je vais essayer de creuser un peu plus le weekend prochain.
[^] # Re: Erreur
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
je suis en mageia 7, et j'ai les même soucis.
Je comprends les problèmes concernant les binaires, mais beaucoup moins ceux lié à la compilation.
"La première sécurité est la liberté"
[^] # Re: Erreur
Posté par littlebreizhman . Évalué à 2.
C'est bizarre effectivement, je me demandais si ce n'était pas une histoire entre les versions i586 et x64_86 qui coexistent (comme pour le paquet manquant cité dans mon premier post alors que la version 64 bits était bien installé auparavant)
[^] # Re: Erreur
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Est-ce que c'est possible que cela soit lié à l'usage de libXXX et de lib64XXX sous Mageia et non sous debian ?
"La première sécurité est la liberté"
[^] # Re: Erreur
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
Sauf erreur de ma part, Meson utilise pkg-config pour trouver les dépendances. Donc ce qu'il faudrait regarder:
pkg-config --libs --cflags sane-backends?sane-backends.pcquelque-part dans /usr ? Sinon, un.pcavec un nom similaire ? Auquel cas je peux patcher lemeson.build.[^] # Re: Erreur
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
# urpmi sane-backends
Le paquetage sane-backends-1.0.27-4.mga7.x86_64 est déjà installé
$ pkg-config --libs --cflags sane-backends
Package sane-backends was not found in the pkg-config search path.
Perhaps you should add the directory containing `sane-backends.pc'
to the PKG_CONFIG_PATH environment variable
Package 'sane-backends', required by 'virtual:world', not found
# urpmf sane-backends.pc
lib64sane1-devel:/usr/lib64/pkgconfig/sane-backends.pc
⏚ [root:~] # urpmi lib64sane1-devel
$ pkg-config --libs --cflags sane-backends
-lsane
$ ./ironscanner
…
Traceback (most recent call last):
File "launcher.py", line 6, in
File "", line 983, in find_and_load
File "", line 967, in _find_and_load_unlocked
File "", line 677, in _load_unlocked
File "/usr/local/lib/python3.7/dist-packages/PyInstaller/loader/pyimod03_importers.py", line 621, in exec_module
File "ironscanner-2.0-py3.7.egg/ironscanner/main.py", line 20, in
File "gi/init_.py", line 129, in require_version
ValueError: Namespace GdkPixbuf not available
…
./libinsane] $ source ./activate_test_env.sh
…
subprojects/libinsane-gobject/src/meson.build:57:6: ERROR: Program(s) ['vapigen'] not found or not executable
…
# urpmf vapigen
lib64vala-devel:/usr/lib64/pkgconfig/vapigen-0.44.pc
lib64vala-devel:/usr/lib64/pkgconfig/vapigen.pc
lib64vala-devel:/usr/share/aclocal/vapigen.m4
vala-tools:/usr/bin/vapigen
vala-tools:/usr/bin/vapigen-0.44
vala-tools:/usr/share/man/man1/vapigen-0.44.1.xz
vala-tools:/usr/share/man/man1/vapigen.1.xz
vala-tools:/usr/share/vala/Makefile.vapigen
# urpmi vala-tools
# urpmf GObject-2.0.gir
lib64girepository-devel:/usr/share/gir-1.0/GObject-2.0.gir
# urpmi lib64girepository-devel
$ source ./activate_test_env.sh
…
ok
$ make install
-> des erreurs
"La première sécurité est la liberté"
[^] # Re: Erreur
Posté par Jérôme Flesch (site web personnel) . Évalué à 2. Dernière modification le 12 septembre 2019 à 17:25.
Au moins on avance :-)
Je crois qu'il y a une légère confusion dans les instructions. Comme indiqué dans le README, le
source ./activate_test_env.shest à faire à partir des sources de IronScanner, et non pas celle de la Libinsane. Ce script va s'occuper de créer un environnement de dev/test pour IronScanner, ce qui implique qu'il va compiler la dernière Libinsane lui-même.Un script similaire existe aussi dans les sources de la Libinsane, mais celui-là est uniquement pour le développement/test de la Libinsane toute seule (sans IronScanner).
Pour le
make install, pareil, c'est uniquement à faire dans les sources d'IronScanner. Ça va installer IronScanner dans le virtualenv Python (ou sur le système si aucun virtualenv n'est actif). Par contre, fairemake installdans Libinsane va tenter d'installer la Libinsane sur le système (il n'y pas vraiment de virtualenv pour une librairie C), d'où les erreurs je suppose.[^] # Re: Erreur
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
je m'y perds un peu, finalement, c'est où qu'il faut regardé ?
"La première sécurité est la liberté"
[^] # Re: Erreur
Posté par Jérôme Flesch (site web personnel) . Évalué à 2.
https://gitlab.gnome.org/World/OpenPaperwork/ironscanner#from-sources
[^] # Re: Erreur
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Quand je clique sur "scanner type", le logiciel donne l'impression de freezer. Je n'ai pas de scanner au boulot, je voulais tester le scanner de la maison un MFC1910 en réseau.
"La première sécurité est la liberté"
# Je vais apporter ma petite contribution
Posté par philectro . Évalué à 2.
Je viens de faire un rapport d'une mg4200 sous Windows, Canon.
J'ai 2autres scanner.
Je vais faire les 5 autres rapports avec tout ça.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.