J'ai décidé ce jour de présenter ma candidature aux éléctions au Conseil openSUSE. Voici pourquoi.

Je ne suis pas un super hacker très expérimenté, je serais plutôt un bidouilleur très intéressé, toujours en apprentissage et aimant partager autour de savoir-faire techniques.

Depuis que je suis passé à openSUSE (voir ici), j'ai pris plaisir à créer et maintenir des paquets, dont certains sont maintenant dans les dépôts officiels. Petit à petit, j'ai rejoins la communauté française, jusqu'à devenir président de son association, Alionet, l'an dernier. J'ai aussi écrit quelques articles, avec l'aide de Seb95 de passionlinux, je traduit et relaie les news du projet openSUSE et je suis régulièrement présent sur le stand openSUSE lors des événements du Libre en France.

Et pourquoi je voudrais candidater au conseil openSUSE alors ?

Eh bien, simplement parce que c'est un projet qui me plaît. Je prends plaisir à y contribuer, c'est simple et accueillant, même quand j'ai fait des erreurs lors de la construction de mes premiers paquets les discussions étaient ouvertes et détendues, chose parfois rare dans le Libre. Je n'ai pas non plus trouvé de guerres de chapelles dans ce projet, ou moins qu'ailleurs il m'a semblé. Faire acte de candidature est donc pour moi un moyen de rendre à ce projet ce que j'ai pu en apprendre et c'est aussi une façon de démontrer mon intérêt et qu'il compte pour moi.

Si je venais à être élu au sein du Conseil, il y a deux sujets sur lesquels je souhaite plus particulièrement travailler:

• le lien avec les communautés d'utilisateurs: comment les encourager et les accompagner à contribuer ? comment mieux coopérer avec les groupes d'utilisateurs existants ?
• il y a eu de nombreuses discussions très intéressantes sur la forme juridique du projet il y a plusieurs mois. Si ces sujets sont encore d'actualité, je souhaite m'y pencher. Réfléchir et travailler à la transformation d'un tel projet sera sûrement une expérience passionnante.

Vous pouvez trouver plus d'infos sur mes contributions sur:

• ma page wiki: https://en.opensuse.org/User:Sogal
• ma page Connect: https://connect.opensuse.org/pg/profile/sogal

Si vous êtes membre du projet, je vous encourage à vous intéresser au processus d'éléctions en cours, voire même à vous présenter également!

Le rythme des snapshots a été un peu plus calme et c'est donc seulement 5 clichés qui ont été publiés fin 2018. N'avaient pas encore été couverts dans des revues antérieures les instantanés 1213, 1214, 1218, 1219 et 1224. Après cela, un soucis dans OBS nous a forcé à faire une pause et à ne pas créer de nouveaux instantanés.

Quoi qu'il en soit, les quelques modificiations qui ont été publiées avec ces 5 instantanés sont:

• Mesa 18.3.1 (mise à jour 18.1.x)
• Qt 5.12.0
• Noyaux Linux 4.19.8 et 4.19.11
• Mozilla Firefox 64.0
• Applications KDE 18.12.0
• KDE Frameworks 5.53.0
• Passez à LLVM 7
• Perl 5.28.0

Vitesse lente donc mais impact important. C'est bien de voir qu'autant de piles majeures ont pu être mises à jour / soumises / testées / publiées avant la fin de l'année.

Mais, comme vous en avez certainement l'habitude, openSUSE Tumbleweed ne serait pas appelé « rolling-release stable » s'il n'y avait pas beaucoup d'autres choses en attente. Et stable signifie que nous ne publions pas d'instantanés tant que les tests openQA soient réussis. Il y aura donc des mises à jour majeures à prévoir dans les prochains jours / semaines:

• Nouveau design de l'installateur: la barre latérale revient, indiquant où on se trouve le processus d'installation. Ceci est déjà vérifié dans Factory et prendra un peu de temps pour tout bien régler dans openQA. C’est aussi la raison principale pour laquelle aucun nouvel instantané n’a lieu pour le moment.
• glibc 2.28, Python 3.7, openssl 1.1.1: toujours en attente pour l'instant dans la mesure où Python 3.7 est connu pour être incompatible avec Salt. De plus, certains cycles de construction dans Factory rendent presque impossible sa mise à jour en 3.7.
• Noyau Linux 4.20.
• tcl 8.6.9, qui casse actuellement la suite de tests de sqlite3.

