Invalid nar signature

Invalid nar signature

[David Thompson]

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

Re: Invalid nar signature

[David Thompson]

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

Re: Invalid nar signature

[Ludovic Courtès]

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’.

Re: Invalid nar signature

[Thompson, David]

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

Re: Invalid nar signature

[Ludovic Courtès]

"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’.

Re: Invalid nar signature

[Thompson, David]

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

Re: Invalid nar signature

[David Thompson]

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

Re: Invalid nar signature

[Ludovic Courtès]

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’.

Re: Invalid nar signature

[David Thompson]

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

Re: Invalid nar signature

[Ludovic Courtès]

[-- 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’.

Re: Invalid nar signature

[Thompson, David]

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

Re: Invalid nar signature

[Ludovic Courtès]

"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’.

Re: Invalid nar signature

[Thompson, David]

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