From simon at josefsson.org  Tue Oct  4 11:15:44 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 04 Oct 2022 11:15:44 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
Message-ID: <87tu4kx83j.fsf@latte.josefsson.org>

Hi

The GnuTLS developers talked about separating the Guile bindings for
GnuTLS into a separate git repository, with the advantages being 1)
simplify core GnuTLS maintenance and reduce complexity, 2) allow a
separate release schedule for guile-gnutls.  What do you think?  Is
there any disadvantage with this?  I'm happy to (co-?)create a
guile-gnutls repository and do a first release of it to get the ball
rolling.

/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/20221004/ec49b49a/attachment.sig>

From ametzler at bebt.de  Tue Oct  4 18:31:16 2022
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 4 Oct 2022 18:31:16 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87tu4kx83j.fsf@latte.josefsson.org>
References: <87tu4kx83j.fsf@latte.josefsson.org>
Message-ID: <Yzxf1HH+La2Xk9bC@argenau.bebt.de>

On 2022-10-04 Simon Josefsson <simon at josefsson.org> wrote:
> Hi

> The GnuTLS developers talked about separating the Guile bindings for
> GnuTLS into a separate git repository, with the advantages being 1)
> simplify core GnuTLS maintenance and reduce complexity, 2) allow a
> separate release schedule for guile-gnutls.  What do you think?  Is
> there any disadvantage with this?  I'm happy to (co-?)create a
> guile-gnutls repository and do a first release of it to get the ball
> rolling.

FWIW Russ Alberry recently had some thoughts about maintaining language
bindings.  https://lists.debian.org/debian-devel/2022/08/msg00265.html

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ludo at gnu.org  Tue Oct  4 20:19:38 2022
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Tue, 04 Oct 2022 20:19:38 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87tu4kx83j.fsf@latte.josefsson.org> (Simon Josefsson's message
 of "Tue, 04 Oct 2022 11:15:44 +0200")
References: <87tu4kx83j.fsf@latte.josefsson.org>
Message-ID: <87pmf7tps5.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> skribis:

> The GnuTLS developers talked about separating the Guile bindings for
> GnuTLS into a separate git repository,

Heh, good to know.

> with the advantages being 1) simplify core GnuTLS maintenance and
> reduce complexity, 2) allow a separate release schedule for
> guile-gnutls.  What do you think?  Is there any disadvantage with
> this?  I'm happy to (co-?)create a guile-gnutls repository and do a
> first release of it to get the ball rolling.

I think the repository layout has to mirror the social construct.
Having the bindings within GnuTLS was IMO a strength at a time when
there was cohesion.  Nowadays, it seems like it?s become a hindrance to
everyone involved so separating the bindings sounds like a reasonable
choice.

I?ll happily take your offer to create the initial repo if it still
holds.  :-)

The Guile-Gcrypt bindings have been maintained separately since their
inception and it?s worked rather well.

Thanks for your message!

Ludo?.


From simon at josefsson.org  Wed Oct  5 15:30:04 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 05 Oct 2022 15:30:04 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87pmf7tps5.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
 =?iso-8859-1?Q?=22's?= message of "Tue, 04
 Oct 2022 20:19:38 +0200")
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
Message-ID: <87lepuxusj.fsf@latte.josefsson.org>

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

> Hi Simon,
>
> Simon Josefsson <simon at josefsson.org> skribis:
>
>> The GnuTLS developers talked about separating the Guile bindings for
>> GnuTLS into a separate git repository,
>
> Heh, good to know.

Hi.  Sorry, I should have qualified that as _some_ GnuTLS developers,
thus not speaking for everyone.

>> with the advantages being 1) simplify core GnuTLS maintenance and
>> reduce complexity, 2) allow a separate release schedule for
>> guile-gnutls.  What do you think?  Is there any disadvantage with
>> this?  I'm happy to (co-?)create a guile-gnutls repository and do a
>> first release of it to get the ball rolling.
>
> I think the repository layout has to mirror the social construct.
> Having the bindings within GnuTLS was IMO a strength at a time when
> there was cohesion.  Nowadays, it seems like it?s become a hindrance to
> everyone involved so separating the bindings sounds like a reasonable
> choice.

Right, I sadly agree with this, wishing some things were different.

> I?ll happily take your offer to create the initial repo if it still
> holds.  :-)

Certainly.  Is gitlab.com/gnutls a suitable place for this (do you have
a gitlab.com username?), or should we try to move it to savannah or some
other place?  Do you know if someone other than you are likely to work
on guile-gnutls soon?  The guile/ contributors list is short:

Author: Alon Bar-Lev <alon.barlev at gmail.com>
Author: Daiki Ueno <ueno at gnu.org>
Author: Leonardo Bras <leobras.c at gmail.com>
Author: Ludovic Court?s <ludo at gnu.org>
Author: Marcin Cie?lak <saper at saper.info>
Author: Nikos Mavrogiannopoulos <nmav at gnutls.org>
Author: Simon Josefsson <jas at josefsson.org>
Author: Simon South <simon at simonsouth.net>
Author: Tim R?hsen <tim.ruehsen at gmx.de>

> The Guile-Gcrypt bindings have been maintained separately since their
> inception and it?s worked rather well.

