bug#40071: Cross-compiled package closure size.

[zimoun]

Hi Mathieu,

On dim., 15 mars 2020 at 12:31, Mathieu Othacehe  wrote:

> mathieu@elbruz ~/guix [env]$ guix size 
> /gnu/store/14ygibryjr7mcly0q9mb8306hlg16nhq-hello-2.10
> store item   totalself
> /gnu/store/vm2gaw5jk1zr1x9qzj4z52qjxvrh0nk9-glibc-cross-aarch64-linux-gnu-2.31
>158.971.4  38.2%
> /gnu/store/w00jb174abikqpznadwzvvgwl3r7qfzd-glibc-2.31  38.4
> 36.7  19.6%
> /gnu/store/08vqg0s77dnff7rz90b0h87n2rfyaszg-gcc-7.5.0-lib   71.0
> 32.6  17.5%
> /gnu/store/vqsixs9ks4chpjynhizkpdd1gdshv87h-gcc-cross-aarch64-linux-gnu-7.5.0-lib
>186.827.9  14.9%
> /gnu/store/fgrpk8r46k34pyqv6xkbi8gbv997dbpx-gcc-cross-sans-libc-aarch64-linux-gnu-7.5.0-lib
> 80.8 9.8   5.2%
> /gnu/store/zf5603c5l6ilgyg35gqfkn82v3k9hbri-linux-libre-headers-cross-aarch64-linux-gnu-5.4.20
>  5.1 5.1   2.7%
> /gnu/store/6hhsxa3vvbh8gvcfjw4k5sfk1qrhkcrf-bash-static-5.0.16   1.6 
> 1.6   0.9%
> /gnu/store/nvc3r588745kkj159lm1pa4xz5g99rqd-bash-static-5.0.16   1.6 
> 1.6   0.9%
> /gnu/store/14ygibryjr7mcly0q9mb8306hlg16nhq-hello-2.10 187.0 
> 0.2   0.1%

Well, using Guix 729ce5f, the situation is sadly similar,

--8<---cut here---start->8---
7$ guix size $(guix build hello --target=aarch64-linux-gnu)
store item   totalself
/gnu/store/fhnvh4qw8ln2i83pfhlccivwxma89q4x-glibc-cross-aarch64-linux-gnu-2.33  
  48.146.4  30.8%
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33  38.3
36.6  24.3%
/gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib  71.7
33.4  22.1%
/gnu/store/a8i28a0wjpfw40jiz3xdigkpwwdmfcrb-gcc-cross-aarch64-linux-gnu-10.3.0-lib
   150.530.7  20.4%
/gnu/store/4f304c7dp68hkcp1zi1i07zm8nfvvyp7-bash-static-5.1.81.7 
1.7   1.1%
/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.81.7 
1.7   1.1%
/gnu/store/rys78r4j72zh45xchq87x2y30ya8mzvi-hello-2.12.1   150.7 
0.2   0.1%
total: 150.7 MiB
--8<---cut here---end--->8---

> The native glibc, gcc-lib and one of the two bash-static packages should
> be removed.

What is the next step to tackle that?


For reference,

> [1]: https://lists.gnu.org/archive/html/bug-guix/2020-03/msg00170.html



Cheers,
simon

bug#58631: Shepherd crash on berlin

[Ludovic Courtès]

Heap usage of shepherd on berlin gathered roughly at T0 (a few hours
after booting), T0+8h, an T0+10h:

