É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 ? »

Quand EndeavourOS montre sa vraie nature, ça peut faire mal.

Depuis que j’ai mis de côté les articles de tests de distributions – qui finissent par toutes se ressembler – et que je me suis réorienté vers tout ce qui est logiciel de plus haut niveau, j’ai senti un certain soulagement.

En septembre 2019, j’écrivais un article au titre évocateur : « EndeavourOS, un outil bien pratique pour les archlinuxien(ne)s ne voulant plus se prendre la tête. »

Mi-novembre 2019, un article avait été posté sur le site d’EndeavourOS s’excusant de devoir annuler la publication prévue pour le mois de novembre, le travail n’étant pas terminé, spécialement en ce qui concerne la partie installation en ligne. Étant « dans le secret des Dieux » (en tant que modérateur) je peux confirmer que l’installation en réseau, ce n’était pas encore tout à fait ça.

Durant la deuxième quinzaine d’octobre 2019, pacman 5.2 a été rendu disponible, cassant certains outils, dont Kalu qui était utilisé par EndeavourOS, comme je l’ai précisé dans un article du 23 octobre 2019. La loi de Murphy s’exprimant à fond, l’ISO qui devait sortir en novembre 2019 ne contenait plus Kalu, remplacé par un outil maison, eos-update-notifier.

Continuer la lecture de « Quand EndeavourOS montre sa vraie nature, ça peut faire mal. »

Parfois, certains dogmes du logiciel libre se vérifient…

Le logiciel libre au fil des années est devenu un monde dogmatique, et j’ai pu en faire les frais à chaque fois que j’ai osé dire que ce monde ne tournait pas complètement rond, entre l’utilisation abusive du principe du fork, la coupure entre développeurs et utilisateurs, la ségrégation logicielle appliquée par les purs et durs qui sont parfois plus « Stallmannien que Stallman ». Je vous renvoie à ma série de billets sur le monde du libre part en couilles pour les détails plus ou moins croustillants.

Comme je m’amuse à le dire dans ma série de vidéos « Les pitreries du libre » : « Errare Humanum Est, Perserverare Libristum Est ».

Il y a cependant un « dogme » qui veut que n’importe quelle personne qui utilise du logiciel libre peut apporter des modifications pour le plus grand bonheur des autres. C’est un peu le complément d’une des quatre libertés fondamentales du logiciel libre.

Il y a un exemple que je vais rapidement abordé, lié à Mate-Desktop. Il y a quelques jours, un composant d’un logiciel – que j’utilise qui me permet de gérer mes clés SSH et GPG qui s’appelle Seahorse – est mis à jour. C’est Gnome-Keyring.

Continuer la lecture de « Parfois, certains dogmes du logiciel libre se vérifient… »

Vieux geek, épisode 50 : 1997, l’année où la première génération de Pentium devint… folle :)

1997. Microsoft travaille d’arrache-pied sur MS-Windows 97 (qui sera connu sous le nom de MS-Windows 98 au final) et Intel apprend l’existence d’un bug qui fait planter sa génération de processeur grand public haut de gamme, les Pentium et leur pendant amélioré, les Pentium MMX.

En 1994, les processeurs Pentium avaient déjà eu droit à une première « tempête de merde » avec un bug resté dans les mémoires, le bug dit FDIV. En gros, les premiers Pentium qui allait de 66 à 100 Mhz avait un bug affreux, surtout si on avait besoin de faire des calculs en utilisant des nombres décimaux. Les résultats étaient parfois incorrects.

Mais début novembre 1997, c’est un bug d’un autre niveau qui touche les processeurs d’Intel. Le bug dit F00F met le processeur en rideau. En clair, si le processeur était touché par le bug, le seul moyen de récupérer la main était de redemarrer à la sauvage son ordinateur !

Plutôt ennuyeux comme bug. Si Microsoft proposa un contournement pour MS-Windows NT4, sauf erreur de ma part, aucun correctif ne fut proposé avec MS-Windows 95. J’ai pu trouvé une gazette de février 1998 déclarant ceci :

