bug#48305: java eclipse jetty util does not build

[Julien Lepiller]

Le Sun, 09 May 2021 02:45:57 +0200,
"Dr. Arne Babenhauserheide"  a écrit :

> I see
> 
> „check“-Phasebuilder for
> `/gnu/store/im3vs3rs3cg02qzbya8xr75g30qfraf8-java-eclipse-jetty-util-9.2.22.drv'
> failed with exit code 1 Erstellung von
> /gnu/store/im3vs3rs3cg02qzbya8xr75g30qfraf8-java-eclipse-jetty-util-9.2.22.drv
> fehlgeschlagen Das Erstellungsprotokoll kann unter
> „/var/log/guix/drvs/im/3vs3rs3cg02qzbya8xr75g30qfraf8-java-eclipse-jetty-util-9.2.22.drv.bz2“
> eingesehen werden.
> /gnu/store/7k6rv14mkd368dnmfl3iwlqh020307ba-java-kafka-clients-1.0.0.drv
> wird erstellt … cannot build derivation
> `/gnu/store/vvlj7l0yyzdz3gb09p70dyyixqxmrghb-maven-wagon-http-3.3.4.drv':
> 1 dependencies couldn't be built cannot build derivation
> `/gnu/store/7q25bsm6njn3nhq2qs75ghs9qyakzas1-maven-wagon-provider-test-3.3.4.drv':
> 1 dependencies couldn't be built cannot build derivation
> `/gnu/store/hskyf4y35hc34008zkpawfrh6gc2z225-maven-wagon-tck-http-3.3.4.drv':
> 1 dependencies couldn't be built
> /gnu/store/v6g3vn80hzm78pp0jw41m4r2lsi4ghrj-libX11-1.6.10.tar.bz2.drv
> wird erstellt … cannot build derivation
> `/gnu/store/87k46rrwrjn9m6iprsjf73hfhzs2v524-maven-3.6.1.drv': 1
> dependencies couldn't be built guix upgrade: error: build of
> `/gnu/store/87k46rrwrjn9m6iprsjf73hfhzs2v524-maven-3.6.1.drv' failed
> 
> It looks like junit is missing during build:
> /tmp/guix-build-java-eclipse-jetty-util-9.2.22.drv-0/jetty.project-jetty-9.\
> 2.22.v20170606/jetty-util/src/test/java/org/eclipse/jetty/util/MultiExceptionTest.java:\
> 26: error: package org.junit does not exist
> 
> The build log is attached.
> 
> Best wishes,
> Arne
> 

Thanks for the report! That was my fault. When updating jetty 9.4 (a
security update), I forgot to check its influence on jetty 9.2. Our
tooling is not very good at them, because "guix refresh -l" doesn't
report "dependencies" that only come from inheritance.

Hopefully, fixed with 64c1a60b117295e8bc2b2a67dae7adda48492331, and a
subsequent (and similar) failure in jetty-http-test-classes is also
fixed in the following cbb704b21eb319f4943f1e01f6c2785a8b7db349. jetty
9.2 packages should now build fine, so closing :)

It should work again after you run "guix pull".

bug#48305: java eclipse jetty util does not build

[Dr. Arne Babenhauserheide]

I see

„check“-Phasebuilder for 
`/gnu/store/im3vs3rs3cg02qzbya8xr75g30qfraf8-java-eclipse-jetty-util-9.2.22.drv'
 failed with exit code 1
Erstellung von 
/gnu/store/im3vs3rs3cg02qzbya8xr75g30qfraf8-java-eclipse-jetty-util-9.2.22.drv 
fehlgeschlagen
Das Erstellungsprotokoll kann unter 
„/var/log/guix/drvs/im/3vs3rs3cg02qzbya8xr75g30qfraf8-java-eclipse-jetty-util-9.2.22.drv.bz2“
 eingesehen werden.
/gnu/store/7k6rv14mkd368dnmfl3iwlqh020307ba-java-kafka-clients-1.0.0.drv wird 
erstellt …
cannot build derivation 
`/gnu/store/vvlj7l0yyzdz3gb09p70dyyixqxmrghb-maven-wagon-http-3.3.4.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/7q25bsm6njn3nhq2qs75ghs9qyakzas1-maven-wagon-provider-test-3.3.4.drv':
 1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/hskyf4y35hc34008zkpawfrh6gc2z225-maven-wagon-tck-http-3.3.4.drv': 1 
dependencies couldn't be built
/gnu/store/v6g3vn80hzm78pp0jw41m4r2lsi4ghrj-libX11-1.6.10.tar.bz2.drv wird 
erstellt …
cannot build derivation 
`/gnu/store/87k46rrwrjn9m6iprsjf73hfhzs2v524-maven-3.6.1.drv': 1 dependencies 
couldn't be built
guix upgrade: error: build of
`/gnu/store/87k46rrwrjn9m6iprsjf73hfhzs2v524-maven-3.6.1.drv' failed

It looks like junit is missing during build:
/tmp/guix-build-java-eclipse-jetty-util-9.2.22.drv-0/jetty.project-jetty-9.\
2.22.v20170606/jetty-util/src/test/java/org/eclipse/jetty/util/MultiExceptionTest.java:\
26: error: package org.junit does not exist

The build log is attached.

Best wishes,
Arne



3vs3rs3cg02qzbya8xr75g30qfraf8-java-eclipse-jetty-util-9.2.22.drv.bz2
Description: Binary data


