Rapporter des bugs, c’est bien…

…Ne pas se précipiter pour le faire, c’est encore mieux. Cela fait 17 ans que je suis en mono-démarrage linuxien, à l’époque avec la Ubuntu 6.06 LTS après une semaine sous OpenSuSE 10.1 à l’époque. J’ai donc eu l’occasion au fil de ces années de rapporter des bugs.

Le problème avec les outils de suivi des bugs, en anglais bugtracker, c’est qu’ils sont remplis de rapports de bugs en double, triple, quadruple voire quintuple exemplaire. En effet, dans la précipitation, on oublie de vérifier si le bug a été rapporté… Outre le fait que cela encombre et pollue le bugtracker, ça complique la vie des développeurs qui essaye de trier les bugs pour corriger ce qui a été rapporté.

J’ai appris avec le temps qu’il fallait faire attention et ne pas agir précipitamment. J’ai eu un bug étrange avec mercurial et le code source de développement de Mozilla Firefox et de Mozilla Thunderbird.

En effet, quand je tapais la commande hg --verbose pull -u pour récupérer les nouveautés s’il y en a de disponible, j’avais droit à ce long message d’erreurs avec mercurial 6.6.

$ hg –verbose pull -u
Traceback (most recent call last):
File « /usr/lib/python3.11/site-packages/mercurial/dispatch.py », line 466, in _callcatch
return scmutil.callcatch(ui, func)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File « /usr/lib/python3.11/site-packages/mercurial/scmutil.py », line 152, in callcatch
return func()
^^^^^^
[environ 60 lignes d’erreurs plus loin]

File « /usr/lib/python3.11/site-packages/mercurial/extensions.py », line 613, in wrap
return wrapper(origfn, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File « /usr/lib/python3.11/site-packages/hgext/fsmonitor/__init__.py », line 747, in wrapdirstate
if hasattr(self, b’_fsmonitorstate’):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: attribute name must be string, not ‘bytes’

J’avais d’abord pensé à un bug du côté de Mozilla, mais sur le bugzilla, rien de bien probant en utilisant la recherche par mots clés.

J’ai ensuite pensé à un bug du côté de mercurial 6.6. En utilisant l’outil AUR downgrade, j’ai rétrogradé la version de mercurial à la 6.5.2. Et d’un seul coup, tout a fonctionné comme prévu.

Continuer la lecture de « Rapporter des bugs, c’est bien… »

Et si une grande purge du Linux bureautique arrivait, qui resterait en vie ?

C’est un exercice de pensée que j’ai eu envie de faire. Qui resterait en vie si un jour une grande purge avait lieu dans le petit monde des distributions GNU/Linux à destination bureautique.

Je parle des distributions génériques et « passe-partout » pour les linuxien(ne)s de tous niveaux.

Je ne prétends à aucune exhaustivité, juste à faire de mon mieux pour n’oublier personne. En cas d’oubli, les commentaires sont les bienvenus.

Il resterait selon moi :

1) Les distributions GNU/Linux mères, à savoir par ordre alphabétique :

Continuer la lecture de « Et si une grande purge du Linux bureautique arrivait, qui resterait en vie ? »

Pourquoi j’ai quitté le projet EndeavourOS.

Cela faisait pas mal de temps que je ne participais plus aussi activement au forum qu’au début du projet. Mon activité s’était résumé à continuer les traductions de l’outil Welcome, et quand les sous-forums par langue existaient, j’y postais les traductions des notes de publication.

Mon intérêt et mon implication dans le projet diminuait lentement. Il faut dire que certains choix techniques m’ont fait m’éloigner encore plus du projet. À savoir :

  1. La mise en place du dépôt tiers au dessus des dépôts officiels dans /etc/pacman.conf
  2. L’utilisation de dracut en lieu et place de mkinitcpio
  3. Proposer systemd-boot par défaut au lieu de grub
  4. Le passage à KDE comme environnement par défaut de l’image ISO live

C’est pour cela que j’ai publié un post dans le forum d’EndeavourOS pour annoncer mon départ du projet.

Continuer la lecture de « Pourquoi j’ai quitté le projet EndeavourOS. »

En vrac’ de milieu de semaine…

Petit en vrac’ en ce quatrième mercredi de novembre 2023.

Côté logiciel libre, informatique et internet.

  • EndeavourOS a sorti une nouvelle image ISO dont la principale nouveauté visible est le remplacement de Xfce par KDE sur l’image ISO live. Plus d’infos sur les notes de publications en anglais que je n’ai pas eu le temps de traduire. Désolé.
  • Dans le petit monde des distributions de la famille RHEL élargi, il ne manquait plus que Rocky Linux en version 9.3. C’est désormais chose faite.
  • C’est officiel. Le noyau Linux LTS de l’année 2023 sera le 6.6 avec un support de 3 ans. Plus d’infos sur l’article de Phoronix.
  • Souhaitons – avec un peu de retard – un bon anniversaire à MS-Windows 1.01 (le premier de la série des 1.0x) qui est sorti il y a 38 ans, le 20 novembre 1985.

Côté culture ?

Si vous aimez le dark ambiant aux pistes longues, le double album de Steve Roach « Sanctuary Desire » est pour vous. Merci à Agnès de Destination Passions pour m’avoir orienté vers cet album.

Sur ce, bonne fin de semaine !

Un petit bilan de mes expérimentations avec la Fedora Linux 39.

Dans un article vieux de quelques jours – au moment où j’écris cet article le 19 novembre 2013 – j’évoquais quelle serait ma porte de sortie si Archlinux venait à disparaître.

Après avoir fait compilé l’émulateur Vice en version de développement (cf la vidéo ci-dessous), je me suis attaqué à d’autres émulateurs que j’utilise au quotidien ou presque 🙂

Voici les dépendances que j’ai rajouté à la Fedora Linux 39 pour pouvoir compiler Vice en version de développement :

  • ‘Development Tools’ (avec groupinstall)
  • ‘C Development Tools and Libraries’ (avec groupinstall)
  • compat-ffmpeg4-devel (en provenance des dépôts rpmfusion)
  • xa
  • texlive
  • texinfo-tex
  • gtk3-devel
  • glew-devel
  • libcurl-devel
  • pulseaudio-libs-devel
  • alsa-lib-devel

J’ai continué avec Dosbox-X – en version de développement – avec son interface en SDL2 en ajoutant les dépendances suivantes :

  • fluidsynth-devel
  • libslirp-devel
  • SDL2_net-devel

Continuer la lecture de « Un petit bilan de mes expérimentations avec la Fedora Linux 39. »