Guile-GnuTLS/Git circular dependency

  • Done
  • quality assurance status badge
Details
5 participants
  • Ludovic Courtès
  • Christopher Baines
  • Simon Josefsson
  • Vivien Kraus
  • Simon Tournier
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important
L
L
Ludovic Courtès wrote on 6 May 2023 19:20
(address . bug-guix@gnu.org)
877ctljs0m.fsf@inria.fr
Hi,

‘git-download’ needs to depend on guile-gnutls to implement its fallback
mechanism (downloading from mirrors or from SWH over HTTPS). Commit
c625e5b64d0a6cb7ffbf2ef971d4c990b1f5c5c1 restored this. However, it
also introduced a circular dependency: the origin of guile-gnutls relies
on 'git-download', which would now depend on guile-gnutls. Thus, I
reverted it right away.

We need to solve that. For now, the only fix I can think of is having
‘guile-gnutls’ built from a “make dist”-provided tarballs. Apparently
we can add assets at https://gitlab.com/gnutls/guile/-/tags; would you
like to upload a tarball and accompanying signature, Simon?

Unfortunately, that means doing away with all the packaging work by
Vivien, in particular proper bootstrapping with Gnulib.

The longer-term solution is to add a “builtin:git-download” derivation
builder, just like we have “builtin:download”. The implementation
should be relatively easy, but we’ll have to be able to deal with
daemons that lack this builtin possibly for several years.

Thoughts?

Ludo’.
L
L
Ludovic Courtès wrote on 6 May 2023 19:21
control message for bug #63331
(address . control@debbugs.gnu.org)
875y95jrza.fsf@gnu.org
severity 63331 important
quit
V
V
Vivien Kraus wrote on 6 May 2023 22:07
Re: bug#63331: Guile-GnuTLS/Git circular dependency
(name . Simon Josefsson)(address . simon@josefsson.org)
f2fa465da9153c5224746686d79667a6495ed134.camel@planete-kraus.eu
Hi!

Le samedi 06 mai 2023 à 19:20 +0200, Ludovic Courtès a écrit :
Toggle quote (8 lines)
> We need to solve that.  For now, the only fix I can think of is
> having
> ‘guile-gnutls’ built from a “make dist”-provided tarballs. 
> Apparently
> we can add assets at <https://gitlab.com/gnutls/guile/-/tags>; would
> you
> like to upload a tarball and accompanying signature, Simon?

If the problem is with git-download, couldn’t we just use a "git-
archive"-provided tarball, and keep the bootstrapping process? Or are
there further dependencies with the autotools that require a dist-
provided tarball?

Vivien
L
L
Ludovic Courtès wrote on 6 May 2023 22:17
(name . Vivien Kraus)(address . vivien@planete-kraus.eu)
87bkixi58v.fsf@gnu.org
Hi,

Vivien Kraus <vivien@planete-kraus.eu> skribis:

Toggle quote (14 lines)
> Le samedi 06 mai 2023 à 19:20 +0200, Ludovic Courtès a écrit :
>> We need to solve that.  For now, the only fix I can think of is
>> having
>> ‘guile-gnutls’ built from a “make dist”-provided tarballs. 
>> Apparently
>> we can add assets at <https://gitlab.com/gnutls/guile/-/tags>; would
>> you
>> like to upload a tarball and accompanying signature, Simon?
>
> If the problem is with git-download, couldn’t we just use a "git-
> archive"-provided tarball, and keep the bootstrapping process? Or are
> there further dependencies with the autotools that require a dist-
> provided tarball?

The ‘gnulib’ package also uses ‘git-fetch’, so we’d at least need to get
rid of it.

More importantly, tarballs generated by GitLab & co. are usually built
on the fly and change over time (details about the tarball headers
etc. may change). So we cannot depend them.

A tarball produced with ‘make dist’ will have everything we need,
including Gnulib.

