Journal Base de données de scanners : besoin de contributeurs (yep, encore)

49
6
sept.
2019

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 . Évalué à 3 (+3/-0).

    J'ai une page "La connexion a échoué" ???

  • # Problème dépendance

    Posté par . Évalué à 3 (+1/-0). Dernière modification le 06/09/19 à 14:54.

    Sous Linux Suse Leap 15, à l'éxécution :

    Error loading Python lib '/tmp/_MEIqq9muE/libpython3.7m.so.1.0': dlopen: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/_MEIqq9muE/libpython3.7m.so.1.0)
    

    On est sous glibc 2.26

    • [^] # Re: Problème dépendance

      Posté par (page perso) . Évalué à 2 (+1/-1).

      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 . Évalué à 3 (+1/-0).

        un container Docker ?faudra juste gérer un lien sur le device USB.

      • [^] # Re: Problème dépendance

        Posté par . Évalué à 1 (+0/-0).

        Mince !
        Pourtant, j'ai bien l'impression d'être « dans les clous » par rapport à l'environnement que tu décris :

          /tmp $ lsb_release -d
          Description:  Ubuntu 18.04.3 LTS
          /tmp $ ./ironscanner
          [7235] PyInstaller Bootloader 3.x
          [7235] --- %< ---
          [7236] Error loading Python lib '/tmp/_MEIkFpyWM/libpython3.7m.so.1.0': dlopen: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/_MEIkFpyWM/libpython3.7m.so.1.0)
          [7235] --- %< ---

        Et effectivement :

          /tmp $ dpkg -l | grep libc6: | awk '{print $2, " - ",$3}'
          libc6:amd64  -  2.27-3ubuntu1
          libc6:i386  -  2.27-3ubuntu1

        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 (page perso) . Évalué à 2 (+0/-0).

          Y a-t-il une solution simple, ou reconstruire l'exécutable à partir des sources est-elle la seule ?

          Je ne vois que deux solutions malheureusement:

          • Le lancer à partir des sources + un virtualenv python (voir le readme sur gitlab)
          • Faire un schroot Debian Buster
  • # Erreur

    Posté par . Évalué à 1 (+2/-1).

    J'ai cette erreur :

    [23544] Error loading Python lib '/tmp/_MEIM41sN9/libpython3.7m.so.1.0': dlopen: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/_MEIM41sN9/libpython3.7m.so.1.0)
    

    Je dois installer la glibc 2.28 ? J'ai un paquet glibc-source mais pas de glibc.

  • # Fait

    Posté par . Évalué à 3 (+2/-0).

    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.

  • # Lib Insane

    Posté par (page perso) . Évalué à -10 (+1/-13).

    Tu comptes garder ce nom? C'est pour concurrencer libcaca?

    Un LUG en Lorraine : https://enunclic-cappel.fr

  • # libsane et libinsane

    Posté par . Évalué à 1 (+0/-0).

    J'ai pas bien compris.

    Est-ce que ce que ces deux librairies sont en concurrences ? complémentaires ?

    • [^] # Re: libsane et libinsane

      Posté par (page perso) . Évalué à 5 (+3/-0).

      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 . Évalué à 2 (+0/-0). Dernière modification le 07/09/19 à 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 (page perso) . Évalué à 3 (+1/-0).

          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 valeurs Flatbed et Automatic Document Feeder. Mais il y a par exemple les scanners Canon CanoScan N1240U/LiDE30 qui ont pour sources possibles Normal, Transparency et Negative. 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-y pour 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 . Évalué à 3 (+1/-0). Dernière modification le 07/09/19 à 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 . Évalué à 2 (+1/-0).

    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 . Évalué à 1 (+0/-0).

      Il a scanné une seule page chez moi.

    • [^] # Re: Cinq minutes?!

      Posté par (page perso) . Évalué à 6 (+4/-0).

      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 ;).

  • # Vieux problème

    Posté par (page perso) . Évalué à 7 (+5/-0). Dernière modification le 06/09/19 à 18:43.

    Salut Jérôme,

    Félicitation pour tes initiatives et bon courage. Lorsque j'avais bossé pour GNOME Scan, j'avais été aussi très frustré par SANE. Cette API est très simple et c'est juste un passe-plat unique pour toutes les variations de numériseurs existants. Même l'usage élémentaire n'a pas été standardisé : numériser une région, choisir la densité, la couleur et la source. Il y a tout juste quelques recommendations : http://www.sane-project.org/sane2/0.08/doc014.html dans SANE2.

    D'ailleurs, SANE2 n'est jamais sortie, non ?

    Très bonne idée de se limiter à la numérisation papier. La numérisation de négatifs ou les webcams complexifient inutilement l'équation. C'est déjà assez compliqué de gérer des mange-feuilles, des stylos et des numériseurs plats !

    Tu trouveras dans GNOME Scan du code pour gérer certaines spécificités. Je suis sûr que tu as pareil dans simple-scan de Robert ANCELL et dans libinsane ;-). Tu trouvera ça dans https://gitlab.gnome.org/Archive/gnome-scan/tree/master/modules/gsane, dans les fichiers gsane-option-* qui normalisent les options folkloriques. Essentiellement source et area. Je n'ai pas été bien plus loin de tête.

    Pour faire ma base de numériseurs, j'ai épluché les backend SANE disponibles à l'époque, à coup de grep. J'aurai bien aimé avoir ta base de numériseurs !! Le meilleur exemple de variation est https://gitlab.gnome.org/Archive/gnome-scan/blob/master/modules/gsane/gsane-option-source.c

    Dans les traces d'IronScanner (bravo pour le logiciel) :

    ERROR  Failed to load image /home/bersace/Téléchargements/c05283357_1750x1285.jpg
    Traceback (most recent call last):
      File "ironscanner-2.0-py3.7.egg/ironscanner/main.py", line 574, in complete_report
    AttributeError: module 'PIL' has no attribute 'Image'
    

    Ça te parle ?

    • [^] # Re: Vieux problème

      Posté par (page perso) . Évalué à 6 (+4/-0).

      Je vais jeter un coup d'œil au code de Gsane, des fois que tu avais des fixs que je n'ai pas encore :)

      D'ailleurs, SANE2 n'est jamais sortie, non ?

      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) …

      AttributeError: module 'PIL' has no attribute 'Image'

      Arf. Je note que selon la version de PIL, on peut accéder à PIL.Image sans faire import PIL.Image :-)
      C'est rectifié. Merci de me l'avoir signalé.

  • # cannot execute

    Posté par (page perso) . Évalué à 2 (+0/-0).

    Chez moi, ça fait ça:
    bash: ./ironscanner: cannot execute binary file: Erreur de format pour exec()

  • # Code source

    Posté par . Évalué à 1 (+1/-0). Dernière modification le 06/09/19 à 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 (page perso) . Évalué à 2 (+0/-0).

      Effectivement, dans les instructions, il manquait le paquet virtualenv. Merci de me l'avoir signalé. C'est rectifié.

      • [^] # Re: Code source

        Posté par . Évalué à 3 (+0/-0).

        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 (page perso) . Évalué à 2 (+0/-0).

          'fectivement, j'avais manqué quelques autres dépendances (GTK, GdkPixbuf notamment). C'est rectifié.

          • [^] # Re: Code source

            Posté par . Évalué à 3 (+0/-0).

            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 (page perso) . Évalué à 2 (+0/-0). Dernière modification le 09/09/19 à 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:

              sudo apt install \
                  python3-gi libgirepository1.0-dev gobject-introspection \
                  gir1.2-gdkpixbuf-2.0 gir1.2-gtk-3.0
              
              • [^] # Re: Code source

                Posté par . Évalué à 3 (+0/-0).

                J'utilise mageia. gdkpixbuf et autres sont installés, mais le binaire n'est toujours pas content. La compilation des sources échouent aussi :

                |Dependency sane-backends found: NO (tried pkgconfig and cmake)
                
                subprojects/libinsane/src/meson.build:60:4: ERROR: Dependency "sane-backends" not found, tried pkgconfig and cmake
                

                alors que sane-backends est installé.

                "La première sécurité est la liberté"

                • [^] # Re: Code source

                  Posté par . Évalué à 1 (+1/-0).

                  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 . Évalué à 1 (+1/-0).

      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 . Évalué à 1 (+0/-0).

        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 ?

        • [^] # Re: Code source

          Posté par (page perso) . Évalué à 3 (+1/-0).

          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.

          il semble que ce soit un problème de droits

          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 de source, 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'option source (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épond genesys:libusb:003:002->source->sane_control_option(SET_VALUE) failed: 0x40000003, Invalid value. Pourtant la valeur passée me semble correcte.

          Est-ce que tu parviens à scanner avec un autre programme type simple-scan ?

          Ç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 . Évalué à 1 (+1/-0).

            J'arrive à scanner avec Simple Scan.

            • [^] # Re: Code source

              Posté par (page perso) . Évalué à 2 (+0/-0).

              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 source comme inactive (non-lisible) alors qu'elle l'est. --> J'ai autorisé la lecture de l'option source malgré le flag INACTIVE. Je pense que ça devrait débloquer la situation.

              • [^] # Re: Code source

                Posté par . Évalué à 1 (+1/-0). Dernière modification le 07/09/19 à 18:05.

                Je viens de le refaire avec les nouvelles sources, toujours des erreurs, je viens de les transmettre.

                • [^] # Re: Code source

                  Posté par (page perso) . Évalué à 2 (+0/-0).

                  Ç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 . Évalué à 1 (+1/-0).

                    Fait. Encore des erreurs.

                    • [^] # Re: Code source

                      Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 07/09/19 à 23:20.

                      Bon, rebelote.

                      Le backend Genesys dit que la Libinsane ne peut pas changer la valeur de l'option source parce-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 . Évalué à 2 (+2/-0).

                        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 (page perso) . Évalué à 2 (+0/-0).

                          Fait, ça a marché.

                          \o/

                          Ils seront détectés ?

                          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 . Évalué à 6 (+5/-0).

    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.

  • # Serveur HS?

    Posté par (page perso) . Évalué à 4 (+1/-0). Dernière modification le 07/09/19 à 17:23.

    Un souci ?

    INFO   Connecting to openpaper.work
    INFO   Posting report...
    INFO   Please wait, this may take a while...
    ERROR  Error from server: 500 - Internal Server Error
    

    (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 (page perso) . Évalué à 3 (+1/-0). Dernière modification le 07/09/19 à 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 . Évalué à 2 (+1/-0).

    Windows 10, imprimante Canon Pixma MG6850, le scanner n'apparait pas dans la liste.
    Erreur python dans le rapport :

    WARNING Failed to get uname
    Traceback (most recent call last):
      File "C:/msys64/mingw32/lib/python3.7/site-packages/ironscanner/main.py", line 621, in get_info
    AttributeError: module 'os' has no attribute 'uname'
    

    Apparemment, os.uname ne marche pas sous Windows, il faudrait utiliser platform.uname à la place.

    • [^] # Re: Erreur uname

      Posté par (page perso) . Évalué à 3 (+1/-0).

      le scanner n'apparait pas dans la liste.

      Et il marche avec l'application "Numérisation et Fax" de Windows ?

      Apparemment, os.uname ne marche pas sous Windows, il faudrait utiliser platform.uname à la place.

      Bonne remarque. Ce warning est non-bloquant mais je vais voir pour corriger ça.

      • [^] # Re: Erreur uname

        Posté par (page perso) . Évalué à 3 (+1/-0).

        Et il marche avec l'application "Numérisation et Fax" de Windows ?

        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 (page perso) . Évalué à 3 (+1/-0).

      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 (resolution et mode), 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 . Évalué à 1 (+0/-0).

        Je teste ça ce soir !

      • [^] # Re: Erreur uname

        Posté par . Évalué à 1 (+0/-0).

        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 (page perso) . Évalué à 2 (+0/-0).

          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 . Évalué à 1 (+0/-0). Dernière modification le 08/09/19 à 08:14.

    snip

    trouvé

    • [^] # Re: liste des rapports ?

      Posté par . Évalué à 2 (+1/-0).

      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 ;)

  • # Oki

    Posté par . Évalué à 3 (+1/-0).

    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 (page perso) . Évalué à 3 (+1/-0). Dernière modification le 08/09/19 à 23:36.

      En supposant qu'il s'agit d'un scanner USB, ce que je ferais:

      • Voir si il n'y a pas des applications tierces opensource (non-Sane) qui le supporte. J'avais un vieux scanner supporté comme ça il y a longtemps par exemple.
      • sniffer le trafic USB avec Wireshark:
        • tout en sniffant, faire un scan d'une page rouge, puis d'une verte, puis d'une bleue (ça suppose que le scanner est en RGB, mais ça devrait aussi permettre de voir si le scanner est en CMYK ou dans un autre espace de couleur fantaisiste).
        • tout en sniffant, essayer des scans en changeant juste un réglage à chaque fois.
      • jouer aux devinettes
      • jouer avec pyusb et le scanner pour voir si ces devinettes sont tombées juste
      • rajouter un backend à sane et soumettre un patch
      • [^] # Re: Oki

        Posté par . Évalué à 3 (+1/-0).

        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.

  • # Erreur

    Posté par . Évalué à 3 (+1/-0).

    je veux bien faire le test mais… (sur Mageia Cauldronet avec le binaire Linux)

    [16118] LOADER: Running launcher.py
    Traceback (most recent call last):
      File "launcher.py", line 6, in <module>
      File "<frozen importlib._bootstrap>", line 983, in _find_and_load
      File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
      File "<frozen importlib._bootstrap>", 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 <module>
      File "gi/__init__.py", line 129, in require_version
    ValueError: Namespace GdkPixbuf not available
    
    

    j'ai (un peu) cherché et je ne vois pas trop ce qui me manque

    • [^] # Re: Erreur

      Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 08/09/19 à 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 . Évalué à 5 (+3/-0).

        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.

        Traceback (most recent call last):
          File "gi/importer.py", line 138, in load_module
          File "gi/module.py", line 265, in get_introspection_module
          File "gi/module.py", line 117, in __init__
        gi.RepositoryError: Typelib file for namespace 'GModule', version '2.0' not found
        
        During handling of the above exception, another exception occurred:
        
        Traceback (most recent call last):
          File "launcher.py", line 6, in <module>
          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 24, in <module>
          File "gi/importer.py", line 140, in load_module
        ImportError: Typelib file for namespace 'GModule', version '2.0' not found
        [18406] Failed to execute script launcher
        

        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

        |Run-time dependency sane-backends found: NO (tried pkgconfig and cmake)
        
        subprojects/libinsane/src/meson.build:60:4: ERROR: Dependency "sane-backends" not found, tried pkgconfig and cmake
        
        A full log can be found at /tmp/test_ironscanner/ironscanner/sub/libinsane/build/meson-logs/meson-log.txt
        

        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 (page perso) . Évalué à 3 (+1/-0).

          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 . Évalué à 2 (+0/-0). Dernière modification le 09/09/19 à 08:18.

            L'écosystème des distribs est immense.
            Je vais essayer de creuser un peu plus le weekend prochain.

            • [^] # Re: Erreur

              Posté par . Évalué à 3 (+0/-0).

              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 . Évalué à 2 (+0/-0).

                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 . Évalué à 3 (+0/-0).

                  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 (page perso) . Évalué à 2 (+0/-0).

                    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 ?
                    • Est-ce qu'il y un fichier sane-backends.pc quelque-part dans /usr ? Sinon, un .pc avec un nom similaire ? Auquel cas je peux patcher le meson.build.
                    • [^] # Re: Erreur

                      Posté par . Évalué à 4 (+1/-0).

                      # 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 (page perso) . Évalué à 2 (+0/-0). Dernière modification le 12/09/19 à 17:25.

                        Au moins on avance :-)

                        ./libinsane] $ source ./activate_test_env.sh

                        Je crois qu'il y a une légère confusion dans les instructions. Comme indiqué dans le README, le source ./activate_test_env.sh est à 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, faire make install dans 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.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.