bug#51466: bug#53355: guix shell --check: confusing error message

[Chris Marusich]

Hi,

I also observed this bug and reported it as 53355.  I tried to search
for bugs, but I didn't find this bug report until Ludo mentioned it.  I
think it's probably the same bug, so I've merged them.

Ludovic Courtès  writes:

> It looks like the shell-check machinery is misdiagnosing things, as
> Vagrant reported in  (is this on
> Debian too?).

Yes, it's also Debian.  Debian Bullseye.  I've also verified that
similar behavior occurs on Fedora, although the problematic env vars are
different.  I tried fiddling with SHELL like Vagrant did, but I couldn't
make the error go away like he did.  Maybe I did something differently.

> Could you try the debugging tricks I proposed there?

Sure thing!  Thank you for taking the time to make the patch, even
though it was simple.  Here is the result on my Debian Bullseye ppc64el
system:

--8<---cut here---start->8---
[0] [env] marusich@suzaku:~/guix-master
$ ./pre-inst-env guix shell --check --pure --development guix
guix shell: checking the environment variables visible from shell '/bin/sh'...

;;; (dropped "env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit" 
#)

;;; (variable "$ 
LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib" "$ 
LIBRARY_PATH")

;;; (variable 
"C_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" 
"C_INCLUDE_PATH")

;;; (variable "USER=marusich" "USER")

;;; (variable 
"GUIX_LOCPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/locale" 
"GUIX_LOCPATH")

;;; (variable "HOME=/home/marusich" "HOME")

;;; (variable 
"GUILE_LOAD_COMPILED_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/guile/3.0/site-ccache:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0"
 "GUILE_LOAD_COMPILED_PATH")

;;; (variable 
"CPLUS_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include/c++:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include"
 "CPLUS_INCLUDE_PATH")

;;; (variable 
"INFOPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/info" 
"INFOPATH")

;;; (variable "LOGNAME=marusich" "LOGNAME")

;;; (variable 
"PKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig"
 "PKG_CONFIG_PATH")

;;; (variable "TERM=screen.xterm-256color" "TERM")

;;; (variable 
"ACLOCAL_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/aclocal"
 "ACLOCAL_PATH")

;;; (variable 
"PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/sbin"
 "PATH")

;;; (variable 
"GUIX_ENVIRONMENT=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile" 
"GUIX_ENVIRONMENT")

;;; (variable 
"GUILE_LOAD_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0"
 "GUILE_LOAD_PATH")

;;; (variable "PWD=/home/marusich/guix-master" "PWD")
guix shell: warning: variable 'LIBRARY_PATH' is missing from shell environment
hint: One or more environment variables have a different value in the shell than
the one we set.  This means that you may find yourself running code in an
environment different from the one you asked Guix to prepare.

This usually indicates that your shell startup files are unexpectedly
modifying those environment variables.  For example, if you are using Bash,
make sure that environment variables are set or modified in
`~/.bash_profile' and _not_ in `~/.bashrc'.  For more information on Bash
startup files, run:

 info "(bash) Bash Startup Files"

Alternatively, you can avoid the problem by passing the `--container' or
`-C' option.  That will give you a fully isolated environment running in a
"container", immune to the issue described above.

[1] [env] marusich@suzaku:~/guix-master
$
--8<---cut here---end--->8---

The presence of the "$" in front of LIBRARY_PATH seems suspicious:

  ;;; (variable "$ 
LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib" "$ 
LIBRARY_PATH")

I'm not sure why the "$" is being added.  I tried various things to
remove it.  I tried explicitly setting PS1 to an empty string in my
~/.bashrc.  I also tried setting it explicitly to an empty string in
/etc/profile.  Maybe if we can figure out where that "$ " prefix is
coming from, we can resolve this issue?

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836


signature.asc
Description: PGP signature

bug#53659: Fontmanager failing to build

[宋文武]

Pāladhammika  writes:

> Fixed by roptat
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9295b911163f386ac63286c1d797718afabf5585

Cool, close this now!

bug#53712: Guix System hangs after boot with linux-libre 5.15.17

[Leo Famulari]

On Tue, Feb 01, 2022 at 03:39:27PM -0500, Leo Famulari wrote:
> Guix System on x86_64 hangs after boot when reconfigured to use
> linux-libre 5.15.17.

More anecdata:

While I build Linux 5.15.17 (not linux-libre) using the Guix kernel
config, adapted for Debian, it works fine on Debian.

The only changes required for Debian are:

1) Switch from CONFIG_MODULE_COMPRESS_GZIP to CONFIG_MODULE_COMPRESS_XZ
2) Set CONFIG_MODPROBE_PATH=/sbin/modprobe

This Debian kernel doesn't use the config options set in ((gnu packages
linux) %default-extra-linux-options), so it's not a very useful point of
comparison.