--8<---cut here---start->8---
ludo@berlin ~$ sudo herd eval root '(gc-stats)'
Evaluating user expression (gc-stats).
((gc-time-taken . 36730013844) (heap-size . 31494144) (heap-free-size . 
8339456) (heap-total-allocated . 1198237472) (heap-allocated-since-gc . 
7581824) (protected-objects . 0) (gc-times . 157))
ludo@berlin ~$ sudo cat /proc/1/maps |grep -A10 heap
016fe000-0181 rw-p  00:00 0  [heap]
7f78a387d000-7f78a400 rw-p  00:00 0
7f78a400-7f78a4021000 rw-p  00:00 0
7f78a4021000-7f78a800 ---p  00:00 0
7f78a81d-7f78a860 rw-p  00:00 0
7f78a860-7f78a864 rwxp  00:00 0
7f78a864-7f78a870 rw-p  00:00 0
7f78a870-7f78a874 rwxp  00:00 0
7f78a874-7f78a8c6c000 rw-p  00:00 0
7f78a8c6c000-7f78a8cac000 rwxp  00:00 0
7f78a8cac000-7f78a8ccc000 r--p  00:17 167921 
/gnu/store/9nb1nplyx4gx5pdrmmidngir9jmrzxi3-guile-netlink-1.1.1/lib/guile/3.0/site-ccache/ip/route.go
ludo@berlin ~$ sudo herd eval root '(gc-stats)'
Password:
Evaluating user expression (gc-stats).
((gc-time-taken . 2698835942232) (heap-size . 322998272) (heap-free-size . 
56537088) (heap-total-allocated . 49605825968) (heap-allocated-since-gc . 
67360208) (protected-objects . 0) (gc-times . 1356))
ludo@berlin ~$ sudo cat /proc/1/maps |grep -A12 heap
016fe000-0181 rw-p  00:00 0  [heap]
7f788ce8d000-7f78a1bdd000 rw-p  00:00 0
7f78a1bdd000-7f78a1c1d000 rwxp  00:00 0
7f78a1c1d000-7f78a400 rw-p  00:00 0
7f78a400-7f78a4021000 rw-p  00:00 0
7f78a4021000-7f78a800 ---p  00:00 0
7f78a800-7f78a860 rw-p  00:00 0
7f78a860-7f78a864 rwxp  00:00 0
7f78a864-7f78a870 rw-p  00:00 0
7f78a870-7f78a874 rwxp  00:00 0
7f78a874-7f78a8c6c000 rw-p  00:00 0
7f78a8c6c000-7f78a8cac000 rwxp  00:00 0
7f78a8cac000-7f78a8ccc000 r--p  00:17 167921 
/gnu/store/9nb1nplyx4gx5pdrmmidngir9jmrzxi3-guile-netlink-1.1.1/lib/guile/3.0/site-ccache/ip/route.go
ludo@berlin ~$ sudo herd eval root '(gc-stats)'
Password:
Evaluating user expression (gc-stats).
((gc-time-taken . 2909168084878) (heap-size . 348164096) (heap-free-size . 
51949568) (heap-total-allocated . 53131500656) (heap-allocated-since-gc . 
94062880) (protected-objects . 0) (gc-times . 1383))
ludo@berlin ~$ sudo cat /proc/1/maps |grep -A12 heap
016fe000-0181 rw-p  00:00 0  [heap]
7f788b4bd000-7f78a1bdd000 rw-p  00:00 0 
7f78a1bdd000-7f78a1c1d000 rwxp  00:00 0 
7f78a1c1d000-7f78a400 rw-p  00:00 0 
7f78a400-7f78a4021000 rw-p  00:00 0 
7f78a4021000-7f78a800 ---p  00:00 0 
7f78a800-7f78a860 rw-p  00:00 0 
7f78a860-7f78a864 rwxp  00:00 0 
7f78a864-7f78a870 rw-p  00:00 0 
7f78a870-7f78a874 rwxp  00:00 0 
7f78a874-7f78a8c6c000 rw-p  00:00 0 
7f78a8c6c000-7f78a8cac000 rwxp  00:00 0 
7f78a8cac000-7f78a8ccc000 r--p  00:17 167921 
/gnu/store/9nb1nplyx4gx5pdrmmidngir9jmrzxi3-guile-netlink-1.1.1/lib/guile/3.0/site-ccache/ip/route.go
--8<---cut here---end--->8---

Heap keeps increasing, and quite quickly.  That includes code arenas
allocated for JIT (the “rwx” mappings), but the biggest part seems to be
the rest of the heap (in particular the second mapping on the second and
third samples).

