Re: Impossible to type "ù"
Le 17/12/2019 à 02:33, David Wright a écrit : You don't say what the dedicated key for ù is, but I would expect that you might need something like lv3:ralt_switch in your XKBOPTIONS to get it from one keystroke. I think I'm assuming you have a R-Alt key, sometimes engraved AltGr. (Being English, I compose ù with `u.) Thanks everyone, The problem was fixed by adding lv3:ralt_switch option and a reboot. Pétùr $ cat /etc/default/keyboard # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. XKBMODEL="pc105" XKBLAYOUT="fr" XKBVARIANT="" XKBOPTIONS="lv3:ralt_switch,compose:menu,terminate:ctrl_alt_bksp" BACKSPACE="guess"
Impossible to type "ù"
Hi, I cannot type "ù" anymore on Debian Xfce Sid (French keyboard). All other accented character (éàûè) work but the cursor just blinked when using the dedicated key for "ù". Any clue? $ 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= I tried different keyboard configuration with # dpkg-reconfigure keyboard-configuration the current one: # cat /etc/default/keyboard # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. XKBMODEL="pc105" XKBLAYOUT="fr" XKBVARIANT="" XKBOPTIONS="compose:lwin,terminate:ctrl_alt_bksp" BACKSPACE="guess"
Re: Dualscreen not supported after update
Le 02/09/2019 à 13:42, Pétùr a écrit : > After upgrading my Debian sid this morning, I cannot use anymore my > external screen (plugged into a Dell WD15 dock). > > My system (Xfce) sees the monitor but nothing is displayed. Ok, it works again after downgrading to sid version firmware-linux-nonfree # apt install firmware-linux-nonfree/testing Hope this will be fixed soon.
Dualscreen not supported after update
After upgrading my Debian sid this morning, I cannot use anymore my external screen (plugged into a Dell WD15 dock). My system (Xfce) sees the monitor but nothing is displayed. Am I the only one affected? Here is the upgrade log. Do you see anything which can explain the bug? Start-Date: 2019-09-02 11:24:18 Commandline: apt-get upgrade Upgrade: libreoffice-wiki-publisher:amd64 (1.2.0+LibO6.3.0-2, 1.2.0+LibO6.3.1~rc2-3), texlive-plain-generic:amd64 (2019.20190824-1, 2019.20190830-1), libreoffice-math:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), libusb-1.0-0:amd64 (2:1.0.22-2, 2:1.0.23-1), libreoffice-script-provider-js:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), fuse:amd64 (2.9.9-1, 2.9.9-2), libreoffice-report-builder-bin:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), liblouisutdml-data:amd64 (2.7.1-2, 2.7.1-3), texlive-font-utils:amd64 (2019.20190824-1, 2019.20190830-1), firmware-iwlwifi:amd64 (20190717-1, 20190717-2), libcups2:amd64 (2.2.12-1, 2.2.12-2), libreoffice-sdbc-postgresql:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), texlive-latex-base:amd64 (2019.20190824-1, 2019.20190830-1), pandoc-citeproc:amd64 (0.14.3.1-4+b3, 0.15.0.1-1), libreoffice-sdbc-mysql:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), node-chalk:amd64 (2.3.0-2, 2.4.2-1), libmaven-resolver-java:amd64 (1.4.0-2, 1.4.1-1), libnorm1:amd64 (1.5.8+dfsg2-1, 1.5.8+dfsg2-2), libreoffice-gtk2:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), libreoffice-java-common:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), libgegl-0.4-0:amd64 (0.4.14-1, 0.4.14-1+b1), grub-common:amd64 (2.04-2, 2.04-3), libreoffice-base:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), node-semver:amd64 (5.5.1-1, 5.7.1-1), libreoffice-core:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), liblouis17:amd64 (3.10.0-1, 3.10.0-3), texlive-fonts-recommended-doc:amd64 (2019.20190824-1, 2019.20190830-1), firmware-amd-graphics:amd64 (20190717-1, 20190717-2), libtirpc-common:amd64 (1.1.4-0.4, 1.1.4-1), texlive-base:amd64 (2019.20190824-1, 2019.20190830-1), runit-helper:amd64 (2.8.13.2, 2.8.14), python3-pyatspi:amd64 (2.33.90+really2.32.1+dfsg-3, 2.33.90+really2.32.1+dfsg-4), python3-louis:amd64 (3.10.0-1, 3.10.0-3), grub2-common:amd64 (2.04-2, 2.04-3), texlive:amd64 (2019.20190824-1, 2019.20190830-1), cups-server-common:amd64 (2.2.12-1, 2.2.12-2), elpa-boxquote:amd64 (2.1-2, 2.1-3), libreoffice-l10n-fr:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), texlive-pictures:amd64 (2019.20190824-1, 2019.20190830-1), libreoffice-librelogo:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), cups-common:amd64 (2.2.12-1, 2.2.12-2), libreoffice-sdbc-firebird:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), texlive-lang-french:amd64 (2019.20190824-1, 2019.20190830-1), python3-uno:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), texlive-fonts-recommended:amd64 (2019.20190824-1, 2019.20190830-1), php-composer-ca-bundle:amd64 (1.2.3-1, 1.2.4-1), python3-tzlocal:amd64 (2.0.0b2-1, 2.0.0b2-3), texlive-latex-extra:amd64 (2019.20190824-1, 2019.20190830-1), libaom0:amd64 (1.0.0-3, 1.0.0.errata1-2), libreoffice-script-provider-python:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), libreoffice-base-core:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), cups-filters:amd64 (1.25.3-1, 1.25.4-1), libreoffice-impress:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), acpi-support-base:amd64 (0.143-2, 0.143-3), grub-efi-amd64-bin:amd64 (2.04-2, 2.04-3), libreoffice-help-fr:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), cups-ppdc:amd64 (2.2.12-1, 2.2.12-2), firmware-linux-nonfree:amd64 (20190717-1, 20190717-2), rpl:amd64 (1.6.1-3, 1.6.1-4), libdvbpsi10:amd64 (1.3.2-1, 1.3.3-1), liblouisutdml9:amd64 (2.7.1-2, 2.7.1-3), whiptail:amd64 (0.52.21-2, 0.52.21-3), libreoffice-help-common:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), libnewt0.52:amd64 (0.52.21-2, 0.52.21-3), libfuse2:amd64 (2.9.9-1, 2.9.9-2), libcupsfilters1:amd64 (1.25.3-1, 1.25.4-1), texlive-pstricks-doc:amd64 (2019.20190824-1, 2019.20190830-1), libgcrypt20:amd64 (1.8.4-5, 1.8.5-2), libtirpc3:amd64 (1.1.4-0.4, 1.1.4-1), libreoffice-style-colibre:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), acpi-support:amd64 (0.143-2, 0.143-3), ure:amd64 (6.3.0-2, 6.3.1~rc2-3), libreoffice-sdbc-hsqldb:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), libreoffice-writer:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), libreoffice-common:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), libreoffice-script-provider-bsh:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), libghc-pandoc-citeproc-data:amd64 (0.14.3.1-4, 0.15.0.1-1), texlive-pstricks:amd64 (2019.20190824-1, 2019.20190830-1), libfontembed1:amd64 (1.25.3-1, 1.25.4-1), exactimage:amd64 (1.0.2-4, 1.0.2-5), debhelper:amd64 (12.5.3, 12.5.4), libhogweed4:amd64 (3.4.1-1+b1, 3.5.1+really3.4.1-1), grub-efi-amd64:amd64 (2.04-2, 2.04-3), firmware-misc-nonfree:amd64 (20190717-1, 20190717-2), liblouisutdml-bin:amd64 (2.7.1-2, 2.7.1-3), libreoffice-nlpsolver:amd64 (0.9+LibO6.3.0-2, 0.9+LibO6.3.1~rc2-3), libnettle6:amd64 (3.4.1-1+b1, 3.5.1+really3.4.1-1), libparlatype2:amd64 (1.6.1-2, 1.6.1-3), xfce4-genmon-plugin:amd64 (4.0.1-2, 4.0.2-1), cups-filters-core-drivers:amd64 (1.25.3-1, 1.25.4-1), findutils:amd64 (4.6.0+git+20190510-2, 4.7.0-1), libreoffice:amd64 (1:6.3.0-2, 1:6.3.1~rc2-3), grub-efi-amd64-signed:amd64 (1+2.04+2, 1+2.04+3), fonts-opensy
Re: trying to grab video of screen on a Thinkpad x130e netbook . . .
On 24/08/19 13:29, Albretch Mueller wrote: How can I make a video from what is displayed on the screen using ffmpeg, aconv or whatever? ffmpeg -f x11grab -s 1280x720 -r 25 -i :0.0 screencast.mp4
Re: Detour: notmuch advertisement (was: emacs save and kill buffer for (neo)mutt)
On 13/04/19 01:43, Peter Wiersig wrote:
Pétùr writes:
I use neomutt with emacs.
If you're using the kitchen sink, why not stay completely in emacs?
https://emacs.stackexchange.com/q/12927
(Disclaimer: I wrote one of the answers to that meta question)
I used mutt for decades, I still think it's a fine tool, but I found
more happiness in my chosen "notmuch" mail setup. David & the bunch are
doing a terrific job with the project as whole and the debian packages
in focus, and even if you're building the project directly from the
repository, it's no bother with dabian (even stable).
What I gained by dropping mutt was an uninterupted access to the rest of
my life in emacs, and the user interface is streamlined to hundreds or
thousands of replied messages a day.
A I finish this post, the next keypress will be C-c C-c like many other
emacs modes, which will send the mail to the list, bury the buffer and
redisplay the search results, where I filtered for debian-user and
unread before.
Thanks, I will definitly consider using notmuch inside emacs. I already
have my email fetched by offlineimap and I use mutt-notmuch inside mutt to
search email (with the code below).
I have some work to do (for example, I have some difficulty with
notmuch's spirit of doing everything with a search; for now I am unable
to display only my inbox inside notmuch-emacs...).
###
# Notmuch integration #
###
macro index,pager \
"unset wait_keynotmuch-mutt --prompt
search`echo
${XDG_CACHE_HOME:-$HOME/.cache}/notmuch/mutt/results`" \
"notmuch: search mail"
macro index,pager \
"unset wait_keynotmuch-mutt
thread`echo
${XDG_CACHE_HOME:-$HOME/.cache}/notmuch/mutt/results`set wait_key" \
"notmuch: reconstruct thread"
macro index,pager \
"unset wait_keynotmuch-mutt tag
-inbox" \
"notmuch: remove message from inbox"
Re: emacs save and kill buffer for (neo)mutt
Thanks. In fact my code was working, but the terminal I used (xfce4-terminal) has a built-in shortcut for "quit" binded to Ctrl+q. This is why Emacs, when launched inside xfce4-terminal, closes instead of going back to mutt. Silly...
Re: emacs save and kill buffer for (neo)mutt
On 12/04/19 13:00, David Wright wrote: On Fri 12 Apr 2019 at 18:04:45 (+0200), Pétùr wrote: I use neomutt with emacs. I would like to quickly save and kill a buffer in emacs. This is to avoid typing C-x C-s and, then, C-x C-c when sending an email. I want one shortcut to save and kill the buffer and be back quickly in mutt to send the email. I tried the following inside my .emacs (binded to C-q). It works but kill also the window when inside a terminal. I am not going back to mutt after writing inside emacs (-nw) and C-q. How can I fix that? I just put (global-set-key [?\C-q] "\C-x\C-s\C-x\C-c") into my ~/.emacs file and it works just as one would expect, both when emacs is running in a separate window (which disappears) or when emacs is running with -nw in an xterm (the xterm is unaffected). I will finish composing this email (in emacs -nw) by typing ^q and expect to be left in mutt, whereupon I shall press y to send it. Is that what you wnat? (Sorry for the late reply) Yes, this is exactly what I want to do. (global-set-key [?\C-q] "\C-x\C-s\C-x\C-c") works as expected when emacs is launched as an instance. But I use it as a daemon. When emacs is launched by "emacs --daemon" and called by emacsclient, your shortcut will kill the buffer and I am not going back to mutt. I have to dig into my tmp folder to retrieve the email I was trying to send. The same behavior occures with the code I use. (see first email). How can I prevent this? Pétùr
emacs save and kill buffer for (neo)mutt
I use neomutt with emacs. I would like to quickly save and kill a buffer in emacs. This is to avoid typing C-x C-s and, then, C-x C-c when sending an email. I want one shortcut to save and kill the buffer and be back quickly in mutt to send the email. I tried the following inside my .emacs (binded to C-q). It works but kill also the window when inside a terminal. I am not going back to mutt after writing inside emacs (-nw) and C-q. How can I fix that? ;; Kill the current buffer immediatly, saving it if needed. (defvar kill-save-buffer-delete-windows t "*Delete windows when `kill-save-buffer' is used. If this is non-nil, then `kill-save-buffer' will also delete the corresponding windows. This is inverted by `kill-save-buffer' when called with a prefix.") (defun kill-save-buffer (arg) "Save the current buffer (if needed) and then kill it. Also, delete its windows according to `kill-save-buffer-delete-windows'. A prefix argument ARG reverses this behavior." (interactive "P") (let ((del kill-save-buffer-delete-windows)) (when arg (setq del (not del))) (when (and (buffer-file-name) (not (file-directory-p (buffer-file-name (save-buffer)) (let ((buf (current-buffer))) (when del (delete-windows-on buf)) (kill-buffer buf (global-set-key (kbd "C-q") 'kill-save-buffer)
Re: Slow firefox and high cpu usage
Le 10/10/2018 à 20:43, Sven Joachim a écrit : > Try killing xfsettingsd, that helps according to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909818#15. Thanks! I can confirm killing xfsettingsd fixes the issue (but Xfce is not really usable after that). I have launch again xfsettings with the debug option and use firefox, I have the following messages related to fontconfig. $ XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon xfce4-settings(fontconfig): monitoring 131 paths xfce4-settings(workspaces): 4 desktop names set from xfconf xfce4-settings(fontconfig): timestamp updated (time=1539336916) xfce4-settings(xsettings): 33 settings changed (serial=1, len=1252) xfce4-settings(fontconfig): monitoring 131 paths xfce4-settings(fontconfig): timestamp updated (time=1539336919) xfce4-settings(xsettings): 33 settings changed (serial=2, len=1252) xfce4-settings(fontconfig): monitoring 131 paths Fontconfig warning: Directory/file mtime in the future. New fonts may not be detected. xfce4-settings(fontconfig): timestamp updated (time=1539336922) xfce4-settings(xsettings): 33 settings changed (serial=3, len=1252) xfce4-settings(fontconfig): monitoring 131 paths Fontconfig warning: Directory/file mtime in the future. New fonts may not be detected. xfce4-settings(fontconfig): timestamp updated (time=1539336925) xfce4-settings(xsettings): 33 settings changed (serial=4, len=1252) xfce4-settings(fontconfig): monitoring 131 paths xfce4-settings(fontconfig): timestamp updated (time=1539336928) xfce4-settings(xsettings): 33 settings changed (serial=5, len=1252) xfce4-settings(fontconfig): monitoring 131 paths xfce4-settings(fontconfig): timestamp updated (time=1539336931) xfce4-settings(xsettings): 33 settings changed (serial=6, len=1252) xfce4-settings(fontconfig): monitoring 131 paths xfce4-settings(fontconfig): timestamp updated (time=1539336934) xfce4-settings(xsettings): 33 settings changed (serial=7, len=1252) xfce4-settings(fontconfig): monitoring 131 paths xfce4-settings(fontconfig): timestamp updated (time=1539336937) xfce4-settings(xsettings): 33 settings changed (serial=8, len=1252) xfce4-settings(fontconfig): monitoring 131 paths
Re: Slow firefox and high cpu usage
Le 10/10/2018 à 23:57, Dan Ritter a écrit : I don't know what that is, exactly, but advertising and trackers now take up 90% of most web processing time and space. Running a good ad blocker like uBlock Origin will help a lot. I use ublock origin (installed from firefox addons "store" not from debian package webext-ublock-origin). I will tried to use webext-ublock-origin instead and keep you informed. Petùr
Re: Slow firefox and high cpu usage
Le 09/10/2018 à 02:04, Patrick Bartek a écrit : First, Firefox is using 50% of your RAM. That's way too much unless you have very little RAM to begin with. How much total RAM do you have? My system has 8GB. Firefox Quantum only shows on average 3 to 4% RAM usage even when streaming a video. I have 8GB of RAM. Also, check what those three "web contents" are. I'm think THEY are the cause of Firefox's slowness. As I don't know what they are, I can't hazard a guess as to what's causing the high CPU usage. The only time I've seen something like this is when an app has crashed into an infinite loop of some sort. "Kill" those one at a time and see what happens to Firefox's CPU usage. Also, clear you cache. Check to see if files are being written continuously to your hard drive. I think also these "web content" threads are the causes of my problem. But they appears even if I disable all modules. FWIW, I'd purge Firefox and reinstall. You're running Sid after all, and all kinds of things can go wrong at any time. Why ARE you running Sid anyway? I did purge and refresh (ie new profile) firefox. I don't complain for this bug. I use sid because I need last versions of some packages for my work. Pétùr
Re: Slow firefox and high cpu usage
Le 08/10/2018 à 23:31, Ben Caradoc-Davies a écrit : I have slow startup and a brief hang during initial UI layout, but only with Adblock Plus enabled. Thanks for the report. I have the same behavior (and lag when creating new tab) but even with all the modules (including ublock) disabled.
Re: Slow firefox and high cpu usage
Le 08/10/2018 à 20:59, Patrick Bartek a écrit : On Mon, 8 Oct 2018 20:07:26 +0200 Pétùr wrote: Hi, I experience a very slow response time (and high cpu usage) for firefox in debian sid these days. I use the 62.0.3 version and the latency is particularly present at the startup. I have to wait few seconds before being able to enter text in the address bar. I tried to reset (install new profile) firefox and launch it in safe mode (ie without extensions). No improvements. Are other users of sid experiencing the same behavior ? I'm using Firefox Quantum (62.0.3) on Stretch. Works just fine. Responsive. Very Little CPU usage. What does Top show is using the cpu? Top shows several threads with high cpu usage such as : PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 12452 petur20 0 4030664 1,9g 67248 R 72,4 50,1 2:54.34 firefox 12937 petur20 0 1830092 381016 156676 R 82,7 9,7 0:12.11 Web Content 12503 petur20 0 1715976 216820 87436 R 81,3 5,5 0:55.60 Web Content 13078 petur20 0 1454508 95080 65480 R 81,3 2,4 0:05.02 Web Content I am using Xfce. Pétùr
Slow firefox and high cpu usage
Hi, I experience a very slow response time (and high cpu usage) for firefox in debian sid these days. I use the 62.0.3 version and the latency is particularly present at the startup. I have to wait few seconds before being able to enter text in the address bar. I tried to reset (install new profile) firefox and launch it in safe mode (ie without extensions). No improvements. Are other users of sid experiencing the same behavior ? Pétùr
openssl 1.1.1-1: bug?
Hi, I cannot connect to WPA2 Entreprise network (PEAP + MSCHAPv2) with openssl 1.1.1-1 (in sid today). I can connect 1.1.0f-3+deb9u2 version (stable). Is it a bug in openssl 1.1.1-1 or some kind of incompatibility between openssl 1.1.1-1 and my radius server? The error log with the 1.1.1-1 version says: Tue Oct 2 14:07:43 2018 : Error: TLS Alert write:fatal:protocol version Tue Oct 2 14:07:43 2018 : Error: rlm_eap: SSL error error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Tue Oct 2 14:07:43 2018 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails. Tue Oct 2 14:07:43 2018 : Auth: Login incorrect (TLS Alert write:fatal:protocol version): [lo...@myuniversity.com] Pétùr
WPA error: TLS Alert write:fatal:protocol version
Le 03/10/2018 à 16:35, Dominik George a écrit : > >> I tried to add "phase1="tls_disable_tlsv1_2=1"" (see below the complete >> wpa_supplicant configuration. > That leaves you with only TLS 1.3, then ;). Ok :-) > You probably want to set tls_disable_tlsv1_1=0 instead, but I did not try > (because please update the RADIUS server). I tried this. With tls_disable_tlsv1_1=0 I have the alert (with no working connexion): SSL: SSL3 alert: write (local SSL3 detected an error):fatal:protocol version OpenSSL: openssl_handshake - SSL_connect error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol wlp3s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed Anyway, it seems the TLS version is not the issue here. Indeed, I tried also to downgrade openssl to the stable version (I use sid). After that, wpa_supplicant can connect. So the problem is a bug from openssl 1.1.1-1. I didn't see this before because network-manager was not able to connect the first time I tried to downgrade openssl. But wpa_supplicant does and now network-manager does so I probably misconfigured nm the first time. Thanks for the help
Re: WPA error: TLS Alert write:fatal:protocol version
Le 02/10/2018 à 17:09, Dominik George a écrit :
> On Tue, Oct 02, 2018 at 04:08:41PM +0200, Pétùr wrote:
>> On debian sid, I have the following error when trying to connect to a WPA2
>> Entreprise network (PEAP + MSCHAPv2) with :
>>
>> Tue Oct 2 14:07:43 2018 : Error: TLS Alert write:fatal:protocol version
>> Tue Oct 2 14:07:43 2018 : Error: rlm_eap: SSL error error:1408F10B:SSL
>> routines:SSL3_GET_RECORD:wrong version number
>> Tue Oct 2 14:07:43 2018 : Error: SSL: SSL_read failed in a system call
>> (-1), TLS session fails.
>> Tue Oct 2 14:07:43 2018 : Auth: Login incorrect (TLS Alert
>> write:fatal:protocol version): [lo...@myuniversity.com]
> OpenSSL 1.1.1, and pretty much everything using it, is now disabling TLS 1.1
> by default. That's probably what you see here, and it means that your RADIUS
> server supports only deprecated TLS versions.
>
> You can enable TLS 1.1 in your wpa_supplicant config, but the real fix is to
> enable TLS 1.2 on your RADIUS server. That has been enabled by default in
> freeradius in Debian since at least jessie, to give you an idea of how
> outdated the setup is ;).
Thanks, I think the tls version is the problem.
I configured wpa_supplicant (because network-manager does not offer
option for the TLS version).
Do you know what exact option is needed by wpa_supplicant to allow TLS 1.1 ?
I tried to add "phase1="tls_disable_tlsv1_2=1"" (see below the complete
wpa_supplicant configuration.
With this option, I don't have the error message but I don't have a
working connexion either.
/etc/wpa_supplicant/wpa_supplicant.conf
network={
ssid="University network"
key_mgmt=WPA-EAP
pairwise=CCMP
group=CCMP TKIP
eap=PEAP
ca_cert="/home/petur/.cat_installer/ca.pem"
identity="n...@univeristy.com"
domain_suffix_match="radius.university.com"
phase1="tls_disable_tlsv1_2=1"
phase2="auth=MSCHAPV2"
password="xxx"
anonymous_identity="anonym...@university.com"
}
Pétùr
WPA error: TLS Alert write:fatal:protocol version
On debian sid, I have the following error when trying to connect to a WPA2 Entreprise network (PEAP + MSCHAPv2) with : Tue Oct 2 14:07:43 2018 : Error: TLS Alert write:fatal:protocol version Tue Oct 2 14:07:43 2018 : Error: rlm_eap: SSL error error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Tue Oct 2 14:07:43 2018 : Error: SSL: SSL_read failed in a system call (-1), TLS session fails. Tue Oct 2 14:07:43 2018 : Auth: Login incorrect (TLS Alert write:fatal:protocol version): [lo...@myuniversity.com] It is probably a bug with a package. I tried to downgrade openssl and libgnutls-openssl27 without any change. Any idea? Pétùr
Re: File with weird permissions, impossible to delete
Le 18/09/2018 à 15:46, David Wright a écrit : >> How can I delete these files without formating ? > To what end? I think you've now got an indication of a problem > somewhat more serious than some software dreaming up crazy > file permissions and timestamps. > > I would now be looking at rescuing everything you can from the drive > without prejudicing any backups you already have. Meanwhile I'd be > trying to determine the source of this corruption. It's rather > worrying that you've had both internal and external drives > affected. That's outside my experience. It is a external hard drive plugged to another computer than the first one with the file corruption problem. This corrupted files are from a internal hard drive which was in a dead computer. I backup the file and now I just want to clean my external HDD. Pétùr
Re: File with weird permissions, impossible to delete
Le 11/09/2018 à 13:52, Pétùr a écrit : > I have some files, with weird permissions: > > # ls -la > d-wS--S--T 2 1061270772 2605320832 4096 oct. 7 2412 index.html > > Cannot delete, cannot change owner or group (what is this user > 1061270772 and group 2605320832 by the way?) even for root. > > How can I get rid of these? > > Pétùr > Another example of weird permissions today for a file on an external hard drive (ntfs) # ll ls: cannot access 'Western_Europe.zip': No such file or directory total 21 -rwxrwxrwx 1 petur petur 228 Mar 31 2010 activation_map_51183.cab -rwxrwxrwx 1 petur petur 10410 Mar 31 2010 map14655-1.gif -rwxrwxrwx 1 petur petur 1737 Mar 31 2010 map14655.gif -? ? ? ? ?? Western_Europe.zip -rwxrwxrwx 1 petur petur 3236 Mar 31 2010 We풦tern_Europe.toc # rm -rfv * rm: cannot remove 'activation_map_51183.cab': Input/output error rm: cannot remove 'map14655-1.gif': Input/output error rm: cannot remove 'map14655.gif': Input/output error How can I delete these files without formating ?
Emacs and message-mode: save and close buffer
I have this code in my .emacs to save and close the buffer with C-c C-c. It is designed to use with message-mode for going back to mutt after writing an email. However, it doesn't save the buffer. If I compose an email and never press C-x C-s, C-c C-c will just close the buffer and erase it with nothing left to send. Pretty annoying! (add-hook 'message-mode-hook (lambda () (define-key mail-mode-map [(control c) (control c)] (lambda () (interactive) (save-buffer) (server-edit) What can I change?
Re: Gimp Babl too old
On 13/09/18 07:03, Tixy wrote: On Wed, 2018-09-12 at 19:54 +0200, Étienne Mollier wrote: At first, it sounded like the last `apt update` execution occurred some time between “libbabl-dev” and “libbabl-0.1-0” upgrade to version 0.1.56-1 on repositories side. But “libbabl-0.1-0” seems somehow picked from another repository, the version convention “1:0.1.44-dmo1” looks like it is designed to supersede Debian's initial package on purpose. Sounds like the sort of thing the third party repository at deb-multimedia.org does, and the 'dmo1' in the package name is a big clue that is the case here. Basically, every time a version of a library in deb-multimedia falls behind Debian you're likely to get some kind of breakage, because it has used the epoch number to fake up this 'I'm a higher version so install me instead of the of official Debian library'. If the OP is running Sid with deb-multimedia then this sort of thing is going to be a reoccurring problem. Thnaks for the explanatio. I was indeed using deb-multimedia.org repository a while ago. Mystery solved!
Re: File with weird permissions, impossible to delete
Le 12/09/2018 à 01:43, Felix Miata a écrit : >> I deleted the file >> .cache/shotwell/thumbs/thumbs360/thumb0c5c.jpg > Deleted exactly how? `rm -vf` in root >> without issue after chattr -i on this file. >> However, it didn't work for the index.html file which is considered as a >> folder. > Exactly how did you try? `rm -rvf` in root
Re: Gimp Babl too old
Le 11/09/2018 à 20:09, Dan Ritter a écrit : > > and a check says that sid now has a version 0.1.56 of babl, so > you should try installing that. Hi, I can only find the 0.1-0 version: $ apt search libbabl En train de trier... Fait Recherche en texte intégral... Fait libbabl-0.1-0/now 1:0.1.44-dmo1 amd64 [installé, local] Dynamic, any to any, pixel format conversion library libbabl-0.1-0-dbg/stable 0.1.18-1 amd64 bibliothèque dynamique de conversion de tous types de formats de pixels –⋅symboles de débogage libbabl-dev/unstable,testing 0.1.56-1 amd64 bibliothèque dynamique de conversion de tous types de formats de pixels –⋅fichiers de développement libbabl-doc/unstable,testing 0.1.56-1 all bibliothèque dynamique de conversion de tous types de formats de pixels –⋅documentation
Re: File with weird permissions, impossible to delete
Le 11/09/2018 à 19:34, Martin a écrit : don't get crazy about FS corruption. There is no sign this is the case so far. Date and UID's are odd, but valid within ext4. Remove the immutable flag (chattr -i), you will be able to alter the files as you like. One hint will be, check if your system time is ok (both, date and hwclock!), may be there is a reason for this odd timestamps. Thanks for the reassuring words. I deleted the file .cache/shotwell/thumbs/thumbs360/thumb0c5c.jpg without issue after chattr -i on this file. However, it didn't work for the index.html file which is considered as a folder. # ls -la .local/share/Trash/expunged/1257950219/ myfolder/files/fullsize/index.html total 16 d-wS--S--T 2 1061270772 2605320832 4096 oct. 7 2412 . drwx-- 3 petur petur 12288 avril 25 12:21 ..
Gimp Babl too old
Gimp does not start on debian sid and shows the message: --- BABL version too old! GIMP requires BABL version 0.1.56 or later. Installed BABL version is 0.1.44. Somehow you or your software packager managed to install GIMP with an older BABL version. Please upgrade to BABL version 0.1.56 or later. --- How to fix it? I tried purge and reinstall, installing gegl. Pétùr
Re: File with weird permissions, impossible to delete
Le 11/09/2018 à 16:44, Michael Stone a écrit : On Tue, Sep 11, 2018 at 08:59:56AM -0400, Greg Wooledge wrote: On Tue, Sep 11, 2018 at 01:52:15PM +0200, Pétùr wrote: I have some files, with weird permissions: # ls -la d-wS--S--T 2 1061270772 2605320832 4096 oct. 7 2412 index.html Obvious file system corruption. Unmount, fsck, re-mount, and then be prepared to restore the data from your last good backup if/when the fsck failed to repair everything. +1, except that fsck is not likely to help and you should probably move right to backups. (looking through the backups to find out when the corruption started...) Mike Stone Thanks everyone for the output. I have theses two files for quite some time now and the system is working great without any issue. Maybe these files were generated by a power shutdown or by a partition full (my machine was not rebooting correctly sometimes ago because a script fills out all the space available). The permissions of the folders of the corrupt files are normal. I will make some backup, then try fsck and leave the corrupted files if fsck doesn't get rid of them, maybe reformate later. Pétùr
Re: File with weird permissions, impossible to delete
I have two files with this problem. The first one (index.html) which is considered as directory is in .local/share/Trash/expunged and the second one is a thumb of shotwell: $ ls -la .cache/shotwell/thumbs/thumbs360/thumb0c5c.jpg --wS-w--wT 1 680132648 44094674 24576 mars 27 2211 .cache/shotwell/thumbs/thumbs360/thumb0c5c.jpg Le 11/09/2018 à 14:27, Martin a écrit : > What file system? ext4 > What does 'lsattr' say? # lsattr .cache/shotwell/thumbs/thumbs360/thumb0c5c.jpg s---i-d---j .cache/shotwell/thumbs/thumbs360/thumb0c5c.jpg > rm # rm -fvr .cache/shotwell/thumbs/thumbs360/thumb0c5c.jpg rm: cannot remove '.cache/shotwell/thumbs/thumbs360/thumb0c5c.jpg': Operation not permitted (the same for chown) > What do you get from command stat index.html stat .cache/shotwell/thumbs/thumbs360/thumb0c5c.jpg File: .cache/shotwell/thumbs/thumbs360/thumb0c5c.jpg Size: 24576 Blocks: 32 IO Block: 4096 regular file Device: 802h/2050d Inode: 4744568 Links: 1 Access: (5222/--wS-w--wT) Uid: (680132648/ UNKNOWN) Gid: (44094674/ UNKNOWN) Access: 2017-07-08 16:44:21.763005816 +0200 Modify: 2211-03-27 19:08:40.011012642 +0100 Change: 2290-05-04 13:52:16.011012642 +0100 Birth: -
File with weird permissions, impossible to delete
I have some files, with weird permissions: # ls -la d-wS--S--T 2 1061270772 2605320832 4096 oct. 7 2412 index.html Cannot delete, cannot change owner or group (what is this user 1061270772 and group 2605320832 by the way?) even for root. How can I get rid of these? Pétùr
Re: Downgrade to Stable
> On Tue, Sep 04, 2018 at 10:23:08AM +0200, Rodolfo Medina wrote: >> A few days ago I downgraded my Debian installation from Sid to Stable by >> changing, in /etc/apt/sources list, all occurrences of `unstable' to `stable' [... >> But still, at log in in tty console, there is: >> >> Debian GNU/Linux buster/sid lennovo tty1 >> >> How come? The default behavior for apt is to install new versions of packages. When changing sid by stable in /etc/apt/sources.list, apt will wait (a long time) for a new version of a package. So if you install Sid, change for stable, you have to wait few years for one or two new stables versions, then you will have a stable installation... On 04/09/2018 12:07, Dan Ritter wrote: > However, if you want to try: > > http://linuxmafia.com/faq/Debian/downgrade.html As suggested by the link of Dan Ritter, you can change the behavior for apt and force the installation of a selected version of packages (ie stable). However, I do not recommend this. For example, there is no guarantee the configuration of packages can be downgraded. It is much simpler to backup data and reinstall stable. Pétùr
Re: New su behavior in util-linux 2.32
Le 11/08/2018 à 13:42, Nicolas George a écrit : > Pétùr (2018-08-11): >> The new 'su' is useless for me because it cannot launch root program. > Maybe learn how to use $PATH? If I modify $PATH for the new "su", I basically re-implement the old behavior of "su". This is exactly what adding 'ALWAYS_SET_PATH yes' in /etc/login.defs does (and I did that). My question was not to modify new "su" but why old "su" is bad practice.
Re: New su behavior in util-linux 2.32
Le 11/08/2018 à 16:03, Curt a écrit : > There was a lengthy discussion, but within it I don't remember anyone > detailing the numerous reasons (or any reason at all) executing plain > 'su' is a "really bad idea," (where I'm reading "really bad idea" to > mean having unintended and very detrimental consequences to the > hapless user). Sorry I missed the discussion (it was during my vacation). I read it quickly and, indeed, there is no proper explanation why old "su" is dangerous to use or a bad idea.
New su behavior in util-linux 2.32
Using 'su' generates now an path error when launching programs such as 'shutdown'. The cause is a new behavior described below. --- util-linux (2.32-0.4) unstable; urgency=medium The util-linux implementation of /bin/su is now used, replacing the one previously supplied by src:shadow (shipped in login package), and bringing Debian in line with other modern distributions. The two implementations are very similar but have some minor differences (and there might be more that was not yet noticed ofcourse), e.g. - new 'su' (with no args, i.e. when preserving the environment) also preserves PATH and IFS, while old su would always reset PATH and IFS even in 'preserve environment' mode. - su '' (empty user string) used to give root, but now returns an error. - previously su only had one pam config, but now 'su -' is configured separately in /etc/pam.d/su-l The first difference is probably the most user visible one. Doing plain 'su' is a really bad idea for many reasons, so using 'su -' is strongly recommended to always get a newly set up environment similar to a normal login. If you want to restore behaviour more similar to the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs. --- The new 'su' is useless for me because it cannot launch root program. I did the modification in /etc/login.defs and restore the previous behavior. However I am concern with the statement " Doing plain 'su' is a really bad idea for many reasons". Could someone explain to me why this is a bad behavior? Pétùr
Re: Nvidia 340 driver bug
Le 02/06/2018 à 17:17, dekkz...@gmail.com a écrit : > > > This is a bug in the nvidia driver module. There is not much you can do > until it is fixed upstream. > > https://devtalk.nvidia.com/default/topic/1031067/ > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899201 There is a patch : https://bugzilla.redhat.com/attachment.cgi?id=1425704 https://bugzilla.redhat.com/show_bug.cgi?id=1570493 Pétùr
Booting once on a different OS (with grub)
Is there a way to tell grub to boot the next time (and only this time) to a different OS than the default one? I have a bluetooth keyboard which does not work in grub. This is why I want to tell grub, while I am on debian, to boot at the next reboot to entry n°3 (which is a window I keep for some specific softwares). I do not want to change grub order each time. I am looking more to something like "touch /forcefsck" to force check filesystem (but for booting to entry 3 in grub). Pétùr
Nvidia 340 driver bug
Le 03/06/2018 à 20:47, floris a écrit : > Pétùr schreef op 2018-06-02 17:46: >>> This is a bug in the nvidia driver module. There is not much you can do >>> until it is fixed upstream. >> >> Thanks! >> >> I would like to use the nouveau driver waiting for the fix. >> >> However I an unable to boot X with the nouveau driver. >> >> I did: >> >> # apt-get purge nvidia. >> # apt-get install --reinstall xserver-xorg xserver-xorg-video-nouveau >> # reboot >> >> I have no xorg.conf. >> >> $ startx >> >> says: >> >> XF86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) > > Did you also removed the NVidia symlinks? I'm not sure if they are > removed when you purge the NVidia packages. > > Try: > sudo update-glx --config glx > If there are any options choose mesa > > and rebuild initramfs with: > sudo update-initramfs -u Thanks for the idea. In fact, there is a bug with xorg-server-1.20.0 and the "compositor" of Xfce. See this bug report and message: https://lists.debian.org/debian-user/2018/05/msg01008.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900550 For the ones affected, if X doesn't start, you have to downgrade xserver-xorg-core and xserver-org-video-nouveau (apt install xserver-xorg-core/testing xserver-xorg-video-nouveau/testing), then you can start X and uncheck the compositor activation check in Xfce. After that, you can upgrade back the package and reboot. Pétùr
Re: Redirect repositories in sources.list for Debian Stretch
Le 02/06/2018 à 17:14, Brian a écrit : > On Sat 02 Jun 2018 at 11:02:31 +, Markos wrote: >> Now I've just installed Debian 9 (stretch) and I'm looking for a site for >> repository redirection, but I'm confused. >> >> I found the sites: >> >> http://httpredir.debian.org/ >> >> http://deb.debian.org/ >> >> http://http.debian.net/ >> >> Are they all reliable? > > deb.debian.org is the recommended mirror to use with apt in stretch > and later. You could also use netselect-apt package to find which mirror is the best for you.
Re: Nvidia 340 driver bug
Le 02/06/2018 à 17:46, Pétùr a écrit : > >> This is a bug in the nvidia driver module. There is not much you can do >> until it is fixed upstream. > > Thanks! > > I would like to use the nouveau driver waiting for the fix. > > However I an unable to boot X with the nouveau driver. Here is the log for the nouveau driver fail: > [ 104.269] (II) NOUVEAU(0): EDID vendor "SEC", prod id 21579 > [ 104.269] (II) NOUVEAU(0): DDCModeFromDetailedTiming: Ignoring tiny 0x822 > mode > [ 104.269] (II) NOUVEAU(0): DDCModeFromDetailedTiming: Ignoring tiny 0x0 > mode > [ 104.269] (II) NOUVEAU(0): Printing DDC gathered Modelines: > [ 104.269] (II) NOUVEAU(0): Modeline "1600x900"x0.0 107.80 1600 1648 1680 > 1932 900 902 907 930 +hsync -vsync (55.8 kHz eP) > [ 104.269] (II) NOUVEAU(0): Modeline "1600x900"x0.0 71.87 1600 1648 1680 > 1932 900 902 907 930 +hsync -vsync (37.2 kHz e) > [ 104.422] (EE) > [ 104.422] (EE) Backtrace: > [ 104.424] (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4d) [0x558f4c3b46fd] > [ 104.424] (EE) 1: /usr/lib/xorg/Xorg (0x558f4c201000+0x1b73b9) > [0x558f4c3b83b9] > [ 104.424] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7fad3be58000+0x11f50) [0x7fad3be69f50] > [ 104.424] (EE) 3: /usr/lib/xorg/Xorg (miRenderColorToPixel+0xe) > [0x558f4c328a9e] > [ 104.424] (EE) 4: /usr/lib/xorg/modules/libexa.so (0x7fad3890+0xf12b) > [0x7fad3890f12b] > [ 104.424] (EE) 5: /usr/lib/xorg/Xorg (0x558f4c201000+0x13a786) > [0x558f4c33b786] > [ 104.424] (EE) 6: /usr/lib/xorg/Xorg (0x558f4c201000+0x12eaec) > [0x558f4c32faec] > [ 104.424] (EE) 7: /usr/lib/xorg/Xorg (0x558f4c201000+0x5b008) > [0x558f4c25c008] > [ 104.424] (EE) 8: /usr/lib/xorg/Xorg (0x558f4c201000+0x5f008) > [0x558f4c260008] > [ 104.424] (EE) 9: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xe7) > [0x7fad3babfa87] > [ 104.425] (EE) 10: /usr/lib/xorg/Xorg (_start+0x2a) [0x558f4c249d0a] > [ 104.425] (EE) > [ 104.425] (EE) Segmentation fault at address 0x8 > [ 104.425] (EE) > Fatal server error: > [ 104.425] (EE) Caught signal 11 (Segmentation fault). Server aborting > [ 104.425] (EE) > [ 104.425] (EE) > Please consult the The X.Org Foundation support >at http://wiki.x.org > for help. > [ 104.425] (EE) Please also check the log file at > "/home/pierre/.local/share/xorg/Xorg.0.log" for additional information. > [ 104.425] (EE) > [ 104.425] (II) AIGLX: Suspending AIGLX clients for VT switch > [ 104.425] (II) NOUVEAU(0): NVLeaveVT is called. > [ 104.435] (EE) Server terminated with error (1). Closing log file.
Re: Nvidia 340 driver bug
> This is a bug in the nvidia driver module. There is not much you can do > until it is fixed upstream. Thanks! I would like to use the nouveau driver waiting for the fix. However I an unable to boot X with the nouveau driver. I did: # apt-get purge nvidia. # apt-get install --reinstall xserver-xorg xserver-xorg-video-nouveau # reboot I have no xorg.conf. $ startx says: XF86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
Nvidia 340 driver bug
I have a recurrent bug with the nvidia 340 driver. Here is the trace. Any idea is welcomed. Pétùr [6.748358] [ cut here ] [6.748361] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'nvidia_stack_t' (offset 11864, size 3)! [6.748371] WARNING: CPU: 6 PID: 702 at /build/linux-43CEzF/linux-4.16.12/mm/usercopy.c:81 usercopy_warn+0x7e/0xa0 [6.748372] Modules linked in: snd_hda_codec_hdmi pktcdvd arc4 pcmcia dell_rbtn iwldvm dell_wmi wmi_bmof iTCO_wdt sparse_keymap iTCO_vendor_support snd_hda_codec_idt uvcvideo dell_laptop intel_powerclamp snd_hda_codec_generic mac80211 dell_smbios coretemp videobuf2_vmalloc dell_wmi_descriptor videobuf2_memops kvm_intel dcdbas videobuf2_v4l2 dell_smm_hwmon snd_hda_intel videobuf2_common kvm videodev irqbypass snd_hda_codec iwlwifi intel_cstate media evdev yenta_socket joydev snd_hda_core intel_uncore snd_hwdep serio_raw snd_pcm pcspkr pcmcia_rsrc sg cfg80211 pcmcia_core snd_timer rfkill snd mei_me soundcore i7core_edac mei lpc_ich shpchp nvidia(PO) wmi battery binfmt_misc dell_smo8800 video ac acpi_cpufreq button drm parport_pc ppdev lp parport sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache [6.748407] jbd2 fscrypto ecb crypto_simd cryptd glue_helper aes_x86_64 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod sdhci_pci ehci_pci cqhci ahci libahci ehci_hcd libata crc32c_intel sdhci psmouse firewire_ohci i2c_i801 scsi_mod firewire_core mmc_core crc_itu_t usbcore e1000e usb_common [6.748432] CPU: 6 PID: 702 Comm: Xorg Tainted: P O 4.16.0-2-amd64 #1 Debian 4.16.12-1 [6.748432] Hardware name: Dell Inc. Precision M4500/, BIOS A14 07/11/2013 [6.748434] RIP: 0010:usercopy_warn+0x7e/0xa0 [6.748435] RSP: 0018:a77b01ef3bb8 EFLAGS: 00010286 [6.748436] RAX: RBX: 98d83805ae58 RCX: 0006 [6.748437] RDX: 0007 RSI: 0082 RDI: 98d86fd96730 [6.748438] RBP: 0003 R08: 035b R09: 0004 [6.748438] R10: a3a77220 R11: 0001 R12: 0001 [6.748439] R13: 98d83805ae5b R14: 98d83805ae58 R15: 98d83805aea0 [6.748440] FS: 7fb60fa256c0() GS:98d86fd8() knlGS: [6.748441] CS: 0010 DS: ES: CR0: 80050033 [6.748442] CR2: 7fb6069ca000 CR3: 00020e118000 CR4: 06e0 [6.748443] Call Trace: [6.748448] __check_object_size+0x9c/0x1a0 [6.748540] os_memcpy_to_user+0x21/0x40 [nvidia] [6.748618] _nv001372rm+0xa5/0x260 [nvidia] [6.748696] ? _nv004784rm+0x4eba/0x5500 [nvidia] [6.748773] ? _nv004331rm+0xec/0xf0 [nvidia] [6.748849] ? _nv004326rm+0xca/0x650 [nvidia] [6.748923] ? _nv015126rm+0x576/0x5c0 [nvidia] [6.748999] ? _nv000694rm+0x2e/0x60 [nvidia] [6.749068] ? _nv000789rm+0x5f5/0x8b0 [nvidia] [6.749134] ? rm_ioctl+0x73/0x100 [nvidia] [6.749182] ? nvidia_ioctl+0x221/0x460 [nvidia] [6.749231] ? nvidia_frontend_ioctl+0x2d/0x60 [nvidia] [6.749279] ? nvidia_frontend_unlocked_ioctl+0x19/0x20 [nvidia] [6.749281] ? do_vfs_ioctl+0xa4/0x630 [6.749283] ? vfs_write+0x12f/0x1a0 [6.749284] ? SyS_ioctl+0x74/0x80 [6.749287] ? do_syscall_64+0x6c/0x130 [6.749290] ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [6.749291] Code: 48 c7 c0 f1 d2 a3 a3 48 0f 44 c2 41 50 51 41 51 48 89 f9 49 89 f1 4d 89 d8 4c 89 d2 48 89 c6 48 c7 c7 38 d3 a3 a3 e8 62 4c e4 ff <0f> 0b 48 83 c4 18 c3 48 c7 c6 3c d3 a4 a3 49 89 f1 49 89 f3 eb [6.749313] ---[ end trace dc2afdad83c552e7 ]---
Re: upgrade to X 1.20.0 broken
On 29/05/18 17:38, rog...@onlinenw.com wrote: Hello, I am running sid, and updated to X.org 1.20.0. Since then I cannot login. I am running lightdm with xfce. lightdm comes up just fine, but when I login, after a second or two, it comes back to the lightdm login screen. I have an old graphics card (EVGA 6600GT) and monitor (NEC 1970GX) from 2005. They use the nouveau display driver. Same problem here. I have an old graphical card (Quadro FX 880M), the nvidia driver 340xx is now out of the sid repository (EOL I suppose) and I tried the nouveau driver. Impossible to log in. I had to go back to the stable version of nvidia-driver (340) with aptitude.
Re: Thunderbird does not start and freezes
Le 27/05/2018 à 15:24, Pétùr a écrit : > In sid, trying to launch thunderbird does do anything and freezes the > system (mouse works but cannot act on windows, going to tty works). I uninstalled apparmor for now and thunderbird is launching. (if someone has the same issue).
Thunderbird does not start and freezes
In sid, trying to launch thunderbird does do anything and freezes the system (mouse works but cannot act on windows, going to tty works). dmesg says: [ 13.676445] audit: type=1400 audit(1527426637.518:35): apparmor="DENIED" operation="open" profile="thunderbird" name="/sys/devices/pci:00/:00:02.0/vendor" pid=1880 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 13.676503] audit: type=1400 audit(1527426637.518:36): apparmor="DENIED" operation="open" profile="thunderbird" name="/sys/devices/pci:00/:00:02.0/vendor" pid=1880 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 13.676624] audit: type=1400 audit(1527426637.518:37): apparmor="DENIED" operation="open" profile="thunderbird" name="/sys/devices/pci:00/:00:02.0/vendor" pid=1880 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 13.676692] audit: type=1400 audit(1527426637.518:38): apparmor="DENIED" operation="open" profile="thunderbird" name="/sys/devices/pci:00/:00:02.0/vendor" pid=1880 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 13.681934] audit: type=1400 audit(1527426637.526:39): apparmor="DENIED" operation="open" profile="thunderbird" name="/sys/devices/pci:00/:00:02.0/vendor" pid=1880 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 13.682129] audit: type=1400 audit(1527426637.526:40): apparmor="DENIED" operation="open" profile="thunderbird" name="/sys/devices/pci:00/:00:02.0/vendor" pid=1880 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 [ 14.560466] audit: type=1400 audit(1527426638.402:41): apparmor="DENIED" operation="open" profile="thunderbird" name="/home/pierre/.icons/icon-theme.cache" pid=1867 comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 Any idea?
Re: Update on my update problem with gnome system.
Le 25/05/2018 à 21:33, Joe a écrit : >> Le 19/05/2018 à 21:03, Hans a écrit : >>> Isn't it today "apt update" and "apt full-upgrade"? >> Thanks, I didn't know this new "full-upgrade" command. >> >> Is "apt full-upgrade" equivalent to "apt-get dist-upgrade" (or apt >> dist-upgrade)? > More or less. Apt-get is actually a bit less intelligent, but in the > case of upgrades of very large numbers of packages (400+), that seems to > work better. It has been recommended for several version upgrades in > preference to aptitude. > > I haven't used apt, but I've used aptitude to upgrade long-neglected > unstable installations, and I've known it to run overnight without > finding a solution. > > For smaller numbers of packages, aptitude (and presumably apt) is > generally quicker at reaching a solution, apt-get may have to be run a > few times with selected packages to break an impasse. I don't use aptitude. I use only apt and apt-get but I believe apt is just a shortcut for apt-get. `apt update` is equivalent for me to `apt-get update` and `apt dist-upgrade` to `apt-get dist-upgrade` (correct me if I am wrong). My question was if apt (or apt-get) dist-upgrade was equivalent of apt (or apt-get) full-upgrade?
Re: Update on my update problem with gnome system.
Le 19/05/2018 à 21:03, Hans a écrit : > Isn't it today "apt update" and "apt full-upgrade"? Thanks, I didn't know this new "full-upgrade" command. Is "apt full-upgrade" equivalent to "apt-get dist-upgrade" (or apt dist-upgrade)? According to the man pages (man apt and man apt-get), dist-upgrade "intelligently handles changing dependencies" when full-upgrade justs "remove currently installed packages if this is needed". >full-upgrade (apt-get(8)) >full-upgrade performs the function of upgrade but will remove > currently installed >packages if this is needed to upgrade the system as a whole. > >dist-upgrade >dist-upgrade in addition to performing the function of upgrade, > also intelligently >handles changing dependencies with new versions of packages; > apt-get has a "smart" >conflict resolution system, and it will attempt to upgrade the > most important packages >at the expense of less important ones if necessary. The > dist-upgrade command may >therefore remove some packages. The /etc/apt/sources.list file > contains a list of >locations from which to retrieve desired package files. See also > apt_preferences(5) >for a mechanism for overriding the general settings for individual > packages.
Re: flyspell with hunspell error complaining about utf8
On 14/05/18 11:48, Stefan Monnier wrote: I have the following error when activate flyspell-mode (with hunspell set as the default dictionnary): "Error enabling Flyspell mode: (UTF-8)" My flyspell configuration (below) worked flawless for years. No one is affected by this bug in debian sid? I tried different ways to call flyspell with hunspell as dictionnary. None is working. You might have better luck in an Emacs forum. I'm not using Sid but FWIW I haven't faced this problem on testing. Also, try and see if the problem also appears with `emacs -q` (if not, then try and figure out which part of your ~/.emacs triggers the problem). I spend some time yesterday on IRC (#emacs) and it seems it is a bug related to the language (French). Another french user was affected but didn't find a solution. The problem is still present when starting emacs with the `-q` option.
Re: flyspell with hunspell error complaining about utf8
On 08/05/18 13:06, Pétùr wrote: I have the following error when activate flyspell-mode (with hunspell set as the default dictionnary): "Error enabling Flyspell mode: (UTF-8)" My flyspell configuration (below) worked flawless for years. No one is affected by this bug in debian sid? I tried different ways to call flyspell with hunspell as dictionnary. None is working. Pétùr
flyspell with hunspell error complaining about utf8
Hi, Does anyone have also an error when using flyspell with hunspell (inside emacs of course)? I have the following error when activate flyspell-mode (with hunspell set as the default dictionnary): "Error enabling Flyspell mode: (UTF-8)" My flyspell configuration (below) worked flawless for years. (if (file-exists-p "/usr/bin/hunspell") (progn (setq ispell-program-name "hunspell") (eval-after-load "ispell" '(progn (defun ispell-get-coding-system () 'utf-8) ;(setq ispell-dictionary "francais") (setq flyspell-sort-corrections nil) (global-set-key [f2] 'flyspell-mode) (add-hook 'LaTeX-mode-hook 'flyspell-mode) (add-hook 'mail-mode-hook 'flyspell-mode) ;(add-hook 'org-mode-hook 'flyspell-mode) (global-set-key [f3] (lambda () (interactive) (ispell-change-dictionary "francais"))) (global-set-key [f4] (lambda () (interactive) (ispell-change-dictionary "english")))
Bug in pdf display probably due to synctex update
In Debian Sid, I cannot anymore use zathura (pdf viewer) and pdf-tools (inside emacs). The problem seems to be linked with synctex (for LaTeX documents). Zathura says "zathura: symbol lookup error: zathura: undefined symbol: synctex_next_result" even when I try to open pdfs which are not created by LaTeX. pdf-tools inside emacs says: "The epdfinfo server quit unexpectedly." and displays non-LaTeX document without error. These two programs depend on libsynctex1 debian package. There is also a libsynctex2 package but it is not used by zathura or pdf-tools. Do anyone suffers from the same bug? Any temporary solution before the fix? Cheers, Pétùr
Re: bad upgrade libgstgl-1.0.so.0
Le 21/03/2018 à 19:38, Kushal Kumaran a écrit : > The package version mentioned above is not from the official debian > repositories. It appears to be from deb-multimedia.org. > > The Debian Multimedia FAQ at > https://wiki.debian.org/DebianMultimedia/FAQ might help. See sections > 2.5 and 3.1. Thank you Kushal, The problem was indeed created by a conflit with the deb-multimedia repository. I fixed it by stopping using this repository and downgrading all the packages concerned. It seems there is less reason to use deb-multimedia these days. The official (unstable) repositories contain almost the same version of packages. The only program I didn't find is avidemux. Pétùr
bad upgrade libgstgl-1.0.so.0
Hi, I had a bad upgrade on my debian sid. It seems both libgstreamer-gl1.0-0:amd64 and libgstreamer-plugins-bad1.0-0:amd64 are trying to write the file /usr/lib/x86_64-linux-gnu/libgstgl-1.0.so.0. Any idea to fix it? Pétùr # apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: gir1.2-gst-plugins-base-1.0 : Depends: libgstreamer-gl1.0-0 (>= 1.14.0) but it is not installed E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). # apt --fix-broken install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following additional packages will be installed: gstreamer1.0-gl libgstreamer-gl1.0-0 The following NEW packages will be installed: gstreamer1.0-gl libgstreamer-gl1.0-0 0 upgraded, 2 newly installed, 0 to remove and 25 not upgraded. 1 not fully installed or removed. Need to get 0 B/2 616 kB of archives. After this operation, 3 169 kB of additional disk space will be used. Do you want to continue? [O/n] (Reading database ... 429315 files and directories currently installed.) Preparing to unpack .../libgstreamer-gl1.0-0_1.14.0-1_amd64.deb ... Unpacking libgstreamer-gl1.0-0:amd64 (1.14.0-1) ... dpkg: error processing archive /var/cache/apt/archives/libgstreamer-gl1.0-0_1.14.0-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libgstgl-1.0.so.0', which is also in package libgstreamer-plugins-bad1.0-0:amd64 1:1.12.4-dmo4 Preparing to unpack .../gstreamer1.0-gl_1.14.0-1_amd64.deb ... Unpacking gstreamer1.0-gl:amd64 (1.14.0-1) ... dpkg: error processing archive /var/cache/apt/archives/gstreamer1.0-gl_1.14.0-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstopengl.so', which is also in package gstreamer1.0-plugins-bad:amd64 1:1.12.4-dmo4 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libgstreamer-gl1.0-0_1.14.0-1_amd64.deb /var/cache/apt/archives/gstreamer1.0-gl_1.14.0-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
System crash (gpu hang?)
I recently experimented some crashes on debian sid. The system becomes unresponsive and falls back to the login (lightdm) window after few minutes. Here is the dmesg log if someone has the time to help me figure out what is going on: https://paste.aperture-sc.net/?95de7f038710fd42#q18U+ujcdN+oYVKPkF8uHPCTWUehItZGtzvXYTsgHVU= Petur
Re: bluetooth keyboard prevents suspend
On 28/01/18 10:32, Karol Augustin wrote: I know that id doesn't fix the problem but as you won't be able to use usb wakup functionality with bluetooth keyboard anyway maybe just disable it in BIOS and it should fix the problem for now. My idea is to rely on another usb device to wake up the computer. For now, my logitech (wireless) mouse doesn't do that but I think it is possible. I will look into it. So disable the BT keyboard, wake up with the mouse. Pétùr
Re: bluetooth keyboard prevents suspend
On 28/01/18 14:28, tv.deb...@googlemail.com wrote: Hello, I am not very familiar with Bluetooth which I tend to disable entirely on my computers, but in case of such problems with buggy hardware I use the TLP package. The configuration allows to precisely choose what hardware (pointing devices, gpu...) or service (wifi, bluetooth...) to enable/disable during sleep and wake-ups. Maybe it can handle your keyboard too. Thanks, it's help! TLP allows indeed to disable specificly one USB device: # Set to 0 to disable, 1 to enable USB autosuspend feature. USB_AUTOSUSPEND=1 # Exclude listed devices from USB autosuspend (separate with spaces). # Use lsusb to get the ids. # Note: input devices (usbhid) are excluded automatically USB_BLACKLIST="0a12:0001" I disabled my usb connected bluetooth dongle (so my usb keyboard doesn't wake up my system). Thanks again! Pétùr
bluetooth keyboard prevents suspend
I have set my BIOS configuration to allow usb devices to wake up the computer. I used my mouse or my usb keyboard to wake up the system. But I just replaced my usb keyboard with a bluetooth one. My bluetooth adapter is a dongle connected to a usb port. Everytime I suspend (no matter which method), the computer wake up immediately (because it detects some connecting activity from the bluetooth keyboard). I have to disconnect the bluetooth keyboard with the hardware button before suspending. Then I can suspend and wakeup with the mouse. Is there a way to suspend without turning off the buetooth keyboard first? Cheers, Pétùr
Re: html page for bug report
Just to let you know I finally opt for a simple html page created with org-mode. I use the checkboxes (org-mode can export checkboxes in proper html) to allow visitors to check (ie mark a bug/feature as fixed/implemented.
Mouse stops working randomly when docked
My mouse and trackpad stop working some time when my laptop (dell M4500) is docked. I can move the cursor and select text but clicking does not work (no change of focus, no action). The keyboard works fine and the system is totally usable. This happens in the morning when I start the computer (after 5-10 min). If I reboot, I don't have the problem for the day. I tried this solution (which would just avoid rebooting) but it didn't work: $ xinput list ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ Logitech M345 id=13 [slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS DualPoint TouchPad id=16 [slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS DualPoint Stick id=17 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboardid=5[slave keyboard (3)] ↳ Power Button id=6[slave keyboard (3)] ↳ Video Bus id=7[slave keyboard (3)] ↳ Power Button id=8[slave keyboard (3)] ↳ Sleep Button id=9[slave keyboard (3)] ↳ Dell Dell Multimedia Pro Keyboard id=10 [slave keyboard (3)] ↳ Dell Dell Multimedia Pro Keyboard id=11 [slave keyboard (3)] ↳ Laptop_Integrated_Webcam_3M: Inid=12 [slave keyboard (3)] ↳ Dell WMI hotkeys id=14 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=15 [slave keyboard (3)] $ xinput reattach 13 2 Do someone know the reason of this bug?
Re: html page for bug report
On 12/01/18 05:57, Dan Ritter wrote: On Fri, Jan 12, 2018 at 11:33:17AM +0100, Pétùr wrote: I am looking for a very simple way to create a bug report webpage. I would like to obtain a single html page where a visitor can create a bug report or feature request. Another visitor can mark the bug as fixed. No authentication. User have zero knowledge in html. Are you aware of such program or script? Every bug or ticket tracker expands to fit at least a minimal set of features: bug numbering, more states between "new" and "fixed", assignment to individuals... I like Request Tracker (RT) an awful lot. It's in Debian. It is not simple to set up, but it can be quite simple to use. Thanks, it seems too powerful for my present needs (I don't want users management, mysql database, etc.) but I will have a look. I will maybe create a html page with a form myself. But I don't see how the visitor can modify an bug report (to mark as fixed). Pétùr
html page for bug report
I am looking for a very simple way to create a bug report webpage. I would like to obtain a single html page where a visitor can create a bug report or feature request. Another visitor can mark the bug as fixed. No authentication. User have zero knowledge in html. Are you aware of such program or script? Pétùr
Re: Cannot copy files from usb source
Le 20/10/2017 à 10:47, Pétùr a écrit : > Le 20/10/2017 à 03:32, Tom Furie a écrit : >>> I cannot copy files from my laptop (with SSD formated in ext4) to my >>> external HDD (formated also in ext4). I have an input/outpur error. The >>> I can do the opposite, i.e. transfert files from my laptop to my >>> external HDD (or other usb connected devices) with no problem. >> Which is it? > > Sorry for the mistake: I *cannot* copy file from my HDD to my laptop and > I *can* copy files from the laptop to my HDD. Writing on my laptop SSD > is the problem. > For the record, I fixed this problem by adding "elevator=deadline" to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub. It seems to be necessary for some old SSD. Without you cannot copy to HDD. It tooks me almost a year to figure out this... Pétùr
Re: Cannot copy files from usb source
Le 20/10/2017 à 03:32, Tom Furie a écrit : >> I cannot copy files from my laptop (with SSD formated in ext4) to my >> external HDD (formated also in ext4). I have an input/outpur error. The >> I can do the opposite, i.e. transfert files from my laptop to my >> external HDD (or other usb connected devices) with no problem. > Which is it? Sorry for the mistake: I *cannot* copy file from my HDD to my laptop and I *can* copy files from the laptop to my HDD. Writing on my laptop SSD is the problem.
Re: pm-utils by default on Xfce for suspend/hibernate
Le 18/10/2017 à 17:32, Alexander V. Makartsev a écrit : > I have PC with Debian 9 "stretch" x86_64 + Xfce and I never needed to > have pm-utils installed, but hibernation\suspend feature works normally > through xfce4 GUI once I set up all prerequisites for hibernation to > work (such as at least working swap and initramfs resume variable). I > also removed packages such as "uswsusp", "hibernate". I have used them > previously, but now they are unnecessary for hibernation to work on my > computer. It is the nvidia proprietary driver which causes the issue. I have no problem to suspend and hibernate with the free driver "nouveau" but the free driver is buggy (see my other question on this list) so I cannot use it. After installing the proprietary (340) one, I have no graphical bug but suspend or hibernate don't work all the time (they fails sometimes). Suspend or hibernate seems to work all the times when I triggers them with pm-utils tools. So I would like to make it the default ones. > How you start Xfce DE and did you installed "xfce4-power-manager" package? > You've said hibernation works when you trigger it manually, so check if > hibernation works via systemd: > $ systemctl hibernate I start xfce with lightdm and I have xfce4-power-manager installed. systemctl hibernate and systemctl suspend seems to work. Pétùr
Cannot copy files from usb source
I have a weird problem with my laptop and external HDD or usb sticks. I cannot copy files from my laptop (with SSD formated in ext4) to my external HDD (formated also in ext4). I have an input/outpur error. The transfert starts but at very very slow rate and then I have the error. I tried different usb ports. The problem is also present with usb sticks formated in fat32. I cannot write to my SSD from any usb source. I can do the opposite, i.e. transfert files from my laptop to my external HDD (or other usb connected devices) with no problem. Maybe related: on the same laptop, I have another problem when I download files from my local network using WiFi. The transfert is extremely slow and the rate change constantly. If I connect my laptop through ethernet, I don't have any issue. I suspected some problem with my SSD but the ethernet transfer is very fast and constant. Do you have any idea about the problem(s)? Pétùr
pm-utils by default on Xfce for suspend/hibernate
On my computer (Debian sid), with a nvidia graphical card and the 340 proprietary driver, suspend/hibernate does not work with xfce tools. I means that xfce4-session-logout --suspend does not work for example. But pm-suspend or pm-hibernate works perfectly. And I can launch them as user because I edited my /etc/sudoers file with: my_user ALL = NOPASSWD: /usr/sbin/pm-hibernate my_user ALL = NOPASSWD: /usr/sbin/pm-suspend So I would like to make pm-utils tools the default ones for suspend/hibernate in Xfce. pm-utils commands should be triggered when clicking "suspend/hibernate" on the xfce logout window. How can I do that?
Re: ugly fonts in thunderbird after sid upgrade
Le 17/10/2017 à 23:01, Ben Caradoc-Davies a écrit : > On 18/10/17 07:38, Michael Biebl wrote: >> Am 16.10.2017 um 22:50 schrieb Pétur Viljamson: >>> I have ugly fonts in thunderbird after updating my Debian sid today. >> It's the latest freetype upgrade causing this for users which use >> subpixel antialiasing. Thunderbird needs to be updated to cope with the >> changes in freetype 2.8.1 >> see https://bugs.debian.org/878870 > > Aha! So the reason I do not see this defect is my use of the old engine > (the one that supports hinting) through a FREETYPE_PROPERTIES setting. > > Pétur, please try starting thunderbird with: > > FREETYPE_PROPERTIES=truetype:interpreter-version=35 thunderbird Thanks Michael, the bug is indeed caused by libfreetype6 update. @Ben: For my, the command: "FREETYPE_PROPERTIES=truetype:interpreter-version=35 thunderbird" didn't fix it. I did reboot when I change my /etc/environment for your. It wasn't working either. The temporary solution for me is to downgrade libfreetype6 to testing. I don't have the bug after that. Another fix is to deactivate the antialiasing setting (but you have less beautiful fonts everywhere). Pétùr
Re: ugly fonts in thunderbird after sid upgrade
Le 17/10/2017 à 05:00, Ben Caradoc-Davies a écrit : >> > > I am using Xfce on sid and do not see any font corruption in > thunderbird. What are your desktop font settings? > > I am using Liberation Sans for desktop and GUI, full hinting, and in > /etc/environment I have: > " Thanks for the answer, I using "Sans" font family for xfce and sans-serif for thunderbird. Changing to Liberation Sans does not change the problem (the same for the hinting setting). I have nothing in /etc/environment and if I copy/paste what you have, it does not fix the bug. Pétùr
Re: Nvidia Quadro FX880M and debian sid
Le 14/09/2017 à 20:18, Jimmy Johnson a écrit : >> P-S : lspci >> >> 01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro >> FX 880M] (rev a2) > > I do not know that nvidia card, but for nvidia I know two packages that > need to be installed, 'xserver-xorg-video-nvidia' this package is nvidia > version 375.xx and is the current nvidia for Sid/Testing and the other > package is 'nvidia-driver', maybe installing package nvidia-driver will > pull-in all you need, I don't remember, but this is the driver I run on > this machine with geforce gt610. Hello, For my card, it seems I need the legacy 340 driver (and xserver-xorg-video-nvidia-legacy-304xx). It is what nvidia-detect says and I have a warning message about this when installing nvidia-driver and xserver-xorg-video-nvidia. I tried anyway to install server-xorg-video-nvidia and nvidia-driver because my card is listed as compatible in the 375.82 notes [1] (Quadro FX 880M is listed). [1] http://us.download.nvidia.com/XFree86/Linux-x86_64/375.82/README/supportedchips.html With 375.82 driver, I have a resolution problem (start in 640x480) but I suppose I can fix it in xorg.conf. More important, I am still unable to suspend or hibernate. The laptop never wakes up. So 375.82 is the same for me than 340xx. I stick for now with the nouveau driver despites the graphical glitches (suspend is more important for me in this moment). I am still *very* interesting by any solution either to be able to suspend with nvidia-driver (340) or to fix the bug of nouveau driver. I am pragmatical in this case and will use whatever works best. Pétùr
Re: Nvidia Quadro FX880M and debian sid
Le 06/09/2017 à 12:02, Felix Miata a écrit : >> 01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro >> FX 880M] (rev a2) > That's probably new enough to be supported by the default Xorg driver. Purge > the > nouveau Xorg driver and all traces of the proprietary driver, and Xorg should > automatically use the default (modesetting, which will show up in Xorg.0.log > as > modeset(0)). I have no complaints using the modesetting driver, but I don't > use > laptops or suspend either. I did purge/reinstall the nouveau Xorg driver and delete any nvidia. packages. It works fine most of the time but I still have graphical problems time to time. It is like the desktop go back in time and display windows which were open 15 min ago (like a snapshot). When it happens, if I move the mouse cursor I can see the actual window which is really open behind the snapshot. If I maximize a window, it reset all the screen and I can work again. I made a quick screencast showing a little bit the issue: https://ncloud.zaclys.com/index.php/s/R8JE9vKNg1llata Is there something to do to fix that?
Nvidia Quadro FX880M and debian sid
Hello, I have installed Debian (Sid) on a Dell precision M4500 from 2010. It has the Nvidia Quadro FX 880M graphical card. I have some freezes and graphical glitches when using the nouveau driver. They appears time to time (the window I was using is still there but I cannot see it anymore except if I put the mouse cursor on it. I tried the proprietary driver (nvidia-legacy-340xx-driver for this card) which has no glitches but suspend and hibernate does not work anymore. *Does someone find a solution to have suspend and hibernate working with this card and the proprietary driver ?* Or: *Does someone have a solution to fix the graphical glitchs I have with the nouveau driver?* Thanks, Pétùr P-S : lspci 01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro FX 880M] (rev a2)
Re: "Bad file descriptor" error when restoring file
Le 08/07/2017 à 18:37, Nicolas George a écrit : > Le decadi 20 messidor, an CCXXV, Nicolas George a écrit : >> This specific error message is always the sign of a severe bug in the >> program. > Hum, I had not imagined the wrong file descriptor was requested on > purpose. The severe bug was not in the program but in the caller. Indeed, it is really shocking that deja-dup fails to produce a correct backup with its default behavior. This front-end should be removed from the repository. That is said, there is still the need for nice, user friendly, front-end for duplicity for those who don't want to use a command-line program. Is there such front-end, reliable and intuitive? Pétùr
Re: "Bad file descriptor" error when restoring file
Le 08/07/2017 à 18:34, Reco a écrit : >> Any idea? >> >> $ duplicity restore --gio --time=2017-07-06T08:14:08Z --force >> file:///home/pierre/data/backup_pierre / --verbosity=9 >> --gpg-options=--no-use-agent --archive-dir=/home/pierre/.cache/deja-dup >> --tempdir=/tmp --log-fd=22 > Sure. Don't ask duplicity to log its actions to file descriptor 22, as > it is highly unlikely to be open. > Skip '--log-fd' altogether. Thanks, it fixes the problem indeed. I am quite disappointed by deja-dup front-end as Nicolas George points out and I will recommend to not use it. I will directly use duplicity instead in the future. So I have my backup but I wonder what is the best behavior in my situation? I had this one issue with my SSD (erratic behavior, many errors and corrupted files), smartmontools says it is clean now and the ssd is less than one year old. fsck fixes the errors. *Am I good to do after reinstalling the backup (so good version not corrupted of files)?* Or should I do a complete reinstallation of Debian? In fact, I wonder if there is a different between a repaired file-system and a newly formated one in term of reliability? Pétùr
"Bad file descriptor" error when restoring file
In brief : my SSD seems to have crashed (system erratic behavior suddently). Debian asks for a fsck at reboot. fsck fixes a lot of errors. I reboot with the default configuration of Xfce which means the config files were damaged -> restoring previous week backup. So, I am trying to restore a backup made with deja-dup. The recovery gets stuck quickly. I tried to pass the duplicity command manually and here is the error : "OSError: [Errno 9] Bad file descriptor" It happens no matter which backup I choose to restore. I am running Debian unstable. Any idea? $ duplicity restore --gio --time=2017-07-06T08:14:08Z --force file:///home/pierre/data/backup_pierre / --verbosity=9 --gpg-options=--no-use-agent --archive-dir=/home/pierre/.cache/deja-dup --tempdir=/tmp --log-fd=22 Warning: Option --gio is pending deprecation and will be removed in a future release. Use of default filenames is strongly suggested. Using temporary directory /tmp/duplicity-LTZSjM-tempdir Traceback (most recent call last): File "/usr/bin/duplicity", line 1553, in with_tempdir(main) File "/usr/bin/duplicity", line 1547, in with_tempdir fn() File "/usr/bin/duplicity", line 1382, in main action = commandline.ProcessCommandLine(sys.argv[1:]) File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 1096, in ProcessCommandLine args = parse_cmdline_options(cmdline_list) File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 637, in parse_cmdline_options (options, args) = parser.parse_args() File "/usr/lib/python2.7/optparse.py", line 1400, in parse_args stop = self._process_args(largs, rargs, values) File "/usr/lib/python2.7/optparse.py", line 1440, in _process_args self._process_long_opt(rargs, values) File "/usr/lib/python2.7/optparse.py", line 1515, in _process_long_opt option.process(opt, value, values, self) File "/usr/lib/python2.7/optparse.py", line 789, in process self.action, self.dest, opt, value, values, parser) File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 197, in take_action self, action, dest, opt, value, values, parser) File "/usr/lib/python2.7/optparse.py", line 809, in take_action self.callback(self, opt, value, parser, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 452, in callback=lambda o, s, v, p: set_log_fd(v)) File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 242, in set_log_fd log.add_fd(fd) File "/usr/lib/python2.7/dist-packages/duplicity/log.py", line 403, in add_fd handler = logging.StreamHandler(os.fdopen(fd, 'w')) OSError: [Errno 9] Bad file descriptor
How to format emails like debian-announce?
I am wondering if the (nice) formating of Debian announce emails is generated by a software or by hand. If it is a software/configuration, I am interesting to know more. It would be useful, for example, if there was a way to generate urls links like this one[1] more or less automatically. [1] http://www.example.com or to quickly do header like this one: The Debian Project https://www.debian.org/ Debian 9 "Stretch" released pr...@debian.org June 17th, 2017https://www.debian.org/News/2017/20170617 Of course, it depends of what editor do you use. I use Emacs when I use mutt and thunderbird otherwise.
Re: Grave bug when playing flash videos
Le 11/06/2017 à 22:50, Pétùr a écrit : > > This bug freezes everything and I have to do a hard reboot. It happens > with flashplugin and pepperflash when I play a video with flash (both > tested with firefox and chromium). Today I am using pepperflash, > installed by the package browser-plugin-freshplayer-pepperflash. update to this bug: it happened twice today when waking up from sleep. the computer was not playing flash videos before the sleep. It seems the problem is unrelated to flash. Does someone has a idea of where I can find relevant log to investigate ? /var/log/daemon/log /var/log/message /var/log/syslog do not give me any clue.
How to migrate from sid to stable?
Hi everyone, I have a computer which does not need anymore to be running the unstable version. I would like to migrate it to stable at some point. If I backup the home and rsync it on a new installation of Debian stable, I will have problems with the downgrade of softwares settings. I am not in a hurry and could slowly migrate to stable. But I am not sure changing the repositories to stable and wait with no update during a while is a good idea. I could not think of a proper (and somehow automatic) way to do this. Is there one? Pétùr
Re: Grave bug when playing flash videos
Le 12/06/2017 à 11:00, Darac Marjal a écrit : > On Sun, Jun 11, 2017 at 10:50:17PM +0200, Pétùr wrote: >> I have a serious bug when using flashplayer in debian sid. >> >> This bug freezes everything and I have to do a hard reboot. It happens >> with flashplugin and pepperflash when I play a video with flash (both >> tested with firefox and chromium). Today I am using pepperflash, >> installed by the package browser-plugin-freshplayer-pepperflash. >> >> The bug could occur after playing 2s or 2h. When I play a flash video, I >> have ~50% chances to be affected. > > Have you tried switching to a VT and back when this happens? There was a > bug in... I *think* it was something like opengl ... recently, whereby a > bunch of unrelated programs (chrome/chromium included) could freeze the > display. Switching away from X and back caused the display to refresh > and things would work again (for a time). Yes I tried to switch to TTY1 with Ctrl+Alt+F1 or to kill X server. The freeze is global and nothing works at all except a hard, electrical, reboot. >> In /var/log/daemon.log I have some inconsistencies at 21:25:28 >> represented by: >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@... > > This is less's representation of null characters and is an artefact of > journaling file systems. Syslog has told the file system "I'm about to > write X bytes to /var/log/daemon.log" and then, at some point during the > writing of that, you've killed the power. During either fsck or mount > (depending on the file system), the journal is replayed - that is, there > is a log saying "X bytes were being writen to /var/log/daemon.log". Now, > most of those bytes never made it to the disk, but the record is still > there. So the file grows by X bytes of nothing. Now the file system is > consistent (the metadate, at least, the idea being that it's better to > have SOME of the file still there, rather than a broken filesystem) Thanks for the explanation.
Grave bug when playing flash videos
I have a serious bug when using flashplayer in debian sid. This bug freezes everything and I have to do a hard reboot. It happens with flashplugin and pepperflash when I play a video with flash (both tested with firefox and chromium). Today I am using pepperflash, installed by the package browser-plugin-freshplayer-pepperflash. The bug could occur after playing 2s or 2h. When I play a flash video, I have ~50% chances to be affected. I have some difficulties to see where it comes from. I need some help. Here is the /var/log/debug for the time of the bug (occurred today at 21:25) : https://hastebin.com/hupeqituji.sql In /var/log/daemon.log I have some inconsistencies at 21:25:28 represented by: ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@... followed by: Jun 11 21:25:28 punda systemd-modules-load[218]: Inserted module 'lp' Jun 11 21:25:28 punda systemd-modules-load[218]: Inserted module 'ppdev' Jun 11 21:25:28 punda systemd[1]: Starting Flush Journal to Persistent Storage... Jun 11 21:25:28 punda systemd[1]: Started Load/Save Random Seed. Jun 11 21:25:28 punda systemd[1]: Started Flush Journal to Persistent Storage. Jun 11 21:25:28 punda systemd[1]: Started Create Static Device Nodes in /dev. Jun 11 21:25:28 punda systemd[1]: Starting udev Kernel Device Manager... Jun 11 21:25:28 punda systemd[1]: Started udev Coldplug all Devices. Jun 11 21:25:28 punda systemd[1]: Started Set the console keyboard layout. Jun 11 21:25:28 punda systemd[1]: Reached target Local File Systems (Pre). The same in syslog (a bunch of ^@^@^@^@^@^@^@^@^@^@^@^@^@^@... followed by the reboot informations). Does someone have a idea?
