/e/'s Notes app can export local notes to .md files. However, it encodes the timestamp as a -YYYYMMDD-HHMMSS suffix on the file name. This is fair enough as dates and times can be unreliable on certain devices and over copies, but it's a bit annoying when "importing" them back (see below). To fix this, I did the following on my computer's Nextcloud sync:

find . -type f -name '*-*-*.md' | sed -r 's/^(.*)-([0-9]{4})([0-9]{2})([0-9]{2})-([0-9]{2})([0-9]{2})([0-9]{2}).md/\2-\3-\4 \5:\6:\7 \1/' | while read -r d t f ; do
  p="$f-$(echo "$d" | tr -d -)-$(echo "$t" | tr -d :).md"
  f="$f.md"
  # update the date and time
  touch -d "$d $t" "$p"
  # move to the un-suffixed name
  mv -v "$p" "$f"
done

I certainly won't win any beauty or quality contest with this code, but this was enough for Nextcloud and the Notes app to pick it up, yay!

Note that the Notes app is a bit silly about backups: it allows to export local notes, but not to import them back. Only solution for doing so is either to re-create them manually (even though I could open each file separately read-only, I couldn't even find a solution to import them one by one), or use some "Murena" account (so either a "true" murena.io, or another Nextcloud host). I did the latter because I have access to a Nextcloud instance already, but I don't quite like the tie-in to a cloud provider -- especially when you can export them already, so there ought to be a no-so-complicated way of importing, doesn't it?
I'm not blaming this on Murena just yet because Notes is a fork of Nextcloud Notes, which might not have the feature itself -- but still, sad.

Si vous avez envie de regarder sous le capot et vous impliquer dans le développement d’une distribution Linux c’est le moment de participer aux tests.
Mageia a publié une première version alpha en décembre 2025, la version bêta est désormais disponible et une version candidate est envisagée pour mars/avril 2026 pour publication de Mageia 10 « quand ce sera prêt », l’occasion de revenir sur les différentes étapes et l’implication possible.

Pour l’apparence de la distribution, un concours artistique a été lancé du 29 janvier au 25 février 2026, la participation des plus graphistes d’entre vous est la bienvenue ! Le choix pour la Mageia 10 va bientôt être fait, il reste toujours quelques points à améliorer par la suite ;-)

Bref, une version 10 de Mageia qui s’inscrit dans la continuité de la stabilité de Mageia 9 : le cycle de publication est là pour l’avérer, il y aura des pleurs, des cris et de grandes joies à réussir à faire fonctionner au mieux vos logiciels de prédilection.

Sommaire

• Cycle alpha : reprise de publication
• Cycle bêta : consolidation des tests et des choix pour la version à publier
• Cycle version candidate : finalisation
• Version finale
• Différences de fonctionnement entre version stable et le cycle de publication.
• S’impliquer pour Mageia 10
• Exemples d’utilisations

Pour cette dépêche, le parti pris est de privilégier les annonces en français. Pour autant, le suivi effectif est à faire en anglais (ensuite décliné au besoin en français).

• Blog Mageia en anglais
• Notes de version Mageia 10 en anglais
• Errata pour Mageia 10 en anglais à consolider au fur et à mesure des évolutions, les corrections effectuées seront archivées à publication de la version

Quelques sujets pris en compte pour Mageia 10 :

• choix du noyau Linux 6.18.x qui est une version LTS
• live ISO 64 bits en 3 versions : KDE, GNOME et XFCE
• conservation d’une version 32 bits (i686 et non plus i586), nécessitant des tests et une définition du périmètre, un live ISO basé sur XFCE
• Wayland par défaut pour GNOME, éventuellement (à tester) pour Plasma KDE et autres environnements le proposant, marquant la résorption de Xorg lorsque possible ; plusieurs compositeurs Wayland pour LXQt sont intégrés (Labwc, niri, hyprland, sway)
• bon fonctionnement de l’infrastructure de mise à jour via URPMI, basé sur RPM ou DNF
• Peaufinement de l’intégration des pilotes libres de GPU pour Intel et AMD ; pour les pilotes nVidia ça va être plus compliqué :/
• des mises à jour de vos logiciels préférés (n’hésitez pas à les préciser en commentaire)

Voici les différents cycles et les choix envisageables restant à chaque étape.

Cycle alpha : reprise de publication

