C’est un programme en flatpak, qui fonctionnait bien jusqu’à la semaine passée.
Les tentatives de lancement échouent sur ce message :
$ flatpak run org.frescobaldi.Frescobaldi
bwrap: Can’t mkdir /etc/debuginfod: Read-only file system
Mais « debuginfod » n’existe pas.
Qu’est « bwrap » ?
J’ai désinstallé et réinstallé. Avant cette action, j’avais un autre message d’erreur, ne pouvant créer un fichier pkcs11.conf dans /etc/pkcs11/ lequel existe mais est vide.
C’est évidemment cette ligne qui détient probablement le secret 
bwrap = un truc style « wrap per », en bon français, un truc qui enrobe… C’est en fait un machin qui sert à lancer effectivement la commande voulue (ici frescobaldi) dans un environnement adéquat pour le flatpak.
Il est dit précisément que le-dit wrappeur n’arrive pas à écrire dans /et/debuginfod, constaté en lecture seule. Il y a visiblement un problème de droit. (chez moi) Pour ce que j’en vois une application utilisateur n’a pas le droit d’y écrire.
Et le mien (frescobaldi), ne cherche visiblement pas à le faire.
Plusieurs choses utiles pour les flatpaks :
1/ Bien utiliser le mode d’installation « user », toutes les installations se font via
flatpake install --user flatpak-voulu
2/ Installer l’application flatpak utilitaire Flatseal, qui permet de vérifier les droits accordés aux flatpaks
3 / Installer l’application flatpak utilitaire Warehouse, qui permet de mieux gérer les versions installées (ou le nettoyage)
PS :
Frescobaldi org.frescobaldi.Frescobaldi 3.3.0 stable user
Après petite recherche complémentaire, a priori debuginfod provient d’un paquet utilité uniquement utile pour le deboguage. Il peut être retiré sans souci
apt-get remove --purge libdebuginfod1
Peut-être que ça élimine le souci…
Après pas mal de pérégrinations, voici ce que donne le dernier test en cours.
Le commutateur « –user » n’est pas accepté
michel@michel:~$ flatpak install --user org.frescobaldi.Frescobaldi
Looking for matches…
error: No remote refs found similar to ‘org.frescobaldi.Frescobaldi’
Sans ce commutateur, il reconnaît que l’installation a été faite :
michel@michel:~$ flatpak install org.frescobaldi.Frescobaldi
Looking for matches…
Skipping: org.frescobaldi.Frescobaldi/x86_64/stable is already installed
Tentative de lancement :
michel@michel:~$ flatpak run org.frescobaldi.Frescobaldi
bwrap: Can’t mkdir /etc/debuginfod: Read-only file system
michel@michel:~$
« debuginfod » n’existe pas… après suppression par :
apt-get remove --purge libdebuginfod1 fait antérieurement au test.
Tentative avec Flagseal : installation sans souci ; puis :
michel@michel:~$ flatpak run com.github.tchx84.Flatseal
bwrap: Can’t mkdir /etc/lvm: Read-only file system
michel@michel:~$
On n’en sort pas…
NB1 : les programmes Flatpak ont des noms à rallonge, désagréables à utiliser.
NB2 : j’ai une solution de repli sur mon ordinateur portable, sur lequel Frescobali fonctionne, mais il serait préférable que l’ordinateur principal (un NUC et un grand écran) soit fonctionnel.
Tu as besoin du flatpak.
Sinon, il est dans les dépôts :
apt install frescobaldi
en supprimant auparavant le flatpak
a) quelle versions ? (système / flatpak …)
a’) petite imprécision de ma part je pense : c’est le flathub qui doit être installé en user. En gros, seul l’utilisateur est capable de voir le magasin flathub. Admin/root n’est pas capabel de le voir donc d’installer des flatpaks. C’est réservé utilisateur.
b) la répétition des read only est intriguante … Il peut y avoir un autre souci plus général. J’ai eu ça récemment mais c’est pas le contexte ici je pense…
Normalement un problème de droit c’est plutôt « Permission denied » pas system read only. Ça c’est montage système de fichier, plus bas niveau que le problème flatpak apparent
Ps : c’est dans ces cas là que l’assistance à distance via dwservice est bien pratique
Lann : Frescobaldi ne fonctionne pas en installation ordinaire, non flatpak. Il y a un message d’erreur de compétition avec un autre logiciel. J’avais essayé autrefois…
MQCV, version :
$ flatpak --version
Flatpak 1.12.7
Ce matin, pas de lancement par la méthode « officielle » :
$ flatpak run org.frescobaldi.Frescobaldi
par contre, à tout hasard, « $frescobaldi » fonctionne !!
Cela donne :
$ frescobaldi
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
michel@michel:~$
Pas de message en console, le programme est parfaitement fonctionnel.
Problème résolu … pour le moment.
Que donne la commande
which frescobaldi
ça devrait être :
/usr/bin/frescobaldi
apt-cache policy frescobaldi serait intéressant également
Le problème n’est pas réglé, simplement contourné.
PS : La mise à jour de flatpak est l’un des rares motifs de mise à jour (pour moi), mais je doute que ce soit si important ici.
La version flatpak frescobaldi peut être significative (dans l’éventualité où le cloisonnement serait mal réglé, mais c’est plutôt rare également)
Comme nous n’avons pas d’explication (pour le moment) je suis d’accord avec toi : le problème est contourné, pas résolu.
C’est aussi le souci du côté snap, en plus de flatpak, ces techniques sont encore jeunotes.
michel@michel:~$ which frescobaldi
/usr/bin/frescobaldi
michel@michel:~$ apt-cache policy frescobaldi
frescobaldi:
Installé : 3.2+ds1-1~ubuntu0.22.04.1
Candidat : 3.2+ds1-1~ubuntu0.22.04.1
Table de version :
*** 3.2+ds1-1~ubuntu0.22.04.1 500
500 fr.archive.ubuntu.com / ubuntu.lafibre.info jammy-updates/universe amd64 Packages
500 fr.archive.ubuntu.com / ubuntu.lafibre.info jammy-updates/universe i386 Packages
100 /var/lib/dpkg/status
3.1.3+ds1-1 500
500 fr.archive.ubuntu.com / ubuntu.lafibre.info jammy/universe amd64 Packages
500 fr.archive.ubuntu.com / ubuntu.lafibre.info jammy/universe i386 Packages
michel@michel:~$
Pourquoi http://fr;Index of /ubuntu devient :
fr.archive.ubuntu.com / ubuntu.lafibre.info jammy/universe
(le ‹ ; › c’est exprès pour empêcher le changement).
NB : autrefois, un clic sur un fichier « .ly » lançait Frescobaldi.
Actuellement, c’est impossible. Il faut lancer Fresco en console, puis aller chercher le fichier « ly » souhaité.
Un clic sur l’icône du programme est tout aussi inactive.
Doit y avoir un problème plus profond dans votre installation flatpak…
Les associations de fichiers sont correctement gérées en flatpak (je viens de tester). Un .ly lance automatiquement frescobaldi.
Très étrange le résultat apt-cache policy, pas très orthodoxe, cf :
frescobaldi:
Installé : 3.2+ds1-1~ubuntu0.22.04.1
Candidat : 3.2+ds1-1~ubuntu0.22.04.1
Table de version :
3.3.0+ds1-2 500
500 http://archive.ubuntu.com/ubuntu mantic/universe amd64 Packages
*** 3.2+ds1-1~ubuntu0.22.04.1 990
990 http://archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages
100 /var/lib/dpkg/status
3.1.3+ds1-1 990
990 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
NB / Perso j’ai éliminé le fr. et je maintiens un source.list strictement /quasi/ standard.
deb [trusted=yes] http://archive.ubuntu.com/ubuntu/ jammy main restricted universe multiverse
deb [trusted=yes] http://archive.ubuntu.com/ubuntu/ jammy-security main restricted universe multiverse
#
deb [trusted=yes] http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted universe multiverse
Et je n’en sors pas.
La jeunesse des technos n’est plus en cause. C’est plutôt l’historique « dans » une machine donnée qui explique très souvent les problèmes.
Sur ma 22.04, j’ai les deux frescobaldi correctement opérationnels. Merci pour les tests induits
Pas compris pour le « ; »
Ce ‹ ; › dans l’URL est une erreur volontaire,elle a pour but d’empêcher :
http://archive;ubuntu.com/ubuntu
de devenir :
fr.archive.ubuntu.com / ubuntu.lafibre.info
avec affichage de « la fibre » en fin de l’URL.
Ce n’est pas ce que je souhaitais afficher…
Michel,
Tu peux utiliser l’icône 
dans l’éditeur de message pour signaler un bloc de texte (code, sortie de terminal…) sans formatage.
Vincent, merci ; j’avais oublié où cela était, n’écrivant que des messages de texte depuis un bon moment.