During that time shepherd is mostly receiving and logging messages from
‘guix publish’, and occasionally accepting a connection on port 22 and
spawning ‘sshd’:

--8<---cut here---start->8---
ludo@berlin ~$ sudo strace -p1 -Tt
strace: Process 1 attached
10:33:59 rt_sigprocmask(SIG_BLOCK, NULL, [HUP INT TERM CHLD], 8) = 0 <0.09>
10:33:59 epoll_wait(13, [{events=EPOLLIN, data={u32=50, u64=50}}], 8, -1) = 1 
<0.925330>
10:34:00 read(50, "GET /nar/lzip/z0l3fp12ck539qkzc2"..., 4096) = 76 <0.12>
10:34:00 newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0444, 
st_size=2298, ...}, 0) = 0 <0.12>
10:34:00 write(51, "2022-10-20 10:34:00 GET /nar/lzi"..., 96) = 96 <0.36>
10:34:00 read(50, 0x7f78a88d8020, 4096) = -1 EAGAIN (Resource temporarily 
unavailable) <0.08>
10:34:00 epoll_ctl(13, EPOLL_CTL_MOD, 50, 
{events=EPOLLIN|EPOLLRDHUP|EPOLLONESHOT, data={u32=50, u64=50}}) = 0 <0.09>
10:34:00 rt_sigprocmask(SIG_BLOCK, NULL, [HUP INT TERM CHLD], 8) = 0 <0.07>
10:34:00 epoll_wait(13, [{events=EPOLLIN, data={u32=50, u64=50}}], 8, -1) = 1 
<0.001968>
10:34:00 read(50, "GET /x2ii2b9zwxnaf020zinccckl2bh"..., 4096) = 46 <0.10>
10:34:00 newfstatat(A

bug#58559: Rust 1.58.1 fails to build

[Ludovic Courtès]

Hi Brendan,

Brendan Tildesley  skribis:

>    Compiling toml v0.5.7
>
> error: use of deprecated associated function
> `std::array::IntoIternew`: use `IntoIterator::into_iter`
> instead
>     --> src/bootstrap/lib.rs:1046:31
>  |
> 1046 | std::array::IntoIter::new(options).flatten()
>  |   ^^^
>  |
>  = note: `-D deprecated` implied by `-D warnings`
>
> error: could not compile `bootstrap` due to previous error
> failed to run:
> /gnu/store/njjhb4ql1bpb1qj5ksmjgnhaxmy093nz-rust-1.60.0-cargo/bin/cargo
> build --manifest-path
> /tmp/guix-build-rust-1.58.1.drv-0/rustc-1.58.1-src/src/bootstrap/Cargo.toml
> --frozen
> Build completed unsuccessfully in 0:00:12
> error: in phase 'build': uncaught exception:
> %exception #<&invoke-error program: "./x.py" arguments: ("-j16"
>  "build" "library/std" "src/tools/cargo" "src/tools/rustfmt")
>  exit-status: 1 term-signal: #f stop-signal: #f>
> phase `build' failed after 12.3 seconds
> command "./x.py" "-j16" "build" "library/std" "src/tools/cargo"
> "src/tools/rustfmt" failed with status 1

Could you share the output of ‘guix describe’ and that of ‘uname -m’ so
we can understand how to reproduce the issue?

FWIW, with a commit of today, Rust 1.58 is available on x86_64-linux:

--8<---cut here---start->8---
$ guix time-machine --commit=4716cea6256523a8ecf90a426d675bfb7620f3e4 -- build 
-n -e '(@@ (gnu packages rust) rust-1.58)'
122.9 MB would be downloaded:
  /gnu/store/jpnrafjr9l8yanhr2lwvdmi7w7mg1jl4-rust-1.58.1-cargo
  /gnu/store/v9swg7qw0hbxw8q32wfkp418wq6r4k97-rust-1.58.1
--8<---cut here---end--->8---

Thanks,
Ludo’.

bug#58640: Garbage collector ('gc') deletes valid user roots when $HOME is inaccessible

[Liliana Marie Prikler]

Am Mittwoch, dem 19.10.2022 um 10:14 -0700 schrieb Felix Lechner:
> Hi,
> 
> The Guix garbage collector ('gc') deletes valid user roots when those
> links are not resolvable via the user's home folder in places such as
> 
>     ~/.cache/guix/profiles/
> 
> which potentially leaves the user without a working profile.
The output of `guix gc --list-roots' seems to suggest that the actual
garbage collector roots are in /var/guix/profiles (note that root sees
the roots of all users, whereas users only see their own).

