bug#52786: [aarch64] elogind 246.10 fails to start on ROCK64, breaking sway

[pelzflorian (Florian Pelz)]

On Tue, Dec 28, 2021 at 04:35:23PM +0100, pelzflorian (Florian Pelz) wrote:
> elogind commit 7db52c01ed07f543f8272ea9a726cb542e771595 is the first
> elogind version that does not launch, but it is too entangled to
> simply revert.  I will take another look tomorrow.

This was a dead end.  With 7db52c01ed07f543f8272ea9a726cb542e771595,
elogind did actually launch but shepherd did not recognize it.  The
attached patch was required, but it does not make a difference for
starting sway.  (Neither is it an alternative fix for
.)

Elogind’s entire v246-stable branch does not run sway anymore on
ROCK64.  I don’t think bisecting is a good way to find the cause.

The sway errors are:

00:00:00.013 [ERROR] [wlr] [libseat] [libseat/backend/seatd.c:78] Could not 
connect to socket /run/seatd.sock: No such file or directory
00:00:00.031 [ERROR] [wlr] [libseat] [libseat/backend/logind.c:267] Could not 
activate session: Action org.freedesktop.login1.chvt is not registered
00:00:00.031 [ERROR] [wlr] [libseat] [libseat/libseat.c:73] No backend was able 
to open a seat
00:00:00.031 [ERROR] [wlr] [backend/session/session.c:84] Unable to create 
seat: Function not implemented
00:00:00.031 [ERROR] [wlr] [backend/session/session.c:218] Failed to load 
session backend
00:00:00.031 [ERROR] [wlr] [backend/backend.c:353] Failed to start a DRM session
00:00:00.031 [ERROR] [sway/server.c:53] Unable to create backend

The first line seems harmless and is also printed on old elogind
before sway starts.

I will try to actually understand what is happening.

Regards,
Florian
From: Florian Pelz 
Date: Sat, 1 Jan 2022 12:17:14 +0100
Subject: [PATCH] TEST elogind: Watch PID file.

* gnu/services/desktop.scm (elogind-shepherd-service): Set #:pid-file.
---
 gnu/services/desktop.scm | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm
index c6761ca784..fc5617c046 100644
--- a/gnu/services/desktop.scm
+++ b/gnu/services/desktop.scm
@@ -13,6 +13,7 @@
 ;;; Copyright � 2020 Tobias Geerinckx-Rice 
 ;;; Copyright � 2020 Reza Alizadeh Majd 
 ;;; Copyright � 2021 Brice Waegeneire 
