Y a t-il un rapport de bogue Debian ouvert sur la décision de passer Firefox en mode Wayland par défaut sur les configurations Wayland?

Tags: #<Tag:0x00007f50a1e7e1d8> #<Tag:0x00007f50a1e7e110>

Bonjour,
Si je me trompe pas, Debian 10 GNOME tourne sous Wayland par défaut (https://wiki.debian.org/Wayland#Supported_environments).
En revanche, le paquet Firefox empaqueté dans Debian n’est pas configuré pour tourner nativement sous Wayland, de sorte qu’à chaque mise à jour je dois remodifier le lanceur du navigateur pour qu’il se lance en mode Wayland.
Je n’ai pas trouvé le rapport de bogue évaluant l’opportunité de configurer le paquet Firefox en mode Wayland natif sur les systèmes Wayland. Pouvez-vous m’aider à mettre la main dessus ?
Merci d’avance !

Dans ce cas ouvre le :wink:

Bonjour,

Quand on installe un iso de Debian 10 stable avec gnome, on est sur wayland par défaut et firefox esr est parfaitement fonctionnel donc pas de rapport de bug (chez moi c’est fonctionnel mais il peut y avoir un bug sur un autre type de config), donc qu’a tu installé a la base :

  1. debian free ou non free ?
  2. c’est bien un paquet empaqueté firefox esr ?
  3. qu’elle est le problème exactement ?

Pourquoi effectivement ne pas ouvrir un rapport si vraiment tu rencontres un problème

Firefox fonctionne sans pb sous GNOME Wayland, qu’il soit en mode Wayland ou X11 (via XWayland), ce n’est pas la question.
Je lance dorénavant GNOME sans XWayland car mes applis courantes sous sous Wayland.
Mais pour Firefox je dois modifier le lanceur car le paquet ne lance pas Firefox par défaut en mode Wayland.
Or ce lanceur est réécrit à chaque mise à jour, ce qui est un peu casse-pied.
Du coup j’ai cherché la discussion côté Debian quant à passer Firefox par défaut en mode Wayland sur les systèmes compatibles, sans trouver.

Est-ce que cette recherche est correctement formulée ?

Non :stuck_out_tongue:
Tout simplement parce que le paquet fourni sur Debian stable ne s’appelle pas firefox mais firefox-esr.

C’est probablement à cause de cette confusion que tu as loupé le rapport de bug qui t’intéresse : #982877 - firefox-esr: please provide an official way to run using wayland

1 J'aime

Bonjour,

Une solution de contournement serait de placer une copie du lanceur modifié dans
~/.local/share/applications

A+

1 J'aime

Ooh il est tout frais en plus, merci :slight_smile:

peux tu expliquer comment ça fonctionne STP ?
Est-ce qu’il primerait /usr/share/applications/firefox.desktop ?

Bonjour,

Je suppose que tu modifies le fichier /usr/share/applications/firefox.desktop, mais que la modif est effacée lors d’une mise à jour de Firefox ?

Si c’est le cas, une fois firefox.desktop modifié, copie-le dans le répertoire de ton utilisateur ~/.local/share/applications :
cp -v /usr/share/applications/firefox.desktop ~/.local/share/applications/

…oui, et il ne sera pas réécrit lors de mises à jour.

Note : Si tu as firefox-esr, le fichier se nomme plutôt firefox-esr.desktop, à toi de voir…

A+

Excellent, merci !

cp -v /usr/share/applications/firefox.desktop /.local/share/applications/
plutôt

Bonjour,

Pas certain, chez-moi ça donnerait ceci :

 yvan@yvan-maison:~$  cp -v /usr/share/applications/firefox.desktop /.local/share/applications/
    '/usr/share/applications/firefox.desktop' -> '/.local/share/applications/'
    cp: impossible de créer le fichier standard '/.local/share/applications/': Aucun fichier ou dossier de ce type
yvan@yvan-maison:~$

À mon avis, il faut soit inclure le tilde « ~ », qui représente /home/toto où « toto » est le nom d’utilisateur de ta session, si tu est bien positionné dans ton répertoire utilisateur, soit donner le chemin absolu : /home/toto/.local/share/applications/ :

yvan@yvan-maison:~$ cp -v /usr/share/applications/firefox.desktop ~/.local/share/applications/
'/usr/share/applications/firefox.desktop' -> '/home/yvan/.local/share/applications/firefox.desktop'
yvan@yvan-maison:~$

A+

Disons que ta commande, lancée depuis mon home, ne semblait pas marcher

Bonjour

Pour info :

Un chemin de fichier qui commence par le caractère / est un chemin absolu
sinon, c’est un chemin relatif (… relatif au répertoire courant)

Le répertoire courant est retourné par la commande

pwd

le caractère ~ est interprété par le shell bash
et remplacé (avant l’exécution de la commande)
par le chemin absolu du répertoire personnel du compte utilisateur
qui lance la commande.

C’est comme si vous utilisiez la variable d’environnement $HOME
qui est aussi un chemin absolu puisqu’il commence par le caractère /

Donc, pour un même compte utilisateur,
la ligne de commande :

echo ~

donnera le même retour que :

echo $HOME

Ces deux lignes retourneront le chemin absolu du répertoire personnel du compte utilisateur qui lancera la commande, et ce, quel que soit le répertoire courant depuis lequel elles seront lancées.


Comme ylag ne connaissait par le répertoire personnel de ton compte utilisateur,
il a (comme on le fait dans ces cas là) utilisé le caractère ~ pour que le shell bash remplace ce caractère par le chemin absolu de ton compte utilisateur.

Et sur ta machine, le shell, avant le lancer la commande cp,
a remplacé le caractère ~ par /home/yvan
ce qui fait que la ligne de commande :

cp -v /usr/share/applications/firefox.desktop ~/.local/share/applications/

lancée par ton compte utilisateur yvan dont le répertoire personnel est /home/yvan
a été automatiquement remplacée par le shell par :

cp -v /usr/share/applications/firefox.desktop /home/yvan/.local/share/applications/

Mais si tu recopies sa ligne de commande en oubliant ce caractère ~
le chemin que tu as donné comme cible de la copie n’était plus le même,
et la commande cp a cherché un répertoire /.local/share/applications/ qui n’existait pas sur ton système de fichiers.

Alors la commande cp n’a pas pu faire ce qu’on lui demandait, donc elle s’en est plaint au shell qui t’a retourné le message d’erreur suivant :

cp: impossible de créer le fichier standard '/.local/share/applications/': Aucun fichier ou dossier de ce type

Bonjour,

Merci à @MicP, qui est bien meilleur pédagogue que moi ! :slightly_smiling_face:

A+

J’y arrive parfois, … mais pas tout le temps. :slightly_smiling_face:

Ok, mais qui est Yvan ? :-p

Yvan ?
Plutôt « yvan », c’est le nom d’utilisateur de ma session :

yvan@yvan-maison:~$ echo $USER
yvan
yvan@yvan-maison:~$ whoami
yvan
yvan@yvan-maison:~$ echo ~
/home/yvan
yvan@yvan-maison:~$ echo $HOME
/home/yvan
yvan@yvan-maison:~$ 

C’est à toi de voir sur ta machine quel est le bon nom d’utilisateur de session à passer dans les chemins pour recopier un fichier d’un répertoire à un autre… :slightly_smiling_face:

Donc, chez-toi, pour recopier le fichier firefox.desktop du répertoire /usr/share/applications dans le répertoire /home/toto/.local/share/applications en utilisant les chemins absolus (ça évite les malentendus :wink: ) :

cp -v /usr/share/applications/firefox.desktop /home/toto/.local/share/applications/firefox.desktop

…où « toto » est à remplacer par ton nom d’utilisateur de la session concernée.

A+

C’est justement pour éviter d’avoir à écrire toute cette quantité de messages
et éviter ces quiproquos interminables et les conséquences désastreuses qui pourraient en découler à cause de la suite d’interprétations
qu’on utilise plutôt la variable $HOME et ~ et qu’on préfère des retours de commandes complets avec le prompt de départ et de retour et les messages d’erreur dans leur intégrité.


Donne nous le retour de la commande suivante
entrée depuis le compte utilisateur non privilégié sur ta machine :

echo $HOME

Par exemple, en retour complet, lancé sur ma machine depuis mon compte utilisateur non privilégié, ça donne :

michel@xubu:~$ echo $HOME
/home/michel
michel@xubu:~$