le problème, mineur mais bon: le 1er lancement de FF et Thb est très lent, environ 8s. Ensuite ce problème disparaît et les lancements sont très rapides
The problem turned out to be the line exec dbus-launch --exit-with-session blackbox. Using the dbus-update-activation-environment command with just exec blackbox did the trick. Now there is no delay.
Il faudrait donc que j'ajoute la ligne exec xfwm4 à l'aide de la commande dbus-update-activation-environment , soit:
Bonjour, je te déconseille de toucher à la configuration de dbus si tu ne comprends pas l'action de ta modif.
dbus est un élément essentiel du gestionnaire de bureau, utilisé par qausiment tous les logiciels.
Fait des traces pour avoir une idée plus précise du problème au lancement de firefox.
piratebab a écrit : 20 juin 2025, 08:02
Bonjour, je te déconseille de toucher à la configuration de dbus si tu ne comprends pas l'action de ta modif.
dbus est un élément essentiel du gestionnaire de bureau, utilisé par qausiment tous les logiciels.
c'est bien noté, je ne vais donc faire aucun essai de la méthode proposée.
Quant à strace ça m'a tout l'air d'être une commande pour les connaisseurs, donc je vais me contenter de tester
qui me fournira un horodatage permettant de voir si l'exécution se fige ou pas à un endroit précis.... enfin j'espère. Le problème c'est que pour faire un autre essai il faut redémarrer le système, le délai à l'ouverture de FF ne se produisant qu'une seule fois après le démarrage. Mais je vais tester si le changement d'utilisateur suffit à provoquer le phénomène. À voir.
strace est sans danger, ce qui est complexe c'est d'interpréter sa sortie.
Si tu vois un truc du genre FUTEX_WAIT, c'est qu'un programme à posé un verrou sur une ressource dont firefox à besoi,. Il faut attendre la levée de ce verrou. La difficulté est de savoir qui a posé le verrou, et sur quelle ressource.
effectivement, toutes ces lignes ne me disent rien. Une fois enregistrées et triées ça donne 38 lignes qui comportent FUTEX_WAIT, quasiment toutes avec un code retour = -1. J'ai vu, sur stackoverflow.com, que trouver les points de blocage à partir de leur adresse n'était pas une mince affaire. Vu que ce petit problème n'est guère gênant, je laisse la chose en l'état.
bon, ben voilà, problème résolu de matin... par une mise à jour du fameux dbus. C'était donc bien, au moins très probablement, le coupable, et les ceusses de stackexchange.com avaient vu juste. Une hard-freeze n'étant pas encore une stable je suis coupable d'impatience caractérisée.
Je suis quand même étonné que dans une "hard-freeze" il puisse encore y avoir autant de paquets mis à jour.
PS1: j'ai 2 trixie= une sur un ssd autonome et l'autre sur mon ancien portable LDLC. Les mises à jour ne sont pas identiques sur le ssd/trixie et sur le LDLC/trixie .Le défaut a été corrigé sur le LDLC/trixie, avec une mise à jour de dbus, mais il est toujours présent sur l'installation ssd/trixie où dbus n'a pas été mis à jour, du moins ce matin. Le problème c'est que ces mises à jours ne sont pas synchrones, avec des écarts de 1 à 3 jours, pas plus.
PS2: je viens de vérifier: Les versions 1.16.2-2 de dbus sont les mêmes, donc dbus ne doit pas être le seul responsable, son environnement doit intervenir. Y aurait-il une interaction entre dbus et je ne sais quoi dans les composants matériels ou logiciels de "ssd autonome" et de "portable LDLC" qui sont différents? c'est probable, non?
Mieux vaut attendre la version stable, Debian 13, pour comparer. C'est au moins la leçon à tirer de tout ça.
dbus est un bus virtuel lié aux applications de bureau. Il est très loin du matériel.
Tu peux utiliser la commande dbus-monitor pour regarder ce qui se passe sur les bus systeme et session. Comme tu en as un qui fonctionne et pas l'autre, tu pourras comparer.
j'ai donc utilisé cette commande.avec sortie sur fichier...pour m'apercevoir que seule une partie de la très longue sortie était enregistrée. Probablement parce que la case "défilement arrière illimité" n'était pas cochée dans les paramètres "terminal Xfce" de mon SSD. Mais finalement, un 2ème redémarrage de ce SSD a remis les choses en place: plus de retard à l'allumage pour Firefox et Thunderbird. Affaire classée donc.
Trixie de mon SSD me permet de tester le comportement de mon portable actuel pour m'assurer que le passage de Debian 12 à Debian 13 se fera sans problème. Probablement mieux, au minimum aussi bien, qu'une installation type "Debian live", non?
Le changement de version majeure de debian s'accompagne généralement aussi d'un changement majeur de version de logiciels fondamentaux de l'univers linux. On pense évidement à la libc, mais ce qui pose le plus de problème, ce sont généralement des logiciels tels que python ou php.
La mise à niveau s'accompagne généralement par l'abandon de trop vielle versions. Si des logiciels de ton systeme les utilisent, tu ne peux plus t'en servir. Mais ce n'est pas la faute de debian, mais de logiciel qui retardent trop la montée en version de leur langage de programmation.
Tu as aussi les changements majeurs de l'architecture son ou vidéo. Si tu n'y est pas préparé, le passage de pulseaudio a pipewire pourra poser problème par exemple (mais rien ne t’empêche d'y passer dés maintenant). idem pour xorg/wayland.
C'est pour ça que je suis en testing. Ces problèmes apparaissent tout au long de l'année, et pas en bloc le jour de changement de version.
piratebab a écrit : 08 juil. 2025, 08:27
.......
C'est pour ça que je suis en testing. Ces problèmes apparaissent tout au long de l'année, et pas en bloc le jour de changement de version.
sans connaître tous ces détails, je m'étais dit qu'en connectant mon [SSD/trixie] sur mon portable ça me permettrait de tester son comportement vis à vis des changements introduits par Debian 13 et ainsi de pouvoir y remédier sans toucher à Debian 12 qui fonctionne très bien. Je trouve cette solution meilleure que l'essai avec un Debian live car je peux réaliser les modifs éventuellement nécessaires sur mon SSD, jusqu'à ce que tout soit au point. Impossible avec une live, du moins telle que je l'avais testée il y a quelques années de ça. En plus ça me fait un système nomade au cas où j'en aie besoin.
merci pour toutes ces précisions.
PS: si je n'avais pas ce problème de pilote mt7902 je n'essaierai même pas de passer à Debian 13. Si une solution est publiée par les développeurs elle le sera d'abord dans ce qui va devenir un dépôt Backport de Debian 13, non?
Elle passera d'abord en SID, puis testing. Je ne sais pas si elle doit rester un peu en testing avant d'intégrer le backport.
Perso je ne met des debian stable que sur les serveurs, ou la machine destinées aux prestations live (je n'ai pas envie de tout planter en plein concert!). Partout ailleurs je suis en testing
