Jérôme Flesch a écrit 402 commentaires

flatpack-builder ne propage pas http_proxy

Flatpak-builder bloque volontairement le réseau pendant les builds de chaque composant. L'objectif est de s'assurer que la liste des dépendances est complète et que le build reste 100% reproduisible. C'est notamment pour éviter que des dépendances soient téléchargées pendant le build.

Par exemple, lors de l'installation d'un module Python avec pip, si une dépendances n'est pas sur le système, pip va essayer de la télécharger. Et par défaut, il va tenter de télécharger la dernière version. Or ce pourrait ne pas être la même entre 2 tentatives de build différentes. Donc il faut que les dépendances soient installées avant explicitement (y compris les dépendances des dépendances, etc).

J'ai eut le même genre de problèmes avec Paperwork. Heureusement pour moi, Mathieu Jourdan avait fait un début de Flatpak qui réglait le problème de l'installation des paquets Python. De mon coté, j'ai pu me concentrer sur les problèmes de fichiers de données spécifiques à la langue de l'utilisateur et sur le problème de l'accès aux scanners.

Pour Maven, je pense que tu peux t'en sortir comme Mathieu Jourdan avait fait pour Python:
- Compiler et installer Maven comme faisant partie du build Flatpak
- Utiliser un mini Makefile bidon pour construire les builds suivants avec Maven

C'est effectivement difficile, mais Flatpak offre ensuite plusieurs avantages:
- Tu as une liste quasi-exhaustive des dépendances de ton programme.
- Tes utilisateurs peuvent tester la dernière version de ton programme quelque-soit leur distribution.
- Tes utilisateurs peuvent te faire des rapports de bugs indépendamment des 25000 versions des dépendances disponibles dans les diverses distributions.
- Tu peux faire de l'intégration continue en mettant à jour ton dépôt Flatpak automatiquement.

Juste pour la blague, une anecdote plus ou moins hors-sujet que j'ai vécu:

Il y a un gars de plus de 50 ans aux US qui a longtemps cru que jflesch@gmail.com était son adresse email. J'ai plusieurs fois prévenu ses interlocuteurs qu'ils avaient une mauvaise adresse.

Un jour ce monsieur a passé une commande pour des chaussures dans un magasin (physique) en donnant mon adresse email. J'ai reçu l'email de confirmation. L'expéditeur de l'email était "support@magasin-xyz.com". J'ai donc répondu à l'email en leur demandant si il était possible d'annuler cette commande. Ils m'ont répondu OK, commande annulée.

Bizarrement, depuis, je ne reçois plus aucun mail à sa place :-)

Pour les jeux:
1) https://store.steampowered.com/app/433340/Slime_Rancher/
2) https://store.steampowered.com/app/331870/AER_Memories_of_Old/

J'ai passé beaucoup trop de temps sur le premier :-)

Le seul défaut de ces deux jeux sous GNU/Linux, c'est le clavier : je suis en QWERTY, et je n'ai pas vu de problème, mais ma petite amie est en AZERTY et a du réglé son clavier en QWERTY pour que ces jeux prennent les entrées clavier correctement (bug Unity ?).

Pour le chat, le seul truc qui me vient à l'esprit serait un serveur IRC privé, avec en client/proxy QuasselIRC (disponible pour GNU/Linux et Android).

https://gitlab.gnome.org/World/OpenPaperwork/ironscanner#from-sources

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.

• https://gitlab.gnome.org/World/OpenPaperwork/libinsane/blob/master/subprojects/libinsane/src/meson.build#L60
• https://mesonbuild.com/Dependencies.html

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.

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.

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

Nop, même idée. Il faut juste espérer que le trafic réseau n'est pas chiffré …

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 ?

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 :(

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

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.

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.

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

Bizarre, toutes les dépendances devraient être incluses dans le binaire. Essaye voir en installant ce paquet: libgdk_pixbuf-gir2.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.

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)

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.

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

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 ?

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.

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

Bien vu. C'est rajouté.