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

[pelzflorian (Florian Pelz)]

Pushed as 74517806f80dab17474a3c5f0b91d437e4d4e052.

I picked up some of your rewording and have changed the wording slightly
to mention Automake, to make it more likely to be picked up by search
engines when given the error.

Thank you for being insistent.

Regards,
Florian

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#70140: Missing ./doc/guix-cookbook.pt_BR.texi

[pelzflorian (Florian Pelz)]

My apologies for not giving a good response.

Yes, the issue you mention is indeed different from a record ABI
mismatch, in that the error message for an ABI message says
“recompilation needed” and is documented in the manual, unlike the
problematic error message that you reported.

Adding a note to doc/guix.texi would target the wrong audience, though,
because every Guix developer needs to rerun ./bootstrap, not only the
developer who added the translation.

The error message you reported

automake-1.16: error: cannot open < ./doc/guix-cookbook.pt_BR.texi: No
such file or directory

can be traced with “make --trace”.  It is because the
Autotools-generated Makefile recognizes that doc/local.mk has changed
and therefore runs “automake-1.16 --gnu Makefile”, which scans for the
Texinfo files mentioned in info_TEXINFOS and cannot open the mentioned
file.

Currrently the file “bootstrap” is a script that creates
“doc/guix.${lang}.texi” stub files.  When you don’t run “bootstrap”, the
files are missing.

At first sight, instead of creating the stub files in “bootstrap”, files
with

@setfilename guix.pt_BR.info
@include version-pt_BR.texi

for all languages could be pushed to guix.git by the developer who adds
the translation.  However, this is not enough, because “bootstrap” still
must run “touch po/doc/guix-manual.eo.po”, otherwise the PO4A rule to
create “doc/version-pt_BR.texi” is not run by GNU Make.

So there is no solution, is there?

Regards,
Florian

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

[pelzflorian (Florian Pelz)]

Hello Rostislav,

This advice would not be read by most affected Guix developers.  The
problem is that every guix developer must rerun ./bootstrap and
./configure on pulling certain changes like ABI breaks (when a new
record is added) and new cookbook versions.

Every Guix developer making a breaking change could put a notice
somewhere where it can be displayed from a pull hook, if that is
possible, but I don’t think developers would remember or that it is
worth the notification, also many would not read it.

Regards,
Florian

bug#69755: Issue trying to guix pull

[pelzflorian (Florian Pelz)]

Michael Ford  writes:
> It looks like rolling-back has resolved the problem now.
> So this issue can be closed.

Closing.  Thank you!

Regards,
Florian

bug#69755: Issue trying to guix pull

[pelzflorian (Florian Pelz)]

Sorry, I forgot, you might need to roll back first, if you had pulled
the broken in-between Guix revision.

guix pull --roll-back

I believe the in-between Guixes cannot be fixed.
Thank you for reporting.

Regards,
Florian

bug#69755: Issue trying to guix pull

[pelzflorian (Florian Pelz)]

Hello Michael.

Michael Ford  writes:
> building 
> /gnu/store/p9nimij8lz4yln5jd3gm0kdhirrwz56h-guix-1.4.0-18.4c94b9e-checkout.drv...
> -suspicious ownership or permission on
> `/gnu/store/bj2rp8ql9zxnv4l9gvlhph55fa241mk4-guix-1.4.0-18.4c94b9e-checkout';
> rejecting this build output
> Backtrace:

A probable fix was pushed by Ludovic recently.
Does it work?  Can this issue be closed?

commit ff1251de0bc327ec478fc66a562430fbf35aef42
Author: Ludovic Courtès 
Date:   Tue Mar 12 11:53:35 2024 +0100

daemon: Address shortcoming in previous security fix for CVE-2024-27297.

This is a followup to 8f4ffb3fae133bb21d7991e97c2f19a7108b1143.

Commit 8f4ffb3fae133bb21d7991e97c2f19a7108b1143 fell short in two
ways: (1) it didn’t have any effet for fixed-output derivations
performed in a chroot, which is the case for all of them except those
using “builtin:download” and “builtin:git-download”, and (2) it did not
preserve ownership when copying, leading to “suspicious ownership or
permission […] rejecting this build output” errors.

Regards,
Florian

bug#69123: Guix manual returns a 404 when trying to download FiraSans-Regular.ttf

[pelzflorian (Florian Pelz)]

Pushed as b7ccc5cb1b4ec936c00dbd98376c5d2677e60a63.

The text in the manual should be less wide now.

Regards,
Florian

bug#47714: Cutting the internet in guix installation will stop the installation permanently (irreversible)

[pelzflorian (Florian Pelz)]

close 47714
thanks

Closing, as this likely is not Guix’ bug but a hard-to-fix kernel bug
for your hardware.  (Kernel developers possibly could make it so the
screen does not get stuck.)  Feel free to reopen if this bug still
occurs with the current Guix release and only affects the installer:

"pelzflorian (Florian Pelz)"  writes:
> Does the same issue affect installing software with Guix on an already
> installed system?  If it only affects the installer, there might be a
> valid issue with Guix’ cow-store service.

Regards,
Florian

bug#47714: Cutting the internet in guix installation will stop the installation permanently (irreversible)

[pelzflorian (Florian Pelz)]

bo0od  writes:
> Hi There,
>
> Try install guix with manual installation while its on the end step
> (downloading things which mentioned in config.csm) cut the internet
> off, It will not reback you to the terminal so that you can
> repeat/relaunch the installation/downloading from where it stopped but
> rather will give you stuck/freeze screen.
>
> ThX!

I would like to close this bug.

Does the same issue affect installing software with Guix on an already
installed system?  If it only affects the installer, there might be a
valid issue with Guix’ cow-store service.

Otherwise, I guess this is not a Guix bug.  Stuck/freeze during manual
installation sounds like a kernel bug or like not properly mounting the
file systems.  Some unrelated Ethernet issues (with getting curlftpfs to
start automatically) disappear for my machine when installing non-free
Realtek firmware, which is not a solution, but this is likely not a Guix
bug but an issue with the linux-libre kernel.

Will close in two weeks.

Regards,
Florian

bug#67038: Inconsistent use of space before ellipsis

[pelzflorian (Florian Pelz)]

Simon Tournier  writes:
> For consistency, I suggest the rule: ’word...’ and not ’word ...’
>
> Something like the patch attached.

+1

This is more consistent.  Looking at the translation files in po/guix,
only guix/status.scm:568 uses the space before ellipsis.  The message
"applying ~a graft" does not occur in the manual, so it does not need
changing.

(match event
  […]
  (('download-started item uri _ ...)
   (when print-urls?
 (erase-current-line*)
 (format port (info (G_ "downloading from ~a ...")) uri)
 (newline port)))

Should we keep this space?  Perhaps keep it; it is clearer where the
URI ends.

Regards,
Florian

bug#65572: [PATCH v3] doc: Describe black screen issue when booting the installer.

[pelzflorian (Florian Pelz)]

Pushed as 2890114a708e3a54a14ceb762f0726b013ffdc85.

Csepp  writes:
> There was a thread about having a dedicated "safe video" option in the
> GRUB menu, like a lot of distros do.  I still think we should do that

Yes, I agree.  It would need a way to make a custom GRUB menu entry that
refers to a Guix System generation, and adding that feature is
complicated because it best worked for other non-GRUB bootloaders too.
If it were added, “safe video” could be described in the same place.

Regards,
Florian

bug#65572: Black screen in installer

[pelzflorian (Florian Pelz)]

Hi Iku-Tulo, one more thing, could you confirm that `nomodeset` alone
without video=uvesafb really is not enough?

Regards,
Florian

bug#65572: Black screen in installer

[pelzflorian (Florian Pelz)]

Hello Iku-Tulo, thank you for the report.

Vilutar  writes:
> intelfb: Version 0.9.6
> intelfb: Cannot reserve FB region

An unlikely guess: I have had problems with a black screen when using a
television as a screen.  However this does not sound like it.

> Then I tried `nomodeset video=uvesafb` Linux parameters and the GUI
> now rendered. I don't know if these work as a global workaround for
> other machines,

No, there have been reports that uvesafb does not work on every machine.

> should they be documented in the installation
> instructions?

Yes, if we can give proper instructions.  Perhaps the attached patch?

Regards,
Florian

From: Florian Pelz 
Date: Thu, 31 Aug 2023 12:44:55 +0200
Subject: [PATCH] doc: Describe black screen issue when booting the installer.

With suggestions by Iku-Tulo Vilutar .
Fixes .

* doc/guix.texi (System Installation): Add suggestion when
booting the installer fails with a black screen.
---
 doc/guix.texi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 04e5875925..5aeed7851d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2402,6 +2402,16 @@ BIOS or UEFI boot menu, where you can choose to boot from the USB stick.
 In order to boot from Libreboot, switch to the command mode by pressing
 the @kbd{c} key and type @command{search_grub usb}.
 
+Sadly, on some machines, the installation medium cannot be properly
+booted and you only see a black screen after booting.  This may
+indicate that your machine cannot run Guix System; perhaps you instead
+want to install Guix on a foreign distro (@pxref{Binary
+Installation}).  If you are adventurous, a possible workaround is
+pressing the @kbd{e} key in the GRUB boot menu and appending
+@option{nomodeset video=uvesafb} to the Linux bootline.  Sometimes the
+black screen issue can also be resolved by connecting a different
+display.
+
 @xref{Installing Guix in a VM}, if, instead, you would like to install
 Guix System in a virtual machine (VM).
 

base-commit: 299d0463d54c97b237deb2fe9e464108544344c0
-- 
2.41.0

bug#64881: [translation] M-x texinfo-all-menus-update breaks translated cookbook

[pelzflorian (Florian Pelz)]

Maxim Cournoyer  writes:
> M-x texinfo-update-all-menus is available out-of-the-box in Emacs, when
> visiting a .texi file (you invoke it via Alt-x texinfo-update-all-menus
> or by visiting the 'Texinfo -> Update All Menus' menu).

Oops my bad.  I should have expected that Emacs commands are invisible
unless the right Emacs mode is used.  Thank you for clarifying and
presenting as a patch.

Josselin Poiret  writes:
> `make as-derivation` uses #:select? git? to restrict to only files
> that are checked out in git.  It doesn't try to get the contents of HEAD
> though, the working directory's state is used instead.

Oh hmm doc/guix-cookbook.de.texi is not checked in, so even `make
as-derivation` should have worked ...

This got nothing to do with stray .de.texi files.  Apparently it is
because the menu entries lack menu descriptions (which should be
optional according to `info texinfo').

The attached patch on top of your patch helps ...

Either we add optional descriptions everywhere or not update menu
entries without description or change how po4a translates the menu
entries in po4a source file lib/Locale/Po4a/Texinfo.pm in
translate_buffer_menuentry, to make po4a translate when there is no
description.  I don’t plan to do that though.

Regards,
Florian
From: Florian Pelz 
Date: Thu, 27 Jul 2023 20:12:15 +0200
Subject: [PATCH] doc: guix-cookbook: Also add Texinfo menu description
 dummies.

* doc/guix-cookbook.texi: Add dummy menu descriptions to Texinfo menus.
---
 doc/guix-cookbook.texi | 100 -
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/doc/guix-cookbook.texi b/doc/guix-cookbook.texi
index 5698614c00..2697331412 100644
--- a/doc/guix-cookbook.texi
+++ b/doc/guix-cookbook.texi
@@ -89,7 +89,7 @@ Top
 
 Scheme tutorials
 
-* A Scheme Crash Course::
+* A Scheme Crash Course::a.
 
 Packaging
 
@@ -97,26 +97,26 @@ Top
 
 Packaging Tutorial
 
-* A ``Hello World'' package::
-* Setup::
-* Extended example::
-* Other build systems::
-* Programmable and automated package definition::
-* Getting help::
-* Conclusion::
-* References::
+* A ``Hello World'' package::  b.
+* Setup::  c.
+* Extended example::  d.
+* Other build systems::  e.
+* Programmable and automated package definition::  f.
+* Getting help::  g.
+* Conclusion::  h.
+* References::  i.
 
 Setup
 
-* Local file::
-* Channels::
-* Direct checkout hacking::
+* Local file::  j.
+* Channels::  k.
+* Direct checkout hacking::  l.
 
 Programmable and automated package definition
 
-* Recursive importers::
-* Automatic update::
-* Inheritance::
+* Recursive importers::  m.
+* Automatic update::  n.
+* Inheritance::  o.
 
 System Configuration
 
@@ -134,12 +134,12 @@ Top
 
 Customizing a Window Manager
 
-* StumpWM::
-* Session lock::
+* StumpWM::  p.
+* Session lock::  q.
 
 Session lock
 
-* Xorg::
+* Xorg::  r.
 
 Containers
 
@@ -148,8 +148,8 @@ Top
 
 Guix System Containers
 
-* A Database Container::
-* Container Networking::
+* A Database Container::  s.
+* Container Networking::  t.
 
 Advanced package management
 
@@ -157,11 +157,11 @@ Top
 
 Guix Profiles in Practice
 