-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

bug#48300: Guix Emacs does not get "America/Sao_Paulo" timezone by name

[Leo Prikler]

Am Samstag, den 08.05.2021, 18:19 -0300 schrieb Jorge P. de Morais
Neto:
> Hi all!  I use Guix on Debian bullseye¹.  My Emacs is a Guix-
> installed
> emacs-next with a package transformation option to use the latest
> commit
> from the master branch.  It works fine except that it wrongly
> evaluates
> the following function call:
> (current-time-zone nil "America/Sao_Paulo")
> It returns `(0 "America")'.  And I have verified that the same bug
> also
> occurs on plain Emacs 27.2 (also from Guix).
> 
> Last time I tested in a manually compiled Emacs 27.1.50, I got the
> correct result: `(-10800 "-03")'.  Also I have just tested on someone
> else’s notebook---Emacs 26.3 from Ubuntu---and it too returned the
> correct result.  I have not tested other timezones.
I'm not quite sure how tzdata works on foreign systems, but I'll assume
Guix always takes the one itself has.  Using this, I don't find any
America/Sao_Paolo, which would be the one you're looking for, but I do
find Brazil/East, which gives the expected result.  

Btw. I ran the same command on Emacs 27.2 from Guix and 26.3 on a
machine, that regrettably still runs Mint.  Neither know of
America/Sao_Paolo, which strongly makes me believe it's tzdata's fault.

It also seems as though right/America/Sao_Paolo exists within tzdata,
but Emacs doesn't try to read it.  I have no clue why though.

Regards,
Leo

bug#48300: Guix Emacs does not get "America/Sao_Paulo" timezone by name

[Jorge P. de Morais Neto]

Hi all!  I use Guix on Debian bullseye¹.  My Emacs is a Guix-installed
emacs-next with a package transformation option to use the latest commit
from the master branch.  It works fine except that it wrongly evaluates
the following function call:
(current-time-zone nil "America/Sao_Paulo")
It returns `(0 "America")'.  And I have verified that the same bug also
occurs on plain Emacs 27.2 (also from Guix).

Last time I tested in a manually compiled Emacs 27.1.50, I got the
correct result: `(-10800 "-03")'.  Also I have just tested on someone
else’s notebook---Emacs 26.3 from Ubuntu---and it too returned the
correct result.  I have not tested other timezones.

Thank you for your work in GNU!

¹ I intend to migrate to PureOS for better free software ethics.

Regards

-- 
-  "In Support of Richard Stallman"
- If an email of mine arrives at your spam box, please notify me.
- Please adopt free/libre formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

bug#41948: [PATCH] Fix some finalizer thread race conditions

[Andrew Whatson]

* libguile/finalizers.c (finalization_pipe): Initialize.
(reset_finalization_pipe): Factored out.
(start_finalization_thread): Create the pipe immediately before
launching the thread.  Ensure the pipe is cleaned up if thread creation
fails.  Update the finalizer callback if thread creation succeeds.
(stop_finalization_thread): Clean up the pipe after stopping the thread.
(spawn_finalizer_thread): Remove finalizer callback logic.
(scm_set_automatic_finalization_enabled): Remove pipe management.
(scm_init_finalizer_thread): Remove pipe management.
---
 libguile/finalizers.c | 45 +++
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/libguile/finalizers.c b/libguile/finalizers.c
index 0ae165fd1..5122e5fe3 100644
--- a/libguile/finalizers.c
+++ b/libguile/finalizers.c
@@ -24,6 +24,7 @@
 # include 
 #endif
 
+#include 
 #include 
 #include 
 #include 
@@ -170,7 +171,7 @@ queue_finalizer_async (void)
 
 #if SCM_USE_PTHREAD_THREADS
 
-static int finalization_pipe[2];
+static int finalization_pipe[2] = { -1, -1 };
 static scm_i_pthread_mutex_t finalization_thread_lock =
   SCM_I_PTHREAD_MUTEX_INITIALIZER;
 static pthread_t finalization_thread;
@@ -190,6 +191,15 @@ notify_about_to_fork (void)
   full_write (finalization_pipe[1], &byte, 1);
 }
 
+static void
+reset_finalization_pipe (void)
+{
+  close (finalization_pipe[0]);
+  close (finalization_pipe[1]);
+  finalization_pipe[0] = -1;
+  finalization_pipe[1] = -1;
+}
+
 struct finalization_pipe_data
 {
   char byte;
@@ -254,15 +264,25 @@ start_finalization_thread (void)
   scm_i_pthread_mutex_lock (&finalization_thread_lock);
   if (!finalization_thread_is_running)
 {
+  assert (finalization_pipe[0] == -1);
+
   /* Use the raw pthread API and scm_with_guile, because we don't want
 to block on any lock that scm_spawn_thread might want to take,
 and we don't want to inherit the dynamic state (fluids) of the
 caller.  */
-  if (pthread_create (&finalization_thread, NULL,
- run_finalization_thread, NULL))
-   perror ("error creating finalization thread");
+  if (pipe2 (finalization_pipe, O_CLOEXEC) != 0)
+   perror ("error creating finalization pipe");
+  else if (pthread_create (&finalization_thread, NULL,
+  run_finalization_thread, NULL))
+   {
+ reset_finalization_pipe ();
+ perror ("error creating finalization thread");
+   }
   else
-   finalization_thread_is_running = 1;
+   {
+ GC_set_finalizer_notifier (notify_finalizers_to_run);
+ finalization_thread_is_running = 1;
+   }
 }
   scm_i_pthread_mutex_unlock (&finalization_thread_lock);
 }
