Re: linux-libre source tarballs
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") all concurrently trying to build the very same
> very-slow-to-build tarball on ci.guix.gnu.org. Sometimes one of them
> might succeed, but the others may not, and even though one of them
> succeeded, none of the failing ones retry...
>
> Not knowing exactly how ci.guix.gnu.org works, would it make sense to
> create a tarball package instead of the ... computed origin(?) tarball,
> so it could be better represented in the package dependency graph, and
> the various linux-libre-* packages can wait till it is available rather
> than all trying to recreate the same thing?
If I understand correctly, this was recently fixed in Cuirass:
https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=d1a95e8b33b454a45bda506a22a8b9d9d2c8b16e
Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
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 practically useful tool, is demonstrating what it takes to have a full system build system. Everyone's life would be easier if software packaging were made more compatible with how Guix (and Nix of course) work today. And one way to get the rest of the world move towards this goal would be to help them: propose and implement changes to their build systems that would make integration with Guix easier. So... > My idea is this: rather than generating 'imports' from native build > packages for every target - which is kinda laborious in its way - we > could translate an existing Rust/Node/Racket package into an > intermediate simple package tar ball - call it a sexp-pack ;). This How about pushing all the other package manager towards producing sexp-packs, and helping them to get there? Cheers, Konrad
Re: [PATCH RFC 0/4] Getting rid of input labels?
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 clarity; in this case, I think inputs should
>
> be a list of packages or other “lowerable” objects, rather than a list
>
> of “anything” that could be magically interpreted at run time.
I agree with this, a list of potentially ambiguous "any-type" inputs seems
fraught.
I think there's an opportunity to avoid the need to "fall back" to the status
quo, though. I picture a structure for inputs that has three cases, trivially
decided based on data shape:
- a bare symbol, eg '(tzdata glib)
this is translated to `(("tzdata" ,tzdata) ("glib" ,glib))
works the exact same if the symbol is an =origin=, you get the name of the
symbol quoted followed by the value of the symbol.
- a 2-tuple, eg '(tzdata ("gnome-lib" glib))
when we encounter a 2-tuple, we use the first value as the label and the
second as the value.
so this becomes `(("tzdata" ,tzdata) ("gnome-lib" ,glib))
- a 3-tuple, eg '(tzdata ("glib:bin" glib "bin"))
when we encounter a 3-tuple, we use the first value as the label, second as
the value, and third as the output name.
Following this convention, the inputs for most packages will be a list of bare
symbols, and packages which need custom labels and/or outputs for some inputs
can get them with little effort.
Cheers,
Ryan
Re: ocaml - how can we get more recent version of core-kernel and common ppx'es
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 package? /Erik On 18.05.2021 22:29, pukkamustard wrote: Hi Erik, There has been some work towards updating the OCaml packages in Guix (see https://issues.guix.gnu.org/47768). A lot of packages have been updated so that there is a now an updated ocaml-X package for a previously existing ocaml4.07-X package. This includes a lot of ppx'es. However not everything has been updated yet and there are still a few packages missing to be able to update ocaml-core-kernel. But maybe you could use the #47768 as a basis and update some packages towards ocaml-core-kernel? Help is also required in reviewing the patches. The series has become quite large and hard to review (42 patches). If you could try them out that would be great. -pukkamustard Erik writes: Hi, I have a project that requires a more recent core-kernel and some of the ppx'es (such as ppx_fields_conv). Being very new to guix I've managed to add/update packages for python and ruby stuff, but this ocaml.scm file is quite different. There's a lot going on which I'm guessing is related to complexities arising from the whole ppx transition that happened in the ocaml ecosystem a few years ago, or perhaps just to the somewhat unsynchronized way libraries move to new versions of the compiler and libs (just speculating here). Anyway afaict (with my limited guix-fu) I would either need to duplicate a whole lot of packages or somehow reorganize things to share definitions where it makes sense. Both those options would require some coordination with the people who made the ocaml.scm infrastructure first, because clearly there are projects out there that need the current set of packages to work like they do now and I don't want to just post a huge patch that surprises these people. Can we get a thread going somewhere on adding a recent version of ocaml-core-kernel (for the 4.11.1 ocaml package, possibly bumping that to 4.11.2 in the process)? Best regards, Erik Lovlie
Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
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 Now we never got to truely solving npm, for example. And despite heroic efforts: Go, Rust, Racket are often in stages of disarray. The irony is that, when we leverage GNU Guix infrastructure, the software packages themselves can be really simple. All we need is a source ball and a little metadata. From that GNU Guix can do the hard stuff and handle the builds and dependencies. This is why our C build system is so effective and simple packages translate well to GNU Guix. My idea is this: rather than generating 'imports' from native build packages for every target - which is kinda laborious in its way - we could translate an existing Rust/Node/Racket package into an intermediate simple package tar ball - call it a sexp-pack ;). This repackaged sexp-pack can only reference other sexp-packs which gets rid of (1). The sexp-pack generator can identify and help resolve circular dependencies which solves (2). At this intermediate stage we can also also patch sources which helps with (3). We would have a sexp-pack for cargo and another for npm. As sexp-packs are generated from source, the GNU Guix turn around and packaging time can potentially be sped up. And once a hosted sexp-pack exists it is stable. It may be silly to create another layer (of indirection). But I think that breaking up the packaging process this way will help us to actually fix npm and cargo support in a reasonable time frame. Also it works the other way, I would no longer need cargo or Racket packages ;) Pj.
Re: Cuirass badges
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
