bug#31785: Multiple client 'build-paths' RPCs can lead to daemon deadlock

[Ludovic Courtès]

Hey Reepca,

Reepca Russelstein  skribis:

> Here is the reproducer:

Brilliant!  It works wonderfully well.

I moved it to its own file to limit interference with others—plus it’s
one of our oldest bugs so it deserves it. ;-)

> P.S: If in attempting to turn this into a proper test, you try using the
> timeout argument to join-thread, be aware that a second attempt at
> calling join-thread on the same thread will fail with "In procedure
> lock-mutex: mutex already locked by thread".  This is because
> join-thread in (ice-9 threads) has a bug in it: unlock-mutex is not
> called in the "else" case of the cond.  I am mentioning this here in
> case I forget to make a proper report of it.

Heh, how many bugs did you find while chasing this one?

I pushed your patch together with the reproducer as
78da6951787f07e9460091885d7a9eb3e667b512.

Now we have to update the ‘guix’ package, though perhaps that’ll have to
wait until next year, we’ll see.

Thanks a lot for your work and for your support!  You’re my hero.  :-)

Ludo’.

bug#75134: Issue with guix pull

[pelzflorian (Florian Pelz)]

Hi Eric.  8 GiB of RAM must be enough, since guix pull can run on 32-bit
i686-linux.

Another idea would be to pull on one core

guix pull --cores=1

or generally to enable more debug output like

guix pull --debug=4

I remember how someone used Guix on Ubuntu in a UTM virtual machine on a
Macbook and the VM behaved strangely at times until rebooted.

Regards,
Florian

bug#75175: Request for merging "libgcrypt-gpg-update" branch

[Ludovic Courtès]

Oops, this should have gone to guix-patches.  Closing!

bug#63158: packages.guix.gnu.org occasionally wrecks havoc

[Luis Felipe via Bug reports for GNU Guix]

Oh, I didn't notice this report until today, sorry.

A related issue has been reported upstream to Artanis. See 
https://gitlab.com/hardenedlinux/artanis/-/issues/122.




OpenPGP_0x0AB0D067012F08C3.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

bug#75175: Request for merging "libgcrypt-gpg-update" branch

[Ludovic Courtès]

Hello,

I’d like to merge the ‘libgcrypt-gpg-update’ branch.

It is partially built at
 for x86_64-linux and
i686-linux (partially only because that’s via the “-full-upgrade” jobs,
which include additional upgrades).

It’s fairly trivial and safe but expensive (‘cmake-minimal’ depends on
libgcrypt).

  04673f8d50 gnu: gpgme: Update to 1.24.1.
  458b9b649b gnu: gnupg: Update to 2.5.2.
  469bac1546 gnu: npth: Update to 1.8.
  d51e56f7e4 gnu: libksba: Update to 1.6.7.
  22dc97b670 gnu: libassuan: Update to 3.0.1.
  7e989b4ca8 gnu: libgcrypt: Update to 1.11.0.
  74c937a7f3 gnu: libgpg-error: Update to 1.51.

Ludo’.

bug#75157: Grafting inconsistency with multiple outputs is causing problems

[Dariqq]

Hello FLorian,


I think you are experiencing a different (related) issue because the 
problem I seems to vanish by linking to the glib that is used by g-golf 
instead (the --no-grafts options ensures that only one glib is in my 
guix shell)


On 29.12.24 01:24, pelzflorian (Florian Pelz) wrote:



Both my GLibs have one output only.  I still believe above guix commit
is the first bad commit for you, as well, and

guix time-machine -q --commit=78c4d00ab02ab41a22058cdbec0329752e47580f

will show the error and parent commit

guix time-machine -q --commit=08e0144d2338c8fb51e52e74274554583d0faa69

will be fine.  Is it?





The problem i am seeing is still available in 
08e0144d2338c8fb51e52e74274554583d0faa69.



Here is what I've been playing around with:
a simple c file that just loads a scm file.
a simple scm file that just tries to instantiate a gobject class (in 
this example from json-glib but that is irrelevant, using something 
small and simple)


--8<---cut here---start->8---
main.c:
#include 

int
main (int argc, char **argv)
{
scm_init_guile();
scm_c_primitive_load("foo.scm");
}

foo.scm:
(use-modules (g-golf))

(gi-import "Json")

(describe (make 
#:immutable #t))


Build with
gcc -o main main.c \
`pkg-config --cflags --libs guile-3.0` \
`pkg-config --cflags --libs gobject-2.0`

Running this with grafts:
 ./main

(process:3071): GLib-GObject-CRITICAL **: 08:50:36.946: 
g_object_new_is_valid_property: object class 'JsonParser' has no 
property named 'immutable'

#< 7f186b2f56d0> is an instance of class 
Slots are:
 g-inst = #

(process:3071): GLib-GObject-CRITICAL **: 08:50:36.947: 
g_object_get_is_valid_property: object class 'JsonParser' has no 
property named 'immutable'


(process:3071): GLib-GObject-CRITICAL **: 08:50:36.947: 
g_object_get_is_valid_property: object class 'JsonParser' has no 
property named 'immutable'

 immutable = #f

When not linking to gobject , using no-grafts or running directly from 
guile repl things work as I would expect:

./main
#< 7ff2471f1d20> is an instance of class 
Slots are:
 g-inst = #
 immutable = #t
--8<---cut here---end--->8---

On 08e0144d2338c8fb51e52e74274554583d0faa69 a similar problem exists:
g-golf depends on the ungrafted out output of hidden glib
but full glib is getting grafted (because of other other outputs)



If I prepend the glib with the single output graft to pkgconfig path and 
rebuild (s.t. my c prgram is linked to the same glib that is used by 
g-golf) things start magically working again.




I believe what we describe here is yet another symptom of old bug
, but if we have a first bad commit,
and if it is the first bad commit for you, too,
it might help solve it.  Or perhaps this bug can be solved separately if
really the loading through typelib vs. not through typelib is the cause.



There might be an even bigger issue here?


However regardless of it causing issues I think having 2 different 
grafted glibs (or rather anything) is not really great.



Regards,
Florian


Have nice day,
Dariqq