GNU bug report logs - #72183
[PATCH] gnu: guile: Update to 3.0.10.

Previous Next

To reply to this bug, email your comments to 72183 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Thompson, David" <dthompson2 <at> worcester.edu>
To: Ryan Prior via Guix-patches <guix-patches <at> gnu.org>
Subject: [PATCH] gnu: guile: Update to 3.0.10.
Date: Thu, 18 Jul 2024 16:16:35 -0400

[Message part 1 (text/plain, inline)]

I thought this would be an easy upgrade, but it seems that it will
cause a lot of churn. 'guix refresh' says:

    Building the following 1640 packages would ensure 3146 dependent
packages are rebuilt

I believe this is because Shepherd is built against guile-3.0-latest,
and elogind depends on Shepherd.

Guix *should* be in a position to get fresh Guile builds quickly, but
I guess this process will be slow until the guile-3.0 package can be
upgraded to 3.0.10 (which will require a world rebuild) at which point
Shepherd can return to using guile-3.0.

There's a lot of compiler improvements and bug fixes in 3.0.10, so it
would be nice to have this update land soon. After this, I can update
guile-hoot depend on it rather than guile-next. Several other packages
depending on guile-next could also be upgraded to use guile-3.0-latest
instead, such as guile-ares-rs.

Who can help me "shepherd" this upgrade? ;)

Thanks,

- Dave

[0001-gnu-guile-Update-to-3.0.10.patch (text/x-patch, attachment)]

Message #8 received at 72183 <at> debbugs.gnu.org (full text, mbox):

From: "Thompson, David" <dthompson2 <at> worcester.edu>
To: 72183 <at> debbugs.gnu.org
Subject: [PATCH] gnu: shepherd 0.9: Switch from guile-3.0-latest to guile-3.0.
Date: Thu, 18 Jul 2024 16:49:16 -0400

[Message part 1 (text/plain, inline)]

Thanks to Efraim for pointing out that we could simply switch Shepherd
to refer to guile-3.0 instead of guile-3.0-latest.  The attached patch
does this.

Now updating guile-3.0-latest causes much less churn:

Building the following 23 packages would ensure 47 dependent packages
are rebuilt: guile-studio <at> 0.1.1-1.dd0ad42 guile-chickadee <at> 0.10.0
guile-gemini <at> 0.1 guile-openai <at> 0.2-1.751cd5d guile-newra <at> 0-0.266e72e
haunt <at> 0.3.0 guile-bash <at> 0.1.6-0.1eabc56 lokke <at> 0.0.0-1.92d3637
swineherd <at> 0.0.4 cuirass <at> 1.2.0-6.0eaf7b6 emacs-guix <at> 0.5.2-7.455272c
guile-imanifest <at> 0.0.0-0.ccd5a21 cl-ospm <at> 0.0.2 guix-jupyter <at> 0.2.2
guix-build-coordinator-agent-only <at> 0-109.406db8a
nar-herder <at> 0-37.82f9371 guix-minimal <at> 1.4.0-23.843b85c gwl <at> 0.5.1
gwl-next <at> 0.5.0-1.706a089 guix-modules <at> 0.1.0
guix-daemon <at> 1.4.0-23.843b85c bffe <at> 0-6.7df2aa6 hpcguix-web <at> 0.4.1

- Dave

[0001-gnu-shepherd-0.9-Switch-from-guile-3.0-latest-to-gui.patch (text/x-patch, attachment)]

Message #11 received at 72183 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: "Thompson, David" <dthompson2 <at> worcester.edu>
Cc: 72183 <at> debbugs.gnu.org
Subject: Re: [bug#72183] [PATCH] gnu: guile: Update to 3.0.10.
Date: Fri, 19 Jul 2024 18:32:12 +0200

"Thompson, David" <dthompson2 <at> worcester.edu> skribis:

> From f6c6486dab767ba50c4c2ffbb55f10bbf4ee1000 Mon Sep 17 00:00:00 2001
> Message-ID: <f6c6486dab767ba50c4c2ffbb55f10bbf4ee1000.1721332994.git.dthompson2 <at> worcester.edu>
> From: David Thompson <dthompson2 <at> worcester.edu>
> Date: Thu, 18 Jul 2024 14:54:20 -0400
> Subject: [PATCH] gnu: guile: Update to 3.0.10.
>
> * gnu/packages/guile.scm (guile-3.0-latest): Update to 3.0.10.
>
> Change-Id: Id9d58199f1fa3307c94f442c185307d2f4a9ce6f

> From 76c82888fefcef1226c6d18a4cf790d5e02d1c32 Mon Sep 17 00:00:00 2001
> Message-ID: <76c82888fefcef1226c6d18a4cf790d5e02d1c32.1721335570.git.dthompson2 <at> worcester.edu>
> From: David Thompson <dthompson2 <at> worcester.edu>
> Date: Thu, 18 Jul 2024 16:43:32 -0400
> Subject: [PATCH] gnu: shepherd 0.9: Switch from guile-3.0-latest to guile-3.0.
> 
> * gnu/packages/admin.scm (shepherd-0.9)[native-inputs]: Use guile-3.0.
> [inputs]: Ditto.
> 
> Change-Id: I7f7efabc43e11e413300c6aa4c22919070d22389

LGTM.  (Commit the Shepherd patch first.)

Thank you! :-)

