Carrément, deux billets dans la même semaine, c’est rare. Bon rien de foufou, j’ai passé un peu de temps la semaine passé à automatiser le processus de release dans ma boite. J’avais déjà essayé d’utiliser le Maven Release Plugin mais j’ai jamais eu de succés.

Cette fois j’ai quand même été un peu plus loin alors j’écris trois mots sur le sujet, en français, si ça intéresse des gens.

Introduction

L’idée est de pouvoir versionner un composant sans autre intervention humaine que le choix des numéros de version (release et next snapshot).

Le POM.xml

Configuration des plugin

Déjà la première chose est de configurer les différents plugins de release.

  org.apache.maven.plugins
  maven-release-plugin
  2.5.3


  org.codehaus.mojo
  versions-maven-plugin
  2.5


  org.apache.maven.plugins
  maven-javadoc-plugin
  3.0.0
  
    true
  
 

Maven Release Plugin

Le Maven Release Plugin est le plugin qui va faire le gros du travail, Mettre à jour le pom avec les bons numéros de version, faire les commit et poser les tags.

Versions Maven Plugin

Le Versions Maven Plugin va permettre de mettre à jour les dépendances SNAPSHOT avant la release.

Maven Javadoc Plugin

Le Maven Javadoc Plugin C’est le plugin chargé de générer la JavaDoc, il est utilisé par le Maven Release Plugin. Dans mon cas, la Javadoc est pas super valide. Pour éviter de faire planter la release, on désactive la JavaDoc.

Source Code Management

J’ai mis un peu de temps à trouver la configuration qui va bien pour que ça fonctionne.

    scm:git:git://github.com/Marthym/hello-osgi-world.git
    scm:git:git@github.com:Marthym/hello-osgi-world.git
    https://github.com/Marthym/hello-osgi-world

Fichier properties & choix des versions

Pour pouvoir fonctionner en mode silencieux, l’étape de préparation de la release a besoin d’un fichier de configuration, à placer à la racine du projet, contenant les numéros de versions des artefacts du projet, pour la release et pour la prochaine SNAPSHOT.

Le fichier a cette forme :

scm.tag=1.5.0
project.rel.fr.ght1pc9kc\\:hello-osgi-world=1.5.0
project.dev.fr.ght1pc9kc\\:hello-osgi-world=1.6.0-SNAPSHOT
scm.commentPrefix=rel(main):

On peut aussi lui préciser le préfixe de commit, par défaut [maven-release-plugin], perso, j’aime bien l’AngularJS Commit Convention, rel(main):.

Les commandes

Résolutions de dépendences SNAPSHOT

mvn versions:use-releases -DprocessParent=true -DfailIfNotReplaced=true

Le principe du plugin consiste en la suppression des chaînes -SNAPSHOT dans le fichier mais le plugin vérifie quand même que la version existe bien et ait bien été releasé. Si ce n’est pas le cas, il plante.

Deux paramètres :

• processParent: Précise qu’il faut traiter aussi le bloc parent
• failIfNotReplaced: Demande au plugin de sortir en erreur si une version d’une dépendance n’existe pas

Release

mvn release:prepare -DtagNameFormat="@{version}" release:perform

En fait le plugin agit en deux étapes qui peuvent être exécuté en une ligne.

• prepare:
  • Rassemble les informations
  • Joue les test
  • Pose les tags
  • Modifie les poms avec les bonnes versions
• perform:
  • Compile le code sous le tag
  • Pousse le jar sur le Nexus

Attention, il est nécessaire de push les modifs

git push && git push --tags

Maven Release Plugin écrit à l'origine par Marthym pour J’ai acheté un PC neuf cassé ... le April 06, 2018.

Original post of Marthym.Votez pour ce billet sur Planet Libre.

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

DEB, RPM, PKG, Debian, Ubuntu, Fedora, CentOS, OpenSUSE, Archlinux, Gentoo... Autant de systèmes de paquets et de distributions qui font de GNU/Linux un écosystème riche et varié. Mais aussi un enfer à supporter. Le système de packaging change d'un système à l'autre, et les dépendances varient d'une version à l'autre. Essayez de générer un DEB d'une application un peu complexe compatible pour Ubuntu 14.04, 16.04 (bientôt 18.04), Debian 8 et 9, et vous allez vite comprendre la galère. J'ai essayé, j'en ai eu marre et j'ai laissé tombé. Mais je n'ai pas pour autant baissé les bras...

Un beau package bien emballé est la voie royale pour s'immiscer dans la logithèque de l'utilisateur moyen. Mais pour un projet mené avec une équipe limitée (moi), c'est beaucoup trop chronophage. Ayant définitivement abandonné l'idée de me lancer dans le packaging multi-plateforme du logiciel de streaming musical KooZic, j'ai opté pour quelque chose de plus simple : un script d'installation.

Utilisation

Les systèmes suivant sont supportés :

• Ubuntu 16.04 (et dérivés, par exemple Linux Mint 18.x)
• Debian 9
• Debian 8
• Fedora 27
• CentOS 7.4

Si votre système est différent, tant pis, ça sert à rien de continuer à lire. Si il est dans la liste, l'installation tient en 3 commandes :

curl https://raw.githubusercontent.com/DocMarty84/koozic/10.0/extra/installer/koozic_install.py > k_install.py
chmod +x k_install.py
sudo ./k_install.py install

Y'a plus qu'à aller sur http://localhost:8069...

Au niveau des options, on a la possibilité de spécifier :

• -u : l'utilisateur qui sera utilisé (par défaut : root)
• -d : le répertoire d'installation (par défault : /opt)

Supprimer KooZic ?

sudo ./k_install.py uninstall

Voilà.

Mais ça fait quoi exactement ?

Lancer un script quelconque en root n'est franchement pas ce qu'il y a de plus sûr. Qui sait ce qui peut se cacher derrière ce qui est exécuté ? Celui qui prend la peine de lire le script, bien sûr. Pour ceux que ça ne motive pas plus que ça, il reste à me faire confiance.

Juré craché, le script va :

1. installer les dépendances via le système de paquets
2. installer les dépendances Python manquantes avec pip
3. mettre en place un serveur PostgreSQL
4. télécharger la dernière version
5. installer FFMpeg dans /usr/local/bin
6. initialiser KooZic
7. installer et démarrer un script systemd qui permettra de lancer KooZic au démarrage du système

En cas de désinstallation, les étapes 1 à 3 ne seront pas annulées, pour éviter de casser quoi que ce soit. Le reste disparaîtra à tout jamais. Ou jusqu'à la prochaine installation.

Migration d'une installation existante

Si vous êtes de ceux qui utilisent KooZic, merci d'avoir passé le cap de l'installation manuelle ;-) Pour rendre votre installation compatible avec l'installation automatique, il faut stopper KooZic et désactiver le démon systemd si vous en avez créé un. Ensuite, rien de bien exceptionnel :

sudo ./k_install.py install -u USER

Remplacez USER par l'utilisateur qui était utilisé précédemment. Normalement, ça devrait fonctionner. Si pas... ben... Criez à l'aide.

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

Ce vendredi sera publié le 30ème numéro du Courrier du hacker, la newsletter hebdomadaire résumant l’actualité francophone du Logiciel Libre et Open Source. Résumé d’une aventure commencée il y a 30 semaines

Pour rappel, le Courrier du hacker propose une sélection des meilleurs articles relayés dans la semaine par le Journal du hacker. Les meilleurs articles ont déjà été sélectionnés par la communauté du Journal du hacker et j’effectue également une sélection.

Origine du projet

J’ai été très influencé par l’excellent Hacker Newsletter, une newsletter très connue qui fait un résumé des meilleurs articles publiés sur Hacker News, l’agrégateur de liens communautaire. Le fait que ce type de newsletter n’existe pas en France m’a étonné. Et en tant que fondateur du Journal du hacker, le principal agrégateur communautaire de liens de la communauté du Logiciel Libre et Open Source francophone, il m’est rapidement apparu comme évident qu’il fallait que je le fasse moi-même.

Progression des abonnés

J’en ai déjà parlé dans un précédent article, le nombre d’abonnés a grimpé très rapidement les premières semaines. Après avoir atteint un plateau autour des 700 abonnés, la progression a fortement ralenti et a été plus erratique, dépendant principalement des communications publiques faites autour du projet.

À retenir : la communication autour de son projet reste indispensable. C’est un travail de fond en parallèle qui se fait dans la durée.

Travail constant

Il est difficile d’imaginer la régularité nécessaire à la publication d’une newsletter à date fixe, si vous etes comme moi tout le temps sur une dizaine de projets différents à la fois. Je n’ai publié la newsletter en retard que deux fois en 30 semaines, ce qui m’apparait comme un exploit personnel.

À retenir : les débuts sont faciles, le vrai challenge est de s’inscrire dans le temps et de durer. C’est à bien avoir à l’esprit quand on lance une newsletter.

Baisse du taux d’ouverture

Ayant un peu lu la documentation et les retours d’expérience des créateurs de newsletters, je savais que le taux d’ouverture de la newsletter décroissait de manière régulière avec l’augmentation du nombre d’abonnés. C’est bien sur une contrariété importante quand vous produisez du contenu de le voir ignoré par les abonnés. Mais il s’agit d’un processus normal reporté par tous les éditeurs de newsletters. Reste à voir jusqu’à combien cela descendra.

À retenir : j’étais prevenu et je pensais être au-dessus du lot. Raté. C’est une donnée à surveiller et à investiguer.

Interactions avec les abonnés et autour

Je publie régulièrement via les réseaux sociaux à propos des petites nouvelles autour du Courrier du hacker. Et c’est sympa d’apprendre que le Courrier du hacker génère du trafic pour les auteurs des articles

L’initiative que j’avais prises pour les 500 abonnés a également été apprécié. Et les remerciements font chaud au coeur !

À retenir : les créateurs de contenu apprécient (en général) être relayés et qu’on parle de leur travail (moi inclus). Donc un bon moyen de génerer de la visibilité, même si ça doit rester franc et sincère pour ne pas devenir lourd.

Le projet motive d’autres initiatives

Comme je l’avais déjà évoqué dans un précédent article, les newsletters n’ont pas un succès extraordinaire en France. Pourtant le Courrier du hacker semble motiver d’autres Libristes à s’intéresser aux newsletters, comme la Gazette de MicroLinux. Plus on est de fous et plus on rit !

Si vous connaissez d’autres newsletters francophones autour du Logiciel Libre, n’hésitez pas à laisser un commentaire.

Me suivre sur les réseaux sociaux

N’hésitez pas à me suivre directement sur les différents sociaux pour suivre au jour le jour mes différentes projets dans le Logiciel Libre :

• Mastodon : @carlchenet
• Diaspora :  @carlchenet
• Twitter : @carl_chenet

Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.

En ce mardi 3 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Beta Fedora 28.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora 28 et réduisez du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

Notons que Fedora 28, avec ses quelques 51 changements officiels validés, est sans conteste la version comportant le plus de changements de son histoire. La version finale est pour le moment fixée pour la première semaine de mai (sortie le 1er ou le 8 mai).

Voici les nouveautés annoncées pour cette version :

Bureautique

• Passage à GNOME 3.28
• L'environnement Sugar est disponible en version 112.
• Mise à jour de Fontconfig à la version 2.13.
• Réduction de la redondance entre Anaconda et gnome-initial-setup dans la configuration demandée à l'utilisateur crée lors de l'installation. Le clavier, la date, l'heure et la langue resteront configurés par Anaconda, par contre la configuration du nom d'hôte est supprimée tout comme la création du compte root pour reprendre la politique d'Ubuntu. La création du premier utilisateur revient à gnome-initial-setup.
• Les modules invités de VirtualBox sont peu à peu intégrés dans le noyau officiel, Fedora propose ainsi dans ses dépôts officiels les paquets pour obtenir la résolution native ou le dossier partagé dans un système Fedora virtualisé dans Virtualbox.

Gestion du matériel

