En allant sur le blog de Seb alias « Passion GNU/linux », je suis tombé sur un billet écrit le premier avril 2019 qui me semblait au premier abord avoir une odeur marine. Mais en lisant le contenu, je me suis aperçu que ce n’est pas franchement le cas.
Pour résumer, les mainteneurs de la Debian GNU/Linux ayant des emmerdes importantes avec Synaptic ont décidé de le retirer de la version principale, à savoir la saveur GNOME pour processeurs AMD/Intel.
La principale raison invoquée ? L’impossibilité de lancer Synaptic avec Wayland. Bug ouvert en 2016. De mémoire, Gnome propose d’utiliser la session Wayland par défaut depuis… Gnome 3.22 avec la Fedora 25. Même s’il a fallu bien attendre encore une ou deux versions pour être tranquille. Donc on va dire Gnome 3.26, ce qui remonte à septembre 2017…
Bref, même avec un cycle de vie de deux ans, il était prévisible que Synaptic soit un jour avec la tête sur le billot. Pour information, le code n’a plus évolué depuis… début 2017, dixit la page launchpad du projet.
Autant dire que le logiciel est plutôt au ralenti depuis environ deux ans. Mais ce ne sera sûrement pas le seul logiciel qui risque de souffrir d’une popularisation croissante de Wayland, que ce soit avec Gnome ou d’autres environnements. Je pense aussi à OBS Studio ou encore Simple Screen Recorder.
Ce n’est pas parce qu’un outil fonctionne qu’il ne faut pas adapter son code aux nouveautés qui interviendront tôt ou tard. Après, cela dépend de la qualité du code du dit logiciel.
Le deuxième exemple, c’est celui du menu Brisk, développé à l’origine conjointement par Solus et Ubuntu Mate. Suite au départ d’Ikey Doherty – qui était son principal et unique codeur ? – le menu a été laissé à l’abandon durant de nombreux mois.
Manque de chance, lors du développement de Mate-Desktop 1.22 sur lequel le menu Brisk se base, des API ou interfaces de programmation applicatives ont été modifiées.
Résultat des courses ? Impossible de compiler le logiciel. Un développeur lié au projet Mate avait proposé un patch, qui est resté lettre morte durant de nombreux mois. Après l’application du patch, on pouvait compiler le menu, mais il plantait comme un MS-Windows Millenium sous amphétamines.
Un contournement temporaire applicable étant de désactiver l’affichage des icones de catégories. Je vous renvoie au fil lié à ce patch pour en savoir plus.
J’avais aussi fait une vidéo pour expliquer les problèmes liés à la migration vers Mate-desktop 1.22.
Maintenant, il reste à espérer autant pour le menu Brisk que pour Synaptic que le code sera adapté à des technologies plus récentes. Car ce serait con de perdre deux outils qui ont fait leurs preuves à cause du manque de suivi de l’évolution des technologies dont ils dépendent.
Ta perception de la situation du menu brisk est erronée.
Solus développe de très nombreux projets, l’activité sur ces projets varie selon les plans de (la petite) équipe, il est donc normal que certains projet restent en sommeil pendant des périodes plus ou moins longues, ça a toujours été ainsi. Le départ non planifié de Ikey (qui était le seul développeur à plein temps sur le projet) et le fait que les dons (dont un des objectif était d’engager un développeur pour le projet) sont suspendus ont un impact significatif sur les objectifs qui étaient fixés (Le nouveau Software Center, L’installateur et Budgie 11) mais n’en ont pas (en tout cas directement) sur le menu Brisk.
Il s’agit d’un simple problème d’agenda: MATE 1.22 est sorti très peu de temps avant la release de la Solus 4 (d’ailleurs MATE 1.22 a été annoncé officiellement le lendemain de la sortie de la Solus 4). Donc Solus n’a pas besoin de se presser. https://getsol.us/2019/03/17/solus-4-released/
MATE sera migré sur la version 1.22 pour la Solus 4.1.
Ubuntu MATE pour sa part a aussi décidé de rester sur MATE 1.20 pour la version 19.04, sachant que la prochaine release sera la 19.10, ils ne sont pas non plus pressés.
https://ubuntu-mate.org/blog/ubuntu-mate-disco-beta/
C’est embêtant pour les autres distributions qui ont déjà adopté MATE 1.22, on en est conscient et comme je l’ai dit dans les commentaires du patch, on est prêt à tagger une nouvelle release de brisk dès que possible mais pas à n’importe quel prix. Si des contributions de qualité sont proposées elles seront bien entendu acceptées avec gratitude. Sinon, il faudra attendre que Solus fasse les adaptations nécessaires et cela se fera selon le calendrier de la Solus 4.1.
Mais son fonctionnement cassé ne l’est pas lui.
L’équipe a simplement eu les yeux plus gros que le ventre. Ça arrive et le départ du codeur principal de Brisk, ça n’a pas aidé.
J’avais envie de faire une blague, mais non.
Et à cause de quoi ? Un patch pour prévenir des changements d’API – celui de Viktor Kareh était disponible dès juillet / août 2018… Autant dire, il y a plusieurs mois de cela. Pile au pire moment de la crise suite au départ d’Ikey.
C’est cela le problème. Sans feuille de route précise, c’est le flou. En tout cas, sans le patch de Viktor et celui en cours proposé par Wascar, Brisk menu continuerait de planter comme un Windows Millenium sous amphétamine quand il est utilisé conjointement avec Mate 1.22.
C’est cela que je retiens. Désolé d’être énervé, mais avoir passé une après-midi à essayer d’apporter une pierre pour un correctif temporaire et être limite accueilli comme des chiens dans un jeu de quille, ça refroidit.
> Mais son fonctionnement cassé ne l’est pas lui.
Mensonge. Il fonctionne très bien. Tu l’utilises sur une version non supportée de MATE, et ca te troue le c.. de l’admettre.
> L’équipe a simplement eu les yeux plus gros que le ventre. Ça arrive et le départ du codeur principal de Brisk, ça n’a pas aidé.
L’équipe a payé le prix du départ de ikey sur une série d’activités qui ont du être accélérées (migration de l’infrastructure), ou qui n’étaient pas prévues établissement d’une entité juridique pour Solus, migration vers un nouveau domaine, réorganisation des accès, mise en place de nouveaux projets pour la communauté, etc. En outre 3 développements importants prévus n’ont pas été livrés et cela à entraîné des retards sur Solus 4 donc oui ça n’a pas aidé mais malgré toute ta mauvaise foi, ça n’a pas d’impact significatif sur brisk… D’ailleurs parmi les développements qu’on a fait le mois passé, il y avait une extension pour Flarum… alors qu’on aurait pu passer du temps sur brisk… Il s’agit là de simple priorités, ce que tu ne veux pas admettre.
> Et à cause de quoi ? Un patch pour prévenir des changements d’API – celui de Viktor Kareh était disponible dès juillet / août 2018… Autant dire, il y a plusieurs mois de cela. Pile au pire moment de la crise suite au départ d’Ikey.
Un patch sur la version 1.21 de MATE çàd la version de développement. Patch envoyé pour review pour d’autres développeurs (explicitement taggés) : https://github.com/solus-project/brisk-menu/pull/103#issuecomment-395205959
Il s’agit là d’une pratique courante, normale et saine. Par contre on a JAMAIS eu l’intention de valider/merger ce patch tant que MATE 1.22 n’était pas officiellement sorti et si le PR est apparu sur le fork getsolus juste avant la sortie de MATE ce n’est pas par magie mais parce qu’on a informé les membres qu’on allait commencer à tester les changements.
La feuille de route est très simple: une nouvelle version stable sort, on teste, si des changements sont nécessaires, on évalue les contributions et le cas échéant on fait le modifications nécessaire pour l’intégrer à Solus le moment opportun càd pour la version 4.1 https://dev.getsol.us/T7794
brisk-menu est un projet conjoint de Solus *ET* de Ubuntu MATE (et non d’un seul développeur). Ils ont les droits sur le repository, ils auraient aussi pu retravailler le patch de Viktor si ils l’avaient souhaité. La version 19.04 sort le 18 avril et ils viennent juste de publier la beta 1 il y a quelques jours. Si ils ont choisi de rester sur MATE 1.20 c’est qu’ils y a d’autres problèmes à résoudre. Si il n’y avait eu que brisk-menu, ils l’auraient déjà mis à jour.
Désolé d’être aussi direct mais les projets de Solus ne sont pas dictés les autres distributions. On intégrera pas de correctif TEMPORAIRE dont on a pas besoin car ne t’en déplaise ni Solus, ni Ubuntu MATE ne supportent actuellement MATE 1.22. Si un bon patch est proposé, il sera bien entendu intégré avec grand plaisir et une nouvelle version sera publiée sans délais. Sinon il faudra attendre Solus 4.1.
En ce qui concerne ArchLinux, j’imagine que brisk-menu n’est pas dans les dépôt principaux sinon il aurait été patché, les responsables sont habitués à ce gérer ce genre de chose pour pouvoir assurer le rythme des mises à jour. Je suppose donc que brisk se trouve dans un dépôt tiers (AUR). C’est au gestionnaire de ce dépôt que tu dois te plaindre car c’est cette personne qui est la SEULE ET UNIQUE RESPONSABLE de ce qu’elle délivre. C’est son boulot (même si ce n’est toujours pas évident) de s’assurer que son paquet sera prêt à temps et ce même si la source ne suit pas. Malheureusement dans les dépôts tiers beaucoup s’improvisent mainteneur sans se soucier d’avoir les compétences requises et se vautrent au moindre problème or être mainteneur ce n’est pas UNIQUEMENT suivre les versions de la source et publier quand il y a une mise à jour !
Je vais rester calme, car le message plutôt limite auquel je réponds n’est pas fait pour apaiser les ménages.
Non supportée, oui, MAIS C’EST LA DERNIÈRE disponible. C’est un fait que tu ne peux pas nier. Qu’il y ait inadéquation entre le menu et la version de Mate, c’est un autre fait.
Ma mauvaise foi. Attaque ad personam, faute d’argument. Je n’ai jamais nié qu’ils avaient eu des emmerdes. J’ai simplement dit qu’ils étaient au courant du cassage d’API. Évidemment, sans une nouvelle version stable pour compiler, c’est difficile, je te le concède.
L’équipe avait de nombreux projets avant le départ d’Ikey et celui-ci a montré que c’était trop au final.
Ai-je dit le contraire ? Simplement, j’ai dit que le projet était au courant. Après, que le code ait souffert – comme d’autres projets – du départ d’Ikey, qui dirait le contraire ?
Ensuite, les autres distributions ne sont pas aux ordres de Solus pour savoir quand mettre à jour tel ou tel logiciel précis.
Merci pour la page, j’ignorais son existence.
C’est juste un des composants de l’interface d’Ubuntu Mate… Normal qu’avec la version 1.22 de l’environnement qui a pris son temps de repousser de 6 mois l’intégration dans Ubuntu.
Quant au code de Brisk, qui y a touché historiquement ? Sur la version d’origine donc 419 commits, Ikey en a proposé… 386 ! Autant dire que c’est un projet assez mono-développeur avec des apports ponctuels.
Source ? https://github.com/solus-project/brisk-menu/commits/master
Tant pis si des dizaines de personnes se retrouvent avec un menu inutilisable faute d’une inadéquation entre le menu et l’environnement ? Dommage 🙁
AUR est géré par les trusted users, qui regarde tant bien que mal ce qui s’y trouve. Je maintiens la version git du brisk-menu et je suis co-mainteneur du paquet en version stable. Sans les bidouillages comme ceux proposés, nombre de personnes seraient plantés actuellement. C’est tout.
Je passerai sur l’autre attaque ad personam de ce paragraphe. Je fais tout pour proposer des paquets fonctionnels, et si j’ai patché le paquet brisk-menu-git et le stable, c’est simplement pour proposer aux personnes qui utilisent le paquet quelque chose qui fonctionne.
Pas pour le plaisir de me faire mousser l’ego… Non, juste par honnêteté !
Soit tu es de très mauvaise foi, soit tu es tellement borné que tu n’arrives pas à comprendre des concepts simples :
Brisk-menu est un projet conjoint de Solus & Ubuntu MATE Solus 4/Ubuntu MATE 19.04 proposent MATE 1.20 et contrairement à ce que tu essaies de faire croire avec je te cite son « fonctionnement cassé », brisk-menu fonctionne PARFAITEMENT avec les versions actuellement supportées de MATE. Ce n’est pas parce que le code est mis à disposition librement qu’il est dit que les équipes le mettre à jour en suivant le rythme de publication de MATE ou de quelques autres distributions. Les équipes mettent le code à jour en fonction de leur propre agenda, ce qui n’empêche nullement d’autres contributeurs de proposer des PR si ils ont du faire les changement nécessaire plus tôt pour leurs propres besoins.
La dernière mise à jour de brisk qui était sur la feuille de route de Solus était la version https://getsol.us/2017/11/02/brisk-menu-0-5-0-released/
Et la quazi totalité des modifications qui ont été effectuées par la suite sont le fruit de contributeurs divers.
Au passage que tu sais aller commenter le PR au sur le fork actif
https://github.com/getsolus/brisk-menu
Mais que tu utilises le projet que tu sais mort pour citer ta source
https://github.com/solus-project/brisk-menu
Tout ca pour dire 419 au lieu de 426 commits
Et après tu vas dire que tu ne fais absolument pas preuve de mauvaise foi… non, c’est certain que c’est juste une erreur de « distraction », bien entendu.
Et on commence par une attaque ad-personam. Je ne t’ai jamais attaqué sur la personnalité en t’accusant de je ne sais quoi, mais tu le fais sans aucune mauvaise conscience.
Version qui est l’ancienne stable de Mate qui va petit à petit être remplacée, sauf pour Debian Buster et Ubuntu d’ici la 19.10. Donc en gros, cela laisse une fenêtre de tranquillité de quelques semaines voire quelques mois.
Dès que les distributions passeront les unes après les autres à Mate 1.22, les dégats commenceront à être visibles avec les personnes qui gueuleront et ne chercheront pas à comprendre. La technique, les personnes s’en foutent royalement pour la plupart. Si ça fonctionne pas, c’est mal, point barre.
Ce que j’ai fait pour éviter que des centaines d’utilisateurs ne se retrouvent avec un menu qui leur explose en pleine face à la prochaine mise à jour, c’est de récupérer et d’appliquer des patchs. Limiter la casse, c’est mal ? Sûrement. En tout cas, j’essaye – preuve que je suis complètement borné – de me placer au niveau de l’environnement, pas de la distribution qui lui sert de base.
Depuis la version 0.5.0, il y a eu une trentaine de modifications sur le git. Soit 30/426 donc… 7% du total, ce qui est énorme… Surtout avec les désagréments qui ont touché le projet Solus en 2018 qui dépendait – un peu trop – de son fondateur.
J’ai simplement dit – et cela se vérifie avec l’historique des commits – que c’est un projet qui essentiellement lié à Ikey Doherty depuis sa naissance. C’est faux de le dire ?
Quant à ton attaque de fin de commentaire, rien à dire. J’ai été le dindon de l’histoire en offrant du temps libre pour rapporter des logs, proposer des patchs et confirmer que ça allait mieux. Je vais lever le pied en aidant des personnes qui me balance pas de l’ad personam comme introduction à tout commentaire.
Si tu as envie de répondre, fais-le. En évitant l’ad-personam, ce serait mieux.
Sur ce, bonne journée.
Salut Fred,
J’avais appris la nouvelle concernant Synaptic. C’est un vrai coup de massue. Je ne m’imagine pas fonctionner sans, après des années d’utilisation. Peut-être un bon motif de rester sous Stretch plus longtemps que prévu…
Ceci dit, faut-il pour autant le supprimer des dépôts Buster si le problème concerne uniquement Wayland (et donc a priori seulement Gnome) ?
Rester sur stretch sera comme reculer pour mieux sauter. Synaptic n’est plus activement dévéloppé depuis début 2017. Autant dire que ça sent très mauvais pour lui.
Gnome est l’interface par défaut du bureau de Debian donc le retrait d’une version ne supportant pas Wayland était malheureusement prévisible 🙁
« Coup de massue » : expression appropriée.
Je ne connais rien au code et je faire un commentaire naïf peut-être…
Mais Synaptic, c’est une pierre angulaire de Debian. Et là, on retire le truc à quelques mois (ou semaines) du passage à la version stable. Personne n’avait vu arriver ça ? Tout ça sent un peu la grosse improvisation, sur qqch de central pour cette distribution, non ?
Le problème de non lancement avec Wayland est connu depuis 2016. Et j’ai comme l’impression que la pierre angulaire de Debian en graphique à l’air un brin poreuse 🙁
La grosse improvisation, non. L’expression d’une lassitude, oui.
Je suis énervé, oui, et du reste mon billet et comme je suis actuellement vide!
Pourquoi, je vais le dire ici, bien que j’avais un billet en tête pour exprimer au calme mes pensées.
En fait, il n’ a rien qui prend ou qui remplace ce que Synaptic est, c’est le seul Gui (interface utilisateur graphique) qui exploite aussi bien toutes ou du moins une importante quantitée de fonction du gestionnaire de paquets Apt! C’est du reste et a ma connaissance le seul logiciel qui permet de faire tant graphiquement.
Que ce soit logitheque, gnome software, le truc de kde , apper et je sais pas encore quelle autre solution nous avons de nos jours, aucuns et je dis bien aucuns ne fait autant que Synaptic.
Toutes les autres applications sont avant tout des interfaces graphiques universels devant fonctionner aussi bien avec les divers formats de paquets mais pour pas dire de connerie, je resterais sur les RPM et les DEB, doivent faire le minimum syndicale avec ces formats, updates et installations désinstallations de paquets.
Synaptic faisait bien plus que ça…
Bref, tout ça parce qu’il n’est pas compatible encore avec Waylande, mais entre nous est ce que ce dernier est totalement utilisable? Et bien pas chez moi sans ralentis des machines sur lesquelles j’ai testé! Autre question, Waylande est il bien pris en compte par tous les bureaux? A part gnome qui nous l’impose par défaut (et encore heureusement qu’on peut passer outre) nulle ne le fait.
Donc on est en train de valser la seule application graphique qui fait le taf de façon simple de la future stable alors que le bug touche une poignée de personnes…
J’ai espoir qu’il soit dispo dans les backports, ça sauverait un peu le tout.
Pour son inactivité dormante actuellement et depuis au bas mot deux ans, faut aussi savoir que a part le bug de waylande que peut on lui demander de faire de plus? APT n’evolue plus tellement et aprat des améliorations et des corrections de bugs, les nouvelles version de Apt ne sont rien d’autre! Donc que pouvons nous demander a Synaptic de faire qu’il n’a déjà? La gestion des dépôts, il le fait; la gestion des backport, il le fait; le choix de la version qu’on veux du programme, il le fait; les updates, il le fait; … Que peut il faire de plus?
Je vais faire un billet sur ce cas, cas j’étais énervé de voir cette nouvelle que je ne voulais pas croire depuis plusieurs mois, en pensant que ça allait être corrigé, ou du moins qu’on allait laisser passer ça avec un petit mot puisque de toute façon il n’est pas installé avec gnome…
Ça reste une énorme connerie pour moi de faire ça mais bon, on verra bien comment le projet va faire. Mais si c’est ça il faut flinguer de la distribution tout ce qui n’est pas compatible avec waylande et il y en a un paquet!
Si tu es vidé, alors que dire de la crève qui est amoureuse de moi ?!
Ce qui doit donner un code d’une complexité effrayante.
Wayland a souffert d’un retard à cause du cavalier seul de Canonical dans le domaine, Mir. J’ai testé il y a quelques heures Gnome 3.32 en dur sur mon ordinateur fixe. Les seuls programmes qui ne sont pas portés et que j’utilise au quotidien ? Des outils comme OBS Studio ou Simple Screen Recorder.
Sauf erreur de ma part, c’est Gnome par défaut en mode graphique chez Debian depuis une petite éternité…
Qu’on le veuille ou non, à horizon de 5 ans, Wayland aura pris la place de X11. Mon hypothèse est que le port n’a pas été effectué car porter le code aurait été trop complexe et qu’il aurait fallu repartir de la feuille blanche.
Ça diminue de mois en mois. Je me souviens qu’il y a environ un an, gParted ne se lançait pas avec Wayland. Donc…
Je vais être mauvaise langue : le fait que Synaptic ne fonctionne pas dans Wayland m’en touche une sans faire bouger l’autre.
Pourquoi ? tout simplement parce que Wayland est tellement lent à s’imposer sur les différents bureaux de Linux que l’antédiluvien Xorg a encore de très nombreuses années devant lui.
Vous pouvez quoter mon message et rendez vous dans 5 ans lol !
Cela dit, je dois bien reconnaître que j’utilise Synaptic de moins en moins. Son coté vieillot est de plus en plus évident.
On verra dans 5 ans, mais je pense que d’ici là, Plasma l’aura adopté et Mate-Desktop sera aussi dans ce cas. Sauf erreur de ma part, c’est déjà le cas pour l’intimiste enlightenment, non ?
» la gestion des backport, il le fait »
Ben…
Non.
Installer par les backports, on recommande de le faire à la console. J’avais essayé une fois en me servant de Synaptic et ça avait foiré. J’avais ensuite désinstallé, puis j’avais fait ça à la console et ça avait marché sans soucis. Je crois qu’il gère mal les histoires de dépendances avec les backports (je ne suis plus sûr à 100%). Mais sinon, oui, Synaptic est très bien.
Et c’est vrai que ça fait un gros trou si on se retrouve sans cet outil. Les autres interfaces graphiques ne sont pas comparables.
Mais je me dis que qqn va bien devoir se sortir les pouces.
Linux Mint, par exemple, leur gestionnaire de mises à jour se base sur Synaptic. Bcp d’utilisateurs Debian utilisent ça.
J’imagine qu’on va trouver une solution de compromis, du genre le mettre dans les backports pour Buster, afin qu’on puisse quand-même l’utiliser. Et ça laissera le temps de chercher une solution pour la suite.
Non, je t’assure que non, faut juste savoir comment faire et lui dire d’aller chercher les recommandations dans backport….
OK. Moi j’avais juste choisi la version des backports. Et constatant l’échec, je m’étais rabattu sur le terminal, sans fouiller plus loin dans Synaptic.
Solus n’est-elle pas censée être une RR? Malgré les mises à jour, visiblement je suis resté en version 3.9999999…
Comme pour Arch : ils mettent les ISO à jour de temps en temps.
Pour le numéro de version qui ne change pas, j’imagine que tu parles de Grub ? Il faut sans doute le régénérer pour qu’il mette ce numéro à jour. Pour vérifier ta version, fais un « lsb_release -a » dans un terminal, et vois ce que ça dit.
Avec Fedora, on a l’équivalent de Synaptic, yumex-dnf, qui est lui aussi « deprecated ».
Il a même disparu des repos (sources tjs dispo sur github) et pour les spins Fedora (versions livrées par défaut sans Gnome Shell : Xfce, Mate, Cinnamon, KDE…) un autre outils, dragora, a été choisi.
Cet outil est moisi, lent, ergonomie pourrie, mais au moins, ça fait la promotion de Gnome Software 🙂 (et aussi de dnf en ligne de commande !)
C’est vrai que c’est pénible les logiciels qui ne sont pas compatible Wayland. Ce que je ne comprends pas, c’est qu’il y a une sorte de wrapper X11 pour Wayland, Xwayland, qui est sensé permettre l’utilisation des anciens logiciels. Mais pour les logiciels de capture vidéos ça ne fonctionne pas. Tu cites Simple Screen Recorder, mais Vokoscreen c’est pareil.
Bilan: je n’utilise pas Wayland, car j’ai besoin de Vokoscreen régulièrement…