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 ! »

Vieux Geek, épisode 280 : et si on était un peu hors série ?

C’est en discutant avec une personne sur le réseau (a)social Mastodon que je me suis souvenu d’un site que j’avais créé et maintenu entre fin 1998 et fin 2002. Un site où je regroupais des easter eggs, des petites parodies rapidement faites sous GIMP.

À l’époque, j’étais encore en connexion RTC puis RNIS (dont le nom commercial était Numéris). Il est vrai que je me fournissais en matière sur le site « The Easter Egg Archive ».

À l’époque j’avais acheté un nom de domaine qui transitait via un hébergeur qui a disparu dans l’explosion de la bulle Internet et qui s’appelait citeweb.net.

J’avais tout codé à la main – quand ce genre d’activité était encore possible – en utilisant les frames qui ont disparu dans les années 2005-2010. Je pensais que tout le contenu était perdu à jamais, mais via l’Internet Wayback Machine, j’ai pu retomber sur des captures du site plus ou moins complète, plus ou moins utilisables.

Continuer la lecture de « Vieux Geek, épisode 280 : et si on était un peu hors série ? »

Tenacity et Sneedacity, les deux forks principaux d’Audacity 3.x.

Quand Audacity 3 est sorti, un scandale est arrivé avec lui. Après son rachat par Muse Group, une télémétrie que l’on peut qualifier d’agressive a été rajoutée. Avec une politique de confidentialité assez bizarre. En effet, en recherchant des informations, je suis tombé sur cet article du Monde Informatique du 5 juillet 2021.

Je cite :

Cette politique de confidentialité interdit également aux personnes de moins de 13 ans d’utiliser le logiciel, ce qui, comme le précise FOSS Post, constitue une violation de la licence GPL utilisée par Audacity.

Il n’en fallait pas moins pour que le code source d’origine soit recopié pour être purgé de la partie télémétrie. Deux projets sont apparemment les plus vivaces : Tenacity et Sneedacity. Le premier étant la suite du fork lancé par un développeur au pseudo de Cookie Engineer, l’autre par la communauté de 4chan.

Il s’en serait suivi une campagne de harcèlement à cause du nom du logiciel, allant apparemment jusqu’à des menaces au couteau… Pour l’instant, tout ceci est à prendre avec des pincettes.

Plus d’infos sur ce bug de github et sur un fil reddit.

Pour tout dire, je ne sais pas quoi penser d’une telle déclaration. J’ai voulu voir si les deux forks en question étaient disponibles sur le grand livre de recettes qu’est AUR. Au 13 juillet, je n’ai pu trouver qu’une recette pour Tenacity. Le fork Sneedacity semblant être ignoré pour le moment.

Continuer la lecture de « Tenacity et Sneedacity, les deux forks principaux d’Audacity 3.x. »

« First Blood », premier et meilleur film de la saga John Rambo ?

J’ai toujours considéré la série John Rambo comme un ensemble de films d’action ressemblant à des films de commande pour la propagande de l’époque de Ronald Reagan, combattant les méchants viet-namiens ou encore les méchants afghans et soviétiques. Rambo 2 est sorti en 1985 et le 3 en 1988.

C’est en écoutant la pluie tomber en ce 13 juillet – ou octobre en avance ? – que j’ai eu envie de voir le premier film de la saga John Rambo, celui sorti en 1982. Car j’avais entendu dire que ce n’était pas un bête film d’action.

Je dois dire que j’ai adoré le film, bien que n’étant pas franchement amateur de ce genre cinématographique.

Replaçons-nous dans le contexte de l’époque. Silvester Stallone sort tout juste du succès du deuxième film de la saga Rocky Balboa qu’il intègre le film basé sur le roman de David Morell sorti près de 10 ans plus tôt en 1972.

John Rambo est un ancien béret vert, vétéran du conflit qui secoua la péninsule indochinoise entre 1961 et 1975. Le film commence alors qu’il est à la recherche d’un de ses camarades de combat. Il apprend que ce dernier est mort quelques mois plus tôt d’un cancer lié à l’agent orange.