Tags: opensuse

Parmi les jeux de rôles que j'aime bien, il y a Divinity Original Sin. La suite du jeu, le 2, est sorti il y a quelques temps et je me le suis offert en cette fin d'année sur console. Du coup ça m'a fait pensé que le premier opus, qui a quelques années maintenant, tournerait peut-être correctement sur mon portable (openSUSE Leap). J'ai donc regardé sur GOG et, cool, il était à 9,99€, c'est parti pour le téléchargement.

Une fois récupéré, l'installeur se présente sous la forme d'un script qui va installer les composants du jeu.

Une fois installé, j'essaye de le lancer et pas de bol, ça plante ! Je me retrouve avec des erreurs du type :

(0) /usr/lib/libpthread.so.0 : +0x10d60 [0x7f360f099d60]
(1) ./libOGLBinding.so : api::OpenGLRenderer::ApplyConstants()+0x65 [0x7f360ffd57d5]
(2) ./libRenderFramework.so : rf::Renderer::Apply(bool)+0x57 [0x7f360fc74207]
(3) ./EoCApp : ig::IggyBinding::Swap(rf::Renderer*)+0xfc [0xebf16c]
(4) ./libGameEngine.so : BaseApp::EndDrawGUI(rf::Renderer*)+0x9b [0x7f360fdd288b]
(5) ./libGameEngine.so : BaseApp::MakeFrame()+0x3a4 [0x7f360fdd2db4]
(6) ./libGameEngine.so : BaseApp::OnIdle()+0xe0 [0x7f360fdd1590]
(7) ./EoCApp : main+0x170 [0x6d4430]
(8) /usr/lib/libc.so.6 : __libc_start_main+0xf0 [0x7f360ed01610]
(9) ./EoCApp : _start+0x29 [0x6d41a9]

En farfouillant un peu sur le Web, je trouve un rapport de bug sur Freedesktop.org.

Par chance, ce dernier contient une solution : il faut récupérer un pre-loader qui va pallier le soucis:

curl https://bugs.freedesktop.org/attachment.cgi\?id\=125302 > divos-hack.c

Puis le compiler :

gcc -s -O2 -shared -fPIC -o divos-hack.{so,c} -ldl

Et le copier dans le répertoire contenant les données du jeu :

cp divos-hack.so $HOME/Jeux/Divinity_Original_Sin_Enhanced_Edition/game/

Enfin, il convient d'adapter le lanceur du jeu. J'ai créé un petit wrapper qui lance le jeu avec les options correctes :

#!/bin/bash

allow_glsl_extension_directive_midshader=true LD_PRELOAD='$HOME/Jeux/Divinity_Original_Sin_Enhanced_Edition/game/divos-hack.so' $HOME/Jeux/Divinity_Original_Sin_Enhanced_Edition/start.sh

Puis j'ai adapté le lanceur présent dans $HOME/.local/share/applications/gog_com-Divinity_Original_Sin_Enhanced_Edition_1.desktop :

[Desktop Entry]
Encoding=UTF-8
Value=1.0
Type=Application
Name=Divinity: Original Sin - Enhanced Edition
GenericName=Divinity: Original Sin - Enhanced Edition
Comment=Divinity: Original Sin - Enhanced Edition
Icon=/home/user/Jeux/Divinity_Original_Sin_Enhanced_Edition/support/icon.png
Exec="/home/user/Jeux/Divinity_Original_Sin_Enhanced_Edition/DivinityLauncher.sh"
Categories=Game;
Path=/home/user/Jeux/Divinity_Original_Sin_Enhanced_Edition

Attention : dans ce fichier il faut bien passer les chemins complets.

Ceci fait, le jeu se lance sans problème et je peux en profiter durant mes trajets quotidiens en train, le tout sur un simple Thinkpad T450 avec une puce graphique Intel et sous openSUSE of course !

Tags: tips

