Building the new Podman package fails because building a depdency
(gvisor-tap-vsock) fails:
The following derivation will be built:
/gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv
building
/gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv...
WARNING:
Hi MSavoritias,
Feel free to send a patch when libgit2 gets support so we can discuss
this addition further amongst the Guix community. Additionally, I would
send your idea to the guix-devel mailing list before sending patches to
see what people think there.
I am going to close this issue for n
> Building the new Podman package fails because building a depdency
> (gvisor-tap-vsock) fails:
Hi Nils,
Would you be interested in sending patches to fix these failures?
--
all the best,
jgart
> jgart hat am 01.07.2024 16:35 CEST geschrieben:
>
>
> > Building the new Podman package fails because building a depdency
> > (gvisor-tap-vsock) fails:
>
> Hi Nils,
>
> Would you be interested in sending patches to fix these failures?
No, the patch submission process is too annoying for me
> No, the patch submission process is too annoying for me.
>
Hi Nils,
Sorry to hear that. I can relate to that as I've also been annoyed by aspects
of the process.
Can you share some of the pain points that you've experienced with the patch
submission process?
This will help us potentially ad
Hey there Sharlatan
Embed was failing as the go build tree was symlinked
So the file i sent builds because i wrote a procedure to copy the tree
Although it could also be the case that some altered form of linking
could function or that embed could be altered to accept the existing
form of the go
Hi all,
With Guix 6522f93ed098fa13f51f6d017035607e26237d31 diffoscope's test
suite fails. I'm reporting this here in case we want to try to implement
some kind of workaround in the meantime.
Diffoscope does not seem to have an upstream issue opened yet. I tried
reporting it but was blocked by the
Hi Guix,
At present it is possible to extend service-types that do not implement
compose or extend methods, resulting in surprising behavior that's hard
to debug [1]. We should throw an error when a service-type that does not
have compose or extend fields is extended.
--8<---cut here-
I've started looking into this issue and came up with the following
diff:
--8<---cut here---start->8---
diff --git a/gnu/services.scm b/gnu/services.scm
index 88593e8091..e7e2da6ad5 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -1225,10 +1225,17 @@ (de
> jgart hat am 01.07.2024 19:04 CEST geschrieben:
>
>
> > No, the patch submission process is too annoying for me.
> >
>
> Hi Nils,
>
> Sorry to hear that. I can relate to that as I've also been annoyed by aspects
> of the process.
>
> Can you share some of the pain points that you've exper
10 matches
Mail list logo
