From simon at josefsson.org  Wed Dec  7 22:42:59 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 07 Dec 2022 22:42:59 +0100
Subject: [gnutls-help] guile-gnutls-3.7.11 released [stable]
Message-ID: <m2pmcunb4s.fsf@fika.lan>

Guile-GnuTLS provides Guile bindings for the GnuTLS library.

Project homepage:
  https://gitlab.com/gnutls/guile

The release is available here:
  https://gitlab.com/gnutls/guile/-/releases/v3.7.11

Documentation:
  https://gnutls.gitlab.io/guile/manual/
  https://gnutls.gitlab.io/guile/manual/gnutls-guile.html
  https://gnutls.gitlab.io/guile/manual/gnutls-guile.pdf

Here are the compressed sources and a GPG detached signature:
  https://ftpmirror.gnu.org/gnutls/guile-gnutls-3.7.11.tar.gz
  https://ftpmirror.gnu.org/gnutls/guile-gnutls-3.7.11.tar.gz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are the SHA1 and SHA256 checksums:

1065c7d1f7cd18794d383fbca5c7476831ab25cd  guile-gnutls-3.7.11.tar.gz
BY6qXHY+Gfv5PotO78ESgPgHBTXBOMmb4R8AzWhWE98  guile-gnutls-3.7.11.tar.gz

The SHA256 checksum is base64 encoded, instead of the
hexadecimal encoding that most checksum tools default to.

Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact.  First, be sure to download both the .sig file
and the corresponding tarball.  Then, run a command like this:

  gpg --verify guile-gnutls-3.7.11.tar.gz.sig

The signature should match the fingerprint of the following key:

  pub   ed25519 2019-03-20 [SC]
        B1D2 BD13 75BE CB78 4CF4  F8C4 D73C F638 C53C 06BE
  uid   Simon Josefsson <simon at josefsson.org>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

  gpg --locate-external-key simon at josefsson.org

  gpg --recv-keys 51722B08FE4745A2

As a last resort to find the key, you can try the official GNU
keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify guile-gnutls-3.7.11.tar.gz.sig


This release was bootstrapped with the following tools:
  Autoconf 2.71
  Automake 1.16.5
  Gnulib v0.1-5573-g440b528b1d
  Makeinfo 7.0.1

NEWS

* Noteworthy changes in release 3.7.11 (2022-12-07) [stable]

** Build fixes related to git-version-gen.  Fixes: #9.
It is now possible to run 'autoreconf' from within a tarball.

Happy hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221207/66fc4b61/attachment-0001.sig>

From ludo at gnu.org  Tue Dec 13 11:39:10 2022
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Tue, 13 Dec 2022 11:39:10 +0100
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <m2k0428xht.fsf@fika.lan> (Simon Josefsson's message of "Thu, 10
 Nov 2022 19:39:42 +0100")
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
 <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
 <87h70fal2b.fsf@gnu.org> <875ygsjfo9.fsf@latte.josefsson.org>
 <87k0582ex0.fsf@gnu.org> <87v8oqieqt.fsf@latte.josefsson.org>
 <Y0bsbnQLEKx62Cwt@argenau.bebt.de>
 <878rliwtrq.fsf@latte.josefsson.org> <87a65uquyv.fsf@gnu.org>
 <871qr5bnhk.fsf@latte.josefsson.org> <m2k0428xht.fsf@fika.lan>
Message-ID: <871qp3y4dt.fsf@gnu.org>

Hi Simon,

Sorry for the long delay.

Simon Josefsson <simon at josefsson.org> skribis:

> I pushed out 3.7.10 to improve maintainer rules a bit.  Would you like
> to make a 3.7.11 shortly?  To test the release process and get your
> OpenPGP key into distributions' keyring.  I'm hoping the process is just
> 1) clone repository, 2) ./bootstrap, 3) follow README-release.

I see you went ahead with new releases, thank you!

Now that Gnulib?s pulled in, building from a checkout is significantly
more difficult; for example, the package in Guix cannot be updated as-is
because we?d first need to download a copy of all of Gnulib (with an
?origin?) because ./autopull.sh won?t work in the isolated, network-less
build environment.

(We could build from the source tarball, but Guix is trying to gradually
move away from that as part of its effort on reproducible builds,
because tarballs are in fact build products.)