@@ -276,6 +296,8 @@ stop_finalization_thread (void)
   notify_about_to_fork ();
   if (pthread_join (finalization_thread, NULL))
 perror ("joining finalization thread");
+
+  reset_finalization_pipe ();
   finalization_thread_is_running = 0;
 }
   scm_i_pthread_mutex_unlock (&finalization_thread_lock);
@@ -284,7 +306,6 @@ stop_finalization_thread (void)
 static void
 spawn_finalizer_thread (void)
 {
-  GC_set_finalizer_notifier (notify_finalizers_to_run);
   start_finalization_thread ();
 }
 
@@ -368,8 +389,6 @@ scm_set_automatic_finalization_enabled (int enabled_p)
   if (enabled_p)
 {
 #if SCM_USE_PTHREAD_THREADS
-  if (pipe2 (finalization_pipe, O_CLOEXEC) != 0)
-scm_syserror (NULL);
   GC_set_finalizer_notifier (spawn_finalizer_thread);
 #else
   GC_set_finalizer_notifier (queue_finalizer_async);
@@ -381,10 +400,6 @@ scm_set_automatic_finalization_enabled (int enabled_p)
 
 #if SCM_USE_PTHREAD_THREADS
   stop_finalization_thread ();
-  close (finalization_pipe[0]);
-  close (finalization_pipe[1]);
-  finalization_pipe[0] = -1;
-  finalization_pipe[1] = -1;
 #endif
 }
 
@@ -423,10 +438,6 @@ scm_init_finalizer_thread (void)
 {
 #if SCM_USE_PTHREAD_THREADS
   if (automatic_finalization_p)
-{
-  if (pipe2 (finalization_pipe, O_CLOEXEC) != 0)
-scm_syserror (NULL);
-  GC_set_finalizer_notifier (spawn_finalizer_thread);
-}
+GC_set_finalizer_notifier (spawn_finalizer_thread);
 #endif
 }
-- 
2.31.1

bug#41948: Shepherd deadlocks

[Andrew Whatson]

Hi,

I've reviewed the finalizer patch and made some changes to ensure that
it works correctly if pipe creation or thread creation fail.

Thread creation fails in an out-of-memory scenario, so this part can be
verified by running Guile's test-out-of-memory test case.  You'll need a
libgc built with --disable-munmap for the test to survive long enough to
retry launching the finalizer thread.

Cheers!

bug#41948: Shepherd deadlocks

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Ludovic Courtès  skribis:
>
>> While working on a fix for this issue (finalizer pipe shared between
>> parent and child process), I found the ‘sleep_pipe’ of the main thread
>> is also shared between the parent and its child.
>
> Here’s a patch that fixes the problem as exposed by the reproducer.

I went ahead and pushed as 381291f5ff4480afbb197bf5e5a2272cfe54a386,
together with a test derived from the one I posted earlier.

With this and Andrew’s finalizer pipe patch, we should be good!

This will be in the upcoming Guile 3.0.7 release.

Ludo’.

bug#41948: Shepherd deadlocks

[Ludovic Courtès]

Hi Andrew,

Andrew Whatson  skribis:

> * libguile/finalizers.c (finalization_pipe): Initialize.
> (reset_finalization_pipe): Factored out.
> (start_finalization_thread): Create the pipe immediately before
> launching the thread.  Ensure the pipe is cleaned up if thread creation
> fails.  Update the finalizer callback if thread creation succeeds.
> (stop_finalization_thread): Clean up the pipe after stopping the thread.
> (spawn_finalizer_thread): Remove finalizer callback logic.
> (scm_set_automatic_finalization_enabled): Remove pipe management.
> (scm_init_finalizer_thread): Remove pipe management.

I tweaked the commit log and pushed as
5a281e35f4a5ae78fbcf10591d9358bec8f0bee0.

Thanks!

Ludo’.

bug#48156: basic system test broken: qemu-system-x86_64: error while loading shared libraries: libXcursor.so.1: cannot open shared object file: No such file or directory

[Christopher Baines]

Tobias Geerinckx-Rice  writes:

> Chris,
>
> Christopher Baines 写道：
>> This comes from guix.cbaines.net, so it's probably not affecting
>> anyone
>> else.
>
> The spooky happenings below reminded of this thread.  Perhaps they're
> useful somehow.  Probably not.
>
> --8<---cut here---start->8---
> λ guix environment guix -- ./pre-inst-env guix build \
>   --no-grafts mergerfs --target=aarch64-linux-gnu
> [...]
> downloading from
> https://guix.cbaines.net/nar/lzip/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4
> ...
> [...]
> /gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4
> --8<---cut here---end--->8---
>
> --8<---cut here---start->8---
> λ tree /gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4/
> /gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4/
> └── share
>└── doc
>└── mergerfs-2.32.4
>└── LICENSE
>
> 3 directories, 1 file
> --8<---cut here---end--->8---
>
> --8<---cut here---start->8---
> λ guix environment guix -- ./pre-inst-env guix build \
>   --no-grafts mergerfs --target=aarch64-linux-gnu \
>--check --keep-failed
> [...]
> guix build: error: derivation
> `/gnu/store/xkbxh0bwqppf6ga8fxx38hz3f1kq0av8-mergerfs-2.32.4.drv'
> may not be deterministic: output
> `/gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4'
> differs from
> ‘/gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4-check’
> --8<---cut here---end--->8---
>
> --8<---cut here---start->8---
> λ tree
> /gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4-check
> /gnu/store/g3f3pkvli22b6q514cqwwsfk1ip8dwij-mergerfs-2.32.4-check
> ├── bin
> │   ├── mergerfs
> │   └── mergerfs-fusermount
> ├── sbin
> │   └── mount.mergerfs
> └── share
>├── doc
>│   └── mergerfs-2.32.4
>│   └── LICENSE
>└── man
>└── man1
>└── mergerfs.1.gz
>
> 7 directories, 5 files
> --8<---cut here---end--->8---

