Planet Archlinux FR

ArchLinux, en Français

glibc 2.27-2 et pam 1.3.0-2 peuvent nécessiter une intervention manuelle

La nouvelle version de glibc supprime le support pour NIS et NIS+. Le fichier /etc/nsswitch.conf par défaut fourni par le paquet filesystem reflète déjà cette modification. Assurez-vous de fusionner le fichier pacnew s’il existe avant la mise à jour.

La fonctionnalité NIS peut toujours être activée en installant le paquet libnss_nis. Il n’y a pas de remplacement concernant NIS+ dans les dépôts officiels.

pam 1.3.0-2 n’embarque plus le module pam_unix2 et les liens symboliques de compatibilité pam_unix_*.so. Avant de mettre à jour, passez en revue les fichiers de configuration PAM dans le répertoire /etc/pam.d et remplacez les modules supprimés par pam_unix.so. Les utilisateurs de pam_unix2 devraient également réinitialiser leurs mots de passe après cette modification. Les valeurs par défaut fournies par le paquet pambase ne nécessitent pas de modifications.

Article original (en)

La mise à jour zita-resampler 1.6.0-1 -> 2 requiert une intervention manuelle

Il manquait dans le paquet zita-resampler 1.6.0-1 un lien symbolique vers une bibliothèque qui a été rajouté en 1.6.0-2. Si vous avez installé la version 1.6.0-1, ldconfig aura créé ce lien symbolique au moment de l’installation qui entrera en conflit avec celui inclus dans la version 1.6.0-2. Dans ce cas, supprimez /usr/lib/libzita-resampler.so.1 manuellement avant la mise à jour.

Article original

Fin du support i686

Après 9 mois de dépréciation, le support de l’architecture i686 prend fin aujourd’hui. À la fin de novembre, les paquets i686 seront supprimés des miroirs officiels et plus tard de l’archive des paquets. Le dépôt [multilib] n’est pas affecté.

Pour les utilisateurs qui ne sont pas en mesure de migrer vers du matériel x86_64, une alternative réside dans une branche maintenue par la communauté nommée Arch Linux 32. Consultez leur site Web pour plus de détails sur la migration d’installations existantes.

Article original

Changement de chemin de la bibliothèque Perl

Le paquet Perl utilise maintenant un chemin versionné pour les modules compilés. Cela signifie que les modules conçus pour une version Perl qui ne correspondent pas ne seront plus chargés et devront être reconstruits.

Un hook de pacman avertit des modules concernés lors de la mise à niveau en affichant comme suit:

WARNING: '/usr/lib/perl5/vendor_perl' contains data from at least 143 packages which will NOT be used by the installed perl interpreter.
-> Run the following command to get a list of affected packages: pacman -Qqo '/usr/lib/perl5/vendor_perl' (NdT: AVERTISSEMENT: '/usr/lib/perl5/vendor_perl' contient des données d'au moins 143 paquets qui ne seront PAS utilisés par l'interpréteur Perl installé.
-> Exécutez la commande suivante pour obtenir une liste des paquets affectés: pacman -Qqo '/usr/lib/perl5/vendor_perl' )

Vous devez reconstruire tous les paquets indiqués contre le nouveau paquet Perl avant de pouvoir les utiliser à nouveau. La modification affecte également les modules installés directement via CPAN. La reconstruction sera également de nouveau nécessaire avec les futures mises à jour principales de Perl, telles que 5.28 et 5.30.

Notez que la reconstruction était déjà requise lors des mises à jour majeures antérieures à cette modification, mais désormais Perl n’essayera plus de charger les modules et échouera de façon étrange.

Si le système de construction d’un logiciel ne détecte pas automatiquement le changement, vous pouvez utiliser perl -V: vendorarch dans votre PKGBUILD pour interroger Perl sur le chemin d’accès correct. Il existe également sitearch pour les logiciels qui ne sont pas préparés avec pacman.

Article original (en)

Dépréciation de l’outil ABS et point final à rsync

En raison du coût de maintenance élevé des scripts liés au Arch Build System, nous avons décidé de déprécier l’outil abs et par conséquent rsync comme moyen d’obtenir des PKGBUILDs.

L’outil asp, disponible dans [extra], offre une fonctionnalité similaire à abs. asp export pkgname peut être utilisé comme une alternative directe; Vous trouverez plus d’informations sur son utilisation dans la documentation. De plus, les sparse checkouts de Subversion, tels que décrits ici, peuvent être utilisés pour obtenir un effet similaire. Pour récupérer tous les PKGBUILD, la meilleure manière consiste à cloner les miroirs svntogit.

