bug#72277: home-shepherd is flooding tty
On 24.07.24 18:16, Dariqq wrote:
Hi,
Today I connected to my laptop running guix home over ssh as the first
session and got greeted with a lot of shepherd logs from the on-first-
login script from guix-home starting the user shepherd:
Starting service root...
Service root started.
Service root running with value #t.
Service root has been started.
WARNING: Use of `load' in declarative module (#{ g107}#). Add
#:declarative? #f to your define-module invocation.
Daemonizing...
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
Restarting signal handler.
Now running as process 2026.
Starting services...
Configuration successfully loaded from '/gnu/
store/004jm8s9km3j70gh4nhw8fzlbjls5wxa-shepherd.conf'.
Starting service dbus...
Service dbus has been started.
Service dbus started.
Service dbus running with value 2027.
[...]
Successfully started 4 services in the background.
The guile deprecation warning seems to be coming from using the
deprecated way of daemonizing the shepherd. This has been fixed in
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8da4eab2447a52c1d4f79305756cfab4df45a1a7
As I don't want to see these messages I have patched the add-shell-
profile-file procedure in gnu/home/services/shells.scm to send the
output of the on-first-login-script into the void as a workaround.
The shepherd manual mentions a --quit option (there seems to be also --
silent but not documented). Looking at the shepherd code though these
don't seem to do anything which is also not mentioned anywhere causing
even more confusion.
The devel shepherd now understands --silent (and --quiet):
https://git.savannah.gnu.org/cgit/shepherd.git/commit/?h=devel&id=6ffe404ffe794b06fddd304a963a47b62444edfa
When running the shepherd@0.15 with a backported version of the above
commmit and --silent all that is left is the warning
> WARNING: Use of `load' in declarative module (#{ g107}#). Add
> #:declarative? #f to your define-module invocation.
and when using the devel shepherd this is also gone and shepherd is
completely silent.
It would be nice to add an option to home-shepherd-configuration to
autolaunch the shepherd with --silent once it is available in a tagged
release.
bug#72917: ffmpeg@{3,4,5} build failures on i686-linux
Hi,
On 05.09.24 09:25, Ludovic Courtès wrote:
Hello,
As it turns out, while all 3 variants built fine for i686 on a machine
of mine, there are test failures at ci.guix:
From <https://ci.guix.gnu.org/build/5613329/details>:
--8<---cut here---start->8---
--- ./tests/ref/fate/filter-lavd-scalenorm 2023-11-09 23:38:51.0
+
+++ tests/data/fate/filter-lavd-scalenorm 2024-09-04 17:57:08.701821746
+
@@ -1,15 +0,0 @@
-#tb 0: 1/5
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 128x96
-#sar 0: 1/1
-0, 0, 0,1,18432, 0xac484db5
-0, 1, 1,1,18432, 0x94734db6
-0, 2, 2,1,18432, 0x3fac4db3
-0, 3, 3,1,18432, 0x37a94dcd
-0, 4, 4,1,18432, 0x2b3e4dbb
-0, 5, 5,1,18432, 0xd23a67bf
-0, 6, 6,1,18432, 0x898368e1
-0, 7, 7,1,18432, 0x79466438
-0, 8, 8,1,18432, 0x458c5d95
-0, 9, 9,1,18432, 0x9d9a56ee
Test filter-lavd-scalenorm failed. Look at
tests/data/fate/filter-lavd-scalenorm.err for details.
make: *** [tests/Makefile:304: fate-filter-lavd-scalenorm] Error 1
make: *** Waiting for unfinished jobs
TESTfilter-refcmp-psnr-rgb
Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("fate" "-j" "24")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 8.7 seconds
command "make" "fate" "-j" "24" failed with status 2
build process 18 exited with status 256
builder for `/gnu/store/7wsa154li4w974z2p6qnaaw97ng9m8hq-ffmpeg-5.1.4.drv'
failed with exit code 1
--8<---cut here---end--->8---
And from <https://ci.guix.gnu.org/build/5613330/details>:
--8<---cut here---start->8---
--- ./tests/ref/lavf/fits 1970-01-01 00:00:01.0 +
+++ tests/data/fate/lavf-fits 2024-09-04 17:57:17.900035764 +
@@ -1,9 +1,9 @@
ed9fd697d0d782df6201f6a2db184552 *./tests/data/lavf/graylavf.fits
5328000 ./tests/data/lavf/graylavf.fits
-./tests/data/lavf/graylavf.fits CRC=0xbacf446c
+./tests/data/lavf/graylavf.fits CRC=0xeb450e41
48e6caf6a59e32f9a8a39979c9183a7f *./tests/data/lavf/gray16belavf.fits
10368000 ./tests/data/lavf/gray16belavf.fits
-./tests/data/lavf/gray16belavf.fits CRC=0xae2b58d4
+./tests/data/lavf/gray16belavf.fits CRC=0xcc6d0df7
be2f7112fd193c9a909304c81e662769 *./tests/data/lavf/gbrplavf.fits
15408000 ./tests/data/lavf/gbrplavf.fits
./tests/data/lavf/gbrplavf.fits CRC=0x04ed3828
TESTfilter-pixdesc-yuv422p
TESTfilter-pixdesc-yuv444p
Test lavf-fits failed. Look at tests/data/fate/lavf-fits.err for details.
make: *** [tests/Makefile:226: fate-lavf-fits] Error 1
make: *** Waiting for unfinished jobs
Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("fate" "-j" "24")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 17.3 seconds
command "make" "fate" "-j" "24" failed with status 2
build process 18 exited with status 256
builder for `/gnu/store/90fv07zbjc92dscaj42c2yzrqpl1qlza-ffmpeg-3.4.13.drv'
failed with exit code 1
--8<---cut here---end--->8---
Are you seeing this? Does the Internet have something to say about
these?
ffmpeg@5 builds without issues for me. For ffmpeg@3 the tests always
fail at the lavf-fits tests same as the ci system.
For ffmpeg@4 which has by far the most dependants (including things like
webkitgtk etc) i have no test issues.
Thanks,
Ludo’.
I hope this helps,
Dariqq
bug#72917: ffmpeg@{3,4,5} build failures on i686-linux
Hi André, On 03.09.24 16:24, André Batista wrote: I'm sorry for that, I should've checked that this string would match on earlier versions of ffmpeg. Looking back, replacing the 'die' clause would make more sense. However, since changing it now would trigger many rebuilds, I'll send a patch which changes the match only for the broken earlier versions. Thanks, your patch looks a lot more sensible than my bruteforce way. I have successfully rebuild my system with your patch applied. What would be the best way to get it to master? QA seems to think the issue contains no patch. Thanks for reporting and feel free to CC me if/when you see that a patch of mine has been incomplete or otherwise has caused issues. Have a nice day, Dariqq
bug#72917: ffmpeg@{3,4,5} build failures on i686-linux
I was able to reconfigure the system on core updates by adding the
following snippet into openals phases
#$@(if (target-x86-32?)
#~((add-before 'configure 'unprotect
(lambda* _
(substitute* "CMakeLists.txt"
(("if\\(HAVE_GCC_PROTECTED_VISIBILITY\\)") "if(0)")
#~())
which disables the protection causing problems. I don't know what the
implications of this change are.
bug#72917: ffmpeg@{3,4,5} build failures on i686-linux
Hi, Upgraded my old i686 machine to after core updates merge (b8327cb31199fb9f4ebed6c53a59601d41def5a1) and now earlier versions of ffmpeg fail to build. phase `patch-source-shebangs' succeeded after 0.6 seconds starting phase `bypass-openal-check' phase `bypass-openal-check' succeeded after 0.0 seconds starting phase `configure' ERROR: openal not found I can't find the "alGetError ||" string in the configure script which is used to bypass the check on ffmepg@6 in the earlier versions (#72838).
bug#72697: cmake-build-system sets wrong CMAKE_SYSTEM_NAME when crossbuilding for Hurd
Hi,
I was playing around with a package using cmake and got an error when
crossbuilding for i586-pc-gnu. The reason seems to be that cmake build
system only checks for a mingw target and assumes all other targets are
Linux and sets CMAKE_SYSTEM_NAME accordingly.
I am able to work around it by adding something like
#$@(if (and (%current-target-system)
target-hurd?)
'("-DCMAKE_SYSTEM_NAME=GNU")
'())
to the configure-flags of my package.
I am unsure how a fix should look like. I was thinking of moving the
entire crossbuild code out of the build side and instead prepend the
right configure flags for the target to configure-flags for the cross
builder kind of similar how meson-build-system does it.
Unfortunately a change like this causes a lot of rebuilds.
bug#70999: (no subject)
Closing as the patch was resent in #71785 assigned to guix-patches and is now included in core-updates as commit 473590fc4cd9d5a833913ce3f7835eeedcecac21
bug#72277: home-shepherd is flooding tty
Hi,
Today I connected to my laptop running guix home over ssh as the first
session and got greeted with a lot of shepherd logs from the
on-first-login script from guix-home starting the user shepherd:
Starting service root...
Service root started.
Service root running with value #t.
Service root has been started.
WARNING: Use of `load' in declarative module (#{ g107}#). Add
#:declarative? #f to your define-module invocation.
Daemonizing...
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
Restarting signal handler.
Now running as process 2026.
Starting services...
Configuration successfully loaded from
'/gnu/store/004jm8s9km3j70gh4nhw8fzlbjls5wxa-shepherd.conf'.
Starting service dbus...
Service dbus has been started.
Service dbus started.
Service dbus running with value 2027.
[...]
Successfully started 4 services in the background.
As I don't want to see these messages I have patched the
add-shell-profile-file procedure in gnu/home/services/shells.scm to send
the output of the on-first-login-script into the void as a workaround.
The shepherd manual mentions a --quit option (there seems to be also
--silent but not documented). Looking at the shepherd code though these
don't seem to do anything which is also not mentioned anywhere causing
even more confusion.
bug#72119: All kernels depend on the latest kernel
Hi Wilko, On 15.07.24 17:43, Wilko Meyer wrote: Hi Dariqq, As a solution I would propose either - updating the default 5.14.49 header (there is a big warning next to it so probably not a good idea) - or create a second stable, recent enough header to use for such cases. I'm still in favor of the second solution, as previously discussed here: https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00182.html. Just creating a second newer header package would be relatively easy to implement without much rebuilds. (basically only all kernels which are already being rebuild weekly). The more general problem is a bit more tricky though: However, I think linux-libre-headers should refer to the latest header, and for bootstrapping purpose there *should* be a linux-libre-headers-bootstrap variable or something like that. I agree that it is a bit confusing that there is an unversioned linux-libre for the the latest kernel but the unversioned header is some arbitrary version. I'm not too knowledgable on the entire bootstrapping process, but if I see that correctly, the headers are only used in linux-libre-headers-boot0 of commencement.scm? That could be changed, even though I'm not sure what that implies in terms of rebuilds. The main part (i can see) where linux-libre-headers are used apart from the bootstrapping process is being propagated from glibc and therefore being included into *every* build environment (apart from hurd). So in terms of rebuilds basically everything. Have a nice day, Dariqq
bug#72119: All kernels depend on the latest kernel
Hi Guix, Since commit b72b6063cebbcfd64d43f5b05ba8470eb11c3f65 added dwarfes and bpf support to our kernel an update to the latest kernel causes a rebuild of all kernels. The reason is linux-libre-*->dwarfes->libbpf->linux-libre-headers-6.9 as (dependants of) libbpf need newer kernel headers than the default ones (5.15.49). As an example for this you can look at a recent kernel updates job on ci https://ci.guix.gnu.org/eval/1480123 : All kernels are being rebuilt despite only the 6.* ones being updated. This problem will probably only increase in the future as newer versions of packages might also require newer headers. I also encountered this recently when i tried to (unsuccessfully) update mutter to 46 where the build would fail as some file utilizes DMA_BUF_IOCTL_EXPORT_SYNC_FILE which (i think) was only added with the 6.0 kernel headers. Once that is properly packaged in guix using any of the "rolling" headers for mutter would then also cause weekly gnome rebuilds, etc. From the comments in the libbpf package it seems anything >= 6 should be enough for that package as well. As a solution I would propose either - updating the default 5.14.49 header (there is a big warning next to it so probably not a good idea) - or create a second stable, recent enough header to use for such cases. This would also reduce maintenance burden of constantly updating these inputs when the kernel and thus its headers are removed from guix due to becoming eol. This already caused a problem once when the 6.8 kernel was removed: https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00181.html Thanks.
bug#71360: large manifests when adding packages
I think (maybe part of) the problem is that inside entry->gexp in manifest->gexp things get compared using (the hash of) (manifest-entry-item entry) which will be a package object for the new entries but a store path "/gnu/store/*" for packages already present in the profile. Also right afterwards we test if the visited previous-entry is 'manifest-entry=?' to entry again causing a potential problem if one has a string and one a package as item entry. Would this be worth fixing? On 04.06.24 13:38, Dariqq wrote: Hi Guix, I was trying to figure out if the "repeated" tag inside a profiles manifest file is reliable to detect duplicate entries in a profile. While it was working fine for my home and system profile for the normal .guix-profile it was not: This is related to https://issues.guix.gnu.org/55499#0 resp. https://git.savannah.gnu.org/cgit/guix.git/commit/?id=4ff12d1de7cd617b791996ee7ca1240660b4c20e which marks duplicate entries in a profiles as repeated inside the profile manifest file. * Steps to reproduce To stick with the original example: Instead of adding the r packages all in one add them one by one #+begin_example guix package -p /tmp/wrong -i r-cicero-monocle3 guix package -p /tmp/wrong -i r-monocle3 #+end_example The resulting manifest file at /tmp/wrong/manifest has the huge tree for r-monocle3 twice. So the lookup mechanism in manifest->gexp does not seem to work with the install mechanism of profiles. I haven't looked more deeply into it yet. An smaller example is using zlib and glib (which propagates zlib). * Expected Behaviour It should not matter whether you install things in multiple transactions or in one. Thanks.
bug#71360: large manifests when adding packages
Hi Guix, I was trying to figure out if the "repeated" tag inside a profiles manifest file is reliable to detect duplicate entries in a profile. While it was working fine for my home and system profile for the normal .guix-profile it was not: This is related to https://issues.guix.gnu.org/55499#0 resp. https://git.savannah.gnu.org/cgit/guix.git/commit/?id=4ff12d1de7cd617b791996ee7ca1240660b4c20e which marks duplicate entries in a profiles as repeated inside the profile manifest file. * Steps to reproduce To stick with the original example: Instead of adding the r packages all in one add them one by one #+begin_example guix package -p /tmp/wrong -i r-cicero-monocle3 guix package -p /tmp/wrong -i r-monocle3 #+end_example The resulting manifest file at /tmp/wrong/manifest has the huge tree for r-monocle3 twice. So the lookup mechanism in manifest->gexp does not seem to work with the install mechanism of profiles. I haven't looked more deeply into it yet. An smaller example is using zlib and glib (which propagates zlib). * Expected Behaviour It should not matter whether you install things in multiple transactions or in one. Thanks.
bug#70999: [PATCH] build-system/meson: Add #:out-of-source? argument to build system.
Meson currently supports only out-of-source builds. Add the argument
out-of-source? with default to #t such that the install-license-files phase
searches for the license files in the source directory.
* guix/build-system/meson.scm (meson-build): Add out-of-source? argument.
(meson-cross-build): Likewise.
Change-Id: Ib59d9d93b34fd567f05f5f9a10293f6ab924e399
---
I have tested this with the tio package (both natively building and cross
compiling) and seems to work. This will cause a lot of rebuild!
For the position of the argument I've put it above build-type to match the
order in cmake-build-system.
guix/build-system/meson.scm | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/guix/build-system/meson.scm b/guix/build-system/meson.scm
index bf9ca15ecc..6c085fa1fe 100644
--- a/guix/build-system/meson.scm
+++ b/guix/build-system/meson.scm
@@ -176,6 +176,7 @@ (define* (meson-build name inputs
(outputs '("out"))
(configure-flags ''())
(search-paths '())
+ (out-of-source? #t)
(build-type "debugoptimized")
(tests? #t)
(test-options ''())
@@ -225,6 +226,7 @@ (define* (meson-build name inputs
#$(if (pair? configure-flags)
(sexp->gexp configure-flags)
configure-flags)
+ #:out-of-source? #$out-of-source?
#:build-type #$build-type
#:tests? #$tests?
#:test-options #$(sexp->gexp test-options)
@@ -257,7 +259,7 @@ (define* (meson-cross-build name
(configure-flags ''())
(search-paths '())
(native-search-paths '())
-
+(out-of-source? #t)
(build-type "debugoptimized")
(tests? #f)
(test-options ''())
@@ -338,6 +340,7 @@ (define* (meson-cross-build name
,@#$(if (pair? configure-flags)
(sexp->gexp configure-flags)
configure-flags))
+ #:out-of-source? #$out-of-source?
#:build-type #$build-type
#:tests? #$tests?
#:test-options #$(sexp->gexp test-options)
base-commit: 9756d9d6345fb142944261174453ab0a597cc2e7
--
2.41.0
bug#70999: Meson-build system fails to install license files
Hi Guix, I was trying to update a package using meson build system to its newest version and noticed in the build log starting phase `install-license-files' installing 0 license files from '.' phase `install-license-files' succeeded after 0.0 seconds Also other packages built using meson don't seem to have license files in the output. I think the problem is that the "." directory is the "build" directory and not the source directory because in meson configure phase we change directory to the build-dir. The install-license-files function has an argument for specifying out-of-source builds and calling it with that set to #t seems to be able to find license files in the source directory in my limited testing. Another option would be to specify the build dir in the ninja invocations without changing to it. As meson only supports out-of-source builds I think this should be changed though I am unsure how to best do this.
bug#70111: [PATCH] gnu: gnome-essential-extras: Propagate xdg-desktop-portal.
xdg-desktop-portal (and xdg-desktop-portal-gnome) is needed for the dark theme in Gnome 44 to work properly. * gnu/packages/gnome.scm (gnome-essential-extras)[propagated-inputs]: Add xdg-desktop-portal. Change-Id: Id84626e6bc404e9607ee7f8f299ac90f24323081 --- gnu/packages/gnome.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm index c8305b0dd8..7209a14e67 100644 --- a/gnu/packages/gnome.scm +++ b/gnu/packages/gnome.scm @@ -10306,6 +10306,7 @@ (define-public gnome-essential-extras pulseaudio shared-mime-info system-config-printer +xdg-desktop-portal xdg-user-dirs yelp zenity)) base-commit: f26b42f6c07a00dd2cecb006846e672b88748b84 -- 2.41.0
bug#70111: Gnome 44: Dark Theme not Working
Hi Guix, Updated my system to Gnome 44 f5558ee0cc1a11a8b61d3f4d43f05dd79d53ac77 and the dark style setting in Gnome no longer works (compared to Gnome 42), i.e. apps like gnome-control-center and nautilus still have the light theme even though the setting is set to Dark. The setting from the control-center is applied correctly: guix shell glib:bin -- gsettings get org.gnome.desktop.interface color-scheme 'prefer-dark' "GTK_THEME" is unset, no extra config in ~/.config/gtk-*.0/settings.ini and also Application>Appeareance in Gnome Tweaks is set to Adwaita-Dark. Some results from searching online suggest to install xdg-desktop-portal and adding that to the system profile and rebooting indeed makes the dark setting work as expected. Should this be handled by the gnome-desktop-service-type, i.e. added by one of the gnome-meta-packages (probably gnome-essential-extras)? Thanks.
bug#69678: (no subject)
Fixed by 7b9a23ea315d2b4efde755c3bd0b1db3cacba9c2
bug#69678: Gnome fails to build
Hi Guix, As of commit 9c78902d8a9350a3277b2550c0dd87019ecc832e gnome-photos and thus gnome fails to build because pkgconfig can't find babl anymore: Run-time dependency babl found: NO (tried pkgconfig) ../gnome-photos-43.beta/meson.build:155:11: ERROR: Dependency "babl" not found, tried pkgconfig Played around with the babl package a bit and I noticed that the babl.pc file in lib/pkgconfig/ is now called babl-0.1.pc. Renaming it to babl.pc makes pkg-config find babl again. Have a nice day, Dariqq
bug#57292: [PATCH v3] gnu: gdm: Enable accessibility settings.
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.
* gnu/packages/gnome.scm (gdm)[inputs]: Add at-spi2-core, dconf,
gnome-control-center.
[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(-)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 953bd817ed..a967c9cb16 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -77,6 +77,7 @@
;;; Copyright © 2023 Juliana Sims
;;; Copyright © 2023 Dominik Delgado Steuter
;;; Copyright © 2023 Zhu Zihao
+;;; Copyright © 2024 Dariqq
;;;
;;; This file is part of GNU Guix.
;;;
@@ -9007,7 +9008,18 @@ (define-public gdm
(for-each (lambda (desktop)
(symlink desktop (basename desktop)))
(find-files
- (string-append settings "/etc/xdg"))
+ (string-append settings "/etc/xdg")))
+ ;; GDM needs some additional programs available via XDG_DATA_DIRS,
+ ;; to make accessibility settings and related services available.
+ (add-after 'install 'wrap-accessibility-dependencies
+(lambda _
+ (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")
(native-inputs
(list `(,glib "bin") ;for glib-compile-schemas, etc.
dconf
@@ -9029,7 +9041,12 @@ (define-public gdm
iso-codes
libcanberra
libgudev
- linux-pam))
+ linux-pam
+
+ ;; accessibility dependencies
+ at-spi2-core
+ dconf
+ gnome-control-center))
(synopsis "Display manager for GNOME")
(home-page "https://wiki.gnome.org/Projects/GDM/";)
(description
base-commit: ffcce77ec488e3c89401ad77fafa65fcd9e9f5be
--
2.41.0
bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.
Hi, On 10.02.24 04:06, Maxim Cournoyer wrote: 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. 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. 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! 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
bug#59489: bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.
On 04.02.24 20:26, Liliana Marie Prikler wrote:
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
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.
bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.
On 30.01.24 06:27, Liliana Marie Prikler wrote: In my opinion, adding gnome-shell and gnome-control-center to gdm- configuration-gnome-shell-assets would be preferable to propagating inputs. WDYT? 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.
bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.
* gnu/packages/gnome.scm (gdm)[propagated inputs]: Add adwaita-icon-theme, dconf, font-abattis-cantarell, gnome-control-center. * gnu/services/xorg.scm (gdm-shepherd-service): Set XDG_DATA_DIR to 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(-) diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm index 6f22529dd7..c16079da0a 100644 --- a/gnu/packages/gnome.scm +++ b/gnu/packages/gnome.scm @@ -9020,6 +9020,11 @@ (define-public gdm libcanberra libgudev linux-pam)) +(propagated-inputs + (list adwaita-icon-theme +dconf +font-abattis-cantarell +gnome-control-center)) (synopsis "Display manager for GNOME") (home-page "https://wiki.gnome.org/Projects/GDM/";) (description diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm index 1ee15ea90c..8b360d7729 100644 --- a/gnu/services/xorg.scm +++ b/gnu/services/xorg.scm @@ -1039,7 +1039,9 @@ (define-record-type* (debug? gdm-configuration-debug? (default #f)) (default-user gdm-configuration-default-user (default #f)) (gnome-shell-assets gdm-configuration-gnome-shell-assets - (default (list adwaita-icon-theme font-abattis-cantarell))) + ;; XXX: Remove gnome-shell below when GDM + ;; can depend on GNOME Shell directly. + (default (list gnome-shell))) (xorg-configuration gdm-configuration-xorg (default (xorg-configuration))) (x-session gdm-configuration-x-session @@ -1136,6 +1138,10 @@ (define (gdm-pam-service config) #:allow-empty-passwords? (gdm-configuration-allow-empty-passwords? config +(define (gdm-profile-service config) + (cons* (gdm-configuration-gdm config) + (gdm-configuration-gnome-shell-assets config))) + (define (gdm-shepherd-service config) (define config-file (gdm-configuration-file config)) @@ -1164,15 +1170,7 @@ (define (gdm-shepherd-service config) "GDM_X_SESSION=" #$(gdm-configuration-x-session config)) (string-append -"XDG_DATA_DIRS=" -((lambda (ls) (string-join ls ":")) - (map (lambda (path) -(string-append path "/share")) - ;; XXX: Remove gnome-shell below when GDM - ;; can depend on GNOME Shell directly. - (cons #$gnome-shell - '#$(gdm-configuration-gnome-shell-assets -config) +"XDG_DATA_DIRS=/run/current-system/profile/share") ;; Add XCURSOR_PATH so that mutter can find its ;; cursors. gdm doesn't login so doesn't source ;; the corresponding line in /etc/profile. @@ -1237,7 +1235,7 @@ (define gdm-service-type (service-extension polkit-service-type gdm-polkit-rules) (service-extension profile-service-type - gdm-configuration-gnome-shell-assets) +gdm-profile-service) (service-extension dbus-root-service-type (compose list gdm-configuration-gdm)) base-commit: 21e4d6cd6913eca131f2c0fd0cd509fc843c7eb8 -- 2.41.0
bug#57292: bug#59489: gdm: Accessibility icon missing in log in screen
Hi Maxim, On 22.01.24 06:30, Maxim Cournoyer wrote: 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. 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? 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. OpenPGP_0x6B1E601FCD64F877.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
bug#57292: bug#59489: gdm: Accessibility icon missing in log in screen
Hi Maxim, On 20.01.24 04:12, Maxim Cournoyer wrote: 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? 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. This issue appears to have been discussed previously, although I can't find it anymore... I found https://issues.guix.gnu.org/28088 which is a bit related but not exactly the same as there is no login manager involved.
bug#57292: [PATCH] services: gdm: Add packages for accessibility settings.
gdm needs the "/share" subdirectory of these packages present in XDG_DATA_DIRS such that the accessibility settings work: - gnome-control-center: For the icon. - dconf: To be able to change settings. - at-spi2-core: contains accessibiltiy dbus-service. * gnu/services/xorg.scm ()[gnome-shell-assets]: Add at-spi2-core, dconf, gnome-control-center. Change-Id: I71138ef52af6d440fadc43425b0fc48b186dcc40 --- gnu/services/xorg.scm | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm index 1ee15ea90c..27c8aa40c3 100644 --- a/gnu/services/xorg.scm +++ b/gnu/services/xorg.scm @@ -51,6 +51,7 @@ (define-module (gnu services xorg) #:use-module (gnu packages freedesktop) #:use-module (gnu packages gnustep) #:use-module (gnu packages gnome) + #:use-module (gnu packages gtk) #:use-module (gnu packages admin) #:use-module (gnu packages bash) #:use-module (gnu system shadow) @@ -1039,7 +1040,10 @@ (define-record-type* (debug? gdm-configuration-debug? (default #f)) (default-user gdm-configuration-default-user (default #f)) (gnome-shell-assets gdm-configuration-gnome-shell-assets - (default (list adwaita-icon-theme font-abattis-cantarell))) + (default (list at-spi2-core + dconf + gnome-control-center + adwaita-icon-theme font-abattis-cantarell))) (xorg-configuration gdm-configuration-xorg (default (xorg-configuration))) (x-session gdm-configuration-x-session base-commit: 20606ca9af1ac019073f4ed872a9ad9960ff0725 -- 2.41.0
bug#57292: GDM accessibility menu buttons don't do anything
hi, the patch that i've just sent fixes the missing icon and functionality (on gdm 42.0, have not tested gnome-team branch). I've also added the at-spi2-core package discussed before. With this gdm logs that the org.a11y.Bus and org.a11y.atspi.Registry service are started. However there is a new warning later: ATK Bridge is disabled but a11y has already been enabled. I don't really how this dbus service works and if this a problem. At least the basic stuff like zoom, big text, etc. work. Also I've been unable to verify that the screenreader/orca starts in the gdm menu because sound is not working on my machine.
