Aujourd'hui, ce mercredi 26 septembre, est une journée dédiée à un test précis : sur Java 8, 10 et 11. 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 ?

Java est un langage de programmation très populaire dont une des caractéristiques est d'utiliser une machine virtuelle pour exécuter le programme, ce que l'on nomme la JVM pour Java Virtual Machine. Il existe plusieurs JVM concurrentes et Fedora fournie la version libre de référence qui est OpenJDK.

Oracle, le développeur principal, a changé récemment le cycle des versions ce qui conduit à Fedora de proposer pour des raisons de compatibilités plusieurs versions en simultanées dans le système. Fedora 29 devra donc proposer la OpenJDK 8, 10 et 11. Et c'est la raison du test d'aujourd'hui.

Plus précisément les tests consistent en :

• Installer les paquets des différentes versions, et vérifier si le chemin de différents fichiers est le bon.
• Utiliser la méthode des alternatives pour changer la JVM de référence à la volée, et s'assurer que le mécanisme fonctionne.
• Vérifier que OpenJDK respecte les règles cryptographiques du système suivant la politique choisie.
• Vérifier qu'une application fonctionne si on utilise l'algorithme Shenandoah comme algorithme de référence pour la ramasse miette. Uniquement pour les architectures aarch64 et x86_64.

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é.

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

Un hébergement d'une VM avec OpenBSD, ça vous tente ?

C'est ce que nous propose "OpenBSD.amsterdam".

Les Services

Dans une VM avec 512 Mo de RAM, et un espace disque de 50 Go, dont 25 pour votre /home, OBSD.ams nous propose l'hébergement. Il est possible de demander l'accès à la console vmctl(8) - utile quand il faudra prochainement upgrader vers 6.4.

Le but est de tester la robustesse et de faire des retours auprès de l'équipe OpenBSD.

Vous aurez une adresse IPv4, fixée par DHCP, et une adresse IPv6 dédiée.

Il est possible d'installer tout service réseau que vous souhaitez, exécuter httpd ou installer nginx, utilisez votre serveur nsd, et/ou un résolveur cache unbound, un serveur smtpd, un serveur VPN, etc...
Mais ATTENTION, réfléchissez avant d'installer un relais TOR - ne serait-ce qu'à cause de la puissance machine, mais aussi parce qu'ils ont une instance par serveur vmd, une autre instance sur leur réseau, ainsi qu'un noeud de sortie...

La configuration

=> Celle de disklabel :

#            size        offset  fstype [fsize bsize  cpg]
  a:      1024.0M            64  4.2BSD   2048 16384    1 # /
  b:       752.0M       2097216    swap
  c:     51200.0M             0  unused
  d:      3565.2M       3637312  4.2BSD   2048 16384    1 # /tmp
  e:      5088.0M      10938880  4.2BSD   2048 16384    1 # /var
  f:      2048.0M      21359104  4.2BSD   2048 16384    1 # /usr
  g:      1024.0M      25553408  4.2BSD   2048 16384    1 # /usr/X11R6
  h:      7483.8M      27650560  4.2BSD   2048 16384    1 # /usr/local
  i:      2048.0M      42977344  4.2BSD   2048 16384    1 # /usr/src
  j:      4794.6M      47171648  4.2BSD   2048 16384    1 # /usr/obj
  k:     23371.7M      56991008  4.2BSD   2048 16384    1 # /home

=> OpenBSD 6.3 avec les sets d'installation : -x* +xbase* +xfont*

Le coût

60 € / an / instance, à payer en une seule fois, au moment de l'accord. 10 € sont reversés à la Fondation OpenBSD, soit un peu plus de 16 % !

Mais attention, d'abord, il faut les contacter, en restituant les informations nécessaires, dont une clé SSH publique ED22519 - bien vu !
Il est possible de les aborder par le biais de leur compte Mastodon, voire Twitt... mais pour ce dernier, vous vous débrouillez.

----

PS : un partenariat pour notre petite communauté, sur lequel on installerait un service VPN, DNS... qui nous coûterait maximum la reverse à la Fondation OpenBSD, soit les 10 € ; vous seriez d'accord OBSD.ams ?!

Quoiqu'il en soit, même si ça ne se fait pas, nous on apprécie l'initiative, entre le fait de participer à la détection et la remontée de bogues sur VM, vmctl, et le fait de reverser autant à la Fondation OpenBSD, nous on dit "chapeau bas", et "Merci" - c'est vraiment un très beau geste ! :D

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

En ce mardi 25 septembre, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Beta Fedora 29.

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 29 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.

La version finale est pour le moment fixée pour le 23 ou 30 octobre. Voici les nouveautés annoncées pour cette version :

Expérience utilisateur

• Passage à GNOME 3.30.
• De même pour Xfce 4.13 qui bénéficie enfin de GTK+3.
• Le menu de GRUB sera caché par défaut, sauf en cas de dual-boot.
• La variable $PATH par défaut change l'ordre des dossiers /.local/bin pour les placer devant afin d'être prioritaires par rapport aux dossiers systèmes. Cela rejoint la politique de Debian et Ubuntu.
• L'utilitaire Wireshark perd son interface GTK+, uniquement l'interface Qt est proposée en adéquation avec le choix du projet.
• Le synthétiseur vocal festival est proposé à la version 2.5.

Gestion du matériel

• Les paquets i686 sont compilés avec les instructions SSE2 ce qui réduit la liste des processeurs compatibles avec Fedora pour cette architecture. Mais pour les processeurs supportés tout comme x86_64 un gain notable de performance est possible.
• Les images pré-générées pour les architectures ARMv7 et aarch64 bénéficient de la ZRAM pour la swap par défaut afin d'améliorer les performances et limiter l'usure des cartes SD de stockage.
• Prise en charge initiale des FPGA, les cartes 96boards d'Ultra96 et UP² d'Intel proposent des FPGA pour faire des calculs spécialisés comme l'IA ou le machine learning. Fedora propose des outils de base et agnostiques pour les exploiter.
• Clap de fin pour l'architecture ppc64, sa sœur little endian ppc64le recevra toutes les attentions pour cette famille.

Internationalisation

• Mise à jour du gestionnaire d'entrée de saisie IBus vers 1.5.19.
• La famille de police de caractères Liberation, compatible avec celle de Microsoft, passe à la version 2 proposant plus de caractères UNICODE.
• Les langues asiatiques chinoises, coréennes et japonaises utiliseront par défaut les polices de Google Noto.
• Les fichiers des fuseaux horaires de tzdata seront fondés sur le format vanguard en accord avec le choix effectué en amont. Cela améliore la compatibilité avec POSIX.

Administration système

• Mise à jour d'OpenShft Origin 3.10.
• Ajout du module Kubernetes.
• Ansible utilise Python 3 par défaut.
• Stratis Storage est mis à jour à la version 1.0.
• GnuTLS utilise le protocole TLS 1.3 par défaut.
• Le module p11-kit-proxy gère les bases de données NSS par défaut maintenant en plus d'OpenSLL et GnuTLS.
• Fusion de Dstat et Performance Co-Pilot pour les statistiques de performance. Dstat n'est plus maintenu en amont mais PCP ajoute le module pcp-dstat pour être compatible avec son illustre prédécesseur.
• OpenLDAP ne gère plus le module NSS pour la sécurité, suite à son remplacement par défaut par OpenSSL pour Fedora 28.
• Le fichier /usr/bin/python est fourni par le paquet python-unversioned-command en accord avec la PEP 394. Les paquets de Fedora mentionnent explicitement l'usage de Python 2 ou 3.
• Les groupes de paquets python-classroom, engineering-and-scientific, development-libs, cloud-management, font-design, mysql, robotics-suite, authoring-and-publishing et electronic-lab utilisent les paquets Python 3. Le groupe python-web est supprimé.

Développement

• Binutils passe à la version 2.31.
• GLibc 2.28 est utilisée par défaut.
• Node.js 10 est proposé par défaut.
• Python 3.7 devient la version de référence.
• Ruby on Rails est sur les rails de la version 5.2.
• La perle des langages, Perl 5.28, a été mis à jour.
• Le langage Go passe à la version 1.11.
• MySQL 8 est proposé pour sa gestion des bases de données.
• OpenJDK 11 LTS devient la machine virtuelle de référence pour Java.
• La sélection de paquets compatibles entre eux Haskell Stackage LTS passe de la version 10 à 11.

Modularité

• Fedora Workstation et Cloud bénéficient par défaut des modules en plus de Fedora Server. Ainsi tout le monde est capable facilement d'exploiter les modules, pour installer une version différente de Node.js que celle proposée par exemple.

Projet Fedora