Tandis que le paquet extra/abs a déjà été abandonné, rsync (rsync://rsync.archlinux.org/abs) sera désactivé d’ici la fin du mois.

Article original

 

La mise à jour vers ca-certificates-utils 20170307-1 demande une intervention manuelle

La mise à jour vers ca-certificates-utils 20170307-1 demande une intervention manuelle à cause d’un lien symbolique précédement généré dans le post-install qui est maintenant géré proprement dans le paquet.

Supprimer ce lien symbolique n’est pas recommandé (cela peut entrainer des problèmes de téléchargement de paquets), et l’upgrade doit se passer en 3 étapes :

# pacman -Syuw # download packages
# rm /etc/ssl/certs/ca-certificates.crt # remove conflicting file
# pacman -Su # perform upgrade

Article original
En parler sur le forum. Si malgré tout vous avez supprimé le lien mais que l’upgrade s’est bien passée, tout devrait être bon.

Mesa avec le support de libglvnd est maintenant dans [testing]

mesa-17.0.0-3 peut maintenant être installé côte à côte avec le driver nvidia-378.13 sans aucun hack libgl/libglx, grâce au travail de Fedora et les modifications apportée à xorg-server.

    • La première étape a été de supprimer les liens symboliques entre xorg-server (ainsi que les drivers nvidia/mesa) et libglx via la suppression de divers paquets libgl. C’était une opération difficile car cela casse les systèmes avec optimus, la configuration de xorg-server demande une modification manuelle.
    • La seconde étape est maintenant là, avec un nouveau fichier 10-nvidia-drm-outputclass.conf qui devrait aider à avoir un setup xorg-server fonctionnel « out-of-the-box » pour les systèmes optimus !

Merci de tester cela de façon poussée et de poster vos retours sur le forum (en) ou sur le bugtracker.

Article original

Pour plus d’informations sur libglvnd, vous pouvez consulter la page du projet .

Suppression progressive du support i686

En raison de la popularité décroissante de l’i686 parmi les développeurs et la communauté, nous [NdT: développeurs et TU d’Arch] avons décidé de supprimer progressivement le support pour cette architecture.

Cette décision signifie que l’iso de février sera la dernière permettant d’installer Arch Linux 32 bits. Les 9 mois suivants seront une période de dépréciation, durant laquelle i686 recevra tout de même des mises à jour de paquets. À partir de novembre 2017, les outils d’empaquetage et de dépôt ne nécessiteront plus de maintenance, ce qui rendra le i686 non supporté.

Toutefois, comme il y a encore un intérêt à maintenir le i686 en vie, nous [NdT: développeurs et TU d’Arch] aimerions encourager la communauté à le faire avec nos conseils. La liste de diffusion arch-ports et le canal IRC sur Freenode, #archlinux-ports, seront utilisés pour une coordination ultérieure.

Le dépôt [multilib] ne sera pas affecté par cette modification.

xorg-server 1.19.1 est à présent dans extra

La nouvelle version s’accompagne des modifications suivantes:

  • xf86-input-libinput est le pilote d’entrée par défaut, synaptics, evdev et wacom restent cependant disponibles.
  • Les paquets suivants sont dépréciés et déplacés sur AUR: xf86-input-joystick, xf86-input-acecad, xf86-video-apm, xf86-video-ark, xf86-video-chips, xf86-video-glint, xf86-video-i128, xf86-video-i740, xf86-video-mach64, xf86-video-neomagic, xf86-video-nv, xf86-video-r128, xf86-video-rendition, xf86-video-s3, xf86-video-s3virge, xf86-video-savage, xf86-video-siliconmotion, xf86-video-sis, xf86-video-tdfx, xf86-video-trident, xf86-video-tseng.

Article original

La mise à jour d’OpenVPN 2.4.0 requiert une intervention administrateur

La mise à jour vers OpenVPN 2.4.0 apporte des modifications incompatibles avec les configurations précédentes. Faites très attention si vous dépendez de la connectivité VPN pour l’accès à distance ! Une intervention administrative est requise:

  • La configuration est désormais attendue dans des sous-répertoires. Déplacez vos fichiers depuis /etc/openvpn/ vers /etc/openvpn/server/ ou /etc/openvpn/client/.
  • Le chemin de recherche du plugin a changé, supprimez plugins/ des chemins relatifs.
  • L’unité systemd openvpn@.service a été remplacée par openvpn-client@.service et openvpn-server@.service. Redémarrez et réactivez en conséquence.

Ceci n’affecte pas la fonctionnalité de networkmanager, connman ou qopenvpn.

Article original