Since there?s little C and IMO not a strong need for a sophisticated
release machinery, I wonder if we could avoid the dependency on Gnulib?

Sorry for the late and perhaps unexpected reply.  :-)

Cheers,
Ludo?.


From simon at josefsson.org  Tue Dec 13 13:01:20 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 13 Dec 2022 13:01:20 +0100
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <871qp3y4dt.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
 =?iso-8859-1?Q?=22's?= message of "Tue, 13
 Dec 2022 11:39:10 +0100")
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
 <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
 <87h70fal2b.fsf@gnu.org> <875ygsjfo9.fsf@latte.josefsson.org>
 <87k0582ex0.fsf@gnu.org> <87v8oqieqt.fsf@latte.josefsson.org>
 <Y0bsbnQLEKx62Cwt@argenau.bebt.de>
 <878rliwtrq.fsf@latte.josefsson.org> <87a65uquyv.fsf@gnu.org>
 <871qr5bnhk.fsf@latte.josefsson.org> <m2k0428xht.fsf@fika.lan>
 <871qp3y4dt.fsf@gnu.org>
Message-ID: <874jtzcy27.fsf@josefsson.org>

Ludovic Court?s <ludo at gnu.org> writes:

> Hi Simon,
>
> Sorry for the long delay.
>
> Simon Josefsson <simon at josefsson.org> skribis:
>
>> I pushed out 3.7.10 to improve maintainer rules a bit.  Would you like
>> to make a 3.7.11 shortly?  To test the release process and get your
>> OpenPGP key into distributions' keyring.  I'm hoping the process is just
>> 1) clone repository, 2) ./bootstrap, 3) follow README-release.
>
> I see you went ahead with new releases, thank you!
>
> Now that Gnulib?s pulled in, building from a checkout is significantly
> more difficult; for example, the package in Guix cannot be updated as-is
> because we?d first need to download a copy of all of Gnulib (with an
> ?origin?) because ./autopull.sh won?t work in the isolated, network-less
> build environment.
>
> (We could build from the source tarball, but Guix is trying to gradually
> move away from that as part of its effort on reproducible builds,
> because tarballs are in fact build products.)
>
> Since there?s little C and IMO not a strong need for a sophisticated
> release machinery, I wonder if we could avoid the dependency on Gnulib?

Sure, let's see what we can do.  Several files in the previous release
comes from gnulib too, so I don't think this is about dropping gnulib
completely, only re-arranging things to work smoother.  I'd like to
understand the problem more first, as I think there are many ways to
solve it, and this is likely to become a generic problem affecting many
projects.

I can understand that you would want to build from git instead of
tarballs.  How does the download and build process work in Guix?
Without knowing anything about the environment, I imagine there is some
part of the process that downloads the git archive from gitlab, checks
out a particular git tag and verify the PGP signature or compute a hash
checksum and compares it?  Can't that process be teached how to also
download the git submodule?

Alternatively, couldn't Guix package gnulib as a separate package
(similar to autoconf-archive or some other installed source-repository),
and we could have a build-dependency on that?  ./bootstrap.sh knows
about --gnulib-refdir and --gnulib-srcdir to use external gnulib copies.
Then you don't have to teach your download process about git submodules.

Another alternative is to drop the gnulib submodule and to check in the
files from gnulib into git.  This is essentially what 3.7.10 did, since
we copied several files from gnulib.  However then I think you'd might
as well build from tarballs, because this approach turns the git
repository into a manually maintained build artifact (built by the
maintainer by running some set of tools that may or may not be committed
to git) -- which seems even worse from a security/reproducibility point
of view than automatically generated build artifacts (tarball).

There are more options too, but I think the first approach should be to
teach your download process about git submodules, or to understand
exactly why that is a bad idea.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221213/b352f228/attachment.sig>

From ludo at gnu.org  Tue Dec 20 15:00:24 2022
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Tue, 20 Dec 2022 15:00:24 +0100
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <874jtzcy27.fsf@josefsson.org> (Simon Josefsson's message of
 "Tue, 13 Dec 2022 13:01:20 +0100")
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
 <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
 <87h70fal2b.fsf@gnu.org> <875ygsjfo9.fsf@latte.josefsson.org>
 <87k0582ex0.fsf@gnu.org> <87v8oqieqt.fsf@latte.josefsson.org>
 <Y0bsbnQLEKx62Cwt@argenau.bebt.de>
 <878rliwtrq.fsf@latte.josefsson.org> <87a65uquyv.fsf@gnu.org>
 <871qr5bnhk.fsf@latte.josefsson.org> <m2k0428xht.fsf@fika.lan>
 <871qp3y4dt.fsf@gnu.org> <874jtzcy27.fsf@josefsson.org>
