Re: Guix "R" Us - GNU's joy store!

[raingloom <raingloom@riseup.net>]

On Tue, 28 Dec 2021 08:40:20 -0500
jgart <jgart@dismail.de> wrote:

> On Tue, 28 Dec 2021 13:14:45 +0100 Ricardo Wurmus
> <rekado@elephly.net> wrote:
> > 
> > jgart <jgart@dismail.de> writes:
> >   
> > > * Yet to be merged upstream.  
> > 
> > Are these going to be submitted and merged upstream eventually?    
> 
> Hi Ricardo,
> 
> From our README:
> 
> ```
> The goal of this guix channel is to provide packages and services
> that are:
> 
> * Yet to be merged upstream.
> * In alpha or beta stage of development.
> * Customized to certain use-cases.
> * Nightly releases.
> ```
> 
> To expound on the above a bit:
> 
> > Yet to be merged upstream.  
> 
> You can think of GuixRUs as a pre-release channel for software that
> is waiting to be reviewed upstream.
> 
> Sometimes patches can sit for a while while waiting for upstream
> review and GuixRUs hopes to alleviate some of this anxiety by
> providing those patches as "pre-releases" in a community channel that
> makes them available through an expedited review process. We're
> interested in developing tooling to help facilitate this ambitious
> endeavour.

I think guix time-machine and some options to guix pull already let you
build with some patches or from a custom git URL. If not, maybe making
that easier would be preferable to making a separate channel.

> > In alpha or beta stage of development.  
> 
> We'll make grumble available through GuixRUs and provide a service:
> 
> https://issues.guix.gnu.org/
> 
> Another software that is in heavy development but useable:
> 
> https://wahay.org/
> 
> > Nightly releases.  
> 
> GuixRUs will start by tracking olive-editor nightlies:
> 
> https://www.olivevideoeditor.org/nightly.php

What's the improvement with this channel compared to just using the
various package transformations, like --with-latest or --with-branch or
whatever?

> > What's the intended process to avoid this?  
> 
> Packages that are suitable for upstream will be sent in batches. 
> 
> whereiseveryone community are active contributors and we'll make sure
> to send over any developments suitable for upstream.
> 
> We welcome anyone to help contribute in those efforts. 
> 
> Feel free to upstream anything in GuixRUs that you see suitable if we
> don't get around to it.
> 
> If you remember to list the original author/packager when upstreaming
> from GuixRUs it would be much appreciated.
> 
> The first batch to be sent from GuixRUs for upstream will be these
> emacs packages we recently packaged:
> 
> https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/emacs.scm
> 
> > Customized to certain use-cases.  
> 
> I recently forked vis to provide language server protocol support
> "out of the box".[1]
> 
> We're also packaging all the suckless patches for dwm, st, dmenu,
> surf, etc... and making them available as guile variables/code in
> order to easily assemble your own suckless forks with guix[2][3]. In
> other words, GuixRUs can also be thought of as a library for
> assembling your own suckless fork.

Again, package transformations already let you do this. Might make more
sense to just set up a substitute server.

> > Is only free software acceptable in this channel?  
> 
> Yes, we only accept free software. GuixRUs is a free software bazaar.
> 
> GuixRUs is at the service of assisting upstream and the Guix
> community at large.
> 
> all best,
> 
> jgart
> 
> 
> [1]
> https://github.com/fischerling/vis-lspc#easy-vis-lspc-installation-with-guixrus
> [2]
> https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/patches/suckless.scm#L28
> [3]
> https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/suckless.scm#L44
> 

TLDR how much of the effort spent on this channel is really justified
compared to making the underserved use-cases easier in upstream Guix?