Re: pb de locales : dmenu (i3) segfault et urxvt se comporte pas bien
Bonjour, Avant que je n'oublie @ Jean-Michel : j'utilise rxvt-unicode (urxvt). La suite dans le corps du mail. Le 14/11/2020 à 17:53:30, Étienne Mollier a écrit : > Bonjour ORL, > > ORL - AMMD, on 2020-11-14 12:59:07 +0100: > > Sur une Debian testing à jour, depuis un upgrade il y a quelques jours > > semaines, j'ai des pb avec dmenu dans i3 et urxvt. J'ai rempli des > > bugreports, mais pas de réponse, et de toute façon, je crois que > j'avais mal > > cerné le pb : > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973515 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973919 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974571 > > > > Les symptômes : > > - quand je lance mod+d dans i3, ça lance dmenu_run, dès que je tape une > > touche pour lancer une application, ça ferme, et rien ne se passe, > > - urxvt n'affiche plus les caractères accentués (mais je peux en > > copier/coller dedans, par contre). > > > > Quand je les lance en ligne de commande : > > > > $ dmenu_run > > warning: no locale support > > warning: no locale modifiers support > > J'utilise dmenu en complément d'un bureau dwm. Je n'ai pas > reproduit le problème en Sid de mon côté. Ma locale, histoire > de pouvoir taper des caractères accentués, est C.UTF-8 ; > peut-être que ça vaudrait le coup de l'essayer, pour voir s'il y > a un changement de comportement ? OK, j'ai voulu tenter, mais je n'ai pas C.UTF-8 dans les locales proposées par dpkg --reconfigure locales. Il y a un autre moyen pour les générer ? Accessoirement, ce pb survient également avec un autre utilisateur, qui utilise XFCE. Si je lance urxvt, j'ai les mêmes warnings, et le même comportement. > > Est-ce qu'un petit `sudo dpkg-reconfigure locales`, suivi d'une > vérification des locales à engendrer, permettrait de rafraichir > la configuration ? Ah oui, mince, j'ai oublié de vous dire que j'avais commencé par là, mais que ça n'a rien changé. Par contre, j'ai localepurge d'installé sur cette machine, contrairement aux deux autres sur lesquelles je n'ai pas de souci. Peut-être que ça peut avoir un lien ? (moi je ne vois pas lequel, mais bon). > > > $ urxvt > > urxvt: the locale is not supported by Xlib, continuing without locale > > support. > > > [...] > > > > J'ai deux autres machines en Bullseye avec i3 et urxvt où je n'ai pas du > > tout ce problème, donc je penche vraiment pour une configuration > > particulière qui m'échapperait, d'autant que cette install est très > vieille, > > j'ai dû la démarrer en stretch, etch, ou avant, peut-être même à > l'époque de > > lenny, je ne sais plus, donc il peut y avoir des choses qui traînent de > > cette époque. > > Etch était la version 4 de Debian, Testing est actuellement la > version 11 en préparation. Si votre installation date de Etch, > effectivement, elle pourrait peut-être gagner à être rafraîchie. Héhé, oui sans doute. J'avoue que j'aime bien l'idée de jamais avoir eu à réinstaller, c'était un des gros intérêts quand je suis passé à Debian : on ne réinstalle pas, on répare. Bon, faudra peut-être que je m'y résolve, un jour, alors... Merci de votre aide. ORL
Re: /etc/securetty
Bonsoir, 14 nov. 2020 à 17:24 de dl...@bluewin.ch: >> 13 nov. 2020 à 17:18 de s-liste-debian-user-fre...@pipoprods.org: >> >>> Le fichier existe sur mon système (Buster assez fraîchement installé). >>> Il appartient au paquet "login". >>> > Pas chez moi: > > apt-file search /etc/securetty > rear: /usr/share/rear/skel/Linux-ia64/etc/securetty > Ok, je parie que tu ne fais pas tourner Buster mais plutôt Testing ou Unstable. Vrai ? En effet login ne fournit plus /etc/securetty après Buster [1][2] d'où ta sortie de commande différente de la mienne+Sébastien. J'ai l'impression que ta remontée est du même acabit que le bug #931899 [3]. Auquel cas, vu que le fichier n'est plus fourni, pam devrait arrêter de proposer des options qui y font appel au-delà de Buster. Il semble que la ligne fautive soit dans /etc/pam.d/common-auth, plus précisément l'argument "nullok_secure" envoyé au module pam_unix.so. Je te laisse regarder si t'as bien cette ligne. Sous Buster chez moi c'est la suivante : auth [success=1 default=ignore] pam_unix.so nullok_secure Visiblement, supprimer "nullok_secure" résout le pb d'accès. Pas certain que ce soit une perte de sécurité dans la mesure où cet argument autorise lui-même une certaine largesse... nullok_secure: The default action of this module is to not permit the user access to a service if their official password is blank. The nullok_secure argument overrides this default and allows any user with a blank password to access the service as long as the value of PAM_TTY is set to one of the values found in /etc/securetty. Bien cordialement, l0f4r0 [1] : https://packages.debian.org/bullseye/amd64/login/filelist [2] : https://packages.debian.org/sid/amd64/login/filelist [3] : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931899
Re: Arrière fond noir dans KDE Plasma
Ce jour j'ai fait une mise à jour en testing. Il y avait pas mal de paquets KDE et après cette mise à jour kde se comporte à nouveau correctement. Francois Mescam Le 12/11/2020 à 17:09, steve a écrit : Le 12-11-2020, à 10:35:46 +0100, Francois Mescam a écrit : Voir le bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974019 qui parle de l'instabilité de kde. J'ai été confronté à ce problème et j'ai bloqué les paquets suivants aux versions indiquées ci-après : libkdecorations2-5v5:amd64 4:5.17.5-2 libkf5screen-bin:amd64 4:5.17.5-3 libkf5screen7:amd64 4:5.17.5-3 Merci pour l'info et le lien, mais malheureusement ça n'a pas fonctionné sur mon système quelque peu hybride.
Re: pb de locales : dmenu (i3) segfault et urxvt se comporte pas bien
Bonjour ORL, ORL - AMMD, on 2020-11-14 12:59:07 +0100: > Sur une Debian testing à jour, depuis un upgrade il y a quelques jours > semaines, j'ai des pb avec dmenu dans i3 et urxvt. J'ai rempli des > bugreports, mais pas de réponse, et de toute façon, je crois que j'avais mal > cerné le pb : > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973515 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973919 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974571 > > Les symptômes : > - quand je lance mod+d dans i3, ça lance dmenu_run, dès que je tape une > touche pour lancer une application, ça ferme, et rien ne se passe, > - urxvt n'affiche plus les caractères accentués (mais je peux en > copier/coller dedans, par contre). > > Quand je les lance en ligne de commande : > > $ dmenu_run > warning: no locale support > warning: no locale modifiers support J'utilise dmenu en complément d'un bureau dwm. Je n'ai pas reproduit le problème en Sid de mon côté. Ma locale, histoire de pouvoir taper des caractères accentués, est C.UTF-8 ; peut-être que ça vaudrait le coup de l'essayer, pour voir s'il y a un changement de comportement ? Est-ce qu'un petit `sudo dpkg-reconfigure locales`, suivi d'une vérification des locales à engendrer, permettrait de rafraichir la configuration ? > $ urxvt > urxvt: the locale is not supported by Xlib, continuing without locale > support. > [...] > > J'ai deux autres machines en Bullseye avec i3 et urxvt où je n'ai pas du > tout ce problème, donc je penche vraiment pour une configuration > particulière qui m'échapperait, d'autant que cette install est très vieille, > j'ai dû la démarrer en stretch, etch, ou avant, peut-être même à l'époque de > lenny, je ne sais plus, donc il peut y avoir des choses qui traînent de > cette époque. Etch était la version 4 de Debian, Testing est actuellement la version 11 en préparation. Si votre installation date de Etch, effectivement, elle pourrait peut-être gagner à être rafraîchie. Bonne soirée, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/1, please excuse my verbosity. signature.asc Description: PGP signature
Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.
Bonjour Charles, Charles Plessy, on 2020-11-14 18:23:21 +0900: > Le Thu, Nov 12, 2020 at 09:51:06PM +0100, Étienne Mollier a écrit : > > $ export GIT_SSH_COMMAND='ssh -vvv' > > $ git clone g...@salsa.debian.org:med-team/perlprimer.git > > Merci du tuyau, ça bloque à: > > debug1: Sending command: git-upload-pack 'med-team/perlprimer.git' > debug2: channel 1: request exec confirm 1 > debug3: send packet: type 98 > debug2: channel_input_open_confirmation: channel 1: callback done > debug2: channel 1: open confirm rwindow 0 rmax 32768 > > Google ou DuckDuckGo ne révèlent rien concernant "git-upload-pack" > "ipv6" "freeze" Je sèche. C'est vrai que c'est curieux. On est loin dans l'exécution de la commande `git clone` : la connexion SSH est déjà établie, et les clés sont échangées depuis bien longtemps. Chez moi, la connexion se poursuit comme suit: debug1: Sending command: git-upload-pack 'med-team/perlprimer.git' debug2: channel 0: request exec confirm 1 debug3: send packet: type 98 debug2: channel_input_open_confirmation: channel 0: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 2097152 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 remote: Enumerating objects: 660, done. remote: Counting objects: 100% (660/660), done. remote: Compressing objects: 100% (299/299), done. Soit la commande "git-upload-pack 'med-team/perlprimer.git'" ne démarre pas du côté de Salsa, soit elle n'arrive pas à utiliser la liaison existante avec votre machine pour renvoyer la confirmation (paquet type 99). > (Je n'ai pas encore testé le changement de MTU; je ne sais pas comment > le faire sure une interface wifi gérée par GNOME...) La suggestion de Daniel "NoSpam" avec "ip" me semble à explorer. J'ai des souvenirs d'école comme quoi IPv6 ne fragmente pas comme IPv4, et du coup un MTU trop gros peut potentiellement bloquer si la route se dégrade en cours de connexion (je ne suis pas spécialiste en réseau, et le souvenir en question date d'il y a dix ans, donc je peux dire des bêtises). > (Je n'ai pas testé non plus la version 2.29; je suis en 2.27) J'ai testé rapidement avec Git 2.20 de Buster, mais je n'ai pas observé plus de blocages, sinon effectivement, mon test était avec Git 2.29. > Bon week-end ! Merci, à vous de même, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/1, please excuse my verbosity. signature.asc Description: PGP signature
Re: pb de locales : dmenu (i3) segfault et urxvt se comporte pas bien
Bonjour, Le samedi 14 novembre 2020, ORL - AMMD a écrit... > Sur une Debian testing à jour, depuis un upgrade il y a quelques jours > semaines, j'ai des pb avec dmenu dans i3 et urxvt. J'ai rempli des > bugreports, mais pas de réponse, et de toute façon, je crois que j'avais mal > cerné le pb : Ton paquet rxvt, c'est rxvt, ou rxvt-unicode ? -- jm
Re: /etc/securetty
Le 13-11-2020, à 19:18:00 +0100, l0f...@tuta.io a écrit : Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip à faire ? D'après cette phrase je comprends que ton /etc/securetty existe (mais que les droits sont probablement KO à cause du "No such file or directory" plus haut) Au début, il n'existait pas. J'ai tenté d'en créer un vide avec 'touch /etc/securetty' en espérant que ça passerait. Ensuite, je me suis aperçu que ça ne changeait rien, donc je l'ai viré. 13 nov. 2020 à 07:55 de dl...@bluewin.ch: Non il n'existe pas. Quel paquet aurait dû le créer et quel devrait être son contenu ? Maintenant je comprends que ton /etc/securetty n'existe pas finalement. Bref tu m'as un peu perdu... ;) Désolé :) 13 nov. 2020 à 17:18 de s-liste-debian-user-fre...@pipoprods.org: Le fichier existe sur mon système (Buster assez fraîchement installé). Il appartient au paquet "login". Pas chez moi: apt-file search /etc/securetty rear: /usr/share/rear/skel/Linux-ia64/etc/securetty 'dpkg --listfiles login' ne me liste pas ce fichier Idem ici. Du coup que donne un simple : dpkg -l login C'est installé. J'y perds mon grec… Merci pour l'intérêt. Steve
pb de locales : dmenu (i3) segfault et urxvt se comporte pas bien
Salut, Sur une Debian testing à jour, depuis un upgrade il y a quelques jours semaines, j'ai des pb avec dmenu dans i3 et urxvt. J'ai rempli des bugreports, mais pas de réponse, et de toute façon, je crois que j'avais mal cerné le pb : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973515 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973919 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974571 Les symptômes : - quand je lance mod+d dans i3, ça lance dmenu_run, dès que je tape une touche pour lancer une application, ça ferme, et rien ne se passe, - urxvt n'affiche plus les caractères accentués (mais je peux en copier/coller dedans, par contre). Quand je les lance en ligne de commande : $ dmenu_run warning: no locale support warning: no locale modifiers support $ urxvt urxvt: the locale is not supported by Xlib, continuing without locale support. Pourtant mes locales sont bien installées : $ locale LANG=fr_FR.UTF-8 LANGUAGE= LC_CTYPE="fr_FR.UTF-8" LC_NUMERIC="fr_FR.UTF-8" LC_TIME="fr_FR.UTF-8" LC_COLLATE="fr_FR.UTF-8" LC_MONETARY="fr_FR.UTF-8" LC_MESSAGES="fr_FR.UTF-8" LC_PAPER="fr_FR.UTF-8" LC_NAME="fr_FR.UTF-8" LC_ADDRESS="fr_FR.UTF-8" LC_TELEPHONE="fr_FR.UTF-8" LC_MEASUREMENT="fr_FR.UTF-8" LC_IDENTIFICATION="fr_FR.UTF-8" LC_ALL= $ localectl System Locale: LANG=fr_FR.UTF-8 VC Keymap: n/a X11 Layout: fr X11 Model: pc105 X11 Variant: latin9 X11 Options: lv3:ralt_switch $ echo $LANG fr_FR.UTF-8 $ locate locale |grep /etc /etc/X11/Xsession.d/20slim_locale /etc/apt/apt.conf.d/99-localepurge /etc/default/locale /etc/default/locale.dpkg-dist /etc/dpkg/dpkg.cfg.d/50localepurge /etc/iceweasel/searchplugins/locale /etc/iceweasel/searchplugins/locale/en-US /etc/iceweasel/searchplugins/locale/fr /etc/locale.alias /etc/locale.gen /etc/locale.nopurge /usr/share/playonlinux/etc/onglet/preferences-desktop-locale.png J'ai vérifié la plupart de ces dossiers sans rien y trouver de bizarre (à mon niveau). J'avais un fichier /etc/environment dans lequel il y avait LANG="fr_FR.UTF-8", j'ai commenté cette ligne comme recommandé sur le site de Debian. J'ai deux autres machines en Bullseye avec i3 et urxvt où je n'ai pas du tout ce problème, donc je penche vraiment pour une configuration particulière qui m'échapperait, d'autant que cette install est très vieille, j'ai dû la démarrer en stretch, etch, ou avant, peut-être même à l'époque de lenny, je ne sais plus, donc il peut y avoir des choses qui traînent de cette époque. Voilà, si quelqu'un a des pistes pour me dire dans quel sens chercher, ça serait cool, parce que là, je ne m'en sors pas. Merci d'avance. ORL
Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.
Bonjour Le 14/11/2020 à 10:23, Charles Plessy a écrit : [...] (Je n'ai pas encore testé le changement de MTU; je ne sais pas comment le faire sure une interface wifi gérée par GNOME...) en ligne de commande: sudo ip link set mtu 1492 dev -- Daniel
Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.
Le Thu, Nov 12, 2020 at 09:51:06PM +0100, Étienne Mollier a écrit : > > Je n'ai pas rencontré de problèmes de mon côté. En grattant un > peu, la variable d'environnement GIT_SSH_COMMAND peut être > exploitée pour augmenter le verbiage de ssh: > > $ export GIT_SSH_COMMAND='ssh -vvv' > $ git clone g...@salsa.debian.org:med-team/perlprimer.git Merci du tuyau, ça bloque à: debug1: Sending command: git-upload-pack 'med-team/perlprimer.git' debug2: channel 1: request exec confirm 1 debug3: send packet: type 98 debug2: channel_input_open_confirmation: channel 1: callback done debug2: channel 1: open confirm rwindow 0 rmax 32768 Google ou DuckDuckGo ne révèlent rien concernant "git-upload-pack" "ipv6" "freeze" (Je n'ai pas encore testé le changement de MTU; je ne sais pas comment le faire sure une interface wifi gérée par GNOME...) (Je n'ai pas testé non plus la version 2.29; je suis en 2.27) Bon week-end ! -- Charles
Re: /etc/securetty
On 13/11/2020 07:55, steve wrote: Le 12-11-2020, à 17:18:29 +0100, Belaïd a écrit : Bonjour, Le fichier est toujours utilisé de nos jours , c'est juste que les applications n'y accède pas directement mais a travers Pam. Donc ton fichier existe bien sur ta config ? Et que contient-il actuellement ? Non il n'existe pas. Quel paquet aurait dû le créer et quel devrait être son contenu ? Tu peux avoir l'info par la commande suivante: apt-file search /etc/securetty -- Fabien
Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.
On 12/11/2020 21:51, Étienne Mollier wrote: De mon point de vue, Github n'est pas accessible en IPv6, ou du moins, n'en fait pas la publicité : $ host github.com github.com has address 140.82.113.3 github.com mail is handled by 10 alt3.aspmx.l.google.com. github.com mail is handled by 10 alt4.aspmx.l.google.com. github.com mail is handled by 1 aspmx.l.google.com. github.com mail is handled by 5 alt1.aspmx.l.google.com. github.com mail is handled by 5 alt2.aspmx.l.google.com. Ceci pourrait expliquer cela... J'ai également constaté que dig ne renvoyait aucune donnée . -- Fabien
