bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
Attached is the output of guix system shepherd-graph gnu/system/examples/desktop.tmpl on commit 2a49ddb513 graph.dot Description: MS-Word document
bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
On Sat, Jan 1, 2022 at 9:51 PM Leo Famulari wrote: > > Thanks, and I've attached a graph of the same operating system > declaration from the same revision of Guix but for x86_64, along with > rendered images of both graphs. > > The graphs clearly show that xorg-server is provided in two places on > aarch64. The question is why? Thanks Leo for the help on IRC! What we seem to have figured out is that commit 49599fab56 is almost certainly the culprit. So the issue is that somehow using sddm-service-type in %desktop-services on aarch64 instead of gdm-service-type which is used an x86_64 after that commit results in xorg-server-service-type being included twice, likely though gdm-service-type still being included somewhere. set-xorg-configuration is a potential culprit, although so far I haven't' been able to make the test pass by modifying the call to set-xorg-configuration in desktop.tmpl to explicitly pass sddm-service-type.
bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
On Mon, Jan 3, 2022 at 7:15 PM Chris Marusich wrote: > > 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! > 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.
bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
On Mon, Jan 3, 2022 at 9:53 PM Chris Marusich wrote: > > > 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.
bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
On Wed, Jan 5, 2022 at 2:58 AM Chris Marusich wrote: > > > > 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.
bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
On Thu, Jan 6, 2022 at 9:32 PM Chris Marusich 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.
bug#36544: 'set-paths' should exclude 'source' from consideration
> To avoid this unexpected sensitivity on the source origin > method, I > suggest that we explicitly exclude 'source' from consideration > within > the 'set-paths' phase. What do you think? I agree. We should do that in the next ‘core-updates’. I recently ran into this bug myself and was surprised that there would be a difference between building from a tarball and a git checkout. It seems the fix should be fairly straight forward so are there any plans to implement it? Thanks, Aiko