Au cours de la semaine 50/2018, Tumbleweed a reçu 4 instantanés: 1206, 1208, 1211 et 1212. Les principales modifications concernent les paquets suivants :

• Noyau Linux 4.19.7
• Ruby Rails 5.2.1.1 (modifications liées à CVE)
• Guile 2.2.4, mis à jour depuis la branche 2.0
• util-linux 2.33
• Mise à jour du thème XFCE4, comme annoncé dans la liste de diffusion.

Il reste toutefois quelques « gros morceaux » en attente, même si certains font des progrès mineurs :

• glibc 2.28, Python 3.7, openssl 1.1.1 : le principal paquet bloquant, qui empêchait les paquets en attente de construire, a pû être identifié (perl5.28 provoquait une boucle sans fin dans makeinfo lors de l'exécution). La zone de staging est encore loin d’être prête, Python 3.7 étant notoirement incompatible avec Salt.
• Mesa 18.3
• LLVM7: échec de la construction de Rust avec LLVM7
• Nouvelle design de l'installateur : la barre latérale revient (indiquant où se trouve actuellement le flux de travail d'installation)
• PostgreSQL 11
• Noyau Linux 4.19.8
• Perl 5.28
• Qt 5.12.0
• Applications KDE 18.12.0

On dirait que la liste des changements en attente s'allonge de semaine en semaine, en partie du fait que de plus en plus de développeurs semblent, et c'est bien normal, occupés à préparer leurs vacances. Mais il y a en encore bien assez pour que Tumbleweed continue de rouler ! :)

Tags: opensuse

Aujourd'hui juste une petite astuce, ou un rappel pour certains, sur la façon de sécuriser une connexion VNC grâce à l'usage d'un tunnel SSH.

Dans ce post, je suppose que vous avez déjà une connexion SSH fonctionnelle entre votre poste et la machine cible (celle qui exécute le serveur VNC). Cela peut être réalisé très simplement via la commande suivante :

ssh -f -L 5901:localhost:5901 machine.domain.tld sleep 10 ; vncviewer-tigervnc 127.0.0.1:5901

Si on décompose la commande, cela donne :

• -f : on demande à SSH d'exécuter la commande qu'on va lui passer en arrière-plan, ce qui évite une coupure du flux et nous permet d'exécuter le client VNC par la suite ;
• -L 5901:localhost:5901 : on va rediriger les connexions s'effectuant sur la machin client et sur le port 5901 vers le port 5901 de la machine distante ;
• machine.domain.tld : la machine distante, qui exécute le serveur VNC ;
• sleep 10 : la commande à faire exécuter sur la machine distante, cela nous permet de conserver la connexion ouverte car l'option -f requiert forcément une commande à passer en arrière-plan. Et comme on va lancer notre client VNC dans la foulée, il y aura toujours un flux de données et la connexion sera maintenue. En revanche, si le client VNC est fermée, la connexion se fermera au bout de 10 secondes ;
• vncviewer-tigervnc 127.0.0.1:5901 : on connecte le client VNC sur le port local 5901, connexion que SSH va rediriger vers le port 5901 distant, comme indiqué ci-dessus.

Si l'on ne veut pas que le serveur VNC tourne en permanence sur la machine distante, on pourrait même imaginer ajouter une pré-commande du type :

ssh machine.domain.tld vncserver :1

Puis une post-commande pour terminer le serveur VNC une fois qu'on a fini :

ssh machine.domain.tld vncserver -kill :1

Tags: tips

btrfs est un système de fichier moderne, donné pour être le remplaçant du veillissant, mais toujours très fiable et très utilisé, ext4. Il est le choix de base de la proposition de partitionnement par défaut lors de l'installation d'openSUSE pour la partition racine. La partition /home, si l'utilisateur fait le choix d'en créer une séparée, est en xfs.

