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

[Matthijs Kooijman]

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
```

[Matthijs Kooijman (matthijskooijman)]

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

[Daniel van Vugt (vanvugt)]

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

[Matthijs Kooijman (matthijskooijman)]

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).

[Daniel van Vugt (vanvugt)]

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

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Max (foorack)]

The issue still remains and breaks xterm defaults on Ubuntu 22.04.

If Xresources is a folder, the upstream gdm3 Xsession script will fail even with this change, so this bug was not introduced by them and should not be fixed there.

[Ken Gilmer (kgilmer)]

This seems to be preventing the Regolith X11 desktop session from properly initializing. Due to this bug, the gdm3-produced Xsession does not initialize xrdb, which is a required component in Regolith. While a workaround seems simple enough, I guess any X11-based gdm3 session with applications that use Xresources may not be properly initialized on a system with this bug. As such, IMO this bug deserves to be fixed.