Message-ID: <87mt7i6upz.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> skribis:

> Ludovic Court?s <ludo at gnu.org> writes:

[...]

>> Now that Gnulib?s pulled in, building from a checkout is significantly
>> more difficult; for example, the package in Guix cannot be updated as-is
>> because we?d first need to download a copy of all of Gnulib (with an
>> ?origin?) because ./autopull.sh won?t work in the isolated, network-less
>> build environment.
>>
>> (We could build from the source tarball, but Guix is trying to gradually
>> move away from that as part of its effort on reproducible builds,
>> because tarballs are in fact build products.)
>>
>> Since there?s little C and IMO not a strong need for a sophisticated
>> release machinery, I wonder if we could avoid the dependency on Gnulib?
>
> Sure, let's see what we can do.  Several files in the previous release
> comes from gnulib too, so I don't think this is about dropping gnulib
> completely, only re-arranging things to work smoother.  I'd like to
> understand the problem more first, as I think there are many ways to
> solve it, and this is likely to become a generic problem affecting many
> projects.
>
> I can understand that you would want to build from git instead of
> tarballs.  How does the download and build process work in Guix?
> Without knowing anything about the environment, I imagine there is some
> part of the process that downloads the git archive from gitlab, checks
> out a particular git tag and verify the PGP signature or compute a hash
> checksum and compares it?  Can't that process be teached how to also
> download the git submodule?

