bug#42175: "pulseaudio? #f" setting does not prevent pulseaudio from autostarting

[Maxim Cournoyer]

Hello,

Leo Prikler  writes:

> I don't think pulseaudio autostarting is governed by alsa.  There are
> two options you can try.
>
> 1. disable autospawning through configuration.  For that, try setting
> the client-conf field of the pulseaudio-configuration to 
>   '((autospawn . no))
> 2. Removing the pulseaudio package from gnome and anywhere else it
> might be propagated.  (I don't think it is propagated in other
> services).

Indeed, if you look at (gnu services sound), you'll see that what
pulseaudio? #t does (the default) is to add this to ALSA's asound.conf
file:

--8<---cut here---start->8---
`("# Use PulseAudio by default
pcm_type.pulse {
  lib \"" ,#~(string-append #$alsa-plugins:pulseaudio
"/lib/alsa-lib/libasound_module_pcm_pulse.so") "\"
}

ctl_type.pulse {
  lib \"" ,#~(string-append #$alsa-plugins:pulseaudio
"/lib/alsa-lib/libasound_module_ctl_pulse.so") "\"
}

pcm.!default {
  type pulse
  fallback \"sysdefault\"
  hint {
show on
description \"Default ALSA Output (currently PulseAudio Sound Server)\"
  }
}

ctl.!default {
  type pulse
  fallback \"sysdefault\"
}\n\n"
--8<---cut here---end--->8---

This configures ALSA applications to use pulseaudio as its default
output.  Many non-ALSA applications will attempt to use pulseaudio and
the configuration of it being allowed to autostart or not is to be made
at the level of pulseaudio-service-type, as pointed out in Liliana's
reply (thanks!).

Closing,

Maxim

bug#53668: Updating substitutes on LAN hosts dies unexpectedly

[Maxim Cournoyer]

Hi Simon,

Simon Streit  writes:

> Hello,
>
> quite often, and quite randomly I run into this situation that whenever
> Guix tries to rebuild a profile, and sometimes while downloading from
> local Guix hosts sharing their store items, the process will crash with
> the following error:
>
> ~ $1 reconfigure
> substitute: updating substitutes from 'http://192.168.0.157:3000'...  
> 56.3%Backtrace:
> substitute: In ice-9/boot-9.scm:
> substitute:   1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
> substitute: In unknown file:
> substitute:   16 (apply-smob/0 #)
> substitute: In ice-9/boot-9.scm:
> substitute: 724:2 15 (call-with-prompt _ _ # default-prompt-handle…>)
> substitute: In ice-9/eval.scm:
> substitute: 619:8 14 (_ #(#(#)))
> substitute: In guix/ui.scm:
> substitute:2206:7 13 (run-guix . _)
> substitute:   2169:10 12 (run-guix-command _ . _)
> substitute: In ice-9/boot-9.scm:
> substitute:   1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
> substitute:   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
> substitute: In guix/scripts/substitute.scm:
> substitute:757:18  9 (_)
> substitute:348:26  8 (process-query # _ #:cache-urls _ 
> #:acl _)
> substitute: In guix/substitutes.scm:
> substitute:365:27  7 (lookup-narinfos/diverse _ _ # 7f309690d320 …> …)
> substitute:322:31  6 (lookup-narinfos _ _ #:open-connection _ # _)
> substitute:245:26  5 (fetch-narinfos _ _ #:open-connection _ # _)
> substitute: In ice-9/boot-9.scm:
> substitute:   1685:16  4 (raise-exception _ #:continuable? _)
> substitute:   1685:16  3 (raise-exception _ #:continuable? _)
> substitute:   1780:13  2 (_ #< components: 
> (#<…>)
> substitute:   1685:16  1 (raise-exception _ #:continuable? _)
> substitute:   1685:16  0 (raise-exception _ #:continuable? _)
> substitute:
> substitute: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> substitute: Wrong type (expecting exact integer): #f
> guix system: error: 
> `/gnu/store/kcc8zh1fhp05wgw2m48w3gk228j39f5q-guix-1.3.0-21.e427593/bin/guix 
> substitute' died unexpectedly

I suffer from this routinely on my slow HDD machine.  I attribute the
failure to some timeout that isn't reported correctly by guile-ssh.
Perhaps related to
https://github.com/artyom-poptsov/guile-ssh/issues/29; there's a new
update of guile-ssh to try that Artyom has put up on guix-patches; we
should test it.