Hmm, I checked the build for this output as well, same machine, which is
good I guess. I've submitted another build to replace it.

Where did this come up? I wasn't aware anyone else was using
guix.cbaines.net for substitutes, especially for cross-build things.


signature.asc
Description: PGP signature

bug#48273: Icedove 78.10.0 build stuck at 'unpack' phase

[Mark H Weaver]

Hi,

In your original bug report, you stated that the build was stuck in the
'unpack' phase of the 'icedove' package, and you attached a screenshot
showing that phase in-progress.

In this later followup message, you're stating something different: that
it's getting stuck in an earlier package build, namely while building
the 'icecat' source tarball.

Note that the 'icedove' package build cannot even begin until after the
'icecat' source tarball has been successfully built, so it seems that
you had a fully built 'icecat' source tarball on your system at some
point.

bo0od  writes:

>  > Please try again with '--verbosity=3' [0] so that we can see what it's
>
> stuck here:
>
> "s|PACKAGES/icecat|PACKAGES/firefox|g;
> s/GNU Public/Mozilla Public/g;
> s/GNU Foundation/Mozilla Foundation/g;
> s/GNU Corporation/Mozilla Corporation/g;
> s/icecat\.com\>/firefox.com/g;
> s/IceCat-Spdy/Firefox-Spdy/g;
> s/icecat-accounts/firefox-accounts/g;
> s/IceCatAccounts/FirefoxAccounts/g;
> s|https://www\.mozilla\.org/icecat/?utm_source=synceol|https://www.mozilla.org/firefox/?utm_source=synceol|g;
>
> s|www\.gnu\.org/software/gnuzilla/icecat-help|libreplanet.org/wiki/Group:IceCat/Help|g;
> ' '{}' ';'"
>
> (check the uploaded logs, i have done 2 attempts of installing icedove 
> and both stopped at the same place)

This part of the process takes a long time, but at least on my Thinkpad
X200 system (Core 2 Duo, 4 GB RAM, 8 GB swap), it _does_ eventually
finish.

Did the build attempt fail on its own, or did you abort it?

  Thanks,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#40525: inferior process on core-updates crashes: mmap(PROT_NONE) failed

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Ludovic Courtès  skribis:
>
>> Christopher Baines  skribis:
>>
>>> Following up on this, I've built Guile on core-updates with libgc@7
>>> rather than libgc@8 (which is what's used above), and I can't reproduce
>>> the issue. So, I'm getting more certain that this is a regression which
>>> the libgc upgrade has led to.
>>
>> Bah.  :-/
>>
>> We noticed similar issues with libgc@8 earlier but it seemed to be
>> fixed:
>>
>>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36812
>>
>>> Would it be feasible to keep guile, or at least the guile Guix uses with
>>> libgc@7 for now?
>>
>> Yes, we can define a Guile variant in (gnu packages guile) and have
>> (guix self) refer to it.
>
> FWIW flatwhatson reported the dreaded libgc “mmap(PROT_NONE)” crash
> upstream and gathered more info:
>
>   https://github.com/ivmai/bdwgc/issues/353
>
> On #guile they also mentioned that libgc 8 defaults to
> ‘--enable-munmap=6’ whereas libgc 7 would default to ‘--disable-munmap’.
>
> Thus, in ‘core-updates’ commit a605ef3ce9dbd6b79dd9322f89d9facaf875b487,
> I changed libgc 8 so it’s built with ‘--disable-munmap’.  This relieves
> the need for ‘guile-3.0/libgc-7’.  (I checked with “make as-derivation”
> on x86_64-linux that those derivations that would previously fail with
> libgc 8 no longer do.)

Great, that sounds good :)


signature.asc
Description: PGP signature

bug#48282: CI fails to build opencv on x86-64

[Leo Famulari]

On Sat, May 08, 2021 at 07:34:26AM +, Guillaume Le Vaillant wrote:
> It looks like the build farm fails to build the opencv package on
> x86-64. The build log (see [1] or [2]) indicates that the build
> "timed out after 3600 seconds of silence" in the test phase, more
> precisely in the 'opencv_test_aruco' test.

Are you using Intel or AMD?

I ask because of this upstream bug report about ArUco not working on AMD
processors:

https://github.com/opencv/opencv_contrib/issues/2736

The build farm is AMD.

bug#48273: Icedove 78.10.0 build stuck at 'unpack' phase

[Leo Famulari]