Yes, we can change the origin to grab sub-modules as well:

        (origin
          (method git-fetch)
          (uri (git-reference
                (url home-page)
                (recursive? #t)  ; ? here
                (commit (string-append "v" version))))
          (sha256
           (base32
            "06i19a7a3w80msd15ckqwnlnq38vf2frnfk3dyk77086if89mm4a"))
          (file-name (git-file-name name version))
          (patches (search-patches "gnutls-cross.patch")))

As a result, the build process starts by cloning the Gnulib repository,
which is orders of magnitudes bigger than that of Guile-GnuTLS.

But that?s not enough: now ./bootstrap expects ?git? to be in $PATH, so
I need to add that dependency, and it wants to run ./autopull.sh, so I
need to patch its shebang, etc.; here?s the modified package:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 1878 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221220/2a51a4db/attachment.bin>
-------------- next part --------------

That?s not good enough though, because:

--8<---------------cut here---------------start------------->8---
starting phase `pre-bootstrap'
patch-shebang: autopull.sh: changing `/bin/sh' to `/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh'
phase `pre-bootstrap' succeeded after 0.0 seconds
starting phase `bootstrap'
running './bootstrap'
patch-shebang: ./bootstrap: changing `/bin/sh' to `/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh'
./bootstrap: Bootstrapping from checked-out guile-gnutls sources...
./autopull.sh: getting gnulib files...
fatal: not a git repository (or any of the parent directories): .git
./bootstrap: autopull.sh failed.
error: in phase 'bootstrap': uncaught exception:
%exception #<&invoke-error program: "./bootstrap" arguments: () exit-status: 1 term-signal: #f stop-signal: #f> 
phase `bootstrap' failed after 1.0 seconds
--8<---------------cut here---------------end--------------->8---

Taking a step back, we?re using Gnulib for these modules:

  git-version-gen
  havelib
  gitlog-to-changelog
  readme-release
  update-copyright

Does Gnulib ?pay for its weight??  In this case, I don?t think so.

In Guix, I manually copied ?git-version-gen? and ?gitlog-to-changelog?
in the tree, back in the day.  The ?bootstrap? script does little more
than ?autoreconf -vfi? (nowadays it does weird things related to i18n,
but that?s another story).  Yes, this duplicates two files and a few
lines in ?Makefile.am? and ?configure.ac?, but the end result is far
more tractable IMO?.

Mind you, this is not criticism of Gnulib in general; as you know I was
an early adopter and promoter, and it?s served us well in Guile for its
C portability helpers.  I think we have to check the cost/benefit ratio,
which has both technical and social aspects to it, and in this
particular case, I view Gnulib an unnecessary burden.

WDYT?

Ludo?.

? The bootstrap + Gnulib machinery in Guile-GnuTLS is almost 900 lines:

--8<---------------cut here---------------start------------->8---
$ wc -l bootstrap* cfg.mk
  214 bootstrap
   44 bootstrap.conf
  594 bootstrap-funclib.sh
   39 cfg.mk
  891 total
--8<---------------cut here---------------end--------------->8---

From simon at josefsson.org  Tue Dec 20 20:34:42 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 Dec 2022 20:34:42 +0100
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87mt7i6upz.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
 =?iso-8859-1?Q?=22's?= message of "Tue, 20
 Dec 2022 15:00:24 +0100")
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
 <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
 <87h70fal2b.fsf@gnu.org> <875ygsjfo9.fsf@latte.josefsson.org>
 <87k0582ex0.fsf@gnu.org> <87v8oqieqt.fsf@latte.josefsson.org>
 <Y0bsbnQLEKx62Cwt@argenau.bebt.de>
 <878rliwtrq.fsf@latte.josefsson.org> <87a65uquyv.fsf@gnu.org>
 <871qr5bnhk.fsf@latte.josefsson.org> <m2k0428xht.fsf@fika.lan>
 <871qp3y4dt.fsf@gnu.org> <874jtzcy27.fsf@josefsson.org>
 <87mt7i6upz.fsf@gnu.org>
Message-ID: <87o7rxna25.fsf@josefsson.org>

Ludovic Court?s <ludo at gnu.org> writes:

>> I can understand that you would want to build from git instead of
>> tarballs.  How does the download and build process work in Guix?
>> Without knowing anything about the environment, I imagine there is some
>> part of the process that downloads the git archive from gitlab, checks
>> out a particular git tag and verify the PGP signature or compute a hash
>> checksum and compares it?  Can't that process be teached how to also
>> download the git submodule?
>
> Yes, we can change the origin to grab sub-modules as well:
>
>         (origin
>           (method git-fetch)
>           (uri (git-reference
>                 (url home-page)
>                 (recursive? #t)  ; ? here

Ah, great, so at least there is no fundamental problem with git
submodules.

> starting phase `pre-bootstrap'
> patch-shebang: autopull.sh: changing `/bin/sh' to `/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh'
> phase `pre-bootstrap' succeeded after 0.0 seconds
> starting phase `bootstrap'
> running './bootstrap'
> patch-shebang: ./bootstrap: changing `/bin/sh' to `/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh'
> ./bootstrap: Bootstrapping from checked-out guile-gnutls sources...
> ./autopull.sh: getting gnulib files...
> fatal: not a git repository (or any of the parent directories): .git
> ./bootstrap: autopull.sh failed.

Strange, I wonder what is happening there, and why it doesn't happen on
GitLab CI/CD -- it also checks out the git repository including
submodules, and then ./bootstrap is ran.

> Taking a step back, we?re using Gnulib for these modules:
>
>   git-version-gen
>   havelib
>   gitlog-to-changelog
>   readme-release
>   update-copyright
>
> Does Gnulib ?pay for its weight??  In this case, I don?t think so.
>
> In Guix, I manually copied ?git-version-gen? and ?gitlog-to-changelog?
> in the tree, back in the day.  The ?bootstrap? script does little more
> than ?autoreconf -vfi? (nowadays it does weird things related to i18n,
> but that?s another story).  Yes, this duplicates two files and a few
> lines in ?Makefile.am? and ?configure.ac?, but the end result is far
> more tractable IMO?.
>
> Mind you, this is not criticism of Gnulib in general; as you know I was
> an early adopter and promoter, and it?s served us well in Guile for its
> C portability helpers.  I think we have to check the cost/benefit ratio,
> which has both technical and social aspects to it, and in this
> particular case, I view Gnulib an unnecessary burden.
>
> WDYT?
>
> Ludo?.
>
> ? The bootstrap + Gnulib machinery in Guile-GnuTLS is almost 900 lines:
>
> $ wc -l bootstrap* cfg.mk
>   214 bootstrap
>    44 bootstrap.conf
>   594 bootstrap-funclib.sh
>    39 cfg.mk
>   891 total

I share your frustration with complex dependencies.  Is your problem
mainly that it is harder to build guile-gnutls, or is it the size of the
added code, or the actual code?  Maybe a combination, but I'm not sure
which is the main problem here.

The main reason I added the dependencies was 1) to get 'make web-manual'
to produce a manual during CI/CD, 2) to get a proven 'make release'
infrastructure including the README-release file, 3) added
git-version-gen to avoid manual work and to get CI/CD tarballs with good
naming, 4) 'make syntax-check', 5) havelib, and maybe some other parts
that I forgot.

When I look at what changed between these releases, I think the main
complication is the new bootstrap infrastructure.  That is not critical
for using gnulib, and in fact it is highly complex for what it should be
doing: copying a couple of files and then run autoreconf.  I don't see
what extra features it brings guile-gnutls.

I have pushed a branch 'jas/drop-bootstrap' which reverts back to a
simple ./bootstrap script but still uses gnulib-tool from the git
submodule to import some files.  What do you think?

https://gitlab.com/gnutls/guile/-/commit/ec362e8bdb7604295fc24f6f20aea5e5ecf78117

Maybe this strikes a better balance between reusing elements from gnulib
but keeping complexity low.  CI/CD passes with no changes, suggesting
that we really never relied on anything else from ./bootstrap.

If you think using gnulib-tool is too costly as well, we can replace it
with a couple of 'cp' commands, but I'm hoping this complexity reduction
is sufficient.

Would you like to make a 3.7.12 out of this?  I'm happy to do it if you
prefer, but it would be nice to get your PGP key into distributors'
trust anchors for guile-gnutls, and I don't know of any mechanism except
having the person make a release.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221220/424138c5/attachment-0001.sig>

From ludo at gnu.org  Sun Dec 25 21:39:59 2022
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Sun, 25 Dec 2022 21:39:59 +0100
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87o7rxna25.fsf@josefsson.org> (Simon Josefsson's message of
 "Tue, 20 Dec 2022 20:34:42 +0100")
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
 <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
 <87h70fal2b.fsf@gnu.org> <875ygsjfo9.fsf@latte.josefsson.org>
 <87k0582ex0.fsf@gnu.org> <87v8oqieqt.fsf@latte.josefsson.org>
 <Y0bsbnQLEKx62Cwt@argenau.bebt.de>
 <878rliwtrq.fsf@latte.josefsson.org> <87a65uquyv.fsf@gnu.org>
 <871qr5bnhk.fsf@latte.josefsson.org> <m2k0428xht.fsf@fika.lan>
 <871qp3y4dt.fsf@gnu.org> <874jtzcy27.fsf@josefsson.org>
 <87mt7i6upz.fsf@gnu.org> <87o7rxna25.fsf@josefsson.org>
Message-ID: <87bknrw734.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> skribis:

> I share your frustration with complex dependencies.  Is your problem
> mainly that it is harder to build guile-gnutls, or is it the size of the
> added code, or the actual code?  Maybe a combination, but I'm not sure
> which is the main problem here.

It?s a combination.  One way to look at it is the barrier to entry: if
someone rather familiar with autotools, Gnulib, etc. is unable to
readily configure and build the code, then we have a problem it means it
may be intractable for someone who?s getting started with Guile.

Another way to look at it is the ?infrastructure? complexity compared to
the actual code complexity.

> The main reason I added the dependencies was 1) to get 'make web-manual'
> to produce a manual during CI/CD, 2) to get a proven 'make release'
> infrastructure including the README-release file, 3) added
> git-version-gen to avoid manual work and to get CI/CD tarballs with good
> naming, 4) 'make syntax-check', 5) havelib, and maybe some other parts
> that I forgot.

I could live without #4 and #5; I?m not convinced it brings much to a
project like this one.

> When I look at what changed between these releases, I think the main
> complication is the new bootstrap infrastructure.  That is not critical
> for using gnulib, and in fact it is highly complex for what it should be
> doing: copying a couple of files and then run autoreconf.  I don't see
> what extra features it brings guile-gnutls.
>
> I have pushed a branch 'jas/drop-bootstrap' which reverts back to a
> simple ./bootstrap script but still uses gnulib-tool from the git
> submodule to import some files.  What do you think?
>
> https://gitlab.com/gnutls/guile/-/commit/ec362e8bdb7604295fc24f6f20aea5e5ecf78117

It looks much better this way, thanks!