Right, and my experience with supporting language bindings in libidn is
that they are better done externally than internally in the upstream
library project.  The language-specific expertise required seldom exists
in the upstream project, and whatever project-specific expertise is
needed tend to be less important and can be solved through normal
documentation requests within the core project.

/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/20221005/a7a28bbc/attachment-0001.sig>

From ludo at gnu.org  Fri Oct  7 11:32:34 2022
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Fri, 07 Oct 2022 11:32:34 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87lepuxusj.fsf@latte.josefsson.org> (Simon Josefsson's message
 of "Wed, 05 Oct 2022 15:30:04 +0200")
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org>
Message-ID: <87wn9cc72l.fsf@gnu.org>

Hello,

Simon Josefsson <simon at josefsson.org> skribis:

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

[...]

>> I?ll happily take your offer to create the initial repo if it still
>> holds.  :-)
>
> Certainly.  Is gitlab.com/gnutls a suitable place for this (do you have
> a gitlab.com username?), or should we try to move it to savannah or some
> other place?  Do you know if someone other than you are likely to work
> on guile-gnutls soon?  The guile/ contributors list is short:
>
> Author: Alon Bar-Lev <alon.barlev at gmail.com>
> Author: Daiki Ueno <ueno at gnu.org>
> Author: Leonardo Bras <leobras.c at gmail.com>
> Author: Ludovic Court?s <ludo at gnu.org>
> Author: Marcin Cie?lak <saper at saper.info>
> Author: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> Author: Simon Josefsson <jas at josefsson.org>
> Author: Simon South <simon at simonsouth.net>
> Author: Tim R?hsen <tim.ruehsen at gmx.de>

I?m fine having it as a sub-project under gitlab.com/gnutls.  Otherwise,
if it?s not a sub-project, it can just as well be on notabug.org say.

Building the new repo will require ?git filter-branch? magic to get
guile/, doc/, and maybe configure.ac bits.

Thanks for helping out!

Ludo?.


From simon at josefsson.org  Fri Oct  7 13:17:06 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 07 Oct 2022 13:17:06 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87wn9cc72l.fsf@gnu.org>
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
Message-ID: <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>

> 
> I?m fine having it as a sub-project under gitlab.com/gnutls.?
> Otherwise,
> if it?s not a sub-project, it can just as well be on notabug.org say.
> 
> Building the new repo will require ?git filter-branch? magic to get
> guile/, doc/, and maybe configure.ac bits.

Now there is https://gitlab.com/jas/guile-gnutls created like this:

git clone https://gitlab.com/gnutls/gnutls.git guile-gnutls
cd guile-gnutls/
git-filter-repo --path configure.ac --path .gitignore --path
doc/.gitignore --path README.md --path doc/ --path guile/ --path
Makefile.am  --path m4/guile.m4 --path NEWS
git remote add guile-gnutls git at gitlab.com:jas/guile-gnutls.git
git push -u guile-gnutls --all
git push -u guile-gnutls --tags

Is this a suitable base to start on?  Maybe we can iterate a couple of
times to get a suitable setup, I think we should prune some more in
doc/ which according to git-filter-repo man pages should be done by
another run of it to prune the repository further.  Getting a top-level
configure.ac and Makefile.am is a main work item here.

Is https://notabug.org/cwebber/guile-gcrypt a good template for a guile
language binding of a C library?  I prefer to put the manual in doc/
but otherwise it looks good.  Compared to the above setup, we may want
to rename guile/ into gnutls/.

One we are happy with the git repo, I would like it to be at
gitlab.com/gnutls since then we get CI/CD build testing which I don't
think notabug offers?  There should probably be a --path .gitlab-ci.yml
above too.

One question is about version numbers.. it should probably have its own
version number, right?  Would starting at 0.0.0 be a problem for
packaging, or should we start with 3.7.8 (upstream gnutls version) and
then count upwards (separate from GnuTLS versions) from there?  I
prefer starting with 0.0.0 and using semantic versioning from the
start.

/Simon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221007/bcfdc26b/attachment.sig>