On Fri, May 07, 2021 at 06:43:09AM +, bo0od wrote:
> After JSON issue (#48152) got fixed, The error went off but another issue
> appeared which is the process stuck on 'unpack' phase (see the uploaded
> image for more clarification) whether by upgrading the previous icedove
> version to the current one or by installing it freshly.

Thanks for the report.

Please try again with '--verbosity=3' [0] so that we can see what it's
doing.

[0]
https://guix.gnu.org/manual/devel/en/html_node/Common-Build-Options.html

bug#48024: glib-2.62.6 build fails i686

[Bengt Richter]

Hi Mark,

tl;dr -- would you by chance have a mhw-bootstrap.sh that could clone
your set-up of a private git repo to use the way you often mention doing?

I am interested in doing it your way  ;)

IIRC, Pjotr wrote extensive notes on how to build starting with a git clone,
but ended up advising against doing it unless there was no other way.

Any tips appreciated :)
TIA.

On +2021-05-07 13:46:07 -0400, Mark H Weaver wrote:
> Hi,
> 
> Bone Baboon  writes:
> > How can I use the glib I have built in a system configuration while this
> > fix or a variation of it makes it's way into the Guix master branch?
> 
> I guess that you'll need to set up a personal branch of Guix, like I do,
> with a patch applied to the 'glib' package, and another patch applied to
> 'inetutils' (referring to ).
> 
> My recommendation, for now, would be to do this:
> 
> (1) Set up your own git repository, with a personal branch that's the
> same as our official 'master' branch plus the additional patches
> that you need, and to periodically rebase this branch on top of our
> 'master' branch.
> 
> (2) On all of your systems that need these customizations, pass the
> "--url=URL" and "--branch=BRANCH" options to "guix pull", each time
> you use that command.
> 
> There _might_ be a nicer way to set this up using channels, but I've
> never used channels and am mostly ignorant of them.  Maybe someone else
> can chime in on that point.
> 
>   Regards,
> Mark
> 
> -- 
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about .
> 
> 
> 

-- 
Regards,
Bengt Richter

bug#48240: “guix copy” to host with daemon listening on TCP fails

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> There are two hosts running Guix.  The target host runs 
> “guix-daemon” with “--listen=0.0.0.0:”; it does not listen on 
> a local socket file.  Trying to copy store items to the target 
> host fails with this backtrace:

I pushed the four patches as 3270308eebe82075d2f02517c5a2b1599928495c.

Let me know if anything’s amiss!

Thanks,
Ludo’.

bug#48284: Dovecot has two ‘location’ fields

[Ludovic Courtès]

I just noticed this compiler warning:

--8<---cut here---start->8---
gnu/services/mail.scm:431:0: warning: shadows previous definition of 
`%namespace-configuration-location-procedure' at gnu/services/mail.scm:431:0
: warning: shadows previous definition of 
`namespace-configuration-location' at 
--8<---cut here---end--->8---

I believe this comes from the fact that ‘define-configuration’
automatically introduces a ‘location’ field (for the source code
location of  instantiations), which clashes
with this one:

--8<---cut here---start->8---
  (location
   (string "")
   "Physical location of the mailbox. This is in same format as
mail_location, which is also the default for it.")
--8<---cut here---end--->8---

I think this was revealed by the fix in commit
dd0826fbf345dfe7289cf943ed2d29edc51d543f.

Probably the only sane way to address it is by renaming the field above.

Thoughts?

Ludo’.

bug#48214: inetutils-1.9.4 build fails

[Ludovic Courtès]

Hi,

Bone Baboon  skribis:

> Ludovic Courtès writes:
>>> How can I use a package definition from core-updates with guix build or
>>> in a system configuration if it is not available on Guix's master
>>> branch?
>>
>> You can do better :-), you can install 2.0 from master like so:
>>
>>   guix install inetutils --with-latest=inetutils
>
> Thank you for sharing that command.
>
> I prefer to build locally over using substitutes.  When I try to run
> `guix build inetutils --no-substitutes --with-latest=inetutils` it does
> not complete because there is an interactive prompt.  The prompt says
> "Would you like to add this key to your keyring
> ''?".  I have a substitute server that is
> sequentially building packages unattended and this would cause it to
> become stuck and make no further progress.

The interactive prompt is about authenticate the source code tarball,
inetutils-2.0.tar.gz.  It does not relate to substitutes.

>>> On the inetutils mailing list it was suggested that I try inetutils 2.0
>>> on the core-updates branch.  I can successfully build inetutils 2.0 from
>>> the core-updates branch even with IPv6 disabled.
>>>
>>> What is the purpose of the core-updates branch?
>>
>> The ‘core-updates’ branch contains updates to core packages and core
>> Guix functionality that entails a rebuild of all the packages.  In that
>> branch we put package upgrades that would otherwise lead to too many
>> rebuilds (info "(guix) Submitting Patches").
>
> Thank you for explaining this.
>
> ---
>
> What is the process for a package to be brought into master from core-updates?

Submitting a patch the usual way, but making it clear in the subject
line that it targets ‘core-updates’.

> I would rebuild all the packages on my system if I could use inetutils
> 2.0.  Is there a way that I can rebuild all the packages I am using that
> depend on inetutils to use inetutils 2.0 (or more generally any newer
> version of package from core-updates)?

You could maintain your own branch where the default inetutils is 2.0.

>>> Can the Guix master branch provide inetutils 2.0 instead of 1.9.4?
>>
>> No: ‘guix refresh -l inetutils’ shows that almost 2,000 packages depend
>> on inetutils.
>>
>> That said, if needed, ‘master’ could provide 2.0 in addition to 1.9, as
>> is done for GDB for instance.
>
> Would having multiple versions of inetutils in master also create
> multiple versions of packages that depend on inetutils for example a
> version of isc-dhcp that depends on inetutils 1.9 and another that
> depends on inetutils 2.0?

