'tests/guix-system.sh' fails on aarch64-linux

  • Done
  • quality assurance status badge
Details
6 participants
  • Aiko Kyle
  • Chris Marusich
  • Leo Famulari
  • Ludovic Courtès
  • Maxime Devos
  • Pierre Langlois
Owner
unassigned
Submitted by
Leo Famulari
Severity
normal
L
L
Leo Famulari wrote on 31 Dec 2021 00:52
(address . bug-guix@gnu.org)
Yc5GWSoOdA4N8o+x@jasmine.lan
The Guix test 'tests/guix-system.sh' fails on aarch64-linux, like this:

------
+ for example in gnu/system/examples/*.tmpl
+ grep hurd
+ echo gnu/system/examples/desktop.tmpl
+ target=
+ guix system -n disk-image gnu/system/examples/desktop.tmpl
accepted connection from pid 23537, user nixbld
guix system: warning: 'disk-image' is deprecated: use 'image' instead
spurious SIGPOLL
spurious SIGPOLL
spurious SIGPOLL
guix system: error: service 'xorg-server' provided more than once
+ rm -f t-guix-system-22708 t-guix-system-error-22708 /tmp/guix-build-guix-1.3.0-17.2a49ddb.drv-0/t-guix-system-22708/config.scm /tmp/guix-build-guix-1.3.0-17.2a49ddb.drv-0/t-guix-system-22708
/my-torrc
+ rmdir /tmp/guix-build-guix-1.3.0-17.2a49ddb.drv-0/t-guix-system-22708
FAIL tests/guix-system.sh (exit status: 1)
------

This manifests while building the 'guix' package itself. Specifically
this derivation:

/gnu/store/i8rjwl9fmm4b6icvry8l2wlz2dwq09ic-guix-1.3.0-17.2a49ddb.drv

... which is based on commit 9f6532c77d35603f5e5d190616e0c6b1740e82bd:


It doesn't happen on x86_64-linux:

L
L
Leo Famulari wrote on 2 Jan 2022 03:14
(no subject)
(name . GNU bug tracker automated control server)(address . control@debbugs.gnu.org)
YdEKgAUl76AdwYB5@jasmine.lan
merge 52908 52943
C
C
Chris Marusich wrote on 4 Jan 2022 03:15
Re: bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
(address . 52908@debbugs.gnu.org)
87wnjgqm93.fsf@gmail.com
Hi Leo and Aiko,

This issue also affects powerpc64le-linux.

Aiko's patch would indeed fix the failing test. Thank you, Aiko, for
taking the initiative to help investigate and solve the issue! However,
even though that patch would fix the test, anyone who is using
set-xorg-configuration on a non-x86_64 system would still need to change
the way they call it, which is not ideal.

I've attached a different patch that attempts to fix the issue without
requiring callers of set-xorg-configuration to update their code. I
believe this is more consistent with the intent of Ludo's original
change in commit 49599fab564f203b8e92d32e9b28c99e99849bfb.

You'll notice that this patch moves the (gnu services sddm) code into
(gnu services xorg) and deprecates (gnu services sddm). I did this in
order to avoid a circular dependency between the two modules. Perhaps
there's a better way. However, many of the existing display managers
already live in (gnu services xorg), so it seemed reasonable to me.

I've verified that the tests/guix-system.sh test passes on
powerpc64le-linux after applying this patch to current master branch (on
top of commit 9309b488ca4ceef4fcc9283546e3b05c57b16ca8). I've also
verified that the deprecation warnings are being emitted, and that the
existing bindings in (gnu services sddm) are still usable, at the REPL:

Toggle snippet (27 lines)
$ ./pre-inst-env guix repl
GNU Guile 3.0.7
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use (gnu services sddm)
scheme@(guix-user)> (sddm-configuration)
guix repl: warning: 'sddm-configuration' is deprecated, use '(@ (gnu services xorg) sddm-configuration)' instead
$1 = #<<sddm-configuration> sddm: [... omitted for brevity ...]
scheme@(guix-user)> (sddm-configuration? $1)
guix repl: warning: 'sddm-configuration?' is deprecated, use '(@ (gnu services xorg) sddm-configuration?)' instead
$2 = #t
scheme@(guix-user)> sddm-service-type
guix repl: warning: 'sddm-service-type' is deprecated, use '(@ (gnu services xorg) sddm-service-type)' instead
$3 = #<service-type sddm 4b3812c0>
scheme@(guix-user)> (sddm-service)
guix repl: warning: 'sddm-service' is deprecated, use '(@ (gnu services xorg) sddm-service)' instead
guix repl: warning: 'sddm-service' is deprecated, use 'sddm-service-type' instead
$4 = #<<service> type: #<service-type sddm 4b3812c0> value:
#<<sddm-configuration> sddm: [... omitted for brevity ...]
scheme@(guix-user)>

-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmHTrdgVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadvM0P/0V/0ObQP0GEn9FOzMDjy7ZrCO7M
Zi999aV4epia4cGzYsYb+fFNcSrXJ1fQu6hKG0QIdZGqLhLkdaXfnTcDdhPx2TDJ
sEVsjisfpd1IX+JazYmQTVQzeySaBqyIJy9f/YRrkbrCVlVNyRpDwEWztCBajKtN
CDeAhNG2/e9egHiq5em8D/D7ZC/QdfwRgYPUxJS3xdBEQu0XYHjziNtunDz7YVfl
l3B1Xc2K20sH5qy/Rl54BUq7riIC54MzCbRYJ5MLDobv9XWSUkv/MXQPvsYNBxQS
MF0ECJKDRwVJNVZsXUGoKPIvdzMO8K1VJ1Hc1mdQRPG7lARx5cQK0PfGpJiRghde
ST8QNMsKhJPKejKgmCy1/fUp+Ujdr0qBS0DSim6ZrWy3j87jE4KT88zUMlRXiMBQ
hLE4m4fUN0qyrl49aobDEjNbeP2MCl3Oqss8mNtxFwSFoBlseva68jLpI+EPoRlf
JbMJfnwdAdm7mS3LHwaBLgRlOqQVd1hR4FUC7zaR7WTk6E+tT3GZdTCZqK9blXlQ
T6GKQfNobA/asT6y8849ixLZ52Kf+KB2oopDlFjP7Y8gSTODiIv2wiWI6Ex4Visf
HXR0xXCChdJSJDf+HRpw1dDF3JfvZb90zXMgbkTZ/XLC+LiTih/hMsJ5EsWsRHa6
h192cJ5SECgoVh6y
=/KpX
-----END PGP SIGNATURE-----

A
A
Aiko Kyle wrote on 4 Jan 2022 04:43
(name . Chris Marusich)(address . cmmarusich@gmail.com)
CAPWcbYHDLkQxxO4Y+Z=FCC6jDprUm_NfYF1rBDaJDn40KP+Duw@mail.gmail.com
On Mon, Jan 3, 2022 at 7:15 PM Chris Marusich <cmmarusich@gmail.com> wrote:
Toggle quote (19 lines)
>
> Aiko's patch would indeed fix the failing test. Thank you, Aiko, for
> taking the initiative to help investigate and solve the issue! However,
> even though that patch would fix the test, anyone who is using
> set-xorg-configuration on a non-x86_64 system would still need to change
> the way they call it, which is not ideal.
>
> I've attached a different patch that attempts to fix the issue without
> requiring callers of set-xorg-configuration to update their code. I
> believe this is more consistent with the intent of Ludo's original
> change in commit 49599fab564f203b8e92d32e9b28c99e99849bfb.
>
> You'll notice that this patch moves the (gnu services sddm) code into
> (gnu services xorg) and deprecates (gnu services sddm). I did this in
> order to avoid a circular dependency between the two modules. Perhaps
> there's a better way. However, many of the existing display managers
> already live in (gnu services xorg), so it seemed reasonable to me.
>

I originally tried to implement this patch, but as a relative newcomer
to guix and guile scheme, I went for the easier patch of changing the
tests since I wasn't sure which would be the preferred way to fix this
issue. I'll defer to you and Leo for that judgment!

Toggle quote (7 lines)
> I've verified that the tests/guix-system.sh test passes on
> powerpc64le-linux after applying this patch to current master branch (on
> top of commit 9309b488ca4ceef4fcc9283546e3b05c57b16ca8). I've also
> verified that the deprecation warnings are being emitted, and that the
> existing bindings in (gnu services sddm) are still usable, at the REPL:
>

Commit 9309b48 seems to be a week old and I can't seem to apply this
patch on top of the latest commit on master e6fe4e5819.
C
C
Chris Marusich wrote on 4 Jan 2022 05:53
(name . Aiko Kyle)(address . aikokyle@gmail.com)
87bl0s5cfx.fsf@gmail.com
Hi Aiko,

Aiko Kyle <aikokyle@gmail.com> writes:

Toggle quote (3 lines)
> Commit 9309b48 seems to be a week old and I can't seem to apply this
> patch on top of the latest commit on master e6fe4e5819.

How did you apply the patch? I was able to apply the patch locally to
commit 80ebf564e3e264a006d7c7b1f7f2e57fc2468ef1 (".guix-authorizations:
Remove Miguel Ángel Arruga Vivas due to inactivity."), which is
currently the latest commit on master.

I applied by patch by saving the MIME part to a file named "/tmp/patch".
Then I ran the following command from a clean Git checkout of commit
80ebf564e3e264a006d7c7b1f7f2e57fc2468ef1:

git am /tmp/patch

For the record, the SHA-256 hash value of the patch file is
6650872d41068f6031633d2720553eeb05e7d650a51723dfdd2a3c2df3df294e. If
you run "sha256sum /tmp/patch", do you see the same hash value?

--
Chris

-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmHT0sIVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadi6MQALDdnhKKxeUW1tI+/PS9igWPUNIL
/6MLH9Bp3WCRQCGBWyl1e9OLoMKfnbZyYfzrX7gmiLzQh+1Of2b+lEfCRqC43XJZ
ccD1OI94R89NTv75aLx0dmYa9DvBN8Yj1GEqj4jkmmJkjRnvmQiyLFUDv2EJj468
xhfRn7Cq3Gl5vuhFBBt3FsjK8x233PXGQEOEhJ8FUKd62RXSyBXKYniadJ+5h7WI
qaeRDvJOpAHgd3Tr6lFTQIucaCsMvc2MdifXps6p0TW6nckHH9XItX9ZaBZGfmYg
XluWw2jco5/PYBoebaNm41FZwBSRjPCni4lzNyhlYNOTvaAJmW2yEvwy2biWwMsB
Ogyc6hUAebeCr53VqL3DzMFsNI5d+cOhXPoalVwn3ewBY1D2QoDStHNZdW/kOO9/
kDNK+hs7igfUgAJX0SXCz3mH3LjbmM/imX5HQ2/Kpa+3QwjyPQJGt2xgI6Bes01Q
yTB+D0XQ8u3JWKYzCJdykKTWGrIIoWSEyBC3gFJohdCuqtFgL7tqjCSb8Km03X0F
RTSqqVwjFVyLzX9Npv+2cqk/WxPUgd8tx6SDg/5Pi28N2mXpcKIZc9jB3MmMHaea
PQtpyAyD4y/h0fafd5ksBiG287CHc+GR3icP3GHMAWatsCCj3N+QH++/UbGAhNdT
O8LVwILccuoetoo8
=Bv1K
-----END PGP SIGNATURE-----

A
A
Aiko Kyle wrote on 4 Jan 2022 06:08
(name . Chris Marusich)(address . cmmarusich@gmail.com)
CAPWcbYHPT2Z+FBqcJmKm+E6TRZdRQx=RK2QzqkNQzRZbuf0HOg@mail.gmail.com
On Mon, Jan 3, 2022 at 9:53 PM Chris Marusich <cmmarusich@gmail.com> wrote:
Toggle quote (7 lines)
>
> > Commit 9309b48 seems to be a week old and I can't seem to apply this
> > patch on top of the latest commit on master e6fe4e5819.
>
> How did you apply the patch?
>

Without thinking apparently (i.e. using git apply). It applies just
fine, sorry for the noise. I can confirm the test passes here on
aarch64.

It would be great to get this upstreamed soon so I can start guix
pulling master. I think the guix commit and revision in
package-management.scm will also need to be bumped after applying this
fix.
L
L
Leo Famulari wrote on 4 Jan 2022 18:28
(name . Aiko Kyle)(address . aikokyle@gmail.com)
YdSDzTR7uNj+sP/q@jasmine.lan
On Mon, Jan 03, 2022 at 08:43:27PM -0700, Aiko Kyle wrote:
Toggle quote (2 lines)
> I'll defer to you and Leo for that judgment!

I defer to you and Chris! And I agree, let's push the fix ASAP :)
C
C
Chris Marusich wrote on 5 Jan 2022 10:58
(address . 52908@debbugs.gnu.org)
878rvua4h8.fsf_-_@gmail.com
Hi Aiko and Leo,

Aiko Kyle <aikokyle@gmail.com> writes:

Toggle quote (5 lines)
> It would be great to get this upstreamed soon so I can start guix
> pulling master. I think the guix commit and revision in
> package-management.scm will also need to be bumped after applying this
> fix.

It shouldn't be necessary to update the guix commit and revision in
package-management.scm. My understanding is that "guix pull" will
install Guix at the specified commit; it does not use the guix package
to decide which version to install. In other words, even if at the
specified commit the "guix" package is defined to use an older version
(I believe this is always the case, actually), it will not stop "guix
pull" from installing Guix at the specified commit.

If it's necessary to update the "guix" package, we can certainly do it.
However, I don't recall that it's necessary for fixing "guix pull"
problems like this. If you still believe it's necessary, can you help
me to understand why it's necessary?

Leo Famulari <leo@famulari.name> writes:

Toggle quote (5 lines)
> On Mon, Jan 03, 2022 at 08:43:27PM -0700, Aiko Kyle wrote:
>> I'll defer to you and Leo for that judgment!
>
> I defer to you and Chris! And I agree, let's push the fix ASAP :)

OK. I want to give people time to comment on the patch, but I also want
to help fix "guix pull" on master sooner rather than later. I will
commit my patch in about 48 hours to the master branch if nobody has any
further feedback.

I don't think my patch will trigger many rebuilds. To verify this, I
tried building coreutils on powerpc64le-linux before and after applying
my patch. It did not trigger a rebuild of coreutils, so I don't think
it will trigger many rebuilds. It's conceivable that some derivation
that uses the (gnu services xorg) or (gnu services sddm) modules might
change (maybe something related to Guix System?), but I don't know of an
easy way to check that.

--
Chris

-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmHVa9MVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkad9xUQANNw7ITCvRSMXeYAKct+SqIZWxgv
PhwOpK39Daa4SqRlFyOz6dlMXTwFV1cm4M+z/VQn+CaGIp5cbiBDwW5C46SC8ueT
jWj5TwSrER6R8NXLJ5JK4mF3B8YOWNfOeoUnlF+tAsYstVlb9Izsd5IXzfeI5x2w
iqEB2HNmpdbfiKfYBI/5UTE76OlrqJ7MGNIUpLzEV33H3MSbclMawFJ+ViV0xlQG
0wRaJozGUdN4yjim0cnGD2BnvoGxTCn3+1VAIDWUGTa4E0Fs1oiaE+6H4KFaPF+n
fLQnJ1ATqMT1o+xaL1wbbTK0prFPjtZf+JuSK8hG4iWHZlKH6obMSo4LpIo2itCw
b2v+ZmjyqAVgGbsevGagbee1xJ52VAOa1j58HGtI2FO9qXzNfT0JOgx50UtBiXLy
YT+nDiSg6Ml/yhjkI6CeKWFNv1PGljTQfBS4VuDxb3lbIhygmXhsZPg/6ObwhiEW
lcaX2Nmunb7W847pXC4TokWJcZ9atpQymgVH6wKeBa7nibyaqBXt6YdegpnAujju
35Bmpmm1lzccoaARpXNJvYiyRqW5nxFw93rDP4RNJ7aywjb56siPdz59WtNWiD0k
lenMhynzzxJkC80J5deVn2yt1SgcMjGlDpcv4uiB/6Z4bUD4BFmw4GpZXjpLwZOe
pf+Ykl/VfImDPnyk
=1kwh
-----END PGP SIGNATURE-----

P
P
Pierre Langlois wrote on 5 Jan 2022 11:47
(name . Chris Marusich)(address . cmmarusich@gmail.com)
871r1me9gx.fsf@gmx.com
Hi Chris,

Chris Marusich <cmmarusich@gmail.com> writes:

Toggle quote (23 lines)
> [[PGP Signed Part:Undecided]]
> Hi Aiko and Leo,
>
> Aiko Kyle <aikokyle@gmail.com> writes:
>
>> It would be great to get this upstreamed soon so I can start guix
>> pulling master. I think the guix commit and revision in
>> package-management.scm will also need to be bumped after applying this
>> fix.
>
> It shouldn't be necessary to update the guix commit and revision in
> package-management.scm. My understanding is that "guix pull" will
> install Guix at the specified commit; it does not use the guix package
> to decide which version to install. In other words, even if at the
> specified commit the "guix" package is defined to use an older version
> (I believe this is always the case, actually), it will not stop "guix
> pull" from installing Guix at the specified commit.
>
> If it's necessary to update the "guix" package, we can certainly do it.
> However, I don't recall that it's necessary for fixing "guix pull"
> problems like this. If you still believe it's necessary, can you help
> me to understand why it's necessary?

I believe we'll have to update the package as well. For example on
aarch64 I can do a `guix pull' just fine, however `guix system reconfigure'
fails because it builds the full guix package, including running the
tests.

You've mentioned that `guix pull' was not working for you on ppc64
though right? I wonder why, is this a difference between using Guix as
the OS as opposed to a package manager on top of another OS?

Thanks,
Pierre
-----BEGIN PGP SIGNATURE-----

iQFMBAEBCgA2FiEEctU9gYy29KFyWDdMqPyeRH9PfVQFAmHVeY4YHHBpZXJyZS5s
YW5nbG9pc0BnbXguY29tAAoJEKj8nkR/T31U9PoIAIv764y1vQxYlfwyuZkcyASU
oqangC1dBej4OMH1A9Kvwz3Xwhtm/lFZszEzufTJsv87OrrJOW2QJP2oZ6YhDqCo
zKhiLfcxVHaAU/9xf7iqrwI0PRtHxuYfQcuuIdxzEK+HH/WOCTr/p0Hr9whFYD7V
KM28b+YMeNWbFVCDy59JRlhNygGxUMqHjfoHTg/BDt9IDGPDUsEC0CSQOhkrLD/u
nTZaGMT7324V1wQ/HPZChRE4/p6bDphn0citSgbNVLl40wCDjM/zI6ObSEd1TxCv
4mTVhAduW4+L0xkvVVbk+Jy9ELcCqSsIzCIo9p27YTYP2jbTOcET1rQ3FOciekg=
=erVf
-----END PGP SIGNATURE-----

A
A
Aiko Kyle wrote on 5 Jan 2022 18:34
(name . Chris Marusich)(address . cmmarusich@gmail.com)
CAPWcbYEnvU=104vcba+-2o6yxpZVg8Q28u41YOyC3ko584zrFQ@mail.gmail.com
On Wed, Jan 5, 2022 at 2:58 AM Chris Marusich <cmmarusich@gmail.com> wrote:
Toggle quote (21 lines)
>
>
> > It would be great to get this upstreamed soon so I can start guix
> > pulling master. I think the guix commit and revision in
> > package-management.scm will also need to be bumped after applying this
> > fix.
>
> It shouldn't be necessary to update the guix commit and revision in
> package-management.scm. My understanding is that "guix pull" will
> install Guix at the specified commit; it does not use the guix package
> to decide which version to install. In other words, even if at the
> specified commit the "guix" package is defined to use an older version
> (I believe this is always the case, actually), it will not stop "guix
> pull" from installing Guix at the specified commit.
>
> If it's necessary to update the "guix" package, we can certainly do it.
> However, I don't recall that it's necessary for fixing "guix pull"
> problems like this. If you still believe it's necessary, can you help
> me to understand why it's necessary?
>

I actually encountered this issue not doing a "guix pull" but in doing
a "guix system reconfigure" after a guix pull. I don't really
understand why, but I think guix system reconfigure will continue to
fail until the "guix" package is updated. I may be totally incorrect
here though as I'm still new to this.
C
C
Chris Marusich wrote on 6 Jan 2022 08:28
87k0fd2uhj.fsf_-_@gmail.com
Hi Pierre and Aiko,

Pierre Langlois <pierre.langlois@gmx.com> writes:

Toggle quote (9 lines)
> I believe we'll have to update the package as well. For example on
> aarch64 I can do a `guix pull' just fine, however `guix system reconfigure'
> fails because it builds the full guix package, including running the
> tests.
>
> You've mentioned that `guix pull' was not working for you on ppc64
> though right? I wonder why, is this a difference between using Guix as
> the OS as opposed to a package manager on top of another OS?

Aiko Kyle <aikokyle@gmail.com> writes:

Toggle quote (6 lines)
> I actually encountered this issue not doing a "guix pull" but in doing
> a "guix system reconfigure" after a guix pull. I don't really
> understand why, but I think guix system reconfigure will continue to
> fail until the "guix" package is updated. I may be totally incorrect
> here though as I'm still new to this.

You're right. I was confused.

I incorrectly thought that Leo and Aiko were saying that they couldn't
run "guix pull". However, Leo's original message (on Thu, 30 Dec 2021)
explained that the problem occurred for him while building the "guix"
package, not while running "guix pull". In fact, I've just confirmed
that "guix pull" DOES work for me on powerpc64le-linux using commit
b9c5dff57ff961a16c8fc24843a4535ea817e732. I ran this command:

guix pull --cores=14 --commit=b9c5dff57ff961a16c8fc24843a4535ea817e732 --profile=/tmp/test-pull-b9c5dff57

I'm not sure why I was confused, but I apologize. The "guix pull"
command actually works fine on powerpc64le-linux. However, the "guix"
package fails to build, exactly as described in this bug report.

So, I agree: in addition to the patch, we do also need to update the
guix package. To that end, when I commit the patch to the master branch
in about 24 hours, I will also add two commits to update the "guix"
package twice, since the comment in the "guix" package (added in commit
c0a693dfec3e0c3361dab40f354966730dde4ef3) explains that it must be
updated twice:

;; If you are updating this package because it fails to build, you need to
;; actually update it *twice*, as the installer is pointing to the N-1 guix
;; package revision.

I'll let you know once I've done that.

--
Chris

-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmHWmigVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadj1kQAK65udTcg1igNnumjiU7XrqI4BqB
bWTlSYbReZx56bgjrapFEmA33kTLjbyMIU7v6rumscXv7skOREnEI0Hh0XzVPAfA
VeD6IQOTimQiZWcjQcUut+iNQmjiY36+bvr2xrePbe6ZSNaKtM/CvmWkXwF+hSS/
vRiXI+E4hWP/ur+cEzVR3h3hOHKgMCFM3YWoKV2aiuyufs8Bg76DTA3jA1J8dco0
bhW68EGtN2nsr7Wgba9ODnzcoAU2+Pa4gyDRZ2oYSduuZCH7tKSGhSSV++l18bNX
fos6RQyDkp/tHuQYM1JJ8xVPC4vFaj8kEyfmJFFAbeigxAK3BQ9IU8Ft+u6x/wcV
a3eX0rWwINhMQyeZu0CdtsVhowUFjOWK6jPhG+d8IZ3eWBjSMC3XNcSJXTbgfniZ
Fotbf6NS9vWwtU7quFjBw9n+RWPp+j/X0agRnna1GggPRzFLzySBo7gQgEY+KNVg
09K2lJm4SM92Bfc3bNQO0bDptvQeitcfVasNBqXAgFQ8V468ycff6ryHAXSxgZve
EMDGDYbC3twDoXVhe1knQAeeUiyoHmBrcseulzXk0q+dFze5JRxGaCfIWWtZ2hz+
TGr47sOxY5KHcxcelqzK362cK/3C88yAz6KoYH6lhE2bff0iBzO8DLQI9Xd1oHPt
tFFVbeT8TRCGemJH
=tcx6
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 6 Jan 2022 17:39
(name . Chris Marusich)(address . cmmarusich@gmail.com)
87a6g8es32.fsf@gnu.org
Hi,

Chris Marusich <cmmarusich@gmail.com> skribis:

Toggle quote (5 lines)
> I've attached a different patch that attempts to fix the issue without
> requiring callers of set-xorg-configuration to update their code. I
> believe this is more consistent with the intent of Ludo's original
> change in commit 49599fab564f203b8e92d32e9b28c99e99849bfb.

[...]

Toggle quote (12 lines)
> From 09091cc8495e0b4c302a58961e79ac8455ecd208 Mon Sep 17 00:00:00 2001
> From: Chris Marusich <cmmarusich@gmail.com>
> Date: Mon, 3 Jan 2022 14:59:35 -0800
> Subject: [PATCH] services: Consistently use SDDM rather than GDM on
> non-x86_64.
>
> This is a follow-up to 49599fab564f203b8e92d32e9b28c99e99849bfb. Notably, it
> also deprecates (gnu services sddm) and moves what was there into (gnu
> services xorg).
>
> Fixes: <https://issues.guix.gnu.org/52908>.

I’d rather not move things and fix the bug in the same commit. (I’m not
even convinced sddm needs to leave its own module, plus it would break
the API, which is not something to do lightly.)

[...]

Toggle quote (10 lines)
> (define* (set-xorg-configuration config
> #:optional
> (login-manager-service-type
> - gdm-service-type))
> + (let ((system (or (%current-target-system)
> + (%current-system))))
> + (if (string-prefix? "x86_64" system)
> + gdm-service-type
> + sddm-service-type))))

[...]

Toggle quote (15 lines)
> --- a/gnu/system/examples/vm-image.tmpl
> +++ b/gnu/system/examples/vm-image.tmpl
> @@ -107,12 +107,12 @@ root ALL=(ALL) ALL
> ;; Use the DHCP client service rather than NetworkManager.
> (service dhcp-client-service-type))
>
> - ;; Remove GDM, ModemManager, NetworkManager, and wpa-supplicant,
> - ;; which don't make sense in a VM.
> + ;; Remove some services that don't make sense in a VM.
> (remove (lambda (service)
> (let ((type (service-kind service)))
> (or (memq type
> (list gdm-service-type
> + sddm-service-type

These bits LGTM.

Thanks for fixing it!

And yes, we’ll need to update the ‘guix’ package once this fix is in.

Ludo’.
C
C
Chris Marusich wrote on 7 Jan 2022 05:32
87h7agmai0.fsf@gmail.com
Hi Ludo and Aiko,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (4 lines)
> I’d rather not move things and fix the bug in the same commit. (I’m not
> even convinced sddm needs to leave its own module, plus it would break
> the API, which is not something to do lightly.)

You're right! I was able to avoid moving the (gnu services sddm) module
by autoloading it from (gnu services xorg). I've committed the fix as
79260c8695cc5e3cd64f5b01e262369d5a67f141, along with two commits that
update the guix package.

Toggle quote (4 lines)
> Thanks for fixing it!
>
> And yes, we’ll need to update the ‘guix’ package once this fix is in.

Thank you for the review!

Aiko, can you confirm that after running "guix pull" the issue is
resolved on your end, too?

--
Chris

From 79260c8695cc5e3cd64f5b01e262369d5a67f141 Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Thu, 6 Jan 2022 18:43:47 -0800
Subject: [PATCH] services: Consistently use SDDM rather than GDM on
non-x86_64.

This is a follow-up to 49599fab564f203b8e92d32e9b28c99e99849bfb.


* gnu/services/xorg.scm (set-xorg-configuration)[login-manager-service-type]:
When the current system or target system begins with the string "x86_64", use
gdm-service-type as before; otherwise, use sddm-service-type.
* gnu/system/examples/vm-image.tmpl (services): Add sddm-service-type to the
list of service types to remove.
---
gnu/services/xorg.scm | 11 ++++++++++-
gnu/system/examples/vm-image.tmpl | 6 +++---
2 files changed, 13 insertions(+), 4 deletions(-)

Toggle diff (71 lines)
diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 82a7d25602..35f8dbc5f8 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -11,6 +11,7 @@
;;; Copyright © 2021 Brice Waegeneire <brice@waegenei.re>
;;; Copyright © 2021 Oleg Pykhalov <go.wigust@gmail.com>
;;; Copyright © 2021 Josselin Poiret <josselin.poiret@protonmail.ch>
+;;; Copyright © 2022 Chris Marusich <cmmarusich@gmail.com>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -28,6 +29,7 @@
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
(define-module (gnu services xorg)
+ #:autoload (gnu services sddm) (sddm-service-type)
#:use-module (gnu artwork)
#:use-module (gnu services)
#:use-module (gnu services shepherd)
@@ -1040,10 +1042,17 @@ the GNOME desktop environment.")
"Run the GNOME Desktop Manager (GDM), a program that allows
you to log in in a graphical session, whether or not you use GNOME."))))
+;; Since GDM depends on Rust (gdm -> gnome-shell -> gjs -> mozjs -> rust)
+;; and Rust is currently unavailable on non-x86_64 platforms, default to
+;; SDDM there (FIXME).
(define* (set-xorg-configuration config
#:optional
(login-manager-service-type
- gdm-service-type))
+ (let ((system (or (%current-target-system)
+ (%current-system))))
+ (if (string-prefix? "x86_64" system)
+ gdm-service-type
+ sddm-service-type))))
"Tell the log-in manager (of type @var{login-manager-service-type}) to use
@var{config}, an <xorg-configuration> record."
(simple-service 'set-xorg-configuration
diff --git a/gnu/system/examples/vm-image.tmpl b/gnu/system/examples/vm-image.tmpl
index a59d91587b..ccb0b045db 100644
--- a/gnu/system/examples/vm-image.tmpl
+++ b/gnu/system/examples/vm-image.tmpl
@@ -5,7 +5,7 @@
;;
(use-modules (gnu) (guix) (srfi srfi-1))
-(use-service-modules desktop mcron networking spice ssh xorg)
+(use-service-modules desktop mcron networking spice ssh xorg sddm)
(use-package-modules bootloaders certs fonts nvi
package-management wget xorg)
@@ -107,12 +107,12 @@ root ALL=(ALL) ALL
;; Use the DHCP client service rather than NetworkManager.
(service dhcp-client-service-type))
- ;; Remove GDM, ModemManager, NetworkManager, and wpa-supplicant,
- ;; which don't make sense in a VM.
+ ;; Remove some services that don't make sense in a VM.
(remove (lambda (service)
(let ((type (service-kind service)))
(or (memq type
(list gdm-service-type
+ sddm-service-type
wpa-supplicant-service-type
cups-pk-helper-service-type
network-manager-service-type

base-commit: c4240dfdb433239108edaf12acb5c51138f9dc74
--
2.30.2
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmHXwlcVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadtbcP/27B412ECGcUdkiRAXqRryzMWAkZ
5HudQMLXQsOrsi46hrshnNOrd5UL3WlEmAavhdc89BTa5OkzQUeNn50851qq8Bed
o4bxpNKCwIssLPtXNddCmLEGZEoKoF7v0IY8q9EvUpBe30VEmmeNOJULQRl8gNvr
C4J2/MC/3k3RK0I7hk0yshqcs0ESIyMTXSpzlijoIS5yPIkWIZ0j23OsHbOBOwEG
KddMQbZNKA1VX+Ezx+dH8mQic8KYkP63AJ8+m90+IsEhddqhtOXBHsgvcLb1Bmb1
rze2DZ43ZuAnQ2OpS2bMQ59NVrg74NZeE0m6H6AdARlet0WVkMdwOc9JNU9QCP3x
nxPE8Y9QNxl4w8L9kA38FznLumHAemcbxO0iQMIrWFLxU/2vb7hbQ3TFxDDiV7dX
OxQrFrNaToxxHOpW08K4aboPFnpsgC8rmbnWlC0O5+xIhMVqm7DIP2Abazu3L8GB
pg9X+f4/FnI4AXoT/8cjN6lAY32TV3RHp8aAeqJjT4Lfa5cOztRapSGXqzIRlZMg
r2jT8z6fNkhNQRsLmzPrlA0FRHjfGIK3WXYEaX1lPQ6ybRVQbrb7OAydMdRDD34L
DMpF+iKOBQ/UJrgKk+tnHdQJrA0HT1lYZjZPm43yXFaTQORu5T+EV4Q1KQixSAna
P0ETnAwNbepZC2aV
=+8/C
-----END PGP SIGNATURE-----

M
M
Maxime Devos wrote on 7 Jan 2022 11:48
(address . 52908@debbugs.gnu.org)
62475b29c2f3fa83891897e794f124e60fc04709.camel@telenet.be
Chris Marusich schreef op do 06-01-2022 om 20:32 [-0800]:
Toggle quote (3 lines)
> +                                    (if (string-prefix? "x86_64"
> system)

There's a target-x86-64? procedure in (guix utils) you could use here.

Greetings,
Maxime
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYdgadhccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7uNtAP9K00wJAumPa8j7H7OLC1T1JhRK
AsZyq8VuUE7rRF/69QD/fc7bzraEFsp+GNKQjgDciKfVAsEsNbSLd48CvWbMiQ8=
=wiW9
-----END PGP SIGNATURE-----


A
A
Aiko Kyle wrote on 8 Jan 2022 02:26
(name . Chris Marusich)(address . cmmarusich@gmail.com)
CAPWcbYFrFZZMWXuvBcwOvucm6XU8Cpxyfay0jvybA2H_m7wHDQ@mail.gmail.com
On Thu, Jan 6, 2022 at 9:32 PM Chris Marusich <cmmarusich@gmail.com> wrote:
Toggle quote (5 lines)
>
> Aiko, can you confirm that after running "guix pull" the issue is
> resolved on your end, too?
>

I can confirm that this test passes here. However guix system
reconfigure is still failing for me on aarch64 due to the test
'file-needed/recursive' in tests/gremlin.scm failing. There was an
email on guix-devel starting to look into this issue on aarch64 but I
haven't had the time to follow up.
L
L
Leo Famulari wrote on 8 Jan 2022 03:18
(name . Aiko Kyle)(address . aikokyle@gmail.com)
Ydj0f81HlGtruxFh@jasmine.lan
On Fri, Jan 07, 2022 at 06:26:13PM -0700, Aiko Kyle wrote:
Toggle quote (2 lines)
> I can confirm that this test passes here.

Awesome, I am closing this bug. Thanks everybody, for collaborating on a
quick fix!

Toggle quote (6 lines)
> However guix system
> reconfigure is still failing for me on aarch64 due to the test
> 'file-needed/recursive' in tests/gremlin.scm failing. There was an
> email on guix-devel starting to look into this issue on aarch64 but I
> haven't had the time to follow up.

I think there is a fix being discussed here:

Closed
C
C
Chris Marusich wrote on 9 Jan 2022 03:40
Re: bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
(address . control@debbugs.gnu.org)
87wnj9d435.fsf@gmail.com
# Although at first it did seem like 52908 was the sole cause of this
# bug, Aiko reported in 52908 that there are still more problems needing
# resolution. So, this should be regarded as a separate bug, after all.

unmerge 52943
reopen 52943

--
Chris

C
C
Chris Marusich wrote on 9 Jan 2022 05:42
Re: bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
(address . 52908@debbugs.gnu.org)
87mtk5cyf8.fsf@gmail.com
Hi Maxime, Aiko, and Leo,

Maxime Devos <maximedevos@telenet.be> writes:

Toggle quote (9 lines)
> Chris Marusich schreef op do 06-01-2022 om 20:32 [-0800]:
>> +                                    (if (string-prefix? "x86_64"
>> system)
>
> There's a target-x86-64? procedure in (guix utils) you could use here.
>
> Greetings,
> Maxime

Good call! I implemented your suggestion in commit dc2b901.

Aiko Kyle <aikokyle@gmail.com> writes:

Toggle quote (12 lines)
> On Thu, Jan 6, 2022 at 9:32 PM Chris Marusich <cmmarusich@gmail.com> wrote:
>>
>> Aiko, can you confirm that after running "guix pull" the issue is
>> resolved on your end, too?
>>
>
> I can confirm that this test passes here. However guix system
> reconfigure is still failing for me on aarch64 due to the test
> 'file-needed/recursive' in tests/gremlin.scm failing. There was an
> email on guix-devel starting to look into this issue on aarch64 but I
> haven't had the time to follow up.

Thank you for confirming!

Leo Famulari <leo@famulari.name> writes:

Toggle quote (16 lines)
> On Fri, Jan 07, 2022 at 06:26:13PM -0700, Aiko Kyle wrote:
> > I can confirm that this test passes here.
>
> Awesome, I am closing this bug. Thanks everybody, for collaborating on a
> quick fix!
>
> > However guix system
> > reconfigure is still failing for me on aarch64 due to the test
> > 'file-needed/recursive' in tests/gremlin.scm failing. There was an
> > email on guix-devel starting to look into this issue on aarch64 but I
> > haven't had the time to follow up.
>
> I think there is a fix being discussed here:
>
> https://issues.guix.gnu.org/52940

I think the issue described in 52940 is similar but slightly different
to the one Aiko mentioned. I have resolved 52940 because that issue
(only happening on powerpc64le-linux, to my knowledge) has been fixed.
However, I have re-opened Aiko's existing report for the
aarch64-specific issue here:


Let's continue the discussion of that issue there.

--
Chris

-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmHaZ7sVHGNtbWFydXNp
Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadClQP/jYWHcEtX1gVY3rQ4vT0/KZtlL4q
RNb/cF4jKbOGJwJTNKLz2SaskTHA8Aj6sAkJUYX0vRYIm5CtMxpRXcGTnb9+JzqL
ziL1k+LXBuC5G/04WM/DGOVbJXm+lADmQyC+fpZ2GD/V9nOVme8D2aCiRglrS+Cf
nWiam+78vWTdHNtJa7Gj9zY3Fp9y5EE6rep0TOZ24ln8estfWL5mJ5w9FVMHOVhU
V3JMeuaeFlpWs7hqst3LWLBTLEk6qJctEwHIMEnhiCt8O+Co6L2s9BJt8zZQap1O
VaU7ZFljhZFTA698/5s679PzjC8EpwIy3Ng80cjaYZ+wnaqxwq+EeAvZN3EunsAh
fFltBB7K9D5rJn0LcmgiNajDHaWRGpffdTV7H1ZDjYSrd3mptLQ5cH+AAkZJEFTL
3IkQ4kL6HIk8MtevYcVNq3kdESXB3yVwr7mZWf3uE+RYd7R4QqtnpmlWz43akvsi
0WiLQFWGw3oJ6Eu5xp6wY2gDpVfKi9Nr7mFehkYaOVtGRrMHQ8MEHWajwUShNk3b
Nlm0GozgcMPrOfaqF2rCVXB/Xcp4Pwdl2yfvUVggflnMpbWV7HQTRoMXvmcEMZ7W
N27wPEgI4GcFvh0RurfeIIru3qlbp63NsjkZxAF1tBABeM+WFoqmW+DN99k38eJA
SOA3xPnRCch455jx
=smY0
-----END PGP SIGNATURE-----

?
Your comment

This issue is archived.

To comment on this conversation send an email to 52908@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 52908
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch