* Invalid nar signature
@ 2014-12-15 2:22 David Thompson
2014-12-15 2:33 ` David Thompson
2014-12-15 17:19 ` Ludovic Courtès
0 siblings, 2 replies; 13+ messages in thread
From: David Thompson @ 2014-12-15 2:22 UTC (permalink / raw
To: guix-devel
Hello everyone,
While working on a new guix command, called 'guix publish', I've run
into a snag. The archives I've exported via export-paths in the (guix
store) module are rejected by 'guix substitute-binary' due to the nar
signature being invalid. The signature is a string containing
"nix-archive-1" at the head of the file. I can clearly see that text
there, but the read-string operation that happens in the restore-file
procedure in (guix serialization) says otherwise.
The output of the following code in the context of the
(guix serialization) module is "\r", it should be "nix-archive-1":
(with-input-from-file "some-nar-file"
(lambda ()
(read-string (current-input-port))))
Does anyone know what I'm missing here? Thanks in advance.
--
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2014-12-15 2:22 Invalid nar signature David Thompson
@ 2014-12-15 2:33 ` David Thompson
2014-12-15 17:19 ` Ludovic Courtès
1 sibling, 0 replies; 13+ messages in thread
From: David Thompson @ 2014-12-15 2:33 UTC (permalink / raw
To: guix-devel
David Thompson <dthompson2@worcester.edu> writes:
> The output of the following code in the context of the
> (guix serialization) module is "\r", it should be "nix-archive-1":
>
> (with-input-from-file "some-nar-file"
> (lambda ()
> (read-string (current-input-port))))
Also, note that the following code *does* yield "nix-archive-1":
(with-input-from-file "some-nar-file"
(lambda ()
(read-int (current-input-port))
(read-string (current-input-port))))
So, if I remove the first 8 bytes of the file (which when read as an
integer is 1), things look good. What's going on here?
--
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2014-12-15 2:22 Invalid nar signature David Thompson
2014-12-15 2:33 ` David Thompson
@ 2014-12-15 17:19 ` Ludovic Courtès
2014-12-15 20:08 ` Thompson, David
1 sibling, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2014-12-15 17:19 UTC (permalink / raw
To: David Thompson; +Cc: guix-devel
I think this is due to a subtly misleading file format variation.
If you look at ‘export-paths’, it does:
while there are files to write
write-long-long 1
export-path file
write-long-long 0
‘restore-file-set’ does the opposite, which is to read that long-long to
determine whether there’s data coming up, and then to call
‘restore-file’.
HTH!
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2014-12-15 17:19 ` Ludovic Courtès
@ 2014-12-15 20:08 ` Thompson, David
2014-12-15 21:20 ` Ludovic Courtès
0 siblings, 1 reply; 13+ messages in thread
From: Thompson, David @ 2014-12-15 20:08 UTC (permalink / raw
To: Ludovic Courtès; +Cc: guix-devel
On Mon, Dec 15, 2014 at 12:19 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> I think this is due to a subtly misleading file format variation.
>
> If you look at ‘export-paths’, it does:
>
> while there are files to write
> write-long-long 1
> export-path file
> write-long-long 0
>
> ‘restore-file-set’ does the opposite, which is to read that long-long to
> determine whether there’s data coming up, and then to call
> ‘restore-file’.
Thanks. I'm still a little confused, though. I'm not sure what
change I need to make in order to satisfy the substituter. Do I need
to write a variant of export-paths that leaves off the initial
write-long-long call?
- Dave
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2014-12-15 20:08 ` Thompson, David
@ 2014-12-15 21:20 ` Ludovic Courtès
2014-12-15 21:24 ` Thompson, David
2014-12-15 22:49 ` David Thompson
0 siblings, 2 replies; 13+ messages in thread
From: Ludovic Courtès @ 2014-12-15 21:20 UTC (permalink / raw
To: Thompson, David; +Cc: guix-devel
"Thompson, David" <dthompson2@worcester.edu> skribis:
> On Mon, Dec 15, 2014 at 12:19 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> I think this is due to a subtly misleading file format variation.
>>
>> If you look at ‘export-paths’, it does:
>>
>> while there are files to write
>> write-long-long 1
>> export-path file
>> write-long-long 0
>>
>> ‘restore-file-set’ does the opposite, which is to read that long-long to
>> determine whether there’s data coming up, and then to call
>> ‘restore-file’.
>
> Thanks. I'm still a little confused, though. I'm not sure what
> change I need to make in order to satisfy the substituter. Do I need
> to write a variant of export-paths that leaves off the initial
> write-long-long call?
For illustration purposes, here’s a normal sequence:
--8<---------------cut here---------------start------------->8---
$ wget -O t.nar.bz2 http://hydra.gnu.org/nar/wy70n5zk8qinxjz0wdk9q2hh1zjfb32j-miscfiles-1.5
$ bunzip2 t.nar.bz2
$ ./pre-inst-env guile -c '(use-modules (guix serialization)) (call-with-input-file "t.nar" (lambda (port) (restore-file port "restored")))'
$ ls restored/
share
--8<---------------cut here---------------end--------------->8---
‘restore-file’ is what ‘guix substitute-binary --substitute’ uses. It
expects a single store item–i.e., the variant /without/ the leading
long-long, as you noticed.
To produce that, use ‘write-file’ from (guix serialization):
--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guile -c '(use-modules (guix serialization)) (write-file "/gnu/store/wy70n5zk8qinxjz0wdk9q2hh1zjfb32j-miscfiles-1.5" (current-output-port))' > t.nar
$ ./pre-inst-env guile -c '(use-modules (guix serialization)) (call-with-input-file "t.nar" (lambda (port) (restore-file port "restored")))'
$ ls restored/
share
--8<---------------cut here---------------end--------------->8---
Sorry for the confusion!
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2014-12-15 21:20 ` Ludovic Courtès
@ 2014-12-15 21:24 ` Thompson, David
2014-12-15 22:49 ` David Thompson
1 sibling, 0 replies; 13+ messages in thread
From: Thompson, David @ 2014-12-15 21:24 UTC (permalink / raw
To: Ludovic Courtès; +Cc: guix-devel
On Mon, Dec 15, 2014 at 4:20 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Mon, Dec 15, 2014 at 12:19 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> I think this is due to a subtly misleading file format variation.
>>>
>>> If you look at ‘export-paths’, it does:
>>>
>>> while there are files to write
>>> write-long-long 1
>>> export-path file
>>> write-long-long 0
>>>
>>> ‘restore-file-set’ does the opposite, which is to read that long-long to
>>> determine whether there’s data coming up, and then to call
>>> ‘restore-file’.
>>
>> Thanks. I'm still a little confused, though. I'm not sure what
>> change I need to make in order to satisfy the substituter. Do I need
>> to write a variant of export-paths that leaves off the initial
>> write-long-long call?
>
> For illustration purposes, here’s a normal sequence:
>
> --8<---------------cut here---------------start------------->8---
> $ wget -O t.nar.bz2 http://hydra.gnu.org/nar/wy70n5zk8qinxjz0wdk9q2hh1zjfb32j-miscfiles-1.5
> $ bunzip2 t.nar.bz2
> $ ./pre-inst-env guile -c '(use-modules (guix serialization)) (call-with-input-file "t.nar" (lambda (port) (restore-file port "restored")))'
> $ ls restored/
> share
> --8<---------------cut here---------------end--------------->8---
>
> ‘restore-file’ is what ‘guix substitute-binary --substitute’ uses. It
> expects a single store item–i.e., the variant /without/ the leading
> long-long, as you noticed.
>
> To produce that, use ‘write-file’ from (guix serialization):
>
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guile -c '(use-modules (guix serialization)) (write-file "/gnu/store/wy70n5zk8qinxjz0wdk9q2hh1zjfb32j-miscfiles-1.5" (current-output-port))' > t.nar
> $ ./pre-inst-env guile -c '(use-modules (guix serialization)) (call-with-input-file "t.nar" (lambda (port) (restore-file port "restored")))'
> $ ls restored/
> share
> --8<---------------cut here---------------end--------------->8---
Perfect, thanks!
- Dave
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2014-12-15 21:20 ` Ludovic Courtès
2014-12-15 21:24 ` Thompson, David
@ 2014-12-15 22:49 ` David Thompson
2014-12-16 17:07 ` Ludovic Courtès
1 sibling, 1 reply; 13+ messages in thread
From: David Thompson @ 2014-12-15 22:49 UTC (permalink / raw
To: Ludovic Courtès; +Cc: guix-devel
Ludovic Courtès <ludo@gnu.org> writes:
> To produce that, use ‘write-file’ from (guix serialization):
>
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guile -c '(use-modules (guix serialization)) (write-file "/gnu/store/wy70n5zk8qinxjz0wdk9q2hh1zjfb32j-miscfiles-1.5" (current-output-port))' > t.nar
> $ ./pre-inst-env guile -c '(use-modules (guix serialization)) (call-with-input-file "t.nar" (lambda (port) (restore-file port "restored")))'
> $ ls restored/
> share
> --8<---------------cut here---------------end--------------->8---
The above snippet works. However, 'guix substitute-binary' throws the
following error:
guix substitute-binary: error: invalid nar end-of-file marker
Here's my nar rendering code:
(define (render-nar store-item)
"Render archive of the store path corresponding to STORE-ITEM."
(let ((store-path (string-append %store-directory "/" store-item)))
(values '((content-type . (text/x-nix-archive)))
(lambda (port)
(write-file store-path port)))))
Thoughts?
--
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2014-12-15 22:49 ` David Thompson
@ 2014-12-16 17:07 ` Ludovic Courtès
2015-01-15 2:38 ` David Thompson
0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2014-12-16 17:07 UTC (permalink / raw
To: David Thompson; +Cc: guix-devel
David Thompson <dthompson2@worcester.edu> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> To produce that, use ‘write-file’ from (guix serialization):
>>
>> --8<---------------cut here---------------start------------->8---
>> $ ./pre-inst-env guile -c '(use-modules (guix serialization)) (write-file "/gnu/store/wy70n5zk8qinxjz0wdk9q2hh1zjfb32j-miscfiles-1.5" (current-output-port))' > t.nar
>> $ ./pre-inst-env guile -c '(use-modules (guix serialization)) (call-with-input-file "t.nar" (lambda (port) (restore-file port "restored")))'
>> $ ls restored/
>> share
>> --8<---------------cut here---------------end--------------->8---
>
> The above snippet works. However, 'guix substitute-binary' throws the
> following error:
>
> guix substitute-binary: error: invalid nar end-of-file marker
>
> Here's my nar rendering code:
>
> (define (render-nar store-item)
> "Render archive of the store path corresponding to STORE-ITEM."
> (let ((store-path (string-append %store-directory "/" store-item)))
> (values '((content-type . (text/x-nix-archive)))
> (lambda (port)
> (write-file store-path port)))))
Hmm, some ideas of things to try:
1. Add (force-output port) after (write-file ...).
2. Display the value of ‘x’ in ‘restore-file’ at the point where the
exception is raised.
2. strace the substituter and/or ‘guix publish’ to see exactly what
happens on the wire. Is the end-of-file marker string sent? Is it
received? etc.
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2014-12-16 17:07 ` Ludovic Courtès
@ 2015-01-15 2:38 ` David Thompson
2015-01-15 9:51 ` Ludovic Courtès
0 siblings, 1 reply; 13+ messages in thread
From: David Thompson @ 2015-01-15 2:38 UTC (permalink / raw
To: Ludovic Courtès; +Cc: guix-devel
Back at this again after awhile.
Ludovic Courtès <ludo@gnu.org> writes:
> Hmm, some ideas of things to try:
>
> 1. Add (force-output port) after (write-file ...).
No effect.
> 2. Display the value of ‘x’ in ‘restore-file’ at the point where the
> exception is raised.
Haven't tried this yet.
> 2. strace the substituter and/or ‘guix publish’ to see exactly what
> happens on the wire. Is the end-of-file marker string sent? Is it
> received? etc.
Here's a snippet of the strace output:
http://192.168.1.157/.../iw3jn6a1avv78pp5v2cv42vyh0d8zi0g-guile-toxcore-0.1-6a9fbe0 94.1% of 127.5 KiB) = 104
read(10, "vector tox-max-status-message-le"..., 7728) = 117
read(10, " "..., 7611) = 1448
read(10, "t-last-online (unwrap-tox tox) f"..., 6163) = 1448
read(10, "tox tox) nospam))\n\n(define/unwra"..., 4715) = 1448
read(10, " friend-number group-number)))\n\n"..., 3267) = 1448
read(10, ")))\n (if (negative? result)\n "..., 1819) = 1819
http://192.168.1.157/.../iw3jn6a1avv78pp5v2cv42vyh0d8zi0g-guile-toxcore-0.1-6a9fbe0 100.0% of 127.5 KiB) = 104
http://192.168.1.157/.../iw3jn6a1avv78pp5v2cv42vyh0d8zi0g-guile-toxcore-0.1-6a9fbe0 100.0% of 127.5 KiB) = 104
brk(0x41875000) = 0x41875000
mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3d2aaaf000
mremap(0x7f3d2aaaf000, 135168, 266240, MREMAP_MAYMOVE) = 0x7f3d2aa6e000
mremap(0x7f3d2aa6e000, 266240, 528384, MREMAP_MAYMOVE) = 0x7f3d2a9ed000
mremap(0x7f3d2a9ed000, 528384, 430080, MREMAP_MAYMOVE) = 0x7f3d2a9ed000
munmap(0x7f3d2a9ed000, 430080) = 0
http://192.168.1.157/.../iw3jn6a1avv78pp5v2cv42vyh0d8zi0g-guile-toxcore-0.1-6a9fbe0 100.0% of 127.5 KiB) = 104
open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en_US.UTF-8/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en_US.utf8/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en_US/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en.UTF-8/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en.utf8/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "guix substitute-binary: error: i"..., 62guix substitute-binary: error: invalid nar end-of-file marker
) = 62
exit_group(1) = ?
+++ exited with 1 +++
I'm not sure what's going on here. I thought that maybe the substituter
was getting tripped up by the Scheme code in the uncompressed nar, but
I don't have any reason to believe that's true.
Despite that, I tried to compress the nar with bzip2 just for fun, but I
ran into another problem:
warning: call to primitive-fork while multiple threads are running;
further behavior unspecified. See "Processes" in the
manual, for more information.
I'm running a REPL server in addition to the web server, but I imagine
the web server also spawns additional threads to handle requests, so
either way 'filtered-output-port' won't work here.
The return value of 'waitpid' for the bzip2 pid is:
((18764 . 256))
Thoughts on what to try next? I feel like I'm so close, but I keep
running into walls that prevent me from making much progress.
--
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2015-01-15 2:38 ` David Thompson
@ 2015-01-15 9:51 ` Ludovic Courtès
2015-01-15 13:39 ` Thompson, David
0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2015-01-15 9:51 UTC (permalink / raw
To: David Thompson; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 3389 bytes --]
David Thompson <dthompson2@worcester.edu> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
[...]
>> 2. strace the substituter and/or ‘guix publish’ to see exactly what
>> happens on the wire. Is the end-of-file marker string sent? Is it
>> received? etc.
>
> Here's a snippet of the strace output:
>
> http://192.168.1.157/.../iw3jn6a1avv78pp5v2cv42vyh0d8zi0g-guile-toxcore-0.1-6a9fbe0 94.1% of 127.5 KiB) = 104
> read(10, "vector tox-max-status-message-le"..., 7728) = 117
> read(10, " "..., 7611) = 1448
> read(10, "t-last-online (unwrap-tox tox) f"..., 6163) = 1448
> read(10, "tox tox) nospam))\n\n(define/unwra"..., 4715) = 1448
> read(10, " friend-number group-number)))\n\n"..., 3267) = 1448
> read(10, ")))\n (if (negative? result)\n "..., 1819) = 1819
> http://192.168.1.157/.../iw3jn6a1avv78pp5v2cv42vyh0d8zi0g-guile-toxcore-0.1-6a9fbe0 100.0% of 127.5 KiB) = 104
> http://192.168.1.157/.../iw3jn6a1avv78pp5v2cv42vyh0d8zi0g-guile-toxcore-0.1-6a9fbe0 100.0% of 127.5 KiB) = 104
> brk(0x41875000) = 0x41875000
> mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3d2aaaf000
> mremap(0x7f3d2aaaf000, 135168, 266240, MREMAP_MAYMOVE) = 0x7f3d2aa6e000
> mremap(0x7f3d2aa6e000, 266240, 528384, MREMAP_MAYMOVE) = 0x7f3d2a9ed000
> mremap(0x7f3d2a9ed000, 528384, 430080, MREMAP_MAYMOVE) = 0x7f3d2a9ed000
> munmap(0x7f3d2a9ed000, 430080) = 0
> http://192.168.1.157/.../iw3jn6a1avv78pp5v2cv42vyh0d8zi0g-guile-toxcore-0.1-6a9fbe0 100.0% of 127.5 KiB) = 104
> open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en_US.UTF-8/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en_US.utf8/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en_US/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en.UTF-8/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en.utf8/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/gnu/store/72qm7kc9phvsiw6j7xgn1ii0f6s9mx8i-guix-0.8.3b09332/share/locale/en/LC_MESSAGES/guix.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
> write(2, "guix substitute-binary: error: i"..., 62guix substitute-binary: error: invalid nar end-of-file marker
> ) = 62
> exit_group(1) = ?
> +++ exited with 1 +++
Normally, when the error happens, the substituter has already created at
least one file in the target directory,
/gnu/store/iw3jn6a1avv78pp5v2cv42vyh0d8zi0g-guile-toxcore-0.1-6a9fbe0.
Could you apply the patch below, and then run:
rm -rf foo
./pre-inst-env guix substitute-binary --substitute \
/gnu/store/iw3jn6a1avv78pp5v2cv42vyh0d8zi0g-guile-toxcore-0.1-6a9fbe0 \
$PWD/foo > stdout
ls -lRa foo > ls-R
and then send ‘stdout’ and ‘ls-R’?
Could you also check if the files in ‘foo’ look corrupt or anything?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1387 bytes --]
diff --git a/guix/serialization.scm b/guix/serialization.scm
index 64eacf9..d3bdea3 100644
--- a/guix/serialization.scm
+++ b/guix/serialization.scm
@@ -292,19 +292,21 @@ Restore it as FILE."
(define (read-eof-marker)
(match (read-string port)
(")" #t)
- (x (raise
+ (x
+ (pk 'bad-eof x)
+ (raise
(condition
(&message (message "invalid nar end-of-file marker"))
(&nar-read-error (port port) (file file) (token x)))))))
(match (list (read-string port) (read-string port) (read-string port))
(("(" "type" "regular")
- (call-with-output-file file (cut read-contents port <>))
+ (call-with-output-file (pk 'reg file) (cut read-contents port <>))
(read-eof-marker))
(("(" "type" "symlink")
(match (list (read-string port) (read-string port))
(("target" target)
- (symlink target file)
+ (symlink target (pk 'symlink file))
(read-eof-marker))
(x (raise
(condition
@@ -312,7 +314,7 @@ Restore it as FILE."
(&nar-read-error (port port) (file file) (token x)))))))
(("(" "type" "directory")
(let ((dir file))
- (mkdir dir)
+ (mkdir (pk 'dir dir))
(let loop ((prefix (read-string port)))
(match prefix
("entry"
[-- Attachment #3: Type: text/plain, Size: 623 bytes --]
> Despite that, I tried to compress the nar with bzip2 just for fun, but I
> ran into another problem:
>
> warning: call to primitive-fork while multiple threads are running;
> further behavior unspecified. See "Processes" in the
> manual, for more information.
>
> I'm running a REPL server in addition to the web server, but I imagine
> the web server also spawns additional threads to handle requests, so
> either way 'filtered-output-port' won't work here.
(web server http) does not use threads so it should be OK. But we’ll
see that afterwards. :-)
Thanks,
Ludo’.
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2015-01-15 9:51 ` Ludovic Courtès
@ 2015-01-15 13:39 ` Thompson, David
2015-01-15 16:22 ` Ludovic Courtès
0 siblings, 1 reply; 13+ messages in thread
From: Thompson, David @ 2015-01-15 13:39 UTC (permalink / raw
To: Ludovic Courtès; +Cc: guix-devel
On Thu, Jan 15, 2015 at 4:51 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> David Thompson <dthompson2@worcester.edu> skribis:
>
>> Despite that, I tried to compress the nar with bzip2 just for fun, but I
>> ran into another problem:
>>
>> warning: call to primitive-fork while multiple threads are running;
>> further behavior unspecified. See "Processes" in the
>> manual, for more information.
>>
>> I'm running a REPL server in addition to the web server, but I imagine
>> the web server also spawns additional threads to handle requests, so
>> either way 'filtered-output-port' won't work here.
>
> (web server http) does not use threads so it should be OK. But we’ll
> see that afterwards. :-)
Ah, okay. Even so, requiring a single-threaded application in order
to use compressed/decompressed ports makes hacking on 'guix publish'
inconvenient, as it eliminates use of the REPL. But sure, we'll deal
with this afterwards.
- Dave
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2015-01-15 13:39 ` Thompson, David
@ 2015-01-15 16:22 ` Ludovic Courtès
2015-01-15 17:23 ` Thompson, David
0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2015-01-15 16:22 UTC (permalink / raw
To: Thompson, David; +Cc: guix-devel
"Thompson, David" <dthompson2@worcester.edu> skribis:
> On Thu, Jan 15, 2015 at 4:51 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> David Thompson <dthompson2@worcester.edu> skribis:
>>
>>> Despite that, I tried to compress the nar with bzip2 just for fun, but I
>>> ran into another problem:
>>>
>>> warning: call to primitive-fork while multiple threads are running;
>>> further behavior unspecified. See "Processes" in the
>>> manual, for more information.
>>>
>>> I'm running a REPL server in addition to the web server, but I imagine
>>> the web server also spawns additional threads to handle requests, so
>>> either way 'filtered-output-port' won't work here.
>>
>> (web server http) does not use threads so it should be OK. But we’ll
>> see that afterwards. :-)
>
> Ah, okay. Even so, requiring a single-threaded application in order
> to use compressed/decompressed ports makes hacking on 'guix publish'
> inconvenient, as it eliminates use of the REPL.
Agreed. We’ll probably need libbz2 bindings at some point.
Ludo’.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Invalid nar signature
2015-01-15 16:22 ` Ludovic Courtès
@ 2015-01-15 17:23 ` Thompson, David
0 siblings, 0 replies; 13+ messages in thread
From: Thompson, David @ 2015-01-15 17:23 UTC (permalink / raw
To: Ludovic Courtès; +Cc: guix-devel
On Thu, Jan 15, 2015 at 11:22 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Thu, Jan 15, 2015 at 4:51 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> (web server http) does not use threads so it should be OK. But we’ll
>>> see that afterwards. :-)
>>
>> Ah, okay. Even so, requiring a single-threaded application in order
>> to use compressed/decompressed ports makes hacking on 'guix publish'
>> inconvenient, as it eliminates use of the REPL.
>
> Agreed. We’ll probably need libbz2 bindings at some point.
I was about to go down that road last night. ;)
- Dave
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-01-15 17:24 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-15 2:22 Invalid nar signature David Thompson
2014-12-15 2:33 ` David Thompson
2014-12-15 17:19 ` Ludovic Courtès
2014-12-15 20:08 ` Thompson, David
2014-12-15 21:20 ` Ludovic Courtès
2014-12-15 21:24 ` Thompson, David
2014-12-15 22:49 ` David Thompson
2014-12-16 17:07 ` Ludovic Courtès
2015-01-15 2:38 ` David Thompson
2015-01-15 9:51 ` Ludovic Courtès
2015-01-15 13:39 ` Thompson, David
2015-01-15 16:22 ` Ludovic Courtès
2015-01-15 17:23 ` Thompson, David
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.