Planet Libre

Renault : [F28] Participez à la journée de test consacrée à Anaconda

Aujourd'hui, ce lundi 16 avril, est une journée dédiée à un test précis : sur Anaconda. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

Anaconda est depuis les débuts de Fedora le programme qui permet de l'installer sur votre machine. Anaconda a subi avec les années de nombreux changements que ce soit dans son architecture interne tout comme son interface utilisateur.

Et pour Fedora 28, Anaconda va bénéficier du début d'une profonde refonte technique en le rendant plus modulaire. L'objectif est que des composants d'Anaconda communiquent entre eux via DBus et que selon les versions de Fedora (ou de toute personnalisation de celui-ci) des modules soient activés, désactivés voire ajoutés afin de ne proposer que ce qui est nécessaire. L'ajout des modules se fera en plusieurs cycles de Fedora.

De plus, Fedora 28 propose une refonte des responsabilités entre Anaconda et gnome-initial-setup pour éviter qu'une question ne soit posée deux fois à l'utilisateur inutilement.

C'est donc un composant critique et il est nécessaire de s'assurer qu'il fonctionne pour le jour de la sortie officielle.

L'objet de cette journée de tests est bien entendu de valider l'ensemble de ces changements, en étant sûr que le résultat est fiable et fonctionnel.

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-day et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

Articles similaires

genma : Chatonkademy - Billet N°1 - Les utilisateurs

Série de billets sur le projet Chatonkademy

Introduction
Le projet continue et d'autres billets sont en cours de rédaction. Je publie celui-ci pour partager quelques astuces de bases dont j'ai eu besoin. Dans celui-ci, quelques astuces sur les utilisateurs et Yunohost (rappel : dans le projet il y a une instance Yunohost multi utilisateur).

Créer des utilisateurs en masse dans Yunohost

On fait appel à la moulinette. On crée un script du type
Dans le présent script, les mot de passe sont en dur

#!/bin/bash

yunohost user create chaton01 -p motDePasseChaton01 -f chaton01 -l chaton01 -m chaton01@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton02 -p motDePasseChaton02 -f chaton02 -l chaton02 -m chaton02@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton03 -p motDePasseChaton03 -f chaton03 -l chaton03 -m chaton03@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton0X -p motDePasseChaton04 -f chaton0X -l chaton0X -m chaton0X@chatonkademy.com --admin-password motDePassAdminYunohost

Largement améliorable en utilisant des variables pour les mots de passe utilisateur et le mot de passe administrateur, ce qui évite de les mettre en dur au sein du script.

Applications

Dans mon cas, tous les utilisateurs ont accès à toutes les applications. J'ai installé les applications après la création des utilisateurs.
Je ferai un billet (ou plusieurs) sur le cas des applications.

Surveiller leurs connexions

Le besoin est le suivant : les utilisateurs ont été crées, le mot de passe communiqués. Comment suivre si l'instance Yunohost est bien utilisée et si oui par quels utilisateurs. Il y a plusieurs façons de faire et de voir il y a des connexions des utilisateurs.

Tous les logs de connexion se trouvent dans le fichier /var/log/nginx/chatonkademy.com-access.log

Les logs étant compressés, on peut passer par zcat et créer un fichier de cumul des logs dans /tmp/access.log pour avoir un suivi depuis le début de la création de l'instance.

cat /var/log/nginx/chatonkademy.com-access.log >> /tmp/access.log
zcat /var/log/nginx/chatonkademy.com-access.log.*.gz >> /tmp/access.log

Un peu de shell en une ligne permet de faire pas mal de choses, selon les besoins. Quelques exemples :

Ip et utilisateur

root@cloud:# cat /tmp/access.log |cut -f1 -d '[' |sort -u
1.2.3.1 - chaton01
1.2.4.5 - chaton02
1.2.1.2 - chaton03
1.2.1.2 - chaton01
1.2.1.4 - chaton04

Nombre de connexion par utilisateur

cat /tmp/access.log |grep -v "\\- \\-" |cut -f1 -d '['|cut -d "-" -f2 |sort |uniq -c |sort -nr 5733 chaton03
1525 chaton02
1334 chaton01
913 chaton04

Quel(s) utilisateur(s) se connecte quel jour ?

cat /tmp/access.log |cut -f1 -d ']' |grep -v "\\- \\-" |cut -f1 -d ':'|cut -f2 -d '-'|uniq |sed 's/\\[//g' chaton04 11/Apr/2018
chaton01 11/Apr/2018
chaton04 11/Apr/2018
chaton01 11/Apr/2018
chaton03 12/Apr/2018
chaton02 12/Apr/2018
chaton01 12/Apr/2018
chaton02 12/Apr/2018
chaton03 12/Apr/2018

Analyse des logs en graphique

On pourra envisager l'installation de la suite ELK (ElasticSearch Logstash Kibana, pourquoi pas) avec des dashbords qui vont bien pour avoir le reporting des connexions. Pour faire faire plus simple et déjà avoir quelques graphiques, j'ai eu recours un GoAccess. Voir à ce sujet Yunohost - Goaccess - Rapport HTML depuis des logs d'un serveur web.

J'ai repris l'idée de faire l'installation de customWebApp dans Yunohost appelée "Logs" dans laquelle je dépose un fichier index.html qui est le rapport généré par GoAccess

Création d'un script qui contient

#/bin/bash
goaccess --log-format=COMBINED -f /tmp/access.log -a -o /var/www/my_webapp/www/index.html

On le lance via

./root/script_goaccess.sh

On consulte les logs via https://chatonkademy.com/logs/ tout simplement.

Gravatar de genma
Original post of genma.Votez pour ce billet sur Planet Libre.

Journal du hacker : Liens intéressants Journal du hacker semaine #15

Pour la 15ème semaine de l'année 2018, voici 12 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

Pour ne plus rater aucun article de la communauté francophone, voici :

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Gravatar de Journal du hacker
Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Articles similaires

Thuban : Syspatch : Patch Perl pour OpenBSD 6.x

L'équipe OpenBSD nous livre un correctif pour Perl !

Des débordements de la pile mémoire sont possibles qui peuvent conduire à des erreurs de segmentation, des plantages et des lectures au-delà de la mémoire tampon.

Architectures concernées : amd64, arm64 et i386

OS Versions :

Il ne semble pas nécessaire de redémarrer !

 

Gravatar de Thuban
Original post of Thuban.Votez pour ce billet sur Planet Libre.

Yannic Arnoux : Les mots de passe

J’ai été sensible assez tôt à l’importance de la sécurité des mots de passe. Aujourd’hui, plus qu’hier, on ouvre quantité de comptes sur des sites de commerce, de banque ou d’assurance, de santé. J’avais choisi le logiciel KeePassX, un coffre fort numérique protégé par un mot de passe unique, et suivi les bonnes pratiques : associer un mot de passe costaud et différent pour chaque site. Tout avait bien démarré avec de la bonne volonté, mais l’informatique des nuages et la mobilité ont progressivement compliqué les choses.

Au début, c’était simple car on avait une machine familiale dans la maison. Puis au fil des ans, j’ai acquis un portable, puis une tablette et un smartphone, et le casse-tête de la synchronisation entre les périphériques s’est posé. J’ai commencé simple (la machine familiale est la machine maître pour le fichier et des copies sont installées sur les autres périphériques) puis ça a fini par une synchronisation de la base KeePassX à travers Nextcloud, ce qui permet à n’importe quel périphérique de rajouter un mot de passe si besoin.

Enfin il s’est rajouté le problème de l’accès à ses mots de passe depuis des machines tierces (en milieu professionnel notamment). On peut ouvrir les mots de passe sur le téléphone et recopier le mot de passe dans le navigateur de la machine mais c’est pénible. Quand on est développeur, on a forcément une identité numérique (un compte GitHub, un compte StackOverflow, etc…) et on n’est pas forcément schizophrène donc on ne va pas en ouvrir un différent à chaque changement de poste. Du coup, j’ai ajouté la synchronisation de Mozilla Firefox dans la boucle, protégé par un master password pour partager certains identifiants liés à mon activité professionnelle en me rassurant que la référence c’est ma base KeePassX.

