bug#25258: Bashisms when building 0.11.0

[pelzflorian (Florian Pelz)]

Hello,

Guix' testsuite uses the non-POSIX bashism `type -P guile` in
tests/guix-packages.sh which causes a test failure when using
Dash to provide /bin/sh instead of Bash. Additionally gnu/local.mk uses
brace expansion which is not part of POSIX and does not work on Dash.

When building Guix on Parabola GNU/Linux-libre modified to use Dash as
/bin/sh,[1] this causes the Guix build to fail. For building, the guix
0.11.0 package from AUR[2] was used. The attached “patch” allows for a
successful build but is not what we want.

Guix should probably not use bashisms in its Makefile includes and
either not use bashisms in its test suite or make sure the test suite is
executed explicitly with Bash and not /bin/sh.

Regards,
Florian Pelz

[1] https://wiki.archlinux.org/index.php/Dash#Use_DASH_as_.2Fbin.2Fsh
[2] https://aur.archlinux.org/packages/guix/

diff -aur guix-0.11.0.pristine/gnu/local.mk guix-0.11.0.new/gnu/local.mk
--- guix-0.11.0.pristine/gnu/local.mk	2016-12-23 16:24:51.501094452 +0100
+++ guix-0.11.0.new/gnu/local.mk	2016-12-23 17:26:55.651112436 +0100
@@ -903,7 +903,10 @@
 # Those files must remain executable, so they remain executable once
 # imported into the store.
 set-bootstrap-executable-permissions:
