/etc/X11/Xresources no longer loaded, error in patch

Bug #1955850 reported by Matthijs Kooijman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gdm3 (Ubuntu)
New
Undecided
Unassigned

Bug Description

After upgrading from 21.04 to 21.10, my /etc/X11/Xresources/ directory no longer loads on login.

Looking at the sources, I think this can be traced to:
 - Switching from a custom Xsession file to the upstream Xsession file in 3.38.0-1ubuntu1, combined with
 - An oversight in `debian/patches/ubuntu/xresources_is_a_dir.patch`

Looking at [that patch](https://salsa.debian.org/gnome-team/gdm/-/blob/ubuntu/master/debian/patches/ubuntu/xresources_is_a_dir.patch), it has:

```diff
--- a/data/Xsession.in
+++ b/data/Xsession.in
@@ -122,6 +122,13 @@ fi

 if [ -f "$sysresources" ]; then
     xrdb -nocpp -merge "$sysresources"
+elif [ -d "$sysresources" ]; then
+ # directory of Xresources files on Debian/Ubuntu
+ for i in `ls "$sysresources"` ; do
+ if [ -r "$sysresources/$i" -a -f "$sysresources/$i" ] && expr "$i" : '^[[:alnum:]_-]\+$' > /dev/null; then
+ xrdb -nocpp -merge "$sysresources/$i"
+ fi
+ done
 fi

 if [ -f "$userresources" ]; then
```

However, looking a few lines further up in [the original Xsession.in file](https://salsa.debian.org/gnome-team/gdm/-/blob/ubuntu/master/data/Xsession.in#L97), I see:

```sh
if [ -f /etc/X11/Xresources ]; then
    sysresources=/etc/X11/Xresources
else
    sysresources=/usr/etc/X11/Xresources
fi
```

In other words, if `/etc/X11/Xresources` is a directory, the `sysresources` variable is never set correctly, so the patch should also modify this part of the script.

I have observed this broken behavior on version 41~rc-0ubuntu2, but looking at the ubuntu/master branch (as linked above), it still seems broken there.

I'm currently testing this patch:

```diff
--- Xsession.orig 2021-12-27 22:05:09.038863375 +0100
+++ Xsession 2021-12-27 22:05:33.143057433 +0100
@@ -111,7 +111,7 @@
 usermodmap="$HOME/.Xmodmap"
 userxkbmap="$HOME/.Xkbmap"

-if [ -f /etc/X11/Xresources ]; then
+if [ -e /etc/X11/Xresources ]; then
     sysresources=/etc/X11/Xresources
 else
     sysresources=/usr/etc/X11/Xresources
```

I don't know if it works yet, since I need to log out for that, and close my browser, so need to submit this report first ;-)

```
$ lsb_release -rd
Description: Ubuntu 21.10
Release: 21.10
$ apt-cache policy gdm3
gdm3:
  Installed: 41~rc-0ubuntu2
  Candidate: 41~rc-0ubuntu2
  Version table:
 *** 41~rc-0ubuntu2 500
        500 http://nl.archive.ubuntu.com/ubuntu impish/main amd64 Packages
        100 /var/lib/dpkg/status
```

Revision history for this message
Matthijs Kooijman (matthijskooijman) wrote :

Just tested, the above test solves the problem for me.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I wonder why we are still maintaining and releasing an 11 year old patch...

Revision history for this message
Matthijs Kooijman (matthijskooijman) wrote :

Hm, that patch is indeed old, that is not consistent with what I thought was going on. So I looked a little closer.

> Looking at the sources, I think this can be traced to:
 - Switching from a custom Xsession file to the upstream Xsession file in 3.38.0-1ubuntu1, combined with
 - An oversight in `debian/patches/ubuntu/xresources_is_a_dir.patch`

It seems the first point is not actually true. The changelog for that version does list "Don't install debian/Xsession", but it is under "Merge with Debian. Remaining changes:", so it's not a new change in that version, just a statement of an existing difference between Ubuntu and Debian. Looking in the current changelog, the earliest version that mentions this change is 3.26.2.1-2ubuntu1 (from 2017), but already as "remaining". I could not find which version introduced this change, but given the age of the patch, I can imagine it has been around since 2011.

In that light, I suspect that the problem I'm seeing is not introduced by switching to upstream Xsession, but by a change in the upstream XSession file that this patch has not been adapted to. And indeed, it's this one: https://gitlab.gnome.org/GNOME/gdm/-/commit/d98debd294060489c77d913d32674c4e08987b8f

But indeed, submitting this patch (after fixing it) upstream is probably a good idea to prevent issues like this in the future (but I don't have the time to take that on).

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

If you have time to report the bug to the developers then please do so at https://gitlab.gnome.org/GNOME/gdm/-/issues

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.