On Sat, May 29, 2021 at 09:50:36PM -0700, Vagrant Cascadian wrote:
> When it generates a tarball, all the various packages independently try
> to recreate the source tarball; so you have at least fours jobs
> ("linux-libre", "linux-libre-arm64-generic", "linux-libre-headers",
> "linux-libre-bpf") a
Hi Pjotr,
> Maybe this is a crazy idea:
Not crazy enough for me ;-)
Today's mess with language and platform specific build systems is indeed
a problem, and I have been thinking as well about how Guix could help
with this beyond what it already does. Guix' big achievement, beyond
being a practica
On Wednesday, May 26th, 2021 at 2:02 PM, Ludovic Courtès wrote:
> > Could the new syntax accept both variables and specifications, e.g.,
> >
> > (list "glib:bin" foo "bar@2.3")
> >
> > ?
>
> No! I mean, yes it could, but no, I don’t think that’s a good idea.
>
> :-)
>
> In terms of API, I prefer c
I have now applied the patches locally and tested a handful of the
updated packages, and things appear to be working fine for me. Thanks a
lot for doing this!
What is the process for getting these patches commited to master? Do we
need someone to test that the patches didn't break any existing
Maybe this is a crazy idea:
It appears to me that every language out there today is creating their
own build system. We know that creating build-system package support
for GNU Guix is complicated by:
1. Live updates over the internet
2. Circular dependencies
3. Tests requiring internet access
No
Hey Luis,
> And the source file:
>
> https://luis-felipe.gitlab.io/media/2021/05/cuirass-badges-proposal-2021-05-28.svg
>
> I think I like d and d*.
Wooh, that's great! I updated Cuirass to use the d badge proposal.
Many thanks for your help,
Mathieu