Thanks,

Maxim

bug#53204: [patch] font-cns11643: ... unzip error

[Brendan Tildesley]

> On 01/31/2022 1:35 PM Maxime Devos  wrote:
> 
>  
> Brendan Tildesley schreef op ma 31-01-2022 om 12:23 [+0100]:
> > I just noticed there is also this:
> > 
> > starting phase `install-locale'
> > warning: failed to install 'en_US.utf8' locale: Invalid argument
> > 
> > 
> > It occurs for other font-build-system fonts too. Adding glibc-utf8-locales 
> > or glibc-locales didn't fix it.
> > I don't understand it because its just based off gnu-build-system which 
> > doesn't have that issue.
> > 
> > It doesn't GUIX_LOCPATH either
> 
> Perhaps the cause is that font-build-system doesn't have glibc among
> its (implicit) native-inputs, and hence there's no GUIX_LOCPATH search
> path (see )?
> 
> Adding glibc to the native-inputs might work.
> 
> Greetings,
> Maxime. 

Fixed it (attached).From 7af44a6109dae1c056abb10d18e8eecb7113e836 Mon Sep 17 00:00:00 2001
From: Brendan Tildesley 
Date: Mon, 31 Jan 2022 12:55:23 +1100
Subject: [PATCH] gnu: font-cns11643: Update to 98.1.20220104.

* gnu/packages/fonts.scm (font-cns11643): Update to 98.1.20220104.
Use stable archive.org link.
Only extract the files we need, and fix an error caused by unzip
"missmatch local filename" warnings.
---
 gnu/packages/fonts.scm | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 8afb453970..e3a974b6b0 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -18,7 +18,7 @@
 ;;; Copyright © 2017 José Miguel Sánchez García 
 ;;; Copyright © 2017 Alex Griffin 
 ;;; Copyright © 2017 Clément Lassieur 
-;;; Copyright © 2017 Brendan Tildesley 
+;;; Copyright © 2017, 2022 Brendan Tildesley 
 ;;; Copyright © 2017, 2018, 2019, 2020 Arun Isaac 
 ;;; Copyright © 2017 Mohammed Sadiq 
 ;;; Copyright © 2018 Charlie Ritter 
@@ -530,17 +530,26 @@ (define-public font-adobe-source-han-sans
 (define-public font-cns11643
   ;; Since upstream doesn't provide any version numbers, the date of the last
   ;; edit is used, taken from https://data.gov.tw/dataset/5961
-  ;; XXX: The source is also updated in-place, so it may be desirable to mirror
-  ;; it elsewhere to avoid suddenly losing the current source file.
+  ;; Use the archive.org mirror since the source is updated in place.
   (package
 (name "font-cns11643")
-(version "98.1.20180605")
+(version "98.1.20220104")
 (source (origin
   (method url-fetch)
-  (uri "http://www.cns11643.gov.tw/AIDB/Open_Data.zip;)
+  (uri (string-append
+"https://web.archive.org/web/20220119072046/;
+"http://www.cns11643.gov.tw/AIDB/Open_Data.zip;))
   (sha256
(base32
-"000a9whrjr1cd4pjc23pbl60zwkq3wcb5g61p9qi7fn3hwkp0kyw"
+"0ygq7a0gb0nah74wlvf84kss68k514dml1wkcihv2s5v5j9rys0y"
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (replace 'unpack
+   (lambda* (#:key source #:allow-other-keys)
+ ;; Prevent filename warnings from causing an error, and only
+ ;; extract the .ttf files we need.
+ (invoke "unzip" "-j" source "Open_Data/Fonts/*ttf"))
 (build-system font-build-system)
 (home-page "http://www.cns11643.gov.tw/AIDB/welcome.do;)
 (synopsis "CJK TrueType fonts, TW-Kai and TW-Sung")
-- 
2.34.0

bug#53668: Updating substitutes on LAN hosts dies unexpectedly

[Simon Streit]

Simon Streit  writes:
> I just activated the cache. It hasn't crashed so far.

No, it did crash again.

bug#53668: Updating substitutes on LAN hosts dies unexpectedly

[Simon Streit]

Hello Guillaume,

Guillaume Le Vaillant  writes:

> I have also seen this kind of crashes on my LAN.
> I don't know what causes this issue, but I noticed that it has happened
> less often since I activated the cache for the guix-publish service.

I just activated the cache. It hasn't crashed so far.

bug#53645: Unable to guix pull on pinebook pro

[Pierre Langlois]

Hi there,

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
> I took a look but I don't know what's up with
>
>> g++ [...] -o cc1 [...] 
>> collect2: fatal error: ld terminated with signal 9 [Killed]
>
> Seems like the linking step failed somehow?

I would guess that the build ran out of memory, that can happen with the
pinebookpro's mere 4G. Do you have some swap space allocated? I've had
to do that on my rockpro64 (same chip) for guix pull to eventually
succeed.

Here's an example to create a quick swapfile in case you're not
familiar, as root:

  # Create 10G
  dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240
  # Enable it
  chmod 600 /mnt/swapfile
  mkswap /mnt/swapfile
  swapon /mnt/swapfile

Hope this helps! Ideally you wouldn't have to build so much, but I'm
afraid we don't have aarch64 substitutes ready at the moment :-/.

Cheers,
Pierre



signature.asc
Description: PGP signature

bug#53670: ipython CVE-2022-21699

[Leo Famulari]

Python (Interactive Python) is a command shell for interactive computing
in multiple programming languages, originally developed for the Python
programming language. Affected versions are subject to an arbitrary code
execution vulnerability achieved by not properly managing cross user
temporary files. This vulnerability allows one user to run code as
another on the same machine. 

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21699
https://github.com/ipython/ipython/security/advisories/GHSA-pq7m-3gw7-gq5x

bug#53415: binutils-mesboot1-2.14 configure phase fails, In procedure stat: No such file or directory: "config.status"

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> I've seen this failure consistently on one of the machines behind
>> bordeaux.guix.gnu.org, you can see the full logs via following the "View
>> build" links here [1].
>>
>> 1: 
>> http://data.guix.gnu.org/gnu/store/xd8rnmr0k3fhfhilzi66hnggsnx67d5i-binutils-mesboot1-2.14.drv
>>
>> I've tried building multiple times on the machine where the failures
>> occurred, and it's not once succeeded.
>>
>>>From looking at the kept build directory, the config.status file doesn't
>> exist. There is config.status.VX1nZz, but it's empty.
>>
>>
>>
>> starting phase `configure'
>> running ./configure --disable-nls --disable-shared --disable-werror
>> --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu
>> --with-sysroot=/
>> --prefix=/gnu/store/gvmha2v54svwzxigcbap8862rg3fya0w-binutils-mesboot1-2.14
>> error: in phase 'configure': uncaught exception:
>> system-error "stat" "~A: ~S" ("No such file or directory" "config.status") 
>> (2) 
>> phase `configure' failed after 0.0 seconds
>
> I just tried this on my laptop:
>
>   guix build \
> /gnu/store/xd8rnmr0k3fhfhilzi66hnggsnx67d5i-binutils-mesboot1-2.14.drv \
> --check
>
> and the ‘configure’ phase completes without problems.  I have:
>
> $ uname -srv
> Linux 5.15.12-gnu #1 SMP 1
>
> This reminds me of:
>
>   https://issues.guix.gnu.org/49985
>   https://issues.guix.gnu.org/45165
>
> Could it be something with the kernel options, as discussed at
> ?

I was on the following Linux from Guix revision
fe58f05b2482fd45c41fe324ac0d393093dc163e:

Linux 5.15.13-gnu #1 SMP 1

I've tried reconfiguring with f8633a739511e8d5bef93b18b346efb69b91ac8e
which provides Linux 5.15.12, but I see the same behaviour.

Looking at the successful build log, I've realised that the ./configure
script is probably crashing, not producing the config.status file, which
is causing the exception seen.

I've tried stracing everything, and attached the portion from around
where ./configure starts, to the Guile exception for the end of the
build.

I did notice some suspicious looking bits like the following:

stat("/tmp/guix-build-binutils-mesboot1-2.14.drv-0", 0xd058) = -1 EOVERFLOW 
(Value too large for defined data type)

502   write(2, "running ./configure --disable-nl"..., 222 
500   <... read resumed>"starting phase `configure'\n", 4096) = 27
502   <... write resumed>)  = 222
502   rt_sigaction(SIGINT, {sa_handler=SIG_IGN, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x4d4b10},  
500   write(4, "gmlo\0\0\0\0.\0\0\0\0\0\0\0@ build-log 502 "..., 64 
502   <... rt_sigaction resumed>{sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x4d4b10}, 8) = 0
502   rt_sigaction(SIGQUIT, {sa_handler=SIG_IGN, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x4d4b10},  
500   <... write resumed>)  = 64
502   <... rt_sigaction resumed>{sa_handler=SIG_DFL, sa_mask=[], 
sa_flags=SA_RESTORER, sa_restorer=0x4d4b10}, 8) = 0
500   pselect6(13, [12], NULL, NULL, {tv_sec=43200, tv_nsec=0}, NULL 

502   clone(child_stack=NULL, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD 
500   <... pselect6 resumed>)   = 1 (in [12], left {tv_sec=43199, 
tv_nsec=95669})
500   read(12, "running ./configure --disable-nl"..., 4096) = 222
500   write(4, "gmlo\0\0\0\0\362\0\0\0\0\0\0\0@ build-log 502 "..., 264) = 264
500   pselect6(13, [12], NULL, NULL, {tv_sec=43200, tv_nsec=0}, NULL 

515   set_robust_list(0xa2eb60, 24 
502   <... clone resumed>, child_tidptr=0xa2eb50) = 14
515   <... set_robust_list resumed>)= 0
515   execve("./configure", ["./configure", "--disable-nls", 
"--disable-shared", "--disable-werror", "--build=i686-unknown-linux-gnu", 
"--host=i686-unknown-linux-gnu", "--with-sysroot=/", 
"--prefix=/gnu/store/gvmha2v54svw"...], 0x1467930 /* 19 vars */ 
502   wait4(14,  
515   <... execve resumed>) = 0
515   [ Process PID=515 runs in 32 bit mode. ]
515   open("/dev/tty", O_RDWR)  = -1 ENXIO (No such device or address)
515   ioctl(0, TCGETS, 0xd180)  = -1 ENOTTY (Inappropriate ioctl for 
device)
515   brk(NULL) = 0x80b6000
515   brk(0x80b6002)= 0x80b6002
515   getuid()  = 999
515   getgid()  = 3
515   geteuid() = 999
515   getegid() = 3
515   brk(0x80b6049)= 0x80b6049
515   time(NULL)= 1643658451 (2022-01-31T19:47:31+)
515   brk(0x80b6139)= 0x80b6139
515   brk(0x80b6229)= 0x80b6229
515   sigprocmask(SIG_BLOCK, NULL, [])  = 0
515   brk(0x80b6231)= 0x80b6231
515   brk(0x80b623d)= 0x80b623d
515   brk(0x80b6249)= 0x80b6249
515   brk(0x80b6261)= 0x80b6261
515   brk(0x80b626d)= 0x80b626d
515   

bug#53668: Updating substitutes on LAN hosts dies unexpectedly

[Guillaume Le Vaillant]

Simon Streit  skribis:

> Hello,
>
> quite often, and quite randomly I run into this situation that whenever
> Guix tries to rebuild a profile, and sometimes while downloading from
> local Guix hosts sharing their store items, the process will crash with
> the following error:
>
> ~ $1 reconfigure
> substitute: updating substitutes from 'http://192.168.0.157:3000'...  
> 56.3%Backtrace:
> substitute: In ice-9/boot-9.scm:
> substitute:   1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
> substitute: In unknown file:
> substitute:   16 (apply-smob/0 #)
> substitute: In ice-9/boot-9.scm:
> substitute: 724:2 15 (call-with-prompt _ _ # default-prompt-handle…>)
> substitute: In ice-9/eval.scm:
> substitute: 619:8 14 (_ #(#(#)))
> substitute: In guix/ui.scm:
> substitute:2206:7 13 (run-guix . _)
> substitute:   2169:10 12 (run-guix-command _ . _)
> substitute: In ice-9/boot-9.scm:
> substitute:   1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
> substitute:   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
> substitute: In guix/scripts/substitute.scm:
> substitute:757:18  9 (_)
> substitute:348:26  8 (process-query # _ #:cache-urls _ 
> #:acl _)
> substitute: In guix/substitutes.scm:
> substitute:365:27  7 (lookup-narinfos/diverse _ _ # 7f309690d320 …> …)
> substitute:322:31  6 (lookup-narinfos _ _ #:open-connection _ # _)
> substitute:245:26  5 (fetch-narinfos _ _ #:open-connection _ # _)
> substitute: In ice-9/boot-9.scm:
> substitute:   1685:16  4 (raise-exception _ #:continuable? _)
> substitute:   1685:16  3 (raise-exception _ #:continuable? _)
> substitute:   1780:13  2 (_ #< components: 
> (#<…>)
> substitute:   1685:16  1 (raise-exception _ #:continuable? _)
> substitute:   1685:16  0 (raise-exception _ #:continuable? _)
> substitute:
> substitute: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> substitute: Wrong type (expecting exact integer): #f
> guix system: error: 
> `/gnu/store/kcc8zh1fhp05wgw2m48w3gk228j39f5q-guix-1.3.0-21.e427593/bin/guix 
> substitute' died unexpectedly
>
>
> Unfortunately this crash happens at random.  Other times it goes
> through.  Current checkout is ff14bc60e56fb0c6636da1da9a850b7b04abb367,
> which isn't the most current, I know.  I've been observing this behavior
> since some time now, and haven't figured out what the reason is behind
> it yet.  The error message looks similar to [1].
>
> The way this error appears is, that I usually have one host that I
> upgrade first, and then share the checkout and the store between hosts
> to speed up the upgrading process locally.  Unfortunately the updater
> will crash randomly whenever the host starts scanning other hosts that
> are found through mDNS.  Sometimes this happens while fetching new
> packages into a profile.
>
> I've set up publishing:
>
> (service guix-publish-service-type
>   (guix-publish-configuration (host "0.0.0.0")
>   (port 3000)
>   (ttl #f)
>   (advertise? #t)))
>
> and of course host discovery in guix-service-type too.
>
>
> Kind regards
> Simon
>
>
> [1] https://issues.guix.gnu.org/52464

Hi,

I have also seen this kind of crashes on my LAN.
I don't know what causes this issue, but I noticed that it has happened
less often since I activated the cache for the guix-publish service.


signature.asc
Description: PGP signature

bug#53645: Unable to guix pull on pinebook pro

[Maxime Devos]

I took a look but I don't know what's up with

> g++ [...] -o cc1 [...] 
> collect2: fatal error: ld terminated with signal 9 [Killed]

Seems like the linking step failed somehow?

Greetings,
Maxime.


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

bug#53668: Updating substitutes on LAN hosts dies unexpectedly

[Simon Streit]

Hello,

quite often, and quite randomly I run into this situation that whenever
Guix tries to rebuild a profile, and sometimes while downloading from
local Guix hosts sharing their store items, the process will crash with
the following error:

--8<---cut here---start->8---
~ $1 reconfigure
substitute: updating substitutes from 'http://192.168.0.157:3000'...  
56.3%Backtrace:
substitute: In ice-9/boot-9.scm:
substitute:   1752:10 17 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In unknown file:
substitute:   16 (apply-smob/0 #)
substitute: In ice-9/boot-9.scm:
substitute: 724:2 15 (call-with-prompt _ _ #)
substitute: In ice-9/eval.scm:
substitute: 619:8 14 (_ #(#(#)))
substitute: In guix/ui.scm:
substitute:2206:7 13 (run-guix . _)
substitute:   2169:10 12 (run-guix-command _ . _)
substitute: In ice-9/boot-9.scm:
substitute:   1752:10 11 (with-exception-handler _ _ #:unwind? _ # _)
substitute:   1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In guix/scripts/substitute.scm:
substitute:757:18  9 (_)
substitute:348:26  8 (process-query # _ #:cache-urls _ 
#:acl _)
substitute: In guix/substitutes.scm:
substitute:365:27  7 (lookup-narinfos/diverse _ _ # …)
substitute:322:31  6 (lookup-narinfos _ _ #:open-connection _ # _)
substitute:245:26  5 (fetch-narinfos _ _ #:open-connection _ # _)
substitute: In ice-9/boot-9.scm:
substitute:   1685:16  4 (raise-exception _ #:continuable? _)
substitute:   1685:16  3 (raise-exception _ #:continuable? _)
substitute:   1780:13  2 (_ #< components: 
(#<…>)
substitute:   1685:16  1 (raise-exception _ #:continuable? _)
substitute:   1685:16  0 (raise-exception _ #:continuable? _)
substitute:
substitute: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
substitute: Wrong type (expecting exact integer): #f
guix system: error: 
`/gnu/store/kcc8zh1fhp05wgw2m48w3gk228j39f5q-guix-1.3.0-21.e427593/bin/guix 
substitute' died unexpectedly
--8<---cut here---end--->8---

Unfortunately this crash happens at random.  Other times it goes
through.  Current checkout is ff14bc60e56fb0c6636da1da9a850b7b04abb367,
which isn't the most current, I know.  I've been observing this behavior
since some time now, and haven't figured out what the reason is behind
it yet.  The error message looks similar to [1].

The way this error appears is, that I usually have one host that I
upgrade first, and then share the checkout and the store between hosts
to speed up the upgrading process locally.  Unfortunately the updater
will crash randomly whenever the host starts scanning other hosts that
are found through mDNS.  Sometimes this happens while fetching new
packages into a profile.

I've set up publishing:

--8<---cut here---start->8---
(service guix-publish-service-type
  (guix-publish-configuration (host "0.0.0.0")
  (port 3000)
  (ttl #f)
  (advertise? #t)))
--8<---cut here---end--->8---

and of course host discovery in guix-service-type too.


Kind regards
Simon


[1] https://issues.guix.gnu.org/52464

bug#53659: Fontmanager failing to build

[Pāladhammika via Bug reports for GNU Guix]

Hello Guix,

Build fails when saying that python3 is not found.
https://termbin.com/574m

All the best,
Pāladhammika

bug#53658: guix shell cache not working properly

[Guillaume Le Vaillant]

Hi,

With Guix at e217174b7b9046658ac3474d522bde192e9cffb4I have an issue
with the "guix shell -p ..." command, where I end up in a environment
for a profile I used previously instead of the profile specified in the
command line.

I can reproduce the issue this way:

--8<---cut here---start->8---
# Clear the profile cache
rm ${HOME}/.cache/guix/profiles/*

# Make some profiles
mkdir a
echo "(specifications->manifest '(\"gforth\"))" > a/manifest.scm
guix package -m a/manifest.scm -p a/profile
mkdir b
echo "(specifications->manifest '(\"smalltalk\"))" > b/manifest.scm
guix package -m b/manifest.scm -p b/profile

# The first attempt at using a profile when the cache is empty fails
guix shell -q -p a/profile -- gforth
> Backtrace:
>   10 (primitive-load "/home/guillaume/.config/guix/current/b…")
> In guix/ui.scm:
>2209:7  9 (run-guix . _)
>   2172:10  8 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
>   1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/status.scm:
> 802:4  6 (call-with-status-report _ _)
> In guix/scripts/environment.scm:
>951:12  5 (_)
> In guix/store.scm:
>   2123:24  4 (run-with-store #f # …)
> In guix/scripts/environment.scm:
>968:16  3 (_ _)
> In guix/store.scm:
>   1995:38  2 (_ #f)
>1473:0  1 (add-indirect-root #f "/home/guillaume/.cache/guix/prof…")
> In ice-9/boot-9.scm:
>   1685:16  0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure struct-vtable: Wrong type argument in position 1 (expecting 
> struct): #f

# Then using the first profile with the same command works
guix shell -q -p a/profile -- gforth
> Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
bye

# Using the second profile doesn't work
guix shell -q -p b/profile -- gst
> guix shell: erreur : gst : commande introuvable
> conseil : Vouliez-vous dire « gforth » ?

# But the second profile really has the gst program
ls b/profile/bin
> gst  gst-blox  gst-browser  gst-config  gst-convert  [...]

# In fact, using the second profile creates an environment for
# the first profile
guix shell -q -p b/profile -- gforth
> Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
bye

# And the profile cache only contains a link for the first profile instead
# of links for both profiles
ls ${HOME}/.cache/guix/profiles/
> hw7txclxu45xzbt4orha5d6zrgjej5ps4ve5n6je3cnblbg7fz2a
> last-expiry-cleanup

ls hw7txclxu45xzbt4orha5d6zrgjej5ps4ve5n6je3cnblbg7fz2a/bin
> gforth  gforth-0.7.3  gforth-fast  gforth-fast-0.7.3  [...]
--8<---cut here---end--->8---

bug#53659: (No Subject)

[Pāladhammika via Bug reports for GNU Guix]

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

All the best,
Pāladhammika

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

[Maxime Devos]

Grigory Shepelev schreef op ma 31-01-2022 om 15:48 [+0300]:
> The issue can be closed I guess. Thanks for your assistance.

> пн, 31 янв. 2022 г. в 00:06, Maxime Devos :
> > 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.

I don't think that modifying some git settings should break "guix
pull",
so I wouldn't close yet.

Greetings,
Maxime



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

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

[Grigory Shepelev]

The issue can be closed I guess. Thanks for your assistance.

пн, 31 янв. 2022 г. в 00:06, Maxime Devos :

> 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.
>
> Greetings,
> Maxime.
>

bug#53204: [patch] font-cns11643: ... unzip error

[Maxime Devos]

Brendan Tildesley schreef op ma 31-01-2022 om 12:23 [+0100]:
> I just noticed there is also this:
> 
> starting phase `install-locale'
> warning: failed to install 'en_US.utf8' locale: Invalid argument
> 
> 
> It occurs for other font-build-system fonts too. Adding glibc-utf8-locales or 
> glibc-locales didn't fix it.
> I don't understand it because its just based off gnu-build-system which 
> doesn't have that issue.
> 
> It doesn't GUIX_LOCPATH either

Perhaps the cause is that font-build-system doesn't have glibc among
its (implicit) native-inputs, and hence there's no GUIX_LOCPATH search
path (see )?

Adding glibc to the native-inputs might work.

Greetings,
Maxime.


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

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

[Attila Lendvai]

pull.scm does this with channel files, e.g. with /etc/guix/channels.scm:

(load* file (make-user-module '((guix channels

i.e. this way field values are EVAL'd. beside the big can of worms that this 
opens up, it also means that e.g. the name field must be quoted: (name 'guix).

then at other occurrences of channels, an sexp parser is used to read them, 
e.g. in the 'dependencies field of a .guix-channel entry. see 
READ-CHANNEL-METADATA in guix/channels.scm.

here the name field is not EVAL'd, and thus it must be specified without 
quotes: (name guix).

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

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Awareness isn’t something we own; awareness isn’t something we possess. 
Awareness is actually what we are.”
— Adyashanti (1962–)

bug#53204: [patch] font-cns11643: ... unzip error

[Brendan Tildesley]

> On 01/31/2022 10:18 AM Maxime Devos  wrote:
> 
>  
> Brendan Tildesley schreef op ma 31-01-2022 om 02:59 [+0100]:
> > I tried updating it but came across an unzip error, maybe unicode related. 
> > I've also noticed in my Icecat there are all these icons that are showing 
> > as random korean characters, so I wonder if my configuration is wrong 
> > somehow??:
> 
> Maybe add glibc-utf8-locales to the native-inputs of the package
> definition, such that an UTF-8 locale can be installed?
> 
> Greetings,
> Maxime.

I just noticed there is also this:

starting phase `install-locale'
warning: failed to install 'en_US.utf8' locale: Invalid argument


It occurs for other font-build-system fonts too. Adding glibc-utf8-locales or 
glibc-locales didn't fix it.
I don't understand it because its just based off gnu-build-system which doesn't 
have that issue.

It doesn't GUIX_LOCPATH either

bug#53655: haskell build system cannot build attoparsec

[Philip Munksgaard]

I'm trying to build a newer version of attoparsec than the one included in 
guix, namely version 0.14.4.

First of all, `guix import hackage -r attoparsec` fails, as far as I can tell 
because of the requirement to attoparsec-internal, with the following error:

```
$ guix import hackage -r attoparsec

Starting download of /tmp/guix-file.szLCRk
>From https://hackage.haskell.org/package/attoparsec/attoparsec-0.14.4.tar.gz...
 ….14.4.tar.gz  157KiB5.1MiB/s 00:00 [##] 100.0%
Backtrace:
   7 (primitive-load "/home/munksgaard/.config/guix/current/…")
In guix/ui.scm:
   2209:7  6 (run-guix . _)
  2172:10  5 (run-guix-command _ . _)
In guix/scripts/import.scm:
   124:11  4 (guix-import . _)
In guix/scripts/import/hackage.scm:
   129:26  3 (guix-import-hackage . _)
In guix/import/utils.scm:
   504:23  2 (recursive-import _ #:repo->guix-package _ #:guix-name _ …)
In srfi/srfi-1.scm:
   586:17  1 (map1 (("attoparsec-internal" #f)))
In guix/import/utils.scm:
   492:33  0 (lookup-node "attoparsec-internal" #f)

guix/import/utils.scm:492:33: In procedure lookup-node:
Wrong number of values returned to continuation (expected 2)
```

`guix import hackage attoparsec` succeeds, but I have to manually remove the 
dependency on attoparsec-internal, resulting in this file:

```
(define-module (gnu packages futhark)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix build-system haskell)
  #:use-module (guix licenses)
  #:use-module (guix git-download)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (gnu packages)
  #:use-module (gnu packages haskell)
  #:use-module (gnu packages haskell)
  #:use-module (gnu packages haskell-web)
  #:use-module (gnu packages haskell-xyz)
  #:use-module (gnu packages haskell-check)
  #:use-module (gnu packages haskell-crypto))

(package
  (name "ghc-attoparsec")
  (version "0.14.4")
  (source
(origin
  (method url-fetch)
  (uri (hackage-uri "attoparsec" version))
  (sha256
(base32 "0v4yjz4qi8bwhbyavqxlhsfb1iv07v10gxi64khmsmi4hvjpycrz"
  (build-system haskell-build-system)
  (inputs (list ghc-scientific))
  (native-inputs
(list ghc-quickcheck
  ghc-quickcheck-unicode
  ghc-tasty
  ghc-tasty-quickcheck
  ghc-vector))
  (arguments
`(#:cabal-revision
  ("1" "149ihklmwnl13mmixq6iq5gzggkgqwsqrjlg2fshqwwbvbd4nn3r")))
  (home-page "https://github.com/bgamari/attoparsec;)
  (synopsis "Fast combinator parsing for bytestrings and text")
  (description
"This package provides a fast parser combinator library, aimed particularly 
at
dealing efficiently with network protocols and complicated text/binary file
formats.")
  (license license:bsd-3))
```

When trying to build this file however, I get the following error:

```
running "runhaskell Setup.hs" with command "register" and parameters 
("--gen-pkg-config=/gnu/store/25ql0xsjqf0alrvy6hmpw6gzirzbqfmv-ghc-attoparsec-0.14.4/ghc-attoparsec-0.14.4.conf")
error: in phase 'register': uncaught exception:
system-error "fport_read" "~A" ("Is a directory") (21)
phase `register' failed after 0.5 seconds
Backtrace:
  11 (primitive-load "/gnu/store/01ry4yp98silvy0mfwgn8c77fxz…")
In guix/build/gnu-build-system.scm:
906:2 10 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9  8 (for-each # …)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   927:23  6 (_)
In guix/build/haskell-build-system.scm:
   244:23  5 (register #:name _ #:system _ #:inputs _ #:outputs _)
In ice-9/ports.scm:
   433:17  4 (call-with-input-file _ _ #:binary _ #:encoding _ # _)
In ice-9/rdelim.scm:
   160:18  3 (read-string _)
In unknown file:
   2 (read-char #)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)
```

I've attached the entire build log.


q4j1fa750jn3jks5xpf5lqd4pnxkk9-ghc-attoparsec-0.14.4.drv.gz
Description: application/gzip

bug#53645: Unable to guix pull on pinebook pro

[Maxime Devos]

D. Birch schreef op zo 30-01-2022 om 20:36 [+]:
> As title.
> 
> I'm using a pinebook pro (arm64) and guix pull is giving up on me.
> 
> I've attached the output of stdout and stderr.
> 
> Did I do something wrong?

From guix-pull-bug:
> builder for `/gnu/store/5mqlzr4gs2f28c4i64rcbxs2zw2zzfzc-gcc-10.3.0.drv' 
> failed with exit code 1
> build of /gnu/store/5mqlzr4gs2f28c4i64rcbxs2zw2zzfzc-gcc-10.3.0.drv failed
> View build log at 
> '/var/log/guix/drvs/5m/qlzr4gs2f28c4i64rcbxs2zw2zzfzc-gcc-10.3.0.drv.bz2'.

The log /var/log/guix/drvs/5m/qlzr4gs2f28c4i64rcbxs2zw2zzfzc-gcc-10.3.0.drv.bz2
is required to investigate the issue.

Greetings,
Maxime.


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

bug#53204: [patch] font-cns11643: ... unzip error

[Maxime Devos]

Brendan Tildesley schreef op ma 31-01-2022 om 02:59 [+0100]:
> I tried updating it but came across an unzip error, maybe unicode related. 
> I've also noticed in my Icecat there are all these icons that are showing as 
> random korean characters, so I wonder if my configuration is wrong somehow??:

Maybe add glibc-utf8-locales to the native-inputs of the package
definition, such that an UTF-8 locale can be installed?

Greetings,
Maxime.


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