• Meilleure gestion de l'autonomie des ordinateurs portables avec un processeur Intel. Cela passe par une meilleure gestion de l'énergie des ports SATA pour disques durs et SSD (gain de 1-1,5 W), Intel HDA codec pour le multimédia est mis en sommeil après une seconde d’inactivité (gain de 0,4 W) et activation de l'économie d'énergie pour les récepteurs Bluetooth en USB (gain de 0,4 W si tous les ports USB sont en repos). Sachant qu'un ordinateur portable récent non orienté puissance consomme moins de 10 W (7,5 W chez moi) en usage non intensif. Cela peut donner 20% d'autonomie supplémentaire.
• Intégration de la norme Thunderbolt 3 (concurrent à l'USB sur de nombreux points). La politique de sécurité liée à cette norme (pour éviter qu'un nouveau périphérique accède sans autorisation à des informations confidentielles) est intégrée à Gnome Shell pour notifier les demandes à l'utilisateur.
• Mise à jour de VA-API à la version 1.0.0, qui change l'API et l'ABI mais propose en contrepartie une meilleure exploitation de l’accélération matérielle du matériel récent.
• Les appareils photo RealSens ont besoin de deux bibliothèques librealsense 1 et 2 pour exploiter l'entièreté de leur gamme historique. Le paquet librealsense réfèrera à la version 2 de la bibliothèque pour les versions modernes, un nouveau paquet librealsense1 sera nécessaire pour le matériel plus ancien.

Internationalisation

• Ibus Typing utilise maintenant la boîte de dialogue pour les emoji afin de proposer des symboles UNICODE en tapant leur description. Ainsi copyright sign propose le symbole ©.
• La bibliothèque libidn passe à la version 2.0.0 forçant le passage de la norme IDNA2003 à IDNA2008 qui ne sont pas compatibles et pouvaient être source d'attaque par redirection. Cette norme sert à transcrire un nom de domaine Internet UNICODE en une chaîne latine unique comme faß.de qui devient fass.de ou xn--fa-hia.de respectivement.
• Les données concernant l’internationalisation de GLibc sont mises à jour à partir des fichiers ISO et CLDR de 2015 (Unicode 9.0) en remplacement de iso14651_t1_common qui avait 15 ans. Cela permettra de corriger pas mal d'erreurs, dont des tris alphabétiques dans des langages moins courants en Occident. Ou les symbole infini et ensemble vide qui étaient considérés comme identiques.
• Les langues asiatiques chinoises, coréennes et japonaises utiliseront par défaut les polices de Google Noto.

Administration système

• Anaconda, le programme d'installation, devient modulaire. La communication se fait via une API plus stable en DBus, permettant d'améliorer les tests, d'être utilisable sans les droits super utilisateur et d'être étendu par l'utilisateur.
• authselect remplace authconfig et devient l'outil de configuration par défaut pour le PAM et le fichier nsswitch.conf.
• Le paquet tcp_wrappers est supprimé. Son utilisation doit être remplacée par iptables, ou mieux par firewalld.
• libnsl et nss_nis sont proposés hors de GLibc comme recommandé par le projet officiel. libnsl passe à la version 2 au passage autorisant la compatibilité de NIS avec la norme IPv6.
• De même pour Sun RPC dont la gestion dans GLibc est supprimée pour libtirpc qui permet entre autre la gestion de l'IPv6 nativement.
• Le stockage par défaut des clés et autres certificats de sécurité par la bibliothèque NSS est le format de SQLite au lieu de DBM. Cela permet l'accès parallèle et diminue le risque de corruption de la base de données.
• OpenLDAP utilise OpenSSL au lieu de NSS, comme recommandée par le projet officiel.
• Les bibliothèques de OpenLDAP non compatibles multithread redirigent vers leur version compatibles multithread comme libldap qui pointe vers libldap_r.
• OpenLDAP abandonne la gestion de TCP Wrappers également.
• L'utilisateur et groupe nobody:nobody passent de UID et GUID 99:99 à 65534:65534, nfsnobody est supprimé, et nobody n'est plus utilisé de manière systématiquement par défaut pour certains services. Des utilisateurs dédiés seront crées.
• Nouvelle version de la politique de sécurité par défaut. Les clés RSA doivent être de minimum 2048 bits et DSA est désactivé par défaut. Le passage à TLS 1.2 minimum est repoussé pour le moment.
• Les paquets de gestion de Kerberos dans Python sont grandement remaniés. python-krbV, pykerberos et python-requests-kerberos sont remplacés par python-gssapi. Le premier n'est pas compatible Python 3, le second n'a pas de documentation et est trop minimaliste quant au dernier il n'est plus maintenu.
• libcurl utilisera libssh au lieu de libssh2 pour les protocoles SCP et SFTP ce qui permet l'utilisation de l'authentification GSS-API et l'usage d'algorithmes plus sécurisés par défaut.
• L'outil time passe à la version 1.8, qui change de licence vers GPLv3 et GFDL, qui a de nouveaux codes d'erreur et une nouvelle sortie par défaut. L'affichage conforme POSIX reste possible via l'option -p.
• Mise à disposition de l'application Stratis Storage qui est une application Python communiquant à travers DBus pour gérer l'espace de stockage du système. Reposant sur le système de fichier XFS pour le moment, son but est de proposer des fonctionnalités populaires chez Btrfs, ZFS ou LVM mais en plus simple pour l'utilisateur comme les clichés, l'intégrité des données ou mettre en place un système de cache.
• Facter passe de la version 2.4.3 à 3.9.2.

