bug#59185: Trouble mounting recursive file systems in containers

[Morgan Smith]

Hello!

So I was trying to mount /run/user/1000 in a container so it would have
access to all my wayland sockets and such when I got a very cryptic
error message.

I was trying something like this:

guix shell --share=/run/user/1000 -C coreutils

After far too long tracking down the issue, it turns out that the
directory had submounts within it meaning that the MS_REC flag is
required to bind mount it.

My /run/user/1000 only had a submount because xdg-document-portal was
making one.  To test this yourself you can run `mount` to find something
with some submounts.  I think /sys/fs might fail for me for the same
reason.

Now I have no clue what we should do to enable this use case.  Maybe we
should allow users to specify mount options using something like this?

guix shell -C --mount=rbind,ro=/run/user/1000

Maybe we could always bind with the recursive flag?


Thanks,

Morgan

bug#57417: Emacs crashes due to symbol lookup error to rsvg_handle_set_stylesheet

[Maxime Devos]

On 10-11-2022 19:13, arnaud.lechevall...@free.fr wrote:

[...]
I checked the package definition with `guix edit emacs`
...
;; When looking for libpng `configure' links with `-lpng -lz', so we
;; must also provide zlib as an input.
libpng
zlib
(if (target-x86-64?)
librsvg-bootstrap
librsvg-2.40) => need to be change ?
libxpm
libxml2
...

I'm a newbie and I hope these details can help. I would appreciate a little 
help to go further and solve this issue.
Thanks.


Which architecture are you on?  You can find out with

$ echo '(use-modules (guix utils)) (%current-system)' | guix repl

Same question for Vishakh Kumar.

Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#59180: [berlin] configure mumi <- debbugs sync via an rsync service

[Maxim Cournoyer]

Maxim Cournoyer  writes:

> Hi,
>
> Currently, the sync of issues with MUMI happen via a manually launched
> rsync (by rekado).  We should properly configure it in the berlin.scm
> configuration file, so that it sticks after a reboot.

>From Ricardo:

  We need the service to read a secret from a file, set an env var
  (RSYNC_PASSWORD), and then keep doing this:

timeout --kill-after 5m 1h rsync --delete -av
  
-- 
Thanks,
Maxim

bug#57417: Emacs crashes due to symbol lookup error to rsvg_handle_set_stylesheet

[arnaud . lechevallier]

Hi there,

I'm facing the same issue from a fresh 1.3 installation I did on a VM. 
Emacs28.2 is linked against librsvg-2.40.21 which do not provide 
rsvg_handle_set_stylesheet function.

altomcat@guix ~/.config$ libtree 
/gnu/store/jpi4h6afvkifypxjxdpgrdm4shnmavwf-emacs-28.2/bin/.emacs-28.2-real | 
grep rsvg
│   │   │   ┊
/gnu/store/3r3sxc1ywqs93rzj4z46p0cbdy1y1x7m-librsvg-2.40.21/lib
├── librsvg-2.so.2 [LD_LIBRARY_PATH]
│   ┊/gnu/store/3r3sxc1ywqs93rzj4z46p0cbdy1y1x7m-librsvg-2.40.21/lib
│   ┊/gnu/store/3r3sxc1ywqs93rzj4z46p0cbdy1y1x7m-librsvg-2.40.21/lib
Error 
[/gnu/store/jpi4h6afvkifypxjxdpgrdm4shnmavwf-emacs-28.2/bin/.emacs-28.2-real]: 
Not all dependencies were found

altomcat@guix ~/.config$ echo $LD_LIBRARY_PATH
/gnu/store/piln05qmyhyiqb3ggn2hvz1wagzvd8mc-gdk-pixbuf+svg-2.40.0/lib:/gnu/store/cydnixdcrvlizpcz3jkas5vpgd2dmd5z-gnome-bluetooth-3.34.2/lib:/gnu/store/3r3sxc1ywqs93rzj4z46p0cbdy1y1x7m-librsvg-2.40.21/lib:/gnu/store/8902rzyhkzs30c8z9xjkmmdrh2dq1ha7-libgweather-3.34.0/lib

Emacs runs well if I insert the path of librsvg-2.50.7 to LD_LIBRARY_PATH as 
follow

export  
LD_LIBRARY_PATH=/gnu/store/34yxh2p22yaiisb1ayp43ig06hdlj0wg-librsvg-2.50.7/lib:$LD_LIBRARY_PATH

I checked the package definition with `guix edit emacs`
...
   ;; When looking for libpng `configure' links with `-lpng -lz', so we
   ;; must also provide zlib as an input.
   libpng
   zlib
   (if (target-x86-64?)
   librsvg-bootstrap
   librsvg-2.40) => need to be change ?
   libxpm
   libxml2
...

I'm a newbie and I hope these details can help. I would appreciate a little 
help to go further and solve this issue.
Thanks.

bug#59181: [berlin] web services fail to start on reboot due to anonip

[Maxim Cournoyer]

Hi,

Each time we reboot berlin, we must clear anonip files that it uses to
process the nginx logs, which are supposed to be named pipes rather than
empty files, like so:

  # rm /var/run/anonip/*
  # herd start nginx

We should fix that.

-- 
Thanks,
Maxim

bug#58923: Malformed core dumps on Guix System

[Maxim Cournoyer]

Hi,

Mathieu Othacehe  writes:

> Anyway, we can now:
>
> wget https://dump.guix.gnu.org/download/installer-dump-1c97b34e
> tar -xvf installer-dump-1c97b34e
> cd dump.2022-10-14.17.15.30
> gdb $(type -P guile) core-dump
> (gdb) bt
> #0  linux_destroy (dev=0x268e620) at arch/linux.c:1615
> #1  0x7fee6ae9cd37 in chained_finalizer (obj=0x7fee54779370, 
> data=0x7fee6790acc0) at finalizers.c:84
> #2  0x7fee6adf5e3f in GC_invoke_finalizers () at extra/../finalize.c:1281
> #3  0x7fee6ae9d429 in scm_run_finalizers () at finalizers.c:414
> #4  0x7fee6aea4482 in finalization_thread_proc (unused=) 
> at finalizers.c:244
> #5  0x7fee6ae9085a in c_body (d=0x7fee69f21d80) at continuations.c:430
> #6  0x7fee6af1d326 in vm_regular_engine (thread=0x7fee6a3b8b40) at 
> vm-engine.c:972
> #7  0x7fee6af2a5d9 in scm_call_n (proc=, argv= out>, nargs=2) at vm.c:1610
> #8  0x7fee6ae9209a in scm_call_2 (proc=, arg1= out>, arg2=) at eval.c:503
> #9  0x7fee6af48742 in scm_c_with_exception_handler.constprop.0 (type=#t, 
> handler_data=handler_data@entry=0x7fee69f21d10, 
> thunk_data=thunk_data@entry=0x7fee69f21d10, thunk=, 
> handler=)
> at exceptions.c:170
> #10 0x7fee6af1a88f in scm_c_catch (tag=, body= out>, body_data=, handler=, 
> handler_data=, pre_unwind_handler=, 
> pre_unwind_handler_data=0x7fee6a436040) at throw.c:168
> #11 0x7fee6ae92e66 in scm_i_with_continuation_barrier 
> (pre_unwind_handler=0x7fee6ae92b80 , 
> pre_unwind_handler_data=0x7fee6a436040, handler_data=0x7fee69f21d80, 
> handler=0x7fee6ae998b0 , 
> body_data=0x7fee69f21d80, body=0x7fee6ae90850 ) at 
> continuations.c:368
> #12 scm_c_with_continuation_barrier (func=, data= out>) at continuations.c:464
> #13 0x7fee6af19b39 in with_guile (base=0x7fee69f21e08, 
> data=0x7fee69f21e30) at threads.c:645
> #14 0x7fee6adf00ba in GC_call_with_stack_base (fn=fn@entry=0x7fee6af19a60 
> , arg=arg@entry=0x7fee69f21e30) at extra/../misc.c:2106
> #15 0x7fee6af128b8 in scm_i_with_guile (dynamic_state=, 
> data=, func=) at threads.c:688
> #16 scm_with_guile (func=, data=) at 
> threads.c:694
> #17 0x7fee6adc6d7e in ?? () from 
> /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0
> #18 0x7fee6a9c4eff in clone () from 
> /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6
>
> which feels quite nice.

Very nice!  I'm sure that'll be very valuable.

-- 
Thanks,
Maxim

bug#59180: [berlin] configure mumi <- debbugs sync via an rsync service

[Maxim Cournoyer]

Hi,

Currently, the sync of issues with MUMI happen via a manually launched
rsync (by rekado).  We should properly configure it in the berlin.scm
configuration file, so that it sticks after a reboot.

-- 
Thanks,
Maxim

bug#58923: Malformed core dumps on Guix System

[Mathieu Othacehe]

Hey,

Thanks for trying to reproduce it. Turns out, it is now working both on
Berlin and on installation images but still failing on my machine. It's
not often that those kind of issues do resolve by themselves. I would
suspect a kernel regression here.

My machine has the following kernel:
Linux meije 5.19.15 #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux 

