bug#61011: ‘guix system vm’ spawns QEMU and hangs

[Leo Famulari]

On Sun, Jan 22, 2023 at 10:36:21PM +0100, Ludovic Courtès wrote:
>   $(guix time-machine --commit=9923100a42ffa80f604c1c13a5e999e6a4c15146 \
> -- system vm gnu/system/examples/bare-bones.tmpl) -m 1024  # Bad!

I can reproduce.

It seems to work fine without '-m 1024', in which case it only has 512
MB RAM.

bug#61013: guix style indentation problem in (list ...)

[Maxim Cournoyer]

Hello,

I recently stumbled on this indentation produced with guix style:

--8<---cut here---start->8---
(arguments
 (list
   ;; Disable tests that use the network and non-free assets.
   #:test-flags #~(list "-m" "not external and not samples")))
--8<---cut here---end--->8---

While the conventional way would be to indent it as:

--8<---cut here---start->8---
(arguments
 (list
  ;; Disable tests that use the network and non-free assets.
  #:test-flags #~(list "-m" "not external and not samples")))
--8<---cut here---end--->8---

-- 
Thanks,
Maxim

bug#61011: ‘guix system vm’ spawns QEMU and hangs

[Ludovic Courtès]

Hello,

On my Guix System machine, the ‘qemu-system-x86_64’ spawned by ‘guix
system vm’ hangs after printing “Booting from ROM...”; it has to be
terminated with SIGKILL, SIGINT is not enough.

Specifically:

  $(guix time-machine --commit=66188398c446bdf9ce044fa539536e9b54c28c60 \
-- system vm gnu/system/examples/bare-bones.tmpl) -m 1024  # Good.

… whereas:

  $(guix time-machine --commit=9923100a42ffa80f604c1c13a5e999e6a4c15146 \
-- system vm gnu/system/examples/bare-bones.tmpl) -m 1024  # Bad!

I thought the culprit might be this commit:

  commit 9923100a42ffa80f604c1c13a5e999e6a4c15146
  Date:   Fri Dec 23 09:42:27 2022 +0200

  gnu: sgabios: Fix build on cross-build architectures.

  * gnu/packages/firmware.scm (sgabios)[arguments]: When cross-building
  add a make-flag to use the correct objcopy.

… but even after reverting it on today’s master, QEMU occasionally hangs
as before, though not always.

‘qemu-minimal’ as used for “make check-system” seems to work fine.

There have been a number of packages unbundled, so I wonder if another
one of these might be causing problems.

What do you think?

Ludo’.

bug#58120: bug#60840: [PATCH 0/3] gnu: volctl: Update to 0.9.3.

[Maxim Cournoyer]

Hello,

Sergiu Ivanov  writes:

> Hi again,
>
> Maxim Cournoyer  [2023-01-16T18:01:59+0100]:
>>
>> Don't forget to CC my email when sending a revised v2 version with the
>> above :-).
>
> I CCed you, but Google doesn't like another quirk in my E-mail
> configuration which I don't have motivation to debug :-S
>
> I therefore sending you a small ping from my work E-mail, and I'm
> attaching the 3 updated patches just in case it is more convenient
> for you.

Thanks!  I've made cosmetic adjustments to the update commit like so:

--8<---cut here---start->8---
modified   gnu/packages/gtk.scm
@@ -2968,12 +2968,17 @@ (define-public volctl
(lambda* (#:key inputs #:allow-other-keys)
  (substitute* "volctl/xwrappers.py"
(("libXfixes.so")
-(string-append (search-input-file inputs 
"/lib/libXfixes.so")
+(string-append (search-input-file inputs
+  "/lib/libXfixes.so")
 (inputs
  (list libxfixes))
 (propagated-inputs
- (list python-click python-pycairo python-pygobject python-pyyaml
-   python-pulsectl gtk+))
+ (list python-click
+   python-pycairo
+   python-pygobject
+   python-pyyaml
+   python-pulsectl
+   gtk+))
 (home-page "https://buzz.github.io/volctl/";)
 (synopsis "Per-application volume control and on-screen display")
 (description "Volctl is a PulseAudio-enabled tray icon volume control and
--8<---cut here---end--->8---

added a proper GNU Change Log to the commit message:

--8<---cut here---start->8---
gnu: volctl: Update to 0.9.3.

Fixes .

* gnu/packages/gtk.scm (volctl): Update to 0.9.3.
[arguments]: Update substitutions in patch-path phase and delete
trailing #t.
[inputs]: Delete pulseaudio.  Move gtk+ to...
[propagated-inputs] ... here.
--8<---cut here---end--->8---

and pushed the series!

Notice that in my environment, it doesn't run:

--8<---cut here---start->8---
$ volctl
PulseAudio connected
Warning: Could not embed Gtk.StatusIcon.
Fatal error: Could not create a status icon. Are you sure you have a working 
notification area?
pulseaudio disconnected
Alarm clock
--8<---cut here---end--->8---

although I have 'dunst' running on top of my ratpoison WM.

-- 
Thanks,
Maxim

bug#58290: guile ssh error on guix deploy

[Artyom V. Poptsov]

Hello Ludovic, Andrew and all,

thank you for reporting the bug!

The code for reproducing the bug was very helpful indeed, I just
slightly modified the it:

--8<---cut here---start->8---
(use-modules (ssh session)
 (ssh popen)
 (ssh auth)
 (ssh log)
 (rnrs io ports))

(define session
  (make-session #:host "localhost"))

(define (main args)
  (session-parse-config! session)
  (connect! session)
  (userauth-public-key/auto! session)
  (set-log-verbosity! 'functions)

  (let loop ((i 0))
(format (current-error-port) "-- ~a --~%" i)
(let ((pipe (open-remote-pipe session "date" "r")))
  (pk 'x (get-string-all pipe))
  (close-port pipe)
  (loop (+ 1 i)
--8<---cut here---end--->8---

It seems to me that the reason Guile-SSH fails at least partly lies in
changes that were introduced in OpenSSH 5.1.

I set "LogLevel" to "DEBUG3" and ran the test code.  System logs have
shown the following error:

--8<---cut here---start->8---
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 8: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 9: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug2: channel 9: rcvd adjust 1216033
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 0: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 1: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 2: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 3: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 4: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 5: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 6: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 7: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 8: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: channel 9: will not send data 
after close
янв 22 22:40:06 elephant sshd[131488]: debug3: receive packet: type 90
янв 22 22:40:06 elephant sshd[131488]: debug1: server_input_channel_open: ctype 
session rchan 53 win 64000 max 32768
янв 22 22:40:06 elephant sshd[131488]: debug1: input_session_request
янв 22 22:40:06 elephant sshd[131488]: debug2: channel: expanding 20
янв 22 22:40:06 elephant sshd[131488]: debug1: channel 10: new [server-session]
янв 22 22:40:06 elephant sshd[131488]: debug1: session_open: channel 10
янв 22 22:40:06 elephant sshd[131488]: error: no more sessions
--8<---cut here---end--->8---

This "no more sessions" error was the key to understanding the problem.

Here's an excerpt from OpenSSH 5.1 changelog [1]:

--8<---cut here---start->8---
Changes since OpenSSH 5.0
=
[...]
 * Added a MaxSessions option to sshd_config(5) to allow control of the
   number of multiplexed sessions supported over a single TCP connection.
   This allows increasing the number of allowed sessions above the
   previous default of 10, disabling connection multiplexing 
   (MaxSessions=1) or disallowing login/shell/subsystem sessions
   entirely (MaxSessions=0).
--8<---cut here---end--->8---

When I set "MaxSessions" in "/etc/ssh/sshd_config" to 100 and restarted
the sshd daemon, the test code fails on the 100th iteration.

--8<---cut here---start->8---
[...]
;;; [2023/01/22 22:52:03.246549, 3] ssh_packet_need_rekey: rekey: 
[data_rekey_needed=0, out_blocks=817, in_blocks=1309]
;;; [2023/01/22 22:52:03.246559, 3] ssh_packet_socket_callback: rcv packet cb 
(len=0, state=INIT)
;;; [2023/01/22 22:52:03.246568, 3] ssh_packet_socket_callback: Waiting for 
more data (0 < 4)
;;; [2023/01/22 22:52:03.246579, 4] ssh_socket_pollcallback: sending control 
flow event
;;; [2023/01/22 22:52:03.246587, 4] ssh_packet_socket_controlflow_callback: 
sending channel_write_wontblock callback
;;; [2023/01/22 22:52:03.246600, 4] [GSSH DEBUG] read result: 0: #

;;; (x "Вс 22 янв 2023 22:52:03 MSK\n")
;;; [2023/01/22 22:52:03.246636, 4] [GSSH DEBUG] the channel is already freed 
by the closing request from the remote side.
-- 100 --
;;; [2023/01/22 22:52:03.246655, 2] channel_open: Creating a channel 143 with 
64000 window and 32768 max packet
;;; [2023/01/22 22:52:03.246664, 3] ssh_packet_need_rekey: rekey: 
[data_rekey_needed=0, out_blocks=820, in_blocks=1312]
;;; [2023/01/22 22:52:03.246693, 3] ssh_socket_unbuffered_write: Enabling 
POLLOUT for socket
;;; [2023/01/22 22:52:03.246703, 3] packet_send2: packet: wrote [type=90, 
len=32, padding_size=7, comp=24, payload=24]
;;; [2023/01/22 2

bug#58880: Patch impacting translation (was Re: bug#58880: 'guix gc' does not round the amount of disk space freed)

[Julien Lepiller]

Changing the po files in guix repo will work at first, it'll be negated next 
time I push changes from weblate. We could change the po files to ensure 
continuity, but we have to also apply the change to the repo behind weblate. I 
can take care of it after the patch is pushed.

Le 22 janvier 2023 15:49:55 GMT+01:00, zimoun  a 
écrit :
>Hi,
>
>On Sat, 21 Jan 2023 at 17:52, Remco van 't Veer  wrote:
>
 * guix/scripts/gc.scm (guix-gc): Round MiBs in user feedback.
 * po/*/*.po (guix/scripts/gc.scm)a: Round MiBs in user feedback.
>>>
>>> If the way to go with the translation dance?
>>
>> I don't know.  I figured since the translation key was changed this
>> would be the best way to do this but to be honest I don't understand how
>> to do this using "weblate" (from info:guix#Translating Guix).
>
>Julien, WDYT?
>
>
>>> The only change is:
>>>
 diff --git a/guix/scripts/gc.scm b/guix/scripts/gc.scm
 index 5e775c5cdb..2bbfb26d5d 100644
 --- a/guix/scripts/gc.scm
 +++ b/guix/scripts/gc.scm
 @@ -260,10 +260,10 @@ (define-command (guix-gc . args)
  ;; Attempt to have at least SPACE bytes available in STORE.
  (let ((free (free-disk-space (%store-prefix
(if (> free space)
 -  (info (G_ "already ~h MiBs available on ~a, nothing to do~%")
 +  (info (G_ "already ~,2h MiBs available on ~a, nothing to do~%")
  (/ free 1024. 1024.) (%store-prefix))
(let ((to-free (- space free)))
 -(info (G_ "freeing ~h MiBs~%") (/ to-free 1024. 1024.))
 +(info (G_ "freeing ~,2h MiBs~%") (/ to-free 1024. 1024.))
  (collect-garbage store to-free)

(define (delete-generations store pattern)
 @@ -327,10 +327,10 @@ (define-command (guix-gc . args)
   (ensure-free-space store free-space))
  (min-freed
   (let-values (((paths freed) (collect-garbage store 
 min-freed)))
 -  (info (G_ "freed ~h MiBs~%") (/ freed 1024. 1024.
 +  (info (G_ "freed ~,2h MiBs~%") (/ freed 1024. 1024.
  (else
   (let-values (((paths freed) (collect-garbage store)))
 -  (info (G_ "freed ~h MiBs~%") (/ freed 1024. 1024.)))
 +  (info (G_ "freed ~,2h MiBs~%") (/ freed 1024. 1024.)))
  ((list-roots)
   (assert-no-extra-arguments)
   (list-roots))
>>>
>>> and captured by G_ so does this only to be applied and then all the
>>> msgid updated by the translation process?
>>
>> Yes, this is the only change.  The old keys will be orphaned though and
>> remain in the po files.  I'd be happy to drop the po/*/*.po part of the
>> patch if that helps.
>
>Julien, what is the best solution?  Apply a patch touching all PO files
>or apply a patch touching only the messages captured by G_ and then
>update separately the translations?
>
>
>Cheers,
>simon

bug#58880: Patch impacting translation (was Re: bug#58880: 'guix gc' does not round the amount of disk space freed)

[zimoun]

Hi,

On Sat, 21 Jan 2023 at 17:52, Remco van 't Veer  wrote:

>>> * guix/scripts/gc.scm (guix-gc): Round MiBs in user feedback.
>>> * po/*/*.po (guix/scripts/gc.scm)a: Round MiBs in user feedback.
>>
>> If the way to go with the translation dance?
>
> I don't know.  I figured since the translation key was changed this
> would be the best way to do this but to be honest I don't understand how
> to do this using "weblate" (from info:guix#Translating Guix).

Julien, WDYT?


>> The only change is:
>>
>>> diff --git a/guix/scripts/gc.scm b/guix/scripts/gc.scm
>>> index 5e775c5cdb..2bbfb26d5d 100644
>>> --- a/guix/scripts/gc.scm
>>> +++ b/guix/scripts/gc.scm
>>> @@ -260,10 +260,10 @@ (define-command (guix-gc . args)
>>>  ;; Attempt to have at least SPACE bytes available in STORE.
>>>  (let ((free (free-disk-space (%store-prefix
>>>(if (> free space)
>>> -  (info (G_ "already ~h MiBs available on ~a, nothing to do~%")
>>> +  (info (G_ "already ~,2h MiBs available on ~a, nothing to do~%")
>>>  (/ free 1024. 1024.) (%store-prefix))
>>>(let ((to-free (- space free)))
>>> -(info (G_ "freeing ~h MiBs~%") (/ to-free 1024. 1024.))
>>> +(info (G_ "freeing ~,2h MiBs~%") (/ to-free 1024. 1024.))
>>>  (collect-garbage store to-free)
>>>
>>>(define (delete-generations store pattern)
>>> @@ -327,10 +327,10 @@ (define-command (guix-gc . args)
>>>   (ensure-free-space store free-space))
>>>  (min-freed
>>>   (let-values (((paths freed) (collect-garbage store 
>>> min-freed)))
>>> -  (info (G_ "freed ~h MiBs~%") (/ freed 1024. 1024.
>>> +  (info (G_ "freed ~,2h MiBs~%") (/ freed 1024. 1024.
>>>  (else
>>>   (let-values (((paths freed) (collect-garbage store)))
>>> -  (info (G_ "freed ~h MiBs~%") (/ freed 1024. 1024.)))
>>> +  (info (G_ "freed ~,2h MiBs~%") (/ freed 1024. 1024.)))
>>>  ((list-roots)
>>>   (assert-no-extra-arguments)
>>>   (list-roots))
>>
>> and captured by G_ so does this only to be applied and then all the
>> msgid updated by the translation process?
>
> Yes, this is the only change.  The old keys will be orphaned though and
> remain in the po files.  I'd be happy to drop the po/*/*.po part of the
> patch if that helps.

Julien, what is the best solution?  Apply a patch touching all PO files
or apply a patch touching only the messages captured by G_ and then
update separately the translations?


Cheers,
simon

bug#60831: Are our graphs okay?

[Liliana Marie Prikler]

Am Dienstag, dem 17.01.2023 um 10:55 -0500 schrieb Maxim Cournoyer:
> Liliana Marie Prikler  writes:
> 
> > The ‘patch-compilation-driver’ phase pulls in libgccjit even though
> > it has been deliberately removed from emacs-minimal.
> > 
> > * gnu/packages/emacs.scm (emacs)[#:phases]: Delete ‘patch-
> > compilation-driver’.
> > ---
> > Thanks Josselin for pointing this out.
> 
> I'd add the following git tag "Reported-by: Josselin Poiret "
> instead, but otherwise LGTM.
I pushed it without the tag because I initially reported the pulling
in; although Josselin did help in finding how it was pulled in.

Anyway, this particular bug should be fixed now.  As for larger "Are
our graphs okay?" style bugs, I think we can definitely answer those
with "No.", given that cargo hasn't been replaced with antioxidant yet.
Thus, I'm closing this.

Cheers

bug#50329: [PATCH v2 1/2] gnu: emacs-lsp-treemacs: Remove unclearly licensed icons.

[Liliana Marie Prikler]

Am Samstag, dem 19.03.2022 um 15:33 +0100 schrieb r0man:
> emacs-lsp-treemacs bundles icons with unclear licenses.
> See also .
> 
> * gnu/packages/emacs-xyz.scm (%emacs-lsp-treemacs-upstream-source):
> New
> variable.
> (emacs-treemacs)[source]: Use a computed origin to remove unclearly
> licensed
> icons.  Also remove source code which mentions said icons.
> 
> Signed-off-by: Liliana Marie Prikler 
> ---
Pushed now.

Cheers