Développement

• Binutils passe à la version 2.29.1.
• GLibc 2.27 est utilisée par défaut.
• La partie cryptographique libcrypt de GLibc est remplacée par libcrypt.
• GCC 8 devient le compilateur de référence.
• Le framework Web de Python DJango dégaine à la version 2.0.
• Coup de Boost à la version 1.66.
• Ruby est polis à la version 2.5.
• Le compilateur Haskell GHC évolue à la version 8.2.
• De même pour le couple Erlang/OTP pour la version 20.
• Le langage Go court vers la version 1.10.
• L'éléphant PHP avance prudemment à la version 7.2.
• Mise à jour de giflib vers la version 5.1.4. Un paquet compat-giflib est proposé pour faciliter la transition aux utilisateurs.
• Les symboles de débogue PE pour les applications compilées avec MinGW (à destination de Windows donc) seront conservés pour simplifier le débogue natif. Les autres symboles seront bien conservés dans le dossier .debug à part. Cela a un sourcoût d'environ 17% d'espace disque pour une application compilée par ce biais.

Modularité

• Ajout des dépôts modular, modular-updates et modular-updates-testing pour proposer des composants dans des versions différentes que dans les dépôts natifs de Fedora. Ainsi l'utilisateur peut choisir d'utiliser une version plus récente (ou ancienne) de Python que celle proposée nativement. Mais seulement des composants toujours maintenus par le projet officiel sont proposés.

Projet Fedora

• L'architecture Aarch64 (ARM 64 bits) devient une architecture primaire pour Fedora Server, donnant lieu à une meilleure promotion et à une meilleure qualité des images officielles.
• L'architecture s390x est proposée aux images Cloud, Docker et Atomic.
• Les binaires empaquetés par Fedora et compilés avec GCC sont maintenant annotés pour permettre de plus facilement retrouver les options de compilations l'ayant généré ou les propriétés de son ABI.
• Renforcement des options de compilation par défaut pour une meilleure sécurité. Ajout de -fstack-clash-protection, D_GLIBCXX_ASSERTIONS, -fcf-protection=full -mcet, .got.plt et --enable-default-pie.
• Définition et empaquetage des applications écrites en Rust comme exa, ripgrep ou tokei.
• Activation de Python Generators pour permettre aux empaqueteurs de choisir d'utiliser ou non le générateur automatique de dépendance envers un module Python au lancement.
• Les scriptlets ldconfig sont supprimés, du moins pour les paquets installant les bibliothèques partagées dans des endroits standards. Cela simplifiera la maintenance des specs RPM et l'installation des paquets sera également plus rapide.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel. En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Zanata.

Bons tests à tous !

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