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
>
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
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
>
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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):
>
>
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
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
> > >
> 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?
>
>
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
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
28 matches
Mail list logo