Le bilan, au bout de 12 ans, c’est que c’est un sacré bazar :

  • j’utilise une version antédiluvienne de KeePassX pour être compatible avec celle supportée par mon téléphone : la sécurité globale est nivelée par celle du maillon le plus faible
  • j’ai des mots de passe dans KeePassX, des doublons dans Firefox et probablement des mots de passe oubliés uniquement mémorisés dans Firefox.
  • la sécurité du stockage des mots de passe dans Firefox n’est pas terrible mais c’est tellement commode le remplissage automatique des formulaires quand on est sur un site.
  • la base KeePassX est physiquement sur mon téléphone : même si c’est chiffré sérieusement, combien de temps faudrait-il à quelqu’un de motivé et équipé pour la craquer en cas de vol ?

Cela fait beaucoup de points négatifs, il était temps de repenser tout cela et de se mettre au goût du jour. J’ai regardé un peu ce qui se fait avec quelques idées en tête :

  • copier-coller des mots de passe entre une application et un site Web c’est dépassé (et compliqué sur un appareil mobile),
  • stocker une base de mots de passe sur un périphérique mobile c’est risqué,
  • le risque de piratage des sites Web est plus grand qu’auparavant, la solution doit être simple pour créer un mot de passe différent par site.

J’ai finalement choisi BitWarden qui remplit mes critères. Le coffre-fort est hébergé sur leurs serveurs, dans le cloud Azure Microsoft pour être exact. On peut décider de l’héberger soi-même mais je doute faire mieux que des professionnels pour en sécuriser l’accès. On déverrouille l’accès au coffre-fort avec un mot de passe maître, le seul à retenir finalement ; idéalement c’est une phrase plutôt qu’un simple mot de passe car toute la sécurité repose sur lui. Et si on l’oublie, ce n’est pas la peine de le demander aux administrateurs de BitWarden car ils ne l’ont pas, il n’est pas stocké chez eux. L’avantage de BitWarden par rapport à d’autres solutions du même genre c’est aussi qu’il propose des applications pour toutes les plateformes : des extensions de navigateurs, des applications bureau et mobiles. Autre bon point, ils ont des fonctions d’import pour la plupart des solutions concurrentes.

Alors comment décider de faire confiance à BitWarden ? Ce qui compte pour moi c’est :

  • la publication en Open Source du cryptage pour être audité en toute transparence,
  • la possibilité de sortir ses données avec un export en CSV,
  • le sérieux de l’hébergement de la solution.

La confiance, c’est compliqué. Quelles que soient les garanties, il y a un moment où, en son âme et conscience, il faut se lancer ou rebrousser chemin. J’ai franchi le pas et décidé de leur confier mes mots de passe.

Premier écueil pour sortir les mots de passe de Firefox : l’extension Password Exporter ne supporte pas Firefox 57, j’installe la version Firefox 52 ESR. D’ailleurs on annonce la version Firefox 62 ESR pour le mois d’août, ça me conforte dans l’idée que c’est le moment de s’en occuper. L’extension exporte les mots de passe dans un fichier CSV et BitWarden permet de les importer. Pour KeePass, on a un import mais comme j’ai une version KeePassx 0.4 j’ai du passer par la migration vers une version récente de KeePass avant de pouvoir importer ma base de mots de passe dans BitWarden. A ce stade, j’ai un coffre-fort avec plein de doublons entre les données de FireFox et KeePass ; bien fait pour moi, le gros ménage commence.

Je désactive la mémorisation des identifiants de Firefox et je vide les identifiants enregistrés puis j’installe l’extension BitWarden pour Firefox. On ouvre le coffre-fort en entrant son méga mot de passe.

Ouverture coffre-fort

On peut paramétrer la fermeture du coffre-fort. A la maison, on laissera le coffre-fort ouvert jusqu’à la fermeture du navigateur ; au travail on optera pour une fermeture automatique sur inactivité, au bout de 15 minutes. Le principal intérêt d’avoir un gestionnaire de mots de passe couplé au navigateur c’est le remplissage des formulaires pour ne plus faire de copier-coller de mots de passe. L’icône de BitWarden change quand un mot de passe est disponible pour un site et il suffit de le sélectionner pour remplir le formulaire.

Remplissage de formulaire

J’ai terminé ma bascule vers BitWarden depuis une semaine ; je me sers de l’extension Firefox et de l’accès Web, je n’ai installé aucune application native sur mes périphériques. Par sécurité, j’ai prévu une sauvegarde régulière et manuelle vers un support physique, c’est à dire un export des mots de passe vers une clef USB qui reste dans un coffre (non numérique celui-ci)… au cas où BitWarden disparaitrait ou bien si je deviens amnésique ;-)

Gravatar de Yannic Arnoux
Original post of Yannic Arnoux.Votez pour ce billet sur Planet Libre.

Miamondo : Auprès de mon arbre, je vivais heureux…

Bonjour, Ce qui rend les distributions Linux si vivantes, c'est que leur structure interne est comparable à celle d'un arbre. Tout un réseau de racines numériques donne naissance à une souche qui se divise en plusieurs troncs. Ces derniers se ramifient en des branches de plus en plus fines qui se terminent par des feuilles... Lire la suite →

Gravatar de Miamondo
Original post of Miamondo.Votez pour ce billet sur Planet Libre.

Articles similaires

Jehan : ZeMarmot, principal contributeur de GIMP 2.10.0-RC1

Nous avons sorti GIMP 2.10.0-RC1 il y a déjà presque 3 semaines (et sommes même sur le point de sortir une RC2)! Mais c’est seulement maintenant que nous faisons notre petit compte-rendu habituel de contributeurs, en français (celui en anglais a été fait la semaine dernière, ce qui était déjà tard). Notre excuse étant bien entendu le fait que le développement de GIMP et la production de ZeMarmot nous prend le plus gros de notre temps; j’espère que vous considérerez cette excuse aussi valide que nous. 😉

Quoiqu’il en soit, ceci fut notre première Release Candidate de GIMP 2.10.0, c’est donc un énorme évènement (une Release Candidate, c’est une version presque finale, un peu entre une version de développement et une version stable)! Eh oui, 6 ans déjà que vous l’attendez, et l’attente touche à sa fin…

Quelle fut la partication de ZeMarmot?

C’est d’autant plus une sortie excitante pour nous que pour la première fois, je fus le contributeur majeur, avec 270 commits sur les 784 faits entre 2.9.8 et 2.10.0-RC1. C’est donc plus du tiers des modifications et corrections de bugs sur les 4 derniers mois! D’autres participants du projet ZeMarmot ont eux-même quelques commits, notamment Aryeom, notre réalisatrice, qui a contribué 2 icônes manquantes (pour se changer les idées entre ses séances d’animation de marmottes, image par image), ainsi que Lionel (un des membres du CA de l’association LILA qui gère le projet) qui a travaillé sur l’amélioration de la prise en charge de l’unité de mesure “pouce”.