bug#53696: Integer overflow on Guix GC size calculation

[Liliana Marie Prikler]

Am Dienstag, dem 01.02.2022 um 14:06 + schrieb Ekaitz Zarraga:
> Hi,
> 
> I noticed there's some kind of a wierd integer overflow on the size
> calculation on `guix gc`:
> 
> [17592186042896 MiB] deleting
> '/gnu/store/j2s6kva8l20m6rjj10bnknq99jc9rg6w-ghc-random-1.2.0-
> builder'
> [17592186042896 MiB] deleting
> '/gnu/store/8nx7zzj629qvv1533c48bl19wrkwcjh2-curl-7.79.1-doc'
> [17592186042897 MiB] deleting
> '/gnu/store/dcsi13588yyjws76s1wjc7h5spnjd2vn-ghc-kan-extensions-
> 5.2.3-builder'
> [17592186042897 MiB] deleting
> '/gnu/store/5zrhw6kvb8wd3n6lazpblqzsg92y320b-ghc-sop-core-0.5.0.1-
> builder'
> [17592186042897 MiB] deleting
> '/gnu/store/l2ya1z3la9qfdj9139f09q3djs36lw3l-ghc-aeson-pretty-0.8.9-
> builder'
> [17592186042897 MiB] deleting
> '/gnu/store/8a8nbfxq508r7qywkhaw8jj8hicpfjh8-ghc-prelude-extras-
> 0.4.0.3-builder'
> [17592186042897 MiB] deleting
> '/gnu/store/wbz6vkiz7cq8c531xvb31lxm28nz332i-ghc-8.10.7'
> [19 MiB] deleting '/gnu/store/i5np7ifiabg333g2l8ycmvbhimnrrx8k-ghc-
> 8.10.7-doc'
> [170 MiB] deleting '/gnu/store/yx9zjw9118gzfcx33adfwy6kghrzxkys-ghc-
> pem-0.2.4-builder'
> [170 MiB] deleting '/gnu/store/pinvkg1x5rpsgm95zhn50l6xq7rly43f-perl-
> test-output-1.033.drv'
> [170 MiB] deleting '/gnu/store/k1bdc950d62g1pw4yw1khgmfr32m3rpm-perl-
> sub-exporter-0.988.drv'
I find it somewhat concerning that you've accumulated more than 2^64
bytes of garbage.  Are some items counted double here?
Other than that, that's pretty normal size_t wraparound semantics.  I
don't think that number is used for anything other than displaying.

Cheers

bug#53701: Re : i18n guix module error when opening shell after guix home reconfigure

[Roland Everaert via Bug reports for GNU Guix]

Ok, how to revert to the commit before that one, are you aware of any plan for 
a fix in a not so distant future?

Thanks for delving into the abyss for us ;)

Roland Everaert
---
Use the F.O.S.S., Luke

Sent with ProtonMail Secure Email.

--- Original Message ---

Le samedi 29 janvier 2022 à 14:19, Holger Peters  a 
écrit :

> Hi,
>
> An error message about guix i18n has appeared for a while now when using guix 
> with guix home:
>
> Backtrace:
>
> 9 (primitive-load "/home/holger/.guix-home/on-first-login")
>
> In ice-9/eval.scm:
>
> 721:20 8 (primitive-eval (begin (use-modules (guix i18n)) (# …) …))
>
> In ice-9/psyntax.scm:
>
> 1230:36 7 (expand-top-sequence ((begin (use-modules (guix …)) …)) …)
>
> 1090:25 6 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
>
> 1222:19 5 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
>
> 259:10 4 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) …)
>
> In ice-9/boot-9.scm:
>
> 3927:20 3 (process-use-modules )
>
> 222:17 2 (map1 (((guix i18n
>
> 3928:31 1 ( ((guix i18n)))
>
> 3329:6 0 (resolve-interface (guix i18n) #:select _ #:hide _ # _ # …)
>
> The same error message has also appeared on other people’s machines. I think 
> this commit is the one introducing the imports which give the error message: 
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=cde3376b35222f46f8a82e7668a1a6fd42c08754
>
> > Anfang der weitergeleiteten Nachricht:
> >
> > Von: Roland Everaert via help-g...@gnu.org
> >
> > Betreff: i18n guix module error when opening shell after guix home 
> > reconfigure
> >
> > Datum: 5. Januar 2022 um 11:00:38 MEZ
> >
> > An: "help-g...@gnu.org" help-g...@gnu.org
> >
> > Antwort an: Roland Everaert r.evera...@protonmail.com
> >
> > Hello,
> >
> > First, happy new year and best wishes for this year.
> >
> > I have updated my guix home configuration to use my zsh config instead of a 
> > blank bash configuration.
> >
> > Unfortunatelly, when I logout and login again, I face the following errors:
> > ---
> >
> > Backtrace:
> >
> > 9 (primitive-load "/home/roland/.guix-home/on-first-login")
> >
> > In ice-9/eval.scm:
> >
> > 721:20 8 (primitive-eval (begin (use-modules (guix i18n)) (# …) …))
> >
> > In ice-9/psyntax.scm:
> >
> > 1230:36 7 (expand-top-sequence ((begin (use-modules (guix …)) …)) …)
> >
> > 1090:25 6 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
> >
> > 1222:19 5 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
> >
> > 259:10 4 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) …)
> >
> > In ice-9/boot-9.scm:
> >
> > 3927:20 3 (process-use-modules )
> >
> > 222:17 2 (map1 (((guix i18n
> >
> > 3928:31 1 ( ((guix i18n)))
> >
> > 3329:6 0 (resolve-interface (guix i18n) #:select _ #:hide _ # _ # …)
> >
> > ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
> >
> > no code for module (guix i18n)
> > 
> >
> > However, the command guix home reconfigure home-config.scm does not 
> > generate any error, so I don't understand why guix complain about a missing 
> > module related to internationalization.
> >
> > I am using guix, the package manager, on a Fedora 34 distribution.
> >
> > Below is my home-config.scm file content:
> >
> > (use-modules (gnu home)
> >
> > (gnu home services)
> >
> > (gnu home services shells)
> >
> > (gnu services)
> >
> > (gnu packages admin)
> >
> > (gnu packages python-xyz)
> >
> > (gnu packages password-utils)
> >
> > (gnu packages dunst)
> >
> > (gnu packages disk)
> >
> > (gnu packages backup)
> >
> > (gnu packages libreoffice)
> >
> > (gnu packages guile)
> >
> > (gnu packages xdisorg)
> >
> > (gnu packages tls)
> >
> > (gnu packages vpn)
> >
> > (gnu packages terminals)
> >
> > (guix gexp))
> >
> > (home-environment
> >
> > (packages (list htop glances password-store dunst ranger restic hunspell
> >
> > ;; hunspell-dict-fr hunspell-dict-en
> >
> > ;; guile
> >
> > neofetch xdotool openssl openvpn xscreensaver alacritty))
> >
> > (services
> >
> > (list
> >
> > (service home-zsh-service-type
> >
> > (home-zsh-configuration
> >
> > (xdg-flavor? #t)
> >
> > (zshrc (list (local-file "zshrc"
> > -
> >
> > Any idea what might cause such trouble?
> >
> > Roland Everaert
> > ---
> >
> > Use the F.O.S.S., Luke
> >
> > Sent with ProtonMail Secure Email.

bug#53712: Guix System hangs after boot with linux-libre 5.15.17

[Leo Famulari]

Guix System on x86_64 hangs after boot when reconfigured to use
linux-libre 5.15.17.

The system becomes unresponsive to keyboard input after boot. Sometimes
it reaches the login prompt, sometimes not. Services that take a while
to start, typically finishing after the prompt is displayed, do not
ever start.

I bisected and confirmed that the problem is introduced in Guix Git
commit aad96ed54070 "gnu: linux-libre: Update to 5.15.17."

I could not reproduce the problem with `guix system vm [...]`. Maybe
this means that the problem only occurs after reconfiguring, rather than
a fresh system, or maybe it just doesn't occur at all in a KVM VM.

I'll try with 5.15.18 and the 5.10 series. We are still unable to deploy
linux-libre 5.16 for Guix System users due to this bug:

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

bug#53712: Guix System hangs after boot with linux-libre 5.15.17

[Leo Famulari]

On Tue, Feb 01, 2022 at 04:11:27PM -0500, Maxim Cournoyer wrote:
> Not sure if that helps, but my system is running smoothly on 5.15.18 as
> I write this.  What are the specifics of your system?

Interestingly, for me 5.15.18 does boot to an interactive console, but
the system fails to bring up the wifi interface, and then it fails to
halt upon command, just hanging forever. At least, it did that for the 3
times I tried using that generation.

This is a Thinkpad x200s with 3 GB RAM. Normal BIOS. I've attached the
operating-system declaration.

There are similar reports on #guix IRC from two other users:

http://logs.guix.gnu.org/guix/2022-01-31.log#152606
http://logs.guix.gnu.org/guix/2022-01-30.log#005034
;; This is an operating system configuration template
;; for a "bare bones" setup, with no X11 display server.

(use-modules (gnu))
(use-service-modules networking
 desktop
 dbus
 ssh)
(use-package-modules admin
 certs
 curl
 linux
 ntp
 nvi
 ssh
 rsync
 tmux
 version-control
 wicd
 vim)

(operating-system
  (host-name "zamia")
  (timezone "America/New_York")
  (locale "en_US.UTF-8")

  (kernel-loadable-modules (list rtl8812au-aircrack-ng-linux-module))
  (kernel-arguments
   '(;; Console resolution
 "gfxpayload=1440x900x16,1440x900"

 ;; console cursor. stops the blinking but the colors are bad
 "vt.cur.default=0x520032"

 "consoleblank=120"
 ;; ???
 "quiet"
 ;; Disable the PC speaker
 "modprobe.blacklist=pcspkr,snd_pcsp"))

  ;; Assuming /dev/sdX is the target hard disk, and "my-root" is
  ;; the label of the target root file system.
  (bootloader (grub-configuration (target "/dev/sda")
  (terminal-outputs '(console
  (file-systems (cons* (file-system
(device (uuid "0pa2dcd8-e037-43fb-b0cc-9ec5bcc3127a"))
(mount-point "/")
(type "btrfs")
(options "compress-force=zstd"))
   (file-system
(device (uuid "9p614cc2-af95-482a-b906-ebc958ed57b7"))
(mount-point "/home")
(type "btrfs")
(options "compress-force=zstd"))

   ; This will break the boot
   ; 
;  (file-system
;(device "/foo/bar")
;(mount-point "/bar")
;(type "none")
;(check? #f)
;(needed-for-boot? #t)
;(flags '(bind-mount)))
  %base-file-systems))

  ;; This is where user accounts are specified.  The "root"
  ;; account is implicit, and is initially created with the
  ;; empty password.
  (users (append (list (user-account
 (name "leo")
 (group "users")
 ;; Adding the account to the "wheel" group
 ;; makes it a sudoer.  Adding it to "audio"
 ;; and "video" allows the user to play sound
 ;; and access the webcam.
 (supplementary-groups '("wheel" "netdev" "audio"
   %base-user-accounts))

  ;; Globally-installed packages.
  (packages (append (list curl
  atop htop
  git
  openssh mosh
  nss-certs
  ntp
  rsync
  tmux
  tree
  vim nvi)
%base-packages-disk-utilities
%base-packages))

  (services
(append
  (list (dbus-service)
(service gpm-service-type)
(service openssh-service-type
   (openssh-configuration
 (password-authentication? #f)))
(service ntp-service-type)
(service wicd-service-type wicd)
(elogind-service))
   (modify-services %base-services
 (guix-service-type config =>
(guix-configuration
  (inherit config)
  (substitute-urls
'("https://custom.example.com";

bug#53696: Integer overflow on Guix GC size calculation

[Ekaitz Zarraga]

Hi,

‐‐‐ Original Message ‐‐‐

On Tuesday, February 1st, 2022 at 10:20 PM, Liliana Marie Prikler 
 wrote:
>
> I find it somewhat concerning that you've accumulated more than 2^64
> bytes of garbage.

I'm a dirty boy.

> Are some items counted double here?

The number started growing from 0 and then that appeared and it continued
smoothly from the previous. It's like something went bad in the middle.

> Other than that, that's pretty normal size_t wraparound semantics. I
> don't think that number is used for anything other than displaying.

Showing wrong information to the people that use the program is pretty
weird. The program still works but showing wrong data is worse than
not showing it in my opinion.
I'll take a look and try to see if I can fix it.

> Cheers

Best,
Ekaitz

bug#53712: Guix System hangs after boot with linux-libre 5.15.17

[Leo Famulari]

On Tue, Feb 01, 2022 at 03:39:27PM -0500, Leo Famulari wrote:
> I'll try with 5.15.18 and the 5.10 series. We are still unable to deploy
> linux-libre 5.16 for Guix System users due to this bug:

Same problem with 5.10.95.

bug#53580: /var/run/shepherd/socket is missing on an otherwise functional system

[Maxime Devos]

Attila Lendvai schreef op do 27-01-2022 om 11:32 [+]:
> (define (call-with-server-socket file-name proc)
>   "Call PROC, passing it a listening socket at FILE-NAME and deleting the
> socket file at FILE-NAME upon exit of PROC.  Return the values of PROC."
>   (let ((sock (open-server-socket file-name)))
>     (dynamic-wind
>   noop
>   (lambda () (proc sock))
>   (lambda ()
>     (close sock)
>     (catch-system-error (delete-file file-name))
> ```
> 
> maybe this is caused by some call/cc magic that causes an unwind that deletes 
> the file, but then continues?

Shepherd doesn't use call/cc anywhere.  However, it does use
_delimited_ continuations, even though only through let/ec and
'guard'/'catch'/...  More generally, call/cc is typically unused in
(Guile) Scheme code, and call-with-prompt / abort-to-prompt / shift /
reset / % are used instead.

My guess what happens: the start code of a shepherd service
fails between 'fork' and 'exec', with an exception.  The exception
isn't caught (or is caught and reraised), so the 'out' guard of the
'dynamic-wind' is entered and the file representing the socket is
deleted.

If that's indeed the case, it might be a good idea to install
some exception handlers in fork+exec-command and friends (including
make-forkexec-constructor/container), to make shepherd more robust
w.r.t. services failing to start.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#53710: guix pull fails

[Jesse Gibbons]

~$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 787b13a (279 new 
commits)...

Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git    787b13a
Computing Guix derivation for 'x86_64-linux'... \Backtrace:
  17 (primitive-load 
"/gnu/store/rx23w5k5nys4a2hjwcy4lampkhnslj3m-compute-guix-derivation")

In ice-9/eval.scm:
    155:9 16 (_ _)
    159:9 15 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))

In ice-9/boot-9.scm:
    152:2 14 (with-fluid* _ _ _)
    152:2 13 (with-fluid* _ _ _)
In ./guix/store.scm:
  2123:24 12 (run-with-store # 
# ?)

   1960:8 11 (_ #)
In ./guix/gexp.scm:
   296:22 10 (_ #)
   1180:2  9 (_ #)
   1046:2  8 (_ #)
    892:4  7 (_ #)
In ./guix/store.scm:
  2008:12  6 (_ #)
   1406:5  5 (map/accumulate-builds #7f691ce7e140> # ?)
  1421:15  4 (_ # 
("/gnu/store/gmi62pbnf0jfish26chd7pvfzs2rzlxa-guile-ssh-?" ?) ?)

  1421:15  3 (loop #f)
   733:11  2 (process-stderr # _)
In ./guix/serialization.scm:
   102:11  1 (read-int #)
 80:6  0 (get-bytevector-n* # 8)

./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
ERROR:
  1. &nar-error:
  file: #f
  port: #
guix pull: error: You found a bug: the program 
'/gnu/store/rx23w5k5nys4a2hjwcy4lampkhnslj3m-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"787b13a5d9df8f0cc7170de1b80cead68b516c66"; system: "x86_64-linux";

host version: "90a41fe388102d448b3f91a070e38a7680d2d568"; pull-version: 1).
Please report the COMPLETE output above by email to .

--
-Jesse Gibbons

bug#53712: Guix System hangs after boot with linux-libre 5.15.17

[Leo Famulari]

On Tue, Feb 01, 2022 at 03:39:27PM -0500, Leo Famulari wrote:
> Guix System on x86_64 hangs after boot when reconfigured to use
> linux-libre 5.15.17.

More anecdata:

While I build Linux 5.15.17 (not linux-libre) using the Guix kernel
config, adapted for Debian, it works fine on Debian.

The only changes required for Debian are:

1) Switch from CONFIG_MODULE_COMPRESS_GZIP to CONFIG_MODULE_COMPRESS_XZ
2) Set CONFIG_MODPROBE_PATH=/sbin/modprobe

This Debian kernel doesn't use the config options set in ((gnu packages
linux) %default-extra-linux-options), so it's not a very useful point of
comparison.

bug#53712: Guix System hangs after boot with linux-libre 5.15.17

[Maxim Cournoyer]

Hi Leo,

Leo Famulari  writes:

> Guix System on x86_64 hangs after boot when reconfigured to use
> linux-libre 5.15.17.
>
> The system becomes unresponsive to keyboard input after boot. Sometimes
> it reaches the login prompt, sometimes not. Services that take a while
> to start, typically finishing after the prompt is displayed, do not
> ever start.
>
> I bisected and confirmed that the problem is introduced in Guix Git
> commit aad96ed54070 "gnu: linux-libre: Update to 5.15.17."
>
> I could not reproduce the problem with `guix system vm [...]`. Maybe
> this means that the problem only occurs after reconfiguring, rather than
> a fresh system, or maybe it just doesn't occur at all in a KVM VM.
>
> I'll try with 5.15.18 and the 5.10 series. We are still unable to deploy
> linux-libre 5.16 for Guix System users due to this bug:

Not sure if that helps, but my system is running smoothly on 5.15.18 as
I write this.  What are the specifics of your system?

Thanks,

Maxim

bug#53700: Guix package is hardcoded in guix home

[Gordon Quad via Bug reports for GNU Guix]

guix home uses guix package directly imported from (gnu packages
package-management) gnu/home/services.scm:22

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n22

It looks like for now it is used only here gnu/home/services.scm:283

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n284

It is quite unfortunte to see guix home to pull whole extra copy of guix
only to use few files to do gettext localization init.

If would be nice to be able to customize guix package used there so I
can make sure guix used by guix home is the same as in my guix daemon.

bug#53426: mingw-w64-{x86_64, i686}-winpthreads broken after absorption of binutils-next

[Carl Dong]

I did some more exploration, and found that not only are the mingw-w64-{x86_64, 
i686}-winpthreads packages broken, but any --target=x86_64-w64-mingw32 package:

$ guix build --target=x86_64-w64-mingw32 hello

I have this patch which resolves the problem by simply disabling compressed 
debug sections, but perhaps it’d also be worthwhile to investigate the root 
cause...

--8<---cut here---start->8---
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 78cbf871ac..397e4d4c1c 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -101,7 +101,8 @@ (define* (cross-binutils target #:optional (binutils 
binutils))
  "ath9k-htc-firmware-binutils.patch")))
  ((target-mingw? target)
   (package-with-extra-patches
-   binutils
+   (package-with-extra-configure-variable
+binutils "--enable-compressed-debug-sections" "no")
(search-patches "binutils-mingw-w64-timestamp.patch"
"binutils-mingw-w64-deterministic.patch")))
  (else binutils))
--8<---cut here---end--->8---

Cheers,
Carl Dong

> On Jan 21, 2022, at 5:10 PM, Maxime Devos  wrote:
> 
> Carl Dong schreef op vr 21-01-2022 om 16:30 [-0500]:
>> I’m wondering what the best course of action is to fix the mingw-w64-
>> {x86_64,i686}-winpthreads packages (e.g. just remove the configure
>> flag for mingw-w64? Add that flag only for linux? Or something else?)
>> and would love some help.
> 
> I would assume that it works for Linux, it also works for the Hurd,
> so I would prefer something like
> 
> #$@(if (target-mingw?) '() '("--some-configuration..."))
> 
> above
> 
> #$@(if (target-linux?) '("--some-configuration...") '())
> 
> Greetings,
> Maxime.
> 



signature.asc
Description: Message signed with OpenPGP

bug#53694: Librecad fails to build

[Guillaume Le Vaillant]

Ekaitz Zarraga  skribis:

> Hi,
>
> After a `guix pull` librecad fails to build. I attach the log.
> It looks related with `boost` but I have no time to research further right 
> now.
>
> Best,
> Ekaitz

Fixed in 787b13a5d9df8f0cc7170de1b80cead68b516c66.


signature.asc
Description: PGP signature

bug#47681: [PATCH] services: udev: Use a fixed location for the rules directory and config.

[Maxim Cournoyer]

Fixes .

This change adjusts the location of the udev configuration file and rules
directory to a fixed location.  Since udev relies on inotify to discover
change to its rules directory (/etc/udev/rules.d), by using a fixed directory
layout, new udev rules can be automatically picked up without restarting the
service.

* gnu/services/base.scm (udev-rules-union): Build rules output directly
in #$output.
(udev-shepherd-service)[start]: Adjust the UDEV_CONFIG_FILE and
EUDEV_RULES_DIRECTORY environment variables.
[actions]: Remove field.  The 'rules' action is no longer useful.
(udev.conf): New variable.
(udev-etc): New procedure.
(udev-service-type): Extend the etc-service-type with it.
---
 gnu/services/base.scm | 210 +-
 1 file changed, 104 insertions(+), 106 deletions(-)

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index fbd01e84d6..4c8a840156 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -15,7 +15,7 @@
 ;;; Copyright © 2020, 2021 Brice Waegeneire 
 ;;; Copyright © 2021 qblade 
 ;;; Copyright © 2021 Hui Lu 
-;;; Copyright © 2021 Maxim Cournoyer 
+;;; Copyright © 2021, 2022 Maxim Cournoyer 
 ;;; Copyright © 2022 Guillaume Le Vaillant 
 ;;;
 ;;; This file is part of GNU Guix.
@@ -1995,8 +1995,7 @@ (define (rules-sub-directory directory)
 (find directory-exists?
   (map (cut string-append directory <>) %standard-locations)))
 
-  (mkdir-p (string-append #$output "/lib/udev"))
-  (union-build (string-append #$output "/lib/udev/rules.d")
+  (union-build #$output
(filter-map rules-sub-directory '#$packages)
 
   (computed-file "udev-rules" build))
@@ -2045,116 +2044,115 @@ (define kvm-udev-rule
 
 (define udev-shepherd-service
   ;; Return a  for UDEV with RULES.
+  (match-lambda
+(($  udev)
+ (list
+  (shepherd-service
+   (provision '(udev))
+
+   ;; Udev needs /dev to be a 'devtmpfs' mount so that new device nodes can
+   ;; be added: see
+   ;; 
.
+   (requirement '(root-file-system))
+
+   (documentation "Populate the /dev directory, dynamically.")
+   (start
+(with-imported-modules (source-module-closure
+'((gnu build linux-boot)))
+  #~(lambda ()
+  (define udevd
+;; 'udevd' from eudev.
+#$(file-append udev "/sbin/udevd"))
+
+  (define (wait-for-udevd)
+;; Wait until someone's listening on udevd's control
+;; socket.
+(let ((sock (socket AF_UNIX SOCK_SEQPACKET 0)))
+  (let try ()
+(catch 'system-error
+  (lambda ()
+(connect sock PF_UNIX "/run/udev/control")
+(close-port sock))
+  (lambda args
+(format #t "waiting for udevd...~%")
+(usleep 50)
+(try))
+
+  ;; Allow udev to find the modules.
+  (setenv "LINUX_MODULE_DIRECTORY"
+  "/run/booted-system/kernel/lib/modules")
+
+  (let* ((kernel-release
+  (utsname:release (uname)))
+ (linux-module-directory
+  (getenv "LINUX_MODULE_DIRECTORY"))
+ (directory
+  (string-append linux-module-directory "/"
+ kernel-release))
+ (old-umask (umask #o022)))
+;; If we're in a container, DIRECTORY might not exist,
+;; for instance because the host runs a different
+;; kernel.  In that case, skip it; we'll just miss a few
+;; nodes like /dev/fuse.
+(when (file-exists? directory)
+  (make-static-device-nodes directory))
+(umask old-umask))
+
+  (let ((pid (fork+exec-command
+  (list udevd)
+  #:environment-variables
+  (cons*
+   ;; The first one is for udev, the second one for
+   ;; eudev.
+   "UDEV_CONFIG_FILE=/etc/udev/udev.conf"
+   "EUDEV_RULES_DIRECTORY=/etc/udev/rules.d"
+   (string-append "LINUX_MODULE_DIRECTORY="
+  (getenv "LINUX_MODULE_DIRECTORY"))
+   (default-environment-variables)
+;; Wait until udevd is up and running.  This appears to
+;; be needed so that the events triggered below are
+;; actually handled.
+(wait-for-udevd)
+
+;; Trigger device 

bug#53696: Integer overflow on Guix GC size calculation

[Ekaitz Zarraga]

Hi,

I noticed there's some kind of a wierd integer overflow on the size calculation 
on `guix gc`:

[17592186042896 MiB] deleting 
'/gnu/store/j2s6kva8l20m6rjj10bnknq99jc9rg6w-ghc-random-1.2.0-builder'
[17592186042896 MiB] deleting 
'/gnu/store/8nx7zzj629qvv1533c48bl19wrkwcjh2-curl-7.79.1-doc'
[17592186042897 MiB] deleting 
'/gnu/store/dcsi13588yyjws76s1wjc7h5spnjd2vn-ghc-kan-extensions-5.2.3-builder'
[17592186042897 MiB] deleting 
'/gnu/store/5zrhw6kvb8wd3n6lazpblqzsg92y320b-ghc-sop-core-0.5.0.1-builder'
[17592186042897 MiB] deleting 
'/gnu/store/l2ya1z3la9qfdj9139f09q3djs36lw3l-ghc-aeson-pretty-0.8.9-builder'
[17592186042897 MiB] deleting 
'/gnu/store/8a8nbfxq508r7qywkhaw8jj8hicpfjh8-ghc-prelude-extras-0.4.0.3-builder'
[17592186042897 MiB] deleting 
'/gnu/store/wbz6vkiz7cq8c531xvb31lxm28nz332i-ghc-8.10.7'
[19 MiB] deleting '/gnu/store/i5np7ifiabg333g2l8ycmvbhimnrrx8k-ghc-8.10.7-doc'
[170 MiB] deleting 
'/gnu/store/yx9zjw9118gzfcx33adfwy6kghrzxkys-ghc-pem-0.2.4-builder'
[170 MiB] deleting 
'/gnu/store/pinvkg1x5rpsgm95zhn50l6xq7rly43f-perl-test-output-1.033.drv'
[170 MiB] deleting 
'/gnu/store/k1bdc950d62g1pw4yw1khgmfr32m3rpm-perl-sub-exporter-0.988.drv'

bug#53657: inconsistent parsing of the channel sexp's

[Ricardo Wurmus]

Thanks for the bug report.

I feel like I’m missing something here.

> this leads to an actual issue that channel dependencies don't match up,
> unless the name is without quotes in the dependencies list
> specification.

I don’t understand what it means for “channel dependencies” to “match
up”.  How is this an issue?

I’ll say that I agree that there’s an apparent inconsistency (as
evidenced also by commit 52e64b21be50e2c5febd7bf1accd88ffdc05a4bb, which
corrected a mistake in the documentation that used an explicit quote), I
just don’t see yet how it leads to a practical problem.

Could you please elaborate?

-- 
Ricardo

bug#53695: trash-cli crashes

[Simon Streit]

With trash-cli's last update, it doesn't work any more and exits with
the following error:

--8<---cut here---start->8---
Traceback (most recent call last):
  File "/home/ss2/.guix-profile/bin/trash-list", line 4, in 
from trashcli.list import main as main
ModuleNotFoundError: No module named 'trashcli'
--8<---cut here---end--->8---

I've tried to come up with a solution, but none work so far.


Kind regards
Simon

bug#53694: Librecad fails to build

[Ekaitz Zarraga]

Hi,

After a `guix pull` librecad fails to build. I attach the log.
It looks related with `boost` but I have no time to research further right now.

Best,
Ekaitz

q36q0k7jjsh9lpk3h1i651dilgrdrq-librecad-2.2.0-rc2.drv.bz2
Description: application/bzip

bug#53580: (No Subject)

[Efraim Flashner]

On Thu, Jan 27, 2022 at 12:13:28PM +, Attila Lendvai wrote:
> i forgot to add that i'm working on a shepherd service, and this may be due 
> to errors in the service's user code, like the start gexp.

This is generally when I see this type of error. I normally try to
create a minimal VM and launch that when I'm trying out a new service.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#53214: Release 1.4.0 progress

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> The build farm is having trouble building Guix for i686-linux. In fact,
> it hasn't successfully completed the 'guix' job in weeks:
>
> https://issues.guix.gnu.org/53463

(This issue title doesn’t mention i686.)  I’m looking at it, though a
bit slowly because I’ve been busy with other things:

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

> And building the guix package does not work on aarch64, also for weeks:
>
> https://issues.guix.gnu.org/52943

Ah, I thought this had been fixed with Chris Marusich’s commits but
apparently not?

> Finally, should we consider retiring the armhf port in 1.4.0? It seems
> that we have stopped trying to build for it:
>
> https://ci.guix.gnu.org/search?query=guix+spec%3Amaster+system%3Aarmhf-linux

The “armhf-linux” box was unchecked, not sure why.  I’ve re-added it and
we’ll see.  (For the record, anyone with access to berlin or with a
certificate can do it via the Cuirass web interface.)

Bordeaux.guix does have binaries:

--8<---cut here---start->8---
$ guix weather -s armhf-linux coreutils guile grep sed
computing 4 package derivations for armhf-linux...
looking for 6 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  0.0% substitutes available (0 out of 6)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  0.042 seconds per request (0.2 seconds in total)
  23.6 requests per second

  0.0% (0 out of 6) of the missing items are queued
  at least 1,000 queued builds
  aarch64-linux: 1000 (100.0%)
  build rate: 17.64 builds per hour
  i686-linux: 4.74 builds per hour
  x86_64-linux: 9.23 builds per hour
  powerpc64le-linux: 3.69 builds per hour
looking for 6 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org
  100.0% substitutes available (6 out of 6)
  23.1 MiB of nars (compressed)
  113.8 MiB on disk (uncompressed)
  0.034 seconds per request (0.1 seconds in total)
  29.3 requests per second
  (continuous integration information unavailable)
--8<---cut here---end--->8---

Overall it’s not a great situation to be in, but I think we should be
able to address it.  Usually I think it’s safer to merge ‘core-updates’
only after “make assert-binaries-available” passes.

Thanks,
Ludo’.

bug#52801: Guile misbehaves in case of escapes and carriage returns, sometimes breaking "guix pull"

[Ludovic Courtès]

Hi Maxime,

Maxime Devos  skribis:

> Grigory Shepelev schreef op zo 30-01-2022 om 22:45 [+0300]:
>> Seems like the problem was in my .gitconfig file where "autocrlf =
>> true". I set it to "false", and cleared the cache. Then the "guix
>> pull" started to work as expected. 
>
> According to
> 
> and ,
> we can tell libgit to not do CRLF conversion, which would make (guix git)
> more robust.

Indeed.  Looks like Guile-Git doesn’t expose checkout options yet, so
doing that would be the first step.

Maybe Guix should just ignore ~/.gitconfig altogether?

Thanks,
Ludo’.