> Maybe this strikes a better balance between reusing elements from gnulib
> but keeping complexity low.  CI/CD passes with no changes, suggesting
> that we really never relied on anything else from ./bootstrap.
>
> If you think using gnulib-tool is too costly as well, we can replace it
> with a couple of 'cp' commands, but I'm hoping this complexity reduction
> is sufficient.

Having to clone all of Gnulib just to pick a couple of files isn?t great
from a packaging perspective, but we can start this way.

> Would you like to make a 3.7.12 out of this?  I'm happy to do it if you
> prefer, but it would be nice to get your PGP key into distributors'
> trust anchors for guile-gnutls, and I don't know of any mechanism except
> having the person make a release.

By ?trust anchor?, you mean informally the set of people who ever
release it, right?

I?d be happy to make a release, I?ve just been fairly busy making
releases lately.  :-)

Thanks for your feedback!

Ludo?.


From simon at josefsson.org  Mon Dec 26 00:24:33 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 Dec 2022 00:24:33 +0100
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87bknrw734.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
 =?iso-8859-1?Q?=22's?= message of "Sun, 25
 Dec 2022 21:39:59 +0100")
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
 <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
 <87h70fal2b.fsf@gnu.org> <875ygsjfo9.fsf@latte.josefsson.org>
 <87k0582ex0.fsf@gnu.org> <87v8oqieqt.fsf@latte.josefsson.org>
 <Y0bsbnQLEKx62Cwt@argenau.bebt.de>
 <878rliwtrq.fsf@latte.josefsson.org> <87a65uquyv.fsf@gnu.org>
 <871qr5bnhk.fsf@latte.josefsson.org> <m2k0428xht.fsf@fika.lan>
 <871qp3y4dt.fsf@gnu.org> <874jtzcy27.fsf@josefsson.org>
 <87mt7i6upz.fsf@gnu.org> <87o7rxna25.fsf@josefsson.org>
 <87bknrw734.fsf@gnu.org>
Message-ID: <87tu1jkqxa.fsf@josefsson.org>

Ludovic Court?s <ludo at gnu.org> writes:

>> The main reason I added the dependencies was 1) to get 'make web-manual'
>> to produce a manual during CI/CD, 2) to get a proven 'make release'
>> infrastructure including the README-release file, 3) added
>> git-version-gen to avoid manual work and to get CI/CD tarballs with good
>> naming, 4) 'make syntax-check', 5) havelib, and maybe some other parts
>> that I forgot.
>
> I could live without #4 and #5; I?m not convinced it brings much to a
> project like this one.

The guile.m4 macro that we use depends on havelib's m4/lib-*.m4 which
also needs build-aux/config.rpath.

>> Maybe this strikes a better balance between reusing elements from gnulib
>> but keeping complexity low.  CI/CD passes with no changes, suggesting
>> that we really never relied on anything else from ./bootstrap.
>>
>> If you think using gnulib-tool is too costly as well, we can replace it
>> with a couple of 'cp' commands, but I'm hoping this complexity reduction
>> is sufficient.
>
> Having to clone all of Gnulib just to pick a couple of files isn?t great
> from a packaging perspective, but we can start this way.

Yeah, maybe we can make the git submodule checkout optional?  It could
be used for developers who want to upgrade these files, or by people who
really wants to re-bootstrap everything from original source code.  I
have pushed the following branch now:

https://gitlab.com/gnutls/guile/-/commits/jas/drop-bootstrap2

The gnulib submodule is still present, but you don't have to use it if
you don't want all that bandwidth usage.  Maybe we could even drop the
git submodule too -- what we would lose then is the exact gnulib git
commit that we used for importing the gnulib files.

>> Would you like to make a 3.7.12 out of this?  I'm happy to do it if you
>> prefer, but it would be nice to get your PGP key into distributors'
>> trust anchors for guile-gnutls, and I don't know of any mechanism except
>> having the person make a release.
>
> By ?trust anchor?, you mean informally the set of people who ever
> release it, right?

Yes.  Assuming there are any distributors that check PGP signatures...

> I?d be happy to make a release, I?ve just been fairly busy making
> releases lately.  :-)

Yay, please merge jas/drop-bootstrap2 (if you like it) to master, make
any further changes you want, and then follow README-releases steps!

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221226/a4734fa7/attachment.sig>