On a entendu beaucoup de chose sur l'usage (ou le mésusage selon les cas) de btrfs avec notamment des problèmes dûs aux scripts de maintenance (présents dans /usr/share/btrfsmaintenance/ et lancés par leur timers systemd respectifs). Il faut reconnaître que les opérations de scrub et de balance des blocs ralentissent, parfois, considérablement le système durant un instant. Et plus on attend pour le faire (ex. d'un système n'étant pas utilisé souvent et, à chaque utilisation, recevant une grande quantité de données sur le disque), plus il y a de travail à faire et cela peut durer jusqu'à 5 minutes, durant lequel la machine est très ralentie, voire peut apparaître bloquée. Je ne vais pas revenir là-dessus, ce sujet a été abordé maintes fois à grand coup de trolls, de mauvaise foi et d'arguments non factuels à plusieurs endroits.

Dans ce billet, je voudrais juste partager un retour d'expérience, positif, sur l'usage de btrfs non seulement sur la partition racine, mais également dans ma partition /home. En effet, j'ai décidé il y a plusieurs semaines de convertir ma partition xfs (proposition de base de l'installeur openSUSE) en btrfs afin de profiter des snapshots.

Pour ce faire, j'ai commencé par passer en runlevel 3 :

init 3

J'ai fait une sauvegarde de mon /home actuel sur un disque externe :

rsync -arv --progress /home/ /run/media/user/DISK_BACKUP/

Ceci fait, j'ai démonté mon /home :

umount /home

Puis formater la partition en btrfs. Notez ici que si ça avait un système de fichier de type ext2/3/4 ou reiserfs, j'aurai pu tout simplement le convertir en btrfs, sans perte de données, via la commande btrfs-convert -p -l home /dev/partition_home. Pour formater la partition donc :

mkfs.btrfs -L home /dev/partition_home

Ceci fait, ne pas omettre de modifier le /etc/fstab pour refléter le changement de système de fichier. J'ai ensuite créé un sous-volume btrfs au nom de mon utilisateur :

btrfs subvolume create /home/user

Dans lequel j'ai activé les snapshots, but de toute l'opération :

snapper -c home create-config /home/user

Ceci va me créer une configuration pour snapper, l'utilitaire en charge de gérer la création et la suppression des snapshots, dans /etc/snapper/configs/home que j'ai adapté à mes besoins comme suit :

# nom du sous-volume dont il faut prendre un instantané
SUBVOLUME="/home/user"

# type du système de fichier
FSTYPE="btrfs"

# btrfs …

Voici une petite astuce bien pratique lorsqu'on utilise des virtualenv Python. C'est quand même assez pratique, quand on a plusieurs terminaux ouverts, de savoir si oui ou non on se trouve dans un virtualenv et si oui, lequel. Ça peut éviter des bêtises aussi.

Pour ce faire, j'ai ajouter les éléments suivants à mon $HOME/.zshrc:

function virtualenv_info () {
    [ $VIRTUAL_ENV ] && echo "($(basename $VIRTUAL_ENV)) "
}

export VIRTUAL_ENV_DISABLE_PROMPT=0

Puis dans mon prompt, j'ai ajouté $(virtualenv_info) comme suit:

LPROMPT='$(virtualenv_info)$(pwd_icon) %F{yellow}%2c%f %F{magenta}❱%f '

Ce qui donne, dans mon prompt complet:

Tags: terminal, tips

Cela faisait déjà plusieurs mois que je voulais changer le site pour du statique dans lequel je puisse écrire en Markdown avec un déploiement automatique. C'est chose faire, enfin !, grâce à Bashblog. Il s'agît d'un script tout simple en Bash.

J'ai importé la plupart des vieux articles, mais pas tous, trop pénible ou certains étaient obsolètes.

Avec ce flux de travail simplifié, j'espère pouvoir retrouver la motivation d'écrire. @+

Aujourd'hui vendredi 25 mai, c'est la sortie d'openSUSE Leap 15.0 !

Au menu de cette release :

• un nouveau rôle de serveur transactionnel permettant des mises à jours atomiques ;
• GNOME 3.26 ;
• Utilisation de Wayland par défaut (mais Xorg reste disponible) ;
• Un nouveau partitionnement Btrfs utilisant la libstorage-ng ;
• firewalld remplace SuSEFirewall ;
• bien d'autres nouveautés (voir les release notes )

Et pendant que vous lirez ces lignes, je serai à Prague, en train de visiter et d'assister la conférence openSUSE 2018 et de fêter cette sortie !

Have a lot of fun !

Tags: opensuse