Re: [testing] passage du pilote proprio à nouveau
Le 31 juillet 2023 Michel a écrit : >> Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs >> mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log > > Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par > défaut, sans modification de startx ou de ~/.xsession ... Ce ne serait pas parce que Xorg est lancé en root ? Par défaut les users n'ont pas accès à /var/log. Vérifie /etc/X11/Xwrapper.config qui doit avoir needs_root_rights=no (du moins si ta carte graphique le permet).
Fwd: Plantage suite à ajout de desktop icon dans /usr/share/applications/
PS En fouillant, je découvre un paquet [ https://www.freedesktop.org/wiki/Software/desktop-file-utils/ | https://www.freedesktop.org/wiki/Software/desktop-file-utils/ ] qui est installé apparemment d'office sur (ma) debian 11. Il propose 3 fonctions : desktop-file-validate desktop-file-install update-desktop-database Confirmez-vous que c'est "l'outil de référence" debian ? Par ailleurs, je lis ici qu'il existe gnome-desktop-item-edit (inexistant sur ma debian 11 gnome) [ https://www.xmodulo.com/create-desktop-shortcut-launcher-linux.html | https://www.xmodulo.com/create-desktop-shortcut-launcher-linux.html ] Cet autre article explique un procédé entièrement manuel (comme je faisais) : [ https://cleberjamaral.hashnode.dev/how-to-create-a-desktop-launcher-on-debian | https://cleberjamaral.hashnode.dev/how-to-create-a-desktop-launcher-on-debian ] Enfin, je n'ai pas "Create Launcher" via un clic droit sur un fichier d'exécutable, comme je le vois sur divers forums. Est-ce normal sur une debian 11 installée avec DE gnome ? Détail de mon exploration de 4 commandes de desktop-file-utils = En CLI, avec desktop-file TAB, je peux faire apparaître : desktop-file-edit -> bizarre, pas dans la doc desktop-file-install desktop-file-validate 1/ Avec desktop-file-edit $ desktop-file-edit ~/Desktop/test.desktop Error on file "/home/test/Desktop/test.desktop": No such file or directory $ touch ~/Desktop/test.desktop $ desktop-file-edit ~/Desktop/test.desktop /home/test/Desktop/test.desktop: error: required key "Type" in group "Desktop Entry" is not present /home/test/Desktop/test.desktop: error: required key "Name" in group "Desktop Entry" is not present Error on file "/home/test/Desktop/test.desktop": Failed to validate the created desktop file ...Après recherche, il faut spécifier comme suit : desktop-file-edit \ --set-name="GIMP on LXD" \ --set-comment="GIMP 2.8 with custom plugins" \ --set-icon="/home/vivek/backups/desktop-entries/gimp.png" \ --add-category="Graphics;2DGraphics;RasterGraphics;GTK;" \ --set-key="Exec" --set-value="/snap/bin/lxc exec gui-1804-gimp -- sudo --login --user vivek /usr/bin/gimp-2.8 %U" \ --set-key="Type" --set-value="Application" \ gimp-2.8.desktop https://www.cyberciti.biz/howto/how-to-install-and-edit-desktop-files-on-linux-desktop-entries/ Mais cette commande, valide, n'est plus mise en avant par la [ https://www.freedesktop.org/wiki/Software/desktop-file-utils/ | doc ] . D'ailleurs : $ dlocate -lsbin desktop-file-utils /usr/bin/desktop-file-install /usr/bin/desktop-file-validate /usr/bin/update-desktop-database et : ~$ dpkg -L desktop-file-utils | grep /usr/bin/ /usr/bin/desktop-file-install /usr/bin/desktop-file-validate /usr/bin/update-desktop-database /usr/bin/desktop-file-edit 2/ Avec desktop-file-install $ sudo desktop-file-install ~/Desktop/test.desktop (OK ; code 0) 3/ Avec desktop-file-validate : La commande indique ce qui cloche, par exemple : warning: key "Encoding" in group "Desktop Entry" is deprecated warning: value "Application;Network;" for key "Categories" in group "Desktop Entry" contains a deprecated value "Application" Pratique ! 4/ Avec update-desktop-database man update-desktop-database dit : "Build cache database of MIME types handled by desktop files" ~$ sudo update-desktop-database -v ... File "/usr/share/applications/remmina-gnome.desktop" lacks MimeType key Notez que ce sont les icônes créées par debian 11... Y a-t-il lieu de corriger ça ? Si oui, comment ? =
Plantage suite à ajout de desktop icon dans /usr/share/applications/
Bonjour, Sous debian 11 et bureau gnome, je crée une desktop icon (~/Desktop). Puis je l’ajoute au repertoire habituel (/user/share/applications/) boum ! Quelques diamants apparaissent en haut à droite d’un écran noir… planté ! Ctrl Alt F2 à F6 me propose une console. Ctrl Alt F1 me propose un accueil graphique, mais impossible d’ouvrir une session. Je suis renvoyé au menu graphique, en boucle. Je redémarre. Je peux alors ouvrir une session. Le répertoire utilisé pour que le programme apparaisse au menu Applications est : /usr/share/applications J’ai fait sudo cp (du bureau vers ce répertoire) puisqu’une simple copie est refusée. Et c’est là que ça a planté. Quelles causes possibles ? J’ai trouvé Categories=Application;Programming; alors qu’aucune catégorie Application n’existe. Une scorie oubliée. Pensez-vous que ça ait pu seul causer le plantage ? J’ai une autre desktop icon avec Application qui n’a pas fait planter la machine et fonctionne actuellement bien. Comment expliquez-vous l’impossibilité d’ouvrir une session graphique sans devoir redémarrer ? Est-ce que je fais une mauvaise manip pour ajouter une application au système (accès par menu Applications et par la Touche recherche) ? Merci.
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 14:05, didier gaumet a écrit : Le 31/07/2023 à 14:00, didier gaumet a écrit : [...] Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou /var/log/Xorg.0.log. [...] (je suis pénible à ne pas me relire soigneusement): Pour un Xorg lancé par root ce devrait être /var/log/Xorg.log ou /var/log/Xorg.0.log. Merci à Michel, Michel et Erwan pour les précisions :-) Donc en cas de besoin chercher à tous les endroits mentionnés et pour éviter les erreurs, vérifier les dates incluses dans les logs pour vérifier qu'on regarde bien le bon fichier log, pas un vieux fichier log plus utilisé
Re: reply-to de la liste
Le 30/07/2023 à 14:29, hamster a écrit : > En essayant je vois que la liste debian-user-french@lists.debian.org n'a > pas de champ "reply-to". Est-ce que c'est voulu ou bien est-ce que c'est > un oubli ? C'est probablement voulu par le projet Debian. Modifier le champ `Reply-to` dans l'en-tête d'un mail est un sujet sensible dans le monde du mail et il y a déjà eu des discussions sur la liste anglaise: https://teams.debian.org/debian-user/2017/06/msg00346.html La documentation de mailman (aussi en anglais) explique bien comment changer le champ `Reply-to` et les 2 points de vue du débat: https://www.gnu.org/software/mailman/mailman-admin/node11.html Les champs List-Id, List-Url, List-Help, List-Unsubscribe, List-Subscribe et List-Post sont également ajoutés. List-Post contient l'adresse à utiliser pour répondre à la liste.
Re: Intérêt d’un « NAS » commercial ou open source ?
Un point important est de régulièrement vérifier ses propres
procédures de restauration (dans des conditions les plus réalistes
possibles).
Le dim. 30 juil. 2023 à 12:22, Sébastien Dinot
a écrit :
>
> Sébastien Dinot a écrit :
> > > Tu expliques bien les intérêts pour la sauvegarde, mais comment se
> > > passe une restauration ?
> >
> > Très bien. :)
>
> Illustration pas plus tard que maintenant, suite à l'effacement
> accidentel d'un message important reçu vendredi après-midi :
>
> # export BORG_RSH="ssh -i /root/.ssh/id_rsa_backup"
>
> # borg list
> ssh://uxxx...@uxx.your-storagebox.de:23/~/backup/borg/{hostname}
> hector-20220228-223303Mon, 2022-02-28 22:33:10 [7bb7..0cf6]
> [...]
> hector-20230728-223304Fri, 2023-07-28 22:33:13 [9b5e..d4df]
> [...]
>
> # borg list
> ssh://uxxx...@uxx.your-storagebox.de:23/~/backup/borg/{hostname}::hector-20230728-223304
> home//mail/inbox
> -rw---4233917 Fri, 2023-07-28 22:31:33
> home//mail/inbox
>
> # cd /tmp
> # borg extract
> ssh://uxxx...@uxx.your-storagebox.de:23/~/backup/borg/{hostname}::hector-20230728-223304
> home//mail/inbox
>
> Et le tour est joué. Récupération dans /tmp/home//mail/inbox de
> l'état de la boite mail en date du 28 juillet au soir, il ne me restait
> plus qu'à aller piocher ledit mail dans ce fichier et à le déplacer dans
> ma boite courante.
>
> Sébastien
>
> --
> Sébastien Dinot, sebastien.di...@free.fr
> http://www.palabritudes.net/
> Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !
>
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 15:20, Michel Verdier a écrit : > Le 31 juillet 2023 didier gaumet a écrit : > >> Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? >> Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg >> lancé par un utilisateur avec un DE il faudra regarder le contenu de >> ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me >> souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour un >> Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou >> /var/log/Xorg.0.log. > > Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs > mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par défaut, sans modification de startx ou de ~/.xsession ...
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 14:00, didier gaumet a écrit : Le 31/07/2023 à 12:49, Gaëtan Perrier a écrit : Pas eu besoin d'attendre longtemps :( Freeze juste après l'envoi du message précédent. Rien dans /var/log/syslog à part une série de ^@ Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg lancé par un utilisateur avec un DE il faudra regarder le contenu de ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou /var/log/Xorg.0.log. Pour tous les fichiers d'erreur Xorg, de mémoire il faut chercher les chaînes EE pour les erreurs et WW pour les avertissements, le reste je crois que c'est principalement II pour info (me rappelle pas bien) Et si tu veux vraiment faire de la plongée (je ne sais plus qui nous parlait de plongée récemment sur cette liste), tu peux essayer de debugger tout ça: https://x.org/wiki/Development/Documentation/ServerDebugging/ En testing ça fait plusieurs mois que les logs users après sddm sont dans journal, plus dans .xsession-errors -- Erwan David
Re: [testing] passage du pilote proprio à nouveau
Le 31 juillet 2023 didier gaumet a écrit : > Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? > Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg > lancé par un utilisateur avec un DE il faudra regarder le contenu de > ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me > souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour un > Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou > /var/log/Xorg.0.log. Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 14:00, didier gaumet a écrit : [...] Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou /var/log/Xorg.0.log. [...] (je suis pénible à ne pas me relire soigneusement): Pour un Xorg lancé par root ce devrait être /var/log/Xorg.log ou /var/log/Xorg.0.log.
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 12:49, Gaëtan Perrier a écrit : Pas eu besoin d'attendre longtemps :( Freeze juste après l'envoi du message précédent. Rien dans /var/log/syslog à part une série de ^@ Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg lancé par un utilisateur avec un DE il faudra regarder le contenu de ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou /var/log/Xorg.0.log. Pour tous les fichiers d'erreur Xorg, de mémoire il faut chercher les chaînes EE pour les erreurs et WW pour les avertissements, le reste je crois que c'est principalement II pour info (me rappelle pas bien) Et si tu veux vraiment faire de la plongée (je ne sais plus qui nous parlait de plongée récemment sur cette liste), tu peux essayer de debugger tout ça: https://x.org/wiki/Development/Documentation/ServerDebugging/
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 12:42 +0200, Gaëtan Perrier a écrit : > Pour l'instant ça semble tourner. Reste à voir si j'ai toujours des freeze ou > pas ... > Pas eu besoin d'attendre longtemps :( Freeze juste après l'envoi du message précédent. Rien dans /var/log/syslog à part une série de ^@ Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 12:05 +0200, didier gaumet a écrit : > Le 31/07/2023 à 11:18, Gaëtan Perrier a écrit : > [...] > > Par contre depuis j'ai constaté que si je mets un fichier xorg.cong > > basique: > > > > Section "Device" > > Identifier "MyGPU" > > Driver "nouveau" > > EndSection > > > > Le support des décodeurs en user est ok ... > > Donc problème résolu ou il reste un autre truc qui ne marche pas (j'ai > pas épluché les sorties de commandes que tu as citées) ? > Alors finalement j'ai fait l'extraction depuis le pilote 340.xxx et ça me sort beaucoup plus de firmwares: ~$ ls /lib/firmware/nouveau/ nv106_fuc084nv98_vp nvc0_bsp nvcf_fuc085 nvf1_fuc084 nv106_fuc085nva3_bsp nvc0_fuc084 nvcf_fuc086 nvf1_fuc085 nv106_fuc086nva3_fuc084 nvc0_fuc085 nvd7_fuc084 nvf1_fuc086 nv108_fuc084nva3_fuc085 nvc0_fuc086 nvd7_fuc085 vuc-h264-0 nv108_fuc085nva3_fuc086 nvc0_ppp nvd7_fuc086 vuc-mpeg12-0 nv108_fuc086nva3_ppp nvc0_vp nvd9_fuc084 vuc-mpeg4-0 nv84_bspnva3_vp nvc1_fuc084 nvd9_fuc085 vuc-mpeg4-1 nv84_bsp-h264 nva5_fuc084 nvc1_fuc085 nvd9_fuc086 vuc-vc1-0 nv84_vp nva5_fuc085 nvc1_fuc086 nve0_bsp vuc-vc1-1 nv84_vp-h264-1 nva5_fuc086 nvc3_fuc084 nve0_vp vuc-vc1-2 nv84_vp-h264-2 nva8_fuc084 nvc3_fuc085 nve4_fuc084 vuc-vp3-h264-0 nv84_vp-mpeg12 nva8_fuc085 nvc3_fuc086 nve4_fuc085 vuc-vp3-mpeg12-0 nv84_vp-vc1-1 nva8_fuc086 nvc4_fuc084 nve4_fuc086 vuc-vp3-vc1-0 nv84_vp-vc1-2 nvaa_fuc084 nvc4_fuc085 nve6_fuc084 vuc-vp3-vc1-1 nv84_vp-vc1-3 nvaa_fuc085 nvc4_fuc086 nve6_fuc085 vuc-vp3-vc1-2 nv84_xuc00f nvaa_fuc086 nvc8_fuc084 nve6_fuc086 vuc-vp4-h264-0 nv84_xuc103 nvac_fuc084 nvc8_fuc085 nve7_fuc084 vuc-vp4-mpeg12-0 nv98_bspnvac_fuc085 nvc8_fuc086 nve7_fuc085 vuc-vp4-mpeg4-0 nv98_fuc084 nvac_fuc086 nvce_fuc084 nve7_fuc086 vuc-vp4-mpeg4-1 nv98_fuc085 nvaf_fuc084 nvce_fuc085 nvf0_fuc084 vuc-vp4-vc1-0 nv98_fuc086 nvaf_fuc085 nvce_fuc086 nvf0_fuc085 vuc-vp4-vc1-1 nv98_pppnvaf_fuc086 nvcf_fuc084 nvf0_fuc086 vuc-vp4-vc1-2 Du coup en user vainfo me retourne : ~$ vainfo libva info: VA-API version 1.19.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so libva info: Found init function __vaDriverInit_1_17 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.19 (libva 2.12.0) vainfo: Driver version: Mesa Gallium driver 22.3.6 for NVCF vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc et vdpauinfo retourne toujours en user: ~$ vdpauinfo display: :1 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types --- 42016384 16384 NV12 YV12 42216384 16384 UYVY YUYV 44416384 16384 Y8U8V8A8 V8U8Y8A8 420_16 16384 16384 422_16 16384 16384 444_16 16384 16384 Decoder capabilities: namelevel macbs width height MPEG1 0 8192 2048 2048 MPEG2_SIMPLE3 8192 2048 2048 MPEG2_MAIN 3 8192 2048 2048 H264_BASELINE 41 8192 2048 2048 H264_MAIN 41 8192 2048 2048 H264_HIGH 41 8192 2048 2048 VC1_SIMPLE 1 8190 2048 2048 VC1_MAIN2 8190 2048 2048 VC1_ADVANCED4 8190 2048 2048 MPEG4_PART2_SP 3 8192 2048 2048 MPEG4_PART2_ASP 5 8192 2048 2048 DIVX4_QMOBILE --- not supported --- DIVX4_MOBILE --- not supported --- DIVX4_HOME_THEATER --- not supported --- DIVX4_HD_1080P --- not supported --- DIVX5_QMOBILE --- not supported --- DIVX5_MOBILE --- not supported --- DIVX5_HOME_THEATER --- not supported --- DIVX5_HD_1080P --- not supported --- H264_CONSTRAINED_BASELINE 41 8192 2048 2048 H264_EXTENDED --- not supported --- H264_PROGRESSIVE_HIGH --- not supported --- H264_CONSTRAINED_HIGH --- not supported --- H264_HIGH_444_PREDICTIVE --- not supported --- VP9_PROFILE_0 --- not supported --- VP9_PROFILE_1 --- not supported --- VP9_PROFILE_2
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 11:18, Gaëtan Perrier a écrit : [...] Par contre depuis j'ai constaté que si je mets un fichier xorg.cong basique: Section "Device" Identifier "MyGPU" Driver "nouveau" EndSection Le support des décodeurs en user est ok ... Donc problème résolu ou il reste un autre truc qui ne marche pas (j'ai pas épluché les sorties de commandes que tu as citées) ?
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 10:00 +0200, didier gaumet a écrit : > Le 31/07/2023 à 00:20, Gaëtan Perrier a écrit : > > Bonjour, > > > > Mon PC étant assez âgé (i5-2500k et Nvidia GTX550Ti) j'utilisais jusqu'à > > maintenant le pilote proprio nvidia 390.157. Tout fonctionnait > > parfaitement. > > Ce pilote n'étant plus maintenu, pas compatible avec kernel 6.4 et retiré > > de > > debian testing j'ai donc décidé de passer à Nouveau. > > apparemment un autre possibilité serait de garder le pilote proprio en > passant de testing à Sid, le pilote proprio y étant toujours disponible > car des modifications mineures ont été apportées pour que ça puisse être > construit avec les noyaux récents, si j'ai bien suivi. A ce que j'ai compris le support "nouveau noyau" s'arrête au 6.3. Quand le 6.4 est arrivé sur ma machine son installation a échoué à cause des pilotes nvidia ... C'est ce qui a motivé mon passage à Nouveau. > > Après c'est à toi de voir, chacun a une perception différente. Perso, > pour moi Debian c'est intéressant en Stable. Mais j'ai déjà joué avec > Testing et Sid par le passé et même Sid+experimental récemment. Je > préférerais suivre Sid que testing, à titre perso, toujours. Ma perception est effectivement différente. ;) Pour moi stable c'est bien sur un serveur. Pour une machine de bureau les appli ne suivent pas assez vite même avec les backports. Après entre testing et sid je n'ai pas vraiment d'avis mais comme ça doit bien faire 20 ans que je tourne en testing (+ qq morceaux sid) je n'ai jamais changé. > > > Mais depuis j'ai régulièrement des freezes et j'ai des doutes sur le fait > > que > > ma config soit correcte. > > > > Pour passer du pilote proprio à Nouveau j'ai donc supprimé tous les paquets > > nvidia-* et libnvidia* > > J'ai supprimé le xorg.conf. > > t'as supprimé ou purgé? Si tu as seulement supprimé, fais un purge des > mêmes paquets, ça peut aider C'était bien un purge qui a été réalisé. > > > J'ai essayé de suivre cette page (qui ne semble pas à jour) pour récupérer > > les > > firmware du pilote 390.157. > > quelle page? oups j'ai oublié le lien :-( https://nouveau.freedesktop.org/VideoAcceleration.html > > > J'ai réussi, après quelques modif du script > > extract_firmware.py, à récupérer les fichiers suivant: > [...] > > tu as essayé avec simplement les firmwares de testing? > firmware-misc-nonfree firmware-nvidia-gsp ou firmware-nvidia-tesla-gsp > A ce que j'ai compris les gsp ne concernent que les cartes depuis l'archi Turing, la mienne est une Fermi bien plus vieille. Pour misc-nonfree oui j'ai essayé mais je n'ai pas les décodeurs. Par contre depuis j'ai constaté que si je mets un fichier xorg.cong basique: Section "Device" Identifier "MyGPU" Driver "nouveau" EndSection Le support des décodeurs en user est ok ... A+ Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
On Monday 31 July 2023 00:20:58 Gaëtan Perrier wrote: > Mon PC étant assez âgé (i5-2500k et Nvidia GTX550Ti) j'utilisais jusqu'à > maintenant le pilote proprio nvidia 390.157. Tout fonctionnait parfaitement. > Ce pilote n'étant plus maintenu, pas compatible avec kernel 6.4 et retiré de > debian testing j'ai donc décidé de passer à Nouveau. Le pilote 390.157 proposé par Nvidia sur son site est en version 32 bits : www.nvidia.fr/Download/driverResults.aspx/196247/fr Pour créer un pilote Nouveau, il faut semble t-il un xorg.conf. J'ai tenté il y a peu, mais résolution maximum 1024X768, trop insuffisant, mais ça m'a permis d'avoir le mode graphique pour rechercher une solution. Désolé de ne pas t'aider plus...
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 00:20, Gaëtan Perrier a écrit : Bonjour, Mon PC étant assez âgé (i5-2500k et Nvidia GTX550Ti) j'utilisais jusqu'à maintenant le pilote proprio nvidia 390.157. Tout fonctionnait parfaitement. Ce pilote n'étant plus maintenu, pas compatible avec kernel 6.4 et retiré de debian testing j'ai donc décidé de passer à Nouveau. apparemment un autre possibilité serait de garder le pilote proprio en passant de testing à Sid, le pilote proprio y étant toujours disponible car des modifications mineures ont été apportées pour que ça puisse être construit avec les noyaux récents, si j'ai bien suivi. Après c'est à toi de voir, chacun a une perception différente. Perso, pour moi Debian c'est intéressant en Stable. Mais j'ai déjà joué avec Testing et Sid par le passé et même Sid+experimental récemment. Je préférerais suivre Sid que testing, à titre perso, toujours. Mais depuis j'ai régulièrement des freezes et j'ai des doutes sur le fait que ma config soit correcte. Pour passer du pilote proprio à Nouveau j'ai donc supprimé tous les paquets nvidia-* et libnvidia* J'ai supprimé le xorg.conf. t'as supprimé ou purgé? Si tu as seulement supprimé, fais un purge des mêmes paquets, ça peut aider J'ai essayé de suivre cette page (qui ne semble pas à jour) pour récupérer les firmware du pilote 390.157. quelle page? J'ai réussi, après quelques modif du script extract_firmware.py, à récupérer les fichiers suivant: [...] tu as essayé avec simplement les firmwares de testing? firmware-misc-nonfree firmware-nvidia-gsp ou firmware-nvidia-tesla-gsp
Re: parametrage avance de thunderbird
Le 31/07/2023 à 07:44, Jean-François Bachelet a écrit :
bien résumons :
- quand je reçois un mail j'en suis le destinataire, ok ?
oui
- alors quand je réponds à ce mail il DOIT mettre le destinataire (moi)
en adresse d'expéditeur. et pas une autre adresse à la tord moi le noeud
prise au hasard gr!
[...]
non
explication: tu es libre de choisir de répondre à un message que tu as
reçu à une de tes adresses e-mail donnée par un e-mail expédié par une
de tes adresses e-mail différente
D'autres contributeurs t'ont déjà apporté les réponses sur les
paramétrages, globaux ou par message, à effectuer pour obtenir le
comportement que tu souhaites.
Si tu préfères l'aide officielle Thunderbird, elle est là:
- comment choisir l'adresse e-mail d'expédition d'un message ("utiliser
les identités"):
https://support.mozilla.org/fr/kb/utiliser-identites-thunderbird#
- pour compléter, comment choisir l'adresse de réponse à laquelle doit
parvenir une éventuelle réponse du destinataire plutôt qu'à l'adresse
d'expédition '"Panneau 'paramètres du compte'"). Voir le champ "adresse
pour la réponse":
https://support.mozilla.org/fr/kb/options-configuration-pour-comptes#
