Re: Building a software toolchain that works

Hi, On Tue, 15 Mar 2022 at 09:19:50 +0100, Ludovic Courtès wrote: > > One could develop a `guix contribute ` subcommand or standalone > > script that would implement the following workflow: > > > > 1. Obtain the source and unpack it into a writable working directory, > >skipping downstream p

Improve the output of `guix refresh -l`

Hello, Guix! Inspired by https://git.savannah.gnu.org/cgit/guix.git/commit/?id=209a3274f8702acd32fa2a489667048ca4ad304b. I found that the output of `guix refresh -l` for package have many dependants is not convenient to read. for example, run `guix refresh -l pango`, The terminal prints: ``` Bui

Re: Building a software toolchain that works

Hi Ryan, > a. My Guile isn't strong enough to put together a proof-of-concept in > Guix as a solo effort. I might be able to write a PoC in concert with > a more experienced Guiler. We could schedule some strategy & pair > programming sessions to get something on track. Do not miss:

Re: Building a software toolchain that works

Hi Olivier, > On another note, what I find fascinating is why Guix and Nix are not > more used in academic papers. Indeed. One part of the answer is, IMHO: it is difficult to spread the word. For instance, with co-authors, we have tried to write a short paper detailing what Guix solves, i.e., t

Re: Improve the output of `guix refresh -l`

Zhu Zihao schreef op do 17-03-2022 om 18:22 [+0800]: > for example, run `guix refresh -l pango`, The terminal prints: > > ``` > Building the following 2945 packages would ensure 7521 dependent > packages are rebuilt: .. > ``` > > The package list is too long to read, flood my terminal with pa

Re: Building a software toolchain that works

David Arroyo schreef op ma 14-03-2022 om 17:40 [-0400]: > 1. Obtain the source and unpack it into a writable working directory, >    skipping downstream patches and snippets. Why skip downstream patches and snippets? Often, these are necessry to make the source actually compileable (e.g. if it us

Re: Building a software toolchain that works

On Thu, Mar 17, 2022, at 11:35, Maxime Devos wrote: > Why skip downstream patches and snippets? The spirit of the workflow is to enable someone to easily contribute a patch to an upstream project. With that in mind, I assumed that our downstream patches would not be accepted by the upstream projec

Re: Building a software toolchain that works

I run Guix everywhere I can, and it's now the only way I develop software. Having said that, I have thought about this issue a little bit, and here's my opinion on why this happens. Pjotr Prins writes: > And they start out as the next new thing to solve all problems! If > they would only woul

Interest in "guix lint" Meetup?

Hey folks, was wondering if there would be interest in doing a virtual meetup where we try and fix issues revealed by "guix lint". On a fairly recently pulled guix: $ guix lint --checkers=description > guix-lint-description $ guix lint --checkers=synopsis > guix-lint-description $ wc -l gui

Re: Interest in "guix lint" Meetup?

On Thu, 17 Mar 2022 21:04:13 -0400 Vagrant Cascadian wrote > The description and synopsis fixes are generally pretty easy, so might > make for good first steps for someone wanting to get familiar with the > process of contributing without having to invest a whole lot of time and

Re: Building a software toolchain that works

On Thu, Mar 17, 2022 at 03:04:18PM -0500, Katherine Cox-Buday wrote: > In addition, because free software is largely developed in people's spare > time, they're going to use whatever tools make them most productive or even > just happy. They're probably not thinking about their software against t