-* Basic setup with manifests::
-* Required packages::
-* Default profile::
-* The benefits of manifests::
-* Reproducible profiles::
+* Basic setup with manifests::  u.
+* Required packages::  v.
+* Default profile::  w.
+* The benefits of manifests::  x.
+* Reproducible profiles::  y.
 
 Environment management
 
@@ -194,7 +194,7 @@ Scheme tutorials
 Let's get started!
 
 @menu
-* A Scheme Crash Course::
+* A Scheme Crash Course::  z.
 @end menu
 
 @node A Scheme Crash Course
@@ -492,14 +492,14 @@ Packaging Tutorial
 basic programming knowledge.
 
 @menu
-* A ``Hello World'' package::
-* Setup::
-* Extended example::
-* Other build systems::
-* Programmable and automated package definition::
-* Getting help::
-* Conclusion::
-* References::
+* A ``Hello World'' package::  aa.
+* Setup::  ab.
+* Extended example::  ac.
+* Other build systems::  ad.
+* Programmable and automated package definition::  ae.
+* Getting help::  af.
+* Conclusion::  ag.
+* References::  ah.
 @end menu
 
 @node A ``Hello World'' package
@@ -708,9 +708,9 @@ Setup
 But first, let's look at other possibilities.
 
 @menu
-* Local file::
-* Channels::
-* Direct checkout hacking::
+* Local file::  ai.
+* Channels::  aj.
+* Direct checkout hacking::  ak.
 @end menu
 
 @node Local file
@@ -1364,9 +1364,9 @@ Programmable and automated package definition
 Let's illustrate this with some awesome features of Guix!
 
 @menu
-* Recursive importers::
-* Automatic update::
-* Inheritance::
+* Recursive importers::  al.
+* Automatic update::  am.
+* Inheritance::  an.
 @end menu
 
 @node Recursive importers
@@ -2180,8 +2180,8 @@ Customizing a Window Manager
 @cindex wm
 
 @menu
-* StumpWM::
-* Session lock::
+* StumpWM::  ao.
+* Session lock::  ap.
 @end menu
 
 @node StumpWM
@@ -2240,7 +2240,7 @@ Session lock
 StumpWM or EXWM, you might have to set it up 

bug#64881: [translation] M-x texinfo-all-menus-update breaks translated cookbook

[pelzflorian (Florian Pelz)]

Hello Maxim,

I never used M-x texinfo-all-menus-update before and do not know which
package or output provides it.

As I understand, presumably the PO4A / POXREF step of make was
interrupted and therefore there are half-complete stray .de.texi files.
Otherwise, the references would be translated or the .de.texi files
would not exist.

Maxim Cournoyer  writes:
> variants do not, which breaks 'make as-derivation' (or 'guix pull').

IIUC 'make as-derivation' uses the files from the guix directory, but
'guix pull' uses the files from a repo checkout and was not / cannot be
broken by stray files.

Regards,
Florian

bug#63921: Activation snippets in reverse order, prevent boot

[pelzflorian (Florian Pelz)]

David Wilson has described a way to fix this bug in Guix


Regards,
Florian

bug#64006: Installation frustration weekend

[pelzflorian (Florian Pelz)]

Denys Nykula  writes:
> but I still look at
> it as a bug,

Then it is a bug.  Please go ahead and open a separate bug when you have
time or preferably a patch when you have a fix.  However, the console
default font in gnu/services/base.scm is universal for all locales and
really should keep supporting progress bars instead of Greek and
Cyrillic and Arabic script.  Possibly however the modify-services form
you mention should be added to the services field by the installer for
Ukrainian etc. just like the keyboard-layout is added to the config
automatically.

Regards,
Florian

bug#64006: Installation frustration weekend

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
>> Console fonts lose Cyrillic support after the first pull and upgrade.
>> Question marks appear in place of my letters instead.
> This sounds like a bug/regression; in the source code
> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.scm>,
> it looks like it should work, because it uses GNU Unifont,

What was I thinking.  Console without kmscon cannot support a complete
font.  It’s just that the default changed from supporting Cyrillic to
supporting progress bars:

commit 01334a61c7541d8ae29c5252e2e5b3ed7a59c552
Author: Julien Lepiller 
Date:   Fri Feb 3 12:56:02 2023 +0100

gnu: Use unifont by default in TTYs.

It has even better language support than LatGrkCyr-8x16 and can show
fancy progress bars.

* gnu/services/base.scm (%default-console-font): Use unifont.

See: 
<https://git.savannah.gnu.org/cgit/guix.git/commit/?id=01334a61c7541d8ae29c5252e2e5b3ed7a59c552>

IMHO this new default is sensible.  This sub-issue is not a bug.  You
should use either kmscon or change the default.

Regards,
Florian

bug#64006: Installation frustration weekend

[pelzflorian (Florian Pelz)]

Hi Denys!  Sorry to hear, but thank you for writing which bugs still
cause trouble with Guix System.

I can say this:

Denys Nykula  writes:
> Installation with a desktop environment (EXWM) started to "die
> unexpectedly" every time when loading subtitutes, please see installer-
> dump-790b17b6.

Not being a maintainer, I have not looked at the dump, but as you
reported, apparently this will be fixed by making a new Guix release,
because the latest Guix has fixes for dealing with substitute server
errors.


> (Nice thing) Didn't find a netcat tool in the installer image to copy

You can use “guix install netcat” in the installer, probably, at least
it will work after running “herd start cow-store /mnt” as described for
manual installation in the manual.  Not a bug in my opinion.


> Nothing hints that to enter the encryption key when it asks it the
> second time during the boot, the user has to switch their keyboard
> layout.

Yes … this is a bug, but how to fix it; does Debian do better?


> Console fonts lose Cyrillic support after the first pull and upgrade.
> Question marks appear in place of my letters instead.

This sounds like a bug/regression; in the source code
,
it looks like it should work, because it uses GNU Unifont, but it does
not display Cyrillic for me either.  However, you could add kmscon to
your operating system config’s services field to make console fonts work
for all languages, for example like this

(services
 (cons* (service kmscon-service-type)
…
%desktop-services))


> (Probably impossible to fix by design, but worth mentioning) Pulling
> and downloading substitutes wastes hours of time and traffic, without
> estimates and with the warning split into many small messages without a
> total sum. Also seems like it happens from scratch after the boot,
> despite the installer having already pulled so much from the Internet.

Yes, I think double downloads cannot be fixed, because the installer is
tested to provide a first working version (except download errors …),
but it will always be outdated.

But why there are duplicate substitute messages in the console, I do not
know.  Is it a bug?


> …
> Nothing hints that the combination for layout switching is now
> Shift+Alt, not Alt+Shift.

Both have the same effect for me.  Shift+Alt and Alt+Shift both work for
me.  Strange.  What happens when you change the combination in your
operating system config’s keyboard layout settings and reconfigure?



> Video (Intel HD Graphics 400) freezes after gdm shows the mouse, so I
> can't use the environment or switch to a console to get a debug log.

Did it work in Debian?  Did you use nonfree drivers before?

Regards,
Florian

bug#63977: Incorrect language tags in case of incomplete translations

[pelzflorian (Florian Pelz)]

Maxime Devos  writes:
> This French web page has an English blog post.  This is OK, HTML
> supports that.  Just put a "lang="en"' attribute in the 'article' tag

Done in c392a144df6c1e11ec5a672f7e2c00fbfc51f5bd.  Thank you for the
report!  I do not have a screen reader to test though.

Regards,
Florian

bug#63975: Broken link (404) in blog post breadcrumbs

[pelzflorian (Florian Pelz)]

Pushed as bf07f52a57505c4b12fa6b384b79751e387ae624 with some changes;
the change is effected in the post-url-path procedure now.

bug#63975: Broken link (404) in blog post breadcrumbs

[pelzflorian (Florian Pelz)]

Maxime Devos  writes:
> then click on the link ‘Parameterized Packages for GNU Guix’ in the
> breadcrumbs ‘Home -> Blog -> Parameterized Packages for GNU Guix’.
>
> This goes to
>
> https://guix.gnu.org/blog/2023/parameterized-packages-for-gnu-guix
>
> which is a 404 Not Found.

Thank you Maxime for spotting it!

The attached patch should fix it; I still need to test if it works
before pushing.

(Old blog posts still have a redirect from
https://guix.gnu.org/blog/2019/post-url-path to
https://guix.gnu.org/en/blog/2019/post-url-path in maintenance.git,
but we do not want to add a redirect for each new blog post.)

Regards,
Florian

From: Florian Pelz 
Date: Sat, 10 Jun 2023 13:26:55 +0200
Subject: [PATCH] website: blog: Refer to the localized URL in breadcrumbs.

Fixes .
Reported by Maxime Devos 