On le voit, à chaque sortie, ZeMarmot est un acteur de plus en plus majeur du développement de GIMP. Il n’y a pas à dire, nous en sommes fier. Normalement après chaque sortie, je liste en détail mes contributions, mais il y en a tellement que j’ai décidé de désormais limiter aux quelques contributions plus marquantes:

  • Amélioration du debuggage avec une boîte de dialogue récupérant des données et traces d’exécution. J’en ai déjà parlé (en anglais seulement).
  • Sauvegarde automatiques d’images juste avant un crash! Oui vous ne rêvez pas! Alors je sais… GIMP est très stable. On a donc eu quelques remarques à ce sujet nous disant que de toutes façons, GIMP ne plante jamais (et on est fier de lire ce type de remarques car on a beaucoup travaillé pour en arriver à cette stabilité qui n’était absolument pas un acquis quand j’ai commencé à contribuer, il y a quelques années; c’est même l’une des raisons pour laquelle j’ai fait mes premiers patchs). Mais cela reste du logiciel, et dans le logiciel, tout est possible! Je développe celui-ci, et suis pourtant le premier à vous l’affirmer: non, GIMP n’est pas parfait! Il est très stable, mais les plantages peuvent arriver. Pire! C’est sûr, un jour, il vous plantera à la figure, si vous l’utilisez beaucoup! Et ce sera le jour où vous vous y attendrez le moins (loi de Murphy). La différence, c’est que maintenant GIMP sera prêt!
    Bon soyons précis, ce n’est pas non plus du “sauvetage” à 100%. Par nature, un crash est un état d’instabilité extrême d’un processus. On peut essayer de préserver des données, mais même cela peut échouer. Par contre souvent cela réussira. Et c’est seulement ce jour qui importera: celui où vos heures de travail auront été sauvées par ce petit bout de code. 😀
  • La pipette à couleur prend maintenant en compte la gestion des couleurs de votre moniteur sur macOS.
  • J’ai implémenté la capture d’écran avec l’API générique Freedesktop.  Sur les plateformes GNU/Linux, à terme, c’est censé remplacer les APIs spécifiques des environnements de bureaux. Néanmoins les implémentations GNOME/KDE gardent tout de même la priorité à ce jour jusqu’à ce que les implémentations Freedesktop soient plus complètes (et ainsi éviter des pertes de fonctionnalités).
  • J’ai ajouté de nouvelles configuration des préférences pour l’export de métadonnées, et fait en sorte que tous nos plug-ins d’export respectent ces préférences (notamment en rajoutant de nouvelles APIs pour les développeurs de plug-ins: gimp_export_exif(),  gimp_export_xmp() et gimp_export_iptc()). C’est un sujet sensible car les métadonnées de fichiers peuvent contenir des données sensibles (votre nom souvent déjà, souvent le nom de votre entreprise voire votre adresse email, parfois même des coordonnées GPS que les appareils modernes ajoutent automatiquement, etc.) et clairement certaines personnes peuvent préférer ne pas avoir à gérer et filtrer manuellement ces données et simplement demander à ne pas les exporter par défaut.
  • Diverses nouvelles APIs pour les développeurs de plug-in:
    • gimp_get_pdb_status() retourne le statut du dernier appel PDB. Cela permet à un plug-in qui dépend d’autres plug-ins d’en savoir plus sur les raisons de retour. Par exemple si une procédure est stoppée intéractivement, cela ne doit pas être considéré comme une erreur, mais plutôt comme une interruption manuelle.
    • gimp_stack_trace_available(), gimp_stack_trace_print() et gimp_stack_trace_query() pour aider au débuggage de plug-ins.
    • gimp_context_get_distance_metric() et gimp_context_set_distance_metric() pour le choix de métrique de distance utilisé par gimp_edit_blend() (et à usage futur).
  • Amélioration de l’API gimp_edit_blend() qui se base maintenant sur l’opération “gegl:distance-transform“, ce qui rend la procédure bien plus rapide.
  • Amélioration du traitement d’image splash avec du redimensionnement pour apparaître avec une taille raisonnable sur toute dimension d’écran.
  • Des vulnérabilités furent reportés fin 2017, donc j’ai corrigé CVE-2017-17784, CVE-2017-17786, CVE-2017-17787 et CVE-2017-17789.

Au milieu de tout cela, j’ai aussi déjà annoncé le nouveau paquet mypaint-brushes.
Enfin il y a toutes ces autres mini-fonctionnalités mais surtout les nombreux bugs corrigés. En fait je ne crois pas que j’aurais pu corriger aussi facilement autant de bugs sans notre nouveau système de débug. Donc j’en suis particulièrement content. Je sais que certains ne considèrent pas cela si important (ce n’est pas une vraie fonctionnalité, pour du dessin ou de l’édition d’image ou autre). Je le sais, puisque j’ai lu sur un forum une remarque se plaignant que la news sur gimp.org mette surtout en avance des fonctionnalités de debug, comme si cela ne les valait pas. Pourtant c’est une des contributions dont je suis le plus fier. Je l’ai expérimentée ces derniers mois, et très clairement, cela nous a aidé énormément à débugguer plein de problème sans même avoir eu à demander aux gens de faire des actions ésotériques (telles que “pourriez-vous lancer GIMP dans un débuggueur?” – “Un quoi?”).
En outre je ne le rappellerai jamais assez, mais pour moi la stabilité et fiabilité d’un logiciel est l’une des bases qualitatives. Cette fonctionnalité va clairement dans ce sens.

Quoiqu’il en soit, je l’avais déjà dit: la correction de bug et stabilité sont mes buts personnels pour la 2.10. Comme vous le voyez, ce n’étaient pas des paroles en l’air. 🙂

Tutorer un étudiant pour coder dans GIMP

Parmi les autres nouvelles sympas, un étudiant, Darshan Kadu, nous a approché comme stagiaire FSF. Je lui ai proposé de continuer le portage de notre prise en charge du format JPEG2000  (passant d’une implémentation basée sur Jasper vers OpenJPEG, puisque la première bibliothèque est déprécié). J’agis donc comme tuteur. Ce n’est pas ma première fois à travailler avec des étudiants universitaires. J’ai déjà donné quelques cours dans une université parisienne l’an dernier, et franchement j’aime beaucoup ces échanges (que ce soit avec un seul stagiaire ou une classe entière).

Cela a relancé les discussions sur GSoC et si on souhaitait à nouveau tenter d’y participer (pour mémoire, le projet GIMP y a participé plusieurs années mais a ensuite arrêté; en fait il me semble que le dernier GSoC du projet fut l’année où j’ai commencé à faire mes premiers patchs sur GIMP, je n’ai donc jamais eu l’opportunité d’y participer en tant que tuteur). Quelques personnes proposaient d’avoir des stagiaires pour travailler sur toute sorte de fonctionnalités majeures dans le cœur de GIMP. Je voudrais commenter ce souhait.
Personnellement cela m’intéresse de participer car j’aime accompagner des étudiants dans le monde du développement professionnel. Si au passage, on peut avoir quelques patchs cools, c’est génial. Mais je pense qu’un tel évènement ne doit pas être utilisé juste pour avoir du “bon code pas cher”. Déjà car j’ai toujours détesté l’exploitation de stagiaires mal payés (bon en l’occurrence, avec GSoC, ils ont clairement une paie raisonnable). Ensuite simplement pour une raison qualitative: je pense que tout projet qui se repose principalement sur ce type de contribution ne peut obtenir que du code peu maintenable et de piètre qualité.

C’est simple: quelque soit votre métier, imaginez vous quand vous étiez étudiant. Maintenant demandez vous ce qu’il se passerait si on lâchait le “vous étudiant” à votre poste actuel (auquel vous êtes arrivé après des années à apprendre le métier, à faire des projets, avec des succès et des erreurs…). Pensez-vous vraiment que vous auriez révolutionné votre métier? J’espère que vous répondrez non, sinon c’est un peu triste que vous considériez ne pas avoir évolué posivitement depuis votre vie étudiante! ;p

Donc oui, GSoC comme tout stage, est une opportunité sympa pour travailler avec des jeunes esprits vifs et avec des idées neuves. Mais cela ne doit pas être pris comme une sorte de solution magique pour obtenir du code pas cher, rapide et bon. J’ai l’impression que beaucoup de gens voient cela ainsi malheureusement.
Bon on verra l’an prochain si on décide finalement d’y revenir (cette année encore, on ne s’est pas inscrit), mais je souhaitais donner un peu mon avis à ce sujet puisqu’il est dans l’air.

Release Candidate? Sortie de 2.10 bientôt?

Clairement nous travaillons dur ces derniers temps. Nous sommes même passé sous les 10 bugs bloquants il y a quelques jours (mais cela oscille beaucoup, et à l’heure d’écriture, on est de retour à 10 bugs)!

Nous avons tout de même dû discuter un peu s’il fallait vraiment nommer cette sortie une RC. En effet de manière stricte, ce ne devrait pas être un “candidat pour une sortie (stable)”. Cependant nous sommes un peu fatigué de trainer des pieds (depuis 6 ans!). GIMP 2.10 ne sera pas parfaite. Aucune sortie de logiciel ne sera jamais parfaite. C’est un fait! Mais GIMP 2.10 sera déjà vraiment méga cool, même s’il devait sortir dans l’état actuel. C’est pourquoi on s’est dit qu’on devait un peu pousser dans le bon sens. Faire une “Release Candidate” est donc une sortie psychologiquement forte pour se dire “maintenant faut qu’on pousse vers la sortie”. Et c’est donc exactement ce que l’on fait. 🙂
Attendez vous donc à voir la 2.10 très bientôt, sauf si vraiment on découvre un problème très grave que nous n’aurions pas repéré jusque là (on touche du bois!).

Amusez vous bien avec GIMP 2.10 RC1, tout le monde! Et surtout, testez, testez, testez! Et envoyez des rapports de bugs si vous trouvez quelque chose qui ne va pas! 😀

 

Rappel: vous pouvez financer mon travail sur du Logiciel Libre sur Liberapay, Patreon ou Tipeee à travers le projet ZeMarmot.

Gravatar de Jehan
Original post of Jehan.Votez pour ce billet sur Planet Libre.

Articles similaires

nIQnutn : Des nouvelles de l'association Debian-Facile

Des infos fraîches concernant l'association Debian-Facile.
Depuis quelque temps, le mouvement a repris pour l'asso. On essaie de rattraper le retard que nous avons pris depuis bien trop longtemps.
Comme tous les projets libres, il nous manque toujours des bras et de l'énergie. C'est l'occasion de participer et de vous engager, chaque coup de main est précieux

Les détails de l'annonce: Debian-Facile : Nous avons besoin de vous !
N'hésitez pas à montrer votre soutien.

nIQnutn CC-BY

Gravatar de nIQnutn
Original post of nIQnutn.Votez pour ce billet sur Planet Libre.

System Linux : Calculatrice graphique Open source et Française

calculette.jpg

Cocorico !

Allez on est pas à 80 balles prêt on fait l'effort ! :

https://www.numworks.com/fr/

Gravatar de System Linux
Original post of System Linux.Votez pour ce billet sur Planet Libre.

Articles similaires

Renault : [F28] Participez à la journée de test consacrée au noyau Linux 4.16

Aujourd'hui, ce vendredi 13 avril, est une journée dédiée à un test précis : sur le noyau Linux 4.16. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

Le noyau Linux est le cœur du système Fedora (et des autres distributions GNU/Linux). C'est le composant qui fait le lien entre les logiciels et le matériel. C'est lui qui permet aux processus de travailler ensemble sur un même ordinateur et de pouvoir utiliser les périphériques (à travers des pilotes) disponibles sur chaque machine.

C'est donc un composant critique et il est nécessaire de s'assurer qu'il fonctionne.

Les tests du jour couvrent :

  • L'exécution des tests automatisés par défaut et ceux de performances ;
  • Vérifier que la machine démarre correctement ;
  • Vérifier que le matériel est bien exploité (affichage, claviers, souris, imprimantes, scanners, USB, carte graphique, carte son, webcam, réseau filaire et wifi, etc.)
Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-day et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

Articles similaires

Renault : Du test de Fedora à une contribution pour Yocto / OpenEmbedded

Comme vous le savez certainement, je suis un amateur de Fedora depuis longtemps (merci papa), je prépare des dépêches de sortie depuis Fedora 9, et je teste les versions instables sur ma machine principale depuis Fedora 15. Cela est un moyen efficace de trouver des bogues pour les corriger avant la sortie finale (et ainsi améliorer la qualité pour tout le monde). La rédaction des dépêches permettant de voir l'ensemble des changements opérés à chaque fois en avance.

À l'occasion de la sortie de Fedora 28 Bêta, j'ai voulu préparer le terrain pour ma machine professionnelle pour m'assurer que mon travail serait possible dans cet environnement sans perdre de temps. Si globalement le système tourne bien, restait à s'assurer que mon travail compilerait toujours. Avec des changements de versions pour GLibc et GCC, rien n'est garanti.

Contexte

Pour le compte de mon employeur, le client actuel il y a deux Yocto utilisés (un par projet). L'un est un Yocto Pyro fourni par Toradex pour une plateforme iMX7D, l'autre un Yocto Rocko fourni par Variscite pour une plateforme iMX6. Comme ce sont des versions récentes, la probabilité que le comportement diverge est faible (et en réalité, ce sera le cas, seule un correctif supplémentaire sera nécessaire pour le Yocto Pyro).

Yocto est un système de génération de distribution. Grâce à un système de recettes et de couches, nous pouvons intégrer des logiciels provenant de différentes sources, les configurer et les assembler pour générer différentes images et des paquets. Pour cela, comme pour tout système similaire (comme buildroot), Yocto récupère les sources des compilateurs, des bibliothèques de base, etc. Il compile une chaîne de compilation croisée ce qui permet d'exécuter par exemple un compilateur comme GCC sur mon ordinateur de travail (d'architecture x86_64 Intel) mais dont le résultat sera exploitable sur la carte cible donc des processeurs ARM dans mon cas. Ensuite cette chaîne de compilation servira à générer l'ensemble des paquets et l'image finale pour la carte électronique du projet.

Pour la génération de la chaîne de compilation croisée, Yocto a besoin d'utiliser des outils déjà présents dans ma machine. Typiquement le compilateur GCC de mon architecture. C'est pour cette étape que changer de version de Fedora peut être risqué. Car si GCC change, le comportement pour générer la chaîne de compilation croisée aussi. Exemple : quand GCC active par défaut l'usage de CPP 14 certains programmes ne sont plus compilables en l'état car ils ne respectent pas cette nouvelle version du langage et il faut dans ce cas préciser à GCC de ne pas utiliser le comportement par défaut, ou rendre le programme compilé compatible CPP 14.

Et le soucis avec Fedora 28 ?

Pour minimiser les différences entre les distributions (Ubuntu, Fedora, Debian, etc.), Yocto a introduit par défaut un paquet yocto-uninative qui est un glibc-native précompilé pour la machine hôte (ici mon Fedora x86_64). Cela autorise par exemple à deux distributions de partager le cache de Yocto et que la compilation aboutisse malgré des glibc qui diffèrent. Cela n'est possible que parce que Glibc est globalement rétrocompatible dans les symboles.

Mais avec Fedora 28, le paquet yocto-uninative de Yocto ne fonctionne plus. Il faut compiler glibc-native à la main. Si cela ne constitue pas un frein pour travailler mais c'est une régression importante qu'il convient de corriger avant la sortie officielle de Fedora 28. D'autant que Yocto prépare la sortie de sa nouvelle version sumo et être compatible avec Fedora 28 est un gros plus.

Le problème survient lors de la compilation de bibliothèques Perl, qui se plaignent que le symbole XCRYPT_2.0 de la bibliothèque libcrypt n'existe pas. Et en effet, dans le glibc fournit par yocto-uninative, ce symbole n'existe pas alors qu'il existe dans la version de mon système. En somme, il y a une incompatibilité entre les deux en terme de symboles alors qu'il est nécessaire que cela corresponde pour continuer.