Il repart donc sur la route, et arrive dans la petite ville de Hope où le shérif Teasle, incarné par Brian Dehenny – le prend pour un vagabond. Il l’emmene jusqu’à la sortie de la ville. John Rambo étant écoeuré décide de faire demi-tour et il est arrêté assez violemment. Il est par la suite maltraité par les hommes du shérif ce qui refait monter en lui les souvenirs douloureux des maltraitances subies.

Il s’évade et s’ensuit une chasse à l’homme qui est le thème principal du film. On n’est pas face à un soldat entraîné à tuer mais face à un vétéran qui se fit cracher dessus dès son retour par les mouvements pacifistes qui rejettait aussi bien la guerre au Viet-Nam – à raison vu comment la chute de Saigon s’est déroulée – mais aussi les vétérans qui ne revenait pas complètement intacts.

Il faut se souvenir qu’en 1982, la guerre du Viet-Nam est à peine fini depuis un peu plus de 6 ans. Autant dire que cela a été un film – surtout avec le dénouement qui arracherait des larmes au coeur le plus dur – qui a marqué et qu’il faut revoir, même si sur certains plans, il fait son âge.

Y a pas à dire… Il y a des semaines à bugs…

Il y a des semaines qui commencent en fanfare sur le plan informatique. Celle qui a commencé le 12 juillet est une semaine qui va être bien chargée côté bugs rapportés sur les différents projets que j’utilise au quotidien.

Aveu préliminaire : j’utilise pas mal de logiciels en version de développement, il est donc normal que je sois face à des bugs. Pour être plus clair, oui, je cherche la merde.

Tout a commencé dimanche 11 juillet dans l’après-midi. En voulant mettre en place une machine virtuelle avec EndeavourOS à l’intérieur, je m’aperçois de la présence de plantages avec LightDM. En fouillant sur l’outil de suivi de bugs d’Archlinux, je tombe sur une entrée qui colle à mon problème.

Je finis par trouver le bug correspondant sur l’outil de suivi de Xorg, et après avoir recherché le code responsable, je trouve l’ajout qui semble être responsable du merdier.

Premier bug de la semaine en voie d’avancement pour la correction. Le deuxième est plus marrant, car on pourrait parler de bug en cascade. Je m’explique.

Je suis utilisateur et mainteneur sur AUR de qemu-git, la version de développement de Qemu qui est un peu la version 100% libre de VirtualBox. Oui, je sais que les puristes vont sortir les torches et préparer le bûcher pour m’y faire cuire comme une merguez, mais c’est pour l’image.

Aux alentours du 7 juillet, j’avais rapporté un bug de compilation qui faisait que le processus s’arrêtait très tôt. Un correctif a été créé et ajouté dans un lot d’autres correctifs. Pour le moment, tout allait bien. Mais non.

Je tente donc lundi après-midi de faire compiler une nouvelle version de développement pour voir si le code ajouté est correct. C’est le cas, mais j’ai droit à un nouveau plantage plutôt tardif du processus de compilation.

J’ai donc ouvert un autre bug dans la foulée… On parie que le correctif pour ce problème fera exploser en vol une nouvelle fois la compilation ?

J’ai aussi parlé rapidement d’un bug que j’ai découvert dans la version de développement de Dosbox-X, mais je vous renvoie à l’article correspondant.

Déjà 4 bugs, et on est que mardi matin… Mais quand on aime, on ne compte pas.

Ce matin, je voulais faire compiler le code de développement de l’émulateur Vice (Commodore PET, Vic20, C64/128, Plus4) et j’ai eu droit à un autre bug de compilation.

Un cinquième bug, le quatrième que j’ai ouvert en l’espace de moins de 36 heures, rédigeant ce billet vers 10 h 00 du matin.

Sur le forum d’EndeavourOS, j’ai pris comme « surnom » sur ma fiche un humoristique « Bugman approved! ». À croire qu’en ce moment, ça me colle bien à la peau !