Friday, May 6, 2022

(M)utter Madness - application is not responding

I am running Gnome on Debian Testing, and after a recent update to Gnome 42, I started getting the

Application is not responding

dialogue box every few seconds with any application that carries out any processing operations, forcing me to click the "Wait" button to continue. The main culprit was Synaptic, which has to update and check package lists to identify updates: a process which quite normally takes a few seconds. I was getting the "not responding message three times during this process.

I don't know what changed recently to cause this annoyance, but here is how to fix it.

Open dconf Editor and go to /org/gnome/mutter.

Look for check-alive-timeout and edit the period if necessary. Mine was set to 5000 which is 5 seconds in milliseconds. I changed to to 60000, which is 1 minute in milliseconds - a more reasonable period.


I did a bit more research and found that it may actually be the application at fault,and the issue may be limited to Wayland.

The check-alive feature is there for the user to be able to terminate frozen applications more easily. However, sometimes applications are implemented in a way where they fail to be reply to ping requests in a timely manner, resulting in that, to the compositor, they are indistinguishable from clients that have frozen indefinitely. 

When using an application that has these issues, the GUI showed in response to the failure to respond to ping requests can become annoying, as it disrupts the visual presentation of the application. 

To allow users to work-around these issues, add a setting allowing them to configure the timeout waited until an application is considered frozen, or disabling the check completely.

Gnome has added this setting, which is good.

Wayland compositors can send a ping to apps that they are supposed to respond to with a pong. However, if an app caught itself in an infinite loop or other computation that takes a long time, it might not send that pong.

Requests provided by wl_shell_surface 

wl_shell_surface::pong - respond to a ping event 


uint - serial number of the ping event 

A client must respond to a ping event with a pong request or the client may be deemed unresponsive.

Saturday, March 5, 2022

Firefox on Wayland

I'm using the Firefox release version from Ubuntuzilla on Debian Testing running Gnome, which uses Wayland by default now, so I wondered, does Firefox use Wayland by default? The answer is no, but it is fairly easy to enable it and it seems to work well, with a claimed significant improvement in rendering performance.

To enable Wayland mode in Firefox, edit



Exec=env MOZ_ENABLE_WAYLAND=1 firefox %u

(This will also work with other builds of Firefox and executable paths. See StackExchange.)

To get the performance increase in rendering, set


to true in about:config. (Arch Wiki)

There is a bug which results in the window icon and title not displaying.

To correct this I had to change the line


in the desktop file above to


(StartupWMClass must match the executable name exactly.)

I found the solution in this bug report, of which the previous bug is a duplicate, although more descriptive of this issue.

Monday, February 14, 2022

XFCE Docklike Plugin on Debian Bullseye Live

Traditionally on XFCE you would have a menu button and window buttons in the panel. You could create a launcher for an application in the form of an icon, and have window buttons in the form of icons for running applications. With the obvious disadvantage that you would have two application icons on the panel, where really you only need one (taskbars can contain a pinned launcher which, when the application is running, can also be used to switch to the application).

There is now such a taskbar available for XFCE, called xfce-docklike-plugin. It's not in the Debian Bullseye repository, so it's necessary to download, build and install it.

Unless you cheat and use the MX Linux repository based on Debian Bullseye. MX Linux XFCE edition is using the plugin as it's default window switcher. The repository is here. Tested on Debian Live XFCE non-free. You will need to install


Wednesday, January 5, 2022

Debian Security does not have a release file

If you are updating from Debian Buster to Debian Bullseye, you may notice the message in the title when editing you sources.list file. This is because the repository has changed.

In buster it was:

deb buster/updates main contrib non-free

deb buster/security main

In bullseye it is

deb bullseye-security main 


deb bullseye-security main

depending on where you look. (Debian Security Information or Debian SourcesList.)

Simply replacing Buster with Bullseye gives the error in the title.

Edit: changed the Buster repository because I think I misremembered the address. I changed to one I blogged about before as working after a similar issue.

Debian seems to be trying to make the security repository address as confusing as possible, and succeeding.

Thursday, December 16, 2021

Update icon in Firefox Mozilla build from Ubuntuzilla

In a previous post I wrote about how to get the latest version of Firefox in Debian using Ubuntuzilla. The only disadvantage with this method I have found is that the Firefox icon is seriously out of date. There is a bug report for this at Ubuntuzilla, but as it has been open for almost eight years, the chances of seeing it fixed are slim.

A user has posted a fix there.

Go to


in a terminal and do

# ln -sfn /opt/firefox/browser/chrome/icons/default/default128.png firefox-mozilla-build.png

This needs to be repeated after an update apparently.

Saturday, December 11, 2021

New Firefox ESR is late in Debian

Firefox 78 ESR reached its end of life on 2 November - five weeks ago - but the new version, Firefox 91 ESR has not arrived in Debian Stable (or indeed testing, which I am using now). That means that a number of issues that are fixed in 91 ESR will not be fixed in Firefox 78 ESR, leaving users exposed to vulnerabilities until 91 ESR arrives.

Although none of these vulnerabilities has been exploited to expose users to attack, being weeks overdue for security updates is not a good place to be.

