bug#71556: GNOME Konsol crashes

[Simon Josefsson via Bug reports for GNU Guix]

> 21 juni 2024 kl. 06:32 skrev Liliana Marie Prikler 
> :
> 
> Am Freitag, dem 14.06.2024 um 18:34 +0200 schrieb Simon Josefsson:
>> Hi.
>> 
>> GNOME Konsol has crashed for me, bringing down all 10+ windows I had
>> open (and plenty of ongoing work halted...).  I've now seen this
>> twice, so I suppose it counts as reproducible, even though I don't
>> know how to trigger it.  I recall that it happened when I used the
>> mouse to maybe resize windows or switch workspace somehow.
>> 
>> This is guix v1.3.0-60008-g7e00fb9f31 with a fairly normal system
>> configuration [1] on a fairly ordinary amd64 desktop (MSI Z790P).
>> Syslog has these two crashes:
> … and a fairly normal GPU?

Built-in UHD 770 in the Intel 14900K CPU (no overclocking). I am using Dasharo 
system firmware if that makes a difference.

I’ve used this system extensively and think some recent update may have 
introduced it as I started seeing it only recently. Hard to tell though since 
it only happened after 4+ hours of interactive work each time.

> The crash indicates some driver issue, probably in Mesa.  Since GNOME
> is increasingly hardware accelerated, you tend to notice them in a lot
> of places.  You can twiddle the GSK_RENDERER environment variable to
> something less buggy, potentially at the cost of performance.
> Particularly the cairo one ought to do slow, but correct CPU rendering.

Ah this makes sense. I will try and see if I notice it again. It hasn’t 
happened for any other application.

/Simon

bug#71556: GNOME Konsol crashes

[Simon Josefsson via Bug reports for GNU Guix]

Hi.

GNOME Konsol has crashed for me, bringing down all 10+ windows I had
open (and plenty of ongoing work halted...).  I've now seen this twice,
so I suppose it counts as reproducible, even though I don't know how to
trigger it.  I recall that it happened when I used the mouse to maybe
resize windows or switch workspace somehow.

This is guix v1.3.0-60008-g7e00fb9f31 with a fairly normal system
configuration [1] on a fairly ordinary amd64 desktop (MSI Z790P).
Syslog has these two crashes:

Jun 12 17:53:49 localhost vmunix: [244491.668326] .kgx-real[2161]: segfault at 
29 ip 7fd22dc31d6d sp 7ffed19f0630 error 6 in 
crocus_dri.so[7fd22da94000+165b000] likely on CPU 10 (core 20, socket 0)
Jun 12 17:53:49 localhost vmunix: [244491.668348] Code: c0 75 42 48 8b 93 08 1a 
00 00 48 8d 8b 08 1a 00 00 49 8d 44 24 08 66 48 0f 6e c9 66 48 0f 6e c2 66 0f 
6c c1 41 0f 11 44 24 08 <48> 89 42 08 48 89 83 08 1a 00 00 f0 83 6d 00 01 75 31 
5b 5d 41 5c

Jun 13 20:45:36 localhost vmunix: [96351.516581] .kgx-real[2371]: segfault at 8 
ip 7f34fc831d6d sp 7ffe27647ae0 error 6 in 
crocus_dri.so[7f34fc694000+165b000] likely on CPU 30 (core 46, socket 0)
Jun 13 20:45:36 localhost vmunix: [96351.516595] Code: c0 75 42 48 8b 93 08 1a 
00 00 48 8d 8b 08 1a 00 00 49 8d 44 24 08 66 48 0f 6e c9 66 48 0f 6e c2 66 0f 
6c c1 41 0f 11 44 24 08 <48> 89 42 08 48 89 83 08 1a 00 00 f0 83 6d 00 01 75 31 
5b 5d 41 5c

Anyone else seeing this?  I know it is hard to debug based on this
information...

/Simon

[1] https://gitlab.com/jas/sjd-cosmos/-/blob/master/yeti.sjd.se/config.scm


signature.asc
Description: PGP signature

bug#64691: use https:// instead of git:// in shepherd www

[Simon Josefsson via Bug reports for GNU Guix]

Hello, and congratulations on the shepherd 0.10.2 release!

How about using https for git clone instructions, instead of the old
non-secured way?  See patch below.

The "Download" link on 
goes to  which doesn't exist.  How about
updating it to point to ?

/Simon

cvs2 diff: Diffing .
Index: dmd.html
===
RCS file: /web/shepherd/shepherd/dmd.html,v
retrieving revision 1.34
diff -u -p -r1.34 dmd.html
--- dmd.html13 May 2023 14:40:49 -  1.34
+++ dmd.html17 Jul 2023 19:36:44 -
@@ -87,7 +87,7 @@ can be found at
 Development
 
 
-  Anonymous checkout: git clone 
git://git.savannah.gnu.org/shepherd.git
+  Anonymous checkout: git clone 
https://git.savannah.gnu.org/git/shepherd.git
   You can also browse the Git repository with your web browser: 
 https://git.savannah.gnu.org/cgit/shepherd.git;>https://git.savannah.gnu.org/cgit/shepherd.git
 
cvs2 diff: Diffing manual
cvs2 diff: Diffing manual/html_node


signature.asc
Description: PGP signature