-	chmod +x $(DESTDIR)$(bootstrapdir)/*/{bash,mkdir,tar,xz}
+	chmod +x $(DESTDIR)$(bootstrapdir)/*/bash
+	chmod +x $(DESTDIR)$(bootstrapdir)/*/mkdir
+	chmod +x $(DESTDIR)$(bootstrapdir)/*/tar
+	chmod +x $(DESTDIR)$(bootstrapdir)/*/xz
 
 DISTCLEANFILES =\
   $(nodist_bootstrap_x86_64_linux_DATA)		\
diff -aur guix-0.11.0.pristine/Makefile.am guix-0.11.0.new/Makefile.am
--- guix-0.11.0.pristine/Makefile.am	2016-12-23 16:24:49.007702057 +0100
+++ guix-0.11.0.new/Makefile.am	2016-12-23 16:25:39.372217348 +0100
@@ -275,7 +275,6 @@
   tests/guix-download.sh			\
   tests/guix-gc.sh\
   tests/guix-hash.sh\
-  tests/guix-package.sh\
   tests/guix-package-net.sh			\
   tests/guix-system.sh\
   tests/guix-archive.sh\

bug#25775: Can't install packages after guix pull

[pelzflorian (Florian Pelz)]

On 02/18/2017 12:11 PM, Pjotr Prins wrote:
> I am seeing the same on a fresh checkout and build:
> 
> penguin2:~/genenetwork/guix$ ./pre-inst-env guix package -p 
> $HOME/opt/guix-build-system --install autoconf
> warning: failed to install locale: Invalid argument
> Backtrace:
> In guix/packages.scm:
>  982: 19 [bag-grafts # #]
>  966: 18 [fold-bag-dependencies # guix/packages.scm:982:29 (package grafts)> ...]
>  983: 17 [# # 
> ()]
>  786: 16 [cache! # # "x86_64-linux" ...]
>  910: 15 [thunk]
>  786: 14 [cache! # # # ...]
> 1092: 13 [thunk]
> 1024: 12 [bag->derivation # # #]
> In srfi/srfi-1.scm:
>  578: 11 [map # #]
> In guix/packages.scm:
>  846: 10 [expand-input # # # ...]
> In guix/store.scm:
> 1249: 9 [run-with-store # ...]
> In guix/packages.scm:
>  480: 8 [# #]
>  485: 7 [# #]
> In gnu/packages/bash.scm:
>  249: 6 [# #]
> In guix/download.scm:
>  421: 5 [# #]
> In guix/store.scm:
> 1169: 4 [# #]
> In guix/packages.scm:
>  786: 3 [cache! # #f ...]
> 1092: 2 [thunk]
>  786: 1 [cache! # #f ...]
>  871: 0 [thunk]
> 
> @ commit 42e721a13d6f47397e585f5909d140c4bafb4ad0
> 
> Installation with --no-grafts passes fine.
> 
> Pj.
> 

I had the same error yesterday on Arch after `guix pull` when I tried to
`guix system init` or `guix package -u`. I tried again with a newly
compiled guix from git, but the same error occurred. I did not try
--no-grafts.

Today I don’t even get that far:

$ guix package -u
guix package: error: failed to connect to
`/var/guix/daemon-socket/socket': Connection refused

`systemctl status -l guix-daemon` shows no errors. Another reboot of
course does not help.

Regards,
Florian

bug#25775: Can't install packages after guix pull

[pelzflorian (Florian Pelz)]

A full uninstall and reinstall as described on the Arch wiki solved the
issue for me; `guix pull` and everything works again. systemctl had
reported the daemon to be running; I still have no idea what happened.
Some network thing? No idea.

bug#26158: Gnome starts unreliably

[pelzflorian (Florian Pelz)]

Does

guix package -i xf86-video-intel

or

guix package -i xf86-video-nouveau

help (or whatever else your GPU is from `guix package -s xf86-video-`)?

Regards,
Florian

bug#26170: documentation: Explanation of propagated-inputs unclear

[pelzflorian (Florian Pelz)]

Hello,

I presume the difference between a package’s `inputs` and
`propagated-inputs` in Guix packages is that propagated inputs get
installed to a Guix profile whenever the package is installed while
inputs are dependencies that remain in the Store. I presume libraries
the packaged program is linked to do not need to go to
`propagated-inputs` because the program is linked to the files in the Store.

For more context, I am attempting to package the GNOME Evolution mail
client which looks for evolution-data-server’s
share/dbus-1/services/org.gnome.evolution.dataserver.Sources.service
at run time and thus should use it as a propagated input (I believe).

I am however confused by `info guix` where I find explanations like
“Lastly, ‘propagated-inputs’ is similar to ‘inputs’, but the
  specified packages will be automatically installed alongside
  the package they belong to (*note ‘guix package’:
  package-cmd-propagated-inputs, for information on how ‘guix
  package’ deals with propagated inputs.)”
and
“Sometimes packages have “propagated inputs”: these are dependencies
 that automatically get installed along with the required package
 (*note ‘propagated-inputs’ in ‘package’ objects:
 package-propagated-inputs, for information about propagated inputs
 in package definitions).“

I suggest mentioning more explicitly
 1) that `propagated-inputs` are automatically installed *to the Guix
profile* and not just the Store like regular inputs and
 2) that C/C++ libraries do not need to be propagated because they can
just as well be loaded from the Store *unless* their header files are
included by header files of another input package (?) and
 3) more examples like the above example for GNOME Evolution (which
however I have yet to finish packaging and submit as a patch; maybe
dconf is a better example – I presume it is also needed at run time and
not just).

This would have made the purpose of `propagated-inputs` easier to
understand.

Regards,
Florian

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

[pelzflorian (Florian Pelz)]

Currently multiple packages contain the file
share/glib-2.0/schemas/gschemas.compiled (which is built by
glib-or-gtk-build-system). Doing so *works* (because each package’s
share directory in the Store is part of the XDG_DATA_DIRS environment
variable, GSettings looks for settings in each of the gschemas.compiled
files in the Store) but leads to *warnings* because only one package’s
gschemas.compiled can be added to the profile at the same time.

To avoid these misleading warnings, either
· no package’s gschemas.compiled should go to the profile on
  install *or*
· gschemas.compiled should not be created for each package by
  glib-or-gtk-build-system, instead it should be created only once
  in each profile by a profile hook from the GSettings data of all
  packages in the manifest,
· or something else?

This bug report follows a discussion here:
https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00552.html

Is it easily possible to prevent a file from going from the Store to a
profile?

As for the other possible solution using a profile hook, John Darrington
asked:
> But what would happen if one had for example gnome-calculator in the
> system profile,
> and gnome-maps in the user profile?  Would it work under those
> circumstances?

A profile hook for gschemas.compiled would eliminate half the purpose of
glib-or-gtk-build-system I believe… It would still be used for setting
GTK_PATH GTK+ modules.

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

[pelzflorian (Florian Pelz)]

On 03/23/2017 05:20 PM, Federico Beffa wrote:
> Note that if you mix GTK-2 and GTK-3 schemas many applications will
> crash.  The glib-or-gtk-build-system tries to avoid mixing the two.
> 
> Fede
> 

I believe you are confusing schemas and modules. GSettings schemas come
from GLib and both GTK+ 2 and GTK+ 3 use the same GLib.

Regards,
Florian

bug#27231: regression?: grub-configuration for grub-efi does not return a bootloader-configuration

[pelzflorian (Florian Pelz)]

Hello,

My GuixSD configuration (see attachment) for UEFI got broken some
three weeks ago but I’ve only now caught up with my e-mail and “fixed”
it.

root@floriannotebook ~# guix system reconfigure 
/home/florian/keep/guixsd-asus.scm
Backtrace:
   9 (apply-smob/1 #)
In ice-9/boot-9.scm:
713:2  8 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  7 (_ #(#(#)))
In ice-9/boot-9.scm:
   2316:4  6 (save-module-excursion _)
  3823:12  5 (_)
In guix/ui.scm:
   1311:8  4 (run-guix-command _ . _)
In ice-9/boot-9.scm:
837:9  3 (catch _ _ # …)
837:9  2 (catch _ _ # …)
In guix/scripts/system.scm:
   1006:8  1 (_)
   885:27  0 (process-action _ _ _)

guix/scripts/system.scm:885:27: In procedure process-action:
guix/scripts/system.scm:885:27: In procedure bootloader-configuration-device: 
Wrong type argument: #< grub: # device: "/dev/sda" menu-entries: () 
default-entry: 0 timeout: 5 theme: #< images: (#< 
aspect-ratio: 4/3 file: #< base: # url: 
"git://git.savannah.gnu.org/guix/guix-artwork.git" commit: "6998d30" 
recursive?: #f> gjomvsacge5nz76kqiyzbpiin32l7nn672voskuo7ahz3za56jga () 
3a4d300> suffix: ("/grub/GuixSD-fully-black-4-3.svg")>>) color-normal: ((fg . 
light-gray) (bg . black)) color-highlight: ((fg . yellow) (bg . black))>>



I ‘guix pull’ed before reconfiguring.

I used this:

  (bootloader (grub-configuration (device "/dev/sda")
  (grub grub-efi)))

Then ‘guix system reconfigure /home/florian/keep/guixsd-asus.scm’ kept
failing. Debugging by (load)ing .guix-real in the Guile REPL and using
breakpoints showed me that this was not a valid
(bootloader-configuration?).

Replacing the above by

  (bootloader (bootloader-configuration (bootloader grub-efi-bootloader)
(device "/dev/sda")))

fixed it today and I can ‘guix system reconfigure’ again.

I don’t know why this broke and if it breaks for others too
(apparently noone has filed a bug yet), which is why I’m filing a bug
here. Using a syntax rule for grub-configuration seems complicated to
me anyway, but I’m still a Guile newbie.

Regards,
Florian
;; Custom config adapted from GNOME/Xfce example in Guix manual.
;; Meant to use GNU Hurd once it is ready.

(use-modules (gnu)
 (gnu packages admin)
 (gnu packages shells)
 (gnu system grub)
 (gnu system locale)
 (gnu system nss)
 (guix gexp))
(use-service-modules avahi
 base
 dbus
 desktop
 networking
 xorg)
(use-package-modules bootloaders
 certs
 cryptsetup
 emacs
 fonts
 freedesktop
 gnome
 guile
 libusb
 linux ; for lvm2, util-linux
 rsync
 ssh
 suckless
 version-control
 wget)

(operating-system
  (host-name "floriannotebook")
  (timezone "Europe/Berlin")
  (locale "en_US.UTF-8")
  (locale-definitions
   (cons (locale-definition
  (name "de_DE.utf8") (source "de_DE"))
 %default-locale-definitions))

  ;; Assuming /dev/sda is the target hard disk, and "GuixSD"
  ;; is the label of the target root file system.
  (bootloader (grub-configuration (device "/dev/sda")
  (grub grub-efi)))
  ;; (bootloader (bootloader-configuration (bootloader grub-efi-bootloader)
  ;;   (device "/dev/sda")))
;;(menu-entries
;;  (list
;;(menu-entry
;;  (label "Parabola GNU/Linux-libre")
;;  ;; see Arch Wiki / GRUB / Encrypted 
GNU/Linux menuentry to see what is missing here
;;  (linux "/boot/vmlinuz-linux-libre")
;;  (linux-arguments 
'("cryptdevice=UUID=e269b169-073a-49f4-a03f-1a34d88384f8:Main" 
"root=/dev/mapper/Main-rootvol resume=/dev/mapper/Main-swapvol" "rw" 
"add_efi_memmap" "initrd=/initramfs-linux-libre.img" 
"init=/lib/systemd/systemd"))
;;  (initrd 
"/boot/initramfs-linux-libre.img"))
;;(menu-entry
;;  (label "Parabola GNU/Linux-libre LTS")
;;  (linux "/boot/vmlinuz-linux-libre-lts")
;;  (linux-arguments 
'("cryptdevice=UUID=e269b169-073a-49f4-a03f-1a34d88384f8:Main" 
"root=/dev/mapper/Main-rootvol" "resume=/dev/mapper/Main-swapvol" "rw" 
"add_efi_memmap" "initrd=/initramfs-linux-libre-lts.img" 
"init=/lib/systemd/systemd"))
;;  (initrd 
"/boot/initr

bug#27231: regression?: grub-configuration for grub-efi does not return a bootloader-configuration

[pelzflorian (Florian Pelz)]

On Sun, Jun 04, 2017 at 04:38:11PM +0300, Alex Kost wrote:
> This is a limitation of 'grub-configuration' macro: that backtrace
> happened because you have 'grub' field *not* in the first place of your
> 'grub-configuration'.
>
> […]
>
> Note that this will work if you put (grub grub-efi) in the first place:
> 
>   (grub-configuration (grub grub-efi)
>   (device "/dev/sda"))
>

Ah… Thank you for clarifying.

  (bootloader (grub-configuration (grub grub-efi)
  (device "/dev/sda")))

I just tried and this fails too with the same error. I’m not sure why
it does not match the syntax rule for grub-configuration.

This macro seems complicated and unintuitive. I don’t like how a
syntax rule feigns being a record definition but isn’t and therefore
breaks things… Why not just inherit bootloader-configuration?

Regards,
Florian

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[pelzflorian (Florian Pelz)]

On Wed, Jun 07, 2017 at 05:58:07PM -0400, Mark H Weaver wrote:
> I have a question: Does GNOME 3 work for *anyone* in Guix now?  If so,
> that would be useful information.  If not, I wonder why this got merged
> into master.
> 
>   Mark
> 

It does not work for me. I get the same error. I'm using the virtual
console for now.

Regards,
Florian

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

[pelzflorian (Florian Pelz)]

On Thu, Jun 08, 2017 at 02:01:22PM +0200, Ludovic Courtès wrote:
> I think many of us use GTK+/GNOME applications, but fewer use GNOME, so
> I suppose we just didn’t test a full GNOME setup.
> 
> Next time we should probably do that or, even better, have an automated
> test that logs in, takes a screenshot, and does some OCR to check
> whether we got something that looks like a GNOME screen.
>
> WDYT?
> 
> Ludo’.
> 

Like a reftest, i.e. comparing a screenshot to what one expects the
screenshot to look like? You can probably take a screenshot of the
GNOME desktop by running gnome-screenshot or by making a D-Bus call to
org.gnome.Shell.Screenshot.Screenshot for a new user (so themes do not
affect it) and compare what is shown in the upper left corner. It says
Activities and the font and color of the top left corner will
presumably change rarely.

A simpler and possibly preferable solution would be checking if GNOME
can successfully start an application set to autostart as per the xdg
desktop specification without gnome-session crashing.

I am not sure how such a test can be run without disrupting a running
login session. Possibly GNOME can be launched on an X server
configured to use xf86-video-dummy like I once tried on a headless
server, see:

https://wiki.archlinux.org/index.php/Vino#Running_on_a_headless_server

I do not know if this can eventually be adapted to Wayland. Xdummy
probably does not support KMS which I believe is required on Wayland.

I so far have not got around to contributing code to the Guix project,
so I probably will not be implementing this either...

Regards,
Florian

bug#27231: regression?: grub-configuration for grub-efi does not return a bootloader-configuration

[pelzflorian (Florian Pelz)]

On Sun, Jun 04, 2017 at 04:25:13PM +0200, pelzflorian (Florian Pelz) wrote:
> On Sun, Jun 04, 2017 at 04:38:11PM +0300, Alex Kost wrote:
> > This is a limitation of 'grub-configuration' macro: that backtrace
> > happened because you have 'grub' field *not* in the first place of your
> > 'grub-configuration'.
> >
> > […]
> >
> > Note that this will work if you put (grub grub-efi) in the first place:
> > 
> >   (grub-configuration (grub grub-efi)
> >   (device "/dev/sda"))
> >
> 
> Ah… Thank you for clarifying.
> 
>   (bootloader (grub-configuration (grub grub-efi)
>   (device "/dev/sda")))
> 
> I just tried and this fails too with the same error. I’m not sure why
> it does not match the syntax rule for grub-configuration.
> 

No, it worked. I must have done something wrong before.

Regards,
Florian

bug#26006: New web site is on line!

[pelzflorian (Florian Pelz)]

Nice website!

On Wed, Dec 06, 2017 at 06:10:48PM +0100, Ludovic Courtès wrote:
> Please report:
> 
>   • broken links;
> 
>   • other pages that need a redirect;
> 
>   • information that disappeared—I’m thinking in particular of talks,
> which used to appear under /help, but are now supposed to be made
> available via a blog post, the advantage being that we get
> /blog/tag/TOPIC links to the post;
> 
>   • anything else that’s broken.
> 

I believe there is a typo on the home page below the video. „leave“
should be „live“:

diff --git a/website/apps/base/templates/home.scm 
b/website/apps/base/templates/home.scm
index bf727dd..f7c2d1c 100644
--- a/website/apps/base/templates/home.scm
+++ b/website/apps/base/templates/home.scm
@@ -196,7 +196,7 @@
 
(p
"GNU Guix won't interfere with the package manager that comes
-with your distribution. They can leave together."))
+with your distribution. They can live together."))
 
   (div
(@ (class "action-box centered-text"))

Regards,
Florian


signature.asc
Description: PGP signature

bug#26006: New web site is on line!

[pelzflorian (Florian Pelz)]

On Fri, Dec 08, 2017 at 01:42:27PM -0500, Quiliro Ordonez Baca wrote:
> "pelzflorian (Florian Pelz)"  writes:
> >
> > I believe there is a typo on the home page below the video. „leave“
> > should be „live“:
> >
> > diff --git a/website/apps/base/templates/home.scm 
> > b/website/apps/base/templates/home.scm
> > index bf727dd..f7c2d1c 100644
> > --- a/website/apps/base/templates/home.scm
> > +++ b/website/apps/base/templates/home.scm
> > @@ -196,7 +196,7 @@
> >  
> > (p
> > "GNU Guix won't interfere with the package manager that comes
> > -with your distribution. They can leave together."))
> > +with your distribution. They can live together."))
> >  
> >(div
> > (@ (class "action-box centered-text"))
> 
> Did you write this patch by hand or did you use some kind of help? If
> you got help from something such as Emacs, I would like to learn how you
> did it so I can contribute with patches to easy stuff such as typos,
> website and documentation.
> 

That would be great.

The above is part of the output from the „git diff“ shell command
after I changed the /website/apps/base/templates/home.scm file in the
guix-artwork.git from Savannah.

For a real patch you could use „git format-patch“ to create an e-mail
file which you can open in your e-mail program and then send.  There
are tutorials on-line.  Use „git am“ to apply such a patch from
someone else after you saved their e-mail to a file.  (There also are
other methods like „git send-email“, „git am“ and so on.)

Emacs also has Git integration, but I am not familiar with it.

Regards,
Florian


signature.asc
Description: PGP signature

bug#31714: Cannot use usb-storage initrd module.

[pelzflorian (Florian Pelz)]

My laptop broke and now I use my formerly internal hard disk as an
external hard disk in another laptop.  It booted fine but I could not
reconfigure maybe because Guix checks for a wrong spelling of the
usb-storage module.


When I pulled
1458f768c1049812166228b8526128b199518e50
and reconfigured I was told to use

(operating-system
  ...
  (initrd-modules (append (list "uas" "usb_storage")
  %base-initrd-modules))

However the module is apparently called usb-storage with a hyphen, the
path is
/gnu/store/9idmpc60bgah6cy6s0k739kpj9qz50qc-linux-libre-4.16.13/lib/modules/4.16.13-gnu/kernel/drivers/usb/storage/usb-storage.ko


Possibly for this reason I got an error

/home/florian/keep/guixsd/guixsd-mac.scm:85:22: warning: 'title' field is 
deprecated
The following derivations will be built:
   /gnu/store/3rk9b4k6797h0yg7m7fbm8jv920cy2cq-system.drv
   /gnu/store/bkhkin2lils3jb3g6j8v14yn50d97xxh-grub.cfg.drv
   [...]
   /gnu/store/l5bglmivni7211gi52gh3z7wvxlhn0b7-module-import-compiled.drv
   /gnu/store/ys5drlyhchjzvdbib2wc46xp2ybx1w52-linux-modules.drv
   /gnu/store/1xjispr77v2q6d8xxlygvg89ls2w79cv-init.drv
   /gnu/store/05knsd3pq0xjd8lw86rz8a7w5dl181c0-raw-initrd.drv
Backtrace:
   6 (primitive-load "/gnu/store/09v5nd445bk4qkcy2ya84swhbri?")
In ice-9/eval.scm:
619:8  5 (_ #f)
   626:19  4 (_ #)
   293:34  3 (_ #)
In srfi/srfi-1.scm:
   592:29  2 (map1 _)
   592:17  1 (map1 ("usb_storage" "ahci" "usb-storage" "uas" "usb?" ?))
In unknown file:
   0 (scm-error misc-error #f "~A ~S ~S" ("module not fo?" ?) ?)

ERROR: In procedure scm-error:
module not found "usb_storage.ko" 
"/gnu/store/9idmpc60bgah6cy6s0k739kpj9qz50qc-linux-libre-4.16.13/lib/modules"
builder for `/gnu/store/ys5drlyhchjzvdbib2wc46xp2ybx1w52-linux-modules.drv' 
failed with exit code 1
cannot build derivation `/gnu/store/1xjispr77v2q6d8xxlygvg89ls2w79cv-init.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/05knsd3pq0xjd8lw86rz8a7w5dl181c0-raw-initrd.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/bkhkin2lils3jb3g6j8v14yn50d97xxh-grub.cfg.drv': 1 dependencies 
couldn't be built
guix system: error: build failed: build of 
`/gnu/store/bkhkin2lils3jb3g6j8v14yn50d97xxh-grub.cfg.drv' failed


But when I use


(operating-system
  ...
  (initrd-modules (append (list "uas" "usb-storage")
  %base-initrd-modules))

then I get an error because I should spell it usb_storage.


/home/florian/keep/guixsd/guixsd-mac.scm:85:22: warning: 'title' field is 
deprecated
/home/florian/keep/guixsd/guixsd-mac.scm:80:9: error: you may need these 
modules in the initrd for /dev/sdc2: uas usb_storage
hint: Try adding them to the `initrd-modules' field of your `operating-system'
declaration, along these lines:

  (operating-system
;; ...
(initrd-modules (append (list "uas" "usb_storage")
%base-initrd-modules)))



Eventually I changed gnu/system/mapped-devices.scm to  replace

  (when aliases
(let ((modules (delete-duplicates
(append-map (cut matching-modules <> aliases)
(device-module-aliases device)
  (unless (every (cute member <> linux-modules) modules)
(raise (condition
(&message
 (message (format #f (G_ "you may need these modules \
in the initrd for ~a:~{ ~a~}")
  device modules)))
(&fix-hint
 (hint (format #f (G_ "Try adding them to the
...

by #t.  Then it successfully reconfigured.

I tested again Guix commit 19b662ea7c53a28270a783f10ca033d8c9d2a954
today and it is still broken.

bug#33171: TMPDIR and build containers

[pelzflorian (Florian Pelz)]

Hello,

The manual says that TMPDIR does not leak into the build environment:

>You can influence the directory where the daemon stores build trees
> via the ‘TMPDIR’ environment variable.  However, the build tree within
> the chroot is always called ‘/tmp/guix-build-NAME.drv-0’, where NAME is
> the derivation name—e.g., ‘coreutils-8.24’.  This way, the value of
> ‘TMPDIR’ does not leak inside build environments, which avoids
> discrepancies in cases where build processes capture the name of their
> build tree.


However, later it says:

>When the daemon performs a build on behalf of the user, it creates a
> build directory under ‘/tmp’ or under the directory specified by its
> ‘TMPDIR’ environment variable; this directory is shared with the
> container for the duration of the build.  Be aware that using a
> directory other than ‘/tmp’ can affect build results—for example, with a
> longer directory name, a build process that uses Unix-domain sockets
> might hit the name length limitation for ‘sun_path’, which it would
> otherwise not hit.


This seems like a contradiction, or do I misunderstand?

Regards,
Florian

bug#26170: Bug #26170 Hunting: doc: Explanation of propagated-inputs unclear

[pelzflorian (Florian Pelz)]

Thank you for bringing up this bug again with detailed
cross-referencing.  Sorry for not sending a patch earlier.

I do not think it makes sense to close yet.  I attach a proposed patch
now (its text is not properly wrapped yet).  It may contain
misunderstandings about propagated inputs as I have not packaged much.

On Wed, Sep 09, 2020 at 03:25:31PM +0200, zimoun wrote:
> Currently, the term “propagated inputs” in the index [2] goes to the
> section “Invoking guix package” [3] and explaining:
> 
> Sometimes packages have propagated inputs: these are
> dependencies that automatically get installed along with the
> required package (see propagated-inputs in package objects, for
> information about propagated inputs in package definitions).
> 
> An example is the GNU MPC library: its C header files refer to
> those of the GNU MPFR library, which in turn refer to those of
> the GMP library. Thus, when installing MPC, the MPFR and GMP
> libraries also get installed in the profile; removing MPC also
> removes MPFR and GMP—unless they had also been explicitly
> installed by the user.
> 
> with the hyperlink [4] mentioning:

Note the text currently in the manual is the same as back then when I
filed the bug.

When starting to read about propagated inputs in the documentation of
`guix package --install`, I agree, it is clear enough, the reader will
understand that propagated inputs get treated like with `guix package
--install` and the reader need not think about profiles and the store.

However, back then I may have gotten confused because I started off
reading the Defining Packages section without the context of `guix
package --install`.  In this context, I may have been thinking of
installation to a directory rather than a user running `guix install`.


> 3) more examples like the above example for GNOME Evolution (which
> however I have yet to finish packaging and submit as a patch; maybe
> dconf is a better example – I presume it is also needed at run time and
> not just).

I was mistaken about 3).  I am glad Ricardo Wurmus packaged Evolution.
Apparently I was wrong and evolution does not need
evolution-data-server as a propagated-input.

Regards,
Florian
>From fd4955cd0a61e92c37a371e4c5411a505ad5ac76 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Wed, 9 Sep 2020 16:54:04 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] doc: Clarify what propagated inputs are.

Fixes .

* doc/guix.texi (package Reference)[package-propagated-inputs]: Clarify.
---
 doc/guix.texi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 1d6782e6fa..0a5640b174 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -6360,21 +6360,21 @@ this area (@pxref{Invoking guix lint}).
 
 @anchor{package-propagated-inputs}
 Lastly, @code{propagated-inputs} is similar to @code{inputs}, but the
-specified packages will be automatically installed alongside the package
+specified packages will be automatically installed to profiles 
(@pxref{Features, the role of profiles in Guix}) alongside the package
 they belong to (@pxref{package-cmd-propagated-inputs, @command{guix
 package}}, for information on how @command{guix package} deals with
 propagated inputs).
 
-For example this is necessary when a C/C++ library needs headers of
+For example this is necessary when packaging a C/C++ library that needs 
headers of
 another library to compile, or when a pkg-config file refers to another
 one @i{via} its @code{Requires} field.
 
 Another example where @code{propagated-inputs} is useful is for languages
 that lack a facility to record the run-time search path akin to the
 @code{RUNPATH} of ELF files; this includes Guile, Python, Perl, and
-more.  To ensure that libraries written in those languages can find
-library code they depend on at run time, run-time dependencies must be
-listed in @code{propagated-inputs} rather than @code{inputs}.
+more.  When packaging libraries written in those languages, ensure they can 
find
+library code they depend on at run time by listing run-time dependencies
+in @code{propagated-inputs} rather than @code{inputs}.
 
 @item @code{outputs} (default: @code{'("out")})
 The list of output names of the package.  @xref{Packages with Multiple
-- 
2.28.0

bug#26170: Bug #26170 Hunting: doc: Explanation of propagated-inputs unclear

[pelzflorian (Florian Pelz)]

On Wed, Sep 16, 2020 at 12:37:20PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)"  skribis:
> >  Another example where @code{propagated-inputs} is useful is for languages
> >  that lack a facility to record the run-time search path akin to the
> >  @code{RUNPATH} of ELF files; this includes Guile, Python, Perl, and
> > -more.  To ensure that libraries written in those languages can find
> > -library code they depend on at run time, run-time dependencies must be
> > -listed in @code{propagated-inputs} rather than @code{inputs}.
> > +more.  When packaging libraries written in those languages, ensure they 
> > can find
> > +library code they depend on at run time by listing run-time dependencies
> > +in @code{propagated-inputs} rather than @code{inputs}.
> 
> I’m not convinced about this hunk; it uses imperative tense towards the
> reader to state the same thing no?

The difference is “When packaging libraries”.  I suppose the intention
is that propagated-inputs be declared as part of library packages and
not as part of the application using those libraries.  I am unsure if
I understand correctly if “When packaging libraries” is not explicitly
stated.

Regards,
Florian

bug#26170: Bug #26170 Hunting: doc: Explanation of propagated-inputs unclear

[pelzflorian (Florian Pelz)]

Thank you both!  Pushed as 125fc37e5f32afdbd1e5fca119c9eb41e7ad8ec1.
Closing.

Regards,
Florian

bug#43746: What to do about packages that don't support --without-tests / #:tests? #f setting

[pelzflorian (Florian Pelz)]

The new package transformation option --without-tests works by setting
#:tests? #f in the specified packages.  But some packages replace
their 'check phase and no longer honor #tests?.  glib for example.

Attached is an attempt to document this current behavior.  Shall I
push it?  Alternatively, it should be documented to write a check
phase that honors #:tests?.  Or the package transformation should be
changed to remove any check phase it finds.

Regards,
Florian>From b55e6ee01fe674b282e7ec75d0e4c8a839262261 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Thu, 1 Oct 2020 15:35:52 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] doc: Explain why '--without-tests' may fail with modified
 'check' phase.

* doc/guix.texi (Package Transformation Options): Explain.
---
 doc/guix.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index e8458ad8d8..6a2bd629cb 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -9350,6 +9350,12 @@ The command above installs @code{python-notebook} on top 
of
 rebuilds everything that depends on @code{python}, including
 @code{python-notebook} itself.
 
+Internally, @code{--without-tests} relies on changing the
+@code{#:tests?} option of a package's @code{check} phase (@pxref{Build
+Systems}).  Note that some packages use a customized @code{check} phase
+that does not respect a @code{#:tests? #f} setting.  Therefore there are
+some packages for which @code{--without-tests} cannot disable tests.
+
 @end table
 
 @node Additional Build Options
-- 
2.28.0

bug#43746: What to do about packages that don't support --without-tests / #:tests? #f setting

[pelzflorian (Florian Pelz)]

On Thu, Oct 01, 2020 at 11:07:54PM +0200, Ludovic Courtès wrote:
> Oh, we should fix ‘glib’ in ‘core-updates’.

I verified the attached patch fixes glib on the ‘master’ branch.  I’m
not sure about adding a copyright.  Anyway.  Shall I push it to
‘core-updates’ or wait until I can test it on ‘core-updates’ without
rebuilding the world?

> I’m inclined to apply the patch you propose and leaving phases
> unchanged.
> […]
> I’d change the last sentence to:
> 
>   Therefore, @option{--without-tests} has no effect on these packages.

I changed it and pushed the patch to the documentation as
3c01fcc1bb9c086f487d9694cb91a57d7abd0880.  Thank you!

(I maybe should have written in the commit message “Fixes
.”  Oh well.  I will leave the bug open
though because glib is not fixed yet.)

Regards,
Florian>From 505cfd0fa3411a21c8794ab84473dc1dd2b8754c Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sat, 3 Oct 2020 00:29:56 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] gnu: glib: Adhere to '--without-tests' option.

* gnu/packages/glib.scm (glib)[arguments]<#:phases>[configure]:
Only run tests if 'tests?' is true.
---
 gnu/packages/glib.scm | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index ca037d3b24..c703894155 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -13,6 +13,7 @@
 ;;; Copyright © 2019 Giacomo Leidi 
 ;;; Copyright © 2019, 2020 Marius Bakke 
 ;;; Copyright © 2020 Nicolò Balzarotti 
+;;; Copyright © 2020 Florian Pelz 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -325,11 +326,14 @@ shared NFS home directories.")
   (for-each (lambda (x) (apply disable x)) failing-tests)
   #t)))
 (replace 'check
-  (lambda _
-(setenv "MESON_TESTTHREADS"
-(number->string (parallel-job-count)))
-;; Do not run tests marked as "flaky".
-(invoke "meson" "test" "--no-suite" "flaky")))
+  (lambda* (#:key tests? #:allow-other-keys)
+(if tests?
+(begin
+  (setenv "MESON_TESTTHREADS"
+  (number->string (parallel-job-count)))
+  ;; Do not run tests marked as "flaky".
+  (invoke "meson" "test" "--no-suite" "flaky"))
+#t)))
 ;; TODO: meson does not permit the bindir to be outside of prefix.
 ;; See https://github.com/mesonbuild/meson/issues/2561
 ;; We can remove this once meson is patched.
-- 
2.28.0

bug#43746: What to do about packages that don't support --without-tests / #:tests? #f setting

[pelzflorian (Florian Pelz)]

On Sat, Oct 03, 2020 at 12:04:37PM +0200, Ludovic Courtès wrote:
> > I verified the attached patch fixes glib on the ‘master’ branch.
> If you tested it on ‘master’, you can push it on ‘core-updates’.

Pushed as 0585a0d0d1fe6e334d36e2d851b42b47d6769546.  Thank you!

Closing, since the issue is documented now and fixing *all* other
check phases is generally not worth it.

Regards,
Florian

bug#43796: Privacy policy

[pelzflorian (Florian Pelz)]

IANAL but I think Guix needs a privacy policy for both its website and
the Guix software in general.

Attached is a patch for the website that also documents data use by
Guix and Guix System.  Maybe I’ve overdone some parts and probably
something important is missing.

In particular, the GDPR requires IP addresses to be deleted from logs
after a reasonable time.  I think but am not sure the current process
for nginx is to delete only when the log files become too big.  A more
suitable policy must be implemented and the users must be told about
it, I think.  See .

In general I think it is better to have an incomplete policy than to
have none.

Comments?

Regards,
Florian
>From 080df2de1f1f99fce3d7dffcce57f723fd266e17 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sun, 4 Oct 2020 17:10:13 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] website: Add privacy policy.

* website/apps/base/templates/privacy.scm: New file with
web page on privacy.
* website/apps/base/templates/components.scm (navbar): Add it.
* website/po/POTFILES: Add it.
* website/apps/base/builder.scm (privacy-builder): New procedure.
(builder): Add it.
---
 website/apps/base/builder.scm  |  23 +
 website/apps/base/templates/components.scm |  18 +++-
 website/apps/base/templates/privacy.scm| 115 +
 website/po/POTFILES|   1 +
 4 files changed, 156 insertions(+), 1 deletion(-)
 create mode 100644 website/apps/base/templates/privacy.scm

diff --git a/website/apps/base/builder.scm b/website/apps/base/builder.scm
index 4882dc5..2acf4dc 100644
--- a/website/apps/base/builder.scm
+++ b/website/apps/base/builder.scm
@@ -1,6 +1,22 @@
 ;;; GNU Guix web site
+;;; Copyright © 2020 Florian Pelz 
 ;;; Initially written by sirgazil who waives all
 ;;; copyright interest on this file.
+;;;
+;;; This file is part of the GNU Guix web site.
+;;;
+;;; The GNU Guix web site is free software; you can redistribute it and/or 
modify it
+;;; under the terms of the GNU Affero General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; The GNU Guix web site is distributed in the hope that it will be useful, 
but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU Affero General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU Affero General Public License
+;;; along with the GNU Guix web site.  If not, see 
.
 
 (define-module (apps base builder)
   #:use-module (apps base data)
@@ -13,6 +29,7 @@
   #:use-module (apps base templates help)
   #:use-module (apps base templates home)
   #:use-module (apps base templates menu)
+  #:use-module (apps base templates privacy)
   #:use-module (apps base templates security)
   #:use-module (apps base types)
   #:use-module (apps blog utils)
@@ -54,6 +71,7 @@
 (contact-builder)
 (irc-builder)
 (contribute-builder)
+ (privacy-builder)
 (security-builder)
 (graphics-builder
 
@@ -115,6 +133,11 @@
   (make-page "menu/index.html" (menu-t) sxml->html))
 
 
+(define (privacy-builder)
+  "Return a Haunt page representing the Privacy page of the website."
+  (make-page "privacy/index.html" (privacy-t) sxml->html))
+
+
 (define (security-builder)
   "Return a Haunt page representing the Security page of the website."
   (make-page "security/index.html" (security-t) sxml->html))
diff --git a/website/apps/base/templates/components.scm 
b/website/apps/base/templates/components.scm
index 44d410e..1bf11e9 100644
--- a/website/apps/base/templates/components.scm
+++ b/website/apps/base/templates/components.scm
@@ -1,7 +1,22 @@
 ;;; GNU Guix web site
-;;; Copyright © 2019 Florian Pelz 
+;;; Copyright © 2019, 2020 Florian Pelz 
 ;;; Initially written by sirgazil who waives all
 ;;; copyright interest on this file.
+;;;
+;;; This file is part of the GNU Guix web site.
+;;;
+;;; The GNU Guix web site is free software; you can redistribute it and/or 
modify it
+;;; under the terms of the GNU Affero General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; The GNU Guix web site is distributed in the hope that it will be useful, 
but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU Affero General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU Affero General Public License
+;;; along with the GNU Guix web site.  If not, see 
.
 
 ;;; This module defines HTML parts like header, breadcrumbs, footer,
 ;;; buttons, etc., which are used website-wide.
@

bug#43796: Privacy policy

[pelzflorian (Florian Pelz)]

On Sun, Oct 04, 2020 at 11:56:04AM -0400, Julien Lepiller wrote:
> The GDPR is not the only legislation that applies to us. For
> services hosted in France for instance, there is a legal obligation
> to keep logs for at least one year (not sure exactly who that
> applies to). There could be something similar in Germany where
> berlin is located.

A quick web search does not reveal any such obligation in Germany.
I also know people who don’t log.  But again, IANAL.

The Debian Privacy Policy says they store web logs for 15 days.
But iplocation.net tells me their server is hosted in the Netherlands.

If the Guix admins do not intend to use such data to “respond to
excess usage or security attacks” on the website, logging should be
disabled and I will remove that wording from the proposed patch.

> I think some of the wording is vague. Does "can be used to identify"
> mean we will use the IP to identify the person (is it the reason we
> process this data?) Or is it something that we could technically do,
> but refuse to do?

I changed it to

During your use of Guix’ software in its default configuration,
your IP address will be revealed to the network services you use.
>From an IP address it may be possible to identify who uses the
service and from which internet connection.  These services include

Attached is the complete patch with this single change.

Are there other things which are badly worded?

Regards,
Florian
>From 7f5354304697cf175dee3a76397d0f4ecff902cf Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Mon, 5 Oct 2020 11:08:34 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] website: Add privacy policy.

* website/apps/base/templates/privacy.scm: New file with
web page on privacy.
* website/apps/base/templates/components.scm (navbar): Add it.
* website/po/POTFILES: Add it.
* website/apps/base/builder.scm (privacy-builder): New procedure.
(builder): Add it.
---
 website/apps/base/builder.scm  |  23 +
 website/apps/base/templates/components.scm |  18 +++-
 website/apps/base/templates/privacy.scm| 115 +
 website/po/POTFILES|   1 +
 4 files changed, 156 insertions(+), 1 deletion(-)
 create mode 100644 website/apps/base/templates/privacy.scm

diff --git a/website/apps/base/builder.scm b/website/apps/base/builder.scm
index 4882dc5..2acf4dc 100644
--- a/website/apps/base/builder.scm
+++ b/website/apps/base/builder.scm
@@ -1,6 +1,22 @@
 ;;; GNU Guix web site
+;;; Copyright © 2020 Florian Pelz 
 ;;; Initially written by sirgazil who waives all
 ;;; copyright interest on this file.
+;;;
+;;; This file is part of the GNU Guix web site.
+;;;
+;;; The GNU Guix web site is free software; you can redistribute it and/or 
modify it
+;;; under the terms of the GNU Affero General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; The GNU Guix web site is distributed in the hope that it will be useful, 
but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU Affero General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU Affero General Public License
+;;; along with the GNU Guix web site.  If not, see 
.
 
 (define-module (apps base builder)
   #:use-module (apps base data)
@@ -13,6 +29,7 @@
   #:use-module (apps base templates help)
   #:use-module (apps base templates home)
   #:use-module (apps base templates menu)
+  #:use-module (apps base templates privacy)
   #:use-module (apps base templates security)
   #:use-module (apps base types)
   #:use-module (apps blog utils)
@@ -54,6 +71,7 @@
 (contact-builder)
 (irc-builder)
 (contribute-builder)
+ (privacy-builder)
 (security-builder)
 (graphics-builder
 
@@ -115,6 +133,11 @@
   (make-page "menu/index.html" (menu-t) sxml->html))
 
 
+(define (privacy-builder)
+  "Return a Haunt page representing the Privacy page of the website."
+  (make-page "privacy/index.html" (privacy-t) sxml->html))
+
+
 (define (security-builder)
   "Return a Haunt page representing the Security page of the website."
   (make-page "security/index.html" (security-t) sxml->html))
diff --git a/website/apps/base/templates/components.scm 
b/website/apps/base/templates/components.scm
index 44d410e..1bf11e9 100644
--- a/website/apps/base/templates/components.scm
+++ b/website/apps/base/templates/components.scm
@@ -1,7 +1,22 @@
 ;;; GNU Guix web site
-;;; Copyright © 2019 Florian Pelz 
+;;; Copyright © 2019, 2020 Florian Pelz 
 ;;; Initially written by sirgazil who waives all
 ;;; copyright interest on this file.
+;;;
+;;; This file is part of the GNU Guix web site.
+;;;
+;;; The GNU Guix web site is free software; you can redistribute it and/or 
modify it
+;;; under the terms of the GNU

bug#43796: (no subject)

[pelzflorian (Florian Pelz)]

On Mon, Oct 05, 2020 at 09:09:20AM +0200, Tomás Ortín Fernández via Bug reports 
for GNU Guix wrote:
> As I understand it, the Guix distribution is *not* a service but a
> piece of software. Neither the Guix community nor the GNU project
> have any responsibility over the third-party services you decide to
> use with the Guix system, your software in your computer; it's only
> responsible of what concerns their services: the website and the
> repositories.

Actually I think we Guix contributors are responsible for the default
configuration.  I would suppose we even should display the Terms of
Service of the default NTP pool 
during install.

Regards,
Florian

bug#43796: (no subject)

[pelzflorian (Florian Pelz)]

On Mon, Oct 05, 2020 at 09:09:20AM +0200, Tomás Ortín Fernández via Bug reports 
for GNU Guix wrote:
> I understand that the point of mentioning all that is more as an
> advice than a policy. Wouldn't it be more useful in a section about
> privacy recommendations (or something similar) that in the privacy
> policy?

Do you mean that the part about Guix and Guix System should rather be
explained in the manual?  Then I agree.  The website’s privacy policy
(or whatever we shall call it) should reference the manual then.

Regards,
Florian

bug#44301: Black screen in Guix System installation

[pelzflorian (Florian Pelz)]

On Sat, Oct 31, 2020 at 02:22:58PM +0100, soheilkhanalipur--- via Bug reports 
for GNU Guix wrote:
> Guix has some incompatibilities like (issues.guix.gnu.org/43985) with my 
> computer.
> What are these? what's the solution?

Your issues are post-install, I think, so the installer worked
properly, so Guix basically works.  However:

Possibly you will not get a good experience because (if I understand
it correctly) Linux-libre might have various incompatibilities because
it is deliberately lacking non-free firmware.

You might work around the graphics issues by using nomodeset or
blacklisting nouveau and then using uvesafb like
.
I’m not sure if all that is really necessary.

Your 7.jpg shows this message:

[  18.727379] usb 1-1.3: Fatal – failed to load firmware

This may be because Linux-libre

bug#44301: Black screen in Guix System installation

[pelzflorian (Florian Pelz)]

I do not know if you deliberately did not reply to all.  I hope you do
not mind me quoting you.

On Sat, Oct 31, 2020 at 04:16:11PM -0400, Douglas Linford wrote:
> Is recompiling the kernel to include radeon an option?
> Meaning, can I recompile the kernel myself?
> 
> Douglas

Guix will not provide support for that, but there is a Guix channel
where others are doing that.  (I cannot link to it and of course it is
a trade-off because parts of Linux (instead of Linux-libre) are
nonfree.)  The uvesafb solution I linked to in my last mail is an
alternative that I use for one old laptop of mine that does not make
much use of your GPU and is therefore slower and may or may not be
more power-hungry, I don’t know.

soheilkhanalipur reported problems with an Nvidia GPU.  I had not seen
that before, maybe the above also helps.  I do not know if
soheilkhanalipur’s USB issues are still problematic.

(Sorry I accidently sent out a draft e-mail before, but it was mostly
complete.)

Regards,
Florian

bug#44455: [ARTWORK] website: Not enough context for translation of None

[pelzflorian (Florian Pelz)]

On Thu, Nov 05, 2020 at 06:51:20PM +0100, Miguel Ángel Arruga Vivas wrote:
> Feel free to push these three together with the one for
> German when you have it ready.

Pushed as fc8ec5409bd3d7221afc2f9feaac4ce36d5c1192 and following.
Thank you for doing the work and thinking it through!

Regards,
Florian

bug#44650: Do not suggest `guix pull --news' after first pull

[pelzflorian (Florian Pelz)]

After doing a `guix pull` on the new VM image
,
the following is displayed:

> hint: Run `guix pull --news' to read all the news.
> 
> hint: After setting `PATH', run `hash guix' to make sure your shell refers to 
> `/home/guest/.config/guix/current/bin/guix'.

The former `guix pull --news` is without effect (it is the very first
time I did a `guix pull`).  It is a no-op.  Users should not get the
suggestion to run `guix pull --news`.


Within (guix scripts pull)’ build-and-install procedure, the value of
(display-channel-news-headlines profile) is .

The attached patch changes it to return #f.  I have verified running
`guix pull --news' is not suggested anymore with it (although I have
not tested if news are still displayed).

It would perhaps be nicer if the news since version 1.2.0 were
displayed, but I do not know how to make it so.  I guess since the
original guix package must come from the guix package in (gnu packages
package-management), it is impossible to determine the version from
which news should be computed.

Regards,
Florian
>From 8da37dc91f2f82da5f1da0ed2b6f0c0602599e5c Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sat, 14 Nov 2020 23:36:52 +0100
Subject: [PATCH] pull: Do not suggest running `guix pull --news' on the first
 run.

* guix/scripts/pull.scm (display-channel-news-headlines): If there
are no news to display, return false instead of .
---
 guix/scripts/pull.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index bb1b560a22..38405fb79d 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -385,7 +385,7 @@ previous generation.  Return true if there are news to 
display."
 (and=> (relative-generation profile -1)
(cut generation-file-name profile <>)))
 
-  (when previous
+  (if previous
 (let ((old-channels (profile-channels previous))
   (new-channels (profile-channels profile)))
   ;; Find the channels present in both PROFILE and PREVIOUS, and print
@@ -405,7 +405,8 @@ previous generation.  Return true if there are news to 
display."
   #:concise? #t)))
 channels))
 
- (any ->bool more?))
+ (any ->bool more?
+#f))
 
 (define (display-news profile)
   ;; Display profile news, with the understanding that this process represents
-- 
2.29.1

bug#44650: Do not suggest `guix pull --news' after first pull

[pelzflorian (Florian Pelz)]

On Sun, Nov 15, 2020 at 02:56:30AM +0100, pelzflorian (Florian Pelz) wrote:
> -  (when previous
> +  (if previous
>  (let ((old-channels (profile-channels previous))
>(new-channels (profile-channels profile)))
>;; Find the channels present in both PROFILE and PREVIOUS, and print
> @@ -405,7 +405,8 @@ previous generation.  Return true if there are news to 
> display."
>#:concise? #t)))
>  channels))
>  
> - (any ->bool more?))
> + (any ->bool more?
> +#f))

I changed the patch to use `and` instead of `if` (attached).  I
confirmed that channel news display fine on a later `guix pull`.

Should I add a copyright line?  I believe no.

Regards,
Florian
>From 8b1557004f618a47d4bea3a65a5b88c4cb718c4c Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sat, 14 Nov 2020 23:36:52 +0100
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] pull: Do not suggest running `guix pull --news' on the first
 run.

* guix/scripts/pull.scm (display-channel-news-headlines): If there
are no news to display, return false instead of .
---
 guix/scripts/pull.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index bb1b560a22..7fd8b3f1a4 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -385,7 +385,7 @@ previous generation.  Return true if there are news to 
display."
 (and=> (relative-generation profile -1)
(cut generation-file-name profile <>)))
 
-  (when previous
+  (and previous
 (let ((old-channels (profile-channels previous))
   (new-channels (profile-channels profile)))
   ;; Find the channels present in both PROFILE and PREVIOUS, and print
-- 
2.29.1

bug#44650: Do not suggest `guix pull --news' after first pull

[pelzflorian (Florian Pelz)]

On Mon, Nov 16, 2020 at 12:35:08PM +0100, Ludovic Courtès wrote:
> Perfect, you can push to ‘version-1.2.0’, thank you!
> 
> Ludo’.

Thank you.  Pushed as 29ed17d6345d30b0646f0a9b63ab201e0e6871ec.  Done.

Regards,
Florian

bug#22952: Backlight brightness keys in GDM and MATE require password authentication

[pelzflorian (Florian Pelz)]

I’m reopening this bug because it is very similar to my issue.

When using my Macbook’s keyboard XF86MonBrightnessUp/Down keys to
adjust screen brightness (probably on non-Macbooks too) in GDM or
MATE, I am asked to enter my authentication password to make
gnome-settings-daemon’s libexec/gsd-backlight-helper (or some
equivalent program on MATE) change screen brightness.

This should not be so; gsd-backlight-helper should have PolicyKit, pam
or setuid or whatever.

Regards,
Florian

bug#22952: Backlight brightness keys in GDM and MATE require password authentication

[pelzflorian (Florian Pelz)]

On Wed, Nov 18, 2020 at 10:14:32PM +0100, Marius Bakke wrote:
> To work around it locally, try adding:
> 
>   (simple-service 'gsd-polkit polkit-service-type
>   (list gnome-settings-daemon))
> 
> to the (services ...) section of your system configuration.

Thank you.  You are correct for GDM.  Adding this fixes changing the
backlight in GDM.  Perhaps the GDM service should extend the polkit
service like that.  It also does not conflict with adding a
gnome-service-type.

MATE still complains.  Without changing services, normally both on the
first log-in to MATE and on subsequent log-ins, when pressing the keys
to change the backlight, a message window still tells me that
/gnu/store/5kmmwc9q23lihpy3nv2knbvsr9qv2aln-mate-power-manager-1.24.2/sbin/mate-power-backlight-helper
needs to be authenticated as the super user; I need to enter the
password.

Only with gnome-service-type and when not removing the GDM service,
after GDM (which uses the gsd), on the first log-in to the MATE
desktop, the backlight keys do nothing at all.  When I try to log out,
it says Power Manager is not responding.  When I force the log-out
despite the Power Manager, then log back in, I again get the message
each time I press the backlight keys.

I added:

(simple-service 'mate-power-polkit polkit-service-type
(list mate-power-manager))

It does not work.

Regards,
Florian

bug#44773: guix pull does not support transformation options but claims to

[pelzflorian (Florian Pelz)]

Running `guix pull --help-transform' displays all the usual
transformation options, but when I try to use any, it reports an
unrecognized option.

It would be nice if I could use `guix pull --without-tests=glib' since
tests time out on my (somewhat slow) Beaglebone Black.

Regards,
Florian

bug#44773: guix pull does not support transformation options but claims to

[pelzflorian (Florian Pelz)]

On Sat, Nov 21, 2020 at 01:09:49AM +0100, pelzflorian (Florian Pelz) wrote:
> It would be nice if I could use `guix pull --without-tests=glib' since
> tests time out on my (somewhat slow) Beaglebone Black.

P.S. --without-tests=glib does not work for 1.2.0 anyway though
because glib was only fixed for core-updates
<https://lists.gnu.org/archive/html/bug-guix/2020-10/msg00060.html>.
I don’t know if fixing `guix pull` transformation options would aid
pulls to core-updates though.

bug#44773: guix pull does not support transformation options but claims to

[pelzflorian (Florian Pelz)]

On Sat, Nov 21, 2020 at 12:43:29PM +0100, Ludovic Courtès wrote:
> Hi,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> 
> > Running `guix pull --help-transform' displays all the usual
> > transformation options, but when I try to use any, it reports an
> > unrecognized option.
> 
> Oops, fixed in e79ecff045094a75226439a6284306475a2f907e.  I’ll
> cherry-pick it in ‘version-1.2.0’.

Thank you!


> Are substitutes for GLib missing?
> 
> Thanks,
> Ludo’.

They are missing on armhf-linux (maybe for months, I am not sure).
guix weather glib shows no substitutes.  I believed it was because of
the getdents issue (bug 44773), I had not followed the mails; other
packages (gnupg for example) have substitutes though.

Regards,
Florian

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

[pelzflorian (Florian Pelz)]

Hello Leo!  Thank you for going through old issues!

So the issue appears to be fixed by commit
de136f3ee7878dea139e751b7e4ca04c2542c91d (from year 2018) making sure
a gschemas.compiled encompassing all packages in a Guix profile gets
created.  Reverting that commit does not print warnings today (I don’t
know why), but still causes choosing one of the packages’
gschemas.compiled over the other.

For normal usage, creating individual, per-package gschemas.compiled
files in glib-or-gtk-build-system probably is *useless*.  Checking the
utility is hard though because I have not found a package that does
not create a per-package gschemas.compiled in their build phase
anyway.

I think the bug is done.  Purging the gschemas.compiled files from all
packages would need to be done in an extra phase for many build
systems (glib-or-gtk build system, cmake build system, meson build
system) that would be useless when a package does not use glib.  It is
difficult.  Also the gschemas.compiled files are small in size.  Some
people maybe even do or could rely on the per-package
gschemas.compiled file in self-written setups that do not use Guix
profiles/environments.

Closing.

Regards,
Florian

bug#34893: Translated manuals refer to wrong substitute server

[pelzflorian (Florian Pelz)]

On Tue, Jan 12, 2021 at 03:21:14PM +0100, Julien Lepiller wrote:
> Le Sun, 17 Mar 2019 14:53:56 +0100,
> "pelzflorian (Florian Pelz)"  a écrit :
> > Where the manual refers to the default substitute server
> > https://ci.guix.info, the translated manuals wrongly use
> > https://ci.guix.fr.info or similar.
>
> Since we don't use the guix.info domain anymore, this should not be an
> issue anymore. I'm closing this issue, but feel free to re-open if you
> think this is still an issue.

Thank you for closing!  I didn’t even see the issue anymore at the one
place where ci.guix.info was still used.

 Ce que montre cet exemple est que ‘kcoreaddons’ et probablement les
 58 paquets qui en dépendent n’ont pas de substituts sur
 ‘ci.guix.info’ ; de même pour ‘qgpgme’ et les 46 paquets qui en
 dépendent.

Anyway I changed that last occurrence of guix.info as
89dbcac107d931fd33eda4a83db445e8a90cc4af.

Regards,
Florian

bug#46663: [Website] 404 redirection on a link in a blog article

[pelzflorian (Florian Pelz)]

On Sat, Feb 20, 2021 at 02:25:03PM +0100, Epholys wrote:
> Hello,
> 
> I want to report a missing resource on the web page:
> https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/
> 
> 
> The link [full graph] redirects to a 404:
> https://guix.gnu.org/en/static/blog/img/gcc-core-mesboot0-graph.svg

Thank you for reporting!  Fixed as
6361ba930f94d7c0f7f0265ff63c97d300c57067.

The website will rebuild soon to include the fix.

Closing.

Regards,
Florian

bug#46663: [Website] 404 redirection on a link in a blog article

[pelzflorian (Florian Pelz)]

On Mon, Feb 22, 2021 at 08:20:43PM +0100, raingloom wrote:
> Is there something that scans the website for broken links? Might be
> worth setting up if not.

You made me check for other broken links using wget on a local build
of the website.  Indeed there were some more broken links.  Thanks!

However I am too lazy to try to set up automatic and continuous broken
link checking.  I think me and others should just be more careful when
moving things around.

Regards,
Florian

bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN, zh'

[pelzflorian (Florian Pelz)]

Hello,

On Mon, Mar 01, 2021 at 11:06:59AM +0100, Ludovic Courtès wrote:
> Florian, could it be that we’re not normalizing language tags
> appropriately?  Does that ring a bell?

Tobias’ analysis likely is correct.  I haven’t yet build a current
berlin virtual machine to test though.

We’re not normalizing language tags at all currently.  Doing URL
redirects in nginx confuses me greatly; I have no idea how to
concisely specify redirects *and* have them execute in the right
order.  The many lines

(redirect "/blog/2006/purely-functional-software-deployment-model" 
"/$lang/blog/2006/purely-functional-software-deployment-model/")

and similar in maintenance.git’s hydra/nginx/berlin.scm file are a bad
solution and are testament to my confusion.  I would not like one line
for each package.

Regards,
Florian

bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN, zh'

[pelzflorian (Florian Pelz)]

On Sat, Feb 27, 2021 at 01:31:40PM +0100, Tobias Geerinckx-Rice via Bug reports 
for GNU Guix wrote:
> I expect that adding it and changing ietf-tags.scm to use "zh-CN" will fix
> both 404s, but need to check that it doesn't break anything else.

I made the tiny change to guix-artwork’s ietf-tags.scm as
04c96a370b8cae48ed162e4414b8950cc65c513b now (sorry for taking so
long):

diff --git a/website/po/ietf-tags.scm b/website/po/ietf-tags.scm
index 32b81ef..5bd22f4 100644
--- a/website/po/ietf-tags.scm
+++ b/website/po/ietf-tags.scm
@@ -10,4 +10,4 @@
  ("de_DE" . "de")
  ("es_ES" . "es")
  ("fr_FR" . "fr")
- ("zh_CN" . "zh-cn"))
+ ("zh_CN" . "zh-CN"))

Note that the prior zh-cn URLs will be broken.

I will play around with nginx’ map directive to make zh-cn and zh
Accept-Language settings direct to the proper URL later, afterwards I
will close this bug.  zh-cn URLs remain invalid.  Links to the manual
continue to use zh-cn.

For testing I dug out the VM code

where I had removed parts of berlin that are not relevant to the
website.  The change breaks neither website nor manual.

Thanks ylc991 for the report!

Regards,
Florian

bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN, zh'

[pelzflorian (Florian Pelz)]

Hello all,

On Mon, Mar 01, 2021 at 11:06:59AM +0100, Ludovic Courtès wrote:
> Florian, could it be that we’re not normalizing language tags
> appropriately?  Does that ring a bell?

The attached patch to maintenance.git fixes the remaining minor issue:
Now Accept-Language language codes get normalized, zh to zh-CN, so web
browsers requesting any kind of Chinese get the website in mainland
Chinese.  (This is a minor issue.  The only valid URL is /zh-CN/ since
my last patch to guix-artwork because I don’t know how to
rewrite/redirect URLs in nginx.)

The patch was tested on a berlin VM.

There is no copyright header in maintenance.git’s
hydra/nginx/berlin.scm so I did not add a copyright.  I hereby license
the patch CC0
.

Shall I just push?  A reconfigure of berlin will be necessary but is
not urgent.

Regards,
FlorianFrom: Florian Pelz 
Date: Thu, 4 Mar 2021 20:29:27 +0100
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] nginx: berlin: Normalize Accept-Language language code zh to
 zh-CN.

Now web browsers requesting any kind of Chinese get the website in
mainland Chinese.

zh, zh-Hans, zh-Hans-CN all are synonymous with zh-CN now.

* hydra/nginx/berlin.scm (accept-languages): New procedure.
(%extra-content): Normalize $lang variable with it.
---
 hydra/nginx/berlin.scm | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/hydra/nginx/berlin.scm b/hydra/nginx/berlin.scm
index 85aaf38..4b9d297 100644
--- a/hydra/nginx/berlin.scm
+++ b/hydra/nginx/berlin.scm
@@ -995,12 +995,37 @@ PUBLISH-URL."
(uri "~ /(.*)")
(body (list "return 301 $scheme://guixwl.org/$1;"
 
+(define (accept-languages language-lists)
+  "Returns nginx configuration code to set up the $lang variable
+according to the Accept-Language header in the HTTP request.  The
+requesting user agent will be served the files at /$lang/some/url.
+Each list in LANGUAGE-LISTS starts with the $lang and is followed by
+synonymous IETF language tags that should be mapped to the same $lang."
+  (define (language-mappings language-list)
+(define (language-mapping language)
+  (string-join (list ""  language (car language-list) ";")))
+(string-join (map language-mapping language-list) "\n"))
+
+  (let ((directives
+ `(,(string-join
+ `("set_from_accept_language $lang_unmapped"
+   ,@(map string-join language-lists)
+   ";"))
+   "map $lang_unmapped $lang {"
+   ,@(map language-mappings language-lists)
+   "}")))
+(string-join directives "\n")))
+
 (define %extra-content
   (list
"default_type  application/octet-stream;"
"sendfileon;"
 
-   "set_from_accept_language $lang en de es fr zh-CN;"
+   (accept-languages '(("en")
+   ("de")
+   ("es")
+   ("fr")
+   ("zh-CN" "zh" "zh-Hans" "zh-Hans-CN")))
 
;; Maximum chunk size to send.  Partly this is a workaround for
;; , but also the nginx docs mention that
-- 
2.30.1

bug#46807: [website] return 404 with HTTP header 'Accept-Language: zh-CN, zh'

[pelzflorian (Florian Pelz)]

Pushed to maintenance.git as 82b075685b6089c7f98acb0993c003936d833776.

Closing.  Thank you all!

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Fri, Apr 16, 2021 at 10:40:55PM -0500, jcguu95 wrote:
>2.2. Unexpected failure
> 
>After running `guix system init /mnt/etc/config.scm /mnt' for 5 to 10
>minutes, I got the error
> 
>,
>|substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
> 0.0%guix substitute: error: TSL error in procedure 'write_to_session_port': 
> Resource temporarily unavailable, try again.
>| 
>|guix system: error: 
> `/gnu/store/1nmwil4cs...vc2p-guix-1.2.0-21.4dff6ec/bin/guix substitute` died 
> unexpectedly
>|root@gnu ~# _
>`
> 
>Retrying it did resolve the problem. And I got a working guix system
>out of it :)

I’ve got the same TLS error (though the procedure for me is
‘write_to_session_record_port’.

I needed to restart the installer at the last step, this stopped while
downloading enlightenment with no error but it does not continue.

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 11:38:56AM +0200, pelzflorian (Florian Pelz) wrote:
> I needed to restart the installer at the last step, this stopped while
> downloading enlightenment with no error but it does not continue.

Note: The last message was

enlightenment-0.24.2  27.0MiB  3.7MiB/s 00:07 
[] 100.0%

But now after maybe 10 minutes it finally continued and died with the
same TLS error about write_to_session_record_port and Resource not
available.

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 11:44:25AM +0200, pelzflorian (Florian Pelz) wrote:
> But now after maybe 10 minutes it finally continued and died with the
> same TLS error about write_to_session_record_port and Resource not
> available.

The error happened while

substitute: updating substitutes from […]

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 11:48:47AM +0200, pelzflorian (Florian Pelz) wrote:
> On Sun, Apr 18, 2021 at 11:44:25AM +0200, pelzflorian (Florian Pelz) wrote:
> > But now after maybe 10 minutes it finally continued and died with the
> > same TLS error about write_to_session_record_port and Resource not
> > available.
> 
> The error happened while
> 
> substitute: updating substitutes from […]

After starting one more time from the last installer step it
downloaded the same enlightenment substitute again and got stuck the
same way.

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 12:15:47PM +0200, Ludovic Courtès wrote:
> Was this in a VM?

No, an Asrock Beebox (real x86_64 hardware).


> Could it be that networking was unstable (e.g., you
> were running this over a flaky WiFi connection)?

It is a stable Ethernet connection.


> How reproducible is
> this?  Any tips on how to reproduce it?
> 
> I did a full bare-bones OS install in a VM, which went fine, but maybe
> that’s not representative of your setup.
> 
> Thanks,
> Ludo’.

The installer completed just now after continuing from the last
install step another time (well with an unrelated error by
grub-install that it could not determine the canonical path of
/boot/efi).  I will try reproducing, but Jin and me both had this
error.

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 01:33:37PM +0200, pelzflorian (Florian Pelz) wrote:
> (well with an unrelated error by
> grub-install that it could not determine the canonical path of
> /boot/efi).

Probably

> I will try reproducing, but Jin and me both had this
> error.

I got the error again with enlightenment.

On IRC Ricardo/rekado suspected
c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa, I will try reverting it.

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sun, Apr 18, 2021 at 02:10:06PM +0200, pelzflorian (Florian Pelz) wrote:
> On IRC Ricardo/rekado suspected
> c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa, I will try reverting it.

It was necessary to revert follow-up commits before reverting
c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa.

I tried on Guix master commit fef2f08bc640f78cc0a86fc7be3eccbc07b5e98c
the following commands:

sed -i '/vi/d' po/packages/LINGUAS #otherwise errors; Julien fixed this by now 
I think
git add po/packages/LINGUAS
git commit -m fixLINGUAS
git revert 2d73086262e1fb33cd0f0f16f74a495fe06b38aa
git revert 673e5276f6b4dda4bfa9dd5bb70220fc8b17abd2
git revert 45fce38fb0b6c6796906149ade145b8d3594c1c6
git revert 9da5ec7099b992a8969a17627548cd341c01bd90
git revert c5ab78f90b111839508d0ab10c0e5ac2038002ca
git revert b48204259aa9cad80c5b23a4060e2d796007ec7a
git revert c37e3b92ad0334ba2fe7ee4e98631f0a4edeee21
git revert 728c90862eb967a1679efdb69e26d7ba37cdc3a3
git revert fd5b77503e852b78a43e1bee4d6bdfbbb1f27e8f
git revert 112692c0d546d35cd67c5dc70dbd1dc609b18f64
git revert ee3226e9d54891c7e696912245e4904435be191c
git revert e2572aa95007558b008f04decff095f46d20e087
git revert 20c08a8a45d0f137ead7c05e720456b2aea44402
git revert 187e97096825d2bcceb144cead6eccc27385acd7
git revert 8116cc66733134a8fb6f9117d4648288b83c8356
git revert b9d058e3f7982eed04cc748cc0b24173a3969c52
git revert 7c85877fdf964694061e3192eac35723ebc047bf
git revert f50f5751fff4cfc6d5abba9681054569694b7a5c
git revert 05f38ca8dccc49d9ec70d1f63461976b97d74d52
git revert 7b812f7c84c43455cdd68a0e51b6ded018afcc8e
git revert f50b501a7472f4f237023831aa415a948115d1d1
git revert 205833b72c5517915a47a50dbe28e7024dc74e57
git revert e2e853ddb0d964e7b0300334ab51ab89950c2376
git revert 87734503a4a1761a4432b601352e5b02340a97f0
git revert 08acee2f98321d57c4faa3ba641a5543b74f10a4
git revert fbd61b5d3de353bfa468641d087bc53aaa1e63a5
git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd
git revert c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa
./bootstrap
./configure --localstatedir=/var
make
GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT=y make update-guix-package
# disabling #:tests? on the guix package was *not* necessary once all reverts 
were in place
make
./pre-inst-env guix system image -t iso9660 gnu/system/install.scm

I dd’d the resulting image to a USB drive and the TLS errors no longer
appear (tried installing everything two times now; without reverts
downloading enlightenment needed retrys everytime).

I suppose if we leave this bug in the new Guix release, then some
substitutes like enlightenment get stuck and fail to download for some
people and therefore the installation fails.  I suspect restarting the
install causes grub-install to fail because it cannot find /boot/efi
anymore, but maybe my grub-install error had other reasons.

I will bisect which reverts are needed, but it takes time …

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Mon, Apr 19, 2021 at 10:05:25AM +0200, pelzflorian (Florian Pelz) wrote:
> I dd’d the resulting image to a USB drive and the TLS errors no longer
> appear (tried installing everything two times now; without reverts
> downloading enlightenment needed retrys everytime).
> […] I suspect restarting the
> install causes grub-install to fail because it cannot find /boot/efi
> anymore, but maybe my grub-install error had other reasons.

No sorry, grub-install still fails, even with no TLS errors no prior
installation restarts.  grub-install failing is an unrelated bug.  I
had not let the install run past the “copying everthing to /mnt” step
last time.

bug#47889: [installer image] grub-install efi fails getting canonical path to /boot/efi on dos-formatted disk

[pelzflorian (Florian Pelz)]

When installing from the Guix install image, grub-install fails on my
x86_64 ASRock Beebox PC:

guix system: error: 
'/gnu/store/hsc3gsqbxkl64nx38sf2fgs2fxzbpr0i-grub-efi-2.04/sbin/grub-install 
--boot-directory /mnt/boot --bootloader-id=Guix --efi-directory /boot/efi' 
exited with status 1; output follows:

 Installing for x86_64-efi platform.
 /gnu/store/hsc3gsqbxkl64nx38sf2fgs2fxzbpr0i-grub-efi-2.04/sbin/grub-install: 
error: failed to get canonical path of `/boot/efi'.

I let the Guix installer (git master commit
fef2f08bc640f78cc0a86fc7be3eccbc07b5e98c) auto-partition my entire
disk without encryption.

“fdisk -l /dev/sda” shows:

Disk /dev/sda: 238.49 GiB, 256060514304 bytes, 500118192 sectors
[…]
Disklabel type: dos
Disk identifier: 0xd0416d83

Device Boot   Start   End   Sectors   Size Id Type
/dev/sda1  2048   7811071   7009024   3.7G 82 Linux swap / Solaris
/dev/sda2  *7011072 500117583 492306432 234.8G 83 Linux

Regards,
Florian

bug#47889: [installer image] grub-install efi fails getting canonical path to /boot/efi on dos-formatted disk

[pelzflorian (Florian Pelz)]

On Mon, Apr 19, 2021 at 11:29:54AM +0200, pelzflorian (Florian Pelz) wrote:
> When installing from the Guix install image, grub-install fails on my
> x86_64 ASRock Beebox PC:

This error occurred on multiple install attempts, but apparently the
last one broke my UEFI; the Beebox can no longer output anything on
the screen.  I will need some time until I can jumper the mainboard.

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Mon, Apr 19, 2021 at 10:05:25AM +0200, pelzflorian (Florian Pelz) wrote:
> I will bisect which reverts are needed, but it takes time …

My UEFI broke; the PC cannot display anything anymore.  Don’t wait for
my debugging.

bug#47889: [installer image] grub-install efi fails getting canonical path to /boot/efi on dos-formatted disk

[pelzflorian (Florian Pelz)]

On Mon, Apr 19, 2021 at 01:27:39PM -0400, Leo Famulari wrote:
> On Mon, Apr 19, 2021 at 11:29:54AM +0200, pelzflorian (Florian Pelz) wrote:
> > When installing from the Guix install image, grub-install fails on my
> > x86_64 ASRock Beebox PC:
> 
> Can you be specific about which install image you used? For example, can
> you provide the URL of the image?

This one:

https://ci.guix.gnu.org/build/175632/details

Same thing happened on an image manually created by running

./pre-inst-env guix system image -t iso9660 gnu/system/install.scm

on commit fef2f08bc640f78cc0a86fc7be3eccbc07b5e98c (after fixing it by
removing the broken “vi” entry from po/packages/LINGUAS which Julien
had only fixed in a later commit).

Regards,
Florian

P.S. I can test again, the PC works again after clearing the CMOS.

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

After flashing the CMOS I can test again.

Without reverts TLS errors happen while or after downloading the
enlightenment substitute from the installer.

With all of those reverts *no* TLS errors happen:

On Mon, Apr 19, 2021 at 10:05:25AM +0200, pelzflorian (Florian Pelz) wrote:
> git revert 2d73086262e1fb33cd0f0f16f74a495fe06b38aa
> git revert 673e5276f6b4dda4bfa9dd5bb70220fc8b17abd2
> git revert 45fce38fb0b6c6796906149ade145b8d3594c1c6
> git revert 9da5ec7099b992a8969a17627548cd341c01bd90
> git revert c5ab78f90b111839508d0ab10c0e5ac2038002ca
> git revert b48204259aa9cad80c5b23a4060e2d796007ec7a
> git revert c37e3b92ad0334ba2fe7ee4e98631f0a4edeee21
> git revert 728c90862eb967a1679efdb69e26d7ba37cdc3a3
> git revert fd5b77503e852b78a43e1bee4d6bdfbbb1f27e8f
> git revert 112692c0d546d35cd67c5dc70dbd1dc609b18f64
> git revert ee3226e9d54891c7e696912245e4904435be191c
> git revert e2572aa95007558b008f04decff095f46d20e087
> git revert 20c08a8a45d0f137ead7c05e720456b2aea44402
> git revert 187e97096825d2bcceb144cead6eccc27385acd7
> git revert 8116cc66733134a8fb6f9117d4648288b83c8356
> git revert b9d058e3f7982eed04cc748cc0b24173a3969c52
> git revert 7c85877fdf964694061e3192eac35723ebc047bf
> git revert f50f5751fff4cfc6d5abba9681054569694b7a5c
> git revert 05f38ca8dccc49d9ec70d1f63461976b97d74d52
> git revert 7b812f7c84c43455cdd68a0e51b6ded018afcc8e
> git revert f50b501a7472f4f237023831aa415a948115d1d1
> git revert 205833b72c5517915a47a50dbe28e7024dc74e57
> git revert e2e853ddb0d964e7b0300334ab51ab89950c2376
> git revert 87734503a4a1761a4432b601352e5b02340a97f0
> git revert 08acee2f98321d57c4faa3ba641a5543b74f10a4
> git revert fbd61b5d3de353bfa468641d087bc53aaa1e63a5
> git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd

The bad commit must be one of those.
c7c7f068c15e419aaf5ef616516aa5ad4e55c2fa is not the problem.

I will bisect tomorrow.

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
> > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd

It seems this is the bad commit.  Downloading the enlightenment
substitute got stuck and after a few minutes displayed the usual TLS
error.

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Tue, Apr 20, 2021 at 05:27:54PM +0200, pelzflorian (Florian Pelz) wrote:
> On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
> > > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd
> 
> It seems this is the bad commit.  Downloading the enlightenment
> substitute got stuck and after a few minutes displayed the usual TLS
> error.

P.S. There are no issues on my Macbook on the same internet
connection, the issue is only with the Beebox PC.

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Tue, Apr 20, 2021 at 02:00:54PM -0400, Leo Famulari wrote:
> On Tue, Apr 20, 2021 at 07:03:26PM +0200, pelzflorian (Florian Pelz) wrote:
> > On Tue, Apr 20, 2021 at 05:27:54PM +0200, pelzflorian (Florian Pelz) wrote:
> > > It seems this is the bad commit.  Downloading the enlightenment
> > > substitute got stuck and after a few minutes displayed the usual TLS
> > > error.
> > 
> > P.S. There are no issues on my Macbook on the same internet
> > connection, the issue is only with the Beebox PC.
> 
> To clarify, you're running the same Guix on both machines, but it only
> fails on one of them?

No sorry I was mistaken, sorry for misguiding you.

I had thought so, but the actions were different on both machines.
Only full installs fail.

Doing a full install with the Enlightenment desktop environment fails
with TLS errors on the Beebox PC.

guix build enlightenment succeeds on the Macbook (with same Guix
commit), but

Running
mount /dev/sda2 /mnt
guile -c '((@ (gnu build install) mount-cow-store) "/mnt" "/tmp/guix-inst")'
guix build enlightenment
succeeds though.  (Without mount-cow-store disk space is insufficient.)

So I will try to do a full reinstall with Enlightenment on the Macbook
now after a backup.

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

Sorry for the slow response.

On Wed, Apr 21, 2021 at 12:38:58AM +0200, Ludovic Courtès wrote:
> Hi Florian,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> > On Tue, Apr 20, 2021 at 03:21:13AM +0200, pelzflorian (Florian Pelz) wrote:
> >> > git revert be5a75ebb5988b87b2392e2113f6590f353dd6cd
> > It seems this is the bad commit.  Downloading the enlightenment
> > substitute got stuck and after a few minutes displayed the usual TLS
> > error.
> Note that on master there have been changes in this area since this
> commit, in particular 20c08a8a45d0f137ead7c05e720456b2aea44402.

I have tested 20c08a in my reverts, it is neither the bad commit nor
does it fix it.
> I assume the error we’re after is still this one:
> 
> >>|substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
> >> 0.0%guix substitute: error: TSL error in procedure 
> >> 'write_to_session_port': Resource temporarily unavailable, try again.

Yes.

> I believe the attached patch “addresses” this problem.

It still gets stuck (sometimes with enlightenment, one time with
udisks, restarting the install fixed it once).  After getting stuck,
this different error message is shown now; no TLS error (copied by
manual typing, there may be typos):

gtk-doc-1.28  653KiB2.4MiB/s 00:00 [] 100.0%
udisks-2.8.4  842KiB1.6MiB/s 00:00 [] 100.0%

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
100.0%Backtrace:
substitute: In ice-9/boot-9.scm:
substitute:   1736:10 17 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In unknown file:
substitute:   16 (apply-smob/0 #)
substitute: In ice-9/boot-9.scm:
substitute: 718:2 15 (call-with-prompt _ _ #)
substitute: In ice-9/eval.scm:
substitute: 619:8 14 (_ #(#(#)))
substitute: In guix/ui.scm:
substitute:   2164:12 13 (run-guix-command _ . _)
substitute: In ice-9/boot-9.scm:
substitute:   1736:10 12 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1736:10 11 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1731:15 10 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In guix/scripts/substitute.scm:
substitute:745:18  9 (_)
substitute:346:26  8 (process-query # _ #:cache-urls _ 
#:acl _)
substitute: In guix/substitutes.scm:
substitute:358:27  7 (lookup-narinfos/diverse _ _ #
substitute:315:31  6 (lookup-narinfos _ _ #:open-connection _ # _)
substitute:238:26  5 (fetch-narinfos _ _ #:open-connection _ # _)
substitute: In ice-9/boot-9.scm:
substitute:   1669:16  4 (raise-exception _ #:continuable? _)
substitute:   1669:16  3 (raise-exception _ #:continuable? _)
substitute:   1764:13  2 (_ #<&compound-exception _ components: 
assertion-fail…>)
substitute:   1669:16  1 (raise-exception _ #:continuable? _)
substitute:   1669:16  0 (raise-exception _ #:continuable? _)
substitute:
substitute: In ice-9/boot-9.scm:1669:16 In procedure raise-exception:
substitute: In procedure %read-line: Wrong type argument in position 1 
(expecting open input port): #
guix system: error: 
`/gnu/store/k3n98i1fk9awd5ydv4ry4k4rlpp7i13m7-guix-1.2.0-22.c467718/bin/guix 
substitute' died unexpectedly

Command failed with exit code 1.
Press Enter to continue.

> Can you reproduce the substitute issue in a simpler environment?
> For instance, by running:
> 
>   rm -rf ~/.cache/guix/substitute/
>   ./pre-inst-env guix weather $(guix package -A |head -2000 |cut -f1) 

Nope, this always works without issue.  Ricardo had written about TLS
errors with 0ad some two or three days ago, but I do not get errors
with 0ad.  The issue is present when installing Enlightenment DE from
the installer on both my Macbook and my Beebox every time, but not
when installing to a VM (but maybe it was just luck)

Regards,
Florian

bug#47889: [installer image] grub-install efi fails getting canonical path to /boot/efi on dos-formatted disk

[pelzflorian (Florian Pelz)]

On Thu, Apr 22, 2021 at 03:28:39PM +0200, Ludovic Courtès wrote:
> There’s no EFI (vfat) partition here.  Is it an EFI machine?
> 
> Is /boot/efi mounted when you boot the installation image?

No because there is no EFI partition.  If I create one and restart the
installer, then it is *not* mounted either, only /mnt/boot/efi later
during the install.  (I believe since the installer is installed as on
an external medium, it does not need an EFI partition.)

I had booted the install image via UEFI boot and had expected auto
partitioning and the default configuration to do the right thing.

> If it were EFI, it would be a GPT partition table, not a DOS one.

Thank you for explaining.  If Guix defaults require GPT on EFI
(according to
)
some computers apparently really do not support dos partition tables
for the EFI system partition), then I think
gnu/installer/newt/partition.scm should disallow selecting a DOS
scheme when auto partitioning the entire disk.

Regards,
Florian

bug#47889: [installer image] grub-install efi fails getting canonical path to /boot/efi on dos-formatted disk

[pelzflorian (Florian Pelz)]

On Fri, Apr 23, 2021 at 12:39:13PM +0200, Ludovic Courtès wrote:
> The installer determines whether it’s doing a UEFI installation like so:
> 
>   (define (efi-installation?)
> "Return #t if an EFI installation should be performed, #f otherwise."
> (file-exists? "/sys/firmware/efi"))
> 
> It uses that to determine whether to create an EFI System Partition
> (ESP) and whether to use ‘grub-efi-bootloader’.
> 
> Did it create an ESP in your case?

No, not on a DOS layout, only on GPT layout.  I think DOS should not
be allowed in auto partitioning (which would be the safer option) or
an ESP should be created on DOS as well.

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

Success!  Thank you.
65;6003;1c
On Fri, Apr 23, 2021 at 11:19:28AM +0200, Ludovic Courtès wrote:
> Florian, could you try again with the attached patch?

It succeeds on two full installs of Enlightenment, no errors, no
prolonged getting stuck.


> If you have the courage, it would be awesome if you could also try the
> patch without the ‘error/again’ bits.

This fails.  I tried with

-(unless (false-if-networking-error
- (begin
-   (for-each (cut write-request <> buffer) batch)
-   (put-bytevector p (get))
-   (force-output p)
-   #t))
-  ;; If PORT becomes unusable, open a fresh connection and retry.
-  (close-port p)  ; close the broken port
-  (connect #f requests result)))
+;; Swallow networking errors that could occur due to connection reuse
+;; and the like; they will be handled down the road when trying to
+;; read responses.
+(false-if-networking-error
+ (begin
+   (for-each (cut write-request <> buffer) batch)
+   (put-bytevector p (get))
+   (force-output p


only and not the rest of your patch, on Guix git master where the full
patch had worked, it fails again with TLS errors (the same error of
Resource temporarily unavailable in procedure
'write_to_session_record_port') after downloading the enlightenment
substitute.


> I double-checked and the GnuTLS Guile bindings already
> handle GNUTLS_E_AGAIN and GNUTLS_E_INTERRUPTED, so my guess is that this
> was just a side effect of dealing with stale TLS sessions:
>   https://gitlab.com/gnutls/gnutls/-/blob/master/guile/src/core.c#L1042

Strange,.

Regards,
Florian

bug#47889: [installer image] grub-install efi fails getting canonical path to /boot/efi on dos-formatted disk

[pelzflorian (Florian Pelz)]

Hello Bengt,

On Sat, Apr 24, 2021 at 05:24:26AM +0200, Bengt Richter wrote:
> How does that work if you want to mount an external USB disk as the target
> of your installation partitioning and formatting etc, but which may be 
> intended
> for another laptop with a different BIOS booting in a different mode than your
> installer was booted into? (Maybe plug the finished USB disk into another 
> laptop?
> USB C3.1 is fast enough if connected to a good SSD cassette).

Do we want to support such rare use cases in the default
configuration?  Currently the configuration created by the installer
assumes you want to install to the same boot mode (UEFI or “legacy”
BIOS) as was selected when booting the installer.  This means that if
your computer only supports one or the other, you have no choice.  It
does not depend on what’s on the disk.

Also, in UEFI mode, the grub-efi-bootloader from
gnu/bootloader/grub.scm would need to be copied and adapted to add the
--removable option if you want to install to a removable USB in UEFI
mode.  This is because grub-efi-bootloader otherwise writes boot
information into your BIOS’s NVRAM on the mainboard of the computer
doing the install.

Regards,
Florian

bug#47867: [1.2.1 pre-release testing] substitute downloading and TLS errors

[pelzflorian (Florian Pelz)]

On Sat, Apr 24, 2021 at 07:13:01PM +0200, Ludovic Courtès wrote:
> I’ve pushed these as two separate patches:
> 
>   c50db7156d http-client: Remove exception mishandling in 'http-multiple-get'.
>   02d62978f4 http-client, substitute: Gracefully handle GnuTLS EAGAIN/EINTR.

I assume they will be cherry-picked to the version-1.3.0 branch and
the guix package will be updated.

> This bug should be gone now.

Yes, after and only after locally updating the guix package I can
create good installer images.

Closing.

Note though that "Guu, Jin-Cheng"  reported the TLS
errors before me, but to guix-devel and not as a bug report.

> I’ll go ahead and fix ‘write_to_session_record_port’ in GnuTLS.

Thank you for all the work!

Regards,
Florian

bug#47889: [installer image] grub-install efi fails getting canonical path to /boot/efi on dos-formatted disk

[pelzflorian (Florian Pelz)]

On Sun, Apr 25, 2021 at 04:15:56PM +0200, Mathieu Othacehe wrote:
> Finally, grub-efi fails because there's no /boot/efi mount point.
> 
> This problem can then occur for two reasons:
> 
> 1. The user is booting the installation image with UEFI support, using
>   an empty installation device, choosing auto-partition and msdos as
>   disk type.
> 
> 2. The user is booting the installation image with UEFI support, using
>   an already msdos formatted installation device and choosing
>   auto-partition.
> 
> I think we could solve 1. easily, by forcing the GPT layout. Solving
> 2. is a bit trickier.

Can you force GPT also in 2.?  All disk partitions get removed anyway.
Arch wiki says MSDOS layout does not work on all EFI systems
.

Regards,
Florian

bug#47889: [installer image] grub-install efi fails getting canonical path to /boot/efi on dos-formatted disk

[pelzflorian (Florian Pelz)]

On Sun, Apr 25, 2021 at 07:12:39PM +0200, Mathieu Othacehe wrote:
> 
> Hello Florian,
> 
> > Can you force GPT also in 2.?  All disk partitions get removed anyway.
> > Arch wiki says MSDOS layout does not work on all EFI systems
> > .
> 
> Well I'm not sure, if someone has an MSDOS partition table with an ESP
> partition it wouldn't be a good idea to wipe it.

You are right of course; the old ESP may contain boot information for
other disks or network boot or whatever.


> The attached patch forces GPT if there's no partition table, and will
> preserve/create an ESP partition on an MSDOS/EFI setup. I'm testing it
> on various machines, seems to work fine.

Thank you for this patch!!  It installs EFI on msdos layout
successfully on my Beebox PC.  That said, it could force GPT on msdos
layouts as well if they lack an ESP.  But I’m already happy.

Regards,
Florian

bug#39341: Installer using 100% of a CPU core

[pelzflorian (Florian Pelz)]

On Sun, Apr 25, 2021 at 11:41:59PM +0200, Ludovic Courtès wrote:
65;6003;1c> I’ve verified that keymap choices in the installer are honored, 
that you
> can change anytime via the F1 menu, and that there’s no file descriptor
> leak in the kmscon process.

Keyboard layout selection completely broke for me, I will check again
later if the mistake is on my part.

Regards,
Florian

bug#39341: Installer using 100% of a CPU core

[pelzflorian (Florian Pelz)]

On Mon, Apr 26, 2021 at 06:07:33PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> 
> > On Sun, Apr 25, 2021 at 11:41:59PM +0200, Ludovic Courtès wrote:
> > 65;6003;1c> I’ve verified that keymap choices in the installer are honored, 
> > that you
> >> can change anytime via the F1 menu, and that there’s no file descriptor
> >> leak in the kmscon process.
> >
> > Keyboard layout selection completely broke for me, I will check again
> > later if the mistake is on my part.
> 
> How did you test?
> 
> I made the initial choice in the early menu and later modified it by
> pressing F1 and “Change keyboard layout”.
> 
> Ludo’.

I selected the layout to be Amharic (or anything else, even QWERTZ
Deutsch/German) both directly and via F1.  Keyboard layout of the same
image (guix git master, with updated guix package) works on QEMU and
fails on real hardware where an old image worked.

Regards,
Florian

bug#39341: Installer using 100% of a CPU core

[pelzflorian (Florian Pelz)]

On Tue, Apr 27, 2021 at 12:38:23PM +0200, Ludovic Courtès wrote:
> What do you mean by “fails on real hardware”?  That the keyboard layout
> is unchanged?

Yes.


> Is there anything in /var/log/messages

No, nothing out of the ordinary, only the installer pages I went
through.

> or wherever kmscon
> writes its logs?

I try with

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index 24b3ea785b..0eff24828c 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -2330,6 +2330,7 @@ This service is not part of @var{%base-services}."
 
(define kmscon-command
  #~(list
+#$(file-append strace "/bin/strace") "-o" "/var/log/kmscon-out" 
"-f"
 #$(file-append kmscon "/bin/kmscon") "--login"
 "--vt" #$virtual-terminal
 "--no-switchvt" ;Prevent a switch to the virtual terminal.

I do

cat /var/log/kmscon-out | grep keymap-update

I see

231   unlink("/tmp/kmscon-231-keymap-update") = -1 ENOENT (No such file or 
directory)
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
17
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
20
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
23
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
26
259   stat("/tmp/kmscon-231-keymap-update", {st_mode=S_IFIFO|0700, st_size=0, 
...}) = 0
259   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", 
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 19
259   lstat("/tmp/kmscon-231-keymap-update", {st_mode=S_IFIFO|0700, st_size=0, 
...}) = 0
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
26
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
18
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
21
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
24


Now I checked again; after going back to the installer via
Ctrl-Alt-F1, I can actually type Amharic.  Maybe it just took a long
time?  But it does not change back to English.

I have more lines in kmscon-out by now

231   unlink("/tmp/kmscon-231-keymap-update") = -1 ENOENT (No such file or 
directory)
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
17
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
20
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
23
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
26
259   stat("/tmp/kmscon-231-keymap-update", {st_mode=S_IFIFO|0700, st_size=0, 
...}) = 0
259   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", 
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 19
259   lstat("/tmp/kmscon-231-keymap-update", {st_mode=S_IFIFO|0700, st_size=0, 
...}) = 0
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
26
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
18
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
21
231   unlink("/tmp/kmscon-231-keymap-update") = 0
231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) = 
24
259   stat("/tmp/kmscon-231-keymap-update", {st_mode=S_IFIFO|0700, st_size=0, 
...}) = 0
259   openat(A

bug#39341: Installer using 100% of a CPU core

[pelzflorian (Florian Pelz)]

Hello Bengt,

On Tue, Apr 27, 2021 at 07:43:56PM +0200, Bengt Richter wrote:
> Perhaps this old bug in some form?
> https://bugzilla.gnome.org/show_bug.cgi?id=776570
> and solution linked from there might help?
> http://unix.stackexchange.com/questions/68

No, I believe it is unrelated to the old bug
 when I changed kmscon, since

- this affects the layout switch at the start of the installer or
  when pressing F1 (Alt+Shift is unrelated, I should not have
  mentioned it),

- reverting Ludo’s fix d904abe0768 to the original bug makes layout
  selection work again (but causes the original bug 100% CPU usage)

- German keyboard layout is affected too, even though it does not use
  Alt+Shift toggleing, and

- apparently even with Ludo’s d904abe0768 the layout switch from the
  start of the installer can still be triggered somehow, since
  keyboard layout eventually switched to Amharic, but I don’t know how
  I triggered it last time.

Regards,
Florian

bug#39341: Installer using 100% of a CPU core

[pelzflorian (Florian Pelz)]

Hi Ludo,

On Tue, Apr 27, 2021 at 11:26:41PM +0200, Ludovic Courtès wrote:
> I tried this in ‘guix system vm gnu/system/install.scm’.  I proceed like
> so:
> 
>   1. after the installer’s welcome screen I choose French layout;
>   2. the next dialog is the host name, which is where I confirm I really
>  got French layout;

At the host name dialog, I still have QWERTY layout, on both my Beebox
and my Macbook.  I can however switch in QEMU on the same Macbook.  Oh
and I just noticed now; the same USB drive does switch layouts on my
fastest machine.  All are UEFI.

>   3. from there I press F1, choose German layout, confirm by typing into
>  the host name dialog that I got German layout;

No effect, I still got QWERTY layout.

>   4. I repeat step #3 with a variety of layouts.

Same.


> Changing layouts there just works and is instantaneous.  (Note that this
> only changes the layout of kmscon, so tty3 & co. are unaffected.)
> 
> The strace log shows this when changing layouts (FD 17 corresponds to
> /tmp/kmscon-165-keymap-update, the FIFO node):
> 
> --8<---cut here---start->8---
> 165   epoll_wait(3, [{EPOLLIN, {u32=17731792, u64=17731792}}, 
> {EPOLLIN|EPOLLHUP, {u32=18285248, u64=18285248}}, {EPOLLIN, {u32=17639536, 
> u64=17639536}}], 32, -1) = 3
> 165   epoll_wait(12, [{EPOLLIN, {u32=17678528, u64=17678528}}], 32, 0) = 1
> 165   read(20, "\33[5;22H\33[44m\33[K\33[6;22H\33[K\33[7;22H"..., 16384) = 
> 1657
> 165   read(20, 0x10f6c28, 16384)= -1 EAGAIN (Resource temporarily 
> unavailable)
> 165   read(17, "p", 1)  = 1
> 165   read(17, "c", 1)  = 1
> 165   read(17, "1", 1)  = 1
> 165   read(17, "0", 1)  = 1
> 165   read(17, "5", 1)  = 1
> 165   read(17, "\0", 1) = 1
> 165   read(17, "f", 1)  = 1
> 165   read(17, "r", 1)  = 1
> 165   read(17, "\0", 1) = 1
> 165   read(17, "\0", 1) = 1
> 165   read(17, "\0", 1) = 1
> 165   read(17, "", 1)   = 0
> 165   
> stat("/gnu/store/m734r6j7g74x9k74sgjb8835pg7dnqbk-libxkbcommon-1.0.3/etc/xkb",
>  0x7fff179314b0) = -1 ENOENT (No such file or directory)
> 165   
> stat("/gnu/store/qz3zdrz12rxawlkvah9qjhjyf6fh1v98-xkeyboard-config-2.31/share/X11/xkb",
>  {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0

Yes i do have this output too:

231   epoll_wait(3, [{EPOLLIN, {u32=8232720, u64=8232720}}, {EPOLLIN|EPOLLHUP, 
{u32=8124896, u64=8124896}}], 32, -1) = 2
231   epoll_wait(12, [{EPOLLIN, {u32=8182976, u64=8182976}}], 32, 0) = 1
231   read(29, "\33[5;67H\33[44m\33[K\33[6;67H\33[K\33[7;67H"..., 16384) = 1833
231   read(29, 0x7fc4f8, 16384) = -1 EAGAIN (Resource temporarily 
unavailable)
231   read(26, "p", 1)  = 1
231   read(26, "c", 1)  = 1
231   read(26, "1", 1)  = 1
231   read(26, "0", 1)  = 1
231   read(26, "5", 1)  = 1
231   read(26, "\0", 1) = 1
231   read(26, "f", 1)  = 1
231   read(26, "r", 1)  = 1
231   read(26, "\0", 1) = 1
231   read(26, "\0", 1) = 1
231   read(26, "\0", 1) = 1
231   read(26, "", 1)   = 0
231   
stat("/gnu/store/m734r6j7g74x9k74sgjb8835pg7dnqbk-libxkbcommon-1.0.3/etc/xkb", 
0x7fff282d66b0) = -1 ENOENT (No such file or directory)
231   
stat("/gnu/store/qz3zdrz12rxawlkvah9qjhjyf6fh1v98-xkeyboard-config-2.31/share/X11/xkb",
 {st_mode=S_IFDIR|0555, st_size=2048, ...}) = 0
231   
stat("/gnu/store/qz3zdrz12rxawlkvah9qjhjyf6fh1v98-xkeyboard-config-2.31/share/X11/xkb",
 {st_mode=S_IFDIR|0555, st_size=2048, ...}) = 0




> 
> [...]
> 
> 165   openat(AT_FDCWD, 
> "/gnu/store/qz3zdrz12rxawlkvah9qjhjyf6fh1v98-xkeyboard-config-2.31/share/X11/xkb/symbols/inet",
>  O_RDONLY) = 22
> 165   fstat(22, {st_mode=S_IFREG|0444, st_size=64040, ...}) = 0
> 165   mmap(NULL, 64040, PROT_READ, MAP_SHARED, 22, 0) = 0x7f50d23b5000
> 165   brk(0x12bb000)= 0x12bb000
> 165   munmap(0x7f50d23b5000, 64040) = 0
> 165   close(22) = 0
> 165   epoll_ctl(3, EPOLL_CTL_DEL, 17, NULL) = 0
> 165   close(17) = 0
> 165   getpid()  = 165
> 165   unlink("/tmp/kmscon-165-keymap-update") = 0
> 165   mknod("/tmp/kmscon-165-keymap-update", S_IFIFO|0700) = 0
> 165   openat(AT_FDCWD, "/tmp/kmscon-165-keymap-update", O_RDONLY|O_NONBLOCK) 
> = 17
> 165   epoll_ctl(3, EPOLL_CTL_ADD, 17, {EPOLLIN, {u32=19410896, 
> u64=19410896}}) = 0
> --8<---cut here---end--->8---
> 
> The last lines show that we delete the FIFO from the poll set, close the
> FIFO, recreate it, and re-add it to the poll set.

I got:

231   openat(AT_FDCWD, 
"/gnu/store/qz3zdrz12rxawlkvah9qjhjyf6fh1v98-xkeyboard-config-2.31/share/X11/xkb/symbols/inet",
 O_RDONLY) = 31
231 

bug#39341: Installer using 100% of a CPU core

[pelzflorian (Florian Pelz)]

On Wed, Apr 28, 2021 at 09:02:10AM +0200, pelzflorian (Florian Pelz) wrote:
> On Tue, Apr 27, 2021 at 11:26:41PM +0200, Ludovic Courtès wrote:
> > 165   openat(AT_FDCWD, 
> > "/gnu/store/qz3zdrz12rxawlkvah9qjhjyf6fh1v98-xkeyboard-config-2.31/share/X11/xkb/symbols/inet",
> >  O_RDONLY) = 22
> > 165   fstat(22, {st_mode=S_IFREG|0444, st_size=64040, ...}) = 0
> > 165   mmap(NULL, 64040, PROT_READ, MAP_SHARED, 22, 0) = 0x7f50d23b5000
> > 165   brk(0x12bb000)= 0x12bb000
> > 165   munmap(0x7f50d23b5000, 64040) = 0
> > 165   close(22) = 0
> > 165   epoll_ctl(3, EPOLL_CTL_DEL, 17, NULL) = 0
> > 165   close(17) = 0
> > 165   getpid()  = 165
> > 165   unlink("/tmp/kmscon-165-keymap-update") = 0
> > 165   mknod("/tmp/kmscon-165-keymap-update", S_IFIFO|0700) = 0
> > 165   openat(AT_FDCWD, "/tmp/kmscon-165-keymap-update", 
> > O_RDONLY|O_NONBLOCK) = 17
> > 165   epoll_ctl(3, EPOLL_CTL_ADD, 17, {EPOLLIN, {u32=19410896, 
> > u64=19410896}}) = 0
> > --8<---cut here---end--->8---
> > 
> > The last lines show that we delete the FIFO from the poll set, close the
> > FIFO, recreate it, and re-add it to the poll set.
> 
> I got:
> 
> 231   openat(AT_FDCWD, 
> "/gnu/store/qz3zdrz12rxawlkvah9qjhjyf6fh1v98-xkeyboard-config-2.31/share/X11/xkb/symbols/inet",
>  O_RDONLY) = 31
> 231   fstat(31, {st_mode=S_IFREG|0444, st_size=64040, ...}) = 0
> 231   mmap(NULL, 64040, PROT_READ, MAP_SHARED, 31, 0) = 0x7f1b1f5c7000
> 231   munmap(0x7f1b1f5c7000, 64040) = 0
> 231   close(31) = 0
> 231   epoll_ctl(3, EPOLL_CTL_DEL, 26, NULL) = 0
> 231   close(26) = 0
> 231   getpid()  = 231
> 231   unlink("/tmp/kmscon-231-keymap-update") = 0
> 231   mknod("/tmp/kmscon-231-keymap-update", S_IFIFO|0700) = 0
> 231   openat(AT_FDCWD, "/tmp/kmscon-231-keymap-update", O_RDONLY|O_NONBLOCK) 
> = 26
> 231   epoll_ctl(3, EPOLL_CTL_ADD, 26, {EPOLLIN, {u32=9609568, u64=9609568}}) 
> = 0
> 231   epoll_wait(3, [{EPOLLIN, {u32=8123856, u64=8123856}}], 32, -1) = 1
> 231   read(14, "\2\0\0\0 
> \0\0\\373{\0\0\0\0\0\326\0\0\0^\335\t\0\347,\0\0]\0\0\0", 1024) = 32
> 231   ioctl(14, DRM_IOCTL_MODE_PAGE_FLIP, 0x7fff282d6b50) = 0
> 
> Slightly different.  This is the next occurrence after the pci05\0fr.

The brk does happen, just later, if it is important.

Regards,
Florian

bug#39341: Installer using 100% of a CPU core

[pelzflorian (Florian Pelz)]

On Wed, Apr 28, 2021 at 03:43:06PM +0200, Ludovic Courtès wrote:
> Hmm I don’t know what to think.  Could you confirm that keyboard
> switching works if you revert d904abe0768293b2322dbf355b6e41d94e769d78?

Yes, revert fixes it but goes back to 100% CPU usage.

Note that layout switching works on QEMU for me and bare-metal only
fails on some of my machines.

Regards,
Florian

bug#39341: Installer using 100% of a CPU core

[pelzflorian (Florian Pelz)]

On Thu, Apr 29, 2021 at 11:33:17AM +0200, Mathieu Othacehe wrote:
> Conveniently, that input was always the main user keyboard I guess. The
> attached patch fixes that issue […]

Aha!  Thank you.

This patch fixed it on my Beebox PC.  Note that my Beebox only ever
had a single input device: a USB keyboard.

Now I can also confirm how before your fix, Mathieu, I triggered the
keyboard layout switch the one time it did actually switch: By
unplugging and replugging my USB keyboard.  Then it used the new
layout.  (When I use another computer, I take the keyboard to the new
computer, that is why I did that.)

Regards,
Florian

bug#39970: guix commands broken on Azerbaijani 'az_AZ' and Turkish 'tr_TR' locales

[pelzflorian (Florian Pelz)]

On Wed, May 05, 2021 at 12:47:02AM -0400, Maxim Cournoyer wrote:
> Closing.
> 
> Thank you,
> 
> Maxim

Sorry for forgetting about this bug.  The above

LC_ALL=tr_TR.utf8 make check TESTS=tests/cran.scm

is *not* fixed, but I won’t take the time to really understand and fix
the few remaining troubles, I think.  Possibly libc bug
 is the real
issue.

Regards,
Florian

bug#48343: Cannot boot after installation

[pelzflorian (Florian Pelz)]

On Wed, May 12, 2021 at 03:33:51PM -0400, Bone Baboon via Bug reports for GNU 
Guix wrote:
> Sergey Petrov writes:
> > but terminal only, my WM (Enlightenment) cannot initialize. I think I
> > can give a try to some other WMs and check how it goes.
> 
> You may find this has useful information in regards to getting a
> graphical environment working:
> https://lists.gnu.org/archive/html/help-guix/2021-04/msg00220.html

Another WM would be the leaner solution, however maybe uvesafb (which
is also used in the installer image) can help you set up GNOME etc.:

https://lists.gnu.org/archive/html/bug-guix/2020-04/msg00320.html

Regards,
Florian

bug#33678: Locale problems

[pelzflorian (Florian Pelz)]

On Sat, Dec 08, 2018 at 10:35:51PM +0100, Danny Milosavljevic wrote:
> Can we do something against the locale problems that keep showing up
> when updating?
> 
> Right now, after a half-finished update from guix master (half-finished 
> because
> once any package build breaks, the entire update will stop), I cannot use any
> Umlauts because "xterm -u8" stops working as it should:
> $ xterm -u8
> Warning: locale not supported by C library, locale unchanged
> $
> 
> Why does this keep happening?  Shouldn't the functional nature and modularity
> of Guix keep using the old locales where those make sense and the new locales
> where those make sense?
> 
> Environment:
> 
> $ locale -a
> locale: Cannot set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_COLLATE to default locale: No such file or directory

Is this only on foreign distros?  I cannot reproduce this in a Guix VM.

These errors occurred for me on the foreign distro Debian also for
Debian commands like localectl because the locale command was taken
from a glibc in root’s guix profile.  I uninstalled the glibc package
and now Debian’s locale commands work again.  `strace locale` made it
seem like the directory for the de_DE.UTF-8 locale was never checked
by the locale program, only de_DE.utf8 and others, which apparently
are not what Debian uses.

Regards,
Florian

bug#33892: guix package --list-generations uses UTC and time-at-midnight for hour durations

[pelzflorian (Florian Pelz)]

Hello Guix,

I would expect guix package --list-generations=…h to display
generations from the past … hours, but apparently it displays
generations offset from UTC midnight (apparently not local time?) and
not the current time, since guix/ui.scm calls a procedure named
time-at-midnight.

In particular, when `guix package --list-generations` shows

Generation 38   Dec 15 2018 13:04:16(current)

then I would expect

$ date --date="Dec 15 2018 13:04:16" +%s
1544875456
$ date +%s
1545989113
$ guix package --list-generations=$(((1545989113-1544875456)/3600+1))h

to display the current generation.

I think either the time for hours should not be computed from midnight
and should use local time for days/weeks.  Alternatively, the
description in the manual should be adjusted.

Regards,
Florian

bug#33894: Guix manual PO file uses same translation msgid ``channels'' for different uses

[pelzflorian (Florian Pelz)]

Hello,

The Guix manual POT file 0.16.0.1 submitted to the Translation Project
has these lines:

#. type: item
#: doc/guix.texi:2919 doc/guix.texi:3279
#, no-wrap
msgid "channels"
msgstr ""

However, doc/guix.texi:2919 is a cindex which should be translated and
doc/guix.texi:3279 is a table item which describes syntax that must
not be translated.

I am not sure

· if this is a bug in PO4A (it could detect that one of them is a
  cindex and the other is not and then use something like a msgctxtid
  as in
  https://gitlab.gnome.org/GNOME/glib/raw/master/glib/ggettext.c
  or _C in https://developer.gnome.org/glib/stable/glib-I18N.html
  )

· or this term should somehow be specified to PO4A as an exception

· or the cindex term could be changed.

Regards,
Florian

bug#34498: Confusing msgid " Running value is ~s.~%"

[pelzflorian (Florian Pelz)]

Hello,

I am fairly sure

#: modules/shepherd/scripts/herd.scm:86
#, scheme-format
msgid "  Running value is ~s.~%"

refers to the value of the #:running slot but translators don’t know
that and would translate it as a value that is running.  This should
be changed and a comment for TRANSLATORS should be added.

Regards,
Florian

bug#34574: Confusing manual entry for gexp->file

[pelzflorian (Florian Pelz)]

Hello,

The Guix manual contains the following description of gexp->file:

 -- Monadic Procedure: gexp->file NAME EXP [#:set-load-path? #t]
  [#:module-path %load-path]  [#:splice? #f]  [#:guile
 (default-guile)] Return a derivation that builds a file NAME
 containing EXP. When SPLICE? is true, EXP is considered to be a
 list of expressions that will be spliced in the resulting file.

 When SET-LOAD-PATH? is true, emit code in the resulting file to set
 ‘%load-path’ and ‘%load-compiled-path’ to honor EXP’s imported
 modules. Look up EXP’s modules in MODULE-PATH.

 The resulting file holds references to all the dependencies of EXP
 or a subset thereof.

I do not understand this last sentence.  How can it be a subset?  A
subset of what?  Can this be explained more clearly or removed?

Regards,
Florian

bug#34574: Confusing manual entry for gexp->file

[pelzflorian (Florian Pelz)]

On Wed, Mar 06, 2019 at 02:17:49PM +0100, Ludovic Courtès wrote:
> Hi Florian,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> 
> > The Guix manual contains the following description of gexp->file:
> >
> >  -- Monadic Procedure: gexp->file NAME EXP [#:set-load-path? #t]
> >   [#:module-path %load-path]  [#:splice? #f]  [#:guile
> >  (default-guile)] Return a derivation that builds a file NAME
> >  containing EXP. When SPLICE? is true, EXP is considered to be a
> >  list of expressions that will be spliced in the resulting file.
> >
> >  When SET-LOAD-PATH? is true, emit code in the resulting file to set
> >  ‘%load-path’ and ‘%load-compiled-path’ to honor EXP’s imported
> >  modules. Look up EXP’s modules in MODULE-PATH.
> >
> >  The resulting file holds references to all the dependencies of EXP
> >  or a subset thereof.
> >
> > I do not understand this last sentence.  How can it be a subset?  A
> > subset of what?  Can this be explained more clearly or removed?
> 
> It can be a subset of the references of EXP because, when a build
> completes, the daemon scan the output(s) to determine the set of
> residual references.  That’s the difference between build-time and
> run-time dependencies.
> 
> For instance, ‘sed’ depends on ‘gcc’ and ‘gcc:lib’ at build time, but
> its output depends only on ‘gcc:lib’.
> 
> Does that make sense?
> 
> Ludo’.

Thank you.  I did not know this is how the daemon determines outputs’
references.  In this case I would understand the manual more easily if
it said:

The output(s) resulting from this derivation will be scanned for
references by the daemon.  They can hold references to all the
dependencies of EXP or a subset thereof.

Please make this more clear in the manual.

Regards,
Florian

bug#34893: Translated manuals refer to wrong substitute server

[pelzflorian (Florian Pelz)]

Where the manual refers to the default substitute server
https://ci.guix.info, the translated manuals wrongly use
https://ci.guix.fr.info or similar.

This is because at the top of doc/guix.texi it says

@set SUBSTITUTE-SERVER ci.guix.info

which is wrongly replaced by something like

@set SUBSTITUTE-SERVER ci.guix.fr.info

in doc/guix.fr.texi.


I believe this is because doc/local.mk has the following code:

$(srcdir)/%D%/guix.%.texi: po/doc/guix-manual.%.po 
$(srcdir)/%D%/contributing.%.texi
-$(AM_V_PO4A)$(PO4A_TRANSLATE) $(PO4A_PARAMS) -m "%D%/guix.texi" -p 
"$<" -l "$@.tmp"
-sed -i "s|guix\.info|$$(basename "$@" | sed 's|texi$$|info|')|" 
"$@.tmp"
-$(AM_V_POXREF)$(xref_command)
-mv "$@.tmp" "$@"


Please change either the line “@set SUBSTITUTE-SERVER ci.guix.info” to
use escape sequences so it is not affected by the local.mk code, or
change the local.mk code somehow.

Regards,
Florian

bug#34955: Manual: Service extensions not clear

[pelzflorian (Florian Pelz)]

The Guix manual (section Defining services) says about service
extensions:

[The example guix-service-type definition] defines three things:

  1. […]

  2. A list of “service extensions”, where each extension designates the
 target service type and a procedure that, given the parameters of
 the service, returns a list of objects to extend the service of
 that type.

 Every service type has at least one service extension.  The only
 exception is the “boot service type”, which is the ultimate
 service.

This is confusing to me because previously it was explained that
services extend services but now it says types extend types which does
not fit the previous explanation.

Later it says:

   There can be only one instance of an extensible service type such as
UDEV-SERVICE-TYPE.  If there were more, the ‘service-extension’
specifications would be ambiguous.

I believe before the example for the definition of service types,
service extensions should be explained.

E.g.

A service type definition specifies which services can be extended by
an instance of the service type.  For each service extension, exactly
one service of the target service type of the extension must appear
in the services field of the operating-system declaration.

Regards,
Florian

bug#35136: Git master installer disk-image has GPT PMBR size mismatch

[pelzflorian (Florian Pelz)]

Since commit 45c0d1d790f01ebc020fc4b2787a6abcdaa3f383 all install ISOs
created with

guix system disk-image --file-system-type=iso9660 gnu/system/install.scm

cannot boot for me, see

https://lists.gnu.org/archive/html/guix-devel/2019-04/msg00061.html


fdisk reports this:

florian@florianmacbook ~ [env]$ fdisk g1.iso # commit 
391e0d65d7129d53c025963d2758724e75626eb4

Welcome to fdisk (util-linux 2.32.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): q

florian@florianmacbook ~ [env]$ fdisk g2.iso # commit 
45c0d1d790f01ebc020fc4b2787a6abcdaa3f383

Welcome to fdisk (util-linux 2.32.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

GPT PMBR size mismatch (3230583 != 3200895) will be corrected by write.

Command (m for help): q

bug#35136: Git master installer disk-image has GPT PMBR size mismatch

[pelzflorian (Florian Pelz)]

On Thu, Apr 04, 2019 at 07:33:17AM +0200, pelzflorian (Florian Pelz) wrote:
> guix system disk-image --file-system-type=iso9660 gnu/system/install.scm
> 

This only happens when specifying --file-system-type=iso9660.

bug#35136: Git master installer disk-image has GPT PMBR size mismatch

[pelzflorian (Florian Pelz)]

I would like to log the commandline with which parted is executed in
initialize-partition-table in gnu/build/vm.scm, but I do not know
where all the output is going.  Apparently it is nowhere in the logs.

bug#35136: Git master installer disk-image has GPT PMBR size mismatch

[pelzflorian (Florian Pelz)]

On Fri, Apr 05, 2019 at 07:57:06AM +0200, pelzflorian (Florian Pelz) wrote:
> I would like to log the commandline with which parted is executed in
> initialize-partition-table in gnu/build/vm.scm, but I do not know
> where all the output is going.  Apparently it is nowhere in the logs.
> 
> 
> 

I was wrong; grub-mkrescue in gnu/build/vm.scm creates the ISO9660
partition table, not parted.  It appears I can get at its commandline
by reconfiguring with a modified grub package that raises an error
containing the commandline.  I will try later.

bug#35136: Git master installer disk-image has GPT PMBR size mismatch

[pelzflorian (Florian Pelz)]

This seems to be a duplicate of https://issues.guix.info/issue/33639
, I think, but it happens to me on x86_64.

bug#33639: ISO installer image is broken on i686

[pelzflorian (Florian Pelz)]

I have what may be the same problem on my x86_64 machine building for
x86_64 when creating an ISO install image by running

guix system disk-image --file-system-type=iso9660 gnu/system/install.scm

Since commit 45c0d1d790f01ebc020fc4b2787a6abcdaa3f383 increased the
RAM for the VM that builds the iso image from 256 to 512, iso files
consistently were corrupt, until I added an lstat call, see below.  On
a second and third attempt to build with lstat I got a corrupt image
again.  Guix install iso files I tested from before that commit were
fine.


florian@florianmacbook ~$ fdisk 
/gnu/store/4nrwajlpab4s8pdph4d77ww7716sa3ir-image.iso
[…]
GPT PMBR size mismatch (3231107 != 3200391) will be corrected by write.

xorriso is sorry exactly like in Ludo’s message from December 06.  The
numbers reported and file sizes are not consistent between corrupt
rebuilds.



On Fri, Dec 21, 2018 at 10:42:14PM +0100, Thomas Schmitt wrote:
> […]
> Next time you make an ISO, retrieve the last size messages of xorriso:
>   ISO image produced: 500069 sectors
>   Written to medium : 500069 sectors at LBA 0

For the corrupt iso with lstat call:

ISO image produced: 80 sectors
Written to medium : 80 sectors at LBA 0



> the new message about the ISO image file size in bytes,

Within the VM lstat consistently reports 1654327296 for non-corrupt
and corrupt images alike.



> and the size of
> the ISO image file size when it is finally ready for exposure in the web.
>

ls -l on the result reports 1638600704.

On the non-corrupt image after adding the lstat call, both lstat
within the VM and ls -l outside the VM print the same size: 1654327296
in this case, i.e. the same as lstat reported on the corrupt images
within the VM.


(To be precise, for lstat I added the following local git commit to my
copy of the Guix repo at the end of the G-expression executed by the
VM:

diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index db9b1707d7..18ccb8970e 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -309,7 +309,8 @@ INPUTS is a list of inputs (as for packages)."
  #:closures graphs
  #:volume-id #$file-system-label
  #:volume-uuid #$(and=> file-system-uuid
-uuid-bytevector))
+uuid-bytevector))
+ (error (lstat "/xchg/guixsd.iso"))
#:system system
 
;; Keep a local file system for /tmp so that we can populate it directly as



and then reconfigured the system after customizing the guix package to
use said commit and disabling tests on the guix package.  This
reported an lstat Scheme object as an error.  Note that the error
procedure does not cause a failed build.)

Regards,
Florian

bug#33639: ISO installer image is broken on i686

[pelzflorian (Florian Pelz)]

On Mon, Apr 08, 2019 at 10:50:29AM +0200, Ludovic Courtès wrote:
> Hello,
> 
> "Thomas Schmitt"  skribis:
> 
> > The fact that the VM always sees the expected size but the host sees varying
> > sizes supports the suspicion that at the end of the VM its i/o buffers or
> > virtual disk are not always properly flushed to the i/o system of the host.
> > The varying success smells like a race condition.
> 
> Indeed, that rings a bell: I fixed a similar issue in commit
> 0dc7d298a33f83d5f02a962b5f1bd24ee0e8ef07.
> 
> Florian: could you check whether the patch below solves the problem for
> you?
> 
> Thanks,
> Ludo’.
> 

No, sadly not.  I reconfigured to a commit with the Guix package
changed to use your patch and I again got this:

GPT PMBR size mismatch (3231103 != 3187775) will be corrected by write.
libburn : SORRY : Read start address 807775s larger than number of readable 
blocks 796944

bug#33639: ISO installer image is broken on i686

[pelzflorian (Florian Pelz)]

On Wed, Apr 10, 2019 at 01:17:14PM +0200, Thomas Schmitt wrote:
> Given the smell of a race condition, i would next try to let the VM
> wait 10 or 15 seconds after xorriso is finished and before it shuts down.
> 

I added a (sleep 15) after ludo’s (sync).  The first image worked but
now I got

libburn : SORRY : Read start address 80s larger than number of readable 
blocks 798640

again.

bug#33639: ISO installer image is broken on i686

[pelzflorian (Florian Pelz)]

On Fri, Apr 12, 2019 at 11:26:28PM +0200, Ludovic Courtès wrote:
> Florian, it would be great if you could confirm.  Just apply it on
> ‘master’, and then run:
> 
>   ./pre-inst-env guix system disk-image --file-system-format=iso9660 \
>  gnu/system/install.scm
> 

Yes, it seems fixed, I can confirm.  Four rebuilds seem fine and are
bootable in QEMU.  They have the same size and `xorriso -indev` is
happy.  The content is different at the beginning of the ISO image
(maybe padding or timestamps in the file system) and in the EFI
partition at the very end of the ISO, but this seems insignificant.

Regards,
Florian

bug#35136: Git master installer disk-image has GPT PMBR size mismatch

[pelzflorian (Florian Pelz)]

On Sun, Apr 07, 2019 at 08:33:23AM +0200, pelzflorian (Florian Pelz) wrote:
> This seems to be a duplicate of https://issues.guix.info/issue/33639
> , I think, but it happens to me on x86_64.
> 

This bug is fixed with ludo’s patch for
https://issues.guix.info/issue/33639

bug#33639: ISO installer image is broken on i686

[pelzflorian (Florian Pelz)]

On Sun, Apr 14, 2019 at 11:43:54PM +0200, Ludovic Courtès wrote:
> How did you visualize differences, Florian?  Diffoscope fails for me
> here (missing tools and scalability issue.)
> 

For me diffoscope failed too.  I used cmp as described here:

https://superuser.com/questions/125376/how-do-i-compare-binary-files-in-linux

and then looked at the addresses in ghex. It is not a nice method.
Sorry.  It works though.

Regards,
Florian

bug#33639: ISO installer image is broken on i686

[pelzflorian (Florian Pelz)]

On Sat, Apr 13, 2019 at 03:46:09PM +0200, pelzflorian (Florian Pelz) wrote:
> Yes, it seems fixed, I can confirm.

Well this is strange.  I got fine ISO images each time (fine with no
complaints from xorriso or fdisk and bootable in QEMU without errors),
but after dd’ing them to different USB flash drives each time I get
kernel output when inserting the flash drive:

[   10.025223] GPT:Primary header thinks Alt. header is not at the end of the 
disk.
[   10.026735] GPT:3220583 != 7831551
[   10.028235] GPT:Alternate GPT header not at the end of the disk.
[   10.029764] GPT:3220583 != 7831551
[   10.031290] GPT: Use GNU Parted to correct GPT errors.


Having such a USB flash drive inside my computer makes UEFI get stuck
on some computers but not on others.

Why is this?  Are all my USB drives bad?  I presume this is a
different bug, or is it?

Regards,
Florian

bug#33639: ISO installer image is broken on i686

[pelzflorian (Florian Pelz)]

On Tue, Apr 16, 2019 at 11:01:45PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)"  skribis:
> > Having such a USB flash drive inside my computer makes UEFI get stuck
> > on some computers but not on others.
> 
> So you cannot boot from these USB drives at all?
> 

No, I cannot boot from them on this Macbook.  I wonder how I installed
Guix System here; it may have been on a Debian ISO.

Regards,
Florian