If this makes you nervous, I will detail how to update to the latest version below.

The story has gone round the internet with an added does of FUD. It is an example of how one web site runs a story they read on another web site which read the story on a blog somewhere and nobody bothers to fact check it.

The story first appeared on BaronHK's Rants, a blog by... somebody. reprinted it, and then Phoronix and The Register covered it.

The story notes the open vulnerabilities (which is true), but the blog and the re-runs all claim that Debian won't be able to push Firefox 91 ESR to Stable because Stable isn't up to date enough. This claim comes from a bug report linked to in the blog where a post on 8 November says:

Firefox-ESR 91.3 doesn't use OpenGL GLX anymore. Instead it uses EGL by default. EGL requires at least mesa version 21.x. Debian stable (bullseye) ships with mesa version 20.3.5 For the nvidia users the following bug report might be important...

Nobody at Phoronix or The Register thought to check the progress of the bug report before running the story. If they had, they would have noticed that the bug was closed on 7 December and the problem was nothing to do with the above and was in fact in Cubed (an audio component, apparently).

So, baseless FUD from a random blog gets spread around the internet.

Debian of course has to make sure that the new Firefox ESR release doesn't have bugs. If you are nervous about using Firefox 78 ESR in Debian, here is one way to get the latest version (there are other ways).

Add the Ubuntuzilla repository and key to your Debian sources, update and install either the latest ESR, or the latest Mozilla build, Firefox 95, which is what I did (I am running Testing after all). 

Note that you will have to uninstall firefox-esr first (which will automatically install the Epiphany browser). You can then install from Ubuntuzilla. If you don't, you will get this error message:

dpkg-divert: error: 'diversion of /usr/bin/firefox to /usr/bin/firefox.ubuntu by
 firefox-mozilla-build' clashes with 'diversion of /usr/bin/firefox to /usr/bin/
firefox.real by firefox-esr'
dpkg: error processing archive /var/cache/apt/archives/firefox-mozilla-build_95.
0-0ubuntu1_amd64.deb (--unpack):
 new firefox-mozilla-build package pre-installation script subprocess returned e
rror exit status 2
dpkg-divert: error: mismatch on divert-to
  when removing 'diversion of /usr/bin/firefox to /usr/bin/firefox.ubuntu by fir
  found 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by firefox-esr'
dpkg: error while cleaning up:
 new firefox-mozilla-build package post-removal script subprocess returned error
 exit status 2
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

Installing anything from Ubuntu on Debian is normally a bad idea, as it can cause instabilities, but in this case it is fine, because the repository is just for the latest Firefox builds from Mozilla.

Update: some information from a Debian developer about the delay.

Work on this is nearing completion.

Please note that Mozilla is constantly updating to newer rustc and LLVM versions. That means that preparing a new major ESR release for Debian requires not just the packaging of the firefox-esr and thunderbird updates, but also some very complex toolchain components. Those components are usually already in unstable/testing, but for stable, oldstable, and LTS, the toolchain must be backported first.

Debian also supports additional hardware architectures and the toolchain components sometimes require specific work in order to support those additional architectures. In fact, that was the case with this current update that is underway. 


It is lamentable that it has taken this long, but that is not an indication of a lack of effort on the part of the people in Debian working on this.

From Piorunz at the mailing lists, here is an alternative method to update Firefox ESR, preserving the user profile until Firefox ESR is updated in Debian.


Piorunz also points out that Mesa is not the problem in a post on Phoronix:

Works perfectly fine with Debian Stable and Mesa 20.3.5, because Firefox 91 ESR detects Mesa version and adjust acelleration settings accordingly: 

Code: X11_EGL available by default

blocklisted by env: 

Blocklisted by gfxInfo



Thursday, December 2, 2021

Fix - Mouse Scroll Wheel stops working

My mouse scroll wheel has been stopping working intermittently for a while. I decided to open it up to see if I could get it working again. I suspected that the mouse has an optical movement detection system for the scroll wheel (as for the mouse itself) because the wheel action is so light it can only be rotating on a shaft, and that dirt might be preventing the detector form working.

Removing the battery revealed a catch which when moved over with a screw driver allowed the top panel of the mouse (the flexible bifurcated ends of which flex to activate the mouse buttons) to be removed.

The scroll wheel (remarkably car wheel like) has spokes. I am guessing* that at the bottom a beam of IR light (because there is no visible light) passes through the spokes to a detector on the other side, and the interruption of the beam is used to detect motion of the mouse wheel.

The wheel was indeed quite dirty, and I noticed a foreign object, a thin strand of unidentifiable material at the side of the wheel which could indeed have blocked light from passing through the spokes of the wheel. An examination of the spokes with a magnifying glass showed they were dusty.

I gave the wheel a clean with a soft artist's paint brush, including the spokes, a wipe with an alcohol impregnated lens cloth and a blast with an air cleaner, through the spokes and underneath and to the sides.

The scroll wheel is now functioning normally.

So don't bin that mouse when the scroll wheel stops working - give it a clean!

* I was right:, has the details, including how the detector knows which direction the wheel is turning.