Objectif : stabilisation du périmètre envisagé, identification des montées de version de logiciels restant à faire lors du cycle de publication.

Cela permet d’avoir des premiers ISO installables, et de revoir les plannings respectifs de ce qui est à intégrer : des langages (Rust, Ruby…), des logiciels (FreeCAD 1.1 en février donc plutôt lors de la bêta…).

Premières personnes à tester généralement issues de Cauldron—la version de développement en rolling-release—dont l’installation a pour objectif d’avérer la cohérence de l’installation et d'identifier sur le bugzilla les bogues bloquants ce qui en permet le suivi lors de chacun des cycles. Une version plus jolie des bogues bloquants est disponible, même s’ils restent à corriger ;-)

Les arborescences de dépôt 10 sont créées sur les miroirs, pour permettre de gérer l’ajout de nouveaux miroirs au fur et à mesure. Pendant tout le cycle de publication, le fonctionnement est similaire à ce qui se passe en cauldron : l’arborescence release/ reçoit les mises à jour de paquets, rien dans updates/.
Le changement des dépôts de cauldron à 10 est nécessaire pour ne pas rester avec la version de développement une fois Mageia 10 officiellement publiée ; une réinstallation reste préconisée pour ne pas avoir de reliquat des bogues corrigés lors du cycle de publication (même si enlever les différentes versions de noyaux et de bibliothèques permet de faire un 1^er ménage, il peut y avoir des reliquats de configuration intermédiaire qui perdurent).

Cycle bêta : consolidation des tests et des choix pour la version à publier

Objectif : stabilisation des versions de logiciels envisagées, identification des correctifs à l’installeur.

Lancement du concours de visuels pour fonds d’écrans de Mageia 10, icônes et économiseurs : du 30 janvier 2026 au 25 février 2026. C’est la bêta2 qui vous fera découvrir la nouvelle apparence retenue pour Mageia 10.

Les pilotes nvidia posant des problèmes récurrents, il est envisagé de ne pas proposer leur intégration aux ISO (ils seraient à installer par la suite). Les tests sont les bienvenus. La version nvidia470 peut encore être configurée après installation initiale : elle est conservée pour les anciennes cartes graphiques—même si elle n’est plus maintenue tandis que la version 390 est obsolète et ne fonctionne plus avec les nouveaux noyaux Linux—et les versions nvidia580 et nvidia590 sont proposées (paquets nvidia-current_all et nvidia-newfeature-all permettant l’ajout des modules dkms), ainsi que le pilote ne fonctionnant qu’à partir des versions de cartes RTX. C’est le pilote nouveau qui est utilisé par défaut lors de l’installation initiale.

Les pilotes graphiques libres de AMD et Intel ont bien sûr aussi été mis à jour, ils sont disponibles directement dans les ISO live d’installation.

Les tests pour Plasma KDE avec la gestion par Wayland permettront d’identifier l’opportunité de proposer Wayland par défaut, le choix alternatif de Xorg restant disponible.

L’utilisation de clé USB persistante (fonctionnalité apparue avec Mageia 7) pourrait permettre d’avoir sur soi une clé d’installation live à jour et bénéficiant des derniers correctifs : démarrage avec clé USB live sur PC à installer, premiers diagnostics de bon fonctionnement du matériel sans installation—utilisation de la partition persistante pour prendre des notes—  afin de lancer l’installation dans les meilleures conditions, bénéficiant des correctifs de l’installeur notamment.

Par exemple, selon la date de publication de FreeCAD 1.1—prévue initialement courant février 2026—il pourrait être disponible dans les dépôts de paquet de Mageia 10 (pas sur les ISO, il n’y a déjà plus beaucoup de place :D).

Cycle version candidate : finalisation

Objectif : pré-version de la version finale, à publier « quand c’est prêt »

C’est l’occasion de finaliser les différentes documentations de Mageia 10.
Les errata ne conservent que ce qui n’a pas pu être corrigé avant publication et nécessitant une intervention manuelle, ils seront tenus à jour après publication pour les cas spécifiques découverts après coup lors d’une utilisation plus large de la distribution.
Les Notes de version ne vont plus évoluer beaucoup, permettant de stabiliser les traductions dans d’autres langues que l’anglais qui reste la référence.

Version finale

Les miroirs pour les paquets peuvent être mis à jour avec la version 10 : l’arborescence release/ ne va plus évoluer et les mises à jour de paquets arrivent dans updates/.

Peaufinement des visuels retenus pour la version 10.

La notification pour proposer de monter automatiquement de version de distribution à partir de Mageia 9 interviendra un peu de temps après la sortie de la version finale : le temps de finir de les mises à jour pour clore les bogues non encore corrigés pour la version finale.

Différences de fonctionnement entre version stable et le cycle de publication.

Le cycle de publication s’appuie sur Cauldron, la version en développement continu ou rolling-release :

• il n’y a pas d’updates/ : les paquets sont directement remplacés dans release/
• un corollaire est que lors d’une mise à jour d’un ensemble de paquets (correction), les miroirs ne seront pas forcément complètement à jour, ce qui peut demander une relance de urpmi --auto-update pour mise à jour complète : en cas d’échec temporaire, une relance plus tard est nécessaire
• ce genre de désynchronisation arrive peu souvent en version stable, un peu plus souvent en Cauldron—ce qui est normal (cela se fait particulièrement sentir lors d’une reconstruction en masse) ;-)

S’impliquer pour Mageia 10

À vous de décider ce que vous souhaitez faire ;-) En comprenant que c’est une version en évolution—certaines choses ne fonctionneront pas—et certaines pourront être corrigées pour la version finale (ou peu après :D). De quoi se mettre le pied à l’étrier pour la version suivante : nouveaux logiciels à (faire) empaqueter, nouvelles versions à prendre en compte…
C’est l’occasion de s’astreindre à lancer certaines applications à partir d’un terminal pour récupérer le maximum de logs possibles, ou d’apprendre à diagnostiquer une configuration spécifique causant des soucis—idéalement pour travailler en amont (upstream) pour faire prendre en compte des correctifs et améliorations.

Vous pouvez vous coordonner en français auprès de nos collègues de MLO pour effectuer au mieux vos remontées d’information.

Rien que les tests permettent de bénéficier de versions actualisées par rapport à Mageia 9 et remonter des bugs restant dans l’intégration de vos logiciels de prédilection à l’environnement de bureau de votre choix. Il y a aussi beaucoup de traductions à effectuer.

C’est l’opportunité de (re-)lire les documentations et les actualiser, notamment les nouvelles fonctionnalités.

Exemples d’utilisations

Je vous laisse ajouter des cas d’utilisation qui vous seraient spécifiques en commentaires.
J’ai la chance de participer à un fablab qui me donne accès à divers matériels pour tester :

• EeePC ne fonctionnant pas en x86_64 (donc i686 maintenant), netbooks hybrides (tablette tactile + clavier détachable) limités à 2 Go de RAM et un UEFI 32 bits exotique même quand le processeur gère le x86_64
• (très) vieux portables et ordis—pour la plupart des gens, vieux = plus de 5 ans—là, c’est plutôt (l’ami de Mickey<) de la période 2008-2014 : des MacBook Pro, des iMac, plein de core2duo / Athlon (ça c’est du x86_64 au moins) ou cartes nvidia déclarées obsolètes (des quadro à l’époque réputées de qualité professionnelle, on voit ce que ça veut dire pour nvidia… :/)
• (très) vieux périphériques : gamepad Sidewinder, volant MT Logic wheel pour supertuxkart avec connectique broche DA-15 jaune (si vous avez d’autres périphériques—préférentiellement en USB—je suis preneur _o/ et, oui, c’est pas loin de Paris…)
• quelques Raspberry Pi et assimilés—donc architecture ARM—mais ce n’est pas l’axe principalement retenu pour Mageia 10 :/ et pour le coup, Debian reste une valeur sûre pour la diversité des logiciels disponibles, même si des travaux communs avec le projet Fedora permettent de se tenir à niveau ;-)

Et bien sûr, des logiciels classiques dans un fablab qui fonctionnent bien (plutôt en flatpak) : Cura et Bambustudio pour l’impression 3D, IDE Scratch pour robots Thymio… et Inkscape / FreeCAD / KiCAD sur du matériel un peu plus récent et moins contraint en ressources ;-)

Si vous utilisez des window managers spécifiques, cela m’intéresse d’avoir des retours aussi (enlightenment, LXQt, WindowMaker… autres ?), Mageia proposant des installations cohérentes (intégration environnement, logiciels…) via les méta-paquets task- qui permettent d’installer un ensemble de dépendances automatiquement.

Bons tests _o/