Testing Stretch

There was a time when I boldly used the ever changing Debian's Sid flavor, but when the last stable version was released, Debian 8 code name "Jessie", I stuck with it. It seems has been ages but it's only a couple of years. Anyway when a few days ago I've learned that Debian 9 "Stretch" had a tentative release date set for June the 17, I decided it was time to give it a spin¹.

"Stretch, the rubber purple octopus"

I'm not going to do a review, I've used it non extensively only for a couple of days and under the hood Debian looks the same. On the outside, the shipped Gnome version was released more than a year ago so it's somewhat old news, but to me it feels fresh and I definitely like the small changes to the appearance and to the environment, at least most of all.

The Bad and the Ugly

For starters, one thing I'm less happy with, was the removal of the option to associate a menu to the physical power button. Now the choices when the button is pressed are: suspend, hibernate and doing nothing.

For the interested reader I'll report below the few lines that need to be patched in the gnome-settings-daemon

--- a/data/gsd-enums.h  2016-10-08 16:08:22.000000000 +0200
+++ b/data/gsd-enums.h  2017-05-31 07:56:53.069017123 +0200
@@ -113,6 +113,8 @@
 typedef enum
 {
   GSD_POWER_BUTTON_ACTION_NOTHING,
+  GSD_POWER_BUTTON_ACTION_INTERACTIVE,
   GSD_POWER_BUTTON_ACTION_SUSPEND,
   GSD_POWER_BUTTON_ACTION_HIBERNATE
 } GsdPowerButtonActionType;
--- a/plugins/media-keys/gsd-media-keys-manager.c   2017-05-31 08:26:10.000000000 +0200
+++ b/plugins/media-keys/gsd-media-keys-manager.c   2017-05-31 07:59:22.657383132 +0200
@@ -1990,6 +1990,12 @@

         action_type = g_settings_get_enum (manager->priv->power_settings, "power-button-action");
         switch (action_type) {
+        case GSD_POWER_BUTTON_ACTION_INTERACTIVE:
+                do_config_power_action (manager, GSD_POWER_ACTION_INTERACTIVE, in_lock_screen);
+                break;
         case GSD_POWER_BUTTON_ACTION_SUSPEND:
                 do_config_power_action (manager, GSD_POWER_ACTION_SUSPEND, in_lock_screen);
                 break;

and the gnome-control-center

--- a/panels/power/cc-power-panel.c 2017-03-10 19:15:25.000000000 +0100
+++ b/panels/power/cc-power-panel.c 2017-05-31 08:41:15.447701349 +0200
@@ -2066,6 +2066,7 @@
   } actions[] = {
     { N_("Suspend"), GSD_POWER_BUTTON_ACTION_SUSPEND },
     { N_("Hibernate"), GSD_POWER_BUTTON_ACTION_HIBERNATE },
+    { N_("Interactive"), GSD_POWER_BUTTON_ACTION_INTERACTIVE},
     { N_("Nothing"), GSD_POWER_BUTTON_ACTION_NOTHING }
   };
   guint i;

to bring back the functionality.

Unfortunately, I suspect the Debian Gnome Packaging Team comprehensibly would not accept changes like the above this late in the release process.

*Shrug* I can live with a couple of custom packages.

Stale Processes

About other small problems I've found, the Gnome Online Accounts daemon, called goa-daemon, has a weird interaction with d-bus and the gnome-keyring. Basically, when a user log out, the goa-daemon is not killed² and if the same user log in again, the still running goa-daemon process couldn't contact the new instance of the gnome-keyring. This breaks the on-line calendar, the default mail client and the third party remote storage desktop integration, in other words, the cloud stops to work.

Looks like it isn't fixed upstream yet, so my workaround is to check at log-in time if the daemon is running and replace it with a new instance if true. A simple way was creating a desktop file in my ~/.config/autostart directory with the following content:

[Desktop Entry]
Name=Replace running goa-daemon
Exec=env sh -c 'pidof goa-daemon 1> /dev/null && /usr/lib/gnome-online-accounts/goa-daemon --replace'
NoDisplay=true
Terminal=false
Type=Application

My explanation above is very brief, the interested reader can check the bug #764029 filed on the Gnome bug tracking system for the gory details. The rabbit hole in this case is quite deep.

Authorizations

Another broken thing that I've found, although somewhat specific to my notebook model, was the iio-sensor-proxy happily spamming my log file with authorization errors³. I haven't exhaustively searched for a solution, but as it's related with all kinds of sensors interactions, like accelerometers, magnetometers, photodetectors and considering that I'm not interested in using the light sensor at the moment⁴, removing the iio-sensor-proxy package solved the issue.

That wasn't the only authorization error present in my logs, as I've found another one regarding lack of permissions accessing the display's ICC profile file. I don't have a solution for it yet but for my use case it's not critical and it happens only one time at the start of the session, so it can wait. Edit: relaxing the permissions of the path /var/lib/gdm3/.local/share/icc/ fixed the error.

Wayland

Even if not activated by default for the user session, Wayland/Weston is used by GDM, the Gnome log-in manager. I've tried a Wayland session once, and it seems to run without glitches on the notebook, but I'm too reliant on a couple of utilities that work only on X, xcape and libinput-gestures, so no Wayland for me yet.

With the transition to Wayland it was changed the way to enable the "tap to click" on the greeter's log-in screen, now there is a dconf Boolean key in the GDM user configuration to flip:

$ sudo su - Debian-gdm -s /bin/sh
$ export $(dbus-launch)
$ gsettings set org.gnome.desktop.peripherals.touchpad tap-to-click true

Speaking of the greeter, another thing I'm missing is the option to switch keyboard layout, and I was unable to find yet the configuration to regain the previous menu. I suspect I need to add the relevant dconf keys/values to the GDM user, if it's possible at all. Edit: in the notebook the greeter keyboard layout is set to Colemak so it's possible, if one day I'm really bored I'll try to figure out where is configured.

Anyway, having configured the keyboard with the Colemak layout and not having a simple way to switch to a different layout at log-in time, it will be a fun challenge/small deterrent for strangers.

As a side note, now on Debian the greeter starts from the first tty instead of the seventh. Color me surprised.

Boot Cosmetic

This should be filed under "yak shaving" as I was looking to force a complete blank screen during boot. I was mildly frustrated that, even if I explicitly passed the quiet option and reduced the log level, there was still a message present a boot time about the check of the system partition(s).

At first I suspected the systemd-fsckd.service, instead the culprit was the initramfs, or better the script inside the initramfs that execute the fsck command. With this knowledge, the quick fix was to appended a redirection to /dev/null after the command invocation in the /usr/share/initramfs-tools/scripts/functions file.

--- a/usr/share/initramfs-tools/scripts/functions   2017-06-02 19:01:42.459905047 +0200
+++ b/usr/share/initramfs-tools/scripts/functions   2017-06-02 19:00:58.093797696 +0200
@@ -386,7 +386,7 @@
        log_end_msg
    else
        log_begin_msg "Checking $NAME file system"
-       logsave -a -s $FSCK_LOGFILE fsck $spinner $force $fix -T -t $TYPE $DEV
+       logsave -a -s $FSCK_LOGFILE fsck $spinner $force $fix -T -t $TYPE $DEV > /dev/null
        FSCKCODE=$?
        log_end_msg
    fi

I've also removed the super annoying blinking cursor, passing the vt.global_cursor_default=0 kernel boot directive.