Étiquette : bug

Parfois tomber sur un bug à la con, cela peut servir.

Vous le savez, je suis tombé sous le charme du Commodore 64, que ce soit avec un vrai datant de 1985, le C64Maxi (sa réplique moderne avec un clavier fonctionnel) ou encore via Vice dont je maintiens les version svn pour l’interface gtk3 et pour l’interface sdl2 sur AUR.

Alors que je faisais ma compilation quasi-quotidienne – c’est un logiciel au développement dynamique – de l’émulateur Vice, je tombe sur une erreur coriace qui me fait planter la génération de la documentation en pdf.

Dans un premier temps, j’ai désactivé la génération de la documentation et mis à jour les deux PKGBUILDs concernés, quitte à réactiver plus tard la création de la documentation quand le bug serait corrigé.

En gros, j’avais ce message d’erreur qui me faisait planter la compilation :

../../../vice.t2d/pdf/xtr/vicepdf.texi:123: epsf.tex not found, images will be ignored.

Message d’erreur franchement bizarre, puis j’ai regardé dans texlive-core – qui est une des dépendances de Vice – si je pouvais trouver ce fichier epsf.tex.

En utilisant la vue en liste, je retrouve le fichier. Encore plus bizarre. En effet, je me suis aperçu par la suite qu’il m’avait installé le paquet texlive-basic, une version minimaliste de texlive-core, qui est en ce moment sur le dépôt de test extra-testing.

Après avoir viré texlive-basic et l’avoir remplacé par texlive-core, tout est rentré dans l’ordre. C’est sûrement une mise à jour un peu chatouilleuse qui arrivera bientôt sur les dépôts stables d’Archlinux.

Tant que le paquet texlive-core n’est pas viré, ça ira très bien comme ça. Croisons juste les doigts. C’est juste les petites joies d’utiliser une Archlinux avec les dépôts de tests activés 🙂

En tout cas, j’ai bien fait de ne pas rapporter de bug sur l’outil de suivi de Vice !

Ajout à 20 h 10.

J’ai l’explication pour l’installation du paquet texlive-basic en lieu et place du texlive-core. Il est proposé à l’installation et on doit dire non par défaut pour éviter d’avoir des ennuis avec texlive.

La preuve avec une capture d’écran :

Comme quoi, tout s’explique 🙂

Merci Archlinux pour la glibc 2.36…

J’adore Archlinux – sinon cela ne ferait pas 13 ans que je l’utilise en démarrage simple – même avec ses travers comme d’avoir certaines technologies un peu à l’avance.

Il y a bientôt 12 ans, j’avais piqué une colère avec l’arrivée de Python 3.0 en avance sur le reste du doucéreux monde des distributions GNU/Linux.

Plus récemment, c’est l’arrivée de la glibc 2.36 qui a provoqué quelques problèmes. Un en relation avec Qemu corrigé par un patch que j’ai rajouté à mon paquet AUR qemu-git. Mais le bug le plus laxatif – de mon point de vue – c’est un bug qui bloque la compilation de Mozilla Firefox et Mozilla Thunderbird.

C’est ainsi que j’ai rapporté un bug. Au début j’ignorais que c’était en relation avec la glibc 2.36, penchant plus pour un bug du compilateur utilisé, clang.

Quelle ne fut pas ma surprise quand j’appris que c’était un bug lié à la glibc. Côté importance du bug, on tape dans le lourd.

Bien qu’au moment où j’écris cet article, les deux patchs correctifs ne sont pas encore intégrés dans le code source de Mozilla Firefox, cela montre qu’il n’y a pas de petits bugs… Après il y aura des personnes qui par fainéantise ou par un niveau d’anglais trop faible ne rapporte pas des bugs. Cela est dommageable.

La semaine à bug continue… Quand il n’y en a plus, il y en a encore !

Dans un précédent article, je disais que je passais une semaine où je rapportais chaque jour – ou presque – un nouveau bug.

Le 14 juillet n’a pas été exempt d’un rapport d’un bug. Cette fois, concernant Dosbox-X et le support des modes graphiques des machines Amstrad PC1512/1640. Tout est parti d’une remarque postée par Benedikt Freisen sur les modes graphiques de l’Amstrad PC1512/1640 – dont j’ai parlé dans un article vieux geek en août 2020 – qui parlait d’une étrangeté avec un mode CGA pseudo-monochrome.

J’ai donc voulu vérifier et quand je lançais Dosbox-X avec comme option machine=amstrad, j’avais droit à un plantage en beauté.

J’ai donc rapporté le bug, et je me suis aperçu que cette régression fut introduite entre Dosbox-X 0.83.13 (sorti début mai 2021) et la version 0.83.14 (sortie en juin 2021).

Après quelques conseils pour pouvoir détecter le jour de la régression – et soyons fous – l’ajout de code responsable de celle-ci, je me suis mis à la longue recherche. Après un faux départ, j’ai décidé de prendre les choses de manière plus méthodique. J’ai pris la référence de la dernière modification de chaque jour.

Pour retrouver le code, j’ai utilisé la commande : git checkout référence

Ensuite, j’utilisais le script de compilation build, puis j’allais dans le répertoire src pour lancer le dosbox-x obtenu. Si ça plantait, je passais au jour précédent, sans nettoyer l’ensemble auparavant avec un make distclean, en réinitialisant le dépot git (pour ne pas avoir de problème de branche orpheline) avec la commande git switch -.

Continuer la lecture de « La semaine à bug continue… Quand il n’y en a plus, il y en a encore ! »

En vrac’ en direct du confinement, épisode 2

Un petit en vrac’ pour un confinement qui est bien parti pour durer au moins 6 semaines, le deuxième à mi-chemin de la fin… Avec un peu de chance !

Côté informatique et internet ?

Côté culture ?

C’est tout pour aujourd’hui. Bon courage !

Archlinux et la mise à jour moisie de Samba, suite mais pas fin ?

Dans un précédent article, je parlais de l’arrivée d’une version moisie – une version de développement vieille de près de 4 mois – de Samba sur Archlinux.

Outre le fait qu’il y avait un bug lié à Python 3.8 qui cassait le fonctionnement de samba-tool, une deuxième couche du problème est rapidement apparu, et ne concerne que certains périphériques.

La version 4.12.0 – on en est à la 4.12.0-3 en ce 2 avril 2020 – est arrivée sur les dépôts de test. J’ai donc profité de l’occasion pour débloquer les paquets ignorés. Un redémarrage plus tard, j’avais toujours le même problème : impossible d’accéder aux partages de ma FreeBox Revolution serveur.

Après quelques recherches, je me suis aperçu que le code de la FreeBox pour cette fonctionnalité est restée bloquée sur le protocole SMBv1… Un bug a été ouvert sur l’outil de suivi de Free en octobre 2017 et n’est toujours pas clos.

Si on en croit les commentaires, c’est le passage du code en GPLv3 qui bloque la montée en version du protocole.

Bref, c’est la mouise… Comment le contourner ? Si vous avez un périphérique bloqué sur cet ancien protocole déprécié et que vous utilisez une Archlinux, il faut modifier le fichier /etc/samba/smb.conf et rajouter dans la section [global] ceci, dixit un message de David C. Rankin sur la liste de publication arch-general.


client min protocol = NT1
server min protocol = NT1

Une autre option étant d’employer CORE à la place de NT1.

Continuer la lecture de « Archlinux et la mise à jour moisie de Samba, suite mais pas fin ? »