bug#64297: [Cuirass] Remote server not picking up job, losing workers

[Ludovic Courtès]

As of cuirass@1.1.0-16.b825967, ‘cuirass remote-server’ appears to not
pick jobs as quickly as it should and to lose sight of workers (you can
see them come and go on ).

/var/log/cuirass-remote-worker.log shows that it does build things, but
only sporadically.  Then there are things like:

  2023-06-26 10:07:58 warning: Poll loop busy during 3404 seconds.

This is presumably related to Cuirass commit
c4743b54720e86b0e0b0295fb6d33977e4293644 (previously ‘remote-worker’
would have a database worker thread; now it opens a new connection every
time—a stopgap before it’s fiberized, but apparently not a good one).

Ludo’.

bug#63982: Shepherd can crash when a user service fails to start

[nils]

> Ludovic Courtès  hat am 22.06.2023 22:08 CEST geschrieben:
> This suggests a problem in the config file: one of the shepherd-*.scm
> files listed above ends up calling (string-append #f …).
> 
> We’d need to see those files to understand what’s happening but it looks
> different from what Maxim reported.

Indeed I misdiagnosed the issue because it happened after a guix upgrade.
I used $XDG_LOG_HOME in my shepherd services, and as of 
f74df2ab879fc5457982bbc85b7455a90e82317d this is no longer set by default. 
Thanks for your help!

bug#54944: guix pull: computing Guix derivation takes forever

[Csepp]

akib via  writes:

> I've just installed Guix on a partition of my new HDD.  After the
> installation I logged in to my user account on a Linux console and
> executed 'guix pull'.  After that it pulled the repository and
> computed Guix derivation, but stuck while updating substitutes.  So I
> thought something is wrong and restarted the command.  Now the pull
> operation always stucks while computing Guix derivation.  There is no
> sign of activity according to top.

Is this maybe related to the CC'd bug?
There the freeze happens later, during the building phase for
packages-base, but it seems like the symtoms are the same.
Does this happen every time you try?
Could you get a backtrace with GDB?
I think the incantation was:
set logging on
thread apply all backtrace
quit

And then the output should be gdb.txt.

bug#64302: Guix derivation cannot be computed during pull

[Andreas Enge]

Hello,

here is what happens on a server I do not manage to update for about a year now:

$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 1bc878d (1,055 new commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   1bc878d
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
building /gnu/store/a2zzynwqii5j84gg9zn2brkh0hiqrh6n-module-import.drv...
building /gnu/store/s8bj7c9nd85ng871h4440w7jw6p0hxpq-module-import.drv...
building 
/gnu/store/3m2pndmnxj91s80ad1kvjw7kjsgpf733-module-import-compiled.drv...
building 
/gnu/store/fg3r0s0r1sbljjdvgsnjkkziskn3fagp-module-import-compiled.drv...
building 
/gnu/store/a2lgmyr95d3nr0snp31662rygf5g7cz7-compute-guix-derivation.drv...
Computing Guix derivation for 'x86_64-linux'... /guix pull: error: You found a 
bug: the program 
'/gnu/store/wvni7k3g4wnf0k782zgfv4gya9bnw8gg-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"1bc878ded2ea349384da6a72d4b8326c63c794b4"; system: "x86_64-linux";
host version: "35b176daf1a466f136f0b77c03de78f482a30702"; pull-version: 1).
Please report the COMPLETE output above by email to .

Here is the content of the compute-guix-derivation script:
#!/gnu/store/1kws5vkl0glvpxg7arabsv6q9vazp0hx-guile-3.0.7/bin/guile 
--no-auto-compile
!#
(eval-when (expand load eval) (set! %load-path (cons 
"/gnu/store/ic6dz76n6kax93q32b3356dvpl19iv5w-module-import" %load-path)) (set! 
%load-compiled-path (cons 
"/gnu/store/hkmx7wwwzdycj5q76j08ffn479vmvdax-module-import-compiled" 
%load-compiled-path)))(begin (use-modules (ice-9 match)) (eval-when (expand 
load eval) (match (command-line) ((_ source _ ...) (match %load-path ((front _ 
...) (unless (string=? front source) (set! %load-path (list source 
(string-append "/gnu/store/60jl4xry9c93j9l0rr7nkvbw7dihjz4k-guile-gcrypt-0.3.0" 
"/share/guile/site/" (effective-version)) front))) (set! 
%load-compiled-path (cons (string-append 
"/gnu/store/60jl4xry9c93j9l0rr7nkvbw7dihjz4k-guile-gcrypt-0.3.0" "/lib/guile/" 
(effective-version) "/site-ccache") %load-compiled-path)) (read-disable (quote 
positions))) (use-modules (guix store) (guix self) (guix derivations) (srfi 
srfi-1)) (match (command-line) ((_ source system version protocol-version 
build-output) (let* ((proto (string->number protocol-version)) (store (if 
(integer? proto) (port->connection (duplicate-port (current-input-port) "w+0") 
#:version proto) (open-connection))) (sock (socket AF_UNIX SOCK_STREAM 0))) 
(connect sock AF_UNIX build-output) (display (and=> (parameterize 
((current-warning-port (%make-void-port "w")) (current-build-output-port sock)) 
(run-with-store store (guix-derivation source version "3.0" #:channel-metadata 
(quote (repository (version 0) (url 
"https://git.savannah.gnu.org/git/guix.git";) (branch "master") (commit 
"1bc878ded2ea349384da6a72d4b8326c63c794b4") (name guix) (introduction 
(channel-introduction (version 0) (commit 
"9edb3f66fd807b096b48283debdcddccfea34bad") (signer "BBB0 2DDF 2CEA F6A8 0D1D  
E643 A2A0 6DF2 A33A 54FA") #:pull-version 1) #:system system)) 
derivation-file-name))

If I remember well, in the past I tried to update with a guix from guix
(obtained with "guix install guix") and also with one from git
("./pre-inst-env guix pull"), and the result was always the same.

So here is the sad outdated state:
$ guix describe
Generation 10   Aug 26 2022 15:29:35(current)
  guix 35b176d
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 35b176daf1a466f136f0b77c03de78f482a30702

Andreas

bug#63982: Shepherd can crash when a user service fails to start

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
>>> Uh, so it remains in “starting” state?
>>
>> Yes!
>
> Turns out that this happens when calling the ‘daemonize’ action on
> ‘root’.  I have a reproducer now and am investigating…

Great, thanks for investigating and let me know if I can provide
something useful.  It seems introducing cooperative scheduling is a path
layered with traps, eh :-).

-- 
Thanks,
Maxim

bug#63197: video acceleration/libva segfaults caused by stale mesa shader cache

[Maxim Cournoyer]

Hi Giovanni,

Giovanni Biscuolo  writes:

[...]

>>> ...or apply a patch to rename "~/.cache/mesa_shader_cache" to
>>> "~/.cache/mesa_shader_cache"
>>
>> That's another good idea.
>
> I was just doing guesswork but the bug caused by this mesa upgrade
> smells like a binary incompatibility between two versions (or just major
> versions)... so a versioned shader cache makes sense to me
>
> I'm not able to propose (I mean to code) such a patch, anyway
>
> Anyway, users should know that they have to periodically clean unused
> shader caches, since from what I read on the net the shader cache tends
> to really /explode/ in terms of size, in some cases
>
>>> Alternatively, we should find a way to make Guix users aware of this
>>> kind of problems and possible workarounds they can apply (it's not
>>> related to this specific bug)
>>
>> I would rather pursue the other above options you suggest, so that it
>> doesn't happen in the first place!

I've ping'd upstream with
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8937#note_1975560.
Let's see what they say!

-- 
Thanks,
Maxim

bug#64307: Fluxbox build fails after e6994d7

[Cairn via Bug reports for GNU Guix]

Commit e6994d7 causes Fluxbox to fail on my aarch64 system. Might disturb other 
targets as well, but I can't test right now. just to be sure, here's the commit 
immediately prior to it, which succeeds:

guix time-machine --commit=74e96c4 -- build fluxbox

The trouble commit deals with applying a fix to `gcc-4.9`, which helped me find 
that Fluxbox will succeed with that particular version:

guix build --with-c-toolchain=fluxbox=gcc-toolchain@4.9 fluxbox

Would it be acceptable to update the Fluxbox definition to use that version? 
Although maybe there's a deeper issue here that I'm missing. Let me know!


signature.asc
Description: OpenPGP digital signature

bug#64106: [PATCH] In modify-services, delete multiple services with one stanza. (Closes: #63921, #64106)

[Felix Lechner via Bug reports for GNU Guix]

With this commit, modify-services will delete all instances of the services
that match the indicated service-type. At the same time, it will also raise
errors for misconfigurations.

The patch was motivated by Brian Cully's statements about the difficult
tradeoff here. [1]

Using the changes respectfully submitted there, modify-services will extract
the "delete" clauses from the clause-alist via code inspired by SRFI-1's
lset-difference. It applies those deletions first, before then passing the
remaining clauses (and the remaining services) on to apply-clauses.

It is possible that apply-clauses can also be simplified since the "delete"
case is now gone, but I remain unsure about how to do that.

This commit was lightly tested on a production machine.

The author owes a deep debt of gratitude to Zipheir from the IRC channel
Libera:#scheme for their expert help in understanding the problem and in
coming up with an elegant solution.

Similarly, Bruno Victal (aka mirai) provided major encouragment with his
participation in the same conversation.

Thank you to both of you!

[1] https://issues.guix.gnu.org/64106#4

* gnu/services.scm: In modify-services, delete multiple services with one
stanza. (Closes: #63921, #64106)
---
 gnu/services.scm | 38 +++---
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/gnu/services.scm b/gnu/services.scm
index 109e050a23..f3772ad6b9 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -46,6 +46,7 @@ (define-module (gnu services)
   #:use-module (gnu packages hurd)
   #:use-module (gnu system setuid)
   #:use-module (srfi srfi-1)
+  #:use-module (srfi srfi-8)
   #:use-module (srfi srfi-9)
   #:use-module (srfi srfi-9 gnu)
   #:use-module (srfi srfi-26)
@@ -305,8 +306,7 @@ (define-syntax clause-alist
 is the source location information."
 ((_ (delete kind) rest ...)
  (cons (list kind
- (lambda (service)
-   #f)
+ #f
  (current-source-location))
(clause-alist rest ...)))
 ((_ (kind param => exp ...) rest ...)
@@ -320,6 +320,16 @@ (define-syntax clause-alist
 ((_)
  '(
 
+(define (clause-kind clause)
+  (match clause
+((kind _ _)
+ kind)))
+
+(define (clause-proc clause)
+  (match clause
+((_ proc _)
+ proc)))
+
 (define (apply-clauses clauses services)
   "Apply CLAUSES, an alist as returned by 'clause-alist', to SERVICES, a list
 of services.  Use each clause at most once; raise an error if a clause was not
@@ -393,7 +403,29 @@ (define-syntax modify-services
 all the MINGETTY-SERVICE-TYPE instances, and it deletes instances of the
 UDEV-SERVICE-TYPE."
 ((_ services clauses ...)
- (apply-clauses (clause-alist clauses ...) services
+ (receive (others deletes) (partition clause-proc (clause-alist clauses 
...))
+   (let ((reduced-services (remove (lambda (service)
+ (find (lambda (clause)
+ (eq? (clause-kind clause)
+  (service-kind service)))
+   deletes))
+   services))
+ (deletes-not-found (remove (lambda (clause)
+  (find (lambda (service)
+  (eq? (clause-kind clause)
+   (service-kind service)))
+services))
+deletes)))
+ (for-each (lambda (clause)
+ (raise (make-compound-condition
+ (condition
+  (&error-location
+   (location (current-source-location
+ (formatted-message
+  (G_ "modify-services: cannot delete '~a'; not 
present in service list")
+  (service-type-name (clause-kind clause))
+   deletes-not-found)
+ (apply-clauses others reduced-services))
 
 
 ;;;

base-commit: 269cfe341f242c2b5f37774cb9b1e17d9aa68e2c
-- 
2.40.1

bug#63921: Patch proposed

[Felix Lechner via Bug reports for GNU Guix]

Hi,

A patch to resolve this issue was proposed at the other bug

  https://issues.guix.gnu.org/64106#5

Kind regards
Felix

bug#64309: Python dlopen()s musl libc

[Athena Martin via Bug reports for GNU Guix]

I've had experiences now with multiple Guix packages, including gajim
(bug 60235) and now python-neovim-remote, which have an issue where
Python tries to dlopen() libc, but finds the system libc instead of
Guix's, resulting on Alpine Linux hosts in a crash with this message:

ImportError: libc.musl-x86_64.so.1: cannot open shared object file: No such 
file or directory

There are a variety of tracebacks that lead up to this, depending on
the package in question.


pgpud8qmC_AkJ.pgp
Description: OpenPGP digital signature