Je regarde dans les changements de Fedora 28 pour comprendre et je retombe sur cette page. Des développeurs de Fedora ont proposé de séparer glibc et libcrypt. Le but est de permettre de faire évoluer ce dernier plus facilement et rapidement. libcrypt serait fournie par le biais du programme libxcrypt. Mais l'équipe de glibc n'a pas encore intégré ce changement, Fedora est ainsi la seule distribution à avoir ce comportement par défaut.

Et c'est là d'où vienne les ennuis, si libxcrypt est rétro-compatible avec l'ancien libcrypt (il fournit les symboles que libcrypt fournissaient), l'inverse n'est pas vrai et on le voit par l'ajout du symbole XCRYPT_2.0.

Travail en amont

Pour corriger cela, il faut agir au niveau de Yocto. Je rejoins donc le canal IRC de #yocto sur Freenode pour expliquer le problème et qu'on élabore une marche à suivre. C'est ainsi que Joshua Watt de Garmin et Richard Purdie d'Intel, deux contributeurs de Yocto ont souhaité m'aider à résoudre ce problème.

Étape 1, générer un yocto-uninative depuis Fedora 28 et l'utiliser localement pour vérifier si cela résout mon soucis. Il faut donc créer la recette pour compiler libxcrypt, puis modifier celui de glibc pour ne pas compiler et de ne pas utiliser son libcrypt interne quand on souhaite générer un SDK. Je dois également corriger Perl (via un correctif déjà existant dans le paquet RPM de Fedora) pour utiliser libxcrypt convenablement avec.

Cela fonctionne bien. Du coup étape 2, j'envoie aux deux développeurs mon yocto-uninative pour qu'ils le testent de leur côté que la compatibilité est bonne sur Ubuntu ou Fedora 27. Cela fonctionne bien aussi.

Étape 3, nettoyer mon travail et l'envoyer en amont pour que tout le monde en bénéficie. Et les prochains yocto-uninative seront compatibles avec Fedora 28. Richard Purdie ira plus loin dans l'utilisation de libxcrypt en utilisant le concept de virtual/crypt. Sachant que ce travail devrait finir par disparaître quand Glibc officiel intégrera le changement de Fedora, normalement cette année.

Et quelques jours plus tard, le travail est publié ici et .

Conclusion

Tout d'abord que le Logiciel Libre est un travail d'équipe, vraiment. Grâce à Joshua et Richard j'ai gagné du temps en recherche d'info, de solution et dans la réalisation des tests. Leur aide a été précieuse. Et eux ont pu bénéficier un retour de Yocto sur Fedora 28 avant sa sortie, permettant de corriger des soucis avant qu'une horde d'utilisateurs ne viennent se plaindre que cela ne fonctionne pas. Et bien entendu les futurs utilisateurs de Fedora 28 et de Yocto pourront se contenter d'utiliser Yocto sans soucis et sans rien faire.

Ensuite, les tests c'est important. En testant les Fedora instables, on découvre des soucis et on peut les résoudre avant que l'utilisateur lambda ne s'en serve. Cela améliore grandement le confort d'utiliser la distribution. Et comme ce changement sera dans glibc officiel, cela permet de préparer le reste du Logiciel Libre à l'arrivée de ce genre de changements majeurs sous le capot.

Pour finir, tester Fedora et écrire les dépêches de sortie me permettent d'être à l'aise avec la distribution au fil du temps. J'ai pu identifier et corriger le soucis plus vite que si je ne maîtrisais pas mon système, car je sais où chercher l'information

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

Articles similaires

Thuban : Publication d'isotop 0.3

Qui dit nouvelle version d'OpenBSD dit nouvelle version d'isotop.
Pour les bavards du fond, isotop est une OpenBSD "simplifiée" qui permet d'avoir rapidement un environnement de travail sur un pc de bureau pour découvrir ce système. Autant que possible, les outils de base dans OpenBSD sont utilisés, et sont accompagnés par quelques scripts qui se veulent aussi légers que possible. Une série de programmes courants sont présents, comme par exemple la suite bureautique libreoffice ou encore le navigateur Firefox.
L'objectif d'isotop n'est pas d'être la plus rapide ni proposer les programmes les plus récents. Je souhaite faciliter l'accès à ce système réputé robuste et sûr, ce qui n'est pas une mince affaire de nos jours.

Pour récupérer la dernière version, vous pouvez lire la page de téléchargement ou bien la suite :

Cliquez sur un des magnets suivants :

Ou alors, les copains hébergent les isos sur leurs serveurs :

Outre les améliorations déjà présentes dans OpenBSD 6.3, on pourra entre autres noter les points suivants dans isotop :

  • Xenodm, le gestionnaire de connexion est plus joli.
  • Un outil pour configurer Xenodm est disponible. Il permet de changer le fond d'écran, en définir plusieurs aléatoirements ou bien configurer une connexion automatique pour un utilisateur (⚠️)
  • Une interface simple pour qu'un utilisateur puisse accéder à des privilèges root est intégrée. Ça évite de configurer doas pour chaque application nécessitant ces droits. On peut voir ça comme un "gksu" simplifié, qui ne retire rien à doas.
  • La possibilité de traduire l'interface est présente. Pour l'instant, c'est le français et l'anglais seulement, selon l'agencement du clavier définit à l'installation.
  • Les médias insérés sont automatiquement montés dans /vol. Un raccourci dans le dossier utilisateur est présent pour y faciliter l'accès.
  • Un peu moins de programmes sont présents par défaut, ça allège les images.
  • L'apparence est plus sobre, libre à chacun de personnaliser le thème à son goût.
  • Si un utilisateur décide d'envoyer aux développeurs d'OpenBSD son "dmesg" (ça aide à améliorer le support matériel), un message de confirmation lui est affiché.
  • Unbound est toujours présent pour se charger des résolutions DNS en local, le FAI n'a pas à savoir ces choses-là.
  • Ffom est intégré pour trouver un miroir rapide.
  • De nouveaux fonds d'écran (merci péhä!)

J'aurais souhaité proposer une installation automatisée. À vrai dire, ce n'est pas si compliqué à mettre en place. J'ai toutefois dû revoir ma copie, puisque cela imposait des choix par défaut à l'utilisateur qui peuvent s'avérer aussi perturbants voire plus que l'installateur normal. Normalement, tout le monde est capable de lire les quelques instructions pour l'installation, à savoir :

  • Laisser au moins de 4G pour les programmes installés avec isotop (je compte large) ;
  • Bien installer le set site63.tgz lors de l'installation.

Par ailleurs, c'est Firefox ESR 52 qui est installé par défaut, simplement pour assurer un support convenable dans le temps au cas où on installerait isotop dans 3 mois. Rien ne vous empêche d'installer la version 59 avec pkg_add.

Bref, j'espère que ça vous donnera envie de découvrir OpenBSD et que les petits ajouts vous feront plaisir :)

Gravatar de Thuban
Original post of Thuban.Votez pour ce billet sur Planet Libre.

Articles similaires

Renault : [F28] Participez à la journée de test consacrée à la version Atomic / Cloud

Aujourd'hui, ce mercredi 11 avril, est une journée dédiée à un test précis : sur l'image Atomic / Cloud de Fedora. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

La version Cloud de Fedora est un des trois produits officiels du projet avec Workstation et Server. Son but est d'être une image très minimale pour être instanciée de nombreuses fois dans le cadre d'un infrastructure Cloud afin de remplir le rôle d'un service. Cependant, contrairement aux deux autres produits, la version Cloud est mise à jour très régulièrement (de nouvelles images sont disponibles toutes les quelques semaines seulement, contre 6-7 mois en moyenne pour les autres).

Une nouveauté qui commence à s'installer est la mise à disposition de Fedora Workstation Atomic. Jusque là, seule l'image Cloud bénéficiait de ce système. Ce travail provient du projet Atomic qui repose lui même sur rpm-ostree dont l'un des buts est de versionner le système pour améliorer la fiabilité du système en cas d'installation ou de mise à jour d'un programme en autorisant un retour en arrière très simplement et avec des opérations qui sont atomiques (d'où le nom). Il est également aisé de voir ce qui a changé dans le système, notamment si l'utilisateur a changé des fichiers de configuration importants et ce qu'il a appliqué. Le système est également plus orienté utilisation d'applications dans un conteneur (comme les Flatpak) et les répertoires systèmes sont mieux isolés, par exemple /usr est par défaut en lecture seule.

