On Tue, 28 Dec 2021 08:40:20 -0500 jgart <jg...@dismail.de> wrote: > On Tue, 28 Dec 2021 13:14:45 +0100 Ricardo Wurmus > <rek...@elephly.net> wrote: > > > > jgart <jg...@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?