[…]What about Windows 95, Windows 3.1, and Windows NT 3.5x? Microsoft is still making a determination about how to address this bug in all the other Windows operating systems.[…]

Qu’on peut traduire par :

[…]Qu’en est-il de Windows 95, Windows 3.1 et Windows NT 3.5x ? Microsoft est toujours de prendre une décision sur la façon de résoudre ce bogue dans tous les autres systèmes d’exploitation Windows.[… ]

Du Microsoft de la grande époque, non ? Et le logiciel libre, alors ? J’y viens.

Continuer la lecture de « Vieux geek, épisode 50 : 1997, l’année où la première génération de Pentium devint… folle 🙂 »

Quand on a le don de tomber sur des bugs à la c**…

…ça devient ennuyeux. Hier, j’ai enfin pu installer la totalité de Gnome 3.4 sur mon Archlinux via le dépot gnome-unstable.

Je ne vous ferais pas un premier bilan, l’installation est trop fraîche. Cependant, c’est une version de gnome parmi les plus boguées que j’ai eu l’occasion de voir. Et j’ai comme l’impression que la version 3.4.1 de l’environnement sera la bienvenue d’ici quinze jours environ.

Et surement la plus boguée de la série des 3.x. Et pourtant, j’ai commencé à utiliser Gnome 3 une semaine avant la sortie de la version finale de Gnome 3.0, donc autant dire que j’ai de la bouteille avec cette version de l’environnement.

Je ne parlerais pas de la tendance qu’à dhcpcd à se suicider quand il est utilisé en duo avec NetworkManager 0.9.4.0 et qu’on ose avoir une adresse au format IPv6, ni du bug de GnuTLS qui bloque la synchronisation d’un agenda google avec Evolution. Non.

Un bug plus marrant à fait son apparition récemment, et ne se manifeste que quand j’utilise le pilote propriétaire de Nvidia. La capture d’une fenêtre donne un résultat comme si on utilisait un miroir. En gros, ça donne cela :

Bug de gnome screenshot 3.4 ?!

Ayant rapporté le bug chez Gnome, il s’est révélé être le doublon d’un bug déjà connu, d’un composant de Gnome-Shell, cogl.

Quand je disais dans un précédent article que Gnome 3.4, c’était pas gagné, je n’avais pas complètement tort 🙁

Systemd et Archlinux… Quand ça veux pas…

… ça veux pas. J’ai voulu essayer systemd sur ma machine personnelle aujourd’hui. Après avoir suivi le guide d’installation, assez simple soit dit en passant, j’ai redémarré et utilisé mon ordinateur toute la journée sans problème.

Ce soir, après avoir fait ma sauvegarde hebdomadaire sur DVD, j’ai eu besoin de retrouver un document mis de coté sur DVD il y a environ un mois. Et quand je veux insérer le DVD, l’assistant qui détecte le DVD et propose l’ouverture automatique ne pointe pas le bout de son museau.

Qu’à cela ne tienne, j’ouvre nautilus, et je double-clique sur l’icone du DVD… Et je me fais traiter comme du poisson pourri, m’indiquant que le média ne peut être monté. J’en profite au passage pour récolter des infos pour ouvrir un rapport de bug si nécessaire.

Le message d’erreur est étrange :

Error mounting: mount exited with exit code 1: helper failed with:
mount: mount point /media/cdrom does not exist

Décidant de vérifier que c’est bien un bug de systemd, je relance la machine en désactivant systemd, et miracle, l’assistant me propose d’ouvrir ou d’éjecter le DVD fraichement inséré.

Pour en avoir le coeur net, je recommence l’opération en laissant systemd activé, et bien entendu, ça bloque. J’ai donc ouvert un rapport de bug sur l’outil de suivi d’Archlinux. On verra bien si un correctif sera rapidement apporté 🙂

En attendant, et en espérant que le prochain Gnome ne sera pas super dépendant de systemd, je reste avec les vieux scripts de démarrage qui fonctionnent bien 😉