Les tests du jour couvrent :

  • Est-ce que l'image démarre correctement, permet de se connecter et si les services se base se lancent bien et que SELinux remplit son rôle ;
  • Vérifier si la gestion de Docker ou Atomic (installation, mise à jour, retour en arrière) fonctionne correctement ;
  • Lancement des applications ;
  • Vérifier la compatibilité avec le cloud Amazon et OpenStack ;
  • S'assurer que l'image Atomic Workstation fonctionne avec ses spécificités : installation du système, Flatpak et GNOME Logiciels pour les notifications et installer des programmes.

Si vous êtes intéressés par l'aspect Cloud de cette image ou par l'ajout d'Atomic dans Fedora Workstation, je vous invite à les tester, elles bénéficient en effet de relativement peu de retours pour le moment. La moindre aide est appréciée, merci.

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

Articles similaires

Littlewing : Intégration et médiation avec Apache Camel

Depuis quelques jours, je teste Apache Camel pour la mise en œuvre  de médiations.

Apache-camel-logo

Apache Camel est un framework assez ancien. Il est similaire à Spring Intégration et permet l’ implémentation de patterns d’intégration.

Les patterns d’intégration

Qu’est-ce qu’un pattern d’intégration allez-vous me dire ? C’est une solution d’architecture ou plus simplement une recette de cuisine permettant d’avoir une solution toute prête à une problématique d’intégration donnée. L’ensemble de ces patterns est décrit sur ce site ( ne vous attardez pas sur le look des années 90 … ).

Exemple :

PublishSubscribeSolution

 

Camel permet simplement de gérer l’intégration via un DSL.

Choix d’implémentations

On peut faire pas mal de choses avec ce FRAMEWORK et de plusieurs manières. J’ai fait les choix d’implémentation suivants :

  • Tout se fera avec SPRING … et pas en XML 🙂
  • Il faut que toutes les médiations soient testables
  • J’exécute le code dans un FATJAR ( pourquoi avec springboot )
Configuration de la route

Apache Camel définit les médiations dans des routes. Elles se définissent assez rapidement .

Les routes commencent par une instruction from et se terminent par une ou plusieurs instructions to.

Pour mon exemple, j’extrais les données d’une table et les stocke dans un fichier.

Tout se configure par des URLs. La première permet d’extraire les données via JPA/HIBERNATE. Une entité Address permet le requêtage. La seconde permet le stockage dans un fichier texte JSON.

Elles sont externalisées dans des fichiers de configuration pour faciliter les tests et accessibles via SPRING.

Lancement de la route

Le lancement de la route se fait dans une méthode main() :

Tests

Camel fournit une API de test assez bien fournie. Elle permet notamment de mocker des endpoints existants (ex. : le fichier de sortie de mon cas de test).

Dans mon cas, j’ai décidé de remplacer la base de données que j’interroge en input par une base HSQLDB chargée en mémoire. Le fichier de sortie est, lui, remplacé dynamiquement par un mock. Pour ce faire, j’ai utilisé les « adviceWith »

Pour aller plus loin

Il y a pas mal d’exemples sur le GITHUB de CAMEL. Vous pouvez également acheter le livre « Camel In Action ». Ca ne vaut pas Effective Java 🙂 , mais vu qu’il est écrit par le principal développeur, c’est une très bonne référence.

 

 

Gravatar de Littlewing
Original post of Littlewing.Votez pour ce billet sur Planet Libre.

Articles similaires

blog-libre : Comment suivre les mises à jour de vos logiciels libres

Je fais de la veille depuis un moment mais je me suis fait la réflexion il y a seulement un mois que je devais suivre les mises à jour des logiciels/outils que j’utilise. Quelques raisons à cela :

  • Suivre l’actualité, surveiller le développement et les nouveautés des logiciels/outils qu’on utilise est sage et fort utile
  • Pour un sysadmin/architecte/dev, ça permet d’avoir une bonne visibilité des dernières solutions/features dans le domaine et de garder un œil sur les bugs résolus
  • Intéressant de voir ce « panaché » de différents projets, comment ils travaillent (cycle de dev, release notes, communication, outils utilisés…), comment ça évolue
  • Mieux comprendre mes outils, leur fonctionnement, leurs limites et bugs. J’aime beaucoup lire les news Coreutils notamment
  • Accessoirement ça peut aider à la prise de décision pour choisir un logiciel. En environnement professionnel un projet avec des commits fréquents, une communauté active peut faire la différence par exemple
RSS comme d’hab

J’ai voulu réutiliser l’outil principal me servant pour ma veille, le lecteur RSS. J’utilise FreshRSS (le meilleur !), il propose les avantages suivants :

  • Il permet de créer une catégorie où on rangera spécifiquement certains flux RSS, j’ai créé la catégorie Releases
  • Il permet lors de l’ajout du flux RSS de spécifier où envoyer le flux RSS (dans quelle catégorie), si on veut l’afficher dans le flux principal ou seulement dans une catégorie précise (Visibilité > Afficher dans sa catégorie) et de choisir la période de rafraîchissement (Ne pas automatiquement rafraîchir plus souvent que 12h pour ma part)
  • Lorsqu’on veut ajouter un flux RSS, il va chercher le flux sur le site. Et c’est très utile vu que la plupart des projets se foutent complètement d’indiquer l’adresse du flux RSS. Par exemple je lui donne https://secure.php.net/releases/, il me propose comme flux RSS https://secure.php.net/releases/feed.php
Bazar comme d’hab

J’ai commencé à lister tous les outils que je voulais suivre, ceux que j’utilise en tant qu’utilisateur (BorgBackup, Raspbian, Termux, Coreutils…), ceux sur lesquels je bosse (MariaDB, PHP, systemd, rsyslog…). Ensuite je me suis penché sur chaque projet, je m’attendais à quelque chose de plus carré et simple… c’est le bazar et pas du tout la cathédrale.

Voici ma liste par ordre alphabétique, je vais attendre un peu (work in progress) et j’en ferai un Mémo. Le premier lien concerne la page releases, le second lien le flux RSS, le troisième (quand il y a besoin) le changelog (news, release notes).

Ansible RSS Changelog
BorgBackup RSS Changelog
Chrony ML
Coreutils RSS
dnsdist RSS Changelog
Elixir RSS Changelog
Etcher RSS Changelog
FreshRSS RSS
Glances RSS
Guake RSS
HAProxy Changelog
MariaDB RSS Changelog
ncdu RSS
Nix RSS
Node.js RSS
peco RSS
PHP RSS
Python RSS
ranger RSS Changelog
Raspbian
rsyslog RSS Changelog
Ruby RSS
scrcpy RSS
Shaarli RSS Changelog
Signal RSS
Syncthing RSS
systemd RSS Changelog
Terminator RSS
Termux RSS
Tilix RSS

Ce que j’ai appris et compris