Ludo’.

Message #16 received at 72183-done <at> debbugs.gnu.org (full text, mbox):

From: "Thompson, David" <dthompson2 <at> worcester.edu>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 72183-done <at> debbugs.gnu.org
Subject: Re: [bug#72183] [PATCH] gnu: guile: Update to 3.0.10.
Date: Fri, 19 Jul 2024 13:09:25 -0400

On Fri, Jul 19, 2024 at 12:32 PM Ludovic Courtès <ludo <at> gnu.org> wrote:
>
> LGTM.  (Commit the Shepherd patch first.)

Pushed! Thanks for the review!

- Dave

Message #23 received at 72183 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: "Thompson, David" <dthompson2 <at> worcester.edu>
Cc: 72183 <at> debbugs.gnu.org
Subject: Re: [bug#72183] [PATCH] gnu: guile: Update to 3.0.10.
Date: Fri, 19 Jul 2024 22:40:29 +0200

Hey,

I temporarily reverted the commits that upgrade Guile and adjust Hoot in
31244f5cefae4c14a1a5d441dc3b3626b5f32abc so we can investigate the issue
below (which broke ‘guix pull’) without pressure.

Turns out ‘guile-3.0-latest’ is used to build Guix itself (via ‘guix
pull’, but also the ‘guix’ package) and this cause a failure of
guix-cli-core.drv:

--8<---------------cut here---------------start------------->8---
error: failed to compile 'guix/scripts/authenticate.scm':

In language/tree-il/peval.scm:
  1558:45 19 (loop _ _ _ value)
In srfi/srfi-1.scm:
   586:17 18 (map1 (#<tree-il (call (@ (guile) format) (const #f) (const "(signature ~a ~a ~a)") (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical data t1416)) (call (@ (gcrypt pk-crypto) canonical-sexp->string) (call (@ (gcrypt pk-crypto) sign) (lexical data t1416) (lexical secret-key t1418))) (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical public-key t1420)))>))
In language/tree-il/peval.scm:
  1558:45 17 (loop _ _ _ value)
In srfi/srfi-1.scm:
   586:29 16 (map1 (#<tree-il (const #f)> #<tree-il (const "(signature ~a ~a ~a)")> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical data t1416))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (call (@ (gcrypt pk-crypto) sign) (lexical data t1416) (lexical secret-key t1418)))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical public-key t1420))>))
   586:29 15 (map1 (#<tree-il (const "(signature ~a ~a ~a)")> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical data t1416))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (call (@ (gcrypt pk-crypto) sign) (lexical data t1416) (lexical secret-key t1418)))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical public-key t1420))>))
   586:17 14 (map1 (#<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical data t1416))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (call (@ (gcrypt pk-crypto) sign) (lexical data t1416) (lexical secret-key t1418)))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical public-key t1420))>))
In language/tree-il/peval.scm:

error: failed to compile 'guix/scripts/publish.scm':

In language/tree-il/peval.scm:
  1558:45 13 (loop _ _ _ value)
In srfi/srfi-1.scm:
   586:17 12 (map1 (#<tree-il (lexical data t1416)>))
In language/tree-il/peval.scm:
  1558:45 19 (loop _ _ _ values)
In srfi/srfi-1.scm:
   586:17 18 (map1 (#<tree-il (call (@ (guile) format) (const #f) (const "(signature ~a ~a ~a)") (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical data t6047)) (call (@ (gcrypt pk-crypto) canonical-sexp->string) (call (@ (gcrypt pk-crypto) sign) (lexical data t6047) (lexical secret-key t6048))) (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical public-key t6049)))>))
In language/tree-il/peval.scm:
   887:11 11 (loop _ _ #<<counter> effort: #<variable 7fffe74eca90 value: 484> size: #<variable 7fffe74eca80 value: 20> continuation: #<procedure abort ()> recursive?: #t data: #<tree-il (lambda ((name . signature-sexp)) (lambda-case (((data secret-key public-key) #f #f #f () (t1416 t1418 t1420)) (call (@ (gcrypt pk-crypto) string->canonical-sexp) (call (@ (guile) format) (const #f) (const "(signature ~a ~a ~a)") (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical data t1416)) (cal?> ?)
   371:20 10 (visit-operand #<<operand> var: #<<var> name: data gensym: data-ae6ce62b6fb2770-3a7 refcount: 1 set?: #f> sym: #{data 1412}# visit: #<procedure 7fffecafb040 at language/tree-il/peval.scm:1011:40 (exp counter ctx)> source: #<tree-il (primcall values (call (@ (gcrypt pk-crypto) bytevector->hash-data) (lexical sha256 sha256-ae6ce62b6fb2770-39d) (const #:key-type) (call (@ (gcrypt pk-crypto) key-type) (lexical public-key public-key-ae6ce62b6fb2770-39b))))> visit-count: 1 use-count:?> ?)

  1558:45 17 (loop _ _ _ value)
In srfi/srfi-1.scm:
   586:29 16 (map1 (#<tree-il (const #f)> #<tree-il (const "(signature ~a ~a ~a)")> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical data t6047))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (call (@ (gcrypt pk-crypto) sign) (lexical data t6047) (lexical secret-key t6048)))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical public-key t6049))>))
   586:29 15 (map1 (#<tree-il (const "(signature ~a ~a ~a)")> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical data t6047))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (call (@ (gcrypt pk-crypto) sign) (lexical data t6047) (lexical secret-key t6048)))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical public-key t6049))>))
   586:17 14 (map1 (#<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical data t6047))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (call (@ (gcrypt pk-crypto) sign) (lexical data t6047) (lexical secret-key t6048)))> #<tree-il (call (@ (gcrypt pk-crypto) canonical-sexp->string) (lexical public-key t6049))>))
In language/tree-il/peval.scm:
  1319:22  9 (loop _ #<vhash 7fffecafb0a0 92 pairs> #<<counter> effort: #<variable 7fffe74eca90 value: 484> size: #<variable 7fffe74eca80 value: 20> continuation: #<procedure abort ()> recursive?: #t data: #<tree-il (lambda ((name . signature-sexp)) (lambda-case (((data secret-key public-key) #f #f #f () (t1416 t1418 t1420)) (call (@ (gcrypt pk-crypto) string->canonical-sexp) (call (@ (guile) format) (const #f) (const "(signature ~a ~a ~a)") (call (@ (gcrypt pk-crypto) canonical-sexp->strin?> ?)
In srfi/srfi-1.scm:
   586:17  8 (map1 (#<tree-il (call (@ (gcrypt pk-crypto) bytevector->hash-data) (lexical sha256 sha256-ae6ce62b6fb2770-39d) (const #:key-type) (call (@ (gcrypt pk-crypto) key-type) (lexical public-key public-key-ae6ce62b6fb2770-39b)))>))
In language/tree-il/peval.scm:
  1558:45 13 (loop _ _ _ value)
In srfi/srfi-1.scm:
   586:17 12 (map1 (#<tree-il (lexical data t6047)>))
In language/tree-il/peval.scm:
  1762:18  7 (loop _ _ _ _)
In ice-9/boot-9.scm:
  1676:22  6 (raise-exception _ #:continuable? _)
  1676:22  5 (raise-exception _ #:continuable? _)
  1802:13  4 (_ #<&compound-exception components: (#<&error> #<&origin origin: #f> #<&message message: "internal error: unexpected kwarg syms ~S ~S"> #<&irritants irritants: (((#:key-type key-type #f)) (t1441))> #<&exception-with-kind-and-args kind: misc-error args: (#f "internal error: unexpected kwarg syms ~S ~S" (((#:key-type key-type #f)) (t1441)) #f)>)>)
In guix/build/compile.scm:
    191:6  3 
[ 36/ 50] compiling...	 44.0% of 25 files(_ misc-error #f "internal error: unexpected kwarg syms ~S ~S" (((#:key-type key-type #f)) (t1441)) #f)
In ice-9/boot-9.scm:
  1749:15  2 (with-exception-handler #<procedure 7fffec498f30 at ice-9/boot-9.scm:1853:7 (exn)> _ #:unwind? _ #:unwind-for-type _)
In guix/build/compile.scm:
   194:21  1 (_)
In unknown file:
           0 (make-stack #t)
guix/build/compile.scm:194:21: internal error: unexpected kwarg syms ((#:key-type key-type #f)) (t1441)

[ 38/ 50] compiling...	 52.0% of 25 files
[ 38/ 50] compiling...	 52.0% of 25 files
[ 39/ 50] compiling...	 56.0% of 25 files
[ 40/ 50] compiling...	 60.0% of 25 filesbuilder for `/gnu/store/w9yvw8972xns0j3j36lg4lbyqv5m2f25-guix-cli-core.drv' failed with exit code 1

[ 41/ 50] compiling...	 64.0% of 25 files
[ 42/ 50] compiling...	 68.0% of 25 filesderivation '/gnu/store/w9yvw8972xns0j3j36lg4lbyqv5m2f25-guix-cli-core.drv' offloaded to '141.80.167.177' failed: build of `/gnu/store/w9yvw8972xns0j3j36lg4lbyqv5m2f25-guix-cli-core.drv' failed

[ 43/ 50] compiling...	 72.0% of 25 files
[ 44/ 50] compiling...	 76.0% of 25 files
[ 45/ 50] compiling...	 80.0% of 25 files
[ 46/ 50] compiling...	 84.0% of 25 files
[ 47/ 50] compiling...	 88.0% of 25 files
[ 48/ 50] compiling...	 92.0% of 25 files
[ 49/ 50] compiling...	 96.0% of 25 filescannot build derivation `/gnu/store/9wyflvlskm5s5043zrrivfv3mv58n1vw-guix-cli-core-modules.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/ych1s7kdksq08rzd1m6ddkpp7x8pw56x-guix-cli.drv': 1 dependencies couldn't be built
--8<---------------cut here---------------end--------------->8---

(Taken from <https://ci.guix.gnu.org/eval/1497691/log/raw> and edited to
be more readable.)

The expressions leading to this internal compiler error are:

  (bytevector->hash-data (sha256 (string->utf8 s))
                         #:key-type (key-type public-key))

and:

  (bytevector->hash-data sha256
                         #:key-type (key-type public-key))

This sounds like a compiler bug, possibly related to Guile commit
f95bf6921e13799abca6a0a13087609c42baba6b.

Note that ‘bytevector->hash-data’ comes from Guile-Gcrypt, which was
itself still compiled with 3.0.9.  So there’s a possibility that the bug
comes with this particular combination as is exhibited by cross-module
inlining.

To be continued…

Ludo’.

Message #26 received at 72183 <at> debbugs.gnu.org (full text, mbox):

From: "Thompson, David" <dthompson2 <at> worcester.edu>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 72183 <at> debbugs.gnu.org
Subject: Re: [bug#72183] [PATCH] gnu: guile: Update to 3.0.10.
Date: Fri, 19 Jul 2024 18:07:17 -0400

Hey Ludo,

On Fri, Jul 19, 2024 at 4:40 PM Ludovic Courtès <ludo <at> gnu.org> wrote:
>
> Hey,
>
> I temporarily reverted the commits that upgrade Guile and adjust Hoot in
> 31244f5cefae4c14a1a5d441dc3b3626b5f32abc so we can investigate the issue
> below (which broke ‘guix pull’) without pressure.

Oh no, sorry! I ran 'guix pull' after pushing these commits and didn't
experience issues so I thought all was well. :(

> Turns out ‘guile-3.0-latest’ is used to build Guix itself (via ‘guix
> pull’, but also the ‘guix’ package) and this cause a failure of
> guix-cli-core.drv:

How about using guile-3.0 for Guix so that future Guile updates can be
done without fear?

> The expressions leading to this internal compiler error are:
>
>   (bytevector->hash-data (sha256 (string->utf8 s))
>                          #:key-type (key-type public-key))
>
> and:
>
>   (bytevector->hash-data sha256
>                          #:key-type (key-type public-key))
>
> This sounds like a compiler bug, possibly related to Guile commit
> f95bf6921e13799abca6a0a13087609c42baba6b.
>
> Note that ‘bytevector->hash-data’ comes from Guile-Gcrypt, which was
> itself still compiled with 3.0.9.  So there’s a possibility that the bug
> comes with this particular combination as is exhibited by cross-module
> inlining.

Yup, that certainly sounds like what is happening here. Cross-module
inlining + the new keyword args optimization.

Sorry for breaking 'guix pull'. I thought I had scoped the changes
down to a safe level. :(

- Dave

Message #29 received at 72183 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: "Thompson, David" <dthompson2 <at> worcester.edu>
Cc: 72183 <at> debbugs.gnu.org
Subject: Re: [bug#72183] [PATCH] gnu: guile: Update to 3.0.10.
Date: Sun, 01 Sep 2024 19:31:35 +0200

Hi David,

"Thompson, David" <dthompson2 <at> worcester.edu> skribis:

> On Fri, Jul 19, 2024 at 4:40 PM Ludovic Courtès <ludo <at> gnu.org> wrote:
>>
>> Hey,
>>
>> I temporarily reverted the commits that upgrade Guile and adjust Hoot in
>> 31244f5cefae4c14a1a5d441dc3b3626b5f32abc so we can investigate the issue
>> below (which broke ‘guix pull’) without pressure.
>
> Oh no, sorry! I ran 'guix pull' after pushing these commits and didn't
> experience issues so I thought all was well. :(

No worries, I didn’t expect that either.

>> Turns out ‘guile-3.0-latest’ is used to build Guix itself (via ‘guix
>> pull’, but also the ‘guix’ package) and this cause a failure of
>> guix-cli-core.drv:
>
> How about using guile-3.0 for Guix so that future Guile updates can be
> done without fear?

We can do that, though I like the idea of following Guile closely.

[...]

>> Note that ‘bytevector->hash-data’ comes from Guile-Gcrypt, which was
>> itself still compiled with 3.0.9.  So there’s a possibility that the bug
>> comes with this particular combination as is exhibited by cross-module
>> inlining.
>
> Yup, that certainly sounds like what is happening here. Cross-module
> inlining + the new keyword args optimization.

I came up with a reduced test case and reported it here:

  https://issues.guix.gnu.org/72936

Another problem I had forgotten is that Guile current ‘main’ and 3.0.10
fails to build on 32-bit platforms:

  https://issues.guix.gnu.org/72215

The best course of action might be to release 3.0.11 with bug fixes for
at least these two things.  WDYT?

In the meantime, I keep using the Guile channel, which works well for me:

  (channel
    (name 'guile)
    (url "https://git.savannah.gnu.org/git/guile.git")
    (branch "main"))

Ludo’.

Message #32 received at 72183 <at> debbugs.gnu.org (full text, mbox):

From: "Thompson, David" <dthompson2 <at> worcester.edu>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 72183 <at> debbugs.gnu.org
Subject: Re: [bug#72183] [PATCH] gnu: guile: Update to 3.0.10.
Date: Mon, 9 Sep 2024 08:24:06 -0400

Hey Ludo,

On Sun, Sep 1, 2024 at 1:31 PM Ludovic Courtès <ludo <at> gnu.org> wrote:
>
> Hi David,
>
> "Thompson, David" <dthompson2 <at> worcester.edu> skribis:
>
> > On Fri, Jul 19, 2024 at 4:40 PM Ludovic Courtès <ludo <at> gnu.org> wrote:
> >>
> >> Hey,
> >>
> >> I temporarily reverted the commits that upgrade Guile and adjust Hoot in
> >> 31244f5cefae4c14a1a5d441dc3b3626b5f32abc so we can investigate the issue
> >> below (which broke ‘guix pull’) without pressure.
> >
> > Oh no, sorry! I ran 'guix pull' after pushing these commits and didn't
> > experience issues so I thought all was well. :(
>
> No worries, I didn’t expect that either.
>
> >> Turns out ‘guile-3.0-latest’ is used to build Guix itself (via ‘guix
> >> pull’, but also the ‘guix’ package) and this cause a failure of
> >> guix-cli-core.drv:
> >
> > How about using guile-3.0 for Guix so that future Guile updates can be
> > done without fear?
>
> We can do that, though I like the idea of following Guile closely.

Okay, let's not do this, then. :)

> >> Note that ‘bytevector->hash-data’ comes from Guile-Gcrypt, which was
> >> itself still compiled with 3.0.9.  So there’s a possibility that the bug
> >> comes with this particular combination as is exhibited by cross-module
> >> inlining.
> >
> > Yup, that certainly sounds like what is happening here. Cross-module
> > inlining + the new keyword args optimization.
>
> I came up with a reduced test case and reported it here:
>
>   https://issues.guix.gnu.org/72936

Awesome, thanks!  Forwarded this to Andy.

> Another problem I had forgotten is that Guile current ‘main’ and 3.0.10
> fails to build on 32-bit platforms:
>
>   https://issues.guix.gnu.org/72215
>
> The best course of action might be to release 3.0.11 with bug fixes for
> at least these two things.  WDYT?

Yes, I think skipping 3.0.10 entirely makes sense.  I will update
guile-next at some point, though, since these issues are already
present in the current version of that package.

> In the meantime, I keep using the Guile channel, which works well for me:
>
>   (channel
>     (name 'guile)
>     (url "https://git.savannah.gnu.org/git/guile.git")
>     (branch "main"))

Oh neat, I didn't realize this was a thing.

Thanks,

- Dave

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.