gdm: Accessibility icon missing in log in screen

In the log in screen, top-right corner of the screen, the accessibility button is there, but its icon is missing. A placeholder image is shown instead.

Guix System 8280429

gdm 42.0

---

Luis Felipe López Acevedo

merge 59489 57292

quit

Hi Dariqq,

Thanks for working toward a fix for this.

Dariqq <dariqq@posteo.net> writes:

Since this is, as the name implies, intended for artwork or other

non-functional "assets", perhaps these package should be propagated by

the gdm package itself? Would that have achieve the same?

This issue appears to have been discussed previously, although I can't

find it anymore...

--

Thanks,

Maxim

tags 59489 + moreinfo

quit

Hi Maxim,

On 20.01.24 04:12, Maxim Cournoyer wrote:

That's what I tried initially and confirmed again today that it doesn't

work for both inputs or propagated inputs. (the icon from

gnome-control-center is visible because the share directory will be

included XDG_DATA_DIRS from the wrapper script from the glib-or-gtk-wrap

phase but not he other packages).

After that the next most simple solution was the hacky workaround via

gnome-shell-assets. Maybe someone has a better idea for how to include

the extra packages?

Also as I use the gnome-desktop via gnome-desktop-service-type all these

packages should already be in my system profile. So somehow the

environment is weird when shepherd starts gdm such that gdm can't find

the extra files but I don't know enough of both guix/shepherd and

gdm/gnome to figure out what the exact problem is.

I found https://issues.guix.gnu.org/28088which is a bit related but not

exactly the same as there is no login manager involved.

Hi Dariqq,

Dariqq <dariqq@posteo.net> writes:

Ah, that's interesting. It means there's probably some environment

variable that gets set and usefor the other things too, or perhaps it

searches relatively to its binary.

Ideally we could patch what it needs in the gdm package definition. A

second option would be to wrap GDM with the paths such as XDG_DATA_DIRS

it wants.

Thanks, that's the issue I remember seeing.

I'd like to avoid abusing the gnome-shell-assets, so would welcome us

further investigating the sources of GDM to get clues as to what/where

it's looking and what it wants exactly, but otherwise with your

explanation I think this can be a first step (apply this change as is).

Does anyone have a problem with it?

--

Thanks,

Maxim

Hi Maxim,

On 22.01.24 06:30, Maxim Cournoyer wrote:

Currently gdm starts with XDG_DATA_DIRS set to the share directories of

gnome-shell and all packages in gnome-shell-assets.

Looking at other login-managers it seems they also set XDG_DATA_DRIS

explicitly. Specifically the sddm-shepherd-service seems to solve this

by setting XDG_DATA_DIRS to the correct path of the current system

profile i.e. "/run/current-system/profile/share".

Maybe we could do the same with gdm? We then would need to add the extra

packages to the system profile rather than some wrapper.

This will then work work for a gdm+gnome setup (with empty

gnome-shell-assets) as the gnome package propagates all the packages

needed and more.

For gdm-only there is then a problem how to include the extra packages.

Currently the gdm-profile-service extension only adds the

gnome-shell-assets but now also gnome-shell would be needed as this

currently not in the system profile but added in XDG_DATA_DIRS.

Then there is the question whether the extra packages should be added to

the profile by the service or propagated from gdm (or some other

package). If the answer is gdm then gdm would also need to be added to

the profile and as gdm depends on gnome-shell and want's gnome-shell

present a service would need to add gnome-shell anyway.

This is essentially the same as the current solution via

gnome-shell-ssets but this will work if the extra packages are in the

system profile through any mean (and not explicitly added via the

gnome-shell-assets) however for non-gnome-setups using gdm a solution is

needed in any way.

dconf, font-abattis-cantarell, gnome-control-center.

run/current-system/profile/share.

(gdm-profile-service): New variable.

(gdm-service-type): Use gdm-profile-service.

(gdm-configuration-gnome-shell-assets): Set default to gnome-shell.

Change-Id: I870206a9ee6a7481d19e6b38b6a3ee72b5801c6a

---

Hi Maxim and others,

This is not quite the explicit wrapper we talked about on IRC but something similiar.

The gdm package now propagates the packages from gnome-shell-assets and I added dconf and gnome-control-center for basic accessibility settings functionality + icon. Does this introduce a problem as dconf is already a natice input?

Maybe also some other packages can be added like at-spi2-core, orca, ... or is this something the user should add to the system profile themselves?

In order for the gdm-shepherd-service to find the propagated packages I changed the XDG_DATA_DIR of the service to the system profile and added a gdm-profile-service to add gdm and gnome-shell to the system profile. Probably the gnome-shell-assets name should now also be changed as is is now only the gnome-shell package.

What do you think?

gnu/packages/gnome.scm | 5 +++++

gnu/services/xorg.scm | 20 +++++++++-----------

2 files changed, 14 insertions(+), 11 deletions(-)

Am Montag, dem 29.01.2024 um 21:31 +0000 schrieb Dariqq:

In my opinion, adding gnome-shell and gnome-control-center to gdm-

configuration-gnome-shell-assets would be preferable to propagating

inputs.

WDYT?

On 30.01.24 06:27, Liliana Marie Prikler wrote:

This is basically my original patch in https://issues.guix.gnu.org/57292#3.

If i understand it correctly Maxim wants gdm to take care of all of

dependencies providing functionality and handcrafting the environment

with gdm-shepherd-service and gdm-configuration-gnome-shell-assets feels

like a hacky workaround.

Am Sonntag, dem 04.02.2024 um 08:53 +0000 schrieb Dariqq:

Yes, it seems Maxim and I have conflicting goals. Maxim wants to avoid

"abusing" gnome-shell-assets whereas I want to avoid propagation, as it

pollutes profiles. Perhaps Maxim and I can agree on how to interpret

gnome-shell-assets, as IIUC even with packages that aren't "pure data"

only the data portion of it ought to be relevant, no?

We should do so especially because the newly propagated variables are

anyhow propagated by gnome-desktop-service, which could constitute

weird behaviour all around.

Cheers

On 04.02.24 20:26, Liliana Marie Prikler wrote:

What would you think of the wrap-program solution which would avoid

propagating pacakges?

I currently have something like

#+BEGIN_SRC scheme

(add-after 'install 'wrap-gdm

(lambda* (#:key inputs outputs #:allow-other-keys)

(wrap-program (string-append #$output "/bin/gdm")

`("XDG_DATA_DIRS" ":" prefix

#$(map (lambda (input)

(file-append (this-package-input input)

"/share"))

'("at-spi2-core"

"dconf"

"gnome-control-center"))))))

#+END_SRC

Also this way the assets (adwaita and cantarell) should be kept in the

gdm-configuration as when I tested this I had a white box as a cursor.

Am Montag, dem 05.02.2024 um 16:08 +0000 schrieb Dariqq:

That SGTM, but we do need a more descriptive phase name. The question

is whether we should inline the gnome-shell assets this way as well or

not.

Maxim, WDYT?

Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

I have never attempted to customize gnome-shell. If it can be

customized with custom themes, different fonts and what not, then I

think it makes sense to keep the user-choosable art assets as

gnome-shell-assets.

Otherwise, if it's not configurable and expects only a specific font,

specific icons, etc., then it seems it'd make sense that it finds them

out of the gate (wrapped from within a phase).

Could someone confirm whether GDM is configurable when it comes to icons

and fonts?

Thanks for working on it, Dariqq!

--

Thanks,

Maxim

Am Freitag, dem 09.02.2024 um 22:06 -0500 schrieb Maxim Cournoyer:

Without the context of Guix, it is. Within the context of Guix, we'd

have to make gsettings functional for most (all?) changes to have an

effect.

Cheers

Hi,

On 10.02.24 04:06, Maxim Cournoyer wrote:

I tried in a vm with only gdm-service-type (and no gnome) and the assets

also wrapped inside gdm and got a white box as a cursor. This might be

caused by adwaita not being in the profile (which gnome-shell-assets

also get added to) but I am not sure about this.

I'd suggest leaving the gnome-shell-assets as is for now and deal with

the gdm customisation issue at another time as it looks like it is more

complicated than just adding the assets to the wrapper.

Regarding the patch should I create and send it or someone of you? (I

don't really care)

And if the answer is me should the patch be against master or gnome-team

branch?

Cheers

Hi Liliana, Dariqq,

[...]

As Dariqq tried to inline the assets in the wrap phase and that did

*not* immediately, work, and since in theory a user could configure GDM

to use different assets, I think the art assets can stay where they

currently are, and the above patch merged to master to fix this

longstanding issue. Perhaps the phase name could be

'wrap-accessibility-dependencies'.

Dariqq, if you send an updated patch along these lines, I think we can

finally get it merged.

--

Thanks,

Maxim

gdm needs the "/share" subdirectory of these packages present in XDG_DATA_DIRS

such that the accessibility settings work:

- at-spi2-core: contains accessibility dbus service.

- dconf: To be able to change settings.

- gnome-control-center: icon.

[phases]: Add wrap-accessibility-dependencies phase.

Change-Id: Ibfe8f1aee9c8fe0c06f895de121f0f84defe4773

---

Hi everyone,

Here is v3 of gdm accessibility issue which adds the wrapper phase we've been discussing.

I added the extra inputs under a seperate section in the inputs. If you'd like to keep them in alphabetical order feel free to adjust this.

ALso I am not sure if the format of my commit message is ok.

I've tested on both master and gnome-team and it works on both.

To ennable the screenreader it is enough for orca to be in the system profile (and orca working i.e. on gnome-team branch).

dconf is both a native and normal input: Based on the fedora gdm.spec it seems like a build dependency however i was not able to verify this as cross-compiling (for i686-linux-gnu) requries me to bootstrap gcc. At leeast the default tests do not seem to require it.

Adding gnome-control-center, which is used for the icon, pulls in python dependencies which breaks cross compiling. Maybe you have some ideas for this.

Also some other thing that I notices is that because /var/lib/gdm is mounted as tmpfs this makes the changes in the gdm accessibility settings not persist through reboots which is annoying. These will get stored in /var/lib/gdm/.config/dconf/.

gnu/packages/gnome.scm | 21 +++++++++++++++++++--

1 file changed, 19 insertions(+), 2 deletions(-)

Am Dienstag, dem 20.02.2024 um 19:58 +0000 schrieb Dariqq:

I've rewritten the commit message slightly and pushed this to gnome-

team. Thus closing.

Cheers