Le lecteur voit le résultat final qu’on lui présente élégamment dans un article, vous verrez difficilement certains points. Voici ce que j’ai appris et compris :

  • Il m’a fallu plus de 3h pour 30 projets entre lister mes outils, ah j’ai oublié celui-là, il est où le flux RSS, bordel le changelog !
  • Les 2/3 des projets sont sur GitHub… l’occasion de se remémorer l’article de Carl : Le danger GitHub
  • Pour ceux qui ne le savent pas, sur GitHub il suffit en général d’ajouter .atom à la fin de l’URL pour avoir le flux RSS. Ainsi https://github.com/peco/peco/releases devient https://github.com/peco/peco/releases.atom
  • Beaucoup de projets publient la release sur GitHub mais ne mettent aucune information. Par exemple rsyslog v8.34.0 (il faut cliquer pour comprendre) : v8.34.0. Dit autrement suivre certains flux RSS ne vous apportera aucune information sauf une date de sortie… il vous faudra systématiquement aller sur la page Changelog. C’est bien pour ça que je les ai donné
  • On pourrait croire que les projets plus importants sont mieux lotis ou plus carré, pas du tout ! Pour moi une référence c’est le changelog de Shaarli : 1/ Changelog versionné, nommé CHANGELOG.md bien voyant et à la racine du projet sur GitHub 2/ Une URL qui ne change pas ! https://github.com/shaarli/Shaarli/blob/master/CHANGELOG.md contrairement à https://github.com/borgbackup/borg/blob/1.1.5/docs/changes.rst#changelog avec le numéro de version dedans, ce qui veut dire que ça va changer 3/ Où on renseigne comment est pensé le changelog : The format is based on Keep a Changelog and this project adheres to Semantic Versioning
  • A comparer avec Raspbian par exemple, je n’ai pas trouvé de flux RSS… raspbian.org existe mais le changelog est chez raspberrypi.org…
  • Citons aussi dnsdist, un sous-projet de PowerDNS. Les releases de PowerDNS et dnsdist sont mises ensemble… donc mélangées : https://github.com/PowerDNS/pdns/releases
  • Parfois pas le choix, il faut passer par une mailing list : https://chrony.tuxfamily.org/lists.html https://www.mail-archive.com/haproxy@formilux.org/msg28004.html (on peut se brancher en RSS dessus mais il faudra filtrer sur ANNOUNCE)
  • Pour vous rendre compte de la difficulté et du bazar pour trouver les bonnes URL : http://feeds.feedburner.com/PythonInsider https://dev.yorhel.nl/ncdu/changes https://savannah.gnu.org/news/atom.php?group=coreutils https://github.com/systemd/systemd/blob/master/NEWS https://www.haproxy.org/download/1.8/src/CHANGELOG https://elixir-lang.org/blog/categories.html#Releases
Cheminement

Souvent les informations récoltées via flux RSS sont insuffisantes, il faut alors aller chercher le changelog qui peut être difficile à retrouver…

Pour ma part je garde un fichier nommé releases sous la main où j’ai répertorié les URL des projets. Concrètement le cheminement donne 1/ Je suis averti de la nouvelle version du logiciel par flux RSS 2/ Je consulte le changelog ou 3/ J’ouvre mon fichier releases, je clique sur le lien du changelog. C’est une solution peu satisfaisante et perfectible. Comment vous faites de votre côté ? Une meilleure solution ? Partagez !

En conclusion

Il reste encore beaucoup de chemin à parcourir aussi bien côté projets pour qu’ils informent correctement et de manière simple que côté utilisateurs cherchant « juste » à s’informer. Chaque projet gère sa barque comme il l’entend, il faut gérer les priorités et faire avec les moyens du bord mais communiquer, améliorer ou juste fournir un changelog et un flux RSS corrects ne devrait pas être négligé.

Les modèles du genre sont Python, MariaDB, Shaarli. Développeurs au boulot ;)

Gravatar de blog-libre
Original post of blog-libre.Votez pour ce billet sur Planet Libre.

Articles similaires

genma : Coffre-fort de mot de passe : état des lieux

Pour (re)définir ce que j'entends par Coffre-fort de mot de passe, je dirai ceci : "Dans le guide d'hygiène numérique, j'évoque le fait qu'il faut avoir un mot de passe différent généré aléatoirement par site, le tout stocké dans un logiciel dédié, un coffre-fort de mot de passe, qui s'ouvre avec une phrase de passe"

J'ai écrit différents articles de sensibilisation et de partage sur les mots de passe et les coffres-forts de mot de passe et je vous mets la série de lien ci-dessous :
-Les phrases de passe
-Changement de mot de passe et testament numérique
-Keepass au quotidien c'est possible
-A.I.2 - Porte blindée ou coffre-fort ?
Et d'une façon générale, Les billets tagués Keepass

Il existe des solutions de service en ligne qui ont l'avantage de proposer une synchronisation (via Internet) entre différents appareils (ordinateur, smartphone, tablette), mais dont le code source n'est pas accessible. Les experts en sécurité des podcasts que j'écoute (Le Comptoir Sécu pour ne pas le nommer) utilise et vante ce type de solution. Personnellement, adepte du logiciel libre, j'ai fait depuis un moment le choix de Keepass. Il faut un petit temps d'adaptation, car un gestionnaire de mot de passe (l'autre nom pour coffre-fort de mot de passe) demande un petit temps d'appropriation. Avec le temps, le réflexe est là : toute nouvelle inscription sur un site passe par la création d'une fiche dans Keepass, la création d'un mot de passe aléatoire utilisé uniquement pour le site en question.

Quelle solution pour une synchronisation ?

Différents billets de blogs et messages dans des forums proposent une même solution, à savoir :
- KeepassX (dans mon cas je suis passé à KeepassXC) ;
- Synchronisation du fichier de base de données via Nextcloud ;
- Application Keeweb intégrée à Nextcloud pour avoir un accès web ;
- Application Keepass2Android et synchronisation Webdav ou via l'application Nextcloud pour un usage mobile.

Quid des sauvegardes ?

Le fait d'avoir un coffre-fort de mot de passe synchronisé entre plusieurs appareils ne fait pas que l'on en a une sauvegarde. Car si on modifie / supprime un des mots de passe du coffre-fort, avec la synchronisation, la suppression est copié dans toutes les versions et on perd définitivement le mot de passe. Les recommandations liées aux sauvegardes s'applique donc là aussi : on copiera régulièrement le fichier du coffre-fort numérique sur un espace de confiance (par exemple un disque externe sur lequel on fait ses sauvegardes, disque que l'on conserve soigneusement).

Quid de la sécurité ?

La sécurité de Keepass tient essentiellement à la qualité et la complexité (la longueur) de la phrase de passe (il faut également penser à mettre à jour le logiciel).

La synchronisation via Nextcloud pose le soucis de la sécurisation de Nexcloud en lui-même (il faut maintenir le serveur à jour et de façon sécurisé et de préférence déléguer cette partie à un administrateur système de confiance, comme au sein des CHATONS par exemple).

Dans le cas de la synchronisation par un client Nexcloud sur son téléphone, on a donc une copie de son coffre-fort numérique sur son téléphone. Tout comme avec son ordinateur (rappel les smartphones ne sont rien d'autres que des ordinateurs au format poche), il faut donc protéger son appareil avec un code, nécessaire au déverrouillage. Et activer le chiffrement du disque.

Autre solution (complémentaire) : avoir deux conteneurs Keepass. Un avec les mots de passe usuels que l'on peut utiliser sur un smartphone et un avec les mots de passe critique qu'on n'utilisera que sur des appareils de confiance, qui risquent peu (il y a toujours un risque, quelque soit l'appareil, mais il est plus facile de voler un smartphone - ou de le perdre) qu'un ordinateur de type tour qui ne bouge pas de son bureau.

Gravatar de genma
Original post of genma.Votez pour ce billet sur Planet Libre.

Renault : [F28] Participez à la journée de test consacrée à la modularité

Aujourd'hui, ce mardi 10 avril est une journée dédiée à un test précis : sur la modularité. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

La modularité est le résultat de la réflexion de Fedora.next, amorcé en 2014. L'objectif est de découpler le cycle de vie des applications avec celui de Fedora afin qu'un utilisateur de Fedora bénéficie de plus de flexibilité. Il serait par exemple possible de choisir une version native de Python plus récente ou plus ancienne que celle disponible par défaut. Auparavant cela n'était possible qu'en choisissant une autre version de Fedora ce qui pouvait être contraignant.