• Fedora Workstation Atomic devient Silverblue. Ce projet qui monte en puissance met en avant le projet Atomic pour l'édition phare de Fedora. Cela consiste majoritairement à utiliser Flatpak et rpm-os-tree pour gérer les paquets permettant une meilleure isolation des composants et une plus grande fiabilité du système. Un site web dédié a été conçu pour l'occasion.
• Les éditions dérivées de Fedora comme les Spins, labs ou conteneurs auront les champs VARIANT et VARIANT_ID renseignés dans le fichier /usr/lib/os-release pour avoir des statistiques plus précises quant à leur utilisation et pour l'utilisateur de connaître la provenance de l'image.
• Fedora Scientific a une image VagrantBox en plus des ISO traditionnelles.
• GCC n'est plus nécessaire dans l'image de compilation de Fedora, réduisant le temps nécessaire à la production des paquets n'en ayant pas besoin.
• Fedora Cloud aura des images mises à jour mensuellement, pour limiter la taille des mises à jour à effectuer après l'installation.
• La compilation du bytecode Python est moins magique pour les paquets, les étapes doivent être mieux décrites pour faciliter la transition vers Python 3.
• Les modules Perl obtenus via CPAN changent leurs URL de search.cpan.org vers metacpan.org dans la description des paquets concernés.
• Les paquets Erlang sont liés à aucune architecture dorénavant.

Tester

Durant le développement d'une nouvelle Fedora, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est pendant une journée de tester une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L'équipe de qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui indiqué. Dans le cas contraire, un bogue devra être ouvert pour permettre l'élaboration d'un correctif.

C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J'annonce régulièrement ici quand une journée de tests est planifiée.

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.

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

Régulièrement, j’entends des utilisateurs se plaindre de ce format de paquet, qui occuperait un peu plus d’espace disque ou qui aurait encore quelques bugs de jeunesse, comme le thème de l’application qui pourrait différer de celui de l’utilisateur ou, plus ennuyeux, l’impossibilité de pouvoir jouir de certaines fonctionnalités, qui seraient pourtant disponibles dans la version standard, non exécutée dans un « bac à sable ».

Mais il faut voir sur le long terme. La version 1.0 est enfin sortie au mois d’août 2018, après plusieurs années de développement, ce qui permet de franchir un premier cap. Maintenant, il faut savoir que si elles n’ont pas été directement pensées pour ce mode de fonctionnement, certaines applications ont besoin d’être adaptées pour pouvoir fonctionner parfaitement. Mais ce n’est qu’une question de temps et ça ne doit pas éclipser pour autant les nombreux avantages déjà permis.

Tout d’abord, nous pouvons citer la sécurité. Les applications Flatpak sont exécutées dans un environnement « bac à sable » (sandbox) sûr, isolé du reste du système. Mieux encore, comme pour les applications mobiles, les développeurs doivent déclarer dans un manifeste de quelles autorisations ils souhaitent pouvoir bénéficier : accès au dossier personnel de l’utilisateur, à certains périphériques (webcam, micro…), à la géolocalisation… Droits que l’utilisateur est libre d’accorder ou révoquer à tout moment. Alors oui, pour un logiciel libre dans lequel l’utilisateur a toute confiance, ça n’a pas forcément grand intérêt, mais dans le cas de logiciels propriétaires, véritables boîtes noires dont on ne sait rien, ça peut tout de suite être plus intéressant.

Autre avantage important, la possibilité offerte aux développeurs de pouvoir atteindre directement l’ensemble de leurs utilisateurs sans attendre le bon vouloir des différentes distributions. Une nouvelle version vient de sortir, un Flatpak est proposé et tout le monde peut en bénéficier, sans avoir à se soucier du système de paquet utilisé par la distribution (DEB, RPM…) ou de la compatibilité des bibliothèques.

Non seulement les développeurs pourront proposer un paquet universel dès la publication de leur application, mais ce dernier pourra représenter la version idéale telle qu’ils l’ont souhaité.

Parce qu’il faut savoir que les paquets des différentes distributions sont souvent bien loin de correspondre à cet idéal. Par exemple, pour des raisons philosophiques ou juridiques, les distributions peuvent très bien désactiver certaines fonctionnalités au moment de la compilation. Des distributions comme Debian ou Fedora, qui font très attention aux quatre libertés du logiciel libre ainsi qu’aux brevets logiciels, préfèrent ainsi se passer de certaines fonctionnalités (par exemple, un algorithme qui serait protégé par un ou plusieurs brevets), plutôt que de se priver de l’application dans son ensemble. Sans parler des nombreux patchs que les distributions peuvent appliquer, dans le but de modifier volontairement le comportement de l’application. Que ces changements soient ou non positifs, l’utilisateur peut très bien préférer la vision des développeurs officiels.

