Bug#979061: xfce4-screenshooter missleading/false panel icon
Package: xfce4-screenshooter Version: 1.9.8-1 Severity: normal Dear Maintainer, * What led up to the situation? updating from Buster to Bullseye * What exactly did you do (or not do) that was effective (or ineffective)? The icon sits in the panel at a size of 32x32 pixels and shows a monitor with a crossed-out screen. This lets one assume that it will i.e. switch-off the monitor or just kill the X-server. Not knowing what it was in earlier versions you never would guess it will take a screenshot. Having a look at the icon file at higher resolutions reveals that it should represent a scissor and a dotted rectangle which indictes something to be cut out. Additionally the light blue color spoils the look when sitting in a dark panel. I am using the greybird theme and not bluebird. * What outcome did you expect instead? A timy neutral (in color) panal icon showing a camera like in Buster and earlier versions of Debian. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-screenshooter depends on: ii libc62.31-6 ii libcairo21.16.0-4 ii libexo-2-0 4.16.0-1 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.4-1 ii libgtk-3-0 3.24.24-1 ii libsoup2.4-1 2.72.0-2 ii libx11-6 2:1.6.12-1 ii libxext6 2:1.3.3-1.1 ii libxfce4ui-2-0 4.16.0-1 ii libxfce4util74.16.0-1 ii libxfixes3 1:5.0.3-2 ii libxml2 2.9.10+dfsg-6.3+b1 Versions of packages xfce4-screenshooter recommends: ii libxfce4panel-2.0-4 4.14.4-1 xfce4-screenshooter suggests no packages. -- no debconf information
Bug#979059: xfce4-screenshooter missleading/false panel icon
Package: xfce4-screenshooter Version: 1.9.8-1 Severity: normal Dear Maintainer, * What led up to the situation? updating from Buster to Bullseye * What exactly did you do (or not do) that was effective (or ineffective)? The icon sits in the panel at a size of 32x32 pixels and shows a monitor with a crossed-out screen. This lets one assume that it will i.e. switch-off the monitor or just kill the X-server. Now knowing what it was in earlier versions you never would guess it will do a screenshot. Having a look at the icon file at higher resolutions reveals that it should represent a scissor and a dotted rectangle which indictes something to be cut out. Additionally the light blue color spoils the look when sitting in a dark panel. I am using the greybird theme and not bluebird. * What outcome did you expect instead? A timy neutral (in color) panal icon showing a camera like in Buster and earlier versions of Debian. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-screenshooter depends on: ii libc62.31-6 ii libcairo21.16.0-4 ii libexo-2-0 4.16.0-1 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.4-1 ii libgtk-3-0 3.24.24-1 ii libsoup2.4-1 2.72.0-2 ii libx11-6 2:1.6.12-1 ii libxext6 2:1.3.3-1.1 ii libxfce4ui-2-0 4.16.0-1 ii libxfce4util74.16.0-1 ii libxfixes3 1:5.0.3-2 ii libxml2 2.9.10+dfsg-6.3+b1 Versions of packages xfce4-screenshooter recommends: ii libxfce4panel-2.0-4 4.14.4-1 xfce4-screenshooter suggests no packages. -- no debconf information
Bug#898726: Fixed in version xfce4-sensors-plugin 1.3.92-1 from experimental
I faced the same problem (wanting to monitor fan2, but showed the value of AVCC in Volts) in Bullseye. Super I/O chip in Bullseye needs following module: nct6775 instead of formerly w83627ehf, while "sensors-detect" still reports the old module (address 0xa00, driver `w83627ehf') - should be fixed as well. In Buster I was lucky to get it right with this lines in ~/.config/xfce4/panel/xfce4-sensors-plugin-31.rc: [Chip2_Feature10] Id=-1 Address=10 Name=CPU-Fan Color=#00B000 Show=true Min=248,00 Max=3500,00 However in Bullseye I had no success even after hours to fiddle around. Finally, before reporting the bug, I checked with xfce4-sensors-plugin 1.3.92-1 from experimental and can confirm that this resolves the problem for me. To complete the information, here the output of "sensors" in Bullseye: $ sensors coretemp-isa- Adapter: ISA adapter Package id 0: +39.0°C (high = +85.0°C, crit = +105.0°C) Core 0:+37.0°C (high = +85.0°C, crit = +105.0°C) Core 1:+33.0°C (high = +85.0°C, crit = +105.0°C) Core 2:+35.0°C (high = +85.0°C, crit = +105.0°C) Core 3:+39.0°C (high = +85.0°C, crit = +105.0°C) acpitz-acpi-0 Adapter: ACPI interface temp1:+27.8°C (crit = +106.0°C) temp2:+29.8°C (crit = +106.0°C) nct6775-isa-0a00 Adapter: ISA adapter Vcore: 896.00 mV (min = +0.00 V, max = +1.74 V) in1: 768.00 mV (min = +0.00 V, max = +0.00 V) ALARM AVCC:3.39 V (min = +2.98 V, max = +3.63 V) +3.3V: 3.41 V (min = +2.98 V, max = +3.63 V) in4: 1.26 V (min = +0.00 V, max = +0.00 V) ALARM in5: 752.00 mV (min = +0.00 V, max = +0.00 V) ALARM in6: 1.08 V (min = +0.00 V, max = +0.00 V) ALARM 3VSB:3.34 V (min = +2.98 V, max = +3.63 V) Vbat:3.30 V (min = +2.70 V, max = +3.63 V) fan1: 270 RPM (min =0 RPM, div = 64) fan2: 329 RPM (min =0 RPM, div = 64) fan3: 397 RPM (min =0 RPM, div = 64) fan4: 0 RPM (div = 128) SYSTIN: +34.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = CPU diode CPUTIN: +39.5°C (high = +80.0°C, hyst = +75.0°C) sensor = CPU diode AUXTIN:+127.0°C (high = +80.0°C, hyst = +75.0°C) sensor = CPU diode PECI Agent 0: +38.5°C (high = +80.0°C, hyst = +75.0°C) (crit = +105.0°C) PCH_CHIP_TEMP: +65.0°C (high = +80.0°C, hyst = +75.0°C) PECI Agent 1:+0.0°C (high = +80.0°C, hyst = +75.0°C) (crit = +72.0°C) PCH_CPU_TEMP:+0.0°C cpu0_vid: +0.000 V intrusion0:ALARM beep_enable: disabled My guess for the problem is that some counter flips over at more than 8 sensors per adapter, so the value of line 2 (3.39V) is taken as output for sensor in line 10 (fan2) in the sample above. This way also the naming from line 10 was asigned to sensor 2 (double fan2 enties). The working entry in ~/.config/xfce4/panel/xfce4-sensors-plugin-31.rc now is like this: [Chip2_Feature10] Address=10 Name=CPU-Fan Color=#00B000 Show=true Min=301,00 Max=3500,00 Regards, Alf
Bug#929834: additional information
I meanwhile ended up using the buster-backports kernel 5.4.0-0.bpo.3-amd64. It seems the only way to avoid the nasty bug having to switch VT to get the monitor back on after blanking/power save. The Intel X11-driver has other drawbacks. While dealing with that problem quite often (also when upgrading 2 Lenovo-Tx20 laptops) I observed following with Ivy-Bridge and Sandy-Bridge CPU's): This problem manly happens when I first boot into another OS and thereafter into Buster without power cycle. Happens i.e. when you upgrade Stretch using a VT and finally reboot. Also happens when I save the complete Buster partition for backup using i.e. Clonezilla or on my PC where I have dual-boot with Stretch and Buster. This problem seems to dissappear with time when further exclusively booting Buster. Could it be that in Buster the GPU is not reset/initialized correctly and there are some settings remaining from previous boot/configuration?
Bug#929834: Found a workaround which also solves other oddities
I did try the different workarounds in Buster like "xset s off", disabling light-locker so it wouldn't start, tried kernel 5.3. All these improved the situations with "black screen", but finally still some situations where the monitor should awake from DPMS state remained and I had to switch virtual console (Ctrl+Alf+F1/F7) randomly every few days. Now I discovered this posting from Dai_trying: http://forums.debian.net/viewtopic.php?f=10=142383#p700796 and generated a /etc/X11/xorg.conf as described service lightdm stop X -configure cp /root/xorg.conf.new /etc/X11/xorg.conf And that really works without any glitches for over a week so far. Additionally it also solved another bug which I reported on 19. March 2019: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893559 It caused solaar (tool to manage Logitech Unifying Receiver) failing to start in xfce4 when set up for automatic start in session. Now it starts reliable iconised in the xfce4-panel. So, my guess is that this nasty bug is actually caused not caused by light-locker, but instead by xorg-server which either looses the mouse or fails to (re)start with correct configuration. With said xorg.conf all this is gone.
Bug#929834: With kernel linux-image-5.3.0-1-amd64 it seems to be fixed
Hi Yves-Alexis, I tested in Buster with kernel linux-image-5.3.0-1-amd64 from unstable and "modesetting" DDX: it appears to be fixed. Hardware is Intel Iyv-Bridge CPU with HD4000 GPU. The workarounds like using "intel" driver or "xset s off" are no longer required - great since the intel driver causes other problems. Would be great if that fix could be applied to the standard Buster kernel 4.19.0, so users will not have to use buster-backports repo.
Bug#942449: Found a solution/workaround
To remove those dead drive icons I just edited /etc/fstab and appended "x-gvfs-hide" to the mount options of those partititions like this: UUID=ea5ad8...de2 /media/sda1 ext4 noatime,errors=remount-ro,noauto,x-gvfs-hide 0 0 Immediately the icons disappear , even without reboot. So, it's just ea configuration error which reports partititions marked "nouser" as removable. Whether it is xfdesktop4 or even a bug in gvfs I don't know.
Bug#942449: xfdesktop4: Icons for hidden disk partitions are shown as removable on the desktop
Package: xfdesktop4
Version: 4.12.4-2
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where
appropriate ***
* What led up to the situation?
Upgrading from Stretch to Buster made hidden drive icons of HD-partititions
appear on the desktop. It is impossible to hide them as before. This is
independant whether they are mountd or unmonted (when set to "noauto").
Those partititions are listed in fstab for manual mount by root only.
fstab entries are like this:
#/dev/sda1
UUID=ea5ad8...de2 /media/sda1 ext4 noatime,errors=remount-ro,noauto 0 0
* What exactly did you do (or not do) that was effective (or
ineffective)?
I have set up UDEV rules to hide those "drives" from users like this:
KERNEL=="sda1",ENV{UDISKS_IGNORE}="1"
According to freedesktop-org documentation the "HintIgnore" property
property should:
If TRUE, the device should be hidden from users.
Thunar beheaves correctly and does not show those drives.
* What was the outcome of this action?
All worked fine as it should in previous Debian releases including
Stretch, but since Buster I cannot hide the drives anymore.
Clicking on them just tells me:
"could not be mounted, operation permitted for root only."
* What outcome did you expect instead?
Respecting the UDEV-rules and not show "dead" icons on the desktop,
where normal users do not have access to.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 10.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8),
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xfdesktop4 depends on:
ii exo-utils0.12.4-1
ii libc62.28-10
ii libcairo21.16.0-4
ii libdbus-1-3 1.12.16-1
ii libdbus-glib-1-2 0.110-4
ii libexo-1-0 0.12.4-1
ii libgarcon-1-00.6.2-1
ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii libglib2.0-0 2.58.3-2+deb10u1
ii libgtk2.0-0 2.24.32-3
ii libnotify4 0.7.7-4
ii libpango-1.0-0 1.42.4-7~deb10u1
ii libpangocairo-1.0-0 1.42.4-7~deb10u1
ii libwnck222.30.7-6
ii libx11-6 2:1.6.7-1
ii libxfce4ui-1-0 4.12.1-3
ii libxfce4util74.12.1-3
ii libxfconf-0-24.12.1-1
ii xfdesktop4-data 4.12.4-2
Versions of packages xfdesktop4 recommends:
ii dbus-user-session [default-dbus-session-bus] 1.12.16-1
ii dbus-x11 [dbus-session-bus] 1.12.16-1
ii librsvg2-common 2.44.10-2.1
ii tumbler 0.2.3-1
ii xdg-user-dirs 0.17-2
Versions of packages xfdesktop4 suggests:
pn menu
-- no debconf information
Bug#929834: Buster/XFCE unlock screen is blank
Am 22.06.19 um 23:34 schrieb John Franklin: > > I've been suffering from this bug in a clean Buster system, too. A > solution noted in another bug tracker is to explicitly tell X.org to > use the intel driver. Apparently, it uses the fbdev driver by default. > (Sorry, I don't have a reference to other bug handy.) > > Per a suggestion in the other bug, I added the following config about a > week ago and haven't seen the problem since. > > $ cat /etc/X11/xorg.conf.d/20-intel.conf > Section "Device" > Identifier "Intel Graphics" > Driver "intel" > EndSection > > jf > Great John, I can confirm that it fixes the bug here too. My hardware: Ivy-Bridge i5 with Intel HD4000 graphics. Thanks, Alf
