Hi,
Maxim Cournoyer writes:
> Dale Mellor writes:
[...]
>> The output is a little unpredictable. The script (which is
>>admittedly somewhat pathological)
>>
>> (job '(next-second '(0 30)) '(begin (display "test: ")
>> (system "date")))
>>
>>
Hi,
Ludovic Courtès writes:
> Maxim Cournoyer skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> If I write:
>>>
>>> (gexp->derivation "foo" #~(mkdir #$output))
>>>
>>> I can be sure that my derivation depends on nothing but (default-guile).
>>> This is important for tests, but also to
Hi Ludovic,
Ludovic Courtès writes:
> Hi Maxim,
>
> Maxim Cournoyer skribis:
>
>>> We have this:
>>>
>>> (define-record-type* #,(id #'stem #'< #'stem #'>)
>>>stem
>>>#,(id #'stem #'make- #'stem)
>>>#,(id #'stem #'stem #'?)
>>>#,@(map
Hi Maxim,
Maxim Cournoyer skribis:
>> We have this:
>>
>> (define-record-type* #,(id #'stem #'< #'stem #'>)
>>stem
>>#,(id #'stem #'make- #'stem)
>>#,(id #'stem #'stem #'?)
>>#,@(map (lambda (name getter def)
>>
Hi,
Marek Paśnikowski skribis:
> grafting '/gnu/store/vp4ybqhxdrf4b2fk37c0s72g6iafqsmz-gtk-4.8.1-doc' ->
> '/gnu/store/7hfq1hbhfsmzjil433cjd8mngvxd05xv-gtk-4.8.1-doc'...
> ERROR: In procedure fport_fill_input: Input/output error
This indicates an error while writing to your storage device,
Simon Streit writes:
> Mathieu Othacehe writes:
>
>>> Disk image is: axygxkgkgcgbk2gjd6q521h85shp7hwf-image.iso from
>>> https://ci.guix.gnu.org/build/125952/details.
>>>
>>> Please find attached some logs too:
>>
>> It looks like you experimented a crash (segfault or so), and the
>> backtrace
Hello,
There is currently an issue involving lf, the package build used by Guix
pulls from the commit tagged r27, however since commit #a94015d, a %d is
replaced with a %v, and the build will fail with the %d. The diff can be
seen here:
Hi,
Ludovic Courtès writes:
> Maxim Cournoyer skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> If I write:
>>>
>>> (gexp->derivation "foo" #~(mkdir #$output))
>>>
>>> I can be sure that my derivation depends on nothing but (default-guile).
>>> This is important for tests, but also to
Mathieu Othacehe writes:
>> Disk image is: axygxkgkgcgbk2gjd6q521h85shp7hwf-image.iso from
>> https://ci.guix.gnu.org/build/125952/details.
>>
>> Please find attached some logs too:
>
> It looks like you experimented a crash (segfault or so), and the
> backtrace is not really helpful here sadly.
Hi Ludovic,
Ludovic Courtès writes:
> Hi,
>
> Maxim Cournoyer skribis:
>
The issue seems to be with the serialization of the
object nested in the
record. I tried this at the REPL:
scheme@(guile-user)> ,m (gnu services mail)
scheme@(gnu services mail)>
Hi André,
André Batista skribis:
> qui 24 nov 2022 às 12:17:19 (1669303039), nan...@riseup.net enviou:
>> Upstream issue #6433
>
> Fixed on upstream commit 936b184e7494158c20e522981f4a324cac6ffa47
Excellent. Let’s close this bug once we’ve updated the ‘libgit2’
package to a version that
qui 24 nov 2022 às 12:17:19 (1669303039), nan...@riseup.net enviou:
> Upstream issue #6433
Fixed on upstream commit 936b184e7494158c20e522981f4a324cac6ffa47
Maxim Cournoyer skribis:
> Ludovic Courtès writes:
[...]
>> If I write:
>>
>> (gexp->derivation "foo" #~(mkdir #$output))
>>
>> I can be sure that my derivation depends on nothing but (default-guile).
>> This is important for tests, but also to make sure we can use this
>> primitive
Hi,
Maxim Cournoyer skribis:
>>> The issue seems to be with the serialization of the
>>> object nested in the
>>> record. I tried this at the REPL:
>>>
>>> scheme@(guile-user)> ,m (gnu services mail)
>>> scheme@(gnu services mail)> (namespace-configuration (name "inbox"))
>>> $8 = #< name:
Hi,
On Mon, 28 Nov 2022 at 00:34, b...@bokr.com wrote:
> Are all the conditions for a clean sync
> of the file system where /gnu/store is mounted guaranteed?
More or less, yes. You can read some discussion in patch#58035 [1].
1:
15 matches
Mail list logo