bug#63331: Guile-GnuTLS/Git circular dependency

[Simon Josefsson via Bug reports for GNU Guix]

> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Unbound variable: protocol/ssl3

Maybe ssl3 is disabled (as it probably should be) in guix's gnutls?

While I built the package on a Guix system using system GnuTLS, I
didn't build it through Guix's packaging, so maybe there is some
difference?

A GitLab CI/CD build check on Guix would be nice, does anyone publish
docker images for a Guix system?

/Simon


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

bug#63331: Guile-GnuTLS/Git circular dependency

[Simon Josefsson via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> We need to solve that.  For now, the only fix I can think of is having
> ‘guile-gnutls’ built from a “make dist”-provided tarballs.  Apparently
> we can add assets at ; would you
> like to upload a tarball and accompanying signature, Simon?

I published a release of gnutls-guile 3.7.12, this time built on my Guix
development machine to test that the release machinery (README-release)
works under Guix as well; the only "interesting" dependency was ncftp
but you had that packaged and it worked fine.

https://gitlab.com/gnutls/guile/-/releases/v3.7.12

/Simon


signature.asc
Description: PGP signature

bug#63331: Guile-GnuTLS/Git circular dependency

[Simon Josefsson via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> We need to solve that.  For now, the only fix I can think of is having
> ‘guile-gnutls’ built from a “make dist”-provided tarballs.  Apparently
> we can add assets at ; would you
> like to upload a tarball and accompanying signature, Simon?

The tarballs I created are available here:
https://gitlab.com/gnutls/guile/-/releases

Is a new releases necessary, or does the 3.7.11 release work?  I can do
a release tonight or tomorrow, but I'm also happy to help someone else
to do the release -- see README-release for the process, skip 'make
upload' if you don't have ftp.gnu.org gnutls credentials.

I'm not sure I exactly what the real problem is here -- but would one
solution be to publish a source-only tarball with the source code files
from git, together with a signature?  That would include any gnulib
files, but not autogenerated ./configure etc.

/Simon


signature.asc
Description: PGP signature

bug#62160: Guix reference manual link from guix.gnu.org?

[Simon Josefsson via Bug reports for GNU Guix]

Hi

I often go to guix.gnu.org to read the (excellent!) Guix manual.  This
leads to this click pattern: guix.gnu.org -> Help -> GNU Guix Manual
1.4.0 which leads me to a page (written in english) to chose language
of the manual -- https://guix.gnu.org/en/manual/ -- and when I chose
English I get a page to chose format of manual --
https://guix.gnu.org/en/manual/en/ -- and that choice takes a split
second cognitive load.

How about these changes to improve user experience?

1) The link guix.gnu.org -> Help -> GNU Guix Manual 1.4.0 goes directly
to the split-node https://guix.gnu.org/en/manual/en/html_node/

  1b) The link could respect the language-choice for the web-site,
i.e., so if I'm browsing https://guix.gnu.org/de/ it should directly
link me to https://guix.gnu.org/de/manual/de/html_node/ instead.

2) Add links to the PDF variant and full-HTML variants in the top-right
menu where different languages are shown.

What do you think?  Then you quickly get into the manual, and there is
still a simple way to chose other languages, and to get PDF/full-HTML
variants.  I don't see any significant disadvantage with this change.

/Simon



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

bug#48214: inetutils-1.9.4 build fails

[Simon Josefsson via Bug reports for GNU Guix]

Bone Baboon via Bug reports for GNU Guix  writes:

> If inetutils follows semantic version numbering then that would suggest
> a breaking change to the inetutils API moving from 1.9.4 to 2.0.

FWIW, inetutils is not following semantic versioning, and 2.0 is
expected to be a simple drop-in for 1.9.4.

/Simon


signature.asc
Description: PGP signature

bug#44986: [PATCH] doc: Give references and examples for services-to-restart.

[Simon Josefsson via Bug reports for GNU Guix]

Hi!  I started using unattended-upgrades, and was confused which service
names (config.scm vs herd) to use.  I think this small documentation
patch would help others.  What do you think?

/Simon
From c414dd60652ecdd124b189b2c46ce30ae9db986d Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Tue, 1 Dec 2020 10:10:17 +0100
Subject: [PATCH] doc: Give references and examples for services-to-restart.

* doc/guix.texi (Unattended Upgrades): Give references and examples
for services-to-restart.
---
 doc/guix.texi | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 889f380108..02d3077983 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -17175,6 +17175,10 @@ only restarts services that are not currently running, which is
 conservative: it minimizes disruption but leaves outdated services
 running.
 
+Use @command{herd status} to find out candidates for restarting.
+@xref{Services}, for general information about services.  Common
+services to restart would include @code{ntpd} and @code{ssh-daemon}.
+
 By default, the @code{mcron} service is restarted.  This ensures that
 the latest version of the unattended upgrade job will be used next time.
 
-- 
2.20.1



signature.asc
Description: PGP signature

bug#44985: ANSI sequences in unattended-upgrades.log?

[Simon Josefsson via Bug reports for GNU Guix]

Hi!  The unattended-upgrades.log file is quite unreadable due to ANSI
sequences.  Probably use of them should be disabled when output is a log
file?

/Simon


signature.asc
Description: PGP signature