bug#70165: D-Bus system service breaks reconfiguration when /var/run/dbus is present + /run and /var/run are on separate file systems.

[Hilton Chain via Bug reports for GNU Guix]

On Fri, 05 Apr 2024 02:52:09 +0800,
Liliana Marie Prikler wrote:
>
> Am Donnerstag, dem 04.04.2024 um 00:36 +0800 schrieb Hilton Chain:
> > Hi,
> >
> > I have /var/run and /run on separate file systems, recently I noticed
> > system reconfiguration stopped with "guix system: error: rename-file:
> > Invalid cross-device link":
> >
> > --8<---cut here---start->8---
> > newfstatat(AT_FDCWD, "/run", {st_mode=S_IFDIR|0755, st_size=440,
> > ...}, AT_SYMLINK_NOFOLLOW) = 0
> > newfstatat(AT_FDCWD, "/run/dbus", {st_mode=S_IFDIR|0700, st_size=40,
> > ...}, AT_SYMLINK_NOFOLLOW) = 0
> > mkdir("/run", 0777) = -1 EEXIST (File exists)
> > mkdir("/run/dbus", 0777)    = -1 EEXIST (File exists)
> > chown("/run/dbus", 988, 983)    = 0
> > chmod("/run/dbus", 0755)    = 0
> > symlink("/run/dbus", "/var/run/dbus")   = -1 EEXIST (File exists)
> > readlink("/var/run/dbus", 0x1634730, 100) = -1 EINVAL (Invalid
> > argument)
> > openat(AT_FDCWD, "/var/run/dbus",
> > O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 17
> > newfstatat(17, "", {st_mode=S_IFDIR|0755, st_size=80, ...},
> > AT_EMPTY_PATH) = 0
> > getdents64(17, 0x16dfe10 /* 4 entries */, 32768) = 112
> > rename("/var/run/dbus/system_bus_socket",
> > "/run/dbus/system_bus_socket") = -1 EXDEV (Invalid cross-device link)
> > close(13)   = 0
> > write(2, "\33[1m\33[0mguix system: error: rena"..., 67guix
> > system: error: rename-file: Invalid cross-device link
> > ) = 67
> > exit_group(1)   = ?
> > +++ exited with 1 +++
> > --8<---cut here---end--->8---
> >
> > It's because /var/run/dbus was used for dbus service before, and now
> > migration to /run/dbus is done with ‘rename-file’:
> >
> > --8<---cut here---start->8---
> > (rename-file (string-append "/var/run/dbus/" next)
> >  (string-append "/run/dbus/" next))
> > --8<---cut here---end--->8---
> >
> > I think the logic can be improved for this case, but not sure how at
> > the moment.
> > What do you think?
> Is there a *good* reason to have those be separate file systems? :D
> What does the FHS say?
>
> Anyhow, cross-fs symlinks and rename-file ought to work assuming that
> both file-systems are already mounted.  Is one of them not needed for
> boot?

Specifically, I'm using tmpfs for them:

--8<---cut here---start->8---
(file-system
  (type "tmpfs")
  (mount-point "/run")
  (device "tmpfs")
  (flags '(no-dev strict-atime))
  (options "mode=0755,nr_inodes=800k,size=20%")
  (needed-for-boot? #t)
  (check? #f))

(file-system
  (type "tmpfs")
  (mount-point "/var/run")
  (device "tmpfs")
  (flags '(no-suid no-dev strict-atime))
  (options "mode=0755,nr_inodes=800k,size=20%")
  (needed-for-boot? #t)
  (check? #f))
--8<---cut here---end--->8---


And here's a reproducer:

--8<---cut here---start->8---
test_dir="$(mktemp --directory)"

sudo mount --type tmpfs none "$test_dir"
touch "$test_dir/test"

guile -c "(rename-file \"$test_dir/test\" \"/tmp/test\")"

sudo umount "$test_dir"
rmdir "$test_dir"
--8<---cut here---end--->8---

--8<---cut here---start->8---
Backtrace:
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   5 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2  4 (call-with-prompt ("prompt") # …)
In ice-9/eval.scm:
619:8  3 (_ #(#(#)))
In ice-9/command-line.scm:
   185:19  2 (_ #)
In unknown file:
   1 (eval (rename-file "/tmp/tmp.9wyzRfQ28l/test" "/tmp/…") #)
   0 (rename-file "/tmp/tmp.9wyzRfQ28l/test" "/tmp/test")

ERROR: In procedure rename-file:
In procedure rename-file: Invalid cross-device link
--8<---cut here---end--->8---

bug#69401: /etc/guix/machines.scm symlink can be garbage collected

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> Some of the build nodes behind the Berlin build farm have a childhurd
> which can build packages.  Unfortunately, the symlink from
> /etc/guix/machines.scm to the generated file in the store to setup
> offloading has been garbage collected on several of the machines.

Indeed.  Here’s an example:

--8<---cut here---start->8---
root@hydra-guix-108 ~# guix gc -R $(readlink -f /run/current-system) |grep 
machines.scm
/gnu/store/xg26iis3ydik6zxqk24cyk7h9zli1d25-machines.scm
root@hydra-guix-108 ~# ls -l /etc/guix/machines.scm
lrwxrwxrwx 1 root root 56 Mar  7 11:53 /etc/guix/machines.scm -> 
/gnu/store/1171q4xhph07ll3mlzlg7igcwg3c98i1-machines.scm
root@hydra-guix-108 ~# stat -L /etc/guix/machines.scm
stat: cannot statx '/etc/guix/machines.scm': No such file or directory
--8<---cut here---end--->8---

Here /etc/guix/machines.scm points to a different ‘machines.scm’ than
the one that is current.  The old one was removed last week:

--8<---cut here---start->8---
root@hydra-guix-108 ~# zgrep 1171q4xhph07ll3mlzlg7igcwg3c98i1 
/var/log/mcron.log.1.gz 
2024-03-27 03:00:05 23100 guix gc -F 150G: [46%] deleting 
'/gnu/store/1171q4xhph07ll3mlzlg7igcwg3c98i1-machines.scm'
--8<---cut here---end--->8---

The /etc/guix/machines.scm link was created on the last deployment
though:

--8<---cut here---start->8---
root@hydra-guix-108 ~# ls -l /etc/guix/machines.scm
lrwxrwxrwx 1 root root 56 Mar  7 11:53 /etc/guix/machines.scm -> 
/gnu/store/1171q4xhph07ll3mlzlg7igcwg3c98i1-machines.scm
root@hydra-guix-108 ~# guix system describe
Generation 109  Mar 07 2024 11:53:30(current)
  file name: /var/guix/profiles/system-109-link
  canonical file name: /gnu/store/5m0sjf3x0pslipcbdxm9ml99h0lbh7c8-system
  label: GNU with Linux-Libre 6.6.18
  bootloader: grub-efi
  root device: label: "my-root"
  kernel: /gnu/store/jcr3d8yy531q4i6kgkfmb0r3ghw418mc-linux-libre-6.6.18/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  commit: 64d269b983b76553466ac93945d58c7865cf190e
  configuration file: 
/gnu/store/d4z76lw515padizhl62hydxwygh57p6k-configuration.scm
--8<---cut here---end--->8---

Could it be that the “wrong” activation snippet was run by ‘guix
deploy’?  Here we see the right one:

--8<---cut here---start->8---
root@hydra-guix-108 ~# grep machines.scm $(guix gc -R $(readlink -f 
/run/current-system) |grep activate-service)
/gnu/store/pgmb9swcx0pljhbw88mgd3zjagz5axvn-activate-service.scm:(eval-when 
(expand load eval) (let ((extensions (quote ())) (prepend (lambda (items lst) 
(let loop ((items items) (lst lst)) (if (null? items) lst (loop (cdr items) 
(cons (car items) (delete (car items) lst (set! %load-path (prepend 
(cons "/gnu/store/pj751v3199vmv6i6sf0szp185ryzcfdg-module-import" (map (lambda 
(extension) (string-append extension "/share/guile/site/" (effective-version))) 
extensions)) %load-path)) (set! %load-compiled-path (prepend (cons 
"/gnu/store/iqbchmbmhmi34bwgv4sm14li9m24dpnl-module-import-compiled" (map 
(lambda (extension) (string-append extension "/lib/guile/" (effective-version) 
"/site-ccache")) extensions)) %load-compiled-path(begin (unless (or #f 
(file-exists? "/etc/guix/signing-key.pub")) (system* 
"/gnu/store/59y43hrlffs8hg1584vg5074jsbfhwjy-guix-1.4.0-16.aeb4943/bin/guix" 
"archive" "--generate-key")) (begin (use-modules (guix build utils)) (define 
acl-file "/etc/guix/acl") (if (file-exists? acl-file) (if (and (symbolic-link? 
acl-file) (store-file-name? (readlink acl-file))) (delete-file acl-file) 
(rename-file acl-file (string-append acl-file ".bak"))) (mkdir-p (dirname 
acl-file))) (symlink "/gnu/store/np3babd2h4xh4x4dvm51k6rp3xbsrzyl-acl" 
acl-file)) (begin (use-modules (guix build utils)) (define machines-file 
"/etc/guix/machines.scm") (if (file-exists? machines-file) (if (and 
(symbolic-link? machines-file) (store-file-name? (readlink machines-file))) 
(delete-file machines-file) (rename-file machines-file (string-append 
machines-file ".bak"))) (mkdir-p (dirname machines-file))) (symlink 
"/gnu/store/xg26iis3ydik6zxqk24cyk7h9zli1d25-machines.scm" machines-file)))
--8<---cut here---end--->8---

To be continued…

Ludo’.

bug#54447: cuirass: missing derivation error

[Ludovic Courtès]

Hello!

News from the everlasting bug!

  cannot build missing derivation 
‘/gnu/store/dfgc46q3l8wlnymv49a1wjnxypin8p0y-plink-1.07.drv’

(From .)

Why was it missing this time?  /var/log/nginx/error.log:

--8<---cut here---start->8---
2024/04/04 17:15:03 [error] 98751#0: *152293778 upstream timed out (110: 
Connection timed out) while reading response header from upstream, client: 
141.80.167.169, server: ci.guix.gnu.org, request: "GET 
/dfgc46q3l8wlnymv49a1wjnxypin8p0y.narinfo HTTP/1.1", upstream: 
"http://127.0.0.1:3000/dfgc46q3l8wlnymv49a1wjnxypin8p0y.narinfo;, host: 
"141.80.167.131"
--8<---cut here---end--->8---

Oops!  (There are dozens of upstream timeouts logged on that minute.)

/var/log/guix-publish.log:

--8<---cut here---start->8---
2024-04-04 17:14:51 GET 
/nar/lzip/pz39bkq7pd1hgy5rwiynqa33gyjvpgs5-python-pygments-2.12.0
2024-04-04 17:14:51 GET /z2xxwwxswdd4b8c8iwmxhqnqbp5nwz09.narinfo
2024-04-04 17:14:51 GET /lgyck285bsxzwrnh3x5ix5dwzd3n3wga.narinfo
2024-04-04 17:14:51 GET 
/nar/zstd/jxkglr445f215m2faqz1i2lgmbans4rf-texlive-amsmath-66594-doc
2024-04-04 17:15:33 GET /qg5cxb869i42jn7x2dm6k5l41ikkz21w.narinfo
2024-04-04 17:15:33 GET 
/nar/zstd/i2hp3q2pfhsyl0al7z38am7cqpddi4qr-texlive-capt-of-66594-doc
2024-04-04 17:15:33 GET /hh0gdbljj3cjdnjbr88kfm21mhys5sy7.narinfo
2024-04-04 17:15:33 GET /dfgc46q3l8wlnymv49a1wjnxypin8p0y.narinfo
2024-04-04 17:15:33 GET /yj63wifalfr6sla42h7mkqg011qrl5d0.narinfo
2024-04-04 17:15:33 GET /h2s2g2adxbnd67g34mnjnpcr6p3nhr69.narinfo
2024-04-04 17:15:33 -> GET /h2s2g2adxbnd67g34mnjnpcr6p3nhr69.narinfo: 404
2024-04-04 17:15:33 GET 
/nar/lzip/6zxlrw15b9dsv73s7v5fqabl7iv5v5il-python-exceptiongroup-1.1.1
2024-04-04 17:15:33 GET 
/nar/zstd/pychjd114abscbqlzcr3s7myf1497vw2-julia-compilersupportlibraries-jll-0.4.0%2B1
--8<---cut here---end--->8---

‘guix publish’ replied, but 40s too late (nginx has
“proxy_connect_timeout 10s;” for .narinfo URLs¹).

Notice the 40s pause time between 17:14:51 and 17:15:33.  Stop-the-world
GC?  Unlikely, because ‘guix publish’ had been running for ~3h, so even
with a leak², it’s hard to believe GC could take this long.

Ludo’.

¹ 
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/berlin.scm#n103
² https://issues.guix.gnu.org/69596

bug#70165: D-Bus system service breaks reconfiguration when /var/run/dbus is present + /run and /var/run are on separate file systems.

[Liliana Marie Prikler]

Am Donnerstag, dem 04.04.2024 um 00:36 +0800 schrieb Hilton Chain:
> Hi,
> 
> I have /var/run and /run on separate file systems, recently I noticed
> system reconfiguration stopped with "guix system: error: rename-file:
> Invalid cross-device link":
> 
> --8<---cut here---start->8---
> newfstatat(AT_FDCWD, "/run", {st_mode=S_IFDIR|0755, st_size=440,
> ...}, AT_SYMLINK_NOFOLLOW) = 0
> newfstatat(AT_FDCWD, "/run/dbus", {st_mode=S_IFDIR|0700, st_size=40,
> ...}, AT_SYMLINK_NOFOLLOW) = 0
> mkdir("/run", 0777) = -1 EEXIST (File exists)
> mkdir("/run/dbus", 0777)    = -1 EEXIST (File exists)
> chown("/run/dbus", 988, 983)    = 0
> chmod("/run/dbus", 0755)    = 0
> symlink("/run/dbus", "/var/run/dbus")   = -1 EEXIST (File exists)
> readlink("/var/run/dbus", 0x1634730, 100) = -1 EINVAL (Invalid
> argument)
> openat(AT_FDCWD, "/var/run/dbus",
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 17
> newfstatat(17, "", {st_mode=S_IFDIR|0755, st_size=80, ...},
> AT_EMPTY_PATH) = 0
> getdents64(17, 0x16dfe10 /* 4 entries */, 32768) = 112
> rename("/var/run/dbus/system_bus_socket",
> "/run/dbus/system_bus_socket") = -1 EXDEV (Invalid cross-device link)
> close(13)   = 0
> write(2, "\33[1m\33[0mguix system: error: rena"..., 67guix
> system: error: rename-file: Invalid cross-device link
> ) = 67
> exit_group(1)   = ?
> +++ exited with 1 +++
> --8<---cut here---end--->8---
> 
> It's because /var/run/dbus was used for dbus service before, and now
> migration to /run/dbus is done with ‘rename-file’:
> 
> --8<---cut here---start->8---
> (rename-file (string-append "/var/run/dbus/" next)
>  (string-append "/run/dbus/" next))
> --8<---cut here---end--->8---
> 
> I think the logic can be improved for this case, but not sure how at
> the moment.
> What do you think?
Is there a *good* reason to have those be separate file systems? :D
What does the FHS say?

Anyhow, cross-fs symlinks and rename-file ought to work assuming that
both file-systems are already mounted.  Is one of them not needed for
boot?

Cheers

bug#70140: Missing ./doc/guix-cookbook.pt_BR.texi

[pelzflorian (Florian Pelz)]

Hello Rostislav.

I do not know how to address the issue properly or where to document it.
The Writing Documentation section is the wrong place, because everyone
has to bootstrap again, not only the one who is writing documentation;
if we put a notice somewhere, then it would be something like:

diff --git a/doc/contributing.texi b/doc/contributing.texi
index f5b01f42fd..2dd4be951f 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -194,24 +194,28 @@ After updating the repository, @command{make} might fail with an error
 similar to the following example:
 
 @example
 error: failed to load 'gnu/packages/linux.scm':
 ice-9/eval.scm:293:34: In procedure abi-check: #>: record ABI mismatch; recompilation needed
 @end example
 
 This means that one of the record types that Guix defines (in this
 example, the @code{origin} record) has changed, and all of guix needs
 to be recompiled to take that change into account.  To do so, run
 @command{make clean-go} followed by @command{make}.
 
+If after updating, @command{make} fails with another error message,
+you probably have to repeat all steps described here, starting with
+@command{./bootstrap}.
+
 @node Running Guix Before It Is Installed
 @section Running Guix Before It Is Installed
 
 In order to keep a sane working environment, you will find it useful to
 test the changes made in your local source tree checkout without
 actually installing them.  So that you can distinguish between your
 ``end-user'' hat and your ``motley'' costume.
 
 To that end, all the command-line tools can be used even if you have not
 run @code{make install}.  To do that, you first need to have an
 environment with all the dependencies available (@pxref{Building from
 Git}), and then simply prefix each command with @command{./pre-inst-env}

Would that be OK?

Regards,
Florian

bug#47506: [PATCH] gnu: fiano-fmap: turn off tests to build program.

[Sharlatan Hellseher]

Hi,

Closing this issue as resolved in .

--
Oleg


signature.asc
Description: PGP signature

bug#45172: fiano-fmap test failure

[Sharlatan Hellseher]

Hi,

Closing this issue as resolved in .

--
Oleg


signature.asc
Description: PGP signature

bug#70170: emacs-strait-el: build failure

[Nicolas Goaziou via Bug reports for GNU Guix]

Hello,

Christopher Howard  writes:

> Hello, after a recent guix pull, I am getting a failure when building
> emacs-straight-el.

Updating the package fixed it. Thanks for the report.

Regards,
-- 
Nicolas Goaziou

bug#70064: Error when loading r-sf and other spatial packages (gdal related)

[Javier Vaquero Martínez]

So I managed to solve this. It turns out that some environment variables 
where making this error to happen. Running in an isolated environment 
with `guix shell -C r r-sf -- r` solves the problem.



Regards

bug#70194: SDDM fails to start, black screen on 188d18fc47

[Richard Sent]

Hi Guix!

After upgrading Guix from c9cd16c630 to 188d18fc47, SDDM fails to start
and drops me onto a black screen. I heard from another user on IRC who
seemingly has the same issue, so I think there's a bug here and it's not
a "me" issue.

>From the log, it seems like it might something to do with sddm-helper
communicating with PAM. Normally a line like "[PAM] Conversation with 1
messages" is printed after "[PAM] Authenticating..."

My SDDM configuration:

--8<---cut here---start->8---
(service sddm-service-type
(sddm-configuration
 (theme "guix-simplyblack-sddm")
 (themes-directory (file-append guix-simplyblack-sddm-theme 
"/share/sddm/themes"
--8<---cut here---end--->8---

An sddm.log entry when it fails to start:

--8<---cut here---start->8---
[23:28:42.129] (II) DAEMON: Initializing...
[23:28:42.143] (II) DAEMON: Starting...
[23:28:42.144] (II) DAEMON: Logind interface found
[23:28:42.144] (II) DAEMON: Adding new display...
[23:28:42.146] (II) DAEMON: Loaded empty theme configuration
[23:28:42.146] (II) DAEMON: Xauthority path: "/var/run/sddm/xauth_TflZQy"
[23:28:42.147] (II) DAEMON: Using VT 7
[23:28:42.147] (II) DAEMON: Display server starting...
[23:28:42.147] (II) DAEMON: Writing cookie to "/var/run/sddm/xauth_TflZQy"
[23:28:42.147] (II) DAEMON: Running: 
/gnu/store/c6dkx87an4c9qjny6yakxss9zm60wk7p-startx -nolisten tcp -dpi 240 
-background none -seat seat0 vt7 -auth /var/run/sddm/xauth_TflZQy -noreset 
-displayfd 16
[23:28:42.719] (II) DAEMON: Setting default cursor
[23:28:42.728] (WW) DAEMON: Could not setup default cursor
[23:28:42.728] (II) DAEMON: Running display setup script  
"/gnu/store/6ansmr2w8q5kppw4vi5bg9cgmf5h36s8-sddm-0.20.0/share/sddm/scripts/Xsetup"
[23:28:42.732] (II) DAEMON: Display server started.
[23:28:42.732] (II) DAEMON: Socket server starting...
[23:28:42.732] (II) DAEMON: Socket server started.
[23:28:42.735] (II) DAEMON: Loading theme configuration from 
"/gnu/store/vvdgqz68b7hjysyxvx4jgrfs9n8l161a-guix-simplyblack-sddm-theme-0.1/share/sddm/themes/guix-simplyblack-sddm/theme.conf"
[23:28:42.735] (II) DAEMON: Greeter starting...
[23:28:42.746] (II) HELPER: [PAM] Starting...
[23:28:42.746] (II) HELPER: [PAM] Authenticating...
[23:28:42.746] (II) HELPER: [PAM] returning.
[23:28:42.794] (II) HELPER: Writing cookie to "/tmp/xauth_FEgdza"
[23:28:42.794] (II) HELPER: Starting X11 session: "" 
"/gnu/store/6ansmr2w8q5kppw4vi5bg9cgmf5h36s8-sddm-0.20.0/bin/sddm-greeter 
--socket /tmp/sddm-:0-lSqpNm --theme 
/gnu/store/vvdgqz68b7hjysyxvx4jgrfs9n8l161a-guix-simplyblack-sddm-theme-0.1/share/sddm/themes/guix-simplyblack-sddm"
[23:28:42.796] (II) DAEMON: Greeter session started successfully
[23:28:45.920] (II) DAEMON: Message received from greeter: Connect
[23:28:47.626] (II) HELPER: [PAM] Closing session
[23:28:47.628] (II) HELPER: [PAM] Ended.
[23:28:47.639] (WW) DAEMON: Auth: sddm-helper exited with 11
[23:28:47.639] (II) DAEMON: Greeter stopped. SDDM::Auth::HelperExitStatus(11)
--8<---cut here---end--->8---

An sddm.log entry when it successfully runs:

--8<---cut here---start->8---
[23:30:57.842] (II) DAEMON: Initializing...
[23:30:57.846] (II) DAEMON: Starting...
[23:30:57.846] (II) DAEMON: No session manager found
[23:30:57.846] (II) DAEMON: Adding new display...
[23:30:57.847] (II) DAEMON: Loaded empty theme configuration
[23:30:57.848] (II) DAEMON: Xauthority path: "/var/run/sddm/xauth_WsJLVn"
[23:30:57.848] (II) DAEMON: Using VT 7
[23:30:57.848] (II) DAEMON: Display server starting...
[23:30:57.848] (II) DAEMON: Writing cookie to "/var/run/sddm/xauth_WsJLVn"
[23:30:57.848] (II) DAEMON: Running: 
/gnu/store/ybrjbiwpbs440d784p2bmsk7apaybbhy-startx -nolisten tcp -dpi 240 
-background none -seat seat0 vt7 -auth /var/run/sddm/xauth_WsJLVn -noreset 
-displayfd 16
[23:30:58.429] (II) DAEMON: Setting default cursor
[23:30:58.439] (WW) DAEMON: Could not setup default cursor
[23:30:58.439] (II) DAEMON: Running display setup script  
"/gnu/store/n0msvb8vfd3q3f9349kpq8305c4mx67x-sddm-0.20.0/share/sddm/scripts/Xsetup"
[23:30:58.442] (II) DAEMON: Display server started.
[23:30:58.442] (II) DAEMON: Socket server starting...
[23:30:58.442] (II) DAEMON: Socket server started.
[23:30:58.445] (II) DAEMON: Loading theme configuration from 
"/gnu/store/vvdgqz68b7hjysyxvx4jgrfs9n8l161a-guix-simplyblack-sddm-theme-0.1/share/sddm/themes/guix-simplyblack-sddm/theme.conf"
[23:30:58.445] (II) DAEMON: Greeter starting...
[23:30:58.456] (II) HELPER: [PAM] Starting...
[23:30:58.456] (II) HELPER: [PAM] Authenticating...
[23:30:58.456] (II) HELPER: [PAM] returning.
[23:30:58.489] (II) HELPER: Writing cookie to "/tmp/xauth_PUcYpV"
[23:30:58.489] (II) HELPER: Starting X11 session: "" 
"/gnu/store/n0msvb8vfd3q3f9349kpq8305c4mx67x-sddm-0.20.0/bin/sddm-greeter 
--socket 

bug#70140: Missing ./doc/guix-cookbook.pt_BR.texi

[Rostislav Svoboda]

> So there is no solution, is there?

In short, you provided a detailed explanation why there's no automatic
solution for failing `make doc/guix.texi` when a new language is added
to the documentation. So far so good. I appreciate that.

However, this is exactly the kind of situation that is begging to be
documented somewhere, along with the instructions on how to get around
the problem. But no, what you're saying (and I'm paraphrasing here) is
"It's not worth it."

???

The whole point of your fa98837b1d commit was to update the
documentation. And now the documentation doesn't compile and you
effectively don't want to do anything about it, except explaining why.

Maybe we could add a small note to the "Writing Documentation"
chapter: "If the doc/guix.texi doesn't compile... well, we don't think
it's important enough to tell you what to do about it."

That would at least be an honest statement.

Cheers, Bost