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/1640dont 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 😉

Network Manager a-t-il révélé un méchant bug dans le noyau linux ?

Il y a quelques temps, j’annonçais l’arrivée de Network Manager sur le dépot current de la Frugalware Linux.

Peu de temps après, j’ai été confronté à un bug assez ennuyeux qui se manifestait après une charge réseau un peu lourde ou une grosse opération de calcul : la connexion wifi rendait l’âme.

J’ai donc ouvert un bug, le 4156. Un bug proche existait déjà, et comme un patch était disponible, Miklos Vajna m’a proposé un patch adapté pour recompiler le noyau.

Après une série de galères pour recompiler le noyau, j’y arrive enfin, et manque de chance, le bug est toujours présent, cependant, une ligne m’interpelle et me donne une piste :


net_ratelimit: 10 callbacks suppressed
ath5k phy0: gain calibration timeout (2412MHz)
ath5k phy0: gain calibration timeout (2467MHz)
ath5k phy0: gain calibration timeout (2412MHz)
ath5k phy0: gain calibration timeout (2472MHz)
ath5k phy0: gain calibration timeout (2412MHz)
No probe response from AP 00:1d:6a:9b:6f:a0 after 500ms, disconnecting.

Après quelques recherches, je m’aperçois que cela ne touche pas que mon circuit wifi, mais aussi d’autres, comme ceux de Broadcomm par exemple.

Un contournement sale a été trouvé, via un bug sur le tracker du site kernel.org sur la fiche du bug 15693 : désactiver toute gestion de l’énergie… Et cela semble fonctionner 🙁

Donc, je compte retourner pour le moment à Wicd qui n’utilise pas la connexion wifi quand la connexion filaire est présente.

Ce sera déjà mieux que de désactiver la gestion de l’énergie, non ? 😉