guix system reconfigure after more than a year

[vidak]

Hello all.

I did not learn to `guix system reconfigure` until recently--well,
didn't know to use it to update important things periodically.

So i did one after more than a year since having done one on my
workstation. In fact the only time I ever did it was to instantiate my
workstation's system, and I could not for the life of me figure out how
to update the Linux kernel. Lol.

So, anyway, it succeeded easily.

Imagine trying to do something like that with Gentoo.

I feel this is a massive testament to Guix.

Thank you so much for all your amazing work.

~vidak

> https://zoinks.one/vidak

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

[jgart]

On Wed, 29 Dec 2021 00:27:04 +0100 raingloom  wrote:
> TLDR how much of the effort spent on this channel is really justified
> compared to making the underserved use-cases easier in upstream Guix?

If there's any particular packages that should be sent upstream feel
free to take them from GuixRUs and send a patch to upstream. Just add
the original packager as co-author out of courtesy. Also, let us know by
linking the ticket number so that we can remove them from the channel. We
also read the commit history daily to stay up to date as we are also
regular contributors to upstream.

If there are any packages that build solely with package transformation
options from the cli and they are currently in GuixRUs also let us know and
we'll remove them after testing.

See the other points in my previous email for more reasons to
have GuixRUs (pre-releases, nightlies (olive), alpha software
(https://issues.guix.gnu.org/47104), vis-lsp, etc...).  I think people
should explore having channels for the sake of just exploring having a
channel. It allows those without commit access to have the freedom to
explore and navigate Guix how they want and at the pace that they'd
like to develop at without fully depending on upstream. Channels can
assist upstream when proper communication is involved. I also think
channels can function as a testing ground before sending a patch for
review to upstream.

The following is just two example channels that have served as a testbed
before sending to upstream:

https://git.genenetwork.org/guix-bioinformatics/guix-bioinformatics
https://github.com/ryanprior/guix-packages

GuixRUs is not a new idea. GuixRUs is like any other guix channel out
in the wild. We just want to have our own small channel as a small
community. We encourage others to start their own channels and we're
working on making starting a channel easier for newcomers in the near
future. Stay tuned!

I hope that further clarified/contextualized some points on GuixRUs I made
in previous emails. If not, feel free to reply with further questions. Thank
you for your interest.

all best,

jgart

Re: git hook error

[Tobias Geerinckx-Rice]

Tobias Geerinckx-Rice 写道：
I wonder if Savannah monitors and publishes numbers, and how 
they

compare to other popular forges.


I asked; they don't.

Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: git hook error

[Leo Famulari]

On Tue, Dec 28, 2021 at 11:31:10PM +0100, Ricardo Wurmus wrote:
> The motivation for that is not found in just one big problem.  It’s a
> small trickle of minor annoyances:
> 
> - Savannah’s uptime isn’t quite as high as we’d like

Okay. I wonder if we could actually do a better job, or if anybody who
hosts a comparable repo does.

Our own record with the build farm and the record of major hosts like
Github are both somewhat discouraging. And if we could only hope for an
equivalent uptime to Savannah, it doesn't seem worth it to shoulder this
work ourselves.

> - we can’t have server-side checks to prevent pushing bad commits
> - we can’t have server-side hooks to better integrate with the build farm
> - we can’t have per-branch rules (e.g. to allow contributors to push to
>   some but not all branches)

We do actually have a server-side hook in place to prevent pushing
unsigned commits. And if we wanted to add more tooling, the Savannah
admin(s) would help us.

Now, if we just wanted more control and visibility into the
infrastructure, that's a reason, but again, I wonder if it's worth the
effort. In terms of infrastructure maintenance, we already seem to be
stretched thin.

My opinion is that, in order to consider hosting our own Git server, we
should wait until people are using declarative Guix configuration to
operate reliable, performant, and public Git servers that would meet our
needs. That is, the Guix project needs to grow this capability without
the heroic effort of a single volunteer. Because that's what we have now
with Savannah, more or less, and we don't have to work for it. Maybe
this has already been achieved, I don't know.

Re: git hook error

[raingloom]

On Tue, 28 Dec 2021 16:40:15 -0500
Leo Famulari  wrote:

> On Tue, Dec 28, 2021 at 10:09:06PM +0100, Ricardo Wurmus wrote:
> > So… uhm, what do you all think about hosting our Git repos by
> > ourselves? Ideally *not* on the servers of the build farm, but on
> > other hardware?  
> 
> I would ask, why would we want to do that?
> 

Maybe not self-hosting, but I would really appreciate a move to a
better forge, like Sourcehut. I have... very few positive
things to say about Savannah's UI, at least from a casual user
perspective. I don't know what it's like for contributors.

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

[raingloom]

On Tue, 28 Dec 2021 08:40:20 -0500
jgart  wrote:

> On Tue, 28 Dec 2021 13:14:45 +0100 Ricardo Wurmus
>  wrote:
> > 
> > jgart  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?

Re: git hook error

[Tobias Geerinckx-Rice]

Hi Ricardo,

Ricardo Wurmus 写道：

- Savannah’s uptime isn’t quite as high as we’d like


I wonder if Savannah monitors and publishes numbers, and how they 
compare to other popular forges.


Why should we do better?  We haven't even managed to set up a git 
mirror after all these years.


- we can’t have server-side checks to prevent pushing bad 
commits
- we can’t have server-side hooks to better integrate with the 
build farm
- we can’t have per-branch rules (e.g. to allow contributors to 
push to

  some but not all branches)


Why not?  Which of these can't be got with server-side hooks?  How 
would you get them on Guix infra then?  Could the Savannah admins 
accommodate us further, if needed?


If the real reason for even one of them is ‘well, we can, but 
nobody wants to write those hooks’, that only bolsters my previous 
scepticism.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: git hook error

[Ricardo Wurmus]

Leo Famulari  writes:

> On Tue, Dec 28, 2021 at 10:09:06PM +0100, Ricardo Wurmus wrote:
>> So… uhm, what do you all think about hosting our Git repos by ourselves?
>> Ideally *not* on the servers of the build farm, but on other hardware?
>
> I would ask, why would we want to do that?

The motivation for that is not found in just one big problem.  It’s a
small trickle of minor annoyances:

- Savannah’s uptime isn’t quite as high as we’d like
- we can’t have server-side checks to prevent pushing bad commits
- we can’t have server-side hooks to better integrate with the build farm
- we can’t have per-branch rules (e.g. to allow contributors to push to
  some but not all branches)

-- 
Ricardo

Re: git hook error

[Leo Famulari]

On Tue, Dec 28, 2021 at 10:09:06PM +0100, Ricardo Wurmus wrote:
> So… uhm, what do you all think about hosting our Git repos by ourselves?
> Ideally *not* on the servers of the build farm, but on other hardware?

I would ask, why would we want to do that?

Re: git hook error

[Ricardo Wurmus]

Leo Famulari  writes:

> On Tue, Dec 28, 2021 at 09:26:54PM +0100, Tobias Geerinckx-Rice wrote:
>> Ricardo,
>> 
>> This is .
>
> Also happened in 2017:
>
> https://www.mail-archive.com/savannah-hackers-public@gnu.org/msg05571.html

Thanks for the pointers!

So… uhm, what do you all think about hosting our Git repos by ourselves?
Ideally *not* on the servers of the build farm, but on other hardware?

-- 
Ricardo

On raw strings in commit field

[Liliana Marie Prikler]

Hi Guix,

when Ricardo recently added guile-aiscm to Guix, I was confused that
both the version field of the package and the commit field of the git-
reference used in its origin.  It turns out, that this is a rare
pattern observed in less than 200 packages currently in Guix.   The
reason to do so (as far as I understand and was explained to me in IRC)
is that commit tags are in principle mutable and hence can not be
relied on when fetching sources.  I do have a few issues with that
explanation, but before that let's go a step back and discuss the
relation of version and commit.

Consider a package being added or updated in Guix.  At the time of
commit, we have the tag v1.2.3 pointing towards commit deadbeef.  We
therefore create a guix package with version "1.2.3" pointing to said
commit (either directly or indirectly).  At this point, one of the
following holds:
  (1) Guix "1.2.3" -> upstream "v1.2.3" -> upstream "deadbeef"
  (2) Guix "1.2.3" -> upstream "deadbeef" <- upstream "v1.2.3"
>From either, we can follow that Guix "1.2.3" = upstream "v1.2.3".  If
upstream keeps their tags around, then both forms are equivalent, but
(1) is more convenient; it allows us to derive commit from version,
which is often done through an affine mapping.

Problems arise, when upstreams move or delete tags.  At this point,
guix packages that use them break and are no longer able to fetch their
source code.  Raw commits are in principle resilient to this kind of
denial of service; instead upstreams would have to actually delete the
commits themselves, including also possible backups such as SWH to
break it.  There is certainly an argument for robustness to be made
here, particularly concerning `guix time-machine', though as noted it
is not infallible.  

It should be noted, that in the case of moving or deleted tags, the
assertion Guix "1.2.3" = upstream "v1.2.3" no longer holds.  Widespread
use of this pattern under the above reasoning would imply that those
upstreams can't be trusted to have stable tags when there are probably
few offenders in that category (considering also that Guix is not the
only tool they'd break if they do move or delete tags).  More
importantly, if we do have a non-trustworthy upstream, it could be
reasoned that referring to some tag is as good as referring to a random
commit and thereby let-bound commits and revisions ought to be used.

As any good Sith would, the above talks in absolutes, or at the very
least uses default logic without considerable fallbacks.  On the note
of fallbacks, we do also have the issue that Guix fails on the first
download that does not match the hash instead of e.g. continuing to SWH
to fetch an archive of the old tag (as well as other fallback-related
issues, also including the "Tricking Peer Review" thread).  Putting
those aside for a while, there is an all but endless amount of
upstreams for which we can't tell ahead of time whether they will act
nicely or not.  The status quo for most of our packages is to assume
that they do and fail loudly if they don't.  The proposed alternative
is to assume they don't and miss out on nice things if they do. 
However, even under that assumption we also miss out on ninja version
bumps and the only way of noticing other than paranoid amounts of
checking whether the tag moved would be to wait for a mail from
upstream claiming that they actually wanted us to notice the ninja
bump.

Neither of the above is really satisfactory.  At the very least, if raw
strings are to be used in the commit fields for tags that "once
existed, but maybe no longer point to that commit", I'd want a comment
like the ones I find in minetest.scm to mentally prepare me for what
I'm about to read in the rest of the package description, but I'd much
prefer using let-bound commit/revision pairs.  Perhaps we could make
revision "0" (alternatively #f if we don't want current versions to
break) special in that a git-version with it expands to just version.  

Long-term, we might want to support having multiple  in
git-fetch -- if the first one fails due to a hash mismatch, we would
warn about that instead of producing an error and thereafter continue
with the second, third, etc. similar to how we currently have mirror://
urls for some well-known mirrored repositories.  That way, we have a
system to warn us about naughty upstreams while also providing
robustness for the time machine.

What do y'all think?

Re: git hook error

[Leo Famulari]

On Tue, Dec 28, 2021 at 09:26:54PM +0100, Tobias Geerinckx-Rice wrote:
> Ricardo,
> 
> This is .

Also happened in 2017:

https://www.mail-archive.com/savannah-hackers-public@gnu.org/msg05571.html

Re: git hook error

[Tobias Geerinckx-Rice]

Ricardo,

This is .

Kind regards,

T G-R


signature.asc
Description: PGP signature

git hook error

[Ricardo Wurmus]

Since a few days I see this when pushing to the repository:

--8<---cut here---start->8---
Enumerating objects: 35, done.
Counting objects: 100% (35/35), done.
Delta compression using up to 4 threads
Compressing objects: 100% (28/28), done.
Writing objects: 100% (28/28), 11.76 KiB | 1.18 MiB/s, done.
Total 28 (delta 22), reused 0 (delta 0), pack-reused 0
remote: Traceback (most recent call last):
remote:   File "hooks/post-receive", line 6, in 
remote: import git_multimail
remote: ImportError: No module named git_multimail
--8<---cut here---end--->8---

Is this our fault or did something change on Savannah’s side?

-- 
Ricardo

Re: Formalizing teams

[Ricardo Wurmus]

Kyle Meyer  writes:

> Fwiw public-inbox indexes the file name from diffs, so you might find
> searching with the "dfn:" against the archive at
>  useful.  For example:
>
>   https://yhetil.org/guix-patches/?q=dfn%3Agnu%2Fpackages%2Fpython-web.scm

FWIW, mumi also lets you search patches as all contents are indexed:


https://issues.guix.gnu.org/search?query=%22%28gnu+packages+python-web%29%22+is%3Aopen+tag%3Apatch

-- 
Ricardo

Re: Formalizing teams

[Kyle Meyer]

Lars-Dominik Braun writes:

> Hi Maxim,
>
>> I've grown to like our apparent lack of structure; we interact globally
>> on any topic of interest and the discussions all happen in a shared
>> space, which makes it easy to stay informed with everything that's going
>> on (do we really need more mailing lists to follow?  I don't think so --
>> our current volume doesn't warrant it).
> to me this is a disadvantage. I don’t have enough time at my hands to
> look at every single thread and patch in my inbox and decide whether
> I can/want to work on it. Thus I’d prefer if I could unsubscribe
> from -patches (I’m not even subscribed to -bug/-commit) and instead
> only look at bugs/patches/commits related to packages/components I’m
> interested into/I actually use.

Fwiw public-inbox indexes the file name from diffs, so you might find
searching with the "dfn:" against the archive at
 useful.  For example:

  https://yhetil.org/guix-patches/?q=dfn%3Agnu%2Fpackages%2Fpython-web.scm

Or with public-inbox's lei (from v1.7.0, which isn't yet packaged for
Guix), you could dump those results to a maildir:

  $ lei q -o /tmp/mdir --mua mutt \
-I https://yhetil.org/guix-patches dfn:gnu/packages/python-web.scm 
d:4.months.ago..
  # later: update with new results and visit in mutt
  $ lei up --mua mutt /tmp/mdir

If you're interested, I went into a bit more detail about this at
.

Re: Formalizing teams

[Ricardo Wurmus]

Maxim Cournoyer  writes:

>> Guix is nowhere near the size of the Rust community (yet!), but I can
>> already picture teams and members:
>>
>>   co-maintainers (“core team”)
>>   community
>>   infrastructure
>>   internationalization
>>   security response
>>   release
>>   Rust packaging
>>   R packaging
>>   Java packaging
>
> We'd have to include every language/system of importance to that list
> (Python, Ruby, Emacs, LaTeX, Perl, etc.), no?

No, only those where we already have the people who could form a team.
There is no need for any of this to be comprehensive.  It just needs to
be an improvement over the status quo.

FWIW, I’ll gladly make it official that I could be the person to talk to
when it comes to “R packaging”.  This is already the case, but only
those people know it who don’t really need to know this.

Advertising this kind of information or recording it somewhere where our
tools could redirect incoming requests would be an improvement.

> Are our problems really organizational?  I think before attempting to
> come up with a solution, we must analyze and agree on what it is that
> needs improvement to help us move forward more efficiently.

I do think it’s a lack of organization, yes.  Today I’m no longer
following guix-commits, guix-patches, or bug-guix, and I’m overwhelmed
by guix-devel and help-guix.  Whenever something catches my attention
I’ll read a bit and maybe reply.  But by far the best way to get my
attention for a review is to ask on #guix or #guix-hpc or to
X-Debbugs-Cc (or Cc) me on emails.

Having some topic-specific streams I could tap into would allow me to be
a little more proactive.

-- 
Ricardo

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

[jgart]

On Tue, 28 Dec 2021 13:14:45 +0100 Ricardo Wurmus  wrote:
> 
> jgart  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.

> 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 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.

> 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

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

[Ricardo Wurmus]

jgart  writes:

> * Yet to be merged upstream.

Are these going to be submitted and merged upstream eventually?  I think
it would be regrettable to establish a channel where ready-to-merge
packages accumulate that never make it into Guix proper because people
don’t want to make the little bit of extra effort to move them.

What’s the intended process to avoid this?

Is only free software acceptable in this channel?

-- 
Ricardo

Re: Formalizing teams

[Lars-Dominik Braun]

Hi Maxim,

> I've grown to like our apparent lack of structure; we interact globally
> on any topic of interest and the discussions all happen in a shared
> space, which makes it easy to stay informed with everything that's going
> on (do we really need more mailing lists to follow?  I don't think so --
> our current volume doesn't warrant it).
to me this is a disadvantage. I don’t have enough time at my hands to
look at every single thread and patch in my inbox and decide whether
I can/want to work on it. Thus I’d prefer if I could unsubscribe
from -patches (I’m not even subscribed to -bug/-commit) and instead
only look at bugs/patches/commits related to packages/components I’m
interested into/I actually use.

To that end having more structure would help. Teams are just one option,
but we need a way to efficiently connect people with skills to review/help
with those who need the review/help. This sounds similar to what
Gentoo’s Bug Wranglers[1] do. I believe someone brought up to automate
this by suggesting reviewers for patches based on the commit history
of packages/components.

[1] https://wiki.gentoo.org/wiki/Project:Bug-wranglers

Cheers,
Lars