From ludo at gnu.org  Fri Oct  7 14:13:16 2022
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Fri, 07 Oct 2022 14:13:16 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
 (Simon Josefsson's message of "Fri, 07 Oct 2022 13:17:06 +0200")
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
 <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
Message-ID: <87h70fal2b.fsf@gnu.org>

Simon Josefsson <simon at josefsson.org> skribis:

> Now there is https://gitlab.com/jas/guile-gnutls created like this:

Great!

> git clone https://gitlab.com/gnutls/gnutls.git guile-gnutls
> cd guile-gnutls/
> git-filter-repo --path configure.ac --path .gitignore --path
> doc/.gitignore --path README.md --path doc/ --path guile/ --path
> Makefile.am  --path m4/guile.m4 --path NEWS
> git remote add guile-gnutls git at gitlab.com:jas/guile-gnutls.git
> git push -u guile-gnutls --all
> git push -u guile-gnutls --tags

I wonder if we should omit NEWS as it blurs the history a bit, in which
case we?d later add a new NEWS file.

WDYT?

> Is this a suitable base to start on?  Maybe we can iterate a couple of
> times to get a suitable setup, I think we should prune some more in
> doc/ which according to git-filter-repo man pages should be done by
> another run of it to prune the repository further.  Getting a top-level
> configure.ac and Makefile.am is a main work item here.

Yes, in doc/ we only need gnutls-guile.texi, gnutls.texi (of which
gnutls-guile.texi was extracted) and Makefile.am I think.

> Is https://notabug.org/cwebber/guile-gcrypt a good template for a guile
> language binding of a C library?

Yes, except that Guile-Gcrypt uses the FFI (pure Scheme).

> I prefer to put the manual in doc/ but otherwise it looks good.

Agreed.

> Compared to the above setup, we may want to rename guile/ into
> gnutls/.

Or move guile/ to the top level, but maybe that can be done in a later
commit.

> One we are happy with the git repo, I would like it to be at
> gitlab.com/gnutls since then we get CI/CD build testing which I don't
> think notabug offers?  There should probably be a --path .gitlab-ci.yml
> above too.

Sounds good.

> One question is about version numbers.. it should probably have its own
> version number, right?  Would starting at 0.0.0 be a problem for
> packaging, or should we start with 3.7.8 (upstream gnutls version) and
> then count upwards (separate from GnuTLS versions) from there?  I
> prefer starting with 0.0.0 and using semantic versioning from the
> start.

That?s a good question.  I would tend to start at 1.0.0 (because it?s
stable).  However some distros, such as Debian, have a binary package
called ?guile-gnutls? that?s currently at 3.7.x, so the version number
may cause them trouble.  I don?t know whether we should take that into
consideration or leave it up to distros.

WDYT?

Ludo?.


From ametzler at bebt.de  Fri Oct  7 19:26:29 2022
From: ametzler at bebt.de (Andreas Metzler)
Date: Fri, 7 Oct 2022 19:26:29 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
 <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
Message-ID: <Y0BhRXgtMQgmwEo3@argenau.bebt.de>

On 2022-10-07 Simon Josefsson <simon at josefsson.org> wrote:
[...]
> One question is about version numbers.. it should probably have its own
> version number, right?  Would starting at 0.0.0 be a problem for
> packaging, or should we start with 3.7.8 (upstream gnutls version) and
> then count upwards (separate from GnuTLS versions) from there?  I
> prefer starting with 0.0.0 and using semantic versioning from the
> start.

We my Debian hat on: Pretty pretty please use a version number > 3.7.8
to allow a simple upgrade from guile-gnutls 3.7.8 to the new separate
version. (Instead of requiring fiddling and ugliness with empty
transition packages or epoch.)

Restarting version also imho does not make sense: Afaiui the next
guile-gnutls will not be something totaly new but essentially 3.7.8
with a changed README. The version number should reflect that. Or do you
envision a rename, too?

cu Andreas


From simon at josefsson.org  Mon Oct 10 09:25:47 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Oct 2022 09:25:47 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <Y0BhRXgtMQgmwEo3@argenau.bebt.de> (Andreas Metzler's message of
 "Fri, 7 Oct 2022 19:26:29 +0200")
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
 <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
 <Y0BhRXgtMQgmwEo3@argenau.bebt.de>
Message-ID: <87a664jg1w.fsf@latte.josefsson.org>

Andreas Metzler <ametzler at bebt.de> writes:

> On 2022-10-07 Simon Josefsson <simon at josefsson.org> wrote:
> [...]
>> One question is about version numbers.. it should probably have its own
>> version number, right?  Would starting at 0.0.0 be a problem for
>> packaging, or should we start with 3.7.8 (upstream gnutls version) and
>> then count upwards (separate from GnuTLS versions) from there?  I
>> prefer starting with 0.0.0 and using semantic versioning from the
>> start.
>
> We my Debian hat on: Pretty pretty please use a version number > 3.7.8
> to allow a simple upgrade from guile-gnutls 3.7.8 to the new separate
> version. (Instead of requiring fiddling and ugliness with empty
> transition packages or epoch.)

Okay that works, and I think we should make a guile-gnutls 3.7.8 release
with as little non-build changes as possible.  From then on, the
versioning is independent of GnuTLS -- and I think it would be nice to
do a quick 4.0.0 to establish a new base to stand on for guile-gnutls.

> Restarting version also imho does not make sense: Afaiui the next
> guile-gnutls will not be something totaly new but essentially 3.7.8
> with a changed README. The version number should reflect that. Or do you
> envision a rename, too?

There has never been a source package 'guile-gnutls' before, so what
version we use should not matter.  If it makes Debian packaging upgrades
easier for the _binary_ guile-gnutls package if we start on 3.7.8, that
seems like a weak but sufficient argument for doing it (unless there is
any arguments against using 3.7.8, which I don't see currently).

/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/20221010/573d5993/attachment.sig>

From simon at josefsson.org  Mon Oct 10 09:33:58 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Oct 2022 09:33:58 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87h70fal2b.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
 =?iso-8859-1?Q?=22's?= message of "Fri, 07
 Oct 2022 14:13:16 +0200")
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>
Message-ID: <875ygsjfo9.fsf@latte.josefsson.org>

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

>> git clone https://gitlab.com/gnutls/gnutls.git guile-gnutls
>> cd guile-gnutls/
>> git-filter-repo --path configure.ac --path .gitignore --path
>> doc/.gitignore --path README.md --path doc/ --path guile/ --path
>> Makefile.am  --path m4/guile.m4 --path NEWS
>> git remote add guile-gnutls git at gitlab.com:jas/guile-gnutls.git
>> git push -u guile-gnutls --all
>> git push -u guile-gnutls --tags
>
> I wonder if we should omit NEWS as it blurs the history a bit, in which
> case we?d later add a new NEWS file.

My thinking is that we should include NEWS and then trim down it to
become a guile-only NEWS file, and having the history of the old big
NEWS file in guile-gnutls's git repository preserves the older history
in case our trimming trims too much.  Does this make sense?

>> Is this a suitable base to start on?  Maybe we can iterate a couple of
>> times to get a suitable setup, I think we should prune some more in
>> doc/ which according to git-filter-repo man pages should be done by
>> another run of it to prune the repository further.  Getting a top-level
>> configure.ac and Makefile.am is a main work item here.
>
> Yes, in doc/ we only need gnutls-guile.texi, gnutls.texi (of which
> gnutls-guile.texi was extracted) and Makefile.am I think.

Right, I'll do another iteration cleaning out doc/ too.

>> Compared to the above setup, we may want to rename guile/ into
>> gnutls/.
>
> Or move guile/ to the top level, but maybe that can be done in a later
> commit.

I prefer having the top-level directory to be mostly maintainer stuff
like text files and build tools, so the source code is more clearly
separated.

>> One question is about version numbers.. it should probably have its own
>> version number, right?  Would starting at 0.0.0 be a problem for
>> packaging, or should we start with 3.7.8 (upstream gnutls version) and
>> then count upwards (separate from GnuTLS versions) from there?  I
>> prefer starting with 0.0.0 and using semantic versioning from the
>> start.
>
> That?s a good question.  I would tend to start at 1.0.0 (because it?s
> stable).  However some distros, such as Debian, have a binary package
> called ?guile-gnutls? that?s currently at 3.7.x, so the version number
> may cause them trouble.  I don?t know whether we should take that into
> consideration or leave it up to distros.

They can always do an epoch if necessary.  I think doing a standalone
guile-gnutls 3.7.8 as quickly as possible and then a 4.0.0 to mark that
versioning is now independent makes sense.  We wouldn't want to couple
guile-gnutls versioning with GnuTLS versioning too tightly.  On the
other hand, maybe we could match guile-gnutls MAJOR.MINOR to the latest
upstream GnuTLS MAJOR.MINOR so the API-versioning becomes clear?

/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/20221010/6c02eb0b/attachment-0001.sig>

From ludo at gnu.org  Mon Oct 10 11:42:19 2022
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Mon, 10 Oct 2022 11:42:19 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <875ygsjfo9.fsf@latte.josefsson.org> (Simon Josefsson's message
 of "Mon, 10 Oct 2022 09:33:58 +0200")
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>
Message-ID: <87k0582ex0.fsf@gnu.org>

Hi!

Simon Josefsson <simon at josefsson.org> skribis:

> Ludovic Court?s <ludo at gnu.org> writes:
>
>>> git clone https://gitlab.com/gnutls/gnutls.git guile-gnutls
>>> cd guile-gnutls/
>>> git-filter-repo --path configure.ac --path .gitignore --path
>>> doc/.gitignore --path README.md --path doc/ --path guile/ --path
>>> Makefile.am  --path m4/guile.m4 --path NEWS
>>> git remote add guile-gnutls git at gitlab.com:jas/guile-gnutls.git
>>> git push -u guile-gnutls --all
>>> git push -u guile-gnutls --tags
>>
>> I wonder if we should omit NEWS as it blurs the history a bit, in which
>> case we?d later add a new NEWS file.
>
> My thinking is that we should include NEWS and then trim down it to
> become a guile-only NEWS file, and having the history of the old big
> NEWS file in guile-gnutls's git repository preserves the older history
> in case our trimming trims too much.  Does this make sense?

Sure, why not.

>> Or move guile/ to the top level, but maybe that can be done in a later
>> commit.
>
> I prefer having the top-level directory to be mostly maintainer stuff
> like text files and build tools, so the source code is more clearly
> separated.

OK, that makes sense to me.

>> That?s a good question.  I would tend to start at 1.0.0 (because it?s
>> stable).  However some distros, such as Debian, have a binary package
>> called ?guile-gnutls? that?s currently at 3.7.x, so the version number
>> may cause them trouble.  I don?t know whether we should take that into
>> consideration or leave it up to distros.
>
> They can always do an epoch if necessary.  I think doing a standalone
> guile-gnutls 3.7.8 as quickly as possible and then a 4.0.0 to mark that
> versioning is now independent makes sense.

Yes, that would work too.

> We wouldn't want to couple guile-gnutls versioning with GnuTLS
> versioning too tightly.

Agreed.

> On the other hand, maybe we could match guile-gnutls MAJOR.MINOR to
> the latest upstream GnuTLS MAJOR.MINOR so the API-versioning becomes
> clear?

That contradicts what you wrote just above, no?  In general, I think the
Guile bindings will be able to target several MAJOR.MINOR versions of
GnuTLS, so keeping its version string independent sounds like the way to
go.  WDYT?

Thanks,
Ludo?.


From ametzler at bebt.de  Mon Oct 10 11:57:16 2022
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 10 Oct 2022 11:57:16 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87a664jg1w.fsf@latte.josefsson.org>
References: <87tu4kx83j.fsf@latte.josefsson.org> <87pmf7tps5.fsf@gnu.org>
 <87lepuxusj.fsf@latte.josefsson.org> <87wn9cc72l.fsf@gnu.org>
 <2fafa63d919fc8d7b21518e26a4e24939593f9a6.camel@josefsson.org>
 <Y0BhRXgtMQgmwEo3@argenau.bebt.de>
 <87a664jg1w.fsf@latte.josefsson.org>
Message-ID: <Y0PsfKJFvvRPwI5b@argenau.bebt.de>

On 2022-10-10 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at bebt.de> writes:
[...]
> > We my Debian hat on: Pretty pretty please use a version number > 3.7.8
> > to allow a simple upgrade from guile-gnutls 3.7.8 to the new separate
> > version. (Instead of requiring fiddling and ugliness with empty
> > transition packages or epoch.)
[...]
> > Restarting version also imho does not make sense: Afaiui the next
> > guile-gnutls will not be something totaly new but essentially 3.7.8
> > with a changed README. The version number should reflect that. Or do you
> > envision a rename, too?

Hello Simon,

let me elaborate a little bit, to make things clearer.

> There has never been a source package 'guile-gnutls' before, so what
> version we use should not matter.

Not for the source-version but ...

>  If it makes Debian packaging upgrades
> easier for the _binary_ guile-gnutls package if we start on 3.7.8, that
> seems like a weak but sufficient argument for doing it (unless there is
> any arguments against using 3.7.8, which I don't see currently).

... the binary packages which are actually installed on a user's system
and which the package manager (yum, apt, ...) deals with and considers
for upgrades usually inherit the version number from the source package.
And yum looks at the binary package version number and will not
"upgrade" from gnutls-guile 3.7.7-1.fc37 to gnutls-guile 0.0.1.

This is a not Debian-specific issue, every distribution that deals with
binary packages (Gentoo might do better, I do not know) would need to
take additional (ugly) work to force the transition if
guile-gnutls-separate used a version-number lower than the last binary
built from gnutls-combined.

Thanks for considering this.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From gunnar.stahl at gunnarstahl.org  Tue Oct 11 14:52:00 2022
From: gunnar.stahl at gunnarstahl.org (Gunnar Stahl)
Date: Tue, 11 Oct 2022 14:52:00 +0200
Subject: [gnutls-help] Problem with gnutls running inside parallels on an
 imac (illegal instruction)
Message-ID: <D4B16EF4-5EE8-40E3-AA11-904F4AB2F21E@gunnarstahl.org>

Hello list,

I have a problem with running debian inside parallels on an iMac 2019 (i5 8500, 64gb ram). Debian actually runs fine, but downloading lineageos via the repo command fails and it seems it is due to gnutls.

When I tried to download lineageos via the repo command
>> repo init -u https://github.com/LineageOS/android.git <https://github.com/LineageOS/android.git> -b lineage-19.1
the command failed with an 'git was killed with signal 4' error.

I narrowed it down to git trying to clone from an http**s** source, which I think utilizes openssl. The command 
>> git clone 'https://gerrit.googlesource.com/git-repo <https://gerrit.googlesource.com/git-repo>' 
dies with the error message 'git-remote-https died of signal 4?. 

When I try to do the same with 
>> wget https://gerrit.googlesource.com/git-repo <https://gerrit.googlesource.com/git-repo>
I receive the error 'Illegal instruction'.

Initially I thought this was a problem with openssl and asked the openssl dev mailing list. 
They pointed me to producing a coredump. So I did:

# ulimit -c unlimeted
# sudo sysctl -w kernel.core_uses_pid=1

and reproduced the error with

# wget https://gerrit.googlesource.com/git-repo

which produced a core dump file which I opened via

# gdb wget core.252637

and that stated:

###
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `wget https://gerrit.googlesource.com/git-repo'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x00007f3a9594fb0a in ?? () from /lib/x86_64-linux-gnu/libgnutls.so.30
###

So it seems that it isn?t openssl causing the problem but gnutls. I therefore tried to apt source ?compile libgnutls and that fails in the test phase with lots of lines like:

###
make[6]: Entering directory '/home/gunnarstahl/build-libgnutls/gnutls28-3.7.7/b4deb/tests'
../../build-aux/test-driver: line 112: 361413 Illegal instruction     "$@" >> "$log_file" 2>&1
FAIL: tls13/supported_versions
../../build-aux/test-driver: line 112: 361411 Illegal instruction     "$@" >> "$log_file" 2>&1
../../build-aux/test-driver: line 112: 361412 Illegal instruction     "$@" >> "$log_file" 2>&1
FAIL: tls13/tls12-no-tls13-exts
FAIL: tls13/post-handshake-with-cert
FAIL: sanity-cpp
../../build-aux/test-driver: line 112: 361441 Illegal instruction     "$@" >> "$log_file" 2>&1
###

Anything I can do here apart from switching to native hardware? Some compiler switches or anything? Any help is appreciated. I?ll happily provide the necessary log files.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221011/1a02c883/attachment.html>

From ondrej at sury.org  Tue Oct 11 15:31:23 2022
From: ondrej at sury.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=)
Date: Tue, 11 Oct 2022 15:31:23 +0200
Subject: [gnutls-help] Problem with gnutls running inside parallels on
 an imac (illegal instruction)
In-Reply-To: <D4B16EF4-5EE8-40E3-AA11-904F4AB2F21E@gunnarstahl.org>
References: <D4B16EF4-5EE8-40E3-AA11-904F4AB2F21E@gunnarstahl.org>
Message-ID: <B3635106-6DA2-4479-A808-E587CB5446B8@sury.org>

Hi,

this usually happens when the guest binaries are compiled with cpu instruction set that?s not supported by host (I?ve seen this too many times when Raspbian decided it?s a ?good idea? to make armhf different from Debian?s armhf and people would mix the two). Recompiling the package is not going to help because that would use the same compiler flags. You can try looking into debian/rules and tweak any extra setting, or compile the gnutls from source (without any Debian modifications or custom ./configure options).

Cheers, 
--
Ond?ej Sur? <ondrej at sury.org> (He/Him)

> On 11. 10. 2022, at 15:12, Gunnar Stahl <gunnar.stahl at gunnarstahl.org> wrote:
> 
> ?Hello list,
> 
> I have a problem with running debian inside parallels on an iMac 2019 (i5 8500, 64gb ram). Debian actually runs fine, but downloading lineageos via the repo command fails and it seems it is due to gnutls.
> 
> When I tried to download lineageos via the repo command
>>> repo init -u https://github.com/LineageOS/android.git -b lineage-19.1
> the command failed with an 'git was killed with signal 4' error.
> 
> I narrowed it down to git trying to clone from an http**s** source, which I think utilizes openssl. The command 
>>> git clone 'https://gerrit.googlesource.com/git-repo' 
> dies with the error message 'git-remote-https died of signal 4?. 
> 
> When I try to do the same with 
>>> wget https://gerrit.googlesource.com/git-repo
> 
> I receive the error 'Illegal instruction'.
> 
> Initially I thought this was a problem with openssl and asked the openssl dev mailing list. 
> They pointed me to producing a coredump. So I did:
> 
> # ulimit -c unlimeted
> # sudo sysctl -w kernel.core_uses_pid=1
> 
> and reproduced the error with
> 
> # wget https://gerrit.googlesource.com/git-repo
> 
> which produced a core dump file which I opened via
> 
> # gdb wget core.252637
> 
> and that stated:
> 
> ###
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `wget https://gerrit.googlesource.com/git-repo'.
> Program terminated with signal SIGILL, Illegal instruction.
> #0  0x00007f3a9594fb0a in ?? () from /lib/x86_64-linux-gnu/libgnutls.so.30
> ###
> 
> So it seems that it isn?t openssl causing the problem but gnutls. I therefore tried to apt source ?compile libgnutls and that fails in the test phase with lots of lines like:
> 
> ###
> make[6]: Entering directory '/home/gunnarstahl/build-libgnutls/gnutls28-3.7.7/b4deb/tests'
> ../../build-aux/test-driver: line 112: 361413 Illegal instruction     "$@" >> "$log_file" 2>&1
> FAIL: tls13/supported_versions
> ../../build-aux/test-driver: line 112: 361411 Illegal instruction     "$@" >> "$log_file" 2>&1
> ../../build-aux/test-driver: line 112: 361412 Illegal instruction     "$@" >> "$log_file" 2>&1
> FAIL: tls13/tls12-no-tls13-exts
> FAIL: tls13/post-handshake-with-cert
> FAIL: sanity-cpp
> ../../build-aux/test-driver: line 112: 361441 Illegal instruction     "$@" >> "$log_file" 2>&1
> ###
> 
> Anything I can do here apart from switching to native hardware? Some compiler switches or anything? Any help is appreciated. I?ll happily provide the necessary log files.
> 
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221011/15e610f1/attachment-0001.html>

From simon at josefsson.org  Tue Oct 11 17:03:54 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Oct 2022 17:03:54 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87k0582ex0.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
 =?iso-8859-1?Q?=22's?= message of "Mon, 10
 Oct 2022 11:42:19 +0200")
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>
Message-ID: <87v8oqieqt.fsf@latte.josefsson.org>

Hi

I have created https://gitlab.com/jas/guile-gnutls/ now that appears to
build: https://gitlab.com/jas/guile-gnutls/-/pipelines/663945143

Could you please test the following tarball as if it were a new release
of the new guile-gnutls project?

https://gitlab.com/jas/guile-gnutls/-/jobs/3156988378/artifacts/raw/guile-gnutls-3.7.8.tar.gz

Alternatively, build directly from git if you prefer that.  See README
and .gitlab-ci.yml for some build hints.

Feedback?

I'll move it to https://gitlab.com/gnutls/guile/ and release as 3.7.9
within a few days, but I'm happy to include any fixes you would like to
see go into it.  We can always fix more things after the release too.  I
am aware of the following nits:

* Possibly incomplete README
* SRP -- should it auto-detect if system-GnuTLS has SRP enabled
  instead of using --disable-srp-authentication?
* SRP -- building without SRP doesn't seem to work, bug?
* configure.ac logic -- use AC_MSG_ERROR instead of AC_MSG_WARN
  when guile or gnutls is missing, there is no point in continuing
  if hard requirements are not met.

/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/20221011/75d3f4ed/attachment.sig>

From simon at josefsson.org  Wed Oct 12 09:58:47 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Oct 2022 09:58:47 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87v8oqieqt.fsf@latte.josefsson.org> (Simon Josefsson's message
 of "Tue, 11 Oct 2022 17:03:54 +0200")
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>
Message-ID: <87r0zdiibs.fsf@latte.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> I'll move it to https://gitlab.com/gnutls/guile/ and release as 3.7.9
> within a few days, but I'm happy to include any fixes you would like to
> see go into it.  We can always fix more things after the release too.  I
> am aware of the following nits:
>
> * Possibly incomplete README
> * SRP -- should it auto-detect if system-GnuTLS has SRP enabled
>   instead of using --disable-srp-authentication?
> * SRP -- building without SRP doesn't seem to work, bug?
> * configure.ac logic -- use AC_MSG_ERROR instead of AC_MSG_WARN
>   when guile or gnutls is missing, there is no point in continuing
>   if hard requirements are not met.

Further nits below, but none that will prevent a release, so I'm merely
writing these down to invite others to give feedback on my plans.

* Use gnulib to avoid manual copies of some files (m4/lib-*) and to get
  maintainer makefiles for, e.g., bootstrapping, release process and
  auto-generated web manual.

* Build failures on almalinux - I can't figure out how to install guile
  on it, see: https://gitlab.com/jas/guile-gnutls/-/jobs/3156988384

* CentOS7 build failure, looks like a real source-code problem?
  https://gitlab.com/jas/guile-gnutls/-/jobs/3156988383
  We have successful builds on Fedora so I'm not that concerned about
  this.

* Plenty of deprecated warnings in the logs... I haven't looked at if
  this is intentional or not.

* We should run 'indent' on the code.

/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/20221012/72b97b33/attachment.sig>

From ametzler at bebt.de  Wed Oct 12 18:33:50 2022
From: ametzler at bebt.de (Andreas Metzler)
Date: Wed, 12 Oct 2022 18:33:50 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87v8oqieqt.fsf@latte.josefsson.org>
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>
Message-ID: <Y0bsbnQLEKx62Cwt@argenau.bebt.de>

On 2022-10-11 Simon Josefsson <simon at josefsson.org> wrote:
> Hi

> I have created https://gitlab.com/jas/guile-gnutls/ now that appears to
> build: https://gitlab.com/jas/guile-gnutls/-/pipelines/663945143

> Could you please test the following tarball as if it were a new release
> of the new guile-gnutls project?

> https://gitlab.com/jas/guile-gnutls/-/jobs/3156988378/artifacts/raw/guile-gnutls-3.7.8.tar.gz

> Alternatively, build directly from git if you prefer that.  See README
[...]

I just quickly ported the Debian packaging (excluding any copyrigght
checks) and it looked reasonable.

Nitpicks:
Supporting ./configure  --disable-guile         don't build GNU Guile bindings
does not make a lot of sense.

I am not sure about the post configure status update:
[...]
         sitedir:    $(GUILE_SITE)
   siteccachedir:    $(GUILE_SITE_CCACHE)
    extensiondir:    $(GUILE_EXTENSION)

Whereas config.log has:
configure:13619: checking for Guile site directory
configure:13622: result: /usr/share/guile/site/3.0
configure:13631: checking for Guile site-ccache directory using pkgconfig
configure:13648: result: /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache
configure:13651: checking for Guile extensions directory
configure:13654: result: /usr/lib/x86_64-linux-gnu/guile/3.0/extensions

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: deb.tar.xz
Type: application/x-xz
Size: 1548 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221012/d156ad06/attachment.xz>

From simon at josefsson.org  Fri Oct 14 12:55:36 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Oct 2022 12:55:36 +0200
Subject: [gnutls-help] Guile-GnuTLS 3.7.9
Message-ID: <87czauwu6v.fsf@latte.josefsson.org>

Guile-GnuTLS provides Guile bindings for the GnuTLS library, see
https://gitlab.com/gnutls/guile for more information.

The release is available here:

https://gitlab.com/gnutls/guile/-/releases/v3.7.9

The following OpenPGP-signed tarballs are available:

https://gitlab.com/gnutls/guile/uploads/b4d5cb4e4394ef8eaa56bfb0edad3c08/guile-gnutls-3.7.9.tar.gz
https://gitlab.com/gnutls/guile/uploads/9ee831010aea06adb1dd6ec78973b5d9/guile-gnutls-3.7.9.tar.gz.sig

SHA1 and SHA256 checksums:

1dcda80acb5ced69e87446c4c27a35ae3c4bed1f  guile-gnutls-3.7.9.tar.gz
ef2321d5a6505942f5aedc98ea295b61c92aa09e0e1cb2ebefaab5ce93677026  guile-gnutls-3.7.9.tar.gz

NEWS entries:

* Noteworthy changes in release 3.7.9 (2022-10-14) [stable]

** Extracted into a separate project, based on GnuTLS 3.7.8.
For earlier NEWS entries, see upstream NEWS file:
https://gitlab.com/gnutls/gnutls/-/blob/master/NEWS

To reproduce the initial guile-gnutls git repository on which
subsequent commits have been added to, you may use:

```
git clone https://gitlab.com/gnutls/gnutls.git guile-gnutls
cd guile-gnutls/
git checkout f5dcbdb46df52458e3756193c2a23bf558a3ecfd
git-filter-repo --path guile/ --path m4/guile.m4 --path doc/gnutls-guile.texi --path doc/extract-guile-c-doc.scm --path doc/cha-copying.texi --path doc/fdl-1.3.texi
```

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/20221014/1cf0e5b0/attachment.sig>

From simon at josefsson.org  Fri Oct 14 13:04:41 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Oct 2022 13:04:41 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <Y0bsbnQLEKx62Cwt@argenau.bebt.de> (Andreas Metzler's message of
 "Wed, 12 Oct 2022 18:33:50 +0200")
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>
Message-ID: <878rliwtrq.fsf@latte.josefsson.org>

Andreas Metzler <ametzler at bebt.de> writes:

> I just quickly ported the Debian packaging (excluding any copyrigght
> checks) and it looked reasonable.

Thank you for testing!

> Nitpicks:
> Supporting ./configure  --disable-guile         don't build GNU Guile bindings
> does not make a lot of sense.
>
> I am not sure about the post configure status update:
> [...]
>          sitedir:    $(GUILE_SITE)
>    siteccachedir:    $(GUILE_SITE_CCACHE)
>     extensiondir:    $(GUILE_EXTENSION)

Should be improved further now, I'm not that familiar with these
variables anyway.  I have published a 3.7.9 release and moved all issues
into https://gitlab.com/gnutls/guile/-/issues now, let's continue from
gitlab issues for specific items -- general discussion or feedback here
is appreciated too.

/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/20221014/73dc7e94/attachment-0001.sig>

From ametzler at bebt.de  Fri Oct 14 18:53:54 2022
From: ametzler at bebt.de (Andreas Metzler)
Date: Fri, 14 Oct 2022 18:53:54 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <878rliwtrq.fsf@latte.josefsson.org>
References: <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>
Message-ID: <Y0mUImsdGdZeeyuc@argenau.bebt.de>

On 2022-10-14 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at bebt.de> writes:

> > I just quickly ported the Debian packaging (excluding any copyrigght
> > checks) and it looked reasonable.

[...]
> Should be improved further now, I'm not that familiar with these
> variables anyway.  I have published a 3.7.9 release and moved all issues
> into https://gitlab.com/gnutls/guile/-/issues now, let's continue from
> gitlab issues for specific items -- general discussion or feedback here
> is appreciated too.

Thanks!

I have just done an initial upload to Debian (experimental). It might
take some time, since introducing a new (source) package requires
approval and checking by Debian ftp-masters.

https://salsa.debian.org/gnutls-team/guile-gnutls/
cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20221014/3e5c7436/attachment.sig>

From ludo at gnu.org  Mon Oct 17 18:24:24 2022
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Mon, 17 Oct 2022 18:24:24 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <878rliwtrq.fsf@latte.josefsson.org> (Simon Josefsson's message
 of "Fri, 14 Oct 2022 13:04:41 +0200")
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>
Message-ID: <87a65uquyv.fsf@gnu.org>

Hi,

Simon Josefsson <simon at josefsson.org> skribis:

> Should be improved further now, I'm not that familiar with these
> variables anyway.  I have published a 3.7.9 release and moved all issues
> into https://gitlab.com/gnutls/guile/-/issues now, let's continue from
> gitlab issues for specific items -- general discussion or feedback here
> is appreciated too.

Yay, thanks!  Thank you Andreas for the Debian update as well.

I?ve prepared the Guix package (will push soon) and it went smoothly.

Two things we could/should do:

  1. LT_INIT([disable-static]) because it doesn?t make sense to build .a
     files?pushed as 006d53214a7fd2bf2ef04acecde89f6ae4fdfb3d;

  2. Change the default .scm and .go installation directory to be under
     $prefix, as is done in guile-gcrypt and many other packages.

Thoughts?

Ludo?.


From simon at josefsson.org  Tue Oct 18 09:27:19 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 18 Oct 2022 09:27:19 +0200
Subject: [gnutls-help] Guile-Gnutls bindings to separate git repo?
In-Reply-To: <87a65uquyv.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
 =?iso-8859-1?Q?=22's?= message of "Mon, 17
 Oct 2022 18:24:24 +0200")
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>
Message-ID: <871qr5bnhk.fsf@latte.josefsson.org>

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

> I?ve prepared the Guix package (will push soon) and it went smoothly.
>
> Two things we could/should do:
>
>   1. LT_INIT([disable-static]) because it doesn?t make sense to build .a
>      files?pushed as 006d53214a7fd2bf2ef04acecde89f6ae4fdfb3d;

Thanks, I didn't realize this was intentional.

>   2. Change the default .scm and .go installation directory to be under
>      $prefix, as is done in guile-gcrypt and many other packages.

Consistency with other packages is good, I don't see a reason why not if
NEWS explains what happened.  Do you have a patch in mind?

Would you like to make a new release?  I think it should be merely 1)
verify that CI/CD is happy, 2) make sure NEWS is updated with release
version and date, 3) do 'git tag -s v3.7.10', 4) do a local' make dist'
and 'gpg -b guile-gnutls*.tar.gz', 5) create a new release at
https://gitlab.com/gnutls/guile/-/releases using the previous one as a
template (i.e., fill in title and attach locally built *.tar.gz*), 6)
send an announcement to this list.  It's seems like a good idea to get
more than one person's PGP key into the "official" list of release
manager keys early on in the life of a project.

/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/20221018/389a212c/attachment.sig>