while Berlin and installation images have respectively:
Linux berlin.guix.gnu.org 6.0.7-gnu #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux
Linux gnu 6.0.7-gnu #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux

Anyway, we can now:

--8<---cut here---start->8---
wget https://dump.guix.gnu.org/download/installer-dump-1c97b34e
tar -xvf installer-dump-1c97b34e
cd dump.2022-10-14.17.15.30
gdb $(type -P guile) core-dump
(gdb) bt
#0  linux_destroy (dev=0x268e620) at arch/linux.c:1615
#1  0x7fee6ae9cd37 in chained_finalizer (obj=0x7fee54779370, 
data=0x7fee6790acc0) at finalizers.c:84
#2  0x7fee6adf5e3f in GC_invoke_finalizers () at extra/../finalize.c:1281
#3  0x7fee6ae9d429 in scm_run_finalizers () at finalizers.c:414
#4  0x7fee6aea4482 in finalization_thread_proc (unused=) at 
finalizers.c:244
#5  0x7fee6ae9085a in c_body (d=0x7fee69f21d80) at continuations.c:430
#6  0x7fee6af1d326 in vm_regular_engine (thread=0x7fee6a3b8b40) at 
vm-engine.c:972
#7  0x7fee6af2a5d9 in scm_call_n (proc=, argv=, nargs=2) at vm.c:1610
#8  0x7fee6ae9209a in scm_call_2 (proc=, arg1=, arg2=) at eval.c:503
#9  0x7fee6af48742 in scm_c_with_exception_handler.constprop.0 (type=#t, 
handler_data=handler_data@entry=0x7fee69f21d10, 
thunk_data=thunk_data@entry=0x7fee69f21d10, thunk=, 
handler=)
at exceptions.c:170
#10 0x7fee6af1a88f in scm_c_catch (tag=, body=, body_data=, handler=, 
handler_data=, pre_unwind_handler=, 
pre_unwind_handler_data=0x7fee6a436040) at throw.c:168
#11 0x7fee6ae92e66 in scm_i_with_continuation_barrier 
(pre_unwind_handler=0x7fee6ae92b80 , 
pre_unwind_handler_data=0x7fee6a436040, handler_data=0x7fee69f21d80, 
handler=0x7fee6ae998b0 , 
body_data=0x7fee69f21d80, body=0x7fee6ae90850 ) at 
continuations.c:368
#12 scm_c_with_continuation_barrier (func=, data=) at continuations.c:464
#13 0x7fee6af19b39 in with_guile (base=0x7fee69f21e08, data=0x7fee69f21e30) 
at threads.c:645
#14 0x7fee6adf00ba in GC_call_with_stack_base (fn=fn@entry=0x7fee6af19a60 
, arg=arg@entry=0x7fee69f21e30) at extra/../misc.c:2106
#15 0x7fee6af128b8 in scm_i_with_guile (dynamic_state=, 
data=, func=) at threads.c:688
#16 scm_with_guile (func=, data=) at threads.c:694
#17 0x7fee6adc6d7e in ?? () from 
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0
#18 0x7fee6a9c4eff in clone () from 
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6
--8<---cut here---end--->8---

which feels quite nice.

Closing that one.

Thanks,

Mathieu

bug#59179: BUG: (./guix/base32.scm:296:65: ERROR)

[dan.munte...@mdc-berlin.de]

Hi, 

please see below


$ guix pull
Updating channel 'guix-science' from Git repository at '
https://github.com/guix-science/guix-science.git'...
Updating channel 'guix' from Git repository at '
https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to b551026 (2 new
commits)...
Building from these channels:
   guix  https://git.savannah.gnu.org/git/guix.git  b551026
   guix-sciencehttps://github.com/guix-science/guix-science.git 5993cb7
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/1xjznjl5gfzlylb4sx4h2scvczr9jxkp-module-
import.drv...
 .
 