More importantly, all GC roots in /home seem to point to the cache used
by guix shell.  By definition, everything in XDG_CACHE_HOME should be
removable without consequences.  Is this not the case here?

Cheers

bug#55360: bug#58375: Installer does not show what is being downloaded

[Mathieu Othacehe]

Hey,

Thanks for having a look!

> I haven’t actually tested the patch but it LGTM.  One thing to check is
> whether ‘terminal-window-size’ returns something sensible for the
> pseudo-terminal; it could be that we need an extra ioctl so the
> pseudo-terminal has the same size as the actual terminal.

Well it returns 0 for all fields, but I tested on several screen sizes
and everything seems fine so I went ahead.

While testing I noticed two new issues though:

1. When the disk is GPT partitionned there is no confirmation page in
  "run-label-page". Something I missed in #57232.

2. When there is an exception in run-external-command-with-handler/tty
for instance, the backtrace page is displayed in the PTY and the
keyboard shortcuts do not work anymore.

I'll address point 1 shortly but could use some advice for point 2.

Thanks,

Mathieu

bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64

[Mathieu Othacehe]

Hello,

> Also, substitute availability for aarch64-linux and armhf-linux is
> OK. Does that mean this issue can be closed?

The guix package for armhf-linux is not built anymore by
ci.guix.gnu.org, but guix for aarch64-linux seems to be working.

Closing,

Thanks,

Mathieu

bug#58309: [BUG Report] found a bug? followup

[Frank Pursel]

In hindsight, these errors occurred while my local network had a
degradation that, no doubt, caused some file transfer interruptions.  I
think this is to blame for these problems -- but -- I believe this may
still point to opportunities to make guix file transfers more robust.
Interrupted file transfers should be detected and, queued for retry, and
not result in store corruption or reports of store corruption.  Perhaps
this problem occurs when incomplete file transfers are prematurely
committed to the store?

On Wed, Oct 19, 2022 at 10:32 AM Maxime Devos 
wrote:

>
>
> On 05-10-2022 19:58, Frank Pursel wrote:
> > Performed another 'guix pull' to receive one more change which led to
> > the additional reporting:
> >
> > guile-ssh-0.15.1-debug  238KiB 227.0MiB/s 00:00 [##]
> 100.0%
> > Backtrace::
> >15 (primitive-load
> "/gnu/store/k76q0ikk8a7769b0d2b9y3jj2mpaywh0-compute-guix-derivation")
> > In ice-9/eval.scm:
> >  155:9 14 (_ _)
> >  159:9 13 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
> > In ice-9/boot-9.scm:
> >  152:2 12 (with-fluid* _ _ _)
> >  152:2 11 (with-fluid* _ _ _)
> > In ./guix/store.scm:
> >2165:24 10 (run-with-store #
> # ?)
> > 1993:8  9 (_ #)
> > In ./guix/gexp.scm:
> > 300:22  8 (_ #)
> > 1181:2  7 (_ #)
> > 1047:2  6 (_ #)
> >  893:4  5 (_ #)
> > In ./guix/store.scm:
> >2050:12  4 (_ #)
> >1402:13  3 (map/accumulate-builds # 7f65668495f0> # ?)
> > 1398:5  2 (map/accumulate-builds # 7f65668495f0> # ?)
> >1414:15  1 (_ #
> ("/gnu/store/063db2n6gr2pqvy77fxp82p0ki6vwklz-guile-avah?" ?) ?)
> >1414:15  0 (loop #f)
> >
>
> Looks like a duplicate of the second part of
> ,
>  (*),
> , 
> and .
>
> (*) I think this one is interesting, as it seems to indicate that build
> errors of packages aren't handled during "guix pull" -- there is a patch
> available for that, though not applied yet IIRC.
>
> Greetings,
> Maxime.
>

bug#58663: ‘guix shell -C’ regression

[Ludovic Courtès]

Recent ‘guix shell -C’ fails to create a container on a foreign distro:

--8<---cut here---start->8---
~$ guix describe
Generation 7Oct 20 2022 16:38:27(current)
  guix 4716cea
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 4716cea6256523a8ecf90a426d675bfb7620f3e4
~$ strace -o ,,s.bad -f guix shell -C coreutils
guix shell: error: mount: mount 
"/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8" on 
"/tmp/guix-directory.E6yvR8//gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8":
 Operation not permitted
~$ grep mount.*/gnu/store ,,s.bad
21363 mount("/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8", 
"/tmp/guix-directory.E6yvR8//gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8",
 0x11cf6e0, MS_RDONLY|MS_NOATIME|MS_BIND, NULL) = 0
21363 mount("/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8", 
"/tmp/guix-directory.E6yvR8//gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8",
 0x11ad160, MS_RDONLY|MS_REMOUNT|MS_NOATIME|MS_BIND, NULL) = -1 EPERM 
(Operation not permitted)
~$ mount |grep /gnu/store
REDACTED on /gnu/store type nfs 
(rw,noatime,nodiratime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=REDACTED,mountvers=3,mountport=47613,mountproto=udp,local_lock=none,addr=REDACTED,_netdev)
--8<---cut here---end--->8---

An older generation (from Feb. 2021) does it just fine on the same
machine:

--8<---cut here---start->8---
$ /var/guix/profiles/per-user/lcourtes/current-guix-6-link/bin/guix describe
  guix e7195e8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: e7195e83c85a83131c0981bae2b6e5613669ebd1
~$ strace -f -o ,,s.good 
/var/guix/profiles/per-user/lcourtes/current-guix-6-link/bin/guix environment 
-C coreutils -- uname -orv
4.9.0-19-amd64 #1 SMP Debian 4.9.320-2 (2022-06-30) GNU/Linux
~$ grep mount.*/gnu/store ,,s.good |head 
25204 mount("/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16", 
"/tmp/guix-directory.erI4qY//gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16",
 0x196a8d0, MS_RDONLY|MS_BIND, NULL) = 0
25204 mount("/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16", 
"/tmp/guix-directory.erI4qY//gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16",
 0x1963e00, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = 0
25204 mount("/gnu/store/zzkly5rbfvahwqgcs7crz0ilpi7x5g5p-ncurses-6.2", 
"/tmp/guix-directory.erI4qY//gnu/store/zzkly5rbfvahwqgcs7crz0ilpi7x5g5p-ncurses-6.2",
 0x18bff90, MS_RDONLY|MS_BIND, NULL) = 0
25204 mount("/gnu/store/zzkly5rbfvahwqgcs7crz0ilpi7x5g5p-ncurses-6.2", 
"/tmp/guix-directory.erI4qY//gnu/store/zzkly5rbfvahwqgcs7crz0ilpi7x5g5p-ncurses-6.2",
 0x1943bc0, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = 0
25204 mount("/gnu/store/knp4rkdm39ph4brkbzsp07q248nfffi1-readline-8.0.4", 
"/tmp/guix-directory.erI4qY//gnu/store/knp4rkdm39ph4brkbzsp07q248nfffi1-readline-8.0.4",
 0x1960c70, MS_RDONLY|MS_BIND, NULL) = 0
25204 mount("/gnu/store/knp4rkdm39ph4brkbzsp07q248nfffi1-readline-8.0.4", 
"/tmp/guix-directory.erI4qY//gnu/store/knp4rkdm39ph4brkbzsp07q248nfffi1-readline-8.0.4",
 0x19732b0, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = 0
25204 mount("/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31", 
"/tmp/guix-directory.erI4qY//gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31",
 0x19491b0, MS_RDONLY|MS_BIND, NULL) = 0
25204 mount("/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31", 
"/tmp/guix-directory.erI4qY//gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31",
 0x1949140, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = 0
25204 mount("/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib", 
"/tmp/guix-directory.erI4qY//gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib",
 0x1974810, MS_RDONLY|MS_BIND, NULL) = 0
25204 mount("/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib", 
"/tmp/guix-directory.erI4qY//gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib",
 0x1960c30, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = 0
--8<---cut here---end--->8---

Notice that in the first case, we bind-mount and remount with
MS_NOATIME, but not in the second case.

This looks like a regression caused by the fix to
 and, viewed from another angle, by
the fact that “nodiratime” is not preserved.

Ludo’.

bug#58606: Emacs next pgtk crashes when pasting to other app

[Joshua Branson via Bug reports for GNU Guix]

Andrew Tropin  writes:

> Recently discovered a problem, which reproduces this way:
> - Open a new emacs instance.
> - Yank anything with M-w or select with mouse.
> - Paste yanked text to chromium/icecat.
>
> Both browser and emacs are hanging up for a while and after that Emacs
> crashes with:
>
> Fatal error 11: Segmentation fault
>
>
> sway, emacs-next-pgtk, ungoogled-chromium

I was unable to reproduce this bug.  I am also using sway.  Also thanks
for the tip about emacs-next-pgtk.  I didn't know that was packaged!

joshua@crazyhorse ~ (master)> guix describe
Generation 45   Oct 20 2022 12:44:46(current)
  guix 00ff6f7
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 00ff6f7c399670a76efffb91276dea2633cc130c
  guixrus 762841a
repository URL: https://git.sr.ht/~whereiseveryone/guixrus
branch: master
commit: 762841aa3fc5140597dd09a8082cf2ad71539f66
  nonguix 2a368a2
repository URL: https://gitlab.com/nonguix/nonguix
branch: master
commit: 2a368a20cc0bc9de566316978749f7bc7f021627


joshua@crazyhorse ~ (master)> guix system describe
Generation 27   Oct 13 2022 12:21:15(current)
  file name: /var/guix/profiles/system-27-link
  canonical file name: /gnu/store/xjdqzg2np46c1ks0qwcyv77wgyf3p184-system
  label: GNU with Linux-Libre 5.19.14
  bootloader: grub
  root device: /dev/mapper/cryptroot
  kernel: 
/gnu/store/8s41d36dgb700p3g5jbgl5vy7wi7lbsw-linux-libre-5.19.14/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 56915dc275994336efd15199769d78ae295e2339
  configuration file: 
/gnu/store/rgw0i1qg29nq5jxk2mcpmvdigrwk4h3i-configuration.scm

>
> Generation 75 Oct 17 2022 15:54:07(current)
>   rde 05225a3
> repository URL: https://git.sr.ht/~abcdw/rde
> branch: master
> commit: 05225a3a20e2f3eba9ebaa3df4cdce3e8b0c33c1
>   guix 3ab1438
> repository URL: file:///home/bob/work/gnu/guix
> branch: master
> commit: 3ab14386cd2a3fc4bacf2291ee585a0685aceb17

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

[Joshua Branson via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> Indeed, the core dump weighs 13 GiB, so it looks like a memory leak (too
> bad ‘info proc stat’ in GDB doesn’t work).
>
> I have not observed it on any other machine.  The difference between
> berlin and machines I have access to is that berlin is being hammered on
> port 22, which means it gets to spawn sshd processes very often.  This
> could be where the leak is.
>

So, this is a hack, but perhaps berlin could start to use endlessh on
port 22, and then the real ssh port could be on another standard port.

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

It would change most guix developers work loads.  But it's a thought.  :)

> Ludo’.

bug#58247: Using guix time-machine results in unsupported manifest format error

[david larsson]

On 2022-10-03 00:10, zimoun wrote:

[..]



Let try the converse,

--8<---cut here---start->8---
$ guix time-machine --commit=729ce5f -- package -i hello -p /tmp/old

$ cat /tmp/old/manifest | grep -A 1 '(manifest'
(manifest
  (version 4)

$ guix package --list-generations -p /tmp/old
Generation 1oct. 02 2022 18:53:10
  hello 2.10out /gnu/store/xg67cpxq2p6q7wn4y2z194pndwdymhpf-hello-2.10

Generation 2oct. 02 2022 21:25:11   (current)
 + 
hello	2.12.1	out	/gnu/store/s5pd3rnzymliafb4la5sca63j86xs0y0-hello-2.12.1
 - hello	2.10  
	out	/gnu/store/xg67cpxq2p6q7wn4y2z194pndwdymhpf-hello-2.10

--8<---cut here---end--->8---

This profile /tmp/old is thus converted from version 3 to version 4, 
and

then, reusing old version of Guix fails,

--8<---cut here---start->8---
$ guix time-machine --commit=7e8e070 -- package -i hello -p /tmp/old
guix package: error: unsupported manifest format
--8<---cut here---end--->8---


Well, I do not know if a fix is possible.  The issue is a
backward compatibility issue.



Hi,
Thanks for the clarification.

I imagine it would be possible to give it a dirty fix, approximately as 
you just showed with /tmp/old, if you also just readd the default 
profile's currently installed packages to it at the end. So, if using 
~/.guix-profile, it would be something like:


1. Say your ~/.guix-profile is at commit=XYZ
2. build a NEW profile with the old package ONLY, from commit=ABC (as in 
/tmp/old)

3. guix pull /tmp/old "back" to commit=XYZ
4. install remaining packages that was in your ~/.guix-profile to 
/tmp/old.

5. mv the ~/.guix-profile symlink to /tmp/old.

( /tmp/old should just be in /var/guix/profiles/per-user/$USER as normal 
)


Building a new package generation like this would not be the same as 
usual, cuz the currently installed packages may come from different guix 
revisions. That might be a dealbreaker for fixing it. I do think it's 
very sad though, that the time-machine is kind of broken whenever the 
manifest gets a new version, with no hint even to the user how to find a 
solution.


Best regards,
David

bug#58666: java-jdom embeds a timestamp in the file names

[Maxim Cournoyer]

Hello,

Build from the farm:
$ find /gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/doc
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/doc/java-jdom-2.0.6.1
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/doc/java-jdom-2.0.6.1/LICENSE.txt
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/java
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/java/jdom-2.x-2022.09.08.17.38-contrib-sources.jar
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/java/jdom-2.x-2022.09.08.17.38-contrib.jar
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/java/jdom-2.x-2022.09.08.17.38-javadoc.jar
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/java/jdom-2.x-2022.09.08.17.38-junit-sources.jar
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/java/jdom-2.x-2022.09.08.17.38-junit.jar
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/java/jdom-2.x-2022.09.08.17.38-sources.jar
/gnu/store/gk9shrkf9bw9ry9qbzrx0z60l6ini8if-java-jdom-2.0.6.1/share/java/jdom-2.x-2022.09.08.17.38.jar

Local build:
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/lib
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/lib/java
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/lib/java/jdom-2.x-2022.10.20.18.50-contrib-sources.jar
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/lib/java/jdom-2.x-2022.10.20.18.50-contrib.jar
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/lib/java/jdom-2.x-2022.10.20.18.50-javadoc.jar
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/lib/java/jdom-2.x-2022.10.20.18.50-junit-sources.jar
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/lib/java/jdom-2.x-2022.10.20.18.50-junit.jar
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/lib/java/jdom-2.x-2022.10.20.18.50-sources.jar
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/lib/java/jdom-2.x-2022.10.20.18.50.jar
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/share
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/share/doc
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/share/doc/java-jdom-2.0.6.1
/gnu/store/yqz1718xy64k8m3rl2gvvpi7z3bzf70h-java-jdom-2.0.6.1/share/doc/java-jdom-2.0.6.1/LICENSE.txt

:-)

-- 
Thanks,
Maxim

bug#58667: lacking useful error output when mount of luks drive fails

[bdju]

https://yld.moe/raw/AhY.jpg

As seen in the above image, after failure to mount my second LUKS drive,
there is not a lot of info to go on. Was asked in IRC to report this by
nckx.

bug#58668: unable to mount second LUKS drive after reboot

[bdju]

I had 228 days of uptime and had changed out my second drive for a
bigger one and modified my config.scm accordingly. Upon reboot I was not
able to mount it or finish booting because of it, even though the
passphrase for my root drive was accepted fine.

I was able to boot this very same new drive after selecting a generation
from August 2nd. I thought at first that this generation was before I
had put the new drive configuration into place, but I noticed two
things:
1) the drive was mounted, I could see the files
2) upon looking over the version of my config.scm used in the booted
system, the new drive configuration was already in place after all

I also verified upon nckx's recommendation that the version of
cryptsetup used hasn't changed in this time. (2.7.3)

The working generation uses the following commit:
e6480571a094e27dc50db2b42334f17a6d1957d4

I realize this report is somewhat light on info, so let me know what
else I can try to provide.

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

[Ludovic Courtès]

Joshua Branson  skribis:

> So, this is a hack, but perhaps berlin could start to use endlessh on
> port 22, and then the real ssh port could be on another standard port.

We should do that, I agree; we should still fix the actual bug though!

Ludo’.

bug#57844: Shepherd fails to start in user session ~50% of the time

[Ludovic Courtès]

Hi,

Andrew Tropin  skribis:

> Yes, I don't remember if I created a thread on that (probably not) or
> just discussed it in some chat, but when shepherd stops it doesn't clean
> up its socket file, so you can't start shepherd again until manually
> remove socket.

Right, but in the context of Guix Home, it should be started only once
anyway, right?

Thanks,
Ludo’.

bug#57844: Shepherd fails to start in user session ~50% of the time

[Andrew Tropin]

On 2022-10-20 23:44, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin  skribis:
>
>> Yes, I don't remember if I created a thread on that (probably not) or
>> just discussed it in some chat, but when shepherd stops it doesn't clean
>> up its socket file, so you can't start shepherd again until manually
>> remove socket.
>
> Right, but in the context of Guix Home, it should be started only once
> anyway, right?

Right.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#58663: ‘guix shell -C’ regression

[Ludovic Courtès]

Ludovic Courtès  skribis:

> ~$ strace -o ,,s.bad -f guix shell -C coreutils
> guix shell: error: mount: mount 
> "/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8" on 
> "/tmp/guix-directory.E6yvR8//gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8":
>  Operation not permitted
> ~$ grep mount.*/gnu/store ,,s.bad
> 21363 mount("/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8", 
> "/tmp/guix-directory.E6yvR8//gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8",
>  0x11cf6e0, MS_RDONLY|MS_NOATIME|MS_BIND, NULL) = 0
> 21363 mount("/gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8", 
> "/tmp/guix-directory.E6yvR8//gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8",
>  0x11ad160, MS_RDONLY|MS_REMOUNT|MS_NOATIME|MS_BIND, NULL) = -1 EPERM 
> (Operation not permitted)
> ~$ mount |grep /gnu/store
> REDACTED on /gnu/store type nfs 
> (rw,noatime,nodiratime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=REDACTED,mountvers=3,mountport=47613,mountproto=udp,local_lock=none,addr=REDACTED,_netdev)

[...]

> This looks like a regression caused by the fix to
>  and, viewed from another angle, by
> the fact that “nodiratime” is not preserved.

It was lack of MS_NODIRATIME preservation that was causing problems.

Fixed in 6352e3a17b5978cf9af9e1668816d8f47ec85208!

Ludo’.