No; what I suggest above would just address the case where people run
‘guix install inetutils’ or it could change the one in
/run/current-system/profile.

> Not having inetutils 2.0 in master appears to break how I connect to the
> internet using Guix if I do both of these:
> * Disable IPv6
> ** See my previous email in this thread that explains the rationale on
>why I am disabling IPv6.
> * Build from source
>
> isc-dhcp fails to build because it depends on inetutils 1.9 which is
> failing.  I am using isc-dhcp when I connecting to the internet.

Unfortunately I don’t have a good solution for you.  :-/

We could change isc-dhcp in ‘master’ so that it depends on inetutils
2.0, but that looks like a band-aid.

Thanks,
Ludo’.

bug#41437: build-system-asdf errors if a system name is too short

[Guillaume Le Vaillant]

Katherine Cox-Buday  skribis:

> #+BEGIN_EXAMPLE
> 10:06 katco says: guix --version
> guix (GNU Guix) c660779722f4130e95cda89c0eb0cff534a89ef2
> #+END_EXAMPLE
>
> I am packaging a system called ~sbcl-1am~, and I discovered that unless
> I make the package name longer, I receive this cryptic error when
> issuing ~guix build -L. sbcl-1am~:
>
> #+BEGIN_EXAMPLE
> Backtrace:
>1 (primitive-load "/home/katco/.config/guix/current/bin/g…")
> In guix/ui.scm:
>   1936:12  0 (run-guix-command _ . _)
>
> guix/ui.scm:1936:12: In procedure run-guix-command:
> Value out of range 0 to 4: 5
> #+END_EXAMPLE

Fixed in 2fa8fd4af59af0de392352915fa50fc21a4cf98a.
Closing.


signature.asc
Description: PGP signature

bug#48225: Wrong result of package-name->name+version

[Guillaume Le Vaillant]

Ludovic Courtès  skribis:

> Hi Guillaume,
>
> Guillaume Le Vaillant  skribis:
>
>> From 1e37a89b943a818b5274c1d5f31143ca48bad40a Mon Sep 17 00:00:00 2001
>> From: Guillaume Le Vaillant 
>> Date: Thu, 6 May 2021 10:32:56 +0200
>> Subject: [PATCH] build-system: asdf: Work around package-name->name+version
>>  bug.
>>
>> This patch modifies how the name of the main Common Lisp system is extracted
>> from the full Guix package name to work around bug#48225 concerning the
>> 'package-name->name+version' function.
>>
>> Fixes .
>>
>> * guix/build-system/asdf.scm (asdf-build): Fix 'systems' function.
>> * guix/build/asdf-build-system.scm (main-system-name): Fix it.
>
> If it works for you, sounds good to me.  Please do rebuild as many CL
> packages, with different CL implementations, to make sure we do not
> overlook any corner case.
>
>> +  (let* ((lisp-prefix (string-append lisp-type "-"))
>> + (package-name (hyphen-separated-name->name+version
>> +(if (string-prefix? lisp-prefix name)
>> +(string-drop name
>> + (string-length 
>> lisp-prefix))
>> +name
>> +`(quote ,(list package-name)))
>
> I’d like to see a FIXME in there: this is all guesswork and we should
> eventually replace guesses with known-good info.
>
> What would it take to pass the right package name and implementation
> name upfront from the package?
>
> Thanks,
> Ludo’.

I tried rebuilding all the sbcl-*, cl-* and ecl-* packages, as well as
stumpwm, uglify-js and nyxt, and I didn't see new failures.
I pushed the patch as 2fa8fd4af59af0de392352915fa50fc21a4cf98a.

When 'package-name->name+version' returns a bad result leading to an
incorrect default Lisp system name being computed, it can be overridden
using the '#:asd-systems' parameter of 'asdf-build-system', which should
work around the problem in almost all cases.

However I suppose other build systems could have issues if they make use
of 'package-name->name+version' on a package with a name like
"abc-123-def-1.2.3" (depending how they use the result).


signature.asc
Description: PGP signature

bug#48225: Wrong result of package-name->name+version

[Ludovic Courtès]

Hi Guillaume,

Guillaume Le Vaillant  skribis:

> From 1e37a89b943a818b5274c1d5f31143ca48bad40a Mon Sep 17 00:00:00 2001
> From: Guillaume Le Vaillant 
> Date: Thu, 6 May 2021 10:32:56 +0200
> Subject: [PATCH] build-system: asdf: Work around package-name->name+version
>  bug.
>
> This patch modifies how the name of the main Common Lisp system is extracted
> from the full Guix package name to work around bug#48225 concerning the
> 'package-name->name+version' function.
>
> Fixes .
>
> * guix/build-system/asdf.scm (asdf-build): Fix 'systems' function.
> * guix/build/asdf-build-system.scm (main-system-name): Fix it.

If it works for you, sounds good to me.  Please do rebuild as many CL
packages, with different CL implementations, to make sure we do not
overlook any corner case.

> +  (let* ((lisp-prefix (string-append lisp-type "-"))
> + (package-name (hyphen-separated-name->name+version
> +(if (string-prefix? lisp-prefix name)
> +(string-drop name
> + (string-length lisp-prefix))
> +name
> +`(quote ,(list package-name)))

I’d like to see a FIXME in there: this is all guesswork and we should
eventually replace guesses with known-good info.

What would it take to pass the right package name and implementation
name upfront from the package?

Thanks,
Ludo’.

bug#46424: Use load-systems or load-systems*

[Pierre Neidhardt]

Interesting.
This reminds me of a puzzling issue I recently had while working on the
Nyxt .asd:

- (asdf:load-asd "/path/to/nyxt.asd")
- (asdf:make :nyxt/quicklisp)

The nyxt/quicklisp system would call ql:update-dist and then would fail,
saying it cannot find "nyxt/quicklisp" (which it is running!)
because ql:update-dist would lead ASDF to somehow forget about the .asd.

Adding (asdf:load-asd "/path/to/nyxt.asd") right after ql:update-dist
fixes it.

I've reworked the whole thing different on Nyxt's master branch, so this
is no longer an issue.

Maybe there is a hint lurking in there...

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

bug#40525: inferior process on core-updates crashes: mmap(PROT_NONE) failed

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Christopher Baines  skribis:
>
>> Following up on this, I've built Guile on core-updates with libgc@7
>> rather than libgc@8 (which is what's used above), and I can't reproduce
>> the issue. So, I'm getting more certain that this is a regression which
>> the libgc upgrade has led to.
>
> Bah.  :-/
>
> We noticed similar issues with libgc@8 earlier but it seemed to be
> fixed:
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36812
>
>> Would it be feasible to keep guile, or at least the guile Guix uses with
>> libgc@7 for now?
>
> Yes, we can define a Guile variant in (gnu packages guile) and have
> (guix self) refer to it.

FWIW flatwhatson reported the dreaded libgc “mmap(PROT_NONE)” crash
upstream and gathered more info:

  https://github.com/ivmai/bdwgc/issues/353

On #guile they also mentioned that libgc 8 defaults to
‘--enable-munmap=6’ whereas libgc 7 would default to ‘--disable-munmap’.

Thus, in ‘core-updates’ commit a605ef3ce9dbd6b79dd9322f89d9facaf875b487,
I changed libgc 8 so it’s built with ‘--disable-munmap’.  This relieves
the need for ‘guile-3.0/libgc-7’.  (I checked with “make as-derivation”
on x86_64-linux that those derivations that would previously fail with
libgc 8 no longer do.)

Ludo’.

bug#41948: Shepherd deadlocks

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> Those two finalizer threads share the same pipe. When we try to
> stop the finalizer thread in Shepherd, right before forking a new
> process, we send a '\1' byte to the finalizer pipe.
>
> 1 write(6, "\1", 1 
>
>
> which is received by (line 183597): 
>
> 253   <... read resumed>"\1", 1)= 1
>
> the marionette finalizer thread. Then, we pthread_join the Shepherd
> finalizer thread, which never stops! Quite unfortunate.

And here’s the patch for this pipe: it closes the finalizer pipe
pre-fork, and it gets reopened lazily.

Together with the ‘sleep_pipe’ patch, it appears to fix the problems
described here.

Ludo’.

diff --git a/libguile/finalizers.c b/libguile/finalizers.c
index 0ae165fd1..5ddc7dbef 100644
--- a/libguile/finalizers.c
+++ b/libguile/finalizers.c
@@ -24,6 +24,7 @@
 # include 
 #endif
 
+#include 
 #include 
 #include 
 #include 
@@ -170,7 +171,7 @@ queue_finalizer_async (void)
 
 #if SCM_USE_PTHREAD_THREADS
 
-static int finalization_pipe[2];
+static int finalization_pipe[2] = { -1, -1 };
 static scm_i_pthread_mutex_t finalization_thread_lock =
   SCM_I_PTHREAD_MUTEX_INITIALIZER;
 static pthread_t finalization_thread;
@@ -254,6 +255,13 @@ start_finalization_thread (void)
   scm_i_pthread_mutex_lock (&finalization_thread_lock);
   if (!finalization_thread_is_running)
 {
+  assert (finalization_pipe[0] == -1);
+
+  if (pipe2 (finalization_pipe, O_CLOEXEC) != 0)
+scm_syserror (NULL);
+
+  GC_set_finalizer_notifier (notify_finalizers_to_run);
+
   /* Use the raw pthread API and scm_with_guile, because we don't want
 	 to block on any lock that scm_spawn_thread might want to take,
 	 and we don't want to inherit the dynamic state (fluids) of the
@@ -276,6 +284,12 @@ stop_finalization_thread (void)
   notify_about_to_fork ();
   if (pthread_join (finalization_thread, NULL))
 perror ("joining finalization thread");
+
+  close (finalization_pipe[0]);
+  close (finalization_pipe[1]);
+  finalization_pipe[0] = -1;
+  finalization_pipe[1] = -1;
+
   finalization_thread_is_running = 0;
 }
   scm_i_pthread_mutex_unlock (&finalization_thread_lock);
@@ -284,7 +298,6 @@ stop_finalization_thread (void)
 static void
 spawn_finalizer_thread (void)
 {
-  GC_set_finalizer_notifier (notify_finalizers_to_run);
   start_finalization_thread ();
 }
 
@@ -368,8 +381,6 @@ scm_set_automatic_finalization_enabled (int enabled_p)
   if (enabled_p)
 {
 #if SCM_USE_PTHREAD_THREADS
-  if (pipe2 (finalization_pipe, O_CLOEXEC) != 0)
-scm_syserror (NULL);
   GC_set_finalizer_notifier (spawn_finalizer_thread);
 #else
   GC_set_finalizer_notifier (queue_finalizer_async);
@@ -381,10 +392,6 @@ scm_set_automatic_finalization_enabled (int enabled_p)
 
 #if SCM_USE_PTHREAD_THREADS
   stop_finalization_thread ();
-  close (finalization_pipe[0]);
-  close (finalization_pipe[1]);
-  finalization_pipe[0] = -1;
-  finalization_pipe[1] = -1;
 #endif
 }
 
@@ -423,10 +430,6 @@ scm_init_finalizer_thread (void)
 {
 #if SCM_USE_PTHREAD_THREADS
   if (automatic_finalization_p)
-{
-  if (pipe2 (finalization_pipe, O_CLOEXEC) != 0)
-scm_syserror (NULL);
 GC_set_finalizer_notifier (spawn_finalizer_thread);
-}
 #endif
 }

bug#46424: Use load-systems or load-systems*

[Guillaume Le Vaillant]

In the case of quri, it looks like the problem comes from the
"(asdf:clear-system c)" call at the end of "quri-test.asd". When
removing it, the build succeeds even without the custom 'asd-systems'
argument in the Guix package definition.

So it looks like the lazy loading of system definitions is working in
asdf-build-system after all. I guess it's the default behaviour of
'load-asd'.

However I don't know why this 'clear-system' call messes up the ASDF
configuration in asdf-build-system, but it doesn't seem to cause
problems in Quicklisp...


signature.asc
Description: PGP signature

bug#48223: EXWM knows nothing about Guix profiles

[Leo Prikler]

Hi,

Am Samstag, den 08.05.2021, 10:56 +0200 schrieb Jan Nieuwenhuizen:
> > Leo Prikler  writes:
> 
> Hello again,
> 
> > > I think the launcher that we install in the install-xsession does
> > > not
> > > do sufficient work to set up the environment variables of the
> > > session
> > > appropriately.  In particular, I think it should source
> > > /etc/profile
> > > prior to running Emacs.
> > > 
> > > WDYT?
> > 
> > I think this is a very good idea.
> 
> To follow-up on this: at first glance sourcing /etc/profile seemed to
> fix my problem.  However, I am calling some scripts from Emacs that
> need
> my ~/.bash_profile to be sourced too.
I don't think sourcing ~/.bash_profile will be portable.  As a zsh
user, I'm putting stuff in .zprofile instead, so all my hacks will be
obsoleted if we start mandating bash_profile.  The "portable"
alternative, that is $HOME/.profile does not exist in our current
skeletons.

Putting this aside, I think it'd also be possible to duplicate whatever
settings you might have put into ~/.bash_profile in ~/.exwm.

> So this got me wondering, something has definately changed here.
> Before, this used to work OOTB.  Any ideas what may have changed?
One thing, that changed is Emacs itself.  In particular, we reverted to
ELPA sub-directories for structure, but keeping a hopefully backwards-
compatible hack in subdirs.el
However, I doubt, that this is the only thing making a difference
between now and then.  Since EMACSLOADPATH is wrong, it would seem,
that there is no profile evaluation whatsoever going on, and I'd argue
this has already been the case before, I just don't know when it
changed or whether things just happened to work "OOTB" despite this.

I also think, that any session should be run under the user's shell
with --login.  As far as I can tell, that happens for GNOME under GDM –
executing getenv for a variable that I only set in my .zprofile I see
the correct value – why does it not happen for EXWM under slim?

Greetings,
Leo

bug#48223: EXWM knows nothing about Guix profiles

[Jan Nieuwenhuizen]

> Leo Prikler  writes:

Hello again,

>> I think the launcher that we install in the install-xsession does not
>> do sufficient work to set up the environment variables of the session
>> appropriately.  In particular, I think it should source /etc/profile
>> prior to running Emacs.
>>
>> WDYT?
>
> I think this is a very good idea.

To follow-up on this: at first glance sourcing /etc/profile seemed to
fix my problem.  However, I am calling some scripts from Emacs that need
my ~/.bash_profile to be sourced too.

So this got me wondering, something has definately changed here.
Before, this used to work OOTB.  Any ideas what may have changed?

BTW, I only tested with slim

--8<---cut here---start->8---
(service slim-service-type
  (slim-configuration
   (auto-login? #t)
   (allow-empty-passwords? #t)
   (default-user "janneke")
   ;;(auto-login-session (file-append emacs-exwm "/bin/exwm"))
   (auto-login-session "/home/janneke/bin/exwm")
   (xorg-configuration
(xorg-configuration
 (keyboard-layout keyboard-layout)
 (server-arguments '("-listen" "tcp"
--8<---cut here---end--->8---

and now use the attached exwm, which works OK for me.

Greetings,
Janneke



exwm
Description: Binary data

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#48282: CI fails to build opencv on x86-64

[Guillaume Le Vaillant]

Hi,

It looks like the build farm fails to build the opencv package on
x86-64. The build log (see [1] or [2]) indicates that the build
"timed out after 3600 seconds of silence" in the test phase, more
precisely in the 'opencv_test_aruco' test.

What is strange is that on my machine the build succeeds and this
'opencv_test_aruco' test takes less than 1 second.

Does someone see the test phase getting stuck when building opencv
locally?


[1] https://ci.guix.gnu.org/build/323874/log/raw
[2] https://ci.guix.gnu.org/build/323859/log/raw


signature.asc
Description: PGP signature