Puis comme les paquets sont identiques pour tous et que les applications sont exécutées dans le même environnement, là encore identique, si l’application fonctionne bien chez le développeur, elle fonctionnera tout aussi bien chez les utilisateurs. Et si l’utilisateur rencontre un bug, ce dernier devrait être plus facilement reproductible par le développeur. Il sera donc bien plus simple d’offrir des garanties et de corriger certains problèmes.

C’est également un gain de temps pour les développeurs, qui n’auront plus à se soucier que d’un unique Flatpak, plutôt que de créer de nombreux paquets pour différentes distributions (quand ils ne se contentent pas, bien souvent, de ne viser qu’une ou deux distributions majeures, laissant les autres sur le carreau).

Alors bien sûr, on se dit que les différentes distributions ont leurs propres contributeurs pour empaqueter toutes ces applications. Mais quand on y pense, que de temps humain gaspillé à recréer tous ces paquets, chacun dans leur coin, pour les mêmes applications… Sans parler des plus petites distributions, qui n’ont pas forcément les moyens humains de gérer tout ça. Ne serait-il pas plus intéressant de pouvoir créer un paquet universel une fois pour toute, et de pouvoir ensuite se concentrer sur des tâches plus gratifiantes ou plus utiles ?

Autre avantage auquel on ne pense pas forcément, la possibilité d’installer sans risque plusieurs versions en parallèle. Que ce soit une version stable et une version de développement à des fins de test, ou une ancienne version stable qui pourrait proposer des fonctionnalités dont on a besoin mais qui auraient malheureusement été supprimées des versions plus récentes (l’évolution des logiciels que l’on utilise ne nous convient pas toujours).

La compatibilité dans le temps devrait également être renforcée. Aujourd’hui, de souhaiter utiliser de vieilles applications abandonnées par leurs développeurs (et donc non adaptées à des systèmes modernes) peut rapidement devenir compliqué, pour ne pas dire impossible pour la plupart des gens, puisque toutes les distributions n’acceptent pas forcément le risque et la charge de travail supplémentaire que représentent de vieilles applications abandonnées ou des bibliothèques obsolètes. Et si ce n’est pas géré par la distribution ou la communauté, ça implique bien souvent de devoir mettre les mains dans le cambouis et de compiler soi-même. Tandis qu’avec un Flatpak et son runtime d’époque associé (qui contient les différentes bibliothèques nécessaires à son bon fonctionnement), la distribution n’a plus besoin de s’en préoccuper.

Donc même si ça ne vous intéresse pas et que vous ne prévoyez pas de changer vos habitudes, on ne peut honnêtement pas dire que cette technologie n’a aucun intérêt (ne serait-ce que pour tout le temps que ça fait gagner aux développeurs de logiciels libres, qui travaillent bien souvent bénévolement). Tout comme il faut arrêter de penser que les distributions de type rolling release telles que Arch Linux ou Manjaro soient le Saint Graal. La première exclut tous les néophytes et la seconde, qui désactive (à raison) le dépôt communautaire AUR par défaut, n’offre donc pas forcément le même catalogue applicatif ou les mêmes versions. Et bien évidemment, en dehors de leur capacité à proposer des versions plutôt à jour, ces distributions ne règlent aucun des différents problèmes soulevés (sécurité, reproductibilité, compatibilité, gain de temps…).

Il est donc préférable de se mettre un instant à la place de l’utilisateur néophyte qui peut enfin bénéficier, à tout instant et de façon sécurisée, des dernières versions de ses applications préférées sans avoir à se soucier de toutes les questions techniques sous-jacentes, qui ne l’intéressent pas et ne l’intéresseront jamais : le choix de la distribution et du format de paquet qui en découlera, les éventuels dépôts tiers à activer (parfois gérés de façon plutôt hasardeuse, pour ne pas dire risquée), les dépendances nécessaires, l’installation d’éventuels outils de développement pour compiler soi-même et bien faire attention à chaque installation ou mise à jour à ne surtout rien casser…

La question est donc de savoir si l’on souhaite ou non démocratiser l’utilisation de GNU/Linux auprès du grand public. Et si c’est le cas, Flatpak pourrait grandement nous y aider.

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