building /gnu/store/cs51n9lmsrjy8n1hqln11qhhqaw5ivw9-compute-guix-
derivation.drv...
Backtrace:
In ice-9/boot-9.scm:
   222:17 19 (map1 (# (#) #) #))
In ice-9/psyntax.scm:
  1479:23 18 (_ _ _)
In ice-9/boot-9.scm:
   222:17 17 (map1 (#https://gitlab.com/mothacehe/guil?>;;))
In ice-9/psyntax.scm:
  2356:44 16 (expand-let _ _ (()) #f (hygiene gnu packages guile-xyz)
# ?)
  1620:31 15 (parse _ _ _ () () () _ _)
  2356:44 14 (expand-let _ _ (() #(ribcage () () ()) #(ribcage
#(method) #((top)) #("l-57d92629c77107c-317a"))) #f # ?)
  1620:31 13 (parse _ _ _ () () () _ _)
  2356:44 12 (expand-let _ _ (() #(ribcage () () ()) #(ribcage #(uri)
#((top)) #("l-57d92629c77107c-317e")) #(# ?) ?) ?)
  1620:31 11 (parse _ _ _ () () () _ _)
  2355:44 10 (expand-let (#
((# #)) #) ?)
In ice-9/boot-9.scm:
   222:17  9 (map1 (# (#) #) #))
In ice-9/psyntax.scm:
  1479:23  8 (_ _ _)
In ice-9/boot-9.scm:
   222:17  7 (map1 (# #))
In ice-9/psyntax.scm:
  1402:23  6 (_ _)
  1343:32  5 (syntax-type (#
# ?) ?)
  1557:32  4 (expand-macro # (# ?) ?)
In ./guix/packages.scm:
   277:25  3 (_ # #
#)
In ./guix/base32.scm:
295:4  2 (base32-string-unfold-right # "8a9913843170dc?")
In unknown file:
   1 (string-fold-right # 0 "8a9913843170dc?" ?)
In ./guix/base32.scm:
   296:65  0 (_ #\e 24)


./guix/base32.scm:296:65: ERROR:
  1. :
  character: #\e
  string: "8a9913843170dc7e46bbb1c93d7c41241fa6d649"
Computing Guix derivation for 'x86_64-linux'...  guix pull: error: You
found a bug: the program '/gnu/store/w49vr3qfhidws1541hljhgjqc576d46c-
compute-guix-derivation'
failed to compute the derivation for Guix (version:
"b5510269c58acfc28f23cdd12bd2454d9fe3e14d"; system: "x86_64-linux";
host version: "cc4fa1018dfec8a60b73da3917830635ac7d2af4"; pull-version: 
1).
Please report the COMPLETE output above by email to .

Best,
-- 
Dan


smime.p7s
Description: S/MIME cryptographic signature

bug#59069: `guix shell -CN' failed to access GPU

[Ludovic Courtès]

Hi!

(Cc: Dave Thompson, the original author of this code.)

As you pointed out on IRC, the problem is that ‘guix shell -C’ provides
/sys whereas ‘guix shell -CN’ doesn’t.

This stems from this call in (gnu build linux-container), which has
always been there:

(mount-file-systems root mounts
#:mount-/proc? (memq 'pid namespaces)
#:mount-/sys?  (memq 'net
 namespaces))

This is explained a few lines above:

  ;; A sysfs mount requires the user to have the CAP_SYS_ADMIN capability in
  ;; the current network namespace.
  (when mount-/sys?
(mount* "none" (scope "/sys") "sysfs"
(logior MS_NOEXEC MS_NOSUID MS_NODEV MS_RDONLY)))

As you noticed with ‘--expose=/sys’, bind-mounting /sys doesn’t work
either (‘mount’ fails with EINVAL).

Not sure what to do.  Thoughts?

Ludo’.

bug#59069: `guix shell -CN' failed to access GPU

[dan]

Ludovic Courtès  writes:

Could you check with strace what it’s trying to access, both 
with and

without ‘-N’?

  guix shell mesa-utils strace … -C -- strace -o /tmp/log.strace 
  glxinfo


I looked into the strace logs, and found out that it's actually 
having trouble accessing /sys, which is not available in a '-N' 
container.  I run the following scripts to test:

$ guix shell -C coreutils -- ls /
bin  dev  etc  gnu  home  proc  sys  tmp

while with the '-N' flag:

$guix shell -CN coreutils --ls /
bin  dev  etc  gnu  home  proc  tmp


I have the strace logs in the paste bin, with the line indicating 
the problem[1][2].


[1]: 
https://paste.sr.ht/~lizog/950ef117109fb0d34e70a813852cf7cbf04919a6#log-cn.strace-L585
[2]: 
https://paste.sr.ht/~lizog/950ef117109fb0d34e70a813852cf7cbf04919a6#log-c.strace-L552


--
dan

bug#59166: Fw: Unable to use GPU in guix shell container with FHS

[dan]

hi jacob,

to use gpu in a container, you need a few additional parameters 
(assuming you are also using x11):



guix shell -CF bash coreutils mesa mesa-utils --expose=/tmp/.X11-unix 
--expose=$XAUTHORITY --expose=/dev/dri --expose=/etc/udev -E 
"DISPLAY|XAUTHORITY" -- glxgear

hope it could help.

--
dan

bug#58732: installer: finalizers & device destroy segfault

[Mathieu Othacehe]

Hey,

> Looking at device.c in Parted, that’s probably the right thing because
> PedDevice objects are kept in a linked list whose head is stored in the
> ‘devices’ global variable of device.c.  So you cannot just free them
> asynchronously from a finalizer thread because they might still be
> accessed from other parts of the library.  This is the explanation that
> should go in the comment, and it’s clearly a good reason not to free
> those PedDevice objects.

If the finalizer was run synchronously when a device is removed from the
weak hash table then things would be OK. The device would be removed
from the global linked list by _device_register. get_device would malloc
a new structure and so on. However finalizers are not run synchronously
so here we are.

> Now, we could provide bindings for ‘ped_device_destroy’ that users could
> explicitly call if they want to (this would be similar to explicit calls
> to ‘close-port’).  We’d arrange to make it idempotent.

Sure.

Thanks for your help on that one. I pushed the proposed patch and updated
Guile-Parted to 0.0.7 in Guix.

Mathieu

bug#59168: ‘--with-latest’ doesn’t pick the right compressed tarball

[Ludovic Courtès]

Right now we get:

--8<---cut here---start->8---
$ guix build make --with-latest=make

Starting download of /tmp/guix-file.iV1Drd
>From https://ftpmirror.gnu.org/gnu/make/make-4.4.tar.lz...
following redirection to 
`https://mirror.cyberbits.eu/gnu/make/make-4.4.tar.lz'...
following redirection to 
`https://rap.mirror.cyberbits.eu/gnu/make/make-4.4.tar.lz'...
 …4.tar.lz  1.2MiB 15.9MiB/s 00:00 
[##] 100.0%

Starting download of /tmp/guix-file.e9zE8F
>From https://ftpmirror.gnu.org/gnu/make/make-4.4.tar.lz.sig...
following redirection to 
`https://mirror.cyberbits.eu/gnu/make/make-4.4.tar.lz.sig'...
following redirection to 
`https://rap.mirror.cyberbits.eu/gnu/make/make-4.4.tar.lz.sig'...
 …tar.lz.sig  566B  438KiB/s 00:00 
[##] 100.0%
gpgv: Signature made Mon 31 Oct 2022 07:49:17 AM CET
gpgv:using RSA key B2508A90102F8AE3B12A0090DEACCAAEDB78137A
gpgv: Good signature from "Paul D. Smith "
gpgv: aka "Paul D. Smith "
The following derivation will be built:
  /gnu/store/aajiqll3kmhmgzc9xvy91wwsjgndll4h-make-4.4.drv

[…]
starting phase `unpack'
tar (child): lzip: Cannot exec: No such file or directory
tar (child): Error is not recoverable: exiting now
[…]

builder for `/gnu/store/9wi7i1wimwd4h6fz5hx8kc96x523j2s4-make-4.4-debug' failed 
previously (cached)
build of /gnu/store/aajiqll3kmhmgzc9xvy91wwsjgndll4h-make-4.4.drv failed
--8<---cut here---end--->8---

This is because the  gexp compiler picks the first
source that comes up, which happens to be tar.lz, rather than tar.gz,
which would work.

Ludo’.

bug#58732: installer: finalizers & device destroy segfault

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> I tested it out and I had several SCM pointers encapsulating the same
> libparted C pointer, thus multiple finalizers on the same underlying C
> pointer.

Yes, that’s the idea I tried to convey.

> Anyway, here is a patch that solves the issue by removing the device
> finalizer. It also means that all devices are persisted until the end of
> the program which doesn't feel right, but I cannot think of a better
> solution.

Looking at device.c in Parted, that’s probably the right thing because
PedDevice objects are kept in a linked list whose head is stored in the
‘devices’ global variable of device.c.  So you cannot just free them
asynchronously from a finalizer thread because they might still be
accessed from other parts of the library.  This is the explanation that
should go in the comment, and it’s clearly a good reason not to free
those PedDevice objects.

Now, we could provide bindings for ‘ped_device_destroy’ that users could
explicitly call if they want to (this would be similar to explicit calls
to ‘close-port’).  We’d arrange to make it idempotent.

Thanks,
Ludo’.

bug#58221: nautilus: Crashes loading KgxNautilus plugin twice (problems with NAUTILUS_EXTENSION_PATH)

[Christopher Baines]

Liliana Marie Prikler  writes:

> Am Samstag, dem 01.10.2022 um 13:29 +0200 schrieb Tobias Kortkamp:
>> Hi,
>> 
>> The problem seems to be that NAUTILUS_EXTENSION_PATH contains the
>> same path twice and that it tries to load KgxNautilus from each of
>> the paths:
>> 
>> $ echo $NAUTILUS_EXTENSION_PATH
>> /run/current-system/profile/lib/nautilus/site-
>> extensions:/run/current-system/profile/lib/nautilus/site-extensions
>> 
>> Running Nautilus like this works fine:
>> 
>> $ NAUTILUS_EXTENSION_PATH=/run/current-
>> system/profile/lib/nautilus/site-extensions nautilus
>
> I only know of one thing setting this variable, that being nautilus'
> search-path.  Do you by chance source some profile multiple times?

There might be a related issue where there's duplicates in search paths,
I've tested in a simple VM and I see the duplication in
NAUTILUS_EXTENSION_PATH.

Anyway, this probably should be something that doesn't cause nautilus to
segfault.

Chris


signature.asc
Description: PGP signature

bug#58923: Malformed core dumps on Guix System

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> I suspected that at first, but I then reproduced it on Berlin so I would
> rather bet on a recent regression. I'll see if this can be reproduced on
> a foreign distribution.

I checked in a Guix System VM and cannot reproduce it either:

--8<---cut here---start->8---
$ guix describe
Generation 234  Nov 07 2022 00:27:58(current)
  guix 4a34da8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 4a34da845ed91821d38ba8a9b65ad650dd7488d1
$ $(guix system vm --no-graphic gnu/system/examples/bare-bones.tmpl) -m 1024
[…]
komputilo login: root
root
This is the GNU operating system, welcome!

root@komputilo ~# ulimit -c unlimited
ulimit -c unlimited
root@komputilo ~# guile -c '(use-modules (system foreign)) (dereference-pointer 
(make-pointer 1234))'
guile -c '(use-modules (system foreign)) (dereference-pointer (make-pointer 
1234))'
[   17.580329] guile[188]: segfault at 4d2 ip 7f53893ff97f sp 
7ffede6ab190 error 4 in libguile-3.0.so.1.5.0[7f53893dc000+c8000]
[   17.582412] Code: 66 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec 08 40 f6 c7 06 
75 26 48 8b 07 83 e0 7f 48 83 f8 1f 75 1a 48 8b 47 08 48 85 c0 74 31 <48> 8b 38 
31 f6 48 83 c4 08 e9 33 d1 fd ff 0f 1f 00 48 89 fa 48 8d
Segmentation fault (core dumped)
root@komputilo ~# uname -a
uname -a
Linux komputilo 6.0.7-gnu #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux
root@komputilo ~# echo "set debug-file-directory 
/gnu/store/9snhi90f2nivxqrvqgjgixdch5zkps88-guile-3.0.8-debug/lib/debug" >> 
~/.gdbinit
echo "set debug-file-directory 
/gnu/store/9snhi90f2nivxqrvqgjgixdch5zkps88-guile-3.0.8-debug/lib/debug" >> 
~/.gdbinit
root@komputilo ~# /gnu/store/8fg0nk7c0xylmb6vpz1hc2mx7k3nqw47-gdb-12.1/bin/gdb 
$(type -P guile) core
/gnu/store/8fg0nk7c0xylmb6vpz1hc2mx7k3nqw47-gdb-12.1/bin/gdb $(type -P guile) 
core
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /run/current-system/profile/bin/guile...
Reading symbols from 
/gnu/store/9snhi90f2nivxqrvqgjgixdch5zkps88-guile-3.0.8-debug/lib/debug//gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8/bin/guile.debug...
[New LWP 188]

warning: Unable to find libthread_db matching inferior's thread library, thread 
debugging will not be available.
Core was generated by `guile -c (use-modules (system foreign)) 
(dereference-pointer (make-pointer 1234'.
Program terminated with signal SIGSEGV, Segmentation fault.
--Type  for more, q to quit, c to continue without paging--

#0  scm_dereference_pointer (pointer=0x7f5388a3d4f0) at foreign.c:375
375 foreign.c: No such file or directory.
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling 
/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8/lib/libguile-3.0.so.1.5.0-gdb.scm
WARNING: (guile-user): imported module (gdb) overrides core binding `symbol?'
;;; 
/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8/lib/libguile-3.0.so.1.5.0-gdb.scm:293:21:
 warning: possibly unbound variable `program-debug-info-name'
;;; 
/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8/lib/libguile-3.0.so.1.5.0-gdb.scm:326:10:
 warning: possibly unbound variable `find-source-for-addr'
;;; 
/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8/lib/libguile-3.0.so.1.5.0-gdb.scm:326:32:
 warning: possibly unbound variable `program-debug-info-addr'
;;; 
/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8/lib/libguile-3.0.so.1.5.0-gdb.scm:327:32:
 warning: possibly unbound variable `program-debug-info-context'
;;; compiled 
/root/.cache/guile/ccache/3.0-LE-8-4.5/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8/lib/libguile-3.0.so.1.5.0-gdb.scm.go
;;; compiling 
/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8/share/guile/3.0/system/base/types.scm
;;; compiled 
/root/.cache/guile/ccache/3.0-LE-8-4.5/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8/share/guile/3.0/system/base/types.scm.go
(gdb) bt
bt
#0  scm_dereference_pointer (pointer=#) at foreign.c:375
#1  0x7f5389478326 in vm_regular_engine (thread=0x7f5388913d80)
at vm-engine.c:972
#2  0x7f53894855d9 in scm_call_n (proc=, 
argv=, nargs=1) at vm.c:1610
#3  0x7f53893ed457 in scm_primitive_eval (exp=, 

bug#58290: guile ssh error on guix deploy

[Andrew Tropin]

On 2022-11-04 00:47, Marius Bakke wrote:

> Ludovic Courtès  skriver:
>
>> Hi,
>>
>> Marius Bakke  skribis:
>>
>>> I have the same problem.  Log messages around failure look something
>>> like this (extracted from above message):
>>>
>>>   Oct  4 11:51:49 localhost shepherd[1]: Service sshd-2 has been started. 
>>>   Oct  4 11:51:50 localhost sshd[250]: Accepted publickey for bob from 
>>> 185.70.53.164 port 1915 ssh2: RSA 
>>> SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
>>>   Oct  4 11:52:28 localhost sshd[252]: error: no more sessions
>>>   Oct  4 11:52:28 localhost shepherd[1]: 1 connection still in use after 
>>> sshd-2 termination. 
>>>   Oct  4 11:52:28 localhost shepherd[1]: Service sshd-2 has been disabled. 
>>>
>>> Then deploy crashes with 'Channel opening failure'.
>>
>> “no more sessions” comes from this:
>>
>> --8<---cut here---start->8---
>> int
>> session_open(Authctxt *authctxt, int chanid)
>> {
>>  Session *s = session_new();
>>  debug("session_open: channel %d", chanid);
>>  if (s == NULL) {
>>  error("no more sessions");
>>  return 0;
>>  }
>>
>> [...]
>>
>> }
>> --8<---cut here---end--->8---
>>
>> Would be interesting to run sshd in verbose/debug mode and see why we
>> hit that; it could be because the maximum number of sessions has been
>> reached or something.
>
> I enabled (log-level 'debug) and this is what happens server side:
>
> Nov  3 21:48:25 capella sshd[26345]: debug1: permanently_set_uid: 0/0
> Nov  3 21:50:27 capella sshd[26115]: debug1: Received SIGCHLD.
> Nov  3 21:50:27 capella sshd[26115]: debug1: session_by_pid: pid 26345
> Nov  3 21:50:27 capella sshd[26115]: debug1: session_exit_message: session 8 
> channel 8 pid 26345
> Nov  3 21:50:27 capella sshd[26115]: debug1: session_exit_message: release 
> channel 8
> Nov  3 21:50:28 capella sshd[26115]: debug1: server_input_channel_open: ctype 
> session rchan 65 win 64000 max 32768
> Nov  3 21:50:28 capella sshd[26115]: debug1: input_session_request
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 0: new [server-session]
> Nov  3 21:50:28 capella sshd[26115]: debug1: session_new: session 0
> Nov  3 21:50:28 capella sshd[26115]: debug1: session_open: channel 0
> Nov  3 21:50:28 capella sshd[26115]: debug1: session_open: session 0: link 
> with channel 0
> Nov  3 21:50:28 capella sshd[26115]: debug1: server_input_channel_open: 
> confirm session
> Nov  3 21:50:28 capella sshd[26115]: debug1: server_input_channel_req: 
> channel 0 request exec reply 1
> Nov  3 21:50:28 capella sshd[26115]: debug1: session_by_channel: session 0 
> channel 0
> Nov  3 21:50:28 capella sshd[26115]: debug1: session_input_channel_req: 
> session 0 req exec
> Nov  3 21:50:28 capella sshd[26535]: debug1: PAM: reinitializing credentials
> Nov  3 21:50:28 capella sshd[26535]: debug1: permanently_set_uid: 0/0
> Nov  3 21:50:28 capella sshd[26115]: debug1: server_input_channel_open: ctype 
> session rchan 66 win 64000 max 32768
> Nov  3 21:50:28 capella sshd[26115]: debug1: input_session_request
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 10: new [server-session]
> Nov  3 21:50:28 capella sshd[26115]: debug1: session_open: channel 10
> ["no more sessions" error occurs here, in a different log file]
> Nov  3 21:50:28 capella sshd[26115]: debug1: session open failed, free 
> channel 10
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 10: free: 
> server-session, nchannels 11
> Nov  3 21:50:28 capella sshd[26115]: debug1: server_input_channel_open: 
> failure session
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 0: free: server-session, 
> nchannels 10
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 1: free: server-session, 
> nchannels 9
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 2: free: server-session, 
> nchannels 8
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 3: free: server-session, 
> nchannels 7
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 4: free: server-session, 
> nchannels 6
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 5: free: server-session, 
> nchannels 5
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 6: free: server-session, 
> nchannels 4
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 7: free: server-session, 
> nchannels 3
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 8: free: server-session, 
> nchannels 2
> Nov  3 21:50:28 capella sshd[26115]: debug1: channel 9: free: server-session, 
> nchannels 1
> Nov  3 21:50:28 capella sshd[26115]: debug1: do_cleanup
>
> I compared this with a successful deploy:
>
> Nov  3 21:44:22 capella sshd[25842]: debug1: permanently_set_uid: 0/0
> Nov  3 21:46:25 capella sshd[25612]: debug1: Received SIGCHLD.
> Nov  3 21:46:25 capella sshd[25612]: debug1: session_by_pid: pid 25842
> Nov  3 21:46:25 capella sshd[25612]: debug1: session_exit_message: session 6 
> channel 6 pid 25842
> Nov  3 

bug#58926: Shepherd becomes unresponsive after an interrupt

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> sudo herd restart service-that-hangs-upon-restart
>
>
> then hitting C-c, Shepherd becomes totally unresponsive:
>
> sudo herd status
>
>
> and all further Shpeherd commands hang forever. I was able to reproduce
> it in two different configurations:
>
> 1. On my laptop with a Wireguard service trying to reach a non-existing
> DNS server.
>
> (service wireguard-service-type
>  (wireguard-configuration
>   (addresses (list "10.0.0.2/24"))
>   (dns '("10.0.0.50")) #does not exit
>
> 2. On Berlin, while trying to restart nginx.

I experienced case #2: in that case ‘strace -p1’ showed that shepherd
was stuck on waitpid of the nginx process, which was not terminating.
Killing that process would unlock shepherd.

This might be .

Would be good to see what’s up with WireGuard.

Ludo’.

bug#59071: guix home does not respect package outputs

[Ludovic Courtès]

Hi,

pron...@riseup.net skribis:

> This should be a good enough reproducer:
>
> ```
> (home-environment
>   (packages
> (map specification->package+output
>   (list "glib:bin"
> ...)))
>   ...)
> ```

‘specification->package+output’ returns two values:

--8<---cut here---start->8---
scheme@(guile-user)> (specification->package+output "glib:bin")
$38 = #
$39 = "bin"
--8<---cut here---end--->8---

However, ‘map’ expects its first argument to return one value and thus
discards additional values:

--8<---cut here---start->8---
scheme@(guile-user)> (map specification->package+output '("glib:bin"))
$40 = (#)
--8<---cut here---end--->8---

Instead, you have to write ‘specifications->packages’:

--8<---cut here---start->8---
scheme@(guile-user)> (specifications->packages '("glib:bin" "inkscape"))
$42 = ((# "bin") 
(# "out"))
--8<---cut here---end--->8---

That’s what ‘guix home import’ does now, but I noticed it’s not
documented so I’ll add it to the manual.

Thanks,
Ludo’.

bug#59069: `guix shell -CN' failed to access GPU

[Ludovic Courtès]

Hi,

dan  skribis:

> I was trying to run some GUI software in a guix container, and would like to 
> have GPU access in it.  However, I later found out that if I gave network 
> access to the container, it seems like unable to properly find the GPU.  The 
> following are the commands that I run and the output I got:

Could you check with strace what it’s trying to access, both with and
without ‘-N’?

  guix shell mesa-utils strace … -C -- strace -o /tmp/log.strace glxinfo

It might be a /dev node, or it might be simply talking to the X server,
which requires network access.

Thanks,
Ludo’.

bug#58631: [Shepherd] Indefinite heap growth (memory leak)

[Ludovic Courtès]

With the Fibers fix for ,
backported in Guix commit d9ca9cdd01bf1097343a047b51a1392131c7cf58, this
shepherd memory leak seems to be finally fixed (details in the issue
above).

Bayfront.guix has been running it for more than 12h and heap size hasn’t
changed in that time span.

I’ll wait a bit more before closing the issue, but we’ll soon be done.

Ludo’.