Ludo’.
S
S
Simon Josefsson wrote on 7 May 2023 10:54
(name . Ludovic Courtès)(address . ludo@gnu.org)
87r0rsh67w.fsf@josefsson.org
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (5 lines)
> We need to solve that. For now, the only fix I can think of is having
> ‘guile-gnutls’ built from a “make dist”-provided tarballs. Apparently
> we can add assets at <https://gitlab.com/gnutls/guile/-/tags>; would you
> like to upload a tarball and accompanying signature, Simon?

The tarballs I created are available here:

Is a new releases necessary, or does the 3.7.11 release work? I can do
a release tonight or tomorrow, but I'm also happy to help someone else
to do the release -- see README-release for the process, skip 'make
upload' if you don't have ftp.gnu.org gnutls credentials.

I'm not sure I exactly what the real problem is here -- but would one
solution be to publish a source-only tarball with the source code files
from git, together with a signature? That would include any gnulib
files, but not autogenerated ./configure etc.

/Simon
-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZFdnQxQcc2ltb25Aam9z
ZWZzc29uLm9yZwAKCRBRcisI/kdFojsJAP0QMWYuJ1zy35vf12PtAOwpN7Ndsstk
tu1aqhQCvsPOtQEA5ILGhwmPkUN+g3qBBRvCHp0HZ5PhWP3jfnU7O9wYWAE=
=vKvq
-----END PGP SIGNATURE-----

S
S
Simon Josefsson wrote on 8 May 2023 15:57
(name . Ludovic Courtès)(address . ludo@gnu.org)
8735472aep.fsf@josefsson.org
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (5 lines)
> We need to solve that. For now, the only fix I can think of is having
> ‘guile-gnutls’ built from a “make dist”-provided tarballs. Apparently
> we can add assets at <https://gitlab.com/gnutls/guile/-/tags>; would you
> like to upload a tarball and accompanying signature, Simon?

I published a release of gnutls-guile 3.7.12, this time built on my Guix
development machine to test that the release machinery (README-release)
works under Guix as well; the only "interesting" dependency was ncftp
but you had that packaged and it worked fine.


/Simon
-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZFj/zhQcc2ltb25Aam9z
ZWZzc29uLm9yZwAKCRBRcisI/kdFonBJAQCh3iS3VMzBO6iPBnkfNUVLd2jK9Utq
QkDerjEjsxf6mAEA5spNVMNa95X3xj4oTDbRrIEV+3VZ8Uia+jDWStEhdw8=
=hvDa
-----END PGP SIGNATURE-----

C
C
Christopher Baines wrote on 9 May 2023 13:15
(name . Simon Josefsson)(address . simon@josefsson.org)
874jol4uje.fsf@cbaines.net
Simon Josefsson via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (15 lines)
> [[PGP Signed Part:Undecided]]
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> We need to solve that. For now, the only fix I can think of is having
>> ‘guile-gnutls’ built from a “make dist”-provided tarballs. Apparently
>> we can add assets at <https://gitlab.com/gnutls/guile/-/tags>; would you
>> like to upload a tarball and accompanying signature, Simon?
>
> I published a release of gnutls-guile 3.7.12, this time built on my Guix
> development machine to test that the release machinery (README-release)
> works under Guix as well; the only "interesting" dependency was ncftp
> but you had that packaged and it worked fine.
>
> https://gitlab.com/gnutls/guile/-/releases/v3.7.12

Thanks so much for this Simon.

I've had a go at updating the Guix guile-gnutls package and sent an

It seems to build for me, but I'm having problems cross building. There
were warnings before about protocol/ssl3 being undefined, but now this
seems to result in an error when building extra.scm:


GUILEC modules/gnutls.go
gnutls.scm:608:23: warning: possibly unbound variable `protocol/ssl3'
gnutls.scm:609:25: warning: possibly unbound variable `protocol/tls1-0'
gnutls.scm:610:25: warning: possibly unbound variable `protocol/tls1-1'
GUILEC modules/gnutls/extra.go
Backtrace:
In ice-9/psyntax.scm:
1229:36 19 (expand-top-sequence (#<syntax:extra.scm:21:0 (#<synt?>) ?)
1221:19 18 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
259:10 17 (parse _ (("placeholder" placeholder)) (()) _ c&e (# #) #)
In ice-9/eval.scm:
293:34 16 (_ #<module (#{ g106}#) 7ffff786d500>)
In ice-9/boot-9.scm:
3411:4 15 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
2595:24 14 (call-with-deferred-observers #<procedure 7ffff778ac30 ?>)
3424:24 13 (_)
222:17 12 (map1 (((gnutls))))
3327:17 11 (resolve-interface (gnutls) #:select _ #:hide _ #:prefix ?)
In ice-9/threads.scm:
390:8 10 (_ _)
In ice-9/boot-9.scm:
3253:13 9 (_)
In ice-9/threads.scm:
390:8 8 (_ _)
In ice-9/boot-9.scm:
3544:20 7 (_)
2836:4 6 (save-module-excursion #<procedure 7ffff78660f0 at ice-?>)
3564:26 5 (_)
In unknown file:
4 (primitive-load-path "gnutls" #<procedure 7ffff27384a0 ?>)
In ice-9/eval.scm:
626:19 3 (_ #<directory (gnutls) 7ffff786d320>)
223:20 2 (proc #<directory (gnutls) 7ffff786d320>)
In unknown file:
1 (%resolve-variable (7 . protocol/ssl3) #<directory (gnu?>)
In ice-9/boot-9.scm:
1685:16 0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: protocol/ssl3
make[3]: *** [Makefile:1295: modules/gnutls/extra.go] Error 1
make[3]: Leaving directory '/tmp/guix-build-guile-gnutls-3.7.12.drv-0/guile-gnutls-3.7.12/guile'
make[2]: *** [Makefile:754: all-recursive] Error 1
make[2]: Leaving directory '/tmp/guix-build-guile-gnutls-3.7.12.drv-0/guile-gnutls-3.7.12/guile'
make[1]: *** [Makefile:471: all-recursive] Error 1
make[1]: Leaving directory '/tmp/guix-build-guile-gnutls-3.7.12.drv-0/guile-gnutls-3.7.12'
make: *** [Makefile:403: all] Error 2
error: in phase 'build': uncaught exception:
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmRaLWVfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XfEzg/+ORmFWWt/k2Y7x+1XK5TpLHvk2fy7YVwS
4gAmP0T1iOPeDss2Vr3X0/iszho8zQ3c5t2lxIZUBf6mP9bGs2z0X1tK/nKiFALd
jpEDFqZs/6ypuXEBxndZshzkzrzLkbD5N1IFZxsKYvXw0OAFD5ATu4Z1LfReeoHg
VHQd1psq9U5VjObN5r0Es4cxRE2m5/pbVORxONLE6qAIhIjnDiNu6QLaDl3k1mpa
NE0D/VGioRNX7FEELMwkQHHTkxsjLoHKdFL3jwEAM5+Tzg8sXZZoJu5njpiwlDuz
aetqsTJtdI0azApku2VjQX/ye3enfs7wwh8U3Ik2svCA1QoYxXhkh8NKfsDhN/fB
lxVvs10PByEiroTzGCIdJxh6VOm+2xSqrU0u9MRU52SbtHpXQfIC/cyII+t7wE1j
afzhAEJuSQsDuDj9FTId20UnqRUqnaccs972tFgUoRm2mLH15GoicvJiCFUQDqzH
7t/bWYEokRIdrQRA/vEy/Cl+SklwVGFnOY9xoTHmdyCQMDeJ4dlytJtuSRlZgHsW
jKGAtV9ZCuVzqAH4dP1imFNqZ6kePcAdPU7bN+mtUyjperWqsAtxpb7G9lHw475Z
6OjSXpG5uRarklSQA9arsnSbrLjACNNhcDg+GRoSO0G0/Xzkt+EtIs+mejT+K7ao
4aMrWKkeYAI=
=Hw2d
-----END PGP SIGNATURE-----

S
S
Simon Josefsson wrote on 9 May 2023 14:23
(name . Christopher Baines)(address . mail@cbaines.net)
38565615c520136e5ea70a07c13ed0c4bedb68f1.camel@josefsson.org
Toggle quote (3 lines)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Unbound variable: protocol/ssl3

Maybe ssl3 is disabled (as it probably should be) in guix's gnutls?

While I built the package on a Guix system using system GnuTLS, I
didn't build it through Guix's packaging, so maybe there is some
difference?

A GitLab CI/CD build check on Guix would be nice, does anyone publish
docker images for a Guix system?

/Simon
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZFo7KAAKCRBRcisI/kdF
onA1AQCpqR+wdDrcyfQAMB4ICSBparhdtPco0wnZ6p3T2ir7MgEA0xkOu6yYxfkL
xvbiJoiB9AifkzsNsRYsM1f42cGM7g4=
=1dnN
-----END PGP SIGNATURE-----


V
V
Vivien Kraus wrote on 9 May 2023 17:19
f9cc480ab8537a285c8738ee46fe4a12e5e17520.camel@planete-kraus.eu
Le mardi 09 mai 2023 à 14:23 +0200, Simon Josefsson a écrit :
Toggle quote (3 lines)
> A GitLab CI/CD build check on Guix would be nice, does anyone publish
> docker images for a Guix system?

The guix builder uses linux tools to provide an isolated build
environment. It is possible to run the guix build daemon without this
protection, so as to run it within a docker container, but build
scripts may behave incorrectly if they run outside of the sandbox. They
could see libraries that they should not be able to see and by that
configure incorrectly, or install things where they should not. Guix
packagers do not usually care if a build script writes files outside of
its correct store directory, because of the isolation provided by the
daemon. Such problems are thus hard to detect, and broken packages
could be anywhere. This is mostly a hypothetical issue, but opam (for
ocaml) warns about build scripts doing unpredictable things:


Aside from that, guix is painfully slow in a container, and uses a lot
of disk space.

Vivien
L
L
Ludovic Courtès wrote on 10 May 2023 17:37
(name . Christopher Baines)(address . mail@cbaines.net)
87pm788afh.fsf@gnu.org
Hi,

Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (11 lines)
> It seems to build for me, but I'm having problems cross building. There
> were warnings before about protocol/ssl3 being undefined, but now this
> seems to result in an error when building extra.scm:
>
>
> GUILEC modules/gnutls.go
> gnutls.scm:608:23: warning: possibly unbound variable `protocol/ssl3'
> gnutls.scm:609:25: warning: possibly unbound variable `protocol/tls1-0'
> gnutls.scm:610:25: warning: possibly unbound variable `protocol/tls1-1'
> GUILEC modules/gnutls/extra.go

[...]

Toggle quote (4 lines)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Unbound variable: protocol/ssl3
> make[3]: *** [Makefile:1295: modules/gnutls/extra.go] Error 1

Is it a regression or did we already have that problem?

That comes from this bit in (gnutls):

;; Renaming.
(define protocol/ssl-3 protocol/ssl3)
(define protocol/tls-1.0 protocol/tls1-0)
(define protocol/tls-1.1 protocol/tls1-1)

When cross-compiling, the .so cannot be loaded (understandably; see also
GNUTLS_GUILE_CROSS_COMPILING) so ‘protocol/ssl3’ above is undefined.
The problem is that when compiling (gnutls extra), we end up loading
(gnutls) and thus evaluating the lines above, which fail.

In Guile-Avahi I worked around it like so:

(define protocol/unspecified
(and (defined? 'protocol/unspec) protocol/unspec))

I guess we could do that as well here.

HTH,
Ludo’.
C
C
Christopher Baines wrote on 10 May 2023 17:59
(name . Ludovic Courtès)(address . ludo@gnu.org)
877ctg18ga.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (23 lines)
> Hi,
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> It seems to build for me, but I'm having problems cross building. There
>> were warnings before about protocol/ssl3 being undefined, but now this
>> seems to result in an error when building extra.scm:
>>
>>
>> GUILEC modules/gnutls.go
>> gnutls.scm:608:23: warning: possibly unbound variable `protocol/ssl3'
>> gnutls.scm:609:25: warning: possibly unbound variable `protocol/tls1-0'
>> gnutls.scm:610:25: warning: possibly unbound variable `protocol/tls1-1'
>> GUILEC modules/gnutls/extra.go
>
> [...]
>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> Unbound variable: protocol/ssl3
>> make[3]: *** [Makefile:1295: modules/gnutls/extra.go] Error 1
>
> Is it a regression or did we already have that problem?

A regression I think, the data service doesn't have recent data, but it
does know about builds that worked:


Toggle quote (19 lines)
> That comes from this bit in (gnutls):
>
> ;; Renaming.
> (define protocol/ssl-3 protocol/ssl3)
> (define protocol/tls-1.0 protocol/tls1-0)
> (define protocol/tls-1.1 protocol/tls1-1)
>
> When cross-compiling, the .so cannot be loaded (understandably; see also
> GNUTLS_GUILE_CROSS_COMPILING) so ‘protocol/ssl3’ above is undefined.
> The problem is that when compiling (gnutls extra), we end up loading
> (gnutls) and thus evaluating the lines above, which fail.
>
> In Guile-Avahi I worked around it like so:
>
> (define protocol/unspecified
> (and (defined? 'protocol/unspec) protocol/unspec))
>
> I guess we could do that as well

That sort of makes sense, although I don't know why this wasn't failing
in the same way in the past. Build logs are available though, so maybe
this makes sense to someone.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmRbv/VfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9Xf8Jw/8DUHTQZ6SHJ9zHbq2uPm5PzwgV7USHjTF
6m6+xboWd/2IKwLcGH+JClgigRELIX96JnbTZQljICMEhr26P9q4SCUBdMiXkNQV
//ZRQH7kzzKiQQ6Pjzazg/GRk3z8ioQCL9T0mq5DBIZF9oU2H+VIZ5hM4K1hREWo
36QxyQlwzGRKMXmjGJz6+QgaeTt4QwKY0eyphU8kzmm20JOMkodgIaR2IkFAzrRX
+Zfg0Lg/7Te8WunBKLqEH5p56t6Sd9+qsjiAb2DrF5OR2n8qYYmtX7VdDz/dDdcn
xscjwnlXAHpITHkw3u2S45f8F/Gd1AsqYoAbShX4ngFjVJv7vDSawDsPgq5ChGoc
aSPOyG5n8ZqehRlvLyekBzzqkZcDnQKtAJhjqxtUGOYP8nWSc/xTyGWQ3hQmPru4
0DHs17ep3x2X4dyZItYJOQTgZYUvcZ2XMAIo+NtlnynTKbDrX3VUzoxwTz1GWDby
ssz23hAdRsyB0NB12k4xn28AfrSi9VhvuJTJth5pL88V0rmdaTpgM14bnnhwbDEJ
5bd2/pH5SPEVe2JtLg+l8b9heSWHnxpO/P7hU/qxPOVNl6UnSiOvVfSdrbv4CdAX
Y9pU5kXOni93FVmDnnbu9QpceZrK8A8768dUueXWNJST6nwXdXaiAg0sMk4uWbg9
EiWTxKhFxWE=
=qrpV
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 11 May 2023 12:38
(name . Christopher Baines)(address . mail@cbaines.net)
87pm775f0l.fsf@gnu.org
Hi,

Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (4 lines)
> That sort of makes sense, although I don't know why this wasn't failing
> in the same way in the past. Build logs are available though, so maybe
> this makes sense to someone.

Turns out that’s because ‘gnutls-cross.patch’ was inadvertently
dismissed in 5e1e67442188ccca8db8c1dd092efbc6fc2c33dc.

I’ll re-apply it (probably upstream as well) unless someone has already
come up with a different solution (Josselin was looking into it).

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 11 Sep 2023 16:36
(address . 63331@debbugs.gnu.org)
87pm2osrot.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (5 lines)
> The longer-term solution is to add a “builtin:git-download” derivation
> builder, just like we have “builtin:download”. The implementation
> should be relatively easy, but we’ll have to be able to deal with
> daemons that lack this builtin possibly for several years.

Patch available!


Ludo’.
V
V
Vivien Kraus wrote on 11 Sep 2023 17:16
Re: bug#63331: Guile-GnuTLS/Git circular dependency and built-in git checkouts
1ae8a6379d508bf5eb69e3540f6dba5a2c0374de.camel@planete-kraus.eu
Hello!

Le lundi 11 septembre 2023 à 16:36 +0200, Ludovic Courtès a écrit :
Toggle quote (6 lines)
> Eventually, when users are all running recent versions of
> ‘guix-daemon’ with support for “builtin:git-download” (2–4
> years from now?), we’ll be able to use “builtin:git-download”
> unconditionally and thus be sure there are no risks of
> derivation cycles.

Do foreign distros need to update their guix package as well? If that
is the case, the provided time frame might be optimistic.

Toggle quote (3 lines)
> Note that the patch series adds a hard dependency on Git.
> This is because the existing ‘git-fetch’ code depends on Git

I applaud the switch to the regular git program from libgit2, as I
would then be able to pull from my cgit "dumb" server instead of having
to maintain a mirror.

Vivien
L
L
Ludovic Courtès wrote on 11 Sep 2023 22:57
Re: bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts
(name . Vivien Kraus)(address . vivien@planete-kraus.eu)
87pm2oqvgg.fsf_-_@gnu.org
Hi,

Vivien Kraus <vivien@planete-kraus.eu> skribis:

Toggle quote (10 lines)
> Le lundi 11 septembre 2023 à 16:36 +0200, Ludovic Courtès a écrit :
>> Eventually, when users are all running recent versions of
>> ‘guix-daemon’ with support for “builtin:git-download” (2–4
>> years from now?), we’ll be able to use “builtin:git-download”
>> unconditionally and thus be sure there are no risks of
>> derivation cycles.
>
> Do foreign distros need to update their guix package as well? If that
> is the case, the provided time frame might be optimistic.

At some point, we can change clients to print a warning saying that
their daemon is outdated if it lacks “builtin:git-download”. That
should help speed things up.

Toggle quote (7 lines)
>> Note that the patch series adds a hard dependency on Git.
>> This is because the existing ‘git-fetch’ code depends on Git
>
> I applaud the switch to the regular git program from libgit2, as I
> would then be able to pull from my cgit "dumb" server instead of having
> to maintain a mirror.

Nothing changes here: ‘git-fetch’ already uses Git.

Ludo’.
S
S
Simon Tournier wrote on 25 Sep 2023 16:03
Re: bug#63331: Guile-GnuTLS/Git circular dependency
(name . Ludovic Courtès)(address . ludo@gnu.org)
87pm264afn.fsf@gmail.com
Hi,

On Sat, 06 May 2023 at 22:17, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (4 lines)
> More importantly, tarballs generated by GitLab & co. are usually built
> on the fly and change over time (details about the tarball headers
> etc. may change). So we cannot depend them.

We could just store this tarball, no?

Well, I am somehow surprise… it appears to me better to find a way for
fixing this circular dependency without introducing a hard dependency on
Git pushed as a daemon dependency.

Cheers,
simon
L
L
Ludovic Courtès wrote on 12 Oct 2023 16:44
(address . 63331-done@debbugs.gnu.org)
87lec7lx2y.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (11 lines)
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> The longer-term solution is to add a “builtin:git-download” derivation
>> builder, just like we have “builtin:download”. The implementation
>> should be relatively easy, but we’ll have to be able to deal with
>> daemons that lack this builtin possibly for several years.
>
> Patch available!
>
> https://issues.guix.gnu.org/65866

This was applied in the meantime. Closing!
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 63331@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 63331
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch