bug#54923: more than one target service of type 'account'

[raingloom]

> more than one target service of type 'account'

I did not add any new service, I just modified openssh-service-type.

```
(operating-system
(inherit os)
(services
 (modify-services
 (operating-system-services os)
 (openssh-service-type
  config =>
  (openssh-configuration
   (inherit config)
   (permit-root-login 'without-password))
```

Full system description in attachment.
;; TODO convert to R6RS module syntax?
(use-modules
 (gnu packages android)
 (gnu packages bootloaders)
 (gnu packages certs)
 (gnu packages cups)
 (gnu packages ghostscript)
 (gnu packages gnome)
 (gnu packages linux)
 (gnu packages networking)
 (gnu packages package-management)
 (gnu packages shells)
 (gnu packages suckless)
 (gnu packages wm)
 (gnu packages xdisorg)
 (gnu packages xorg)
 (gnu services cups)
 (gnu services desktop)
 (gnu services linux)
 (gnu services networking)
 (gnu services ssh)
 (gnu services virtualization)
 (gnu services xorg)
 (gnu services)
 (gnu system install)
 (gnu system nss)
 (gnu system shadow))


;; this is for devices with no screen, or UART, or anything of the sort
;; the name is apt though, because this completely ruins security!
;; DO NOT USE THIS FOR THE FINAL SYSTEM
;; use it only for the inital setup, then reconfigure with a proper config

(define-public (backdoor-os os)
  (operating-system
(inherit os)
(services
 (modify-services
 (operating-system-services os)
 (openssh-service-type
  config =>
  (openssh-configuration
   (inherit config)
   (permit-root-login 'without-password)))

(define-public backdoored-installation-os
  (backdoor-os installation-os))

;; guix system: error: more than one target service of type 'account'
backdoored-installation-os

bug#54922: earlyoom build is (ironically?) going out of memory on 32bit

[raingloom]

This is more of a Haskell problem than an earlyoom one. Pandoc seems to
not like 32 bit. If you take a look at the CI, there are no successful
builds.

http://ci.guix.gnu.org/search?query=earlyoom%20system:i686-linux=145628

Maybe the documentation related phases should just be deleted on 32
bit, or it could be a separate package, or something.

bug#34427: bug#34453: [PATCH] build guile-static with guile-2.0

[Efraim Flashner]

On Tue, Apr 12, 2022 at 12:10:09PM +0200, zimoun wrote:
> Hi,
> 
> What is the status of this old patch #34453?
> 
> http://issues.guix.gnu.org/issue/34453
> 
> 
> On Sat, 16 Feb 2019 at 17:06, Ludovic Courtès  wrote:
> > Efraim Flashner  skribis:
> >
> >> When experimenting I found that using guile@2.0 as a base for
> >> guile-static, the resulting guile-static didn't segfault on the target
> >> architecture.
> >
> > As discussed in , I would rather
> > fix the segfault in 2.2 than move back to 2.0 and effectively delay the
> > problem.
> 
> Note that #34427 is still open.

We can probably drop it. We'll pick it back up again if/when it comes up
again.

-- 
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#34427: guile-bootstrap@2.2 segfault?

[Efraim Flashner]

On Tue, Apr 12, 2022 at 06:01:39PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Efraim Flashner  skribis:
> 
> > On Tue, Feb 12, 2019 at 03:27:37PM +0100, Ludovic Courtès wrote:
> >> Hello Efraim,
> >> 
> >> Efraim Flashner  skribis:
> >> 
> >> > I'm testing %bootstrap-guile from bootstrap.scm and I'm getting a
> >> > segfault when runing guile --version. I've attached an strace of the
> >> > process.
> >> 
> >> To be clear, I believe this is for a *cross-compiled* Guile, right?
> >
> > That's right, %bootstrap-guile is extracted from $(guix build
> > --target=powerpc-linux-gnu bootstrap-tarballs)
> 
> Cross-compilation to aarch64-linux-gnu works fine:
> 
> --8<---cut here---start->8---
> $ unshare -mrf chroot $(guix build guile-static-stripped 
> --target=aarch64-linux-gnu) /bin/guile
> guile: warning: failed to install locale
> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
> GC Warning: Couldn't read /proc/stat
> warning: failed to install locale: Invalid argument
> GNU Guile 3.0.7
> Copyright (C) 1995-2021 Free Software Foundation, Inc.
> 
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
> 
> Enter `,help' for help.
> scheme@(guile-user)> %host-type
> $1 = "aarch64-unknown-linux-gnu"
> scheme@(guile-user)> ,q
> $ guix describe
> Generation 210  Apr 11 2022 09:34:10(current)
>   guix 7da907f
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 7da907f90e74a4edf96d76ee457ff958265ef8d4
> --8<---cut here---end--->8---
> 
> The problem has to do specifically with powerpc-linux-gnu (this is with
> transparent emulation via QEMU+binfmt_misc):
> 
> --8<---cut here---start->8---
> $ unshare -mrf chroot $(guix build guile-static-stripped 
> --target=powerpc-linux-gnu) /bin/guile
> guile: warning: failed to install locale
> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
> GC Warning: Couldn't read /proc/stat
> Pre-boot error; key: wrong-type-arg, args: (#f "Wrong type to apply: ~S" (#f) 
> (#f))qemu: uncaught target signal 6 (Aborted) - core dumped
> Aborted
> --8<---cut here---end--->8---
> 
> Unfortunately I fail to get a backtrace from that core dump.
> 
> Efraim, could you get a backtrace on the bare metal?
> 
> Besides, if PPC32 is the only platform that has a problem, I think this
> bug should not be a blocker.
> 
> WDYT?
> 
> Ludo’.

Here's what I get from strace when running on bare metal. I agree, if
it's only affecting ppc32 we shouldn't have it be a blocker.
28071 
execve("/gnu/store/imbgn3if51jxi1nhwwdb5q9dpkhz9aff-guile-static-stripped-3.0.7/bin/guile",
 ["/gnu/store/imbgn3if51jxi1nhwwdb5"...], 0xaf88c21c /* 30 vars */) = 0
28071 brk(NULL) = 0x10849000
28071 brk(0x108498d8)   = 0x108498d8
28071 uname({sysname="Linux", nodename="g4", ...}) = 0
28071 set_tid_address(0x10849068)   = 28071
28071 set_robust_list(0x10849070, 12)   = 0
28071 rt_sigaction(SIGRTMIN, {sa_handler=0x101154ac, sa_mask=[], 
sa_flags=SA_SIGINFO}, NULL, 8) = 0
28071 rt_sigaction(SIGRT_1, {sa_handler=0x1011558c, sa_mask=[], 
sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
28071 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
28071 ugetrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
28071 readlink("/proc/self/exe", "/gnu/store/imbgn3if51jxi1nhwwdb5"..., 4096) = 
81
28071 brk(0x1086a8d8)   = 0x1086a8d8
28071 brk(0x1086b000)   = 0x1086b000
28071 mprotect(0x1037f000, 4096, PROT_READ) = 0
28071 openat(AT_FDCWD, "/run/current-system/locale/2.33/locale-archive", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, 
"/gnu/store/-glibc-cross-powerpc-linux-gnu-2.33/share/locale/locale.alias",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, 
"/run/current-system/locale/2.33/en_US.UTF-8/LC_IDENTIFICATION", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, 
"/run/current-system/locale/2.33/en_US.utf8/LC_IDENTIFICATION", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, 
"/run/current-system/locale/2.33/en_US/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, 
"/run/current-system/locale/2.33/en.UTF-8/LC_IDENTIFICATION", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, 
"/run/current-system/locale/2.33/en.utf8/LC_IDENTIFICATION", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, "/run/current-system/locale/2.33/en/LC_IDENTIFICATION", 

bug#54919: Guix hangs near the end of ‘home’ operations

[Brian Cully]

During ‘home reconfigure’ after it says ‘Finished updating symlinks.’,
guix hangs forever. Attempting to interrupt with ^C failed, and I had to
force-close my ssh session.

Logging back in, ‘home list-generations’ claims to have
installed a new generation and moved forward. I no longer knew the state
of this generation, since I had to forcefully quit the previous
operation, so I felt it safest to try to roll back my home.

Again, ‘home roll-back’ got to ‘Finished updating symlinks’ and
hard hung. I probably don’t need to tell anyone how this makes me feel
about the stability of this system or any guarantees of atomicity in
transactions.

-bjc

bug#52362: another patchset

[Attila Lendvai]

FYI,

i have extensive fixes to the go importer that i'm preparing for submission:

https://github.com/attila-lendvai-patches/guix/tree/import

it fixes this issue, and it can also recursively import rclone (and go-ethereum 
for that matter):

./pre-inst-env guix import go --recursive github.com/rclone/rclone

emits 100+ packages.

unfortunately, it fails on/skips:

guix import go github.com/billziss-gh/cgofuse

i suspect that it's probably because that module is not adhering to the git tag 
name rules.

-- 
- attila
PGP: 5D5F 45C7 DFCD 0A39

bug#54900: Bug encountered when running `guix pull`

[Maxime Devos]

Jochen Luig schreef op wo 13-04-2022 om 04:56 [+0200]:
> guix substitute: warning: while fetching
> https://ci.guix.gnu.org/nar/lzip/mzz11jzk3ag1nzzzdg83kmgysm5faijd-texlive-babel-fixed-59745
> : server is somewhat slow
> guix substitute: warning: try `--no-substitutes' if the problem
> persists
> guix substitute: error: connect*: Connection timed out
>   16 (primitive-load
> "/gnu/store/ghf5nvs7mwv0w99737ilgja4hfdm2l7s-compute-guix-
> derivation")

Probably network problems, just retry, and maybe pass --fallback to
"guix pull".

Anyway, this is not a bug and hence shouldn't be reported as such, but
error reporting in "guix pull" is complicated™.  FWIW, the v2 patch at
 would avoid the here unnecessary
backtrace and make it clearer that it's just some network problems,
though it's not perfect (the ‘please report a bug’ remains).

Greetings,
Maxime.


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

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Maxime Devos]

Liliana Marie Prikler schreef op wo 13-04-2022 om 12:40 [+0200]:
> You are first encoding a non-ASCII byte to ASCII, which has no glyph
> for "I have no idea what this is", so a question mark (#\?) is used. 
> When converting from invalid ASCII to UTF-8 on the other hand, you do
> have #\� as the WTF character, so that is used instead.  This is
> entirely consistent :)

Right, makes sense.


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

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Liliana Marie Prikler]

Am Mittwoch, dem 13.04.2022 um 10:22 +0200 schrieb Maxime Devos:
> [...]
> Let's test this (in a new REPL with an UTF-8 locale):
> 
> ((@ (ice-9 iconv) string->bytevector) "é" "ANSI_X3.4-1968")
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Throw to key `encoding-error' with args `("put-char" "conversion to
> port encoding failed" 84 # #\é)'.
> 
> ((@ (ice-9 iconv) string->bytevector) "é" "ANSI_X3.4-1968" 'substitute)
> $2 = #vu8(63)
> ((@ (rnrs bytevectors) utf8->string) #vu8(63))
> $3 = "?"
> 
> and the other direction:
> 
> ((@ (ice-9 iconv) bytevector->string) #vu8(128) "ANSI_X3.4-1968"
> 'substitute)
> $5 = "�" ;; why #\� and not #\?? I don't know, I guess Guile is
> inconsistent
You are first encoding a non-ASCII byte to ASCII, which has no glyph
for "I have no idea what this is", so a question mark (#\?) is used. 
When converting from invalid ASCII to UTF-8 on the other hand, you do
have #\� as the WTF character, so that is used instead.  This is
entirely consistent :)

Cheers

bug#54900: Bug encountered when running `guix pull`

[Jochen Luig]

Hello,

I just tried to install guix on my laptop. When trying to run `guix pull`,
at the end of the output it read:

guix pull: error: You found a bug: the program
'/gnu/store/ghf5nvs7mwv0w99737ilgja4hfdm2l7s-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"950f3e4f98add14f645dc4c9f8c512cac7b8a779"; system: "x86_64-linux";
host version: "1.3.0"; pull-version: 1).
Please report the COMPLETE output above by email to .

So here it is.

The host system is a custom version of Ubuntu 20.04 provided by the vendor (
https://www.tuxedocomputers.com):

$ uname -a
Linux molly 5.13.0-10039-tuxedo #44~20.04.1tux1 SMP Sun Mar 27 02:09:26 UTC
2022 x86_64 x86_64 x86_64 GNU/Linux

This is the shell history after running the install script as root that led
to the output I attached to this message:

9  guix search text editor
   10  cd
   11  guix install glibc-locales
   12  export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
   13  ls /etc/nsswitch.conf
   14  cat /etc/nsswitch.conf
   15  info nscd
   16  info
   17  info libc "Name Service Switch"
   18  ps aux | grep nscd
   19  apt search nscd
   20  sudo apt install nscd
   21  ps aux | grep nscd
   22  guix pull

Kind regards,

Jochen
> guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 950f3e4 (17.732 new 
commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   950f3e4
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building /gnu/store/sflmgcfcdwizj7iyd3pfksdvrkc3pskb-config.scm.drv...
building /gnu/store/7k17dvmcrdicjsdxmpvhss4p3i3d70j5-git.scm.drv...
building /gnu/store/j9s3n7iqvh8pqkxkwy91nq3qynr1nby7-hash.scm.drv...
building /gnu/store/g38d4zk80pdl1mzl8xlp2yxvprlkfmvc-module-import.drv...
building /gnu/store/lxqicpd4nxnv8rl2zbsmx5a880m5ndh3-module-import.drv...
building 
/gnu/store/wyjjnkz1wa2k1dcll0586wlmpiz4n751-module-import-compiled.drv...
building 
/gnu/store/31rcg97a659vmyszjcdkhhdjzqbhk6wi-module-import-compiled.drv...
building 
/gnu/store/34g8c11afsqhk37l67madhsnwmfvxhkq-compute-guix-derivation.drv...
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 

bug#54867: "You found a bug" during guix pull on freshly executed qemu image

[Carlos Fernández Llamas]

Hi there!,

Just encountered an error while giving Guix a try.

My steps:
- Downloaded the Guix 1.3.0 qcow2 image: 
https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2
- Executed it on Debian bullseye using qemu-system, as explained here: 
https://guix.gnu.org/manual/en/html_node/Running-Guix-in-a-VM.html (side note: 
running `xz -d` with the downloaded image didn't work, complaining about it not 
being the correct format. Used it directly without decompressing and guix 
started properly anyway, so ¯\_(ツ)_/¯)
- Configured keyboard to the Spanish layout using the GUI.
- Opened a terminal and executed `guix pull`

As a result, got the following output ending with "You found a bug" and a 
suggestion to report it here, so, here we are :)

> guest@gnu ~$ guix pull
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Authenticating channel 'guix', commits 9edb3f6 to 6413d08 (17,564 new 
> commits)...
> Building from this channel:
> guix https://git.savannah.gnu.org/git/guix.git 6413d08
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> libtiff-4.2.0-doc 358KiB 1.4MiB/s 00:00 [##] 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> bdb-5.3.28 945KiB 2.5MiB/s 00:00 [##] 100.0%
> cyrus-sasl-2.1.27 234KiB 2.1MiB/s 00:00 [##] 100.0%
> openldap-2.4.57 1.2MiB 4.1MiB/s 00:00 [##] 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> curl-7.76.0-doc 624KiB 2.1MiB/s 00:00 [##] 100.0%
> nghttp2-1.41.0-lib 89KiB 4.9MiB/s 00:00 [##] 100.0%
> openldap-2.4.50 1.3MiB 9.3MiB/s 00:00 [##] 100.0%
> curl-7.76.0 414KiB 5.2MiB/s 00:00 [##] 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> curl-7.74.0 379KiB 1.3MiB/s 00:00 [##] 100.0%
> git-minimal-2.31.1 4.1MiB 3.7MiB/s 00:01 [##] 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> gnutls-3.6.15-doc 1.0MiB 1.6MiB/s 00:01 [##] 100.0%
> zlib-1.2.11 82KiB 2.1MiB/s 00:00 [##] 100.0%
> gcc-7.5.0 15.2MiB 4.4MiB/s 00:03 [##] 100.0%
> gnutls-3.6.15-debug 2.6MiB 8.5MiB/s 00:00 [##] 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> gmp-6.2.0 583KiB 2.3MiB/s 00:00 [##] 100.0%
> libffi-3.3 54KiB 1.3MiB/s 00:00 [##] 100.0%
> libgc-8.0.4 224KiB 3.5MiB/s 00:00 [##] 100.0%
> libltdl-2.4.6 52KiB 3.7MiB/s 00:00 [##] 100.0%
> libunistring-0.9.10 500KiB 3.9MiB/s 00:00 [##] 100.0%
> pkg-config-0.29.2 498KiB 15.2MiB/s 00:00 [##] 100.0%
> guile-3.0.2 10.8MiB 7.9MiB/s 00:01 [##] 100.0%
> building /gnu/store/sflmgcfcdwizj7iyd3pfksdvrkc3pskb-config.scm.drv...
> building /gnu/store/7k17dvmcrdicjsdxmpvhss4p3i3d70j5-git.scm.drv...
> building /gnu/store/j9s3n7iqvh8pqkxkwy91nq3qynr1nby7-hash.scm.drv...
> building /gnu/store/r8l291ib8hswpym73861dnjfwbvhdk85-module-import.drv...
> building /gnu/store/yl0ycq39b7dwwavn4sv6px2nsd1l1nsz-module-import.drv...
> building 
> /gnu/store/z9zi710wk56i875x55pn93ziv6136vrl-module-import-compiled.drv...
> building 
> /gnu/store/9s4nxajz20r4hr7hzq8yfbdja1b6pkpv-module-import-compiled.drv...
> building 
> /gnu/store/a5b49zygqncj2nq1qwyn8kfxqcq3x0w8-compute-guix-derivation.drv...
> Computing Guix derivation for 'x86_64-linux'... /guix pull: error: You 

bug#54658: "pypi->guix-package, no wheel" test fails

[Maxime Devos]

Maxime Devos schreef op wo 13-04-2022 om 09:52 [+0200]:
> Ludovic Courtès schreef op wo 13-04-2022 om 08:48 [+0200]:
> > Hi,
> > 
> > Maxime Devos  skribis:
> > 
> > > I noticed "./pre-inst-env guix build guix" fails on my computer
> due to
> > > "pypi->guix-package, no wheel" failing.  Here is an excerpt from
> the log:
> > 
> > Which commit are you building for?  For x86_64-linux?
> > 
> > Current ‘guix’ package seems to be fine:
> 
> I can reproduce it in a Guix checkout for
> 855097683230b756ba28636bed03ce904b6f3589 with "make check
> TESTS=tests/pypi.scm". (x86_64-linux)
> 
> It appears to be non-deterministic though --  the first "make check
> TESTS=tests/pypi.scm" failed, but the later ones succeeded.
> 
> I'll try adding some pk debugging and running it in a loop.

I added some pk:

;;; (found (package (name "python-foo") (version "1.0.0") (source (origin 
(method url-fetch) (uri (pypi-uri "foo" version)) (sha256 (base32 
"03rsmi1ricql316vak5gs89prv8494k1j7cgcgj7a763bcd6n4fa" (build-system 
python-build-system) (propagated-inputs (list python-bar python-foo)) 
(native-inputs (list python-pytest)) (home-page "http://example.com;) (synopsis 
"summary") (description "summary") (license license:lgpl2.0)))

;;; (foo@1.0.0 (package (name "python-foo") (version "1.0.0") (source (origin 
(method url-fetch) (uri (pypi-uri "foo" version)) (sha256 (base32 
"0z67xsvpivl9509m5l7n369nakszvnvm7ird09qgs6vn5pwqcl35" (build-system 
python-build-system) (propagated-inputs (list python-bar python-foo)) 
(native-inputs (list python-pytest)) (home-page "http://example.com;) (synopsis 
"summary") (description "summary") (license license:lgpl2.0)))

;;; (foo@?? (package (name "python-foo") (version "1.0.0") (source (origin 
(method url-fetch) (uri (pypi-uri "foo" version)) (sha256 (base32 
"03rsmi1ricql316vak5gs89prv8494k1j7cgcgj7a763bcd6n4fa" (build-system 
python-build-system) (

The problem is that the hash of 'found' and 'found@1.0.0' doesn't match :

03rsmi1ricql316vak5gs89prv8494k1j7cgcgj7a763bcd6n4fa
0z67xsvpivl9509m5l7n369nakszvnvm7ird09qgs6vn5pwqcl35

TBI ...
diff --git a/tests/pypi.scm b/tests/pypi.scm
index 88bb0a3116..359dd58bb1 100644
--- a/tests/pypi.scm
+++ b/tests/pypi.scm
@@ -245,7 +245,7 @@ Requires-Dist: pytest (>=3.1.0); extra == 'testing'
   (string-length test-json-1)))
  ("https://example.com/foo-1.0.0-py2.py3-none-any.whl; #f)
  (_ (error "Unexpected URL: " url)
-(match (pypi->guix-package "foo")
+(match (pk 'found (pypi->guix-package "foo"))
   (('package
  ('name "python-foo")
  ('version "1.0.0")
@@ -265,10 +265,10 @@ Requires-Dist: pytest (>=3.1.0); extra == 'testing'
(and (string=? (bytevector->nix-base32-string
test-source-hash)
   hash)
-(equal? (pypi->guix-package "foo" #:version "1.0.0")
-(pypi->guix-package "foo"))
-(guard (c ((error? c) #t))
-  (pypi->guix-package "foo" #:version "42"
+(equal? (pk 'foo@1.0.0 (pypi->guix-package "foo" #:version "1.0.0"))
+(pk 'foo@?? (pypi->guix-package "foo")))
+(guard (c ((error? c) (pk 'c c #t)))
+  (pk 'n (pypi->guix-package "foo" #:version "42")
   (x
(pk 'fail x #f))
 


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

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Attila Lendvai]

> I don't expect /run/current-system/locale to exist inside the build
> container. Maybe try
>
> (setenv "GUIX_LOCPATH" #+(file-append glibc-locales "/lib/locale"))
> ;; for testing
> ((@ (guix build utils) invoke)
> #+(file-append coreutils "/bin/ls") (getenv "GUIX_LOCPATH"))
>
> instead?


thank you, this works indeed as a band aid:

(setenv "GUIX_LOCPATH" #+(file-append glibc-locales "/lib/locale"))
(setlocale LC_ALL "en_US.utf8")

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“If a nation expects to be ignorant and free, in a state of civilization, it 
expects what never was and never will be.”
— Thomas Jefferson (1743–1826)

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Maxime Devos]

Attila Lendvai schreef op wo 13-04-2022 om 07:51 [+]:
> hrm... this is not relevant here, only a related thought: things
> can go wrong in the GEXP serialization, too: if the writing side
> and the reading side doesn't use the same character encoding.
> locale should be set explicitly at the relevant entry points.

Serialisation is always done in UTF-8, search for UTF-8 in (guix gexp).
I don't know if deserialisation of the script in done in UTF-8, though
it should be done that way.

Also, using the same character encoding is not sufficient, the
character encoding must also encode all characters (in practice, that
means UTF-8).

Greetings,
Maxime.


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

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Maxime Devos]

Attila Lendvai schreef op wo 13-04-2022 om 07:51 [+]:
> i'm not sure why the wrong locale breaks file-system walking and deleting, 
> though.
> 
> i assume if every function in guile uses/assumes the same locale (character
> encoding), then both directions through the guile FFI should be idempotent, 
> no?
> and i think both ASCII and UTF-8 are idempotent wrt C bytes <-> scheme string
> conversions.

The problem is that the default character encoding is ANSI_X3.4-1968
(US-ASCII) and any bytes above 127 makes things non-ASCII.

Also, the string procedures internally always use UTF-8 (or possibly
ISO-85519-1 as an optimisation?), they are not raw bytes instead they
can be consideres a vector of characters (string-ref returns
characters, not bytes, and doesn't use byte positions).

>  IOW, it's only the displaying of the chars that should be broken,
>  not file operations.

LANG=bogus guile
(guile-user)> (setlocale LC_ALL)
(guile-user)> (use-modules (ice-9 i18n))
(guile-user)> (locale-encoding)
(guile-user)> (locale-encoding)
$2 = "ANSI_X3.4-1968"

Apparently the fallback encoding is ‘ANSI_X3.4-1968’.  Let's take a
look at this encoding.  According to IANA
(https://www.iana.org/assignments/character-sets/character-sets.xhtml),
this character encoding can also be named ‘US-ASCII’ and is specified
in RFC2046.  Some excerpts:

   "US-ASCII" does not indicate an arbitrary 7-bit
   character set[sic], but specifies that all octets in the body must
   be interpreted as characters according to the US-ASCII character
   set.

so it looks like, say, é cannot be encoded as US-ASCII, it does not
belong to the character set of the encoding.  More generally, anything
beyond the 127 (Unicode) codepoint cannot be encoded in ANSI_X3.4-1968.

Let's test this (in a new REPL with an UTF-8 locale):

((@ (ice-9 iconv) string->bytevector) "é" "ANSI_X3.4-1968")
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Throw to key `encoding-error' with args `("put-char" "conversion to port 
encoding failed" 84 # #\é)'.

((@ (ice-9 iconv) string->bytevector) "é" "ANSI_X3.4-1968" 'substitute)
$2 = #vu8(63)
((@ (rnrs bytevectors) utf8->string) #vu8(63))
$3 = "?"

and the other direction:

((@ (ice-9 iconv) bytevector->string) #vu8(128) "ANSI_X3.4-1968" 'substitute)
$5 = "�" ;; why #\� and not #\?? I don't know, I guess Guile is inconsistent

(FWIW, I would throw an decoding-error here instead of silently corrupting the
file names.)

Greetings,
Maxime.


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

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Maxime Devos]

Attila Lendvai schreef op wo 13-04-2022 om 07:51 [+]:
> i don't understand why the setlocale call in gnu-build-system's
> install-locale works, but my setlocale kludge in git-download doesn't.

I don't expect /run/current-system/locale to exist inside the build
container.  Maybe try

   (setenv "GUIX_LOCPATH" #+(file-append glibc-locales "/lib/locale"))
   ;; for testing
   ((@ (guix build utils) invoke)
#+(file-append coreutils "/bin/ls") (getenv "GUIX_LOCPATH"))

instead?

gnu-build-system has a (variant of) glibc-locales in its (implicit)
inputs, so there GUIX_LOCPATH can be set to the /gnu/store/.../locales
file name, in the 'set-paths' procedure.

> i even tried to add glibc-locale as native-inputs to the package in question, 
> but it didn't help.

Building the package and downloading the source code are separate steps
(derivations), they don't automatically have access to each other's
inputs.

Greetings,
Maxime


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

bug#54658: "pypi->guix-package, no wheel" test fails

[Maxime Devos]

Ludovic Courtès schreef op wo 13-04-2022 om 08:48 [+0200]:
> Hi,
> 
> Maxime Devos  skribis:
> 
> > I noticed "./pre-inst-env guix build guix" fails on my computer due to
> > "pypi->guix-package, no wheel" failing.  Here is an excerpt from the log:
> 
> Which commit are you building for?  For x86_64-linux?
> 
> Current ‘guix’ package seems to be fine:

I can reproduce it in a Guix checkout for
855097683230b756ba28636bed03ce904b6f3589 with "make check
TESTS=tests/pypi.scm". (x86_64-linux)

It appears to be non-deterministic though --  the first "make check
TESTS=tests/pypi.scm" failed, but the later ones succeeded.

I'll try adding some pk debugging and running it in a loop.

Greetings,
Maxime.


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

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Attila Lendvai]

> * LANG should be set, because it is in #:leaked-env-vars (see
> guix/git-download.scm). I don't know whose LANG it is though
> -- the user's, or the daemon's?


if i add this to the gexp:

(simple-format (current-error-port)
   "LANG is '~A'~%"
   (getenv "LANG"))
(setenv "LANG" "en_US.utf8")
(setenv "GUIX_LOCPATH" "/run/current-system/locale")
(setlocale LC_ALL (getenv "LANG"))

i see:

LANG is ''
Backtrace:
   2 (primitive-load "/gnu/store/z4bis94jg0s0y0xj1xbmliv7xs8?")
In ice-9/eval.scm:
619:8  1 (_ #f)
In unknown file:
   0 (setlocale 6 "en_US.utf8")

ERROR: In procedure setlocale:
In procedure setlocale: Invalid argument


> * GUIX_LOCPATH is not leaked.


it's the same if i add GUIX_LOCPATH to the #:leaked-env-vars and don't setenv 
it explicitly.


> * Even if it was, I don't think that /gnu/store/...glibc-locales
> would be accessible from the build container (though you could give
> it a try?).


i didn't check this specifically, but i'm afraid you are right, and this is why 
my kludge doesn't work.


> * So perhaps GUIX_LOCPATH needs to be set in the gexp in
> guix/git-download.scm, + some setlocale as done by
> gnu-build-system.


i don't understand why the setlocale call in gnu-build-system's install-locale 
works, but my setlocale kludge in git-download doesn't.

i even tried to add glibc-locale as native-inputs to the package in question, 
but it didn't help.


> * Long-term, it could be interesting to remove the
> ‘file name = string encoded in current locale's encoding’
> assumption from Guile.


i'm not sure why the wrong locale breaks file-system walking and deleting, 
though.

i assume if every function in guile uses/assumes the same locale (character 
encoding), then both directions through the guile FFI should be idempotent, no? 
and i think both ASCII and UTF-8 are idempotent wrt C bytes <-> scheme string 
conversions. IOW, it's only the displaying of the chars that should be broken, 
not file operations.

or am i wrong to assume this?

or maybe the character encoding algo used in guile's FFI silently emits actual 
question marks in place of bytes that are outside the valid range of the 
encoding used? if so, that's not a very defensive way of coding, and it's 
eating up hours of my life...

hrm... this is not relevant here, only a related thought: things can go wrong 
in the GEXP serialization, too: if the writing side and the reading side 
doesn't use the same character encoding. locale should be set explicitly at the 
relevant entry points.

i'd appreciate if someone could help me come up with at least a kludge, so that 
i could make progress until it's fixed properly.

thanks for your insights Maxime,

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
If you never heal from what hurt you, you'll bleed on people who didn't cut you.

bug#54658: "pypi->guix-package, no wheel" test fails

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> I noticed "./pre-inst-env guix build guix" fails on my computer due to
> "pypi->guix-package, no wheel" failing.  Here is an excerpt from the log:

Which commit are you building for?  For x86_64-linux?

Current ‘guix’ package seems to be fine:

--8<---cut here---start->8---
$ guix describe
Generation 210  Apr 11 2022 09:34:10(current)
  guix 7da907f
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 7da907f90e74a4edf96d76ee457ff958265ef8d4
$ guix weather guix
computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  100.0% substitutes available (1 out of 1)
  at least 158.4 MiB of nars (compressed)
  303.7 MiB on disk (uncompressed)

  971 queued builds
  powerpc64le-linux: 504 (51.9%)
  i686-linux: 140 (14.4%)
  x86_64-linux: 327 (33.7%)
  build rate: 85.17 builds per hour
  armhf-linux: 22.58 builds per hour
  i686-linux: 21.50 builds per hour
  powerpc64le-linux: 8.06 builds per hour
  aarch64-linux: 23.71 builds per hour
  x86_64-linux: 10.05 builds per hour
looking for 1 store items on https://bordeaux.guix.gnu.org...
https://bordeaux.guix.gnu.org
  100.0% substitutes available (1 out of 1)
  41.8 MiB of nars (compressed)
  303.7 MiB on disk (uncompressed)
  2.105 seconds per request (2.1 seconds in total)
  0.5 requests per second
  (continuous integration information unavailable)
$ guix build guix --no-grafts -d
/gnu/store/vz0lxjxh0fykjk2rsgjycx59svclpj3v-guix-1.3.0-24.2fb4304.drv
--8<---cut here---end--->8---

Ludo’.

bug#54545: [Guix Home] ‘shepherd’ started twice?

[Andrew Tropin]

On 2022-04-12 20:28, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin  skribis:
>
>> Prepared a patch series, which fixes the issues and sligthly adjusts the
>> way home shepherd reload configuration logic works, now it happens only
>> if configuration is changed and also it doesn't try to be smart and
>> start a shepherd if it's not started yet.
>>
>> From d2578f8924217451ca20f0b61fd6f9b9d31c930d Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin 
>> Date: Tue, 12 Apr 2022 11:30:58 +0300
>> Subject: [PATCH 1/3] home: shepherd: Prevent launching the second instance.
>>
>> * gnu/home/services/shepherd.scm: Prevent launching the second instance.
>
> I applied this one with a convention commit log, including a “Fixes”
> line, which is important for traceability.  (Please check the ChangeLog
> convention for future patches.)
>

Read it from time to time, but the information about contribution
guidelines is too much spreaded, for example I can't find info about
Fixes line even with search, but maybe I just not very attentive.

https://guix.gnu.org/en/manual/devel/en/guix.html#Sending-a-Patch-Series-1
https://www.gnu.org/prep/standards/standards.html#Change-Logs

>> From 56d16b4cd511f6837329b888dade0c6d6da4d89d Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin 
>> Date: Tue, 12 Apr 2022 12:19:50 +0300
>> Subject: [PATCH 2/3] home: shepherd: Use run-on-change to reload shepherd
>>  config.
>>
>> * gnu/home/services/shepherd.scm: Add shepherd configuration to
>> XDG_CONFIG_HOME and use it instead of full path to the store. It's necessary
>> to use run-on-change service.
>
> [...]
>
>> +++ b/gnu/home/services/shepherd.scm
>> @@ -105,27 +105,30 @@ (define (launch-shepherd-gexp config)
>>  (system*
>>   #$(file-append shepherd "/bin/shepherd")
>>   "--logfile"
>> - (string-append log-dir "/shepherd.log")
>> - "--config"
>> - #$(home-shepherd-configuration-file services shepherd)
>> + (string-append log-dir "/shepherd.log")
>>  #~"")))
>>  
>>  (define (reload-configuration-gexp config)
>>(let* ((shepherd (home-shepherd-configuration-shepherd config))
>>   (services (home-shepherd-configuration-services config)))
>> -#~(system*
>> -   #$(file-append shepherd "/bin/herd")
>> -   "load" "root"
>> -   #$(home-shepherd-configuration-file services shepherd
>> +#~(when (file-exists?
>> + (string-append
>> +  (or (getenv "XDG_RUNTIME_DIR")
>> +  (format #f "/run/user/~a" (getuid)))
>> +  "/shepherd/socket"))
>> +(system*
>> + #$(file-append shepherd "/bin/herd")
>> + "load" "root"
>> + #$(home-shepherd-configuration-file services shepherd)
>>  
>> -(define (ensure-shepherd-gexp config)
>> -  #~(if (file-exists?
>> - (string-append
>> -  (or (getenv "XDG_RUNTIME_DIR")
>> -  (format #f "/run/user/~a" (getuid)))
>> -  "/shepherd/socket"))
>> -#$(reload-configuration-gexp config)
>> -#$(launch-shepherd-gexp config)))
>> +(define (add-shepherd-configuration config)
>> +  (let* ((shepherd (home-shepherd-configuration-shepherd config))
>> + (services (home-shepherd-configuration-services config)))
>> +`(("shepherd/init.scm"
>> +   ,(home-shepherd-configuration-file services shepherd)
>> +
>> +(define (home-shepherd-run-on-change config)
>> +  `(("files/.config/shepherd/init.scm" ,(reload-configuration-gexp 
>> config
>
> How does this relate to the bug at hand?
>
>   https://issues.guix.gnu.org/54545
>

Almost directly.

During activation if there is no shepherd process we tried to launch a
new one, which was useful back in the days, when I was testing changes
frequently, but can be kinda unexpected for user, if they stopped
Shepherd for some reason, but during activation it started again
automatically.  As we discussed earlier:

>>> Probably we need to do config reload using on-change service and also
>>> not trigger on-change stuff if user isn't logged in.

>>   Makes sense.

it would be nice to reload configuration only if it's changed.  To make
run-on-change work we need to store a config somewhere in
home-environment, to make it possible to compare with previous
generation.  files/.config/shepherd/init.scm looks like a good match
here, in addition to on-change functionality it increases explorability.

> As discussed elsewhere, I find it less ambiguous to pass store file
> names for configuration files.
>

I don't know how much value in it, but we can keep those lines:

>> - "--config"
>> - #$(home-shepherd-configuration-file services shepherd)

> 
> That can be a drawback in some cases, for daemons that won’t be able
> to load a new config from a different location, but shepherd is not in
> that category: it can load a config file via ‘herd load root’ from any
> place.
>