* website/apps/blog/templates/post.scm (post-t)[#:crumbs]: Append a
slash to the URL, so the guix-url procedure will treat it as a web
page and localize it.
---
 website/apps/blog/templates/post.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/website/apps/blog/templates/post.scm b/website/apps/blog/templates/post.scm
index 0d6b08e..aba6fb9 100644
--- a/website/apps/blog/templates/post.scm
+++ b/website/apps/blog/templates/post.scm
@@ -1,4 +1,5 @@
 ;;; GNU Guix web site
+;;; Copyright © 2023 Florian Pelz 
 ;;; Initially written by sirgazil who waives all
 ;;; copyright interest on this file.
 
@@ -34,7 +35,8 @@
  #:crumbs
  (list (crumb (C_ "website menu" "Blog") (guix-url "blog/"))
 	   (crumb (post-ref post 'title)
-		  (guix-url (post-url-path post
+  (guix-url (string-append (post-url-path post)
+   "/"
  #:content
  `(main
(article

base-commit: 0250b260c880aa43fcd0bd2655d924d4719082c4
-- 
2.40.1

bug#63921: Activation snippets in reverse order, prevent boot

[pelzflorian (Florian Pelz)]

Jelle is right, multiple (delete mingetty-service-type) is not useful.
With more thought, what I imagined as more explicit is probably more
like (delete "term-tty2") than (delete mingetty-service-type).  Also I
wouldn’t actually need it.

And as Brian says, just use filter.  modify-services need not do more
than what is already documented.

I would be happy if someone else would undo the change to “delete at
most once”.

Regards,
Florian

bug#63921: Activation snippets in reverse order, prevent boot

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> "pelzflorian (Florian Pelz)"  writes:
>> Using clauses at most once broke the greetd example in the manual:
> Jelle Licht already reported this on IRC, see the end of
> <http://logs.guix.gnu.org/guix/2023-06-06.log>

Cc Jelle Licht

bug#63921: Activation snippets in reverse order, prevent boot

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> Using clauses at most once broke the greetd example in the manual:

Jelle Licht already reported this on IRC, see the end of
<http://logs.guix.gnu.org/guix/2023-06-06.log>

Regards,
Florian

bug#63921: Activation snippets in reverse order, prevent boot

[pelzflorian (Florian Pelz)]

Hi Ludo, hi all.

Ludovic Courtès  writes:
> I ended up
> rewriting ‘modify-services’.  Good news is we now have tests for this.

In the rewrite, you wrote:
> +(define (apply-clauses clauses services)
> +  "Apply CLAUSES, an alist as returned by 'clause-alist', to SERVICES, a list
> +of services.  Use each clause at most once; raise an error if a clause was 
> not
> +used."

Using clauses at most once broke the greetd example in the manual:
> (append
>  (modify-services %base-services
>;; greetd-service-type provides "greetd" PAM service
>(delete login-service-type)
>;; and can be used in place of mingetty-service-type
>(delete mingetty-service-type))
>  (list
>   (service greetd-service-type

But there are multiple instances of mingetty-service-type in
%base-services.  Now an error is raised on reconfigure because there are
two term-tty2 services.

I’m not sure, isn’t it more explicit if we keep your change of deleting
at most once, but change the greetd example?

The following works for me now …

(modify-services %base-services
 (delete login-service-type)
 (delete mingetty-service-type)
 (delete mingetty-service-type)
 (delete mingetty-service-type)
 (delete mingetty-service-type)
 (delete mingetty-service-type)
 (delete mingetty-service-type))

Regards,
Florian

bug#58880: 'guix gc' does not round the amount of disk space freed

[pelzflorian (Florian Pelz)]

Pushed both patches now.  Sorry Remco it took so long.

To patch 1, I added a copyright line for you; even though you changed
little, maybe there still is copyright together with your other patches.
To patch 2, I added a period in the commit message and made the same po
file change also to the new po/guix/it.po file, which previously had an
invalid format string anyway.

Still for the future, IMHO editing PO files outside of Weblate is not
worth the effort.

Regards,
Florian

bug#63680: long lines in cookbook in German language

[pelzflorian (Florian Pelz)]

Gottfried  writes:
> "unreadable overlong lines is an issue with
> the PDF version of the cookbook in any language".
> "On first sight, it looks like complicated TeX tricks are needed to fix
> this.  I do not know."
> says Felix Lechner

It was me who wrote these sentences, Felix commented on something else.
 ;)

Thank you Gottfried for writing the issue.

Regards,
Florian

bug#63427: gdk-pixbuf unable to recognize image formats (JPG, PNG, etc.)

[pelzflorian (Florian Pelz)]

Hi Liliana and all.  Until now the user could decide what image loaders
to install alongside.  Or so I thought.  However, surprisingly I cannot
get any other loader except gdk-pixbuf and librsvg to work anyway.

That is,

guix shell viewnior webp-pixbuf-loader

surprisingly does not see webp files.  I do not understand.

If this changed patch looks fine, now with proper gexp use, I will push
it.  The patch continues to include gdk-pixbuf among the inputs even
though gtk+@2 propagates gdk-pixbuf anyway, but better be explicit.

Regards,
Florian
>From 6acc7322695a13c326918c4b83a999e324406b21 Mon Sep 17 00:00:00 2001
Message-Id: <6acc7322695a13c326918c4b83a999e324406b21.1684001649.git.pelzflor...@pelzflorian.de>
From: Florian Pelz 
Date: Sat, 13 May 2023 12:33:26 +0200
Subject: [PATCH] gnu: viewnior: Support image formats out of the box.

* gnu/packages/image-viewers.scm (viewnior)
[inputs]: Add 'librsvg-for-system'.
[arguments]: Enable 'glib-or-gtk?' to make available
GDK_PIXBUF_MODULE_FILE.  Wrap viewnior to use it instead
of the image loaders installed by the user.
---
 gnu/packages/image-viewers.scm | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/gnu/packages/image-viewers.scm b/gnu/packages/image-viewers.scm
index db7a44d4ff..798a8e50e8 100644
--- a/gnu/packages/image-viewers.scm
+++ b/gnu/packages/image-viewers.scm
@@ -27,6 +27,7 @@
 ;;; Copyright © 2022, 2023 Maxim Cournoyer 
 ;;; Copyright © 2022 Tomasz Jeneralczyk 
 ;;; Copyright © 2022 Cairn 
+;;; Copyright © 2023 Florian Pelz 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -425,13 +426,24 @@ (define-public viewnior
 (base32 "14qvx1wajncd5ab0207274cwk32f4ipfnlaci6phmah0cwra2did"
 (build-system meson-build-system)
 (arguments
- '(#:phases (modify-phases %standard-phases
-  (add-after 'unpack 'patch-source
-(lambda _
-  ;; Don't create 'icon-theme.cache'
-  (substitute* "meson.build"
-(("meson.add_install_script*") "")
-   #:tests? #f));no tests
+ (list #:glib-or-gtk? #t
+   #:phases
+   #~(modify-phases %standard-phases
+   (add-after 'unpack 'patch-source
+ (lambda _
+   ;; Don't create 'icon-theme.cache'
+   (substitute* "meson.build"
+ (("meson.add_install_script*") ""
+   (add-after 'glib-or-gtk-wrap 'wrap-pixbuf
+ (lambda* (#:key outputs #:allow-other-keys)
+   (let ((viewnior (string-append #$output "/bin/viewnior")))
+ (wrap-program viewnior
+   ;; Wrap GDK_PIXBUF_MODULE_FILE so viewnior can be used
+   ;; to view JPG, PNG and SVG, without the user needing
+   ;; to install gdk-pixbuf or librsvg.
+   `("GDK_PIXBUF_MODULE_FILE" =
+ (,(getenv "GDK_PIXBUF_MODULE_FILE"
+   #:tests? #f));no tests
 (native-inputs
  (list gettext-minimal
`(,glib "bin")   ;glib-genmarshal
@@ -440,7 +452,8 @@ (define-public viewnior
 (inputs
  (list exiv2
gdk-pixbuf
-   gtk+-2))
+   gtk+-2
+   (librsvg-for-system)))
 (home-page "https://siyanpanayotov.com/project/viewnior;)
 (synopsis "Simple, fast and elegant image viewer")
 (description "Viewnior is an image viewer program.  Created to be simple,

base-commit: e3e011a08141058598cc7631aeb52d620a3ccb8c
-- 
2.39.2

bug#63427: gdk-pixbuf unable to recognize image formats (JPG, PNG, etc.)

[pelzflorian (Florian Pelz)]

Nathan Dehnel  writes:
> Yes, that one works

That’s good.  This means maybe either

- if guix shell without --pure works too, you just have not run “guix
  upgrade” recently, or

- --pure helped and viewnior is not compatible with the Adwaita dark
theme, or

- --pure helped because you have misconfigured something that breaks the
  installed viewnior, but leaves the pure one intact.

What remains as a bug is wrapping the viewnior program inside
gdk-pixbuf, so installing gdk-pixbuf is not needed anymore.  Untested
patch is attached.

But then other image loaders installed by the user to support
e.g. libexif would not be usable anymore.  We could also add libexif,
but do we even want the attached patch?  Or should it be up to the user
to install image loaders?

Regards,
Florian

>From 29c76710eea6720aa4b5e774a83ce19e577937ac Mon Sep 17 00:00:00 2001
Message-Id: <29c76710eea6720aa4b5e774a83ce19e577937ac.1683974741.git.pelzflor...@pelzflorian.de>
From: Florian Pelz 
Date: Sat, 13 May 2023 12:33:26 +0200
Subject: [PATCH] gnu: viewnior: Support image formats out of the box.

* gnu/packages/image-viewers.scm (viewnior)
[inputs]: Add 'librsvg-for-system'.
[arguments]: Enable 'glib-or-gtk?' to make available
GDK_PIXBUF_MODULE_FILE.  Wrap viewnior to use it instead
of the image loaders installed by the user.
---
 gnu/packages/image-viewers.scm | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/image-viewers.scm b/gnu/packages/image-viewers.scm
index db7a44d4ff..bbe26aadbe 100644
--- a/gnu/packages/image-viewers.scm
+++ b/gnu/packages/image-viewers.scm
@@ -27,6 +27,7 @@
 ;;; Copyright © 2022, 2023 Maxim Cournoyer 
 ;;; Copyright © 2022 Tomasz Jeneralczyk 
 ;;; Copyright © 2022 Cairn 
+;;; Copyright © 2023 Florian Pelz 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -425,12 +426,22 @@ (define-public viewnior
 (base32 "14qvx1wajncd5ab0207274cwk32f4ipfnlaci6phmah0cwra2did"
 (build-system meson-build-system)
 (arguments
- '(#:phases (modify-phases %standard-phases
+ '(#:glib-or-gtk? #t
+   #:phases (modify-phases %standard-phases
   (add-after 'unpack 'patch-source
 (lambda _
   ;; Don't create 'icon-theme.cache'
   (substitute* "meson.build"
-(("meson.add_install_script*") "")
+(("meson.add_install_script*") ""
+  (add-after 'glib-or-gtk-wrap 'wrap-pixbuf
+(lambda* (#:key outputs #:allow-other-keys)
+  (let ((viewnior (string-append #$output "/bin/viewnior")))
+(wrap-program viewnior
+  ;; Wrap GDK_PIXBUF_MODULE_FILE so viewnior can be used
+  ;; to view JPG, PNG and SVG, without the user needing
+  ;; to install gdk-pixbuf or librsvg.
+  `("GDK_PIXBUF_MODULE_FILE" =
+(,(getenv "GDK_PIXBUF_MODULE_FILE"
#:tests? #f));no tests
 (native-inputs
  (list gettext-minimal
@@ -440,7 +451,8 @@ (define-public viewnior
 (inputs
  (list exiv2
gdk-pixbuf
-   gtk+-2))
+   gtk+-2
+   (librsvg-for-system)))
 (home-page "https://siyanpanayotov.com/project/viewnior;)
 (synopsis "Simple, fast and elegant image viewer")
 (description "Viewnior is an image viewer program.  Created to be simple,

base-commit: e3e011a08141058598cc7631aeb52d620a3ccb8c
-- 
2.39.2

bug#63427: gdk-pixbuf unable to recognize image formats (JPG, PNG, etc.)

[pelzflorian (Florian Pelz)]

Nathan, could you try running this command:

guix shell --pure viewnior gdk-pixbuf -- viewnior

For me this works now.  My guess is that for you, something else breaks
viewnior and --pure can help.

Regards,
Florian

bug#63427: gdk-pixbuf unable to recognize image formats (JPG, PNG, etc.)

[pelzflorian (Florian Pelz)]

Hi all.

Josselin Poiret via Bug reports for GNU Guix  writes:
> For
> that, we use the environment variable GDK_PIXBUF_MODULE_FILE, which is a
> search-path for the package gdk-pixbuf, meaning that it is set only if
> gdk-pixbuf is installed in your profile.  […] So
> we should fix this and propagate gdk-pixbuf everywhere (something which
> I'm not too much a fan of, but alas).

The cambalache package does the right thing by wrapping the program to
setenv GDK_PIXBUF_MODULE_FILE to the value it has while building the
package.  glib-or-gtk build system sets GDK_PIXBUF_MODULE_FILE while
building the package.  Note that gdkpixbuf and perhaps
librsvg-for-system must be in inputs.

Regards,
Florian

bug#58880: [PATCH v2 2/2] nls: Update translation keys for guix gc

[pelzflorian (Florian Pelz)]

Remco van 't Veer  writes:
> * po/*/*.po (guix/scripts/gc.scm): Round MiBs in user feedback.

Thank you Remco for not breaking translations, which is nice to users.
But note that usually committers just ignore that the translations stay
broken for a while and that is more feasible for developers and would be
okay too.

Regards,
Florian

bug#60207: ci build of latest guix for armhf

[pelzflorian (Florian Pelz)]

Julius Schwartzenberg  writes:
> Op 24-12-2022 om 22:40 schreef pelzflorian (Florian Pelz):
>> If you want `guix pull` without compiling, then look at
>> <https://guix.gnu.org/en/manual/devel/en/html_node/Channels-with-Substitutes.html>.
>
> I added the lines to my personal .config/guix/channels.scm, but guix
> pull then shows:
> guix pull: waarschuwing: could not find available substitutes at
> https://ci.guix.gnu.org
>
> And it still ends up compiling. I also tried replacing ci with
> bordeaux in the URL, but then it shows a 404.
>
> I think I'm still missing something?

Bah, it appears ci.guix.gnu.org currently just doesn’t build for
armhf-linux.  Bordeaux does not offer the needed Cuirass API.

I believe but do not know that Bordeaux does not actually build the
latest guix, just the packages.

I don’t know if offering the latest guix would even be feasible.
Probably not?  armhf builds take a long time.

Cc to Christopher Baines , Ricardo Wurmus
.

Regards,
Florian

bug#60207: Bug report

[pelzflorian (Florian Pelz)]

Hello Julius.

Julius Schwartzenberg  writes:
> I didn't imagine
> I would need to do a 'guix pull' after running it. It seems I ran it
> at a bad moment, just as 1.4.0 was about to be released.

Indeed, but upgrading without compiling will be easier with bordeaux.
(Probably it would also have been possible to download guix 1.4.0
manually and then insert that into the store with `guix download` or
so.)


> […]
> Is there a way to enforce only binaries are fetched and compilation is
> never attempted? Even if that means I might not always run the latest
> version?

Yes there is a way.  Look at the output from `guix weather` (see

in the English manual); if substitute coverage is bad, you could wait a
few days or maybe look at `guix build --log-file` if compilation fails
at the build farm (see
).

If you want `guix pull` without compiling, then look at
.

I hope it helps.

Regards,
Florian

bug#60207: Bug report

[pelzflorian (Florian Pelz)]

Julius Schwartzenberg  writes:
> Op 20-12-2022 om 10:34 schreef pelzflorian (Florian Pelz):
>> does it work if you do this before pull?
>> sudo guix archive --authorize < $(dirname $(which
>> guix))/../share/guix/bordeaux.guix.gnu.org.pub
>
> When I do this, I get:
>> julius@tinkerboard:~$ sudo guix archive --authorize < $(dirname
>> $(which guix))/../share/guix/bordeaux.guix.gnu.org.pub
>> bash: /usr/local/bin/../share/guix/bordeaux.guix.gnu.org.pub: No such file 
>> or directory
>
> Might there be something wrong with the installation?

Oops, my mistake.  You wrote your guix is at version 1.3.0, which is
older than the bordeaux build farm.

So how would you get an updated Guix?  One way would be to delete /gnu
and /var/guix and then just download and install the 1.4.0 version, but
deleting would invalidate all links to the store.

Alternatively, you run guix pull to some in-between version of guix,
maybe:

guix pull --commit=26499816a973b3aab9aaf8e13b909d0bde4e2dd5

and then run

sudo guix archive --authorize < $(dirname $(which 
guix))/../share/guix/bordeaux.guix.gnu.org.pub

and guix pull.

Regards,
Florian

bug#60164: bug#60165: [1.4.0rc2] Installer doesn't properly render some non-Latin glyphs

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> "pelzflorian (Florian Pelz)"  skribis:
>> is it too late to replace by font-gnu-unifont to fix CJK fonts?
> Oh sure.  Could you send a patch?

Pushed as bbd11199e6856ded8d75468a16789715b6817b45.

> That’ll be in the next release…

It is good that way.  Thank you!

Closing.

Regards,
Florian

bug#60207: Bug report

[pelzflorian (Florian Pelz)]

Hello Julius,

does it work if you do this before pull?

sudo guix archive --authorize < $(dirname $(which 
guix))/../share/guix/bordeaux.guix.gnu.org.pub

Then it would compile fine on the bordeaux build farm and you could
download the substitute from there.

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> * If I resume a crashed installer, I need to resume twice because the
>   first resume always fails immediately.

Hooray, you fixed it.  Ludo, your debugging speed is miraculous.  I did
not know SQLite uses multiple files per database.


> * With bad luck, it permanently fails, even a second, third, fourth,
>   fifth time fail.

It can still permanently fail to resume, e.g. sometimes when doing
Ctrl-c during download of a substitue, it will continue to say nss-certs
is an unknown package, but that may be too rare to happen by chance and
is not what this bug was about.

Closing!

Regards,
Florian

bug#60164: GNU Guix 1.4.0rc2 available for testing!

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> is it too late to replace by font-gnu-unifont to fix CJK fonts?

Sorry, it is not urgent.  CJK translations are very incomplete anyway.
This can wait for later releases.

Still, I have reopened the bug.

Regards,
Florian

bug#60164: GNU Guix 1.4.0rc2 available for testing!

[pelzflorian (Florian Pelz)]

Hi Ludo,

is it too late to replace by font-gnu-unifont to fix CJK fonts?

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Ahoi. :)

Ludovic Courtès  writes:
>> Now that you found the dynamic-wind’s out-guard does not even run:
> It does not run on C-c, but it does run in other cases, typically if you
> just press Enter after reading the message that says “command failed,
> press Enter”.

Ahh.  Then would it be good if you at least pushed the partial fix about
replacing 'restart' with 'stop-service'?  I’m unsure now if it has an
effect on the likelihood that a second resume works again.  But maybe it
does.  And is closer to correct.


> I don’t see how to address the C-c issue so we’ll have to live with it.

Yes.  Thank you for all investigations!

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> The error message that’s haunting us:
>
>   opening file `/gnu/store/….drv': No such file or directory
>
> comes from guix-daemon.  It happens while the client is doing an
> ‘add-text-to-store’ RPC to add that .drv to the store.
> ‘LocalStore::addTextToStore’ supposedly creates the .drv file in
> /gnu/store and then reads it back (‘registerValidPath’ -> ‘addValidPath’
> -> ‘readDerivation’ -> ‘readFile’): this is where it gets ENOENT.
>
> It would suggest that the database is consistent, but that somehow
> writes don’t go through the overlay FS.

Most interesting.

I saw a comment
> void LocalStore::registerValidPaths(const ValidPathInfos & infos)
> {
> /* SQLite will fsync by default, but the new valid paths may not be 
> fsync-ed.
>  * So some may want to fsync them before registering the validity, at the
>  * expense of some speed of the path registering operation. */
> if (settings.syncBeforeRegistering) sync();

In vain, I therefore tried

diff --git a/nix/libstore/globals.cc b/nix/libstore/globals.cc
index d4f9a46a74..5f8a3a3031 100644
--- a/nix/libstore/globals.cc
+++ b/nix/libstore/globals.cc
@@ -40,7 +40,7 @@ Settings::Settings()
 reservedSize = 8 * 1024 * 1024;
 fsyncMetadata = true;
 useSQLiteWAL = true;
-syncBeforeRegistering = false;
+syncBeforeRegistering = true;
 useSubstitutes = true;
 useChroot = false;
 impersonateLinux26 = false;

But it changes nothing.

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> One finding: when hitting C-c, the dynamic-wind exit handler (the one
> that restores the database and umounts the cow store) is *not* executed.

Impressive findings.

Now that you found the dynamic-wind’s out-guard does not even run: Uhh I
had misdiagnosed when I thought your 'stop-service' patch had made a
difference and caused a second resume to work.  Second resume was
already possible on rc2.  Except eventually resume stops working and on
some install attempts with rc2, resume stops working right away.

After seeing that you opened a bug#60116 on setsid(), I tested removing
the setsid call and it had no effect, but if the dynamic-wind’s
out-guard does not even run, that is to be expected.


> I did reproduce the issue in a VM by running “ifconfig ens3 down” in a
> tty, or by killing the ‘guix substitute’ process, to cause failure of
> ‘guix system init’.  In that case the database is indeed restored, but I
> occasionally get errors like “/gnu/store/….drv: No such file or
> directory”.

Yes, this is the error message that I get on failing resumes.

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Maxime Devos  writes:
> So, I'm nominally 'on hiatus', but I noticed this mail, and noticed
> you copied a file (and fsync'ed it), but forgot to fsync the directory
> it was copied to -- from what I've read (but I don't recall the
> source), fsyncing the contents of the file isn't enough, you also need
> to fsync the directory such that the new file entry is in the
> directory after crashing.

Ohh indeed!  The Linux manpage on fsync confirms it.  That invalidates
my fsync testing.  Which was on a codepath that, as Ludo found out, did
not even run.  But I will remember to fsync the directory in the future.

Thank you very much Maxime!

Regards,
Florian

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> I ended up with a minimal change,
> pushed in commit b1aef25453067004279c4267cf25e8d6d365890d, that lets
> modprobe load uvesafb for good (it was all about setting
> ‘LINUX_MODULE_DIRECTORY’).

Thank you Ludo for your excellent work.  All is good now on AMD hardware
(my laptop and PC).  I’m still not sure why LINUX_MODULE_DIRECTORY is
needed here and is not needed for kernel module loader service, but
whatever.

Regards,
Florian

bug#60002: installer console garbled on 1984.is VPS

[pelzflorian (Florian Pelz)]

Attila Lendvai  writes:
> their response: "I changed the video mode in libvirt to virtio instead of the 
> default cirrus."

Yes yes, now that you mention cirrus, yhetil.org turns up results:

https://issues.guix.gnu.org/36069

Could you test that patch maybe?  Well of course it would maybe require
the admins to switch you back to cirrus …


> 1) i cannot switch virtual
> consoles,

I guess you could have selected shell-based installation in the
graphical installer, it just wasn’t visible.


> 2) there's no DHCP on the network, i.e. it requires manual configuration 
> using a shell.

Maybe there’s no DHCP because the graphical installer lets you choose
which networking device you want to use.

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Desperately I tried also adding fsync, to no avail, both issues remain.
Non-working patch attached.

Maybe dynamic-wind is an inappropriate pattern here?

If I interrupt installation using Ctrl-C (which I normally don’t,
instead I unplug Ethernet), then I have to press Ctrl-C twice.  Maybe
that could be related to why I need to resume twice?

I’m in the dark.

Regards,
Florian

does not help

diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm
index 5f720f6641..f5935a29c9 100644
--- a/gnu/installer/final.scm
+++ b/gnu/installer/final.scm
@@ -201,6 +201,12 @@ (define (assert-exit x)
  (stop-service 'guix-daemon)
  (copy-file database-file saved-database)
 
+ ;; Sync it to the filesystem.
+ (let* ((flags O_RDONLY)
+(fd (open saved-database flags)))
+   (fsync fd)
+   (close fd))
+
  (mount-cow-store (%installer-target-dir) backing-directory))
(lambda ()
  ;; We need to drag the guix-daemon to the container MNT
@@ -218,8 +224,16 @@ (define (assert-exit x)
  ;; alive.
  (stop-service 'guix-daemon)
 
- ;; Restore the database and restart it.
+ ;; Restore the database.
  (copy-file saved-database database-file)
+
+ ;; Sync it to the filesystem.
+ (let* ((flags O_RDONLY)
+(fd (open database-file flags)))
+   (fsync fd)
+   (close fd))
+
+ ;; And restart guix-daemon.
  (start-service 'guix-daemon)
 
  ;; Finally umount the cow-store and exit the container.

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Hi Ludo…

Ludovic Courtès  writes:
> This time, I believe we only ever copy the database when we’re sure no
> guix-daemon process is accessing it.

Failure.  In addition to your partially helpful patch from before
(with which a second resume now works most of the time), I now tried
further the new change:

diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm
index 044f79372b..360b34d8cb 100644
--- a/gnu/installer/final.scm
+++ b/gnu/installer/final.scm
@@ -196,14 +196,15 @@ (define (assert-exit x)
  ;; the loaded cow-store locale files will prevent umounting.
  (install-locale locale)

- ;; Save the database, so that it can be restored once the
- ;; cow-store is umounted.
+ ;; Stop the daemon and save the database, so that it can be
+ ;; restored once the cow-store is umounted.
+ (stop-service 'guix-daemon)
  (copy-file database-file saved-database)
+
  (mount-cow-store (%installer-target-dir) backing-directory))
(lambda ()
  ;; We need to drag the guix-daemon to the container MNT
  ;; namespace, so that it can operate on the cow-store.
- (stop-service 'guix-daemon)
  (start-service 'guix-daemon (list (number->string (getpid

  (setvbuf (current-output-port) 'none)


No additional effect. :(  Perhaps at that time, the guix-daemon isnt
doing anything anyway (though the addition makes sense in general and
may help some users).  There are the same two problems, needing to
resume twice each time and eventually not being able to resume at all
(perhaps some multi-core issue?).  I sent installer-dump-89be04d5.

I tried interrupting the Ethernet on the same machine but with an
installed 1.4.0rc2 Guix System during `guix system reconfigure`.
This has no issues…  There must be corruption in the installer.

Regards,
Florian

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

[pelzflorian (Florian Pelz)]

Hello Ludo, sorry to say I attempted your modprobe patch that uses
(parameterize ((default-environment-variables …

No good.  Screen is black.  Same [ modprobe ] failure in dmesg on QEMU
and on real AMD hardware.

There are workarounds by surrounding modprobe within strace or
alternatively using kernel-module-loader-service (attached; but again,
without the file-exists? check, this would cause new issues on some
machines that dont need uvesafb).

A stupid

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index f6f1923121..a99cf09e31 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -289,6 +289,7 @@ (define (uvesafb-shepherd-service _)
  (provision '(maybe-uvesafb))
  (requirement '(file-systems))
  (start #~(lambda ()
+   (sleep 1)
 (or (file-exists? "/dev/fb0")
 (invoke #+(file-append kmod "/bin/modprobe")
 "uvesafb"


fails though.

All bad…

Regards,
Florian
diff --git a/gnu/system/install.scm b/gnu/sysdiff --git a/gnu/system/install.scm b/gnu/system/install.scm
index f6f1923121..2a1f401536 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -40,6 +40,7 @@ (define-module (gnu system install)
   #:use-module (gnu system locale)
   #:use-module (gnu services avahi)
   #:use-module (gnu services dbus)
+  #:use-module (gnu services linux)
   #:use-module (gnu services networking)
   #:use-module (gnu services shepherd)
   #:use-module (gnu services ssh)
@@ -283,29 +284,22 @@ (define %nscd-minimal-caches
 ;; These define a service to load the uvesafb kernel module with the
 ;; appropriate options.  The GUI installer needs it when the machine does not
 ;; support Kernel Mode Setting.  Otherwise kmscon is missing /dev/fb0.
-(define (uvesafb-shepherd-service _)
-  (list (shepherd-service
- (documentation "Load the uvesafb kernel module if needed.")
- (provision '(maybe-uvesafb))
- (requirement '(file-systems))
- (start #~(lambda ()
-(or (file-exists? "/dev/fb0")
-(invoke #+(file-append kmod "/bin/modprobe")
-"uvesafb"
-(string-append "v86d=" #$v86d "/sbin/v86d")
-"mode_option=1024x768"
- (respawn? #f)
- (one-shot? #t
-
-(define uvesafb-service-type
-  (service-type
-   (name 'uvesafb)
-   (extensions
-(list (service-extension shepherd-root-service-type
- uvesafb-shepherd-service)))
-   (description
-"Load the @code{uvesafb} kernel module with the right options.")
-   (default-value #t)))
+(define uvesafb-config
+  (computed-file "uvesafb.conf"
+ #~(with-output-to-file #$output
+ (lambda ()
+   (display
+(string-append "options uvesafb"
+  " " "v86d=" #$v86d "/sbin/v86d"
+   " " "mode_option=1024x768"))
+
+(define uvesafb-services
+  (list (service kernel-module-loader-service-type
+ '("uvesafb"))
+   (simple-service 'uvesafb-config etc-service-type
+ (list `("modprobe.d/uvesafb.conf"
+ ,uvesafb-config)
+   
 
 (define* (%installation-services #:key (system (or (and=>
 (%current-target-system)
@@ -450,8 +444,7 @@ (define bare-bones-os
  ;; installer.  Some may also need a kernel parameter like nomodeset
  ;; or vga=793, but we leave that for the user to specify in GRUB.
  `(,@(if (supported-package? v86d system)
- (list (service uvesafb-service-type))
- '())
+ uvesafb-services)
 
 (define %issue
   ;; Greeting.

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> I shall try with fsync now.

fsyncing the database had no effect.  (In addition to Ludo’s
'stop-service', I had done

diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm
index ef487805f0..13deffef85 100644
--- a/gnu/installer/final.scm
+++ b/gnu/installer/final.scm
@@ -217,8 +217,16 @@ (define (assert-exit x)
  ;; alive.
  (stop-service 'guix-daemon)
 
- ;; Restore the database and restart it.
+ ;; Restore the database.
  (copy-file saved-database database-file)
+
+ ;; Sync it to the filesystem.
+ (let* ((flags O_RDONLY)
+(fd (open database-file flags)))
+   (fsync fd)
+   (close fd))
+
+ ;; And restart guix-daemon.
  (start-service 'guix-daemon)
 
  ;; Finally umount the cow-store and exit the container.


The same two problems:

* If I resume a crashed installer, I need to resume twice because the
  first resume always fails immediately.

* With bad luck, it permanently fails, even a second, third, fourth,
  fifth time fail.

This is the same as without the fsync.  Fsync had no effect.  Still I
uploaded installer-dump-194618fa.

Regards,
Florian

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> Do you see hints as to whether uvesafb gets loaded?
>
> You can do that by adding “console=ttyS0” to the kernel arguments and by
> passing ‘-serial stdio’ to QEMU.

This serial output shows nothing about uvesafb, but dmesg contains about
uvesafb exactly the same modprobe failure as initially without
LINUX_MODULE_DIRECTORY.

I shall try Brice Waegeneire’s kernel-module-loader-service.  This
cannot be a solution because some computers do already have /dev/fb0 and
doing modprobe uvesafb regardless makes their screen go awry.  But it
will be interesting to know if it still works.

Also of course uvesafb still worked fine in November when we added
hardware support warnings to the installer, not long ago, not August.
Probably restoring the old linux kernel would be a workaround too.

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Eventual success, partially.

First of all:

Ludovic Courtès  writes:
> "pelzflorian (Florian Pelz)"  skribis:
>> Additionally, I had to do “GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT=y
>> make update-guix-package”.  Or else the installer was using a Guix that
>> did not have the lines swapped.
> Hmm this is surprising because we’re already using (current-guix) in
> (gnu installer).

Apparently no.  If I commit only those two diffs from your mail, with
`./pre-inst-env guix system image -t iso9660 --label=Guix
gnu/system/install.scm`, then

guix gc --references /gnu/store/*-installer-real

prints a Guix package that does not contain any of the changes to
gnu/installer/final.scm.

Nonetheless I used it and ran the installer with surprising failures
that make me doubt either the health of my USB drive: `guix system
init --fallback` did not download substitutes but said ACL seems to be
uninitialized and fell back to downloading/building the tar.xz
sources.  I pulled the Ethernet plug, resumed the installer to run
`guix system init` again, but this now complains that nss-certs is an
unknown package.  Sending a dump crashed the installer.  On TTY3, `ls
/tmp` tells me '-bash: ls: command not found'.

Another USB drive, another try, the installer again says there's no
ACL and downloads tar.xz, but otherwise behaves as rc2 and sometimes
bugs out when pulling Ethernet; final.scm does not contain the patch.

Is that second diff of yours perhaps really about ACLs?

I do the authorization dance, commit the diff about 'stop-service' and
the update-guix-package, then pull --branch=version-1.4.0.  I can now
resume happily, when pulling the Ethernet and even when pressing
Ctrl-C just for fun.

Except it is necessary to resume twice.  The first resume always fails
and the second resume resumes.  Does it confuse the two databases?

Except after a large number of resumes, not even the second resume
resumes anymore.  I sent a installer-dump-c82c7abf.

I shall try with fsync now.

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Hi again.

Ludovic Courtès  writes:
> So my guess is that things will be much better if we swap these two
> lines.

This was helpful, but not enough.

Swapping them may have improved the likelihood of being able to retry,
but the issue is still there.  I uploaded as installer-dump-5f9f8dbe,
but it is pretty much the same as the previous dump.

Tomorrow, I will try to add an fsync call in between the two lines.

>   ./pre-inst-env guix system image -t iso9660 --label=Guix \
> gnu/system/install.scm

Additionally, I had to do “GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT=y
make update-guix-package”.  Or else the installer was using a Guix that
did not have the lines swapped.

Also before I did the GPG authorization dance (my x86 machine isn’t
worth getting my actual commiter GPG keys, so I make sure its dummy GPG
key is in the keyring branch, .guix-authorizations file, that
guix/channels.scm’s default guix channel points to the url
/home/florian/src/guix and to the commit with the new authorization).
Then I guix pulled.  So that building the installer succeeds.  I did
*not* use ./pre-inst-env.

Regards,
Florian

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> I will next try using 'load-linux-modules-from-directory' and no
> modprobe.

I tried the attached patch.  Doesn’t work, still black (in QEMU).

Says the dmesg:
> [   11.183789] shepherd[1]: Service user-homes has been started.
> [   11.184555] shepherd[1]: Service user-processes has been started.
> [   11.185587] shepherd[1]: Service host-name has been started.
> [   11.186350] shepherd[1]: Service user-homes has been started.
> [   11.187383] shepherd[1]: Failed to start maybe-uvesafb in the background.
> [   15.213524] 8021q: 802.1Q VLAN Support v1.8
> [   15.213541] 8021q: adding VLAN 0 to HW filter on device eth0

And nothing more.

Maybe there is a mistake in my patch.

Regards,
Florian

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index f6f1923121..8456cc1570 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -37,6 +37,7 @@ (define-module (gnu system install)
   #:use-module ((guix store) #:select (%store-prefix))
   #:use-module (guix utils)
   #:use-module (gnu installer)
+  #:use-module (gnu build linux-modules)
   #:use-module (gnu system locale)
   #:use-module (gnu services avahi)
   #:use-module (gnu services dbus)
@@ -289,14 +290,20 @@ (define (uvesafb-shepherd-service _)
  (provision '(maybe-uvesafb))
  (requirement '(file-systems))
  (start #~(lambda ()
-(or (file-exists? "/dev/fb0")
-(invoke #+(file-append kmod "/bin/modprobe")
-"uvesafb"
-(string-append "v86d=" #$v86d "/sbin/v86d")
-"mode_option=1024x768"
+(unless (file-exists? "/dev/fb0")
+  (load-linux-modules-from-directory '("uvesafb") "\
+/run/booted-system/kernel/lib/modules"
  (respawn? #f)
  (one-shot? #t
 
+(define uvesafb-config
+  (computed-file "uvesafb.conf"
+ #~(with-output-to-file #$output
+ (lambda ()
+   (display
+(string-append "options v86d=" #$v86d "/sbin/v86d"
+   " " "mode_option=1024x768"))
+
 (define uvesafb-service-type
   (service-type
(name 'uvesafb)
@@ -450,7 +457,10 @@ (define bare-bones-os
  ;; installer.  Some may also need a kernel parameter like nomodeset
  ;; or vga=793, but we leave that for the user to specify in GRUB.
  `(,@(if (supported-package? v86d system)
- (list (service uvesafb-service-type))
+ (list (simple-service 'uvesafb-config etc-service-type
+ (list `("modprobe.d/uvesafb.conf"
+ ,uvesafb-config)))
+   (service uvesafb-service-type))
  '())
 
 (define %issue

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> Specifically, here’s the minimal change we should test:[…]
> +(unless (file-exists? "/dev/fb0")
> +  (setenv "LINUX_MODULE_DIRECTORY"
> +  "/run/booted-system/kernel/lib/modules")

Thanks for the patch.

I found I can test in QEMU if I put nomodeset in the kernel arguments
in GRUB.

Without the patch, the screen stays black there too.
With the patch, it hrmm it also stays black.

I will next try using 'load-linux-modules-from-directory' and no
modprobe.

Regards,
Florian

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

[pelzflorian (Florian Pelz)]

Thank you Josselin.

Josselin Poiret  writes:
> I don't think there's a race issue with the files being available:

Yes apparently, but it is some kind of race.

BTW it happens on master branch too despite its more recent linux.

> By the way, why is the modprobe binary inside a #+?  The target will want
> to be able to run the binary itself, right?  Shouldn't it be #$?

You are right, I guess.  But I will later try replacing it with Ludo’s
load-linux-modules-from-directory instead.  Perhaps that even gets the
install image small enough for a CDROM again? :)

>> I will try tomorrow to get an strace.  The installer worked fine in …
>> August I believe.
>
> You could also probably try logging the system* call in some temporary
> log file, by using some bash redirection (or with-current-output-port
> and friends).

I replaced the “(invoke #+(file-append kmod "/bin/modprobe") "uvesafb" …”
by a convoluted

(with-output-to-file "/tmp/strace"
  (lambda ()
(with-error-to-port
 (current-output-port)
 (lambda ()
   (open-pipe* OPEN_READ
   #+(file-append strace "/bin/strace")
   "-f"
   #+(file-append kmod "/bin/modprobe")
   "uvesafb"

but now the strace is a workaround and the modprobe succeeds.  Either
way, /tmp/strace shows that modprobe first reads
/run/booted-system/kernel/lib/modules/6.0.10-gnu/modules.softdep and the
like.  The successful strace only eventually goes on to read
uvesafb.ko.gz.

For completeness, the strace ends with

openat(AT_FDCWD, 
"/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libgcc_s.so.1", 
O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0203\0\0\0\0\0\0"..., 
832) = 832
pread64(3, "\4\0\0\0 \0\0\0\5\0\0\0GNU\0\1\0\1\300\4\0\0\0\v\0\0\0\0\0\0\0"..., 
48, 94696) = 48
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=100760, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fc734a32000
mmap(NULL, 103496, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fc734a18000
mmap(0x7fc734a1b000, 69632, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fc734a1b000
mmap(0x7fc734a2c000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x14000) = 0x7fc734a2c000
mmap(0x7fc734a3, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fc734a3
close(3)= 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fc734a15000
arch_prctl(ARCH_SET_FS, 0x7fc734a15740) = 0
mprotect(0x7fc734be7000, 16384, PROT_READ) = 0
mprotect(0x7fc734a3, 4096, PROT_READ) = 0
mprotect(0x7fc734c11000, 4096, PROT_READ) = 0
mprotect(0x7fc734c2d000, 4096, PROT_READ) = 0
mprotect(0x7fc734c5a000, 4096, PROT_READ) = 0
mprotect(0x7fc734d69000, 4096, PROT_READ) = 0
mprotect(0x425000, 4096, PROT_READ) = 0
mprotect(0x7fc734d9c000, 8192, PROT_READ) = 0
munmap(0x7fc734d6b000, 6584)= 0
set_tid_address(0x7fc734a15a10) = 153
set_robust_list(0x7fc734a15a20, 24) = 0
rt_sigaction(SIGRTMIN, {sa_handler=0x7fc734c196a0, sa_mask=[], 
sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fc734c24d80}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7fc734c19740, sa_mask=[], 
sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7fc734c24d80}, NULL, 
8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, 
rlim_max=RLIM64_INFINITY}) = 0
brk(NULL)   = 0x1882000
brk(0x18a3000)  = 0x18a3000
uname({sysname="Linux", nodename="gnu", ...}) = 0
newfstatat(AT_FDCWD, 
"/gnu/store/vh4g56m35wwlfg300s4qafykxjy09511-kmod-29/etc/modprobe.d", 
0x7ffe93ffa1f0, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/run/modprobe.d", 0x7ffe93ffa1f0, 0) = -1 ENOENT (No such 
file or directory)
newfstatat(AT_FDCWD, "/usr/local/lib/modprobe.d", 0x7ffe93ffa1f0, 0) = -1 
ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/lib/modprobe.d", 0x7ffe93ffa1f0, 0) = -1 ENOENT (No such 
file or directory)
openat(AT_FDCWD, 
"/run/booted-system/kernel/lib/modules/6.0.10-gnu/modules.softdep", 
O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_GETFL)   = 0x8000 (flags O_RDONLY|O_LARGEFILE)
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=1424, ...}, AT_EMPTY_PATH) = 0
read(3, "# Soft dependencies extracted fr"..., 2048) = 1424
read(3, "", 2048)   = 0
close(3)= 0
openat(AT_FDCWD, "/proc/cmdline", O_RDONLY|O_CLOEXEC) = 3
read(3, "BOOT_IMAGE=/gnu/store/3qdad0k7wv"..., 4095) = 300
read(3, "", 3795)   = 0
close(3)= 0
openat(AT_FDCWD, 
"/run/booted-system/kernel/lib/modules/6.0.10-gnu/modules.dep.bin", 
O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=1050966, ...}, AT_EMPTY_PATH) 
= 0
mmap(NULL, 1050966, 

bug#60002: installer console garbled on 1984.is VPS

[pelzflorian (Florian Pelz)]

Hello Attila.

So the admins are using a Web interface to QEMU.  Which one?  What -vga
option is it using?

Perhaps when in GRUB, press E to edit the linux boot command-line and
append to it: nomodeset

IIRC there had been discussions about QEMU Bochs graphics and such, but
I can’t find them.

> maybe the installer could be extended with something to start a
> temporary shell to configure te network, without the need to switch
> virtual consoles?

I don’t understand this.  Can others help?

Regards,
Florian

bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails

[pelzflorian (Florian Pelz)]

Just now I tried the installer on an AMD desktop but the graphical
installer screen stays black.  Same on an AMD laptop.  After switching
to another TTY, dmesg tells me this:

> [   11.625264] shepherd[1]: Service host-name has been started.
> [   11.625839] shepherd[1]: Service user-homes has been started.
> [   11.629846] shepherd[1]: 
> [   11.630078] [
> [   11.630230] modprobe
> [   11.630382] ] 
> [   11.630592] modprobe: FATAL: Module uvesafb not found in directory 
> /lib/modules/6.0.10-gnu
> 
> [   11.631734] shepherd[1]: Failed to start maybe-uvesafb in the background.
> [   15.185776] :04:00.0: Missing Free firmware (non-Free firmware loading 
> is disabled)

I tried manually running the modprobe command from
gnu/system/install.scm:

/gnu/store/vh4g56m35wwlfg300s4qafykxjy09511-kmod-29/bin/modprobe uvesafb 
v86d=/gnu/store/na24a7653hyf0pghhw9nhfr6mi15v6cz-v86d-0.1.10/sbin/v86d 
mode_option=1024x768

Works fine.  I can switch back by Ctrl-Alt-F1 and the graphical
installer works.

/run/current-system/kernel/lib/modules/6.0.10-gnu/kernel/drivers/video/fbdev/uvesafb.ko.gz
exists.

So I tried waiting until it exists before modprobe (in the attached
patch).  But modprobe still fails in the same way, according to dmesg,
even though the file evidently already existed.

Why doesn’t modprobe find it?  Where does it look?

I will try tomorrow to get an strace.  The installer worked fine in …
August I believe.

Regards,
Florian

From: Florian Pelz 
Date: Mon, 12 Dec 2022 15:33:26 +0100
Subject: [PATCH doesnt work] installer: Fix uvesafb not loading.

* gnu/system/install.scm (uvesafb-shepherd-service): Wait before
invoking modprobe.
---
 gnu/system/install.scm | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index f6f1923121..ffde933990 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -4,7 +4,7 @@
 ;;; Copyright © 2016 Andreas Enge 
 ;;; Copyright © 2017 Marius Bakke 
 ;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice 
-;;; Copyright © 2020 Florian Pelz 
+;;; Copyright © 2020, 2022 Florian Pelz 
 ;;; Copyright © 2020 Efraim Flashner 
 ;;; Copyright © 2022 Josselin Poiret 
 ;;;
@@ -289,11 +289,18 @@ (define (uvesafb-shepherd-service _)
  (provision '(maybe-uvesafb))
  (requirement '(file-systems))
  (start #~(lambda ()
-(or (file-exists? "/dev/fb0")
-(invoke #+(file-append kmod "/bin/modprobe")
+		(define (start-uvesafb)
+		  ;; HOW TO DO THIS THE RIGHT WAY??
+		  (if (file-exists? "/run/current-system/kernel/lib\
+/modules/6.0.10-gnu/kernel/drivers/video/fbdev/uvesafb.ko.gz")
+			  (invoke #+(file-append kmod "/bin/modprobe")
 "uvesafb"
 (string-append "v86d=" #$v86d "/sbin/v86d")
-"mode_option=1024x768"
+"mode_option=1024x768")
+			  ;; Wait and try again.
+			  (begin (sleep 1) (start-uvesafb
+(or (file-exists? "/dev/fb0")
+(start-uvesafb
  (respawn? #f)
  (one-shot? #t
 
-- 
2.38.1

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> shepherd: Service guix-daemon has been stopped.
> shepherd: Service guix-daemon has been started.
> guix system: Fehler: opening file
> `/gnu/store/4z81a7njyvnwa4kn46ad6vhvi0lcnrhh-shadow-4.9.drv': No such
> file or directory
> Befehl ("guix" "system" "init" "--fallback" "/mnt/etc/config.scm" "/mnt") hat 
> mit Exit-Code 1 geendet

Still happens with 1.4.0rc2.  I guess install-system in
gnu/installer/final.scm does not sync the disk on failure?

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> I tried to reproduce it:
>
>   0. I chose a basic installation to a fully-encrypted disk with a
>  single partition.
>
>   1. I hit Ctrl-C while ‘guix system init’ was downloading substitutes.
>
>   2. That led me to a confusing error screen says “Command cryptsetup
>  failed” with Ignore/Abort/Retry buttons.  This should have been
>  “Command guix system init” failed no?
>
>   3. I resumed starting with the “Configuration File” step, and there
>  ‘guix system init’ ran to completion just fine.

Yes, these were the steps, except I did not do encryption.  But I had
not told the whole story …  Sorry!

So what was missing is that the reason I pressed Ctrl-C was a rare
dropout by my Ethernet controller.  Because it is so rare and has not
happened anymore since, as a substitute, for reproducing, I did as
follows:

 0. Use Ethernet for the installation.

 1. During substitute downloading, pull the Ethernet plug.

 2. Get lucky so the installation will crash with an error and not just
pause.  Otherwise, if no crash, repeat.

 3. Press Ctrl-C.

 4. Resume the installation from the last step.

 5. It will fail now.

I now uploaded an installer-dump-bade9971 of me reproducing the issue.

> Maybe the difference is that you hit Ctrl-C when ‘guix system init’ had
> already started copying stuff to /mnt?

No, like you, I was in the substitute downloading step.

This issue is much rarer than I thought.

Thank you for investigating.

Regards,
Florian

bug#59781: bug#50892: [PATCH] guix-install.sh: Authorize all project build farms at once.

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> If there are no objections I’d like to push to ‘master’ and
> ‘version-1.4.0’ this modified version of your patch.

Thank you two, this patch works (on 1.3.0 only ci.guix.gnu.org, on
1.4.0rc1 also bordeaux, except when I decline authorization).

Regards,
Florian

bug#59783: [version 1.4.0rc1] Suggested window managers don't work out of the box

[pelzflorian (Florian Pelz)]

Oops yes.  Ratpoison even displays instructions to get help in a corner.
C-t C-c works fine (after running `guix build xterm`).  Openbox works
fine when right clicking the black screen.

No bug here.  Closing.

Regards,
Florian

bug#59782: [version 1.4.0rc1] Add r8169 to unsupported hardware

[pelzflorian (Florian Pelz)]

Having the installer show a warning here would *not* be appropriate.

These r8169 issues are so rare, I haven’t met one since.

Even though I believe the r8169 Ethernet was at fault, and guix
substitute freezing also had happened to me in the past with it, and
even though Linux-libre reports it as DEBLOBBED on every boot, I am
closing.  We don’t warn about sub-par nouveau graphics either.

Regards,
Florian

bug#58239: version1.4.0rc1 Installer ISO missing mkfs.ext4

[pelzflorian (Florian Pelz)]

This will be resolved by patch#59661.  And my mail was tactless.  Sorry,
Tobias.

Closing.

Regards,
Florian

bug#58239: version1.4.0rc1 Installer ISO missing mkfs.ext4

[pelzflorian (Florian Pelz)]

reopen 58239
thanks

Huh, I thought it was fixed, but with the 1.4.0rc1 installer image:
mkfs.ext4 is missing, but is needed for manual installation as
described in the manual.  e2fsprogs is in /gnu/store though; I can run
the binaries in its sbin directory.  The installer is among the `guix
gc --referrers` of its store filename.

Regards,
Florian

bug#59781: [version 1.4.0rc1] install.sh script should authorize bordeaux

[pelzflorian (Florian Pelz)]

Tobias Geerinckx-Rice  writes:
> If you mean guix-install.sh:

Yes I mean guix-install.sh. :)

Regards,
Florian

bug#59780: [version 1.4.0rc1] reconfigure fails

[pelzflorian (Florian Pelz)]

Tobias Geerinckx-Rice  writes:
> pelzflorian (Florian Pelz) 写道：
>> Having installed the 1.4.0rc1 installer image: After guix pull, it
>> failed to reconfigure, because master is an unrelated commit.
>
> Hah.  This should indeed be mentioned in calls for -RC testing, but
> probably doesn't deserve a bug report, since there's no bug. WDYT?

Huh I don’t understand. :)  Had this been the 1.4.0 release, reconfigure
would be impossible, unless --allow-downgrades.  Is the actual release
commit always on master; do I overlook something?  Then feel free to
close.

Regards,
Florian

bug#59784: [version 1.4.0rc1] Retrying a failed install fails

[pelzflorian (Florian Pelz)]

I aborted graphical system installation (Ctrl-C), retried the
installation and got this:

shepherd: Service guix-daemon has been stopped.
shepherd: Service guix-daemon has been started.
guix system: Fehler: opening file 
`/gnu/store/4z81a7njyvnwa4kn46ad6vhvi0lcnrhh-shadow-4.9.drv': No such file or 
directory
Befehl ("guix" "system" "init" "--fallback" "/mnt/etc/config.scm" "/mnt") hat 
mit Exit-Code 1 geendet
Drücken Sie die Eingabetaste, um fortzufahren.

(It told me to press Enter to continue.)  I did so; retried; but again
it did not really retry the installation, I always get this same error
message.

Sorry in case this is a duplicate bug.

Regards,
Florian

bug#59783: [version 1.4.0rc1] Suggested window managers don't work out of the box

[pelzflorian (Florian Pelz)]

Once there was a commit

commit 3ad3c55842dd34adc4b1a1b65ba0abfbdf5b92ee
Author: Ludovic Courtès 
Date:   Wed Apr 17 00:27:04 2019 +0200

installer: Desktop environment page now includes window managers.

* gnu/installer/services.scm ()[snippet]: Change to be a
list of sexps and add default value.
[packages]: New field.
(%system-services): Adjust 'snippet' fields to be lists of sexps.
Add Openbox, awesome, i3, and ratpoison.
(system-services->configuration): Adjust 'snippet' handling.  Honor
'packages' field.

Maybe openbox and ratpoison services should not be suggested by the
Guix System graphical installer, because they apparently are unusable
without further config files.  Note that sway is not among the
suggested desktop environments either.  WDYT?

Regards,
Florian

bug#59782: [version 1.4.0rc1] Add r8169 to unsupported hardware

[pelzflorian (Florian Pelz)]

Installation (guix substitute) sometimes gets stuck on my Beebox mini
PC with r8169 Ethernet controller.

For the x86_64 graphical installer, I selected everything.
After it had downloaded plenty of other substitutes, installation
printed this and got stuck:

substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
22,2 MB werden heruntergeladen
  cairo-1.16.0-doc  135KiB 616KiB/s 00:00 [##] 
100.0%

I waited 10 minutes.  Booting the installer image again, it does not
again get stuck.  Installation was successful now.  I propose this
patch, but will retry some more if installation really never freezes
with USB Ethernet.

IIRC I had had similar problems with this Ethernet socket in the past.

Note: I still need to test the patch.

Regards,
Florian

From: Florian Pelz 
Date: Fri, 2 Dec 2022 18:25:11 +0100
Subject: [PATCH] installer: Warn about r8169 Ethernet controller.

Because guix substitute sometimes freezes.

* gnu/installer/hardware.scm (%unsupported-linux-modules): Add it.
---
 gnu/installer/hardware.scm | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gnu/installer/hardware.scm b/gnu/installer/hardware.scm
index cd1a1767d8..8e92949977 100644
--- a/gnu/installer/hardware.scm
+++ b/gnu/installer/hardware.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2022 Ludovic Courtès 
+;;; Copyright © 2022 Florian Pelz 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -55,7 +56,11 @@ (define %unsupported-linux-modules
 "radeon"
 
 ;; Multimedia.
-"ivtv"))
+"ivtv"
+
+;; Manual additions.
+"r8169"  ;works, but guix substitutes occasionally freezes
+))
 
 (define unsupported-pci-device?
   ;; Arrange to load the module alias database only once.

base-commit: 020184fd39c6244e0336db3c608d3946b8d20490
-- 
2.38.1

bug#59781: [version 1.4.0rc1] install.sh script should authorize bordeaux

[pelzflorian (Florian Pelz)]

Could you make install.sh add bordeaux to /etc/guix/acl?  It is
important especially on ARM.

Regards,
Florian

bug#59780: [version 1.4.0rc1] reconfigure fails

[pelzflorian (Florian Pelz)]

Having installed the 1.4.0rc1 installer image: After guix pull, it
failed to reconfigure, because master is an unrelated commit.

Regards,
Florian

bug#59717: ‘guix’ package fails to build on armhf-linux (OOM)

[pelzflorian (Florian Pelz)]

Ludovic Courtès  writes:
> [ 76%] GUILEC   gnu/packages/uucp.go
> [ 76%] GUILEC   gnu/packages/valgrind.go
> [ 76%] GUILEC   gnu/packages/version-control.go
> [ 76%] GUILEC   gnu/packages/video.go
> GC Warning: Failed to expand heap by 67125248 bytes
> GC Warning: Failed to expand heap by 67108864 bytes
> GC Warning: Out of Memory! Heap size: 3440 MiB. Returning NULL!

Happens for me too, unless I do --cores=1.

(In fact my computer turned off for unrelated reasons before the build
finished, but it had gone past to at least xorg.scm.  But I think
--cores=1 made a difference.)

Regards,
Florian

bug#59463: [doc] More foolproof command in https://guix.gnu.org/cookbook/en/html_node/Reproducible-profiles.html

[pelzflorian (Florian Pelz)]

Thanks for reporting in time for the 1.4.0 release of the cookbook. :)
Fixed in 39f88ee29faa98d0b9b9761f2db8dc7721200fe5.

Regards,
Florian

bug#36786: Warn of AMD GPUs unusable with Guix System

[pelzflorian (Florian Pelz)]

pelzflorian (Florian Pelz) wrote on 26 Jul 2019 22:03
> I would rather see a more prominent link to the manual and h-node
>  where on the downloads page it says “runs on i686, x86_64, ARM”,
>  because I suppose many people do not read the manual until they know
>  they need to, and instead expect things to just work, especially now
>  that there’s a graphical installer.

Closing.  Documenting non-working hardware is no longer necessary since
warnings were prominently added within the installer, as discussed at
<https://issues.guix.gnu.org/58357>.

bug#58760: Guix System iso too big for cdrom again

[pelzflorian (Florian Pelz)]

close 58760
thanks

Thank you all for your responses.  But I have closed the issue (without
really trying the methods) because

Tobias writes:
> But we can go deeper if we choose to, by dropping zisofs and going for
> something like squashfs, which achieves higher compression through
> higher block sizes and better algorithms like XZ.

Probably yes, though I don’t dare writing that and

Csepp writes:
> Are there unnecessary dependencies that could be cut out?

Kind of, but only by making variant packages without the dependencies
that Maxime listed in his response, just for the installer, but it would
not be enough to get below 700MB.

Maxime writes:
> I think -Os would be worth investigating.

Yes, that would be easiest, though looking at --tune, I guess making
variant base packages with -Os just for the installer is not worth the
complexity since cdroms are a niche use-case.

It would be possible, so maybe I shouldn’t have closed, but maybe I
shouldn’t have filed the issue in the first place.

Regards,
Florian

bug#58760: Guix System iso too big for cdrom again

[pelzflorian (Florian Pelz)]

Hello Guix,

thanks to commit

commit 26c1bd9dfafb5a954d2174b7a000304cd7ae6345
Author: Tobias Geerinckx-Rice 
Date:   Mon Apr 6 17:48:21 2020 +0200

vm: Transparently compress iso9660 images.

* gnu/build/vm.scm (make-iso9660-image): Use the ‘--zisofs’ xorriso
filter at the highest compression settings for supported directories.

it was possible to burn the Guix System install image to a 700MB CD.
But it fits no more.  I compared using the du tool (comparison between
good old Guix version e427593 and bad new Guix version 3734857f (with
unmerged installer patches) is attached).  The result is that most
packages got slightly bigger and this broke the camel’s back.  From what
Tobias (Cc) wrote, he used the highest compression settings.

So it seems nothing can be done to make the install iso smaller than
700MB and support this antiquated storage medium, but I thought I’d open
a bug and ask, because my laptop doesn’t boot from USB, I have more
CD/Rs than DVD/Rs and I guess they are cheaper than DVD.

Regards,
Florian

239K/gnu/store/00i95b7dlkwy3jxs7zmf26aj2xx9g4k1-guix-icons-0.1
264K/gnu/store/03bfgi532wmcvjiksxl5lfv08d2a-mcron-1.2.1
27K /gnu/store/06xhcadyz7yb6fr4372pwyks0chwd7li-wireless-regdb-2020.11.20
692K/gnu/store/070h6ybqn8jwr27lzmka3zdl9l9p2fyn-ntfs-3g-2021.8.22
129K/gnu/store/091s4h0hv6dsf2hk3124c3k5m3ibf09a-module-import
9.9M/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib
2.3M/gnu/store/0a1cfyj723lpl7akqyacrfx5mnmnypjq-elogind-246.10
124K/gnu/store/0c1yfbxyv877mlgychfgvmk5ha2jqh52-gzip-1.10
1.3M/gnu/store/0hng3anppzxbcm2vf6qpsp2cawlrqpjw-libnl-3.5.0
68K /gnu/store/0j5vj9ymnd2ln16xsp5fn3x8fjs9d828-module-import
2.0K/gnu/store/0kbdigzidwc57xz7c31q20hp1w7r9hzs-system
1017K   /gnu/store/0wnqkvxm4swkhggvhr2lbggvixqqywqi-findutils-4.8.0
4.0K/gnu/store/0zchy9afz47kbf6h5g816k2ac8mmc4a5-pam.d
98K /gnu/store/17rcyc25v3qal1cnxq30q1r5rvvjf07z-guile-lzma-0.1.1
29K /gnu/store/1angm77m7dscbhdx7hwssijclc3s-openfwwf-firmware-5.2
397K/gnu/store/1b9za8ja26bf0rx6ck802vf0q09w8czx-libfido2-1.9.0
2.3M/gnu/store/1gddq9hrlqsyr2pnbk9lqzm1ljbbl0vi-e2fsprogs-1.46.4
424K/gnu/store/1jsaaqyb7s5z0c07wcm3nvnhhm7fbi3w-libidn-1.37
21K /gnu/store/1p42zcz94ghdxldg55mirqjh3gcsiskq-iso639-languages
450K/gnu/store/1sv35zapdscwkq92vhx2ld0hfcy84ngc-jfsutils-1.1.15
998K/gnu/store/1wc9sy8hm0x7l7n93j67c2z82m3rx7ph-inetutils-2.0
6.0K/gnu/store/1xkw8slx0lnaldaza2p9dn5zya526bfm-etc
3.2M/gnu/store/22n2s0vfvqg9v0as9h7fpdn1i9dmryvi-texinfo-6.7
579K/gnu/store/25nlsljfziysgbhhj9nhwfm4qn5h4b71-liburcu-0.13.1
196K/gnu/store/2b2szj7bkwmw38k8xs0p3bm5shhk62xp-dosfstools-4.2
477K/gnu/store/2b3blhwbag1ial0dhxw7wh4zjxl0cqpk-pkg-config-0.29.2
67K /gnu/store/2i5alw7qcp35x0rn0yqxmvxv3pd6ln3w-libltdl-2.4.6
331K/gnu/store/2lczkxbdbzh4gk7wh91bzrqrk7h5g1dl-libgc-8.0.4
1.5M/gnu/store/2lis8khrdk0zzjzs5ydi8rs5h6f6wjr7-shadow-4.9
171K/gnu/store/2nidr0m9g2339xlalqp8k57hz5qjnmdg-guile-readline-3.0.7
275K/gnu/store/2rl0dr9hccvpwg5dh7xw2vhsgnsnnbkr-libthai-0.1.28
2.5M/gnu/store/31ffp5lszf1g7h1zw750w621cm14hxlr-util-linux-2.37.2
1.5M/gnu/store/35lj2sn5p6wfd8h1j11hb2mcvria3cfl-iproute2-5.15.0
2.5M/gnu/store/37zhmvwd0nkprkk576zvf0da8c23nqwb-util-linux-with-udev-2.37.2
455K/gnu/store/3jyi415msv84pgbvn0nhfwjp7y6zqrs9-dbus-1.12.20
2.4M/gnu/store/3k1h2ifn12rs9a06arpvqzrz5k7bwqm1-linux-libre-headers-5.10.35
632K/gnu/store/3kl94m3ksm45a880b6lnn3kagk857lj9-libgcrypt-1.8.8
81K /gnu/store/3kwgpc5swlpcb5kxvj59w03ljil5i9xv-libdatrie-0.2.13
3.4M
/gnu/store/3vw1ryic3pm4jrv3nw72p5c0b5f2hahx-util-linux-with-udev-2.37.2-lib
525K/gnu/store/3x3dl71d4xm6y4hjwq110hmfyfx0xc6j-zstd-1.5.0-lib
2.5M/gnu/store/3ykcfr1g59gqbwpckg5v375k5iyy5yn3-openssh-8.8p1
989K/gnu/store/4001xfiqqdqmk289s3qq66ll10nqa8d5-cryptsetup-2.3.6
638K/gnu/store/42a19j9rnni49qdhg5fqpv52w95ggyaa-screen-4.8.0
801K/gnu/store/4f304c7dp68hkcp1zi1i07zm8nfvvyp7-bash-static-5.1.8
114K/gnu/store/4ff7h98gn50garnhb9xbf5vj3fm42pd9-kexec-tools-2.0.23
138K/gnu/store/4g1mjb2rwi6pcwp0nrc8zhia0sfq9k45-ca-certificate-bundle
160K/gnu/store/4gcznd9r1r3hlmkb2m7s1a37radgnspn-libtasn1-4.17.0
447K/gnu/store/4ic6244i3ca4b4rxc2wnrgllsidyishv-file-5.39
67K /gnu/store/4j3z5c16814xlldi4zxm99ki6d58ngva-ath9k-htc-firmware-1.4.0
34K /gnu/store/4r6f3a6n82nv48c7nznhhcl19k7pl0ig-libsigsegv-2.13
644K/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8
112K/gnu/store/52ry02pdl17072zcppsc7q0a1abwymmw-libnftnl-1.2.0
21K /gnu/store/53dn0dxvcsjy5b1lx21z0xjslk3s3gdd-locales
3.4M/gnu/store/5583c2za2jsn9g6az79rnksgvigwnsk7-util-linux-2.37.2-lib
1.8M/gnu/store/55q02v1a3qz8n7rlhy3jva9qjkfwj8y0-gawk-5.1.0
59K /gnu/store/58sgs8gxjmzxivzli8bpz77bdchglwcg-nss-mdns-0.14.1
1.4M/gnu/store/5bdkljfxz414w2vwrbqcrfsh54jq4sn2-alsa-utils-1.2.4
86K /gnu/store/5gqdzkw4kmg427bsgzwa5h5vlfi1y7c2-libcbor-0.8.0
16M 

bug#58571: translations are incompletely pulled from weblate

[pelzflorian (Florian Pelz)]

Julien Lepiller  writes:
> One thing I suspect is that weblate takes quite a lot of time to pull
> changes from the intermediate repository, so if you provide a
> translation while the repo is being synced, I think they might be
> reset when the file is finally loaded by weblate.

Something similar happened to me once: Immediately after Weblate
reported I had successfully uploaded a PO file, I decided to translate a
new untranslated string.  This made Weblate lose all translations from
the previous PO file upload.

tl;dr: Yes, Weblate sometimes can lose translations.

> For anyone in that situation, the translations are not lost. You can
> always go back to them and you'll see they are untranslated, but
> you'll see a red box on the right saying it's already translated. If
> the text is correct, you can click "fix string" to apply the
> translation.

Good to hear.

Regards,
Florian

bug#58571: translations are incompletely pulled from weblate

[pelzflorian (Florian Pelz)]

two--- via Bug reports for GNU Guix  writes:
> hi
> in https://git.savannah.gnu.org/cgit/guix.git/tree/po/guix/uk.po i see
> kyrylo's translations are pulled there from weblate, but mine
> (https://translate.fedoraproject.org/changes/?project=guix=uk=two22)
> are not, these strings stay untranslated or erroneous.

This is strange and I do not yet see what could be the cause.

Weblate is backed not by savannah but by an intermediate repository
https://framagit.org/tyreunom/guix-translations
which Julien regularly syncs with Savannah each month.

Perhaps could you try changing a translation on Weblate and see if there
is a change to ?  It
will sync faster if after you make the change on Weblate, you use
Weblate’s File download button.

Regards,
Florian

bug#58444: Make gtk use librsvg on aarch64 again.

[pelzflorian (Florian Pelz)]

close 58444
thanks

"pelzflorian (Florian Pelz)"  writes:
> "pelzflorian (Florian Pelz)"  writes:
>> I wrote a patch but probably it would rebuild the world.
> It does rebuild the world.  I will try with (or (target-aarch64?)
> (target-x86-64?)).

My other attempt also caused rebuilds.  Also it's not that important if
gtk+-2 uses an old librsvg.  I had thought GNUtoo's i686 fix (and thank
you for it) introduced a regression for aarch64, but had not noticed how
his use of (target-x86-64?) was a common pattern for e.g. emacs as well.
Perhaps it is better to remove the (target-x86-64?) checks as soon as
mrustc supports i686.

Sorry for the noise.  Closing.

Regards,
Florian

bug#58444: Make gtk use librsvg on aarch64 again.

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> I wrote a patch but probably it would rebuild the world.

It does rebuild the world.  I will try with (or (target-aarch64?)
(target-x86-64?)).

Regards,
Florian

bug#58444: Make gtk use librsvg on aarch64 again.

[pelzflorian (Florian Pelz)]

Hi Guix,

Mathieu Othacehe  writes at 
:
> That's because `gst-plugins-bad` and `librsvg-bootstrap` both refer to
> `librsvg` which depends on Rust which is only supported on x86_64-linux.

This isn’t entirely true.  Since
32a87714f4507f853824d82d9c6ca10e1405c8eb, bordeaux has substitutes for
librsvg for aarch64.

I wrote a patch but probably it would rebuild the world.  I haven’t
tried compiling yet.  Would using (or (target-aarch64?)
  (target-x86-64?)) be better?

From: Florian Pelz 
Date: Tue, 11 Oct 2022 16:57:06 +0200
Subject: [PATCH] gnu: gtk: Use recent librsvg on aarch64 again.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit 75e24eec1ed9772dbcb6737270076eca571dc4ea assumed librsvg didn’t
support aarch64, but it *is* supported since commit
32a87714f4507f853824d82d9c6ca10e1405c8eb.

* gnu/packages/gtk.scm (gtk)[propagated-inputs]: Check if librsvg is supported.
---
 gnu/packages/gtk.scm | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index faf4d6f7eb..985031c7b2 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -32,6 +32,7 @@
 ;;; Copyright © 2022 Zhu Zihao 
 ;;; Copyright © 2022 Benjamin Slade 
 ;;; Copyright © 2022 Denis 'GNUtoo' Carikli 
+;;; Copyright © 2022 Florian Pelz 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -969,9 +970,11 @@ (define-public gtk+-2
 (outputs '("out" "bin" "doc" "debug"))
 (propagated-inputs
  (list atk cairo
-   (if (target-x86-64?)
- librsvg-bootstrap
- librsvg-2.40)
+   (let ((target (or (%current-target-system)
+ (%current-system
+ (if (supported-package? librsvg-bootstrap target)
+ librsvg-bootstrap
+ librsvg-2.40))
glib pango))
 (inputs
  (list cups

base-commit: 59911ae29442aba18bcb53233e793d8f3d264504
-- 
2.37.3


Regards,
Florian

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Closing because discussion has ceased and I’m not confident in anything
here.  I suggest Spanish translators remove the policy and translate new
strings as they see fit.

Regards,
Florian

bug#58333: Manual PDFs other than en and es fail to build

[pelzflorian (Florian Pelz)]

Ricardo Wurmus  writes:
> Julien Lepiller  writes:
>
>> You can push this fix directly to the repo, but please also fix it on
>> weblate or it'll break again next time I update translations.
>
> I pushed the fix and made a change in the German translation on weblate;
> the change for the French translation had already been made on weblate.

Thank you!

Regards,
Florian

bug#58044: Localization: "info guix" always shows the manual in English regardless of the user locale

[pelzflorian (Florian Pelz)]

Hello Luis.

Luis Felipe via Bug reports for GNU Guix  writes:
>   LANG=fr_FR.utf8 info guix
> EXPECTED RESULT
> ☑ The info program is displayed in French
> ☑ The Guix manual is displayed in French
> UNEXPECTED RESULT
> ☑ The info program is displayed in French
> ☒ The Guix manual is displayed in English instead of French

I agree, but I won’t be working on this.

For now only “info guix.fr” or “info guix-cookbook.fr” etc. work.


is relevant.

Regards,
Florian

bug#57581: Failing to build the website

[pelzflorian (Florian Pelz)]

zimoun  writes:
> The culprit seems the package ’qtserialport’ in ’packages-builder’ from
> (apps packages builder).  Maybe introduced by commit
> 1ef04fb2288dade3ad2883026ae286a68ef13a1e.

This was a first failing commit for me too, but the reason the website
does not build appears to be the license field of qtshadertools in
commit 1d65ff8fdeb20cc2db956093f0ecb1f3f72afc0e (Cc to Maxim).  I could
make a patch but not today.  Maxim, would you fix it?

I don’t know if there is a way to catch such mistakes early.  Field
sanitizers?

Regards,
Florian

bug#57581: Failing to build the website

[pelzflorian (Florian Pelz)]

zimoun  writes:
> $ LANG=en_US.UTF-8 GUIX_WEB_SITE_LOCAL=yes guix environment -C -m 
> manifest.scm \
>   -E LANG -E GUIX_WEB_SITE_LOCAL  --share=/tmp
>  \
>   -- haunt build

Yes but `guix build -f .guix.scm` fails for me too, perhaps because it
uses latest-guix from %default-channels.  It’s not fixed by using old
haunt, so I guess a change in guix makes the difference, but I have not
found the commit and will not continue looking for it immediately.

Thank you for looking at it.

Regards,
Florian

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Csepp  writes:
> Roughly half of the population is female.  If you don't think they
> should be consulted about decisions that affect them, then you are
> taking an undemocratic stance.

There is no duty for women to respond.

Regards,
Florian

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Hello all.

"pelzflorian (Florian Pelz)"  writes:
> I now changed parts of the German website translation on Weblate to use
> repetition because I agree with inclusiveness in invitations.

I suggest the attached patch to the website in the guix-artwork repo.
No need for changing doc/contributing.texi, I think.  Also:

Jean Pierre De Jesus DIAZ writes:
> >I can’t really judge but don’t believe their and Ludo’s proposal “les
> >usuaries” is really perceived neutral and acceptable.  (To Spanish
> >speakers: What do psychologists say?  Does it appear feminine to you?)
> It doesn't feel feminine or masculine, so I guess it's neutral. But the fact
> that it makes text hard to read. I'd say that anyone can try doing a Stroop
> test to feel the same in their own language to.

So usuaries may just appear unfamiliar, as I understand.

What would Debian do?  I find usuarios on:

https://www.debian.org/international/spanish/notas

Regards,
Florian
From: Florian Pelz 
Date: Fri, 12 Aug 2022 14:33:09 +0200
Subject: [PATCH] website: home: Add note to translators to use inclusive
 wording.

* website/apps/base/templates/home.scm: Add translators comment.
---
 website/apps/base/templates/home.scm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/website/apps/base/templates/home.scm b/website/apps/base/templates/home.scm
index 47adeb7..de180a0 100644
--- a/website/apps/base/templates/home.scm
+++ b/website/apps/base/templates/home.scm
@@ -1,4 +1,5 @@
 ;;; GNU Guix web site
+;;; Copyright © 2022 Florian Pelz 
 ;;; Initially written by sirgazil who waives all
 ;;; copyright interest on this file.
 
@@ -41,6 +42,8 @@ management|Reproducibility") #\|)
  (section
   (@ (class "featured-content"))
   ,(G_ `(h2 (@ (class "a11y-offset")) "Summary"))
+  ;; TRANSLATORS: Try to translate using inclusive wording
+  ;; that addresses men and women.  Guix is for everyone.
   (ul
,(G_
  `(li

base-commit: 4c7f2ce6428a63e202cd2a9474a06f68a946934d
-- 
2.36.1

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Thank you Tobias.

Tobias Geerinckx-Rice  writes:
> How about we turn them into guidelines and add them to Contributing?

Yes, it would prevent such discussions.  But as lfvega says and as is
generally acknowledged, there is no good solution on how to deal with
gender here.

I can’t really judge but don’t believe their and Ludo’s proposal “les
usuaries” is really perceived neutral and acceptable.  (To Spanish
speakers: What do psychologists say?  Does it appear feminine to you?)

In Germanic (and Slavic?) grammatically feminine is clearly derived from
the grammatically masculine form (Benutzerin from Benutzer), which may
be a different situation from Latin; maybe it is not.

Listing both is verbose and unnatural.

Regards,
Florian

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> Ludovic Courtès  writes:
>>   • Using repetitions, “usuarias y usuarios”.
> It depends, but I think inclusiveness in technical manual sections is
> not important enough to justify such trade-offs (for the German

I now changed parts of the German website translation on Weblate to use
repetition because I agree with inclusiveness in invitations.

Spanish translators may consider this too.

Could the bug be closed soon?

Regards,
Florian

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Thank you Csepp/raingloom for speaking up.

Csepp  writes:
> Just a thought, but maybe it shouldn't be a group of men who decides
> what language is and is not inclusive

I believe we don’t disagree on what is / is not inclusive.

> and whether that's important.
> We've had some Outreachy interns, maybe some of them wouldn't mind being
> consulted on this.

There has been plenty of debate elsewhere; no need to bother; I guess
there won’t be consensus.  Yes, we could have a policy without
consensus.  Actually there may be a majority in favor of using verbose
speech that includes all.

Like "Once the patch is committed in the Guix repository[…].  Users can
obtain the new package definition simply by running guix pull"

"Una vez el parche se haya incorporado al repositorio de Guix[…].  Las
usuarias y los usuarios pueden obtener la nueva definición de paquete
ejecutando simplemente guix pull"

But doing that for every such sentence seems bothersome to read even in
cases when the sentence isn’t long already.  For French this is done but
not always.  Should it still be policy?  A strict or a lenient policy?

We could also just leave it to the individual Weblate translators until
an actual edit war occurs.  Even generic las usuarias had bothered
someone before on the Guix mailing lists but didn’t bother that much.
(I cannot find the link; it was a discussion involving Miguel Ángel
Arruga Vivas and that he uses “New Spanish”.)

Though the translation has become stale anyway and doesn’t fit the
English anymore; someone would need to update it.  Then generic las
usuarias stays until someone changes it on Weblate.

Should this bug be closed then?


> (Or we could do what Michael Warren Lucas does in his books: switch
> between female, male, and neutral.  I don't see how that would be
> exclusive.)

Well yeahh, yet another option. xD

Regards,
Florian

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Hi Ludo.

Ludovic Courtès  writes:
>   • Using gender-neutral words—e.g., “personas” or “quién” rather than
> “usuarios”.
>
>   • Talking to the user: “puedes hacer …” rather than “usuarios pueden
> hacer …”.

Agree, but when these don’t work,


>   • Using the -e suffix, which has the advantage of being concise and
> readable, but potentially off-putting (at least today).
>
>   • Using repetitions, “usuarias y usuarios”.

It depends, but I think inclusiveness in technical manual sections is
not important enough to justify such trade-offs (for the German
translation that is).  Hrmm.  Of course I would comply if need be, but I
do disagree.  (I have very little experience with Spanish though.)

Regards,
Florian

bug#57046: Spanish documentation uses exclusive language

[pelzflorian (Florian Pelz)]

Cc to the Spanish translators in po/doc/guix-manual.es.po

Thank you Jean Pierre De Jesus DIAZ for filing a bug instead of starting
an edit war on Weblate.  But if there is a decision on changing, someone
will have to edit the translation on Weblate.

For comparison,

* the main Spanish translation po/guix/es.po uses usuario

* the French translation switches between “utilisateur·rices”,
  “utilisatrices et utilisateurs” and more often masculine “utilisateurs”

* the Portuguese, Russian, German translation use masculine (although at
  least for German I use feminine in some examples)

* German word for users is masculine Benutzer and feminine is
  Benutzerinnen; there is a psychology study that Benutzer*innen is
  perceived feminine while listing both masculine and feminine Benutzer
  und Benutzerinnen is perceived as including men and women (a different
  language and I might give too much weight to one scientific study)
  


Regards,
Florian

bug#48393: Can't build installer on aarch64 / v86d fails to build on aarch64

[pelzflorian (Florian Pelz)]

Pavel Shlyak  writes:
> This one is done with https://issues.guix.gnu.org/55806. I suggest closing it 
> as resolved.

Indeed.  With 55806, the uvesafb is added if (supported-package? v86d
system), avoiding the need to check the system.  I’m Closing by sending
a mail to 48393-d...@debbugs.gnu.org.

Thank you!

bug#41120: uvesafb service is unsupported on aarch64

[pelzflorian (Florian Pelz)]

Pavel Shlyak  writes:
> This one is done with https://issues.guix.gnu.org/55806. I suggest closing it 
> as resolved.

Indeed.  With 55806, the uvesafb is added if (supported-package? v86d
system), avoiding the need to check the system.  I’m Closing by sending
a mail to 41120-d...@debbugs.gnu.org.

Regards,
Florian

bug#40641: Building from git breaks when /bin/sh isn't bash

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)"  writes:
> “guix shell -D guix -- make”
> to just work without workaround?

Argh, I meant to write “guix shell -D guix -- make check” …

Regards,
Florian

bug#40641: Building from git breaks when /bin/sh isn't bash

[pelzflorian (Florian Pelz)]

Wait wait Maxim, the discussion was that
"B. Wilson"  proposed
> [PATCH] build: Let make use its hard-coded default shell
 > To: guix-patc...@gnu.org
>
 > * configure.ac: Set AM_SUBST_NOTMAKE([SHELL])
 > +# Use make's hard-coded default shell. The make in a guix profile
 > +# defaults to the Right Thing, e.g. $GUIX_ENVIRONMENT/bin/sh
> +AM_SUBST_NOTMAKE([SHELL])
 
Then Maxim Cournoyer  writes:
> This seems odd to me. Perhaps it'd be cleaner to detect which shell is
 > used at configure time to detect when /bin/sh != Bash, and warn that if
 > there are issues, the user should set the SHELL variable to Bash.

elaexuo...@wilsonb.com writes:
> Excellent. I agree it's probably not worth POSIXifying the scripts. Forcing
> make to default to guix's bash seems like the right approach IMHO, so +1 for
> that fix.

I think we’re not on the same page.  Is AM_SUBST_NOTMAKE([SHELL]) really
problematic?  Is seems like there is a legitimate use-case that foreign
distro users with /bin/sh = dash would want “guix shell -D guix -- make”
to just work without workaround?  We could use elaexuotee’s
AM_SUBST_NOTMAKE([SHELL]) patch, could we not?

Regards,
Florian