Adrien Dorsaz a écrit 963 commentaires

Désolée, en ce qui me concerne, je suis absolument défavorable à un nettoyage automatique

Et pourquoi donc ? Quel est l'intérêt de garder des dépêches débutées et jamais terminées ?

De mon point de vue, c'est intéressant de trier, car c'est vraiment décourageant pour les rédacteurs de voir "Actuellement 42 dépêches sont en cours de rédaction". En tant que nouveau rédacteur, je me poserai ce genre de questions:

• Par où commencer à contribuer ?
• Est-ce que j'ose démarrer la 43ème dépêche en cours de rédaction ?
• Est-ce que c'est vraiment très difficile de proposer une dépêche ?
• Qu'est-ce qui pourrait faire que la dépêche reste 5 ans en rédaction ?

Or, je trouve que le côté le plus intéressant de LinuxFr, c'est les nouvelles collaboratives. Sinon, LinuxFr serait juste un forum / discourse communautaire comme il y en a tant sur Internet.

je pense que l'urgence est plutôt d'améliorer par exemple l'interface de saisie des commentaires

Intéressant, de ton point de vue il y a une urgence à ce sujet, alors qu'il n'y a aucune entrée de suivi ouverte liée à ça :) Ou alors je ne l'ai pas trouvée.

en permettant qu'on puisse tout voir quand on répond à un contenu ou à un commentaire, ce qui facilite les dérapages en tous genres.

Désolé, mais je ne vois pas trop le lien entre les dérapages et voir tout le contenu pendant qu'on saisi un commentaire ?

Celui qui a décidé de lancer / répondre à un troll le fera même si tous les commentaires sont affichés sur la page…

En tout cas, il faudra expliquer ce point de vue dans l'entrée de suivi :)

Effectivement, je pense que l'on n'avait simplement pas prévu que les dépêches restent 5 ans dans l'espace de rédaction :)

Pour le coup, il serait peut être vraiment intéressant que je termine le code pour le nettoyage automatique de l'espace de rédaction.

Je l'avais débuté pour cette entrée de suivi.

ah oui, bizarre, je me demande comment j'y suis arrivé, désolé pour le bruit :)

Edit:

Ah j'ai compris, j'ai cliqué sur le lien à propos des seuils d'acceptation des dépêches.

Et j'ai continué à lire celui-ci en croyant être sur celui d'avril :)

finaliser le rapport moral et préparer l’assemblée générale de LinuxFr ;

Wow, on est prévenant, on prévoit déjà celle de cet automne ? 😅

La dernière assemblée a été faite début avril et le rapport est publié dans cette dépêche.

Si j'ai bien compris la réponse, c'était "ok, on a réservé le port 22 pour SSH". Ils ne disent pas avoir audité et validé le RFC pour SSH.

C'est ça qui est fou en fait: l'auteur de SSH a pris pas mal de temps à faire son mail pour demander la réservation du port, il a pris la peine de joindre un brouillon de RFC et d'avoir une version stable presque prête et le lendemain (très rapidement) on lui répond juste "ok" 😅

Oui, tout à fait, Mathieu avait proposé d'abandonner ce système lorsque l'on passera à son nouveau design.

D'ailleurs, le travaille sur l'espace de rédaction était une partie de ce projet qui n'est pas encore terminé :)

Hello,

J'ai fermé cette entrée de suivi, parce que, comme indiqué plus bas, c'est un doublon.

L'espace de rédaction avait été fortement modifiée il y a 2 ans pour avoir une barre latérale dynamique et ça a cassé tout les thèmes alternatifs.

Hello,

Je met dans ce fil les demandes de suivis en doublon:

• RonRonnement-Classic et espace de rédaction
• L'espace de rédaction des dépêches est cassé avec le thème kaiska-short

Hello,

Je ferme la demande, parce qu'elle est en doublon à propos de la barre latérale de l'espace de rédaction.

Hello,

Les images de la demande de suivi ne sont plus accessibles.

Je ferme la demande, parce que je pense que c'est un doublon à propos de la barre latérale.

Merci !

Oui, rails a prévu la commande db:setup pour préparer la première fois la base de donnée (ça permet de la monter sans avoir besoin de passer tous les scripts).

Quand tu vois que le Docker mysql est prêt avec un log du genre:

database_1 | 2020-09-21 16:03:12 139820938893312 [Note] mysqld: ready for connections.`

tu peux exécuter la commande suivante:

docker-compose run linuxfr.org bin/rails db:setup

Dans l'idéal, il aurait fallu faire un entrypoint pour le Docker linuxfr.org pour qu'il configure la première fois la base avec db:setup.

Pour bien le faire, il faudrait faire une boucle de sleep qui attend que le Docker mysql soit prêt.

Chouette, c'est cool que ça marche :-)

L'url par défaut, c'est http://dlfp.lo

Il faut penser à configurer son fichier hosts pour le définir, ainsi que img.dlfp.lo

Pour plus d'informations, tu peux regarder le fichier Docker.md.

Alors, j'ai fait un autre Pull Request: https://github.com/linuxfrorg/linuxfr.org/pull/301

En effet, j'ai appris que Rails a décidé de proposer des versions correctives pour ne plus dépendre de mimemagick.

Je préfère ce PR, parce qu'on suit simplement les mises à jour de Rails et parce qu'on n'a pas besoin d'ajouter le paquet shared-mime-info dans les dépendances du projet.

Pour info, il y a quelques liens qui expliquent pourquoi cette version a été retirée: https://github.com/mimemagicrb/mimemagic/issues/148

mimemagic est sous license MIT et il incluait un fichier de shared-mime-info qui est sous GPL-2. La mise à jour 0.3.10, n'inclue plus ce fichier et nécessite donc l'installation du projet shared-mime-info pour rester sous license MIT.

Ok, j'ai réussi à build avec les changements de ce Pull Request: https://github.com/linuxfrorg/linuxfr.org/pull/300/files

Comme j'ai indiqué dans le Pull Request, je ne suis pas sûr de pouvoir mettre à jour la version bundle dans le Gemfile.lock.

Si ce n'est pas possible, j'aurai encore besoin de modifier le Gemfile.lock, mais en attendant, tu peux utiliser ce patch pour réussir à build l’environnement.

Hello,

Oh, je n'avais pas pensé que l'on pouvait enlever des versions sur rubygems.org…

D'un côté je comprends, les développeurs ne peuvent pas faire le support de toutes les versions, mais d'un autre côté, ce n'est pas très pratique pour pouvoir construire des environnements stables.

Même Debian Bullseye (la testing) a la version 0.3.5 de mimemagic 😅

Heureusement, je vois sur rubygems que l'on pourrait essayer de passer à la version 0.3.10, en croisant les doigts pour que semver soit bien respecté.

Si jamais, j'ai choisi de faire les images Docker avec Debian Stretch, parce que ça correspond aux serveurs de productions de LinuxFr et parce que je n'avais simplement pas réussi à monter l'environnement avec Buster.

Je n'ai pas assez d'expérience avec les environnements Ruby et Rails pour m'aventurer avec d'autres versions de Debian, mais c'est volontiers si quelqu'un y arrive :)

Ce n'est qu'une question d'habitudes… Attention, elles changent souvent 😂

L'article explique justement qu'Adwaita est maintenant clairement le langage visuel et comportemental de GNOME et, surtout, validé par l'équipe design de GNOME.

De fait, c'est un thème GTK, un set d'icônes et de widgets GTK prêt à l'emploi pour créer une application estampillée GNOME (ou qui cible uniquement la plateforme GNOME).

Le thème Adwaita que tu as connu avant va s'appeler dorénavant "Défaut" dans GTK et sera une copie de l'ancien Adwaita. Il ne suivra plus les préceptes de GNOME et deviendra naturellement compatible multi-plateforme, car GTK ne cible plus aucune plateforme en particulier (Windows, MacOS, Elementary, XFCE…).

La bonne nouvelle de ce changement d'habitude, c'est que GTK pourra enfin mieux fonctionner sur Windows, MacOS, Elementary, XFCE… et ce sans avoir besoin de triturer le thème par défaut ni les widgets par défaut.

Il faut voir Adwaita, comme la marque de GNOME. Avant, GTK 3 était très lié à GNOME et c'est pour ça que Adwaita était directement dans GTK.

Aujourd'hui, GTK n'a plus besoin d'évoluer aussi vite que GNOME, il faut voir ça comme un bon signe: GTK est devenue plus mûre et assagit sa vitesse de développement pour être à nouveau plus stable, générique et multiplateforme :-)

Toutefois, je pense que l'on ne va pas se retrouver bloqué avec de vieux widgets comme à l'époque de GTK+ 2 et GNOME 2: en effet, libadwaita permettra d'expérimenter de nouveaux widgets et, à terme, s'ils sont intéressants pour toutes les plateformes cibles de GTK, de les intégrer dans GTK directement.

J'ai le sentiment que GNOME et GTK ont enfin pu se séparer correctement grâce à GTK 4 et son nouveau paradigme où "tout est un widget" (enfin, si j'ai bien suivi GTK 4, je ne suis pas sûr).

Pas de problèmes, merci pour l'explication :)

C'est ça, on est déjà passé en Regular.

Le titre du sondage est donc lui même faux.

Ça fait 2 ans que j'ai proposé ce sondage, on dirait qu'IPOT a fonctionné à l'envers 😅

En fait, j'avais finalement demandé de ne pas publier ce sondage, mais je ne sais plus pourquoi exactement.

Peut être simplement que, finalement, on est passé de Lato Light à Lato Regular ?

Bref, je ne comprends pas bien pourquoi ce sondage est ressorti 2 ans après et s'il est vraiment pertinent aujourd'hui ?

Pour l'espace de rédaction, il faut utiliser le style par défaut de LinuxFr: https://linuxfr.org/suivi/la-barre-laterale-ne-peut-etre-masquee-et-masque-le-contenu-d-une-depeche-en-redaction

Hello,

MMhhh, ça sera intéressant à debugger: le problème semble être le mélange de la syntaxe Markdown pour les liens [super lien](http://localhost) et les liens wikipédias custom de LinuxFr [[article wikipédia.]]. En effet l'exemple [[article wikipédia]] (avec des explications) contient les 2 syntaxes imbriquées.

Pour info, la source Markdown des exemples donnés dans le poste orignal:

- **texte original :** métadonnées GeoTIFF (informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF) ;
- **wikilien ajouté :** métadonnées [[GeoTIFF]] (informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF) ;
- **contournement :** métadonnées [[GeoTIFF]] _(informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF)_ ;

Je ne suis pas sûr que ça sera facile à corriger, car il faudrait modifier l'interpréteur Markdown.

Par contre, un autre exemple de contournement, ça serait de faire tout en Markdown:

- **contournement markdown uniquement :** métadonnées [GeoTIFF](https://fr.wikipedia.org/wiki/GeoTIFF) (informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF) ;

• contournement markdown uniquement : métadonnées GeoTIFF (informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF) ;

On perd la fonction "wikipedia", mais on évite de devoir mettre le texte en italique après.

Ah oui, c'est bien vu d'utiliser le seuil d'acceptation de la modération, j'ai ajusté le commit.

Hello,

En effet, c'est bien vu et le correctif est assez simple: https://github.com/linuxfrorg/linuxfr.org/pull/298 :)