Les modules se comportent comme des dépôts supplémentaires proposant un ensemble de paquets destinés à remplacer ceux des dépôts officiels. Mais bien entendu, tout cela est géré par le projet Fedora avec la même qualité et les mêmes mainteneurs.

Pour le moment Fedora propose quelques modules : Docker, Django, NodeJS et le langage Go.

Les tests du jour couvrent :

  • Lister les modules disponibles et installés ;
  • Installer un nouveau module ;
  • Activer un nouveau module.

Comme vous pouvez le constater, ces tests sont assez simples et ne devraient prendre que quelques minutes seulement.

Il vous faudra bien évidemment installer le dépôt modular avant (paquet fedora-repos-modular).

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

Articles similaires

alterlibriste : Et si Linux devenait une option comme une autre ?

Tous les ans, on nous fait le coup de l’année du desktop Linux, à tel point que cela en devient un running gag et que plus personne n’y croit, d’autant que la fin du support de XP et le passage forcé à Windows 10 n’ont pas changé grand-chose aux stats, et pourtant…

Ma fréquentation régulière du monde du podcast (dont pâtit quelque peu ce blog), qui n’est pas particulièrement libriste mais relativement versé dans la technologie et l’attiré pour la nouveauté me semble révéler un mouvement de fond : Linux devient une alternative crédible.

Certes, cela fait des années que nous répétons qu’il est désormais plus facile d’installer une distribution généraliste qu’un Windows, qu’il est révolu le temps de compiler ses drivers et qu’un Desktop bien peaufiné n’a rien à envier à iOS, mais comme nous crions entre nous, le temps de diffusion semble bien long.

Tous les gens qui touchent un peu à la technique, à la domotique, aux serveurs ou aiment bidouiller, ont désormais eu l’occasion de se frotter à une distribution et le Raspberry pi fait bien sûr parti de ce mouvement. Alors, les habitudes sont parfois un peu dures à changer et les lignes de commandes continuent à faire peur, mais une fois qu’on a goûté à un système qui marche et que l’on peut configurer comme on le souhaite, on apprécie et on le fait savoir.

Dans la cinquantaine de podcasts non libriste que j’écoute, je compte pas loin d’une dizaine de passages à Linux qui sont évoqués depuis un an. Et pas pour des raisons idéologiques. L’essai ne sera peut-être pas totalement concluant ou ne restera cantonné qu’à une vieille machine pour les enfants, mais peu importe, d’autres que les libristes en parlent comme d’une option aussi valable qu’un autre OS. Sans oublier le nombre croissant d’articles dans la presse informatique généraliste.

Parmi les arguments évoqués par les nouveaux convertis : le ras le bol des mises à jour inopinées, les bugs sur certains matériels, les régressions… et la joie de trouver un tout nouveau système totalement fonctionnel. Cette description en titille de plus en plus qui entrevoient alors la possibilité d’essayer.

Énième effet de mode ? Je ne me fais pas d’illusions, parmi ces essais, il y a une certaine proportion qui n’hésite pas à changer de système comme de chemise et repasseront sous OS propriétaire, car seul l’attrait de la nouveauté les y aura fait goûter. Néanmoins le système sort des fourrés dans une sphère plus grand public.
2018 ne sera probablement toujours pas l’année du desktop Linux, mais peut-être sera-t-elle celle où Linux devient une option non idéologique ?

Gravatar de alterlibriste
Original post of alterlibriste.Votez pour ce billet sur Planet Libre.

Journal du hacker : Liens intéressants Journal du hacker semaine #14

Pour la 14ème semaine de l'année 2018, voici 10 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

Pour ne plus rater aucun article de la communauté francophone, voici :

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Gravatar de Journal du hacker
Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Articles similaires

Marty : KooZic: sortie de la v0.8.0, dernière release...

... utilisant Python 2. Les derniers mois ont été assez calmes au niveau de KooZic, logiciel de streaming musical. Le développement ne s'est pas arrêté pour autant, que du contraire. Plusieurs fonctionnalités ont été développées. Entre autres, le support de la normalisation audio, du non-transcodage et d'un convertisseur.

Normalisation audio

Lorsqu'une liste de lecture est parcourue, il nous est tous arrivé au moins une fois de passer d'un titre à un autre et de percevoir une nette différence de volume. Ceci s'explique simplement par le fait que qu'un fichier audio possède un certain niveau de volume, qui peut être différent de l'un à l'autre. Évidemment, lors de l'écoute d'un album complet, ceci n'arrive pas, vu que le volume de l'album est cohérent d'un morceau à l'autre. Mais lorsque les titres proviennent d'origines différentes, le volume peut fortement varier.

De nombreux lecteurs audio permettent de normaliser le volume des titres grâce à la méthode ReplayGain. Plus récemment, l'industrie de diffusion a opté pour une nouvelle méthode de normalisation, la bien nommée EBU R128 (European Broadcasting Union Recommendation R128). Depuis la version 3.2.1, FFMpeg supporte nativement cette méthode de normalisation. Cool, hein ?

Avec la v0.8.0 de KooZic, il est donc à présent possible de paramétrer une liste de lecture pour que la normalisation sus-nommée soit appliquée à tous les titres. Pour que cela fonctionne, il sera évidemment nécessaire de disposer de FFMpeg >= 3.2.1. Notez qu'un binaire est maintenant distribué avec le package KooZic. Il suffit de le copier dans "/usr/local/bin", et le tour est joué.

Une information importante à avoir en tête : la normalisation est un processus gourmand en ressources et augmente de manière non négligeable la durée de conversion. À voir donc si votre serveur peut tenir cette charge supplémentaire.

Et si on ne convertissait plus du tout ?

L'option exactement opposée a été introduite dans cette nouvelle mouture. Et si on profitait des capacités de nos navigateurs modernes pour lire les fichiers audio sans aucun traitement ?

Il est possible de paramétrer une liste de lecture pour contourner complètement l'utilisation de FFMpeg, et simplement lire le fichier tel qu'on le possède. Cela permet de décharger fortement le serveur, au prix d'une augmentation du trafic réseau.

Il est à noter que les résultats diffèrent d'un navigateur à l'autre, selon le format. Selon votre configuration, cela peut s'avérer une option très utile.

Un outil de conversion, mais pour quoi faire ?

Parce que j'en avais besoin. Il existe une myriade d'outils pour convertir un fichier audio d'un format vers un autre. La plupart font ça très bien. Mais, à ma connaissance, aucun ne permet de facilement importer une liste de lecture et de la convertir, en respectant la hiérarchie des fichiers. KooZic est capable de le faire.

À l'image des listes de lecture, on peut facilement créer une liste de fichiers à convertir. Il est également possible d'importer une liste de lecture existante. On choisit le mode de conversion, la qualité, le répertoire de sortie (par défaut dans "/tmp/koozic/"), et on démarre. La conversion démarre de manière asynchrone après moins de 2 minutes. Rien de très sexy, il faut rafraîchir la page pour voir l'avancement. Mais ça fonctionne, et c'est efficace.

Autres Nouveautés

Dans les nouveautés perceptibles, on notera le pré-chargement de la piste suivante lors de la lecture. 30 secondes avant la fin d'une piste, KooZic va charger la piste suivante. Cela permet de diminuer de manière conséquente le gap entre 2 pistes, et se rapprocher d'une configuration "gapless".

Comme annoncé plus haut, cette version est la dernière version utilisant Python 2 (Odoo v10). La prochaine version utilisera Python 3 (Odoo v11).

Mise-à-jour d'une installation existante

La nouvelle version est disponible sur le site du projet. Pas de crainte à avoir, les sources précédentes peuvent être supprimées. On extrait la nouvelle version, et on lance la mise-à-jour à partir du répertoire:

./odoo-bin -u oomusic,oovideo -d koozic --stop-after-init

On peut relancer ensuite avec la commande habituelle.

Gravatar de Marty
Original post of Marty.Votez pour ce billet sur Planet Libre.

Pages