+;;; Copyright � 2022 Florian Pelz 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -731,7 +732,9 @@ (define (elogind-shepherd-service config)
#:environment-variables
(list (string-append "ELOGIND_CONF_FILE="
 #$(elogind-configuration-file
-   config)
+   config)))
+   ;; The PID path from elogind's package definition:
+   #:pid-file "/run/systemd/elogind.pid"))
  (stop #~(make-kill-destructor)
 
 (define elogind-service-type

base-commit: 87624540b486d710749ad00ef5aa427a9e5c1d0c
-- 
2.34.0

bug#52539: Fwd: Comments in /etc/passwd don't get updated

[Ludovic Courtès]

> I clarified this and ensures ‘chfn’ is actually usable in commit
> c76775263e56a10cc1b84d03a5827f42436afe40.

Oops, I hadn’t pushed; the right commit ID is
671e6a81804f264ddcdd6fe7579644404da079b8.

Ludo’.

bug#52585: lualatex: Unexpected non-option argument(s): lualatex.fmt

[Sergiu Ivanov]

Hello Thiago,

Thiago Jung Bauermann  [2021-12-31T05:06:52+0100]:
> Hello Sergiu, Hello Pāladhammika,
>
> Em terça-feira, 28 de dezembro de 2021, às 09:16:32 -03, Sergiu Ivanov 
> escreveu:
>> Hello,
>> 
>> I am chiming in to say that I have the same issue.  In my case this
>> doesn't seem related to https://issues.guix.gnu.org/51252 , because
>> I install the entire texlive package.
>
> I was able to reproduce the problem with the texlive package installed.
> Installing the package texlive-latex-luatex doesn’t help.

Great!

> I can work on this issue some days after the holidays.

Thank you, take your time!  Also, do tell me how I can help.

-
Sergiu

bug#52913: 0ad only builds fine with a specific version of mozjs

[Jesse Gibbons]

> What would be the best way to fix this?
>  - keep a mozjs-78.6 package around just for 0ad
>  - patch 0ad to fix the compatibility issues with mozjs 78.15
>  - use the mozjs version bundled in the 0ad sources
>
> WDYT?

Keeping mozjs-78.6 just for 0ad will probably make things harder later 
on because it's another package to maintain and users likely won't be 
able install 0ad and icecat/icedove in the same profile. I suppose users 
can always use `-P /path/to/0ad-profile` when installing or updating 0ad.


I'm thinking using the bundled mozjs is perhaps the best option, though 
it isn't particularly guixy, because I expect most users would want the 
0ad packaged by guix to be compatible with other 0ad builds in the wild. 
However, I think it would be useful to fix compatibility issues with 
mozjs 78.15 so interested contributors can tell upstream if guix's 
current minor version breaks the expected deterministic behaviors 
described in the error.


Another option would be to keep mozjs-78.6 for 0ad and patch it so 
interested users can test updated mozjs using 
`--with-input=mozjs=mozjs`. It isn't very difficult to modify a list of 
packages to use a specific mozjs in a manifest or home configuration, 
right? Though I guess interested contributors could always add the patch 
themselves just as easily...


Anyway, that's my two cents.

bug#52913: 0ad only builds fine with a specific version of mozjs

[Liliana Marie Prikler]

Am Samstag, dem 01.01.2022 um 12:14 -0700 schrieb Jesse Gibbons:
>  > What would be the best way to fix this?
>  >  - keep a mozjs-78.6 package around just for 0ad
>  >  - patch 0ad to fix the compatibility issues with mozjs 78.15
>  >  - use the mozjs version bundled in the 0ad sources
>  >
>  > WDYT?
> 
> Keeping mozjs-78.6 just for 0ad will probably make things harder later
> on because it's another package to maintain and users likely won't be
> able install 0ad and icecat/icedove in the same profile. I suppose
> users can always use `-P /path/to/0ad-profile` when installing or
> updating 0ad.
I don't think that would be a problem, since mozjs is a regular input.
There ought to be no propagation conflicts between the two.

> I'm thinking using the bundled mozjs is perhaps the best option, though
> it isn't particularly guixy, because I expect most users would want the
> 0ad packaged by guix to be compatible with other 0ad builds in the
> wild.
There is no benefit to using a bundled version over one packaged with
Guix.

> Another option would be to keep mozjs-78.6 for 0ad and patch it so 
> interested users can test updated mozjs using 
> `--with-input=mozjs=mozjs`. It isn't very difficult to modify a list of
> packages to use a specific mozjs in a manifest or home configuration,
> right? Though I guess interested contributors could always add the
> patch themselves just as easily...
Contributors would probably work on top of their local checkouts
anyway, so there's no concern here (other than increased store space
for another mozjs both locally for users and in CI).

@Guillaume: From what I can gather from the build error, it appears as
though the calling convention changed to require an additional
parameter.  I've tracked down the relevant commit [1] and bug [2].

Now obviously doing such a thing violates SemVer, so if rewriting 0ad
with this and other changes in mind is not an option, I think having a
hidden package for 0ad might be the lesser evil.

Cheers

[1]
https://searchfox.org/mozilla-central/commit/a3c605929b16303e8a52ae9d99d5fe6769e8bf09
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1681268

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

[Leo Famulari]

On Sat, Jan 01, 2022 at 04:54:51PM -0700, Aiko Kyle wrote:
> I'm new to guix so I'm really struggling to debug this strange issue.
> On the latest master I can run 'guix pull', and the latest guix seems
> to build just fine, however when I go to do 'guix system reconfigure',
> building guix fails the check phase. I've attached the log file. After
> some help on IRC, I understand that during 'guix system reconfigure'
> ends up building a previous version of itself via the "boot-stripping"
> process in gnu/packages/package-management.scm. I followed this linked
> list of commits backwards and found that commits prior to commit
> 224d437fb4 which updates this guix package definition to version 14
> which is commit 2a621f1 build just fine, however all the versions of
> that package afterwards fail at the same place during 'guix system
> reconfigure', in the check phase, with the same tests failing. At this
> point, I think I lack sufficient knowledge of guix to debug this issue
> further and it looks like cuirass is so backlogged on aarch64 that is
> still hasn't gotten to building these guix versions so I can't compare
> with it's build attempts. Any help would be greatly appreciated as I'd
> really like to be running the latest guix from master.

Thanks, this has already been reported as

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

[Aiko Kyle]

Attached is the output of guix system shepherd-graph
gnu/system/examples/desktop.tmpl on commit 2a49ddb513


graph.dot
Description: MS-Word document

bug#44382: Updating the guix package triggers a full Git clone of guix.git

[Maxim Cournoyer]

Hi Leo,

Leo Famulari  writes:

> On Sun, Nov 29, 2020 at 10:24:18PM -0500, Maxim Cournoyer wrote:
>> I had researched this before and the option the git server is missing is
>> uploadpack.allowAnySHA1InWant [0].  Unfortunately last I check in
>> #savannah their machine (vcs0) is using an older Trisquel stuck with git
>> v2.11.0, one patch version before when the above feature was introduced
>> (v2.11.1)!  If I understood correctly, they have a new VM vcs2 but it
>> needs to be completely setup before they can switch.
>
> Savannah is now using Git version 2.17.1. I wonder if we can have this
> option enabled now? I checked and the problem described by this bug
> still exists.

You'd want to check in #savannah, I think.  It'd help reduce bandwidth
and hasten 'guix pull' a bit if it were now possible, I think.

Thanks!

Maxim

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

[Aiko Kyle]

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.