• =?ISO-8859-1?Q?D=E9lai_de_25_secondes?=

    From Seb@21:1/5 to All on Thu Nov 9 11:50:01 2023
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    Bonjour !


    J'ai installé hier une Debian 12 en remplacement d'une Debian plus
    ancienne. C'est une installation à partir de zéro, pas une mise à jour.

    Mon gestionnaire de fenêtres est fvwm.

    Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian précédente, j'avais remarqué le même délai avec firefox depuis quelques mois
    seulement. Je n'ai pas souvenir que pavucontrol ou xdaliclock ait posé le
    même problème dans la Debian que j'utilisais précédemment.

    Les autres programmes s'ouvrent sans délai (gimp, brave-browser, okular,
    etc.).

    Quand j'appelle "strace pavucontrol", les messages cessent de défiler en arrivant à la dernière des lignes copiées-collées ci-dessous :

    [...]
    eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 11
    futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)
    futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0
    write(10, "\1\0\0\0\0\0\0\0", 8) = 8
    futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1
    poll([{fd=11, events=POLLIN}], 1, 25000

    Sitôt le délai (25000) passé, pavucontrol s'ouvre.

    Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins
    d'une direction dans laquelle chercher ?


    Merci pour vos conseils !
    Seb.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Erwan David@21:1/5 to All on Thu Nov 9 13:10:01 2023
    Le 09/11/2023 à 11:34, Seb a écrit :

    Bonjour !


    J'ai installé hier une Debian 12 en remplacement d'une Debian plus
    ancienne. C'est une installation à partir de zéro, pas une mise à jour.

    Mon gestionnaire de fenêtres est fvwm.

    Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian précédente, j'avais remarqué le même délai avec firefox depuis
    quelques mois seulement. Je n'ai pas souvenir que pavucontrol ou
    xdaliclock ait posé le même problème dans la Debian que j'utilisais précédemment.

    Les autres programmes s'ouvrent sans délai (gimp, brave-browser,
    okular, etc.).

    Quand j'appelle "strace pavucontrol", les messages cessent de défiler
    en arrivant à la dernière des lignes copiées-collées ci-dessous :

    [...]
    eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 11
    futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN
    (Resource temporarily unavailable)
    futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0
    write(10, "\1\0\0\0\0\0\0\0", 8)        = 8
    futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1
    poll([{fd=11, events=POLLIN}], 1, 25000

    Sitôt le délai (25000) passé, pavucontrol s'ouvre.

    Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins d'une direction dans laquelle chercher ?


    Merci pour vos conseils !
    Seb.

    Là il attend un évènement sur le file descripteur 11, il faudrait
    repérer au dessus un appel open (ou nom approchant) que retourne 11 pour
    voir à quelle ressource ça correspond

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?S=C3=A9bastien_NOBILI?=@21:1/5 to All on Thu Nov 9 13:10:01 2023
    Bonjour,

    Le 2023-11-09 12:59, Erwan David a écrit :
    Le 09/11/2023 à 11:34, Seb a écrit :
    poll([{fd=11, events=POLLIN}], 1, 25000

    Sitôt le délai (25000) passé, pavucontrol s'ouvre.

    Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins
    d'une direction dans laquelle chercher ?

    Là il attend un évènement sur le file descripteur 11, il faudrait
    repérer au dessus un appel open (ou nom approchant) que retourne 11
    pour voir à quelle ressource ça correspond

    On doit pouvoir le trouver aussi en lançant cette commande :

    ls -l /proc/$(pidof pavucontrol)/fd

    À condition qu'il n'y ait qu'un seul pavucontrol en fonctionnement.

    Sébastien

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Basile Starynkevitch@21:1/5 to Seb on Thu Nov 9 15:30:01 2023
    On 11/9/23 15:12, Seb wrote:

    Bonjour,


    poll([{fd=11, events=POLLIN}], 1, 25000
    Là il attend un évènement sur le file descripteur 11, il faudrait
    repérer au dessus un appel open (ou nom approchant) que retourne 11
    pour voir à quelle ressource ça correspond

    J'ai redirigé la sortie de strace vers un fichier "trace".
    Ensuite:

    ~/temp> egrep 'poll.*fd=11|^open.*= 11' trace | cat -n
         1    poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
         2    poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
         3    poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
         4    poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
         5    poll([{fd=11, events=POLLIN}], 1, 25000) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
         6    openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache",
    O_RDONLY) = 11
         7    openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
         8    openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so",
    O_RDONLY|O_CLOEXEC) = 11
         9    openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so", O_RDONLY|O_CLOEXEC)
    = 11
         [...]

    C'est le "poll" de la ligne 5 qui bloque.

    Je ne vois donc pas d'openat renvoyant 11 dans les lignes qui le
    précèdent.


    Je devine qu'un processus (j'ignore lequel) a appellé eventfd, qui est
    très utile mais spécifique à Linux:

    https://man7.org/linux/man-pages/man2/eventfd.2.html


    Peut-être qu'il serait utile de télécharger le code source de
    pavucontrol https://freedesktop.org/software/pulseaudio/pavucontrol/ et
    d'y chercher les appels à eventfd.


    Sinon, un rapport de bogue sur https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues pourrait
    être utile.



    ls -l /proc/$(pidof pavucontrol)/fd

    Cela donne, pendant le chargement de pavucontrol :

    ls -l /proc/$(pidof pavucontrol)/fd
    total 0
    lrwx------ 1 seb seb 64 Nov  9 16:07 0 -> /dev/pts/11
    lrwx------ 1 seb seb 64 Nov  9 16:07 1 -> /dev/pts/11
    lrwx------ 1 seb seb 64 Nov  9 16:07 10 -> 'anon_inode:[eventfd]'
    lrwx------ 1 seb seb 64 Nov  9 16:07 11 -> 'anon_inode:[eventfd]'
    lrwx------ 1 seb seb 64 Nov  9 16:07 2 -> /dev/pts/11
    lrwx------ 1 seb seb 64 Nov  9 16:06 3 -> 'socket:[443606]'
    lrwx------ 1 seb seb 64 Nov  9 16:07 4 -> 'anon_inode:[eventfd]'
    lrwx------ 1 seb seb 64 Nov  9 16:07 5 -> 'socket:[444861]'
    lrwx------ 1 seb seb 64 Nov  9 16:07 6 -> 'socket:[440203]'
    lrwx------ 1 seb seb 64 Nov  9 16:07 7 -> 'anon_inode:[eventfd]'
    lrwx------ 1 seb seb 64 Nov  9 16:07 8 -> 'anon_inode:[eventfd]'
    lrwx------ 1 seb seb 64 Nov  9 16:07 9 -> 'socket:[444862]'

    man proc a quelques infos sur "anon_inode:[eventfd]", mais ça ne m'avance pas beaucoup :

                  For file descriptors that have  no  corresponding inode 
    (e.g.,
                  file    descriptors   produced   by   bpf(2),
    epoll_create(2),
                  eventfd(2),  inotify_init(2),  perf_event_open(2),
    signalfd(2),
                  timerfd_create(2), and userfaultfd(2)), the entry will
    be a sym-
                  bolic link with contents of the form

                      anon_inode:file-type

                  In many cases (but not all),  the  file-type  is
    surrounded  by
                  square brackets.

                  For  example, an epoll file descriptor will have a
    symbolic link
                  whose content is the string anon_inode:[eventpoll].

    man 2 eventfd parle d'un mécanisme d'attente :

           eventfd()  creates  an  "eventfd  object"  that can be used as
    an event
           wait/notify mechanism by user-space applications, and by the kernel  to
           notify  user-space  applications of events.

    Cela ne m'avance guère.

    Quelqu'un sait-il donner du sens à tout cela ?


    Pour ma part, je cherche des contributeurs pour le moteur d'inférences http://refpersys.org/ (avec code en
    https://github.com/RefPerSys/RefPerSys/ ....)


    Dans quelque temps (j'espère quelques mois) RefPerSys pourrait aider à chasser ce genre de bogue.


    Librement

    --
    Basile Starynkevitch
    <basile@starynkevitch.net>
    (only mine opinions / les opinions sont miennes uniquement)
    92340 Bourg-la-Reine, France
    web page: starynkevitch.net/Basile/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Seb@21:1/5 to All on Thu Nov 9 15:20:01 2023
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    Bonjour,


    poll([{fd=11, events=POLLIN}], 1, 25000
    Là il attend un évènement sur le file descripteur 11, il faudrait
    repérer au dessus un appel open (ou nom approchant) que retourne 11
    pour voir à quelle ressource ça correspond

    J'ai redirigé la sortie de strace vers un fichier "trace".
    Ensuite:

    ~/temp> egrep 'poll.*fd=11|^open.*= 11' trace | cat -n
    1 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
    2 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
    3 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
    4 poll([{fd=11, events=POLLIN}], 1, 25000) = 1 ([{fd=11, revents=POLLIN}])
    5 poll([{fd=11, events=POLLIN}], 1, 25000) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
    6 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache", O_RDONLY) = 11
    7 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
    8 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so", O_RDONLY|O_CLOEXEC) = 11
    9 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so", O_RDONLY|O_CLOEXEC) = 11
    [...]

    C'est le "poll" de la ligne 5 qui bloque.

    Je ne vois donc pas d'openat renvoyant 11 dans les lignes qui le précèdent.

    ls -l /proc/$(pidof pavucontrol)/fd

    Cela donne, pendant le chargement de pavucontrol :

    ls -l /proc/$(pidof pavucontrol)/fd
    total 0
    lrwx------ 1 seb seb 64 Nov 9 16:07 0 -> /dev/pts/11
    lrwx------ 1 seb seb 64 Nov 9 16:07 1 -> /dev/pts/11
    lrwx------ 1 seb seb 64 Nov 9 16:07 10 -> 'anon_inode:[eventfd]'
    lrwx------ 1 seb seb 64 Nov 9 16:07 11 -> 'anon_inode:[eventfd]'
    lrwx------ 1 seb seb 64 Nov 9 16:07 2 -> /dev/pts/11
    lrwx------ 1 seb seb 64 Nov 9 16:06 3 -> 'socket:[443606]'
    lrwx------ 1 seb seb 64 Nov 9 16:07 4 -> 'anon_inode:[eventfd]'
    lrwx------ 1 seb seb 64 Nov 9 16:07 5 -> 'socket:[444861]'
    lrwx------ 1 seb seb 64 Nov 9 16:07 6 -> 'socket:[440203]'
    lrwx------ 1 seb seb 64 Nov 9 16:07 7 -> 'anon_inode:[eventfd]'
    lrwx------ 1 seb seb 64 Nov 9 16:07 8 -> 'anon_inode:[eventfd]'
    lrwx------ 1 seb seb 64 Nov 9 16:07 9 -> 'socket:[444862]'

    man proc a quelques infos sur "anon_inode:[eventfd]", mais ça ne m'avance
    pas beaucoup :

    For file descriptors that have no corresponding inode (e.g.,
    file descriptors produced by bpf(2), epoll_create(2),
    eventfd(2), inotify_init(2), perf_event_open(2), signalfd(2),
    timerfd_create(2), and userfaultfd(2)), the entry will be a sym-
    bolic link with contents of the form

    anon_inode:file-type

    In many cases (but not all), the file-type is surrounded by
    square brackets.

    For example, an epoll file descriptor will have a symbolic link
    whose content is the string anon_inode:[eventpoll].

    man 2 eventfd parle d'un mécanisme d'attente :

    eventfd() creates an "eventfd object" that can be used as an event
    wait/notify mechanism by user-space applications, and by the kernel to
    notify user-space applications of events.

    Cela ne m'avance guère.

    Quelqu'un sait-il donner du sens à tout cela ?

    Ou pense à une piste complètement différente pour donner sens à ces
    25 secondes d'attente ?


    Merci !
    Seb.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pierre-Elliott =?utf-8?Q?B=C3=A9cue@21:1/5 to Seb on Thu Nov 9 15:40:01 2023
    Seb <seb@h-k.fr> wrote on 09/11/2023 at 11:34:11+0100:

    Bonjour !


    J'ai installé hier une Debian 12 en remplacement d'une Debian plus
    ancienne. C'est une installation à partir de zéro, pas une mise
    à jour.

    Mon gestionnaire de fenêtres est fvwm.

    Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian précédente, j'avais remarqué le même délai avec firefox depuis
    quelques mois seulement. Je n'ai pas souvenir que pavucontrol ou
    xdaliclock ait posé le même problème dans la Debian que j'utilisais précédemment.

    Les autres programmes s'ouvrent sans délai (gimp, brave-browser,
    okular, etc.).

    Quand j'appelle "strace pavucontrol", les messages cessent de défiler
    en arrivant à la dernière des lignes copiées-collées ci-dessous :

    [...]
    eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 11
    futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN
    (Resource temporarily unavailable)
    futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0
    write(10, "\1\0\0\0\0\0\0\0", 8) = 8
    futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1
    poll([{fd=11, events=POLLIN}], 1, 25000

    Sitôt le délai (25000) passé, pavucontrol s'ouvre.

    Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins d'une direction dans laquelle chercher ?

    Si tu as la flemme de débugger, j'imagine que tu as actuellement
    pulseaudio d'installé. Tu pourrais le retirer au profit de
    pipewire-pulse et voir si ça fonctionne mieux.

    En tout état de cause, vu que tu as le fd et 25 secondes pour agir, un
    ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle
    socket/autre il poll.

    --
    PEB

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQJDBAEBCgAtFiEE5CQeth7uIW7ehIz87iFbn7jEWwsFAmVM7UIPHHBlYkBkZWJp YW4ub3JnAAoJEO4hW5+4xFsLSvUP/jHnNmYgwDqDaAM2jIx1L7kfcIv3nprYEUvU NUSytyd1e8a4BWT4d3hfU3lmKrV4Z2emVaNAMA9fraeMuBK+FalnsikPTnW32MRG 2SqPx7ytBRHJCUno2N25AFWPEdWgIFH/CmSTTZaIalufKxcn3yrymD+I94Te+FTs rE9eM2nVi289+bJ1v9EkJ2APDvX6Qdn1Bp1xXRQ2fcRGFC9v9bOsK3Y9lC3bVH11 5xgc90OHHPRRCO94wIqQtGwe1plGS40XQvFypqYKqmOuEF9baCy3IwcI2nPylEBj KS6AX0uRLEkONjiaDcprPnLQGGgIgYYqijvHerfL90kqUe4/rVNOWvsMm9j3bHcx YjhzTVFxo9I6dA/RfYiUzTEkfUwt6YmfjgIEP4TTVS1oH1lYzHFXpBYvZO0mHlch LLxUo0FxSUonp+tJb/9iEJdVOqv966GQPx5AXdxTDjPoDe0Gl8HjDWj4fGV0NGeA PMrnlzn92KxoZ+YIe1Dbbl5zifPWaBfOHoWncLMV16BAD4WXJskHJugRaLNTsIjm EWbltfCrXMqBOczqHmgDKaatV2prML4SmDXWDPFKwXn1jKXQrSgYLtfiTMi0g60E fbiNffAUa/srxH9cEb0Q3fueczPDx8resiOqpTJjSaUwzP9wC6MnDcjxMnnDFRDF
    XwDloO2R
    =8kPA
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Seb@21:1/5 to All on Fri Nov 10 08:50:01 2023
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    Salut,


    Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type.

    Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox que je
    venais de mettre à jour.

    Aujourd'hui (Debian 12), j'ai le problème avec Firefox, Pavucontrol et Xdaliclock.

    Le problème est croissant et menace de devenir handicapant en Debian 13.
    Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.

    Quelque chose qui rend mon installation peu courante, c'est que pendant l'install je décoche toutes les cases liées à des gestionnaires de
    fenêtres, et une fois l'install terminée j'installe le minimum (fvwm et
    ses dépendances). D'habitude, quand on décoche toutes ces cases, c'est
    pour un serveur (qui ne lancera jamais xdaliclock, donc on ne verra pas apparaître ce délai de 25 secondes).

    De la sorte, il est probable que je n'installe pas un package qui est
    standard chez les autres utilisateurs et qui s'avère utile pour certains logiciels graphiques (quoique pas indispensable puisque ces logiciels
    finissent par se lancer).

    Sinon, un rapport de bogue sur https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues pourrait
    être utile.

    C'est vrai qu'un rapport de bug pourrait servir.
    Peut-être plus avec reportbug toutefois, si c'est bien un package qui me
    manque ; il n'y aurait alors qu'une simple dépendance à ajouter.

    Pour ma part, je cherche des contributeurs pour le moteur d'inférences http://refpersys.org/

    Ça a l'air intéressant ; bonne chance !

    Si tu as la flemme de débugger, j'imagine que tu as actuellement
    pulseaudio d'installé. Tu pourrais le retirer au profit de
    pipewire-pulse et voir si ça fonctionne mieux.

    À vrai dire, j'utilise très peu pavucontrol ; c'est la multiplication des endroits où le délai se manifeste qui m'inquiète.

    En tout état de cause, vu que tu as le fd et 25 secondes pour agir, un
    ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle
    socket/autre il poll.

    Ben ça donne ça:
    ls -l /proc/$(pidof pavucontrol)/fd/11
    lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -> 'anon_inode:[eventfd]'


    Seb.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Patrick ZAJDA@21:1/5 to All on Fri Nov 10 10:20:01 2023
    This is a multi-part message in MIME format.
    Hello,

    Question que je ne pense pas avoir lu jusque là, quelle carte graphique utilises-tu ?

    J'ai une carte NVIDIA et j'ai eu ce genre de souci quand j'avais voulu
    tester ce que ça donnerait avec le pilote nouveau.
    Et installer le paquet du pilote propriétaire correspondant à ma carte
    avait résolu le souci.
    C'est probablement pas la solution vu que j'y vais un peu au hasard,
    mais sait-on jamais si ça peut être utile.

    Patrick


    Le 10/11/2023 à 08:43, Seb a écrit :

    Salut,


    Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type.

    Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox que
    je venais de mettre à jour.

    Aujourd'hui (Debian 12), j'ai le problème avec Firefox, Pavucontrol et Xdaliclock.

    Le problème est croissant et menace de devenir handicapant en Debian 13.
    Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.

    Quelque chose qui rend mon installation peu courante, c'est que
    pendant l'install je décoche toutes les cases liées à des
    gestionnaires de fenêtres, et une fois l'install terminée j'installe
    le minimum (fvwm et ses dépendances). D'habitude, quand on décoche
    toutes ces cases, c'est pour un serveur (qui ne lancera jamais
    xdaliclock, donc on ne verra pas apparaître ce délai de 25 secondes).

    De la sorte, il est probable que je n'installe pas un package qui est standard chez les autres utilisateurs et qui s'avère utile pour
    certains logiciels graphiques (quoique pas indispensable puisque ces logiciels finissent par se lancer).

    Sinon, un rapport de bogue sur
    https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues
    pourrait être utile.

    C'est vrai qu'un rapport de bug pourrait servir.
    Peut-être plus avec reportbug toutefois, si c'est bien un package qui
    me manque ; il n'y aurait alors qu'une simple dépendance à ajouter.

    Pour ma part, je cherche des contributeurs pour le moteur
    d'inférences http://refpersys.org/

    Ça a l'air intéressant ; bonne chance !

    Si tu as la flemme de débugger, j'imagine que tu as actuellement
    pulseaudio d'installé. Tu pourrais le retirer au profit de
    pipewire-pulse et voir si ça fonctionne mieux.

    À vrai dire, j'utilise très peu pavucontrol ; c'est la multiplication
    des endroits où le délai se manifeste qui m'inquiète.

    En tout état de cause, vu que tu as le fd et 25 secondes pour agir,
    un ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle
    socket/autre il poll.

    Ben ça donne ça:
    ls -l /proc/$(pidof pavucontrol)/fd/11
    lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -> 'anon_inode:[eventfd]'


    Seb.

    --
    Patrick ZAJDA
    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    Hello,<br>
    <br>
    Question que je ne pense pas avoir lu jusque là, quelle carte
    graphique utilises-tu ?<br>
    <br>
    J'ai une carte NVIDIA et j'ai eu ce genre de souci quand j'avais
    voulu tester ce que ça donnerait avec le pilote nouveau.<br>
    Et installer le paquet du pilote propriétaire correspondant à ma
    carte avait résolu le souci.<br>
    C'est probablement pas la solution vu que j'y vais un peu au hasard,
    mais sait-on jamais si ça peut être utile.<br>
    <br>
    Patrick<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Le 10/11/2023 à 08:43, Seb a écrit :<br>
    </div>
    <blockquote type="cite" cite="mid:nycvar.QRO.7.76.2311100829040.7431@af3358511.vc-37-187-30.rh">
    <br>
    Salut,
    <br>
    <br>
    <br>
    Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type.
    <br>
    <br>
    Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox
    que je venais de mettre à jour.
    <br>
    <br>
    Aujourd'hui (Debian 12), j'ai le problème avec Firefox,
    Pavucontrol et Xdaliclock.
    <br>
    <br>
    Le problème est croissant et menace de devenir handicapant en
    Debian 13.
    <br>
    Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.
    <br>
    <br>
    Quelque chose qui rend mon installation peu courante, c'est que
    pendant l'install je décoche toutes les cases liées à des
    gestionnaires de fenêtres, et une fois l'install terminée
    j'installe le minimum (fvwm et ses dépendances). D'habitude, quand
    on décoche toutes ces cases, c'est pour un serveur (qui ne lancera
    jamais xdaliclock, donc on ne verra pas apparaître ce délai de
    25 secondes).
    <br>
    <br>
    De la sorte, il est probable que je n'installe pas un package qui
    est standard chez les autres utilisateurs et qui s'avère utile
    pour certains logiciels graphiques (quoique pas indispensable
    puisque ces logiciels finissent par se lancer).
    <br>
    <br>
    <blockquote type="cite">Sinon, un rapport de bogue sur
    <a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues">https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues</a>
    pourrait être utile.
    <br>
    </blockquote>
    <br>
    C'est vrai qu'un rapport de bug pourrait servir.
    <br>
    Peut-être plus avec reportbug toutefois, si c'est bien un package
    qui me manque ; il n'y aurait alors qu'une simple dépendance à
    ajouter.
    <br>
    <br>
    <blockquote type="cite">Pour ma part, je cherche des contributeurs
    pour le moteur d'inférences <a class="moz-txt-link-freetext" href="http://refpersys.org/">http://refpersys.org/</a>
    <br>
    </blockquote>
    <br>
    Ça a l'air intéressant ; bonne chance !
    <br>
    <br>
    <blockquote type="cite">Si tu as la flemme de débugger, j'imagine
    que tu as actuellement
    <br>
    pulseaudio d'installé. Tu pourrais le retirer au profit de
    <br>
    pipewire-pulse et voir si ça fonctionne mieux.
    <br>
    </blockquote>
    <br>
    À vrai dire, j'utilise très peu pavucontrol ; c'est la
    multiplication des endroits où le délai se manifeste qui
    m'inquiète.
    <br>
    <br>
    <blockquote type="cite">En tout état de cause, vu que tu as le fd
    et 25 secondes pour agir, un ls -al /proc/XXX/fd/YYY est sans
    doute utile pour savoir quelle socket/autre il poll.
    <br>
    </blockquote>
    <br>
    Ben ça donne ça:
    <br>
    ~&gt; ls -l /proc/$(pidof pavucontrol)/fd/11
    <br>
    lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -&gt;
    'anon_inode:[eventfd]'
    <br>
    <br>
    <br>
    Seb.
    <br>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
    <meta charset="utf-8">
    <style type="text/css">img {white-space: pre;}</style>
    Patrick ZAJDA</div>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Seb@21:1/5 to All on Fri Nov 10 15:30:01 2023
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    Bonsoir,


    Question que je ne pense pas avoir lu jusque là, quelle carte graphique utilises-tu ?

    Une vieille NVidia.

    J'ai une carte NVIDIA et j'ai eu ce genre de souci quand j'avais voulu tester ce que ça donnerait avec le pilote nouveau.

    J'utilisais effectivement le pilote nouveau.

    Et installer le paquet du pilote propriétaire correspondant à ma carte avait résolu le souci.

    J'ai installé le pilote Nvidia et... ça n'a rien changé.


    Merci quand même !

    Seb.


    C'est probablement pas la solution vu que j'y vais un peu au hasard, mais sait-on jamais si ça peut être utile.

    Patrick


    Le 10/11/2023 à 08:43, Seb a écrit :

    Salut,


    Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type.

    Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox que je
    venais de mettre à jour.

    Aujourd'hui (Debian 12), j'ai le problème avec Firefox, Pavucontrol et
    Xdaliclock.

    Le problème est croissant et menace de devenir handicapant en Debian 13.
    Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.

    Quelque chose qui rend mon installation peu courante, c'est que pendant
    l'install je décoche toutes les cases liées à des gestionnaires de
    fenêtres, et une fois l'install terminée j'installe le minimum (fvwm et ses >> dépendances). D'habitude, quand on décoche toutes ces cases, c'est pour un >> serveur (qui ne lancera jamais xdaliclock, donc on ne verra pas apparaître >> ce délai de 25 secondes).

    De la sorte, il est probable que je n'installe pas un package qui est
    standard chez les autres utilisateurs et qui s'avère utile pour certains
    logiciels graphiques (quoique pas indispensable puisque ces logiciels
    finissent par se lancer).

    Sinon, un rapport de bogue sur
    https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues pourrait
    être utile.

    C'est vrai qu'un rapport de bug pourrait servir.
    Peut-être plus avec reportbug toutefois, si c'est bien un package qui me
    manque ; il n'y aurait alors qu'une simple dépendance à ajouter.

    Pour ma part, je cherche des contributeurs pour le moteur d'inférences
    http://refpersys.org/

    Ça a l'air intéressant ; bonne chance !

    Si tu as la flemme de débugger, j'imagine que tu as actuellement
    pulseaudio d'installé. Tu pourrais le retirer au profit de
    pipewire-pulse et voir si ça fonctionne mieux.

    À vrai dire, j'utilise très peu pavucontrol ; c'est la multiplication des
    endroits où le délai se manifeste qui m'inquiète.

    En tout état de cause, vu que tu as le fd et 25 secondes pour agir, un ls >>> -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle socket/autre >>> il poll.

    Ben ça donne ça:
    ls -l /proc/$(pidof pavucontrol)/fd/11
    lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 ->
    'anon_inode:[eventfd]'


    Seb.

    --
    Patrick ZAJDA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ludovic Bellier@21:1/5 to Seb on Fri Nov 10 16:20:02 2023
    On 09/11/2023 10:34, Seb wrote:

    Bonjour !


    J'ai installé hier une Debian 12 en remplacement d'une Debian plus
    ancienne. C'est une installation à partir de zéro, pas une mise à jour.

    Mon gestionnaire de fenêtres est fvwm.

    Lorsque je lance pavucontrol (ou xdaliclock, ou firefox), il s'écoule 25 secondes avant qu'une fenêtre ne s'ouvre. Et dans la Debian précédente, j'avais remarqué le même délai avec firefox depuis
    quelques mois seulement. Je n'ai pas souvenir que pavucontrol ou
    xdaliclock ait posé le même problème dans la Debian que j'utilisais précédemment.

    Les autres programmes s'ouvrent sans délai (gimp, brave-browser,
    okular, etc.).

    Quand j'appelle "strace pavucontrol", les messages cessent de défiler
    en arrivant à la dernière des lignes copiées-collées ci-dessous :

    [...]
    eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 11
    futex(0x55c3de03dba0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN
    (Resource temporarily unavailable)
    futex(0x55c3de03dba0, FUTEX_WAKE_PRIVATE, 1) = 0
    write(10, "\1\0\0\0\0\0\0\0", 8)        = 8
    futex(0x55c3ddf73278, FUTEX_WAKE_PRIVATE, 1) = 1
    poll([{fd=11, events=POLLIN}], 1, 25000

    Sitôt le délai (25000) passé, pavucontrol s'ouvre.

    Auriez-vous une idée de ce qui cause cet arrêt temporaire, ou du moins d'une direction dans laquelle chercher ?


    Bonjour,

    j'ai vu un comportement proche sous ArchLinux il y a quelques mois, la
    piste **dbus** est à explorer:

    https://bbs.archlinux.org/viewtopic.php?id=275523

    Ludovic

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jose CHARTERS@21:1/5 to All on Fri Nov 10 22:30:01 2023
    This is a multi-part message in MIME format.
    Le 10/11/2023 à 08:43, Seb a écrit :
    Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type.

    Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox que
    je venais de mettre à jour.

    Aujourd'hui (Debian 12), j'ai le problème avec Firefox, Pavucontrol et Xdaliclock.

    Le problème est croissant et menace de devenir handicapant en Debian 13.
    Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.

    Quelque chose qui rend mon installation peu courante, c'est que
    pendant l'install je décoche toutes les cases liées à des
    gestionnaires de fenêtres, et une fois l'install terminée j'installe
    le minimum (fvwm et ses dépendances). D'habitude, quand on décoche
    toutes ces cases, c'est pour un serveur (qui ne lancera jamais
    xdaliclock, donc on ne verra pas apparaître ce délai de 25 secondes).

    De la sorte, il est probable que je n'installe pas un package qui est standard chez les autres utilisateurs et qui s'avère utile pour
    certains logiciels graphiques (quoique pas indispensable puisque ces logiciels finissent par se lancer).

    Sinon, un rapport de bogue sur
    https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues
    pourrait être utile.

    C'est vrai qu'un rapport de bug pourrait servir.
    Peut-être plus avec reportbug toutefois, si c'est bien un package qui
    me manque ; il n'y aurait alors qu'une simple dépendance à ajouter.

    Si tu as la flemme de débugger, j'imagine que tu as actuellement
    pulseaudio d'installé. Tu pourrais le retirer au profit de
    pipewire-pulse et voir si ça fonctionne mieux.

    À vrai dire, j'utilise très peu pavucontrol ; c'est la multiplication
    des endroits où le délai se manifeste qui m'inquiète.

    En tout état de cause, vu que tu as le fd et 25 secondes pour agir,
    un ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle
    socket/autre il poll.

    Ben ça donne ça:
    ls -l /proc/$(pidof pavucontrol)/fd/11
    lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -> 'anon_inode:[eventfd]'

    Bonsoir,

    Je n'avais pas le lien jusqu'à présent, mais j'ai le même type de soucis
    sur ma debian 12.

    Pour moi, cela se manifeste lors du lancement de Firefox et lorsque je
    retire certaines clés USB. Je m'en accommodais.

    Sur Debian 11, cela se manifestait uniquement lors du lancement de Firefox.

    Peux-tu me rappeler la commande pour voir le délai de 25 s. Je l'ai vu
    passé dans les mails précédents, mais je n'avais pas percuter que
    c'était valable pour moi également.

    José

    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <div class="moz-cite-prefix">Le 10/11/2023 à 08:43, Seb a écrit :<br>
    </div>
    <blockquote type="cite" cite="mid:nycvar.QRO.7.76.2311100829040.7431@af3358511.vc-37-187-30.rh">Il
    y a 6 mois (Debian 11), je n'avais aucun problème de ce type.
    <br>
    <br>
    Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox
    que je venais de mettre à jour.
    <br>
    <br>
    Aujourd'hui (Debian 12), j'ai le problème avec Firefox,
    Pavucontrol et Xdaliclock.
    <br>
    <br>
    Le problème est croissant et menace de devenir handicapant en
    Debian 13.
    <br>
    Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.
    <br>
    <br>
    Quelque chose qui rend mon installation peu courante, c'est que
    pendant l'install je décoche toutes les cases liées à des
    gestionnaires de fenêtres, et une fois l'install terminée
    j'installe le minimum (fvwm et ses dépendances). D'habitude, quand
    on décoche toutes ces cases, c'est pour un serveur (qui ne lancera
    jamais xdaliclock, donc on ne verra pas apparaître ce délai de
    25 secondes).
    <br>
    <br>
    De la sorte, il est probable que je n'installe pas un package qui
    est standard chez les autres utilisateurs et qui s'avère utile
    pour certains logiciels graphiques (quoique pas indispensable
    puisque ces logiciels finissent par se lancer).
    <br>
    <br>
    <blockquote type="cite">Sinon, un rapport de bogue sur
    <a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues">https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues</a>
    pourrait être utile.
    <br>
    </blockquote>
    <br>
    C'est vrai qu'un rapport de bug pourrait servir.
    <br>
    Peut-être plus avec reportbug toutefois, si c'est bien un package
    qui me manque ; il n'y aurait alors qu'une simple dépendance à
    ajouter.
    <br>
    <br>
    <blockquote type="cite">Si tu as la flemme de débugger, j'imagine
    que tu as actuellement
    <br>
    pulseaudio d'installé. Tu pourrais le retirer au profit de
    <br>
    pipewire-pulse et voir si ça fonctionne mieux.
    <br>
    </blockquote>
    <br>
    À vrai dire, j'utilise très peu pavucontrol ; c'est la
    multiplication des endroits où le délai se manifeste qui
    m'inquiète.
    <br>
    <br>
    <blockquote type="cite">En tout état de cause, vu que tu as le fd
    et 25 secondes pour agir, un ls -al /proc/XXX/fd/YYY est sans
    doute utile pour savoir quelle socket/autre il poll.
    <br>
    </blockquote>
    <br>
    Ben ça donne ça:
    <br>
    ~&gt; ls -l /proc/$(pidof pavucontrol)/fd/11
    <br>
    lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 -&gt;
    'anon_inode:[eventfd]'
    <br>
    </blockquote>
    <p>Bonsoir,</p>
    <p>Je n'avais pas le lien jusqu'à présent, mais j'ai le même type de
    soucis sur ma debian 12.</p>
    <p>Pour moi, cela se manifeste lors du lancement de Firefox et
    lorsque je retire certaines clés USB. Je m'en accommodais.</p>
    <p>Sur Debian 11, cela se manifestait uniquement lors du lancement
    de Firefox.</p>
    <p>Peux-tu me rappeler la commande pour voir le délai de 25 s. Je
    l'ai vu passé dans les mails précédents, mais je n'avais pas
    percuter que c'était valable pour moi également.</p>
    <p>José<br>
    </p>
    <div id="grammalecte_menu_main_button_shadow_host"
    style="width: 0px; height: 0px;"></div>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From NoSpam@21:1/5 to All on Sat Nov 11 12:30:01 2023
    Bonjour

    Le 10/11/2023 à 22:19, Jose CHARTERS a écrit :
    Le 10/11/2023 à 08:43, Seb a écrit :
    Il y a 6 mois (Debian 11), je n'avais aucun problème de ce type.

    Il y a 3 mois (Debian 11), j'ai remarqué ce souci avec un Firefox que
    je venais de mettre à jour.

    Aujourd'hui (Debian 12), j'ai le problème avec Firefox, Pavucontrol
    et Xdaliclock.

    Le problème est croissant et menace de devenir handicapant en Debian 13.
    Je ne pense pas qu'il soit lié spécifiquement à Pavucontrol.

    Quelque chose qui rend mon installation peu courante, c'est que
    pendant l'install je décoche toutes les cases liées à des
    gestionnaires de fenêtres, et une fois l'install terminée j'installe
    le minimum (fvwm et ses dépendances). D'habitude, quand on décoche
    toutes ces cases, c'est pour un serveur (qui ne lancera jamais
    xdaliclock, donc on ne verra pas apparaître ce délai de 25 secondes).

    De la sorte, il est probable que je n'installe pas un package qui est
    standard chez les autres utilisateurs et qui s'avère utile pour
    certains logiciels graphiques (quoique pas indispensable puisque ces
    logiciels finissent par se lancer).

    Sinon, un rapport de bogue sur
    https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues
    pourrait être utile.

    C'est vrai qu'un rapport de bug pourrait servir.
    Peut-être plus avec reportbug toutefois, si c'est bien un package qui
    me manque ; il n'y aurait alors qu'une simple dépendance à ajouter.

    Si tu as la flemme de débugger, j'imagine que tu as actuellement
    pulseaudio d'installé. Tu pourrais le retirer au profit de
    pipewire-pulse et voir si ça fonctionne mieux.

    À vrai dire, j'utilise très peu pavucontrol ; c'est la multiplication
    des endroits où le délai se manifeste qui m'inquiète.

    En tout état de cause, vu que tu as le fd et 25 secondes pour agir,
    un ls -al /proc/XXX/fd/YYY est sans doute utile pour savoir quelle
    socket/autre il poll.

    Ben ça donne ça:
    ls -l /proc/$(pidof pavucontrol)/fd/11
    lrwx------ 1 seb seb 64 Nov 10 10:42 /proc/135045/fd/11 ->
    'anon_inode:[eventfd]'

    Bonsoir,

    Je n'avais pas le lien jusqu'à présent, mais j'ai le même type de
    soucis sur ma debian 12.

    Pour moi, cela se manifeste lors du lancement de Firefox et lorsque je
    retire certaines clés USB. Je m'en accommodais.

    Sur Debian 11, cela se manifestait uniquement lors du lancement de
    Firefox.

    Peux-tu me rappeler la commande pour voir le délai de 25 s. Je l'ai vu passé dans les mails précédents, mais je n'avais pas percuter que
    c'était valable pour moi également.

    https://lists.debian.org/debian-user-french/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jose CHARTERS@21:1/5 to All on Sun Nov 12 18:00:01 2023
    This is a multi-part message in MIME format.
    Le 11/11/2023 à 12:20, NoSpam a écrit :

    Peux-tu me rappeler la commande pour voir le délai de 25 s. Je l'ai
    vu passé dans les mails précédents, mais je n'avais pas percuter que
    c'était valable pour moi également.

    https://lists.debian.org/debian-user-french/

    Merci.

    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <div class="moz-cite-prefix">Le 11/11/2023 à 12:20, NoSpam a écrit :<br>
    </div>
    <blockquote type="cite"
    cite="mid:c4706411-63f2-4413-a348-29ecef87860c@tootai.net"><br>
    <blockquote type="cite">Peux-tu me rappeler la commande pour voir
    le délai de 25 s. Je l'ai vu passé dans les mails précédents,
    mais je n'avais pas percuter que c'était valable pour moi
    également.
    <br>
    <br>
    </blockquote>
    <a class="moz-txt-link-freetext" href="https://lists.debian.org/debian-user-french/">https://lists.debian.org/debian-user-french/</a>
    <br>
    <br>
    </blockquote>
    <p>Merci.<br>
    </p>
    <div id="grammalecte_menu_main_button_shadow_host"
    style="width: 0px; height: 0px;"></div>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Seb@21:1/5 to All on Tue Nov 14 10:30:01 2023
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    Bonjour,


    poll([{fd=11, events=POLLIN}], 1, 25000
    Sitôt le délai (25000) passé, pavucontrol s'ouvre.

    j'ai vu un comportement proche sous ArchLinux il y a quelques mois, la
    piste **dbus** est à explorer: https://bbs.archlinux.org/viewtopic.php?id=275523

    YOUHOU! C'est pile le bon pointeur.

    Je peux donc maintenant raconter l'histoire.

    Il ne me manquait pas de package.

    Par contre, je démarre X avec "startx" et depuis presque 30 ans j'utilise
    un fichier $HOME/.xinitrc pour dire ce qu'il faut faire : lancer fvwm2,
    puis faire un xmodmap, un xrdb, lancer xdaliclock, ouvrir un terminal,
    bref faire en sorte que l'environnement graphique soit confortable dès
    qu'il s'ouvre.

    Quand l'utilisateur n'a pas de fichier ~/.xinitrc, le système utilise le fichier par défaut : /etc/X11/xinit/xinitrc. Celui-ci redirige vers /etc/X11/Xsession.

    À une date que je ne connais pas, quelqu'un s'est dit que
    /etc/X11/Xsession était un super endroit pour lancer des services (liste
    dans /etc/X11/Xsession.d), entre autres DBus.

    Sauf que /etc/X11/Xsession n'est pas appelé si on a son propre fichier ~/.xinitrc.

    À son origine, DBus servait, il me semble, à la communication des
    processus dans KDE ou dans Gnome, et comme je n'utilise ni l'un, ni
    l'autre, ça ne me manquait pas. DBus a pris maintenant un rôle plus
    important, et son absence commence à se faire sentir même sous Fvwm.
    Son timeout est d'exactement 25 secondes.

    La solution simple dans mon cas est donc de renommer ~/.xinitrc en trucs-a-lancer-au-demarrage.sh afin que les fichiers par défaut dans
    /etc/X11 soient utilisés.

    Du coup, j'ai une question connexe : quel est aujourd'hui l'emplacement recommandé pour les p'tites commandes (xmodmap, xrdb, etc.) qui devraient
    se lancer automatiquement sitôt fvwm2 démarré ?

    Je ne peux pas juste appeler à la main /etc/X11/Xsession au début de mon ~/.xinitrc car /etc/X11/Xsession se termine par un "exec $STARTUP".


    Seb.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?S=C3=A9bastien_NOBILI?=@21:1/5 to All on Tue Nov 14 11:50:01 2023
    Bonjour,

    Le 2023-11-14 10:26, Seb a écrit :
    À son origine, DBus servait, il me semble, à la communication des
    processus dans KDE ou dans Gnome, et comme je n'utilise ni l'un, ni
    l'autre, ça ne me manquait pas. DBus a pris maintenant un rôle plus important, et son absence commence à se faire sentir même sous Fvwm.

    C'est devenu un élément assez central en effet. Il est même utilisé par systemd.

    Je ne peux pas juste appeler à la main /etc/X11/Xsession au début de
    mon ~/.xinitrc car /etc/X11/Xsession se termine par un "exec $STARTUP".

    Ici (Bookworm) je n'ai pas cette ligne.

    Perso je me suis créé un dossier dans lequel j'ai mis mes
    propres scripts de démarrage de tout ce que je veux (y compris
    des trucs graphiques) que je lance via une boucle :

    ```
    for script in $(ls ~/.xsession.d/startup.d/); do
    [ -f ~/.xsession.d/startup.d/$script ] || continue
    command ~/.xsession.d/startup.d/$script &
    done
    ```

    Sinon tu peux faire un truc du genre (pas testé) :

    ```
    for f in /etc/X11/Xsession.d/*; do source $f; done
    ```

    À adapter selon ton shell.

    Autre piste, j'ai ça dans mon `.xinitrc` (qui ne doit
    pas me servir puisque je suis passé à Wayland) :

    ```
    export XDG_DATA_DIRS=$XDG_DATA_DIRS:$HOME/.local/share/applications
    if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS";
    then
    eval `dbus-launch --sh-syntax --exit-with-session`
    fi
    ```

    Sébastien

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Basile Starynkevitch@21:1/5 to Seb on Tue Nov 14 11:30:01 2023
    On 11/14/23 10:26, Seb wrote:

    Bonjour,


    poll([{fd=11, events=POLLIN}], 1, 25000
    Sitôt le délai (25000) passé, pavucontrol s'ouvre.

    j'ai vu un comportement proche sous ArchLinux il y a quelques mois,
    la piste **dbus** est à explorer:
    https://bbs.archlinux.org/viewtopic.php?id=275523

    YOUHOU! C'est pile le bon pointeur.

    Je peux donc maintenant raconter l'histoire.

    Il ne me manquait pas de package.

    Par contre, je démarre X avec "startx" et depuis presque 30 ans
    j'utilise un fichier $HOME/.xinitrc pour dire ce qu'il faut faire :
    lancer fvwm2, puis faire un xmodmap, un xrdb, lancer xdaliclock,
    ouvrir un terminal, bref faire en sorte que l'environnement graphique
    soit confortable dès qu'il s'ouvre.

    Quand l'utilisateur n'a pas de fichier ~/.xinitrc, le système utilise
    le fichier par défaut : /etc/X11/xinit/xinitrc. Celui-ci redirige vers /etc/X11/Xsession.

    À une date que je ne connais pas, quelqu'un s'est dit que
    /etc/X11/Xsession était un super endroit pour lancer des services
    (liste dans /etc/X11/Xsession.d), entre autres DBus.

    Sauf que /etc/X11/Xsession n'est pas appelé si on a son propre fichier ~/.xinitrc.

    À son origine, DBus servait, il me semble, à la communication des
    processus dans KDE ou dans Gnome, et comme je n'utilise ni l'un, ni
    l'autre, ça ne me manquait pas. DBus a pris maintenant un rôle plus important, et son absence commence à se faire sentir même sous Fvwm.
    Son timeout est d'exactement 25 secondes.

    La solution simple dans mon cas est donc de renommer ~/.xinitrc en trucs-a-lancer-au-demarrage.sh afin que les fichiers par défaut dans /etc/X11 soient utilisés.

    Du coup, j'ai une question connexe : quel est aujourd'hui
    l'emplacement recommandé pour les p'tites commandes (xmodmap, xrdb,
    etc.) qui devraient se lancer automatiquement sitôt fvwm2 démarré ?


    La page de man suggère:

           During  initialization,  fvwm searches for a configuration file which describes key and button bindings, and many other things.  The
    format of these files is
           described later.  Fvwm first searches for configuration files using the command

               Read config

           This looks for file config in $FVWM_USERDIR and $FVWM_DATADIR directories, as described in  Read.   If  this fails  more  files  are  queried  for  backward
           compatibility.  Here is the complete list of all file locations queried in the default installation (only the first found file is used):

               $HOME/.fvwm/config
               /usr/local/share/fvwm/config

               $HOME/.fvwm/.fvwm2rc
               $HOME/.fvwm2rc
               /usr/local/share/fvwm/.fvwm2rc
               /usr/local/share/fvwm/system.fvwm2rc
               /etc/system.fvwm2rc

            Please note, the last 5 locations are not guaranteed to be supported in the future.



    Je ne peux pas juste appeler à la main /etc/X11/Xsession au début de
    mon ~/.xinitrc car /etc/X11/Xsession se termine par un "exec $STARTUP".


    Seb.

    --
    Basile Starynkevitch
    <basile@starynkevitch.net>
    (only mine opinions / les opinions sont miennes uniquement)
    92340 Bourg-la-Reine, France
    web page: starynkevitch.net/Basile/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michel Verdier@21:1/5 to All on Tue Nov 14 16:30:01 2023
    Le 14 novembre 2023 Seb a écrit :

    J'avais pris un raccourci, je voulais dire que le dernier fichier appelé dans
    /etc/X11/Xsession, /etc/X11/Xsession.d/99x11-common_start, contient "exec $STARTUP".

    /etc/X11/Xsession.d/50x11-common_determine-startup positionne $STARTUP à
    un script qui est soit $HOME/.xsession soit $HOME/.Xsession
    $HOME/.xsessionrc est sourcé, ici je préfère lancer un script donc j'ai
    tout mis en $HOME/.xsession qui est donc lancé via /etc/X11/Xsession

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)