Re: [fr] Moment de convivialité Guix@Paris en février

[Tanguy LE CARROUR]

(Warning: this email is in french because the meeting is supposed
to be held in French.)

Bonjour Guix,

Pour rappel, Guix@Paris c'est demain soir ! 
C'est toujours à l’April et toujours à 19h !

**SPOILER ALERT**… on risque d’un peu parler de ce qui s’est dit pendant
les Guix Days !

D’ici là, je vous souhaite une excellente journée !

-- 
Tanguy

Re: TODO Delete branch snapper.

[Maxim Cournoyer]

Hi,

Nicolas Graves via "Development of GNU Guix and the GNU System
distribution."  writes:

> The snapper branch is here with no activity for quite some time.
>
> There's a patch for snapper in 57311, maybe we can start by deleting the
> branch. 

Done (the branch is now deleted).

-- 
Thanks,
Maxim

Re: Debbugs update

[Suhail]

Felix Lechner via "Development of GNU Guix and the GNU System
distribution."  writes:

> My primary hurdle with modernizing Debbugs, if anyone cares, is that the
> FSF is reluctant to deploy GNU Guix. They insist on Trisquel plus
> Ansible [11] which is what they have been using for some time.
>
> ...
>
> [11] https://lists.nongnu.org/archive/html/help-debbugs/2024-01/msg00049.html

Thank you for your contributions.  On another note, is above the
intended link?  The linked message is from you, and I was unable to find
any specific objections to Guix (by someone speaking on behalf of FSF)
in it.

-- 
Suhail

Re: ice-9 match penalty depending on pattern?

[Carlo Zancanaro]

> ./guix/docker.scm:261:  (((head ...) (tail ...) id)

This one is not like the others. However, looking at the context I think
the pattern could just be (head tail id).

> Why not?  Do I miss something in the implementation of ’match’?

The only reason I can think of would be if these matches are sometimes
provided improper lists, which need to fail these match conditions. That
seems unlikely to me, but it should be clear from looking at the other
match clauses in each case.

Carlo

ice-9 match penalty depending on pattern?

[Simon Tournier]

Hi,

>From Ludo’s mastodon message [1]:

Re ‘match’ penalty: when using ellipses in patterns, the generated
code checks for “proper lists”, which is O(n).  The trick is to
instead match a pair:

✔ (match lst ((head . tail) …))
❎ (match lst ((head tail ...) …))

Therefore I have confused by some patterns.

--8<---cut here---start->8---
28 candidates:
./gnu/services/monitoring.scm:249:((head tail ...)
./gnu/system/file-systems.scm:249:  ((head1 tail1 ...)
./gnu/system/file-systems.scm:251: ((head2 tail2 ...)
./gnu/packages.scm:116:  ((_ file head tail ...)
./gnu/build/activation.scm:85:  ((head tail ...)
./gnu/build/linux-boot.scm:225:  ((head tail ...)
./guix/http-client.scm:255:  ((head tail ...)
./guix/records.scm:604:  ((_ record field offset ((head normal) tail ...))
./guix/records.scm:607:  ((_ record field offset ((head delayed) tail ...))
./guix/records.scm:610:  ((_ record field offset ((head thunked) tail ...))
./guix/read-print.scm:482:  ((head tail ...)
./guix/read-print.scm:750:  ((head tail ...)
./guix/lint.scm:1614:((head tail ...)
./guix/scripts/package.scm:809: ((head tail ...) head
./guix/self.scm:160:  ((head tail ...)
./guix/store.scm:1556:((head tail ...)
./guix/store.scm:1764:  ((head tail ...)
./guix/ui.scm:295:  ((head tail ...)
./guix/ui.scm:2258:   ((head tail ...) head)))
./guix/docker.scm:261:  (((head ...) (tail ...) id)
./guix/build/store-copy.scm:72:((head tail ...)
./guix/build/gremlin.scm:336:  ((head tail ...)
./guix/build/graft.scm:330:  ((head tail ...)
./guix/build/utils.scm:236:  ((head tail ...)
./guix/build/utils.scm:405:  ((head tail ...)
./guix/utils.scm:910:  ((head1 tail1 ...)
./guix/utils.scm:913: ((head2 tail2 ...)
./build-aux/compile-all.scm:71:   ((head tail ...)
--8<---cut here---end--->8---

Maybe for some of them, it changes nothing for the user-visible
performances.  Maybe it does. :-)

Well, I do not know the length of each match.  However, some are part of
some loop.  Therefore, if we could save some cycles by simply replacing
the ellipsis, as

((head tail ...) stuff that use head or tail)

by

((head . tail) stuff that use head or tail)

Why not?  Do I miss something in the implementation of ’match’?

Cheers,
simon

1:
https://social.sciences.re/@civo...@toot.aquilenet.fr/111885442823194970

Re: Debbugs update (Was: Guix Days: Patch flow discussion)

[Ricardo Wurmus]

Hi Felix,

> I also packaged and deployed on GNU Guix
>
>   (A) the fifteen-year old Debbugs version deployed at gnu.org [2][3][4]
>   (B) the modern Debbugs version deployed at debian.org [5][6][7]
>   (C) and a custom version of Mumi for my own bug fixes [8][9]
>
> Together with the official debbugs.gnu.org, which runs on Debian 8, and
> issues.guix.gnu.org, I am now working to fold all five deployments into
> one.

Let me just pop in to say thank you for that.  I appreciate you taking
the time to talk to Debbugs / GNU folks to work through the obstacles
that the current situation with the GNU fork of Debbugs presents us
with.

I don’t want to add weight to the scales on either side (a future with
or without Debbugs), but I think it is important to identify the actual
limitations and opportunities of the existing platform and chart the
shortest route around them.

It’s how we ended up with mumi in the first place, and I’m hopeful that
this approach can get us to a better place when it comes to tooling.

(The biggest chunk of the problem may well be a social issue, that can
only be overcome if we find a narrative we all can comfortably enact.)

-- 
Ricardo

Re: Guix Days: Patch flow discussion

[Suhail]

Josselin Poiret  writes:

> Your mailing system is sending out emails that contain an invalid
> Message-ID header (missing right part of the msgid as specified in
> [1]),
> ...
> [1] https://datatracker.ietf.org/doc/html/rfc2822#section-3.6.4

My apologies (to everyone)!  Thank you for bringing this to my
attention.

> which causes erratic behavior from other participants (the gmail smtp
> servers for example just rewrite the message id to indicate it is
> malformed, breaking the reply chain).

Ouch.

> Could you please fix this?

I believe this is now fixed.  Please let me know in case the issue
persists, or you notice others (though, perhaps, off list).

-- 
Suhail

Re: Guix Days: Patch flow discussion

[Suhail]

Josselin Poiret  writes:

> One thing I would like to get rid of though is debbugs.  It causes a
> lot of pain for everyone, eg. when sending patchsets, it completely
> breaks modern email because it insists on rewriting DMARC-protected
> headers, thus needing to also rewrite "From:" to avoid DMARC errors.

Thank you for sharing (what seems to be) a technical limitation of
Debbugs.  Could you please explain what the consequences of the above
are?  Specifically, how does the rewriting of above headers affect the
contributors' workflow?

> b4/lei is a nice example (we already have yhetil.org as a back-end,
> but maybe a more blessed one would be better) of a tool that lets you
> completely automate applying a patchset to a branch.
>
> patchwork is a nice tool to gather up and track patchsets, with status
> indicators like "under review", "accepted", etc.  Chris already
> deploys one as part of QA, more integration with it would be nice.

It seems (based on above) that "patchwork" can co-exist with debbugs.
Is that also the case with b4/lei?  Specifically, are the
users/reviewers able to benefit from using the above tools at present?
Or are there some reasons (over and above their lack of familiarity with
the above tools) that would prevent them from doing so?

-- 
Suhail

Re: Guix Days: Patch flow discussion

[Suhail]

Steve George  writes:

> The general opinion seemed to be, that it was better to fix small
> issues and commit the change for new users, so they had the
> satisfaction of their contribution making it into the repository. One
> proposal was to do the 'fix', and to then reply back to the bug with a
> diff - showing what was done.

I see.  Thank you for sharing.  I believe being more didactic with "new
users" would be good for the community.

-- 
Suhail

Re: Guix Days: Patch flow discussion

[Suhail]

Steve George  writes:

> elsewhere in the thread someone mentions some tags we could use
> consistently so maintainers can find patches that have been reviewed
> easily.

It seems on the [dev manual] we already have "reviewed-looks-good"
documented.  Thus, I'd like to propose the below *mutually exclusive*
Debbugs tag set:

- "not-yet-reviewed" :: automatically set for all submissions
- "reviewed-needs-fix" :: set explicitly by the reviewer
- "needs-another-review" :: automatically set if there's a revised
  patch, unless "not-yet-reviewed" (in which case no change)
- "reviewed-looks-good" :: set explicitly by the reviewer

In addition to the above, it might also help for there to be an
additional tag of "might-not-need-review" (or simpler,
"review-not-needed") which gets automatically set, provided we implement
a way to label some changes (for some packages) as being "trivial enough
that they're okay as long as build succeeds".

On a related note, is it possible for a reviewer who isn't a committer
to set debbugs tags?

[dev manual]: 


> It would be great to agree those - try them for a bit - and document
> them in a 'howto' so that everyone uses the same process.

In addition to documenting the tags in the "Debbugs Usertags" section of
the manual, it would help for there to be a "howto" which focuses more
on the transition between the tags (i.e., the contribution workflow).

-- 
Suhail

Re: [fr] Moment de convivialité Guix@Paris en février

[Simon Tournier]

salut,

On jeu., 01 févr. 2024 at 20:51, Tanguy LE CARROUR  wrote:

> Ce jeudi 8 février 2024 à 19h, se tiendra la cinquième édition de Guix@Paris
> ouverte au public.
> Comme les fois précédentes, il sera possible de participer à distance
> (*cf* ci-dessous).

Chouette !  Ayant raté la journée de jeudi des Guix Days, je suis très
intéressé par un petit résumé. :-D  Peut-être pas le seul
d’ailleurs. ;-)

à très tantôt,
simon

Re: Mechanism for helping in multi-channels configuration

[Attila Lendvai]

> The wishlist is: provide a machine-readable description on guix-science
> channel side in order to help in finding the good overlap between
> commits of different channels.


i wrote about a missing abstraction here:

https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00104.html

which is more or less related to this.

the git commit log is a too fine-grained granularity here. there should be 
something like a 'guix log' above the git log that could be used, among other 
things, to encode inter-channel dependencies.

maybe frequent semver releases for guix channels could work as reference points 
to be used to formally encode inter-channel dependencies? (and to guide the 
substitute chaching/building; mark "safe points" for the time-machine; etc)

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
Life is a tragedy to those who feel and a comedy to those who think.

Re: Mechanism for helping in multi-channels configuration

[Attila Lendvai]

> Anything is better than an obscure failure/backtrace


i disagree with this specific statement. in the long run, the (inconspicuous) 
cost of added complexity can easily move anything into net negative territory.

IOW, feel encouraged to account for the cost of complexity. it's rarely done 
prior to setbacks.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Until we have met the monsters in ourselves, we keep trying to slay them in 
the outer world. And we find that we cannot. For all darkness in the world 
stems from darkness in the heart. And it is there that we must do our work.”
— Marianne Williamson (1952–), 'Everyday Grace: Having Hope, Finding 
Forgiveness And Making Miracles' (2004)

Re: Guix Days: Patch flow discussion

[Steve George]

Hi Suhail,

On  5 Feb, Suhail wrote:
> Felix Lechner via  writes:
> 
> > Another is that committers should commit what they think is right
> > rather than ask for revised patches.
> 
> I could be mistaken, but I believe this does happen today at least some
> of the time.  Is your position that
> 
> 1. this never happens today and thus, should happen some times when
>warranted.  Or that,
> 
> 2. it happens far too rarely today, and should happen more often. Or
>that,
> 
> 3. committers should never ask for revisions?
(...)

Just to reply to this part, there were a variety of views on what the correct 
balance was between teaching someone and fixing issues so that a contributors 
patch was applied without them having to make further efforts. The general 
opinion seemed to be, that it was better to fix small issues and commit the 
change for new users, so they had the satisfaction of their contribution making 
it into the repository. One proposal was to do the 'fix', and to then reply 
back to the bug with a diff - showing what was done.

Steve

Re: bug#68920: Issues with issues.guix.gnu.org (502 Bad Gateway)

[Andreas Enge]

Am Tue, Feb 06, 2024 at 09:22:43AM -0500 schrieb Maxim Cournoyer:
> Thanks for the report.  It occurred a few times in the past weeks, where
> the 'mumi' service had to be restarted on Berlin.  Let's keep this open
> to see if it'll occur again.  Otherwise I'll close it in a week or two.

It has happened for me last evening, so it does not seem to be definitely
fixed.

Andreas

Re: Intermediate abstraction of system service configuration

[Dale Mellor]

Hello Carlo,

On Tue, 2024-02-06 at 23:10 +1100, Carlo Zancanaro wrote:
> The nginx{,-upstream,-server}-configuration records have fields for
> {extra,raw}-content, which do allow arbitrary configuration lines to
> be
> added to their config. I think this is a sensible escape hatch to
> have
> to provide this middle ground.

   The problem is that some configurations, especially nginx, are
sensitive to the order in which items appear and may require slightly
intricate nesting, and you can't always achieve that with intermixed
raw configuration sections.  And those sections are not (easily)
introspectable.

> Andrew Tropin has done something interesting on the idea of more
> free-form configuration for nginx specifically[1], but I don't think
> that idea has found its way out of rde and into Guix yet.
> 
> >   I think that Guix taking the view of a configuration
> > file as a nested set of string-named blocks containing
> > lists of string-named, string-valued pairs would be an
> > intermediate level of abstraction more suited to the
> > Guix system configuration view of the world.
> 
> We'd have to think carefully about how the Guix model of
> service extension would work with such an intermediate
> representation.

   Agree that it would have repercussions throughout the package
ecosystem.  I would have thought that it would make things easier.  You
could argue that you don't benefit from the Guile syntax checker, but
at the end of the day you don't find out you've made a mistake until
you try to run `guix system reconfigure` anyway.

Re: Preservation of Guix report for 2024-01-26

[Ludovic Courtès]

Hello!

Timothy Sample  skribis:

> I sent https://issues.guix.gnu.org/68769.  Now I see that I didn’t have
> the newest Git hooks installed, so no change ID and no email to the
> relevant team.  Sorry!  (I use worktrees so the Makefile didn’t fix this
> for me automatically – I should have double checked.)

Impressive stuff.

>> We’ll also have to sync the disarchive.guix.gnu.org with ngyro.com.
>
> Hopefully our old system will work again, but I will have to consolidate
> my collection of Disarchive specifications, first.

Please let me/sysadmins know when and how we should run rsync to grab
new stuff from your database.

(We could also set up an infrequent rsync job if that makes sense.)

> I mean the PoG “project”.  Instead of just testing and reporting, it
> will preserve.  For instance, right now if it encounters a tarball that
> Disarchive can’t unpack, it shrugs and moves on.  I want it to store
> those so that we are guaranteed to be able to revisit it in the future.
> Same thing for sources not (yet) in SWH.  I want to store those so that
> SWH can ingest them later.  Because we are doing so well working with
> SWH, the storage requirements for this will be manageable (10s of
> gigabytes).  With that in place, the PoG report will simply explain what
> the archive needs to store and why.  Our goal, then, will be for it to
> store nothing.

That makes a lot of sense to me.  I’m not sure how to implement it but
you certainly have ideas.

Thanks,
Ludo’.

Re: bug#68920: Issues with issues.guix.gnu.org (502 Bad Gateway)

[Maxim Cournoyer]

Hi Christina,

Christina O'Donnell  writes:

> Hi Guix,
>
> From my machine[1] connecting to https://issues.guix.gnu.org/ results
> in, after 130 seconds[2], a 502 bad gateway. It's been having issues
> for over a week, but I only just found a need to test it.
>
> I couldn't see an issue about it on debbugs so I thought it prudent to
> raise an issue.
>
> Reproduced with curl, firefox, and ungoogled-chromium on the main page
> and on specific issues.
>
> It appears to be under a lot of load.

Thanks for the report.  It occurred a few times in the past weeks, where
the 'mumi' service had to be restarted on Berlin.  Let's keep this open
to see if it'll occur again.  Otherwise I'll close it in a week or two.

-- 
Thanks,
Maxim

Re: Mechanism for helping in multi-channels configuration

[Maxim Cournoyer]

Hi,

Simon Tournier  writes:

> Hi,
>
> Well, using Guix bdab356 from a little bit more than one month old, then
> associating the channel guix-science 0b3d4a2f last week, I get the
> failure:
>
> $ guix build /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv
> The following derivation will be built:
>   /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv
> building /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv...
> (repl-version 0 1 1)
> WARNING: (guix-science build bazel-build-system): imported module (guix build 
> utils) overrides core binding `delete'
> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value 
> (python-nr-stream)) (value #f))
> builder for `/gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv' 
> failed to produce output path 
> `/gnu/store/qzgj4vig3vklbznz1i0pgy11nr3z4rv9-guix-science'
> build of /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv failed
> View build log at 
> '/var/log/guix/drvs/g3/aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv.gz'.
> guix build: error: build of 
> `/gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv' failed
>
> Well, that’s expected!  Guix bdab356 does not contain python-nr-stream
> introduced by commit 7dfe41aa71a4a4a9d6065a44e9c6271717215b3e.
>
> The wishlist is: provide a machine-readable description on guix-science
> channel side in order to help in finding the good overlap between
> commits of different channels.
>
> It could be nice if instead of an hard error, “guix pull” could say:
> « the channel ’guix’ needs to be at least at commit 1234abc ».

Anything is better than an obscure failure/backtrace, so I'd say it's a
good idea, especially if you are motivated to hack on it.

-- 
Thanks,
Maxim

Debbugs update (Was: Guix Days: Patch flow discussion)

[Development of GNU Guix and the GNU System distribution.]

Hi Hartmut & Josselin,

On Mon, Feb 05 2024, Hartmut Goebel wrote:

> Am 05.02.24 um 10:39 schrieb Steve George:
>
> [order of quotations reversed]
>
> The current mail-based workflow is too complicated ... which has been
> discussed several times already without any result:

Well, that's not totally true. After hearing the plight last year, I
offered the FSF to assume responsibility for debbugs.gnu.org. [1]

I also packaged and deployed on GNU Guix

  (A) the fifteen-year old Debbugs version deployed at gnu.org [2][3][4]
  (B) the modern Debbugs version deployed at debian.org [5][6][7]
  (C) and a custom version of Mumi for my own bug fixes [8][9]

Together with the official debbugs.gnu.org, which runs on Debian 8, and
issues.guix.gnu.org, I am now working to fold all five deployments into
one.

On Tue, Feb 06 2024, Josselin Poiret wrote:

> One thing I would like to get rid of though is debbugs.

I can do little to appease the hardcore Debbugs haters, but I have a
vision for a bug tracking system that, written in GNU Guile, will
attract less wholesale criticism and more constructive contributions
from from the Emacs and Guix communities, which are the primary users of
debbugs.gnu.org.

Both groups are already in love with the lambda calculus.

Mumi made great steps in that direction but has so far not attracted the
contributions it deserves.

In another piece of the puzzle, Michael Albinus wrote and maintains an
excellent Emacs package called Debbugs.el. It allows bug work to take
place in Gnus and Org Modes [10] rather than in a web browser. With that
package, Emacs could become a favorite way to work on our bugs and
patches, similar to what Magit did for Git.

At Guix, folks also do not use Debbugs to its full potential. Git hooks
are an example. Mumi obscures some features. I know because I worked on
Debian's bugs for many years.

I am committed to Debbugs because I'm not sure interactions between
people can be audited properly on modern development forges. For many
years, I worked with Salsa, Debian's Gitlab instance. While convenient,
it was difficult to find past conversations and code snippets, although
like Josselin I'm watching what the kernel folks are doing.

The databases in forges are also complicated to maintain. Plus, projects
experience immediate vendor lock in.

My primary hurdle with modernizing Debbugs, if anyone cares, is that the
FSF is reluctant to deploy GNU Guix. They insist on Trisquel plus
Ansible [11] which is what they have been using for some time.

Thank you, everyone, for your hard work on GNU Guix!

Kind regards
Felix

[1] https://lists.nongnu.org/archive/html/help-debbugs/2023-10/msg3.html
[2] https://debbugs.juix.org/cgi/bugreport.cgi?bug=66703
[3] 
https://codeberg.org/lechner/juix/src/commit/5fffdb0053b18b4b28adadbbebb79a1d9bfe2337/juix/deploy/debbugs.scm#L1046-L1184
[4] https://codeberg.org/lechner/debbugs-gnu
[5] https://better.juix.org/cgi/bugreport.cgi?bug=66703
[6] 
https://codeberg.org/lechner/juix/src/commit/5fffdb0053b18b4b28adadbbebb79a1d9bfe2337/juix/deploy/debbugs.scm#L1186-L1364
[7] https://salsa.debian.org/debbugs-team/debbugs
[8] https://mumi.juix.org/66703
[9] https://codeberg.org/lechner/mumi
[10] https://elpa.gnu.org/packages/doc/debbugs-ug.html
[11] https://lists.nongnu.org/archive/html/help-debbugs/2024-01/msg00049.html

Re: Guix Days: Patch flow discussion

[Steve George]

Hi Edouard,

On  6 Feb, Edouard Klein wrote:
> I, for one, would be willing to review patches, hoping that in turn my
> patches would be reviewed instead of staying in limbo forever, which is
> a drag on me submitting more patches.
> 
> Is there a procedure to follow, or do I just start replying "LGTM" to
> patch email threads ?

Starting to review patches would be brilliant.

I agreed to organise some 'patch review' online sessions in the next couple of 
weeks. 

Organising a basic process is a good topic for that online session. For 
example, elsewhere in the thread someone mentions some tags we could use 
consistently so maintainers can find patches that have been reviewed easily. It 
would be great to agree those - try them for a bit - and document them in a 
'howto' so that everyone uses the same process.

Steve

Re: Guix Days: Patch flow discussion

[Edouard Klein]

I, for one, would be willing to review patches, hoping that in turn my
patches would be reviewed instead of staying in limbo forever, which is
a drag on me submitting more patches.

Is there a procedure to follow, or do I just start replying "LGTM" to
patch email threads ?

Cheers,

Edouard.
Steve George  writes:

> Hi,
>
> Our goal for the discussion:
>
>   How do we double the number of patches that are *reviewed* and
>   *applied* to Guix in the next six months?
>
> Patch flow is a pipeline, to change it we could:
>
> a. Increase the number of committers - more people to do the
> work
> b. Increase the efficiency of existing committers
> c. Open the gates by decreasing the quality expected from patches
>
> We essentially decided to focus our discussion on (b). We looked at
> things that 'hinder' and 'help' patch review:
>
>
> Hinders
> 
>
> - All our patch reviewers are volunteers doing it in their spare time.
>
> - For a volunteer reviewing someone else's work is not very rewarding, most
>  would prefer to use that precious time to scratch their own itch.
>
> - Can feel like an Sisyphean task: no matter how many patches someone reviews
>  there are more, exacerbated by the number of Guix packages.
>
> - Sense of responsibility: the minute that a reviewer looks at the patch they
>  are now stuck with it
>
> - Repetitive and boring: often patches have minor issues, but it's the same
>  sorts of issues time and time again.
>
> - Risk of negative social interaction: having to tell someone that their patch
>   is incorrect, or that their contribution cannot be used is difficult and
>   draining. Some people felt it was better to say nothing, rather than to
>  respond to a patch.
>
>
> Helps
> ==
>
> This led us to the focus on the fact that **reviewing and applying
> patches can be different people**
>
> We looked for ideas to create more reviewers, make reviewing easier and
> more fun:
>
>
> - Share in the work
> 
>
> 1. encourage new reviewers to step forward - making it more known that 
> reviewing
> patches helps to get them applied. Anyone can review patches.
>
> 2. create directed 'how-to' documentation for reviewing and connect it to QA 
> so
> that 'new reviewers' know what to do
>
> 3. create documentation about 'when' and 'how' it's appropriate to send a 'v2'
> version of a patch so that the QA system builds and accepts it. Sometimes,
> patches rot because non-committers don't want to be seen as 'stealing' 
> someone's
> work with a v2 patch - but making the small changes and resubmitting to QA is
> what is required.
>
> 4. Pay someone else to do it. Noted but out of scope.
> 5. Remove old packages overhead. Old untouched packages create mental 
> overhead,
> and make the task of maintaining the repository in a good state more 
> difficult.
> We could remove old 'untouched' packages and ones that no-longer compile. We
> have methods to hide and notify.
>
>
> - Make it more fun
> ---
>
> 1. do online sessions around reviews, some sprints or pairing - both social 
> and
> a way to spread skills
> 2. find ways to recognise and appreciate reviewers - 'reviewer of the month'
> 3. make it a game - we could have a 'Guix London' vs 'Guix Paris' leader board
> for reviews. Make it a group goal 'can we beat januarys reviews number'
> 4. create some graphs / leaderboard so we know how many patches are being
> reviewed and we can recognise the contribution
>
>
> - Automate it away
> ---
>
> 1. Chris is continuing to try and automate away the boring work - general
> agreement in the group that QA has made a lot of difference.
>
> 2. general discussion about create a 'guix review' command (Nix has one) which
> would download a branch with the appropriate patch and build it locally. This 
> is
> for instances where some adjustment is needed or to check a build. While this
> can be done today, it's a number of steps and quite involved.
>
>
> Agreed Actions
> ==
>
> * [Chris]: continuing his work to improve QA automation. Implication was we'll
>  need some reports / graphs - but these were not discussed in detail.
>
> * [Futurile]: organise a **patch review online sessions**. To run every 13 
> days
>   (so it rotates through the week) - for 3 months to see if it has any 
> traction.
>   Co-ordinate with maintainers so that patches that are reviewed can be
>  committed
>
>
> Actions looking for someone - you?
> 
>
> * Carry forward the 'guix review' command idea
>
> * Write an RFC and discuss the idea of removing older 'bit-rot' packages
>
> * write 'how-to' documentation for reviews and when it's socially
> acceptable to do a v2 patch. A checklist-like approach.
>
>
> If you were in the discussion and I've misrepresented your point, or forgotten
> an important aspect please please reply and correct me.
>
> Also, if you would like to help on any of the tasks please email back to the
> group so 

Re: Experience using the Nix service as a novice user

[Carlo Zancanaro]

Hi Christian!

On Sun, Feb 04 2024, Christian Miller wrote:
> I wanted to try out the Nix service and followed the manual.  I had
> some trouble while doing so.  The following are the steps I took, the
> errors I encountered, and how I resolved them.  As well as feedback to
> the experience.

Thank you for this feedback!

I recently installed the Nix service myself, and ran into these rough
edges, but I didn't think to write them down or fix things. Thank you
for the clear and detailed prompt to do so.

I've just sent a patch to guix-patches with some updates to the manual
which attempts to add the pieces that you found were missing. Could you
have a look at that and make sure you're happy with what I've written?

> At this point, I started encountering problems.  The command
> "nix-channel --update" returns:
>
> unpacking channels...
> error: opening pseudoterminal master: No such device
> error: program
> '/gnu/store/mh2nc81cvw321q0lx4y38g4n7b86q88y-nix-2.16.1/bin/nix-env'
> failed with exit code 1
>
> This was easy to fix because I had found this solution[1]
>
> sudo herd restart nix-daemon

I didn't mention this in the manual, because this seems more like a bug
that should be fixed. I've also had the same issue, so I'll try to
investigate the next time it happens to see if I can fix it.

> I initially attempted this within a VM ($(guix system vm nix.scm) -m
> 4096 -smp 2) that had 4 GiB of memory and 2 cores.  The process was
> terminated. Is it normal for Nix to require such a large amount of
> resources to install a package?

I wouldn't expect it to need that much, unless it was needing to build
things from source. Usually Nix's substitute coverage is pretty good, so
I wouldn't expect you to need to build much from source.

Carlo

Re: Guix Days: Patch flow discussion

[Tomas Volf]

On 2024-02-06 13:09:15 +0100, Clément Lassieur wrote:
> Hi!  Why is it more complicated with services?  You don't need forks at
> all to use packages and services outside of Guix proper.

For packages we have transformations, or I can just inherit.  But I am not aware
of such option for services (is there anything?).

Example: For long time the connman-configuration did not support a way to
provide a configuration file (well, it still does not but that is not the
point).  But I needed it.  So, what options I had?

1. Copy the definition (-configuration, -service-type, ...?) into my
   system configuration and modify it.
2. Modify it in-place in my fork.

I tried 1. first, but keeping it up-to-date proved annoying, having zero support
from git.  Since I already made my fork (due to #65002, which just is not
possible to do outside Guix repository), I later switched to 2. and it worked
well, so I prefer that approach now.

I agree there is no issue for new packages nor new services, I should have
clarified that in my original message.

Have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

Re: On the road to the next release: testing the installer

[Tanguy LE CARROUR]

Quoting Tanguy LE CARROUR (2024-02-06 08:31:39)
> In order to test the latest installer, I went to the "latest download"
> page [1] and clicked on "x86_64-linux" under "GNU Guix System on Linux"
> and ended up on an error page [2]:
> […]
> Is it the ISO that has to be tested? How can I download it?

I guess that part of the answer to my question is "build it yourself" [1], 
right?!

[1]: 
https://guix.gnu.org/en/manual/devel/en/html_node/Building-the-Installation-Image.html

Regards.

-- 
Tanguy

Re: Intermediate abstraction of system service configuration

[Carlo Zancanaro]

Hi Dale!

On Tue, Feb 06 2024, Dale Mellor wrote:
>There is no middle ground.

The nginx{,-upstream,-server}-configuration records have fields for
{extra,raw}-content, which do allow arbitrary configuration lines to be
added to their config. I think this is a sensible escape hatch to have
to provide this middle ground.

Andrew Tropin has done something interesting on the idea of more
free-form configuration for nginx specifically[1], but I don't think
that idea has found its way out of rde and into Guix yet.

>   I think that Guix taking the view of a configuration
> file as a nested set of string-named blocks containing
> lists of string-named, string-valued pairs would be an
> intermediate level of abstraction more suited to the
> Guix system configuration view of the world.

This sounds quite similar to the way that Nix represents their internal
configuration. Their model of configuring services is to have "Attribute
Sets" (i.e. key/value mappings) which specify the configuration of
services. Nix doesn't have service extension in the same way as Guix
does, however, so interactions between different services look very
different. We'd have to think carefully about how the Guix model of
service extension would work with such an intermediate representation.

Carlo

[1]: https://fosstodon.org/@abcdw/110180191828598277

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Tue, Feb 06 2024, Tomas Volf wrote:

> On 2024-02-05 23:08:29 +0100, Wilko Meyer wrote:
>> Guix offers ways to use packages outside of Guix proper in a pretty feasible
>> and maintainable way (manifests, setting up channels), maybe promoting them 
>> as
>> an alternative to having things in guix proper "as soon as possible" (as
>> that's not the only option to have things in a usable form) would be
>> beneficial.
>
> I would just like to point out that while this applies to packages, it is bit
> more complicated for services and other core parts of the Guix.  Combined with
> the fact that Guix severely restricts what workflow model can forks use (e.g.
> merge not being possible if the fork should be authenticated), maintaining
> non-package modifications for longer periods of time can be a hassle.

Hi!  Why is it more complicated with services?  You don't need forks at
all to use packages and services outside of Guix proper.

Re: Guix Days: Patch flow discussion

[Tomas Volf]

On 2024-02-05 23:08:29 +0100, Wilko Meyer wrote:
> Guix offers ways to use packages outside of Guix proper in a pretty feasible
> and maintainable way (manifests, setting up channels), maybe promoting them as
> an alternative to having things in guix proper "as soon as possible" (as
> that's not the only option to have things in a usable form) would be
> beneficial.

I would just like to point out that while this applies to packages, it is bit
more complicated for services and other core parts of the Guix.  Combined with
the fact that Guix severely restricts what workflow model can forks use (e.g.
merge not being possible if the fork should be authenticated), maintaining
non-package modifications for longer periods of time can be a hassle.

So it could be beneficial to put some though into that as well.

Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

Re: Guix Days: Patch flow discussion

[Josselin Poiret]

Hi Sunhail,

Your mailing system is sending out emails that contain an invalid
Message-ID header (missing right part of the msgid as specified in [1]),
which causes erratic behavior from other participants (the gmail smtp
servers for example just rewrite the message id to indicate it is
malformed, breaking the reply chain).  Could you please fix this?

This is quite on-topic in a discussion about the mail-based workflow :)

[1] https://datatracker.ietf.org/doc/html/rfc2822#section-3.6.4

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: Guix Days: Patch flow discussion

[Josselin Poiret]

Hi Hartmut,

Hartmut Goebel  writes:

> Anyhow, all of this has been discussed several times already. And as 
> long as vocal (and active :-) members of the community insist on being 
> able to work via e-mail — while also not adopting modern e-mail-capable 
> forges — this situation will not change.

While I agree with your assessment of what's missing in this workflow,
I'm not sure I know of any e-mail-capable forges that resolve those
particular pain points…  People often think that eg. sr.ht works better
for this, but I don't think the sr.ht MLs have any more structure than
what we have.  For smaller projects, it works okay, but once you get to
the scale of something like Guix, it doesn't offer anything more.

One thing I would like to get rid of though is debbugs.  It causes a lot
of pain for everyone, eg. when sending patchsets, it completely breaks
modern email because it insists on rewriting DMARC-protected headers,
thus needing to also rewrite "From:" to avoid DMARC errors.

I've been following the Linux kernel development a bit closer this past
year, and while there are things that need to improve (like knowing the
status of a patchset in a maintainer's tree), they at least have a lot
of tools that I think we should adopt more broadly:

b4/lei is a nice example (we already have yhetil.org as a back-end, but
maybe a more blessed one would be better) of a tool that lets you
completely automate applying a patchset to a branch.

patchwork is a nice tool to gather up and track patchsets, with status
indicators like "under review", "accepted", etc.  Chris already deploys
one as part of QA, more integration with it would be nice.

One advantage of this is that we would benefit from upstream's bigger
user-base and dev time, and also from the fact that these tools are made
to work together (b4 can automatically mark patchsets as accepted)!

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: guix installation why internet connection required?

[Josselin Poiret]

Hi Giovanni,

Giovanni Biscuolo  writes:

> Sorry I don't understand the problem, could you expand please?
>
> The guix (and daemon) versione are those of the channel used when
> creating the install .iso image; booting the 1.40 installer we get a
> "guix version" and "guix describe" value of 989a391...

Not exactly, to include Guix inside the installer image, it somehow
needs to refer to itself.  The way it used to be done was by using the
`guix` package, which necessarily is older than the current commit.
However, we also implemented the `current-guix` hack that basically uses
a guix checkout at the current guix version as the source for the guix
package.  In both cases though, we shouldn't see any differences in
other package's derivations…

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: Collecting Guix talks at FOSDEM

[Tanguy LE CARROUR]

Hi Steve,


Quoting Steve George (2024-02-06 11:17:42)
> Ludo said they put them into this repo:
> 
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2024
> 
> Do you have access to this? (I do not).

No. I mean, I can read it, but that’s it.

> We can ask people on the channel / this list to put their notes - or 
> integrate their notes into the existing ones there (as it's a shared 
> endeavour).
> 
> Does that work?

+1!

Mine will require a lot of "integration", though! 

-- 
Tanguy

Re: Collecting Guix talks at FOSDEM

[Steve George]

Hi Tanguy,

On 06/02/2024 08:19, Tanguy LE CARROUR wrote:
(...)

Quoting Pjotr Prins (2024-02-06 08:39:25)

It would also be nice to write a BLOG about what was discussed at Guix
days


I have notes about what sessions took place during the Guix days.
I was planning to send (tomorrow?) a patch for the Guix Foundation website
to make it available, like "GNU Guix Days FOSDEM 2023" [1].

[1]: https://foundation.guix.info/events/index.html

I don’t know if it’s the right place to put notes about the content,
though? 樂


Ludo said they put them into this repo:

https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2024

Do you have access to this? (I do not).

We can ask people on the channel / this list to put their notes - or 
integrate their notes into the existing ones there (as it's a shared 
endeavour).


Does that work?

Steve

Re: Collecting Guix talks at FOSDEM

[Steve George]

Hi,

Sounds good.

A blog post for the main Guix web site, with links to the detailed notes 
that were collected.


Ludo told me the raw notes are being collected here:

https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2024

Thanks,

Steve

On 06/02/2024 07:39, Pjotr Prins wrote:

Hi Steve,

It would also be nice to write a BLOG about what was discussed at Guix
days and FOSDEM. That way we get a historical record. If you take the
lead we can collect the notes that were made and write a concise
overview of each discussion. I am sure people are happy to help. That
an idea?

Pj.

On Tue, Jan 16, 2024 at 03:35:17PM +, Steve George wrote:

Hi all,

We're planning to put up a blog post about Guix (and Guix-related) talks at
FOSDEM [0]. I've collected all the talks that that are about Guix (or
connected areas). If I've missed any Guix related talks please tell me so I
can add them to the blog post:

- Declarative and Minimalist Computing track
-

This track [1] has:

- RISC‐V Bootstrapping in Guix and Live‐Bootstrap
 - Ekiatz Zárraga
 - Sunday: 11:20 - 11:40
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-1755-risc-v-bootstrapping-in-guix-and-live-bootstrap/

- Self-hosting and autonomy using guix-forge
 - Arun IsaaC
 - Sunday: 11:40 - 12:00
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2560-self-hosting-and-autonomy-using-guix-forge/

- Spritely, Guile, Guix: a unified vision for user security
 - Christine Lemmer-Webber
 - Sunday: 12:00 - 12:25
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2331-spritely-guile-guix-a-unified-vision-for-user-security/


Other tracks
-

- Making reproducible and publishable large-scale HPC experiments
 - Philippe SWARTVAGHER
 - Saturday: 10:30 - 11:00
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2651-making-reproducible-and-publishable-large-scale-hpc-experiments
/

- Supporting architecture psABIs with GNU Guix.
 - Efraim Flashner
 - Sunday: 14:30 - 14:55
  - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2927-supporting-architecture-psabis-with-gnu-guix/


Connected 'Guile/Scheme' interest
--

- Scheme in the Browser with Guile Hoot and WebAssembly
 - Robin Templeton
 - Sunday: 11:00-11:20
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2339-scheme-in-the-browser-with-guile-hoot-and-webassembly/

Thanks,

Steve

[0] Ludo's post from last year:
https://guix.gnu.org/en/blog/2023/meet-guix-at-fosdem-2023/
[1] 
https://fosdem.org/2024/schedule/track/declarative-and-minimalistic-computing/

Re: Collecting Guix talks at FOSDEM

[Tanguy LE CARROUR]

Quoting Pjotr Prins (2024-02-06 09:48:42)
> On Tue, Feb 06, 2024 at 09:19:15AM +0100, Tanguy LE CARROUR wrote:
> > I have notes about what sessions took place during the Guix days.
> […]
> That is great. We can link out to notes hosted elsewhere.

**SPOILER ALERT** … WIP!

```markdown
# Guix Days 2024

ICAB, february 1st and 2nd

## Day 1

33 persons present on the event’s opening, including newbies and Nix people.

Main track:

- [Introduction to Goblins by Christine from Spritely 
institute](day1/introduction_to_goblins.md)
- [Status of Guix by Efraim](day1/status_of_guix.md)
- Guix QA update by Chris

Sessions:

- Gobelin (Christine)
- Infrastructure (Alexis)
- Documentation (Julien)
- [Guix Home](day1/guix_home.md) (Gabor)
- Alt. Arch. (Efraim)
- [Bootstrapping](day1/bootstrapping.md) (Janneke)
- Release (Julien)


## Day 2

Sessions:

- Funding (Christine)
- Governance/Maintainers (Efraim + Chris)
- Patch flow (Steeve)
- CLI (Jonathan)
- Profiling (Adriel)
- Hurd (Janneke)
- L10N (Julien)
- Hoot (Christine)
- Newbie room (Gabor)
- Onboarding (Gabor)


## Ideas that didn’t make it to sessions

- Shepherd
- HPC
```

-- 
Tanguy

Re: Collecting Guix talks at FOSDEM

[Pjotr Prins]

On Tue, Feb 06, 2024 at 09:19:15AM +0100, Tanguy LE CARROUR wrote:
> Hi Pjotr,
> 
> 
> Quoting Pjotr Prins (2024-02-06 08:39:25)
> > It would also be nice to write a BLOG about what was discussed at Guix
> > days
> 
> I have notes about what sessions took place during the Guix days.
> I was planning to send (tomorrow?) a patch for the Guix Foundation website
> to make it available, like "GNU Guix Days FOSDEM 2023" [1].
> 
> [1]: https://foundation.guix.info/events/index.html
> 
> I don’t know if it’s the right place to put notes about the content,
> though?

That is great. We can link out to notes hosted elsewhere.

Re: GNU Hurd at Guix days

[Tanguy LE CARROUR]

Hi Pjotr,


Quoting pjotr.publi...@thebird.nl (2024-02-06 08:48:56)
> We had a very interesting discussion about the Hurd.

Very interesting, indeed! 10+ persons in a room talking about Hurd!
I guess that hadn’t happened in a long time! 

On my side, I decided to start patching broken packages… again! [1]

[1]: https://www.gnu.org/software//hurd/user/tlecarrour.html

First thing yesterday morning, I set up a ChildHurd and try to offload
build to it and… it worked! 

Unfortunately, the default image seems to be to small to build "real"
packages. I increased it, but… then my real disk was suddenly too small!
This is a problem that came up multiple times while discussing with
Simon… so I decided to upgrade my disk… and I now have to re-install
—I miserably failed my attempt at cross-installing and ended up with a
brick! —, so I thought "why not use the latest installer?" [2].

[2]: https://lists.gnu.org/archive/html/guix-devel/2024-02/msg00068.html

I also have to figure out what’s the proper way to hack with this set up.
Probably a mixture of `build --system`, `build --source`, `diff -purN`,
`--with-patch=`…
So, I guess, you’ll hear from me soon! 

Regards,

-- 
Tanguy

Re: Collecting Guix talks at FOSDEM

[Tanguy LE CARROUR]

Hi Pjotr,


Quoting Pjotr Prins (2024-02-06 08:39:25)
> It would also be nice to write a BLOG about what was discussed at Guix
> days

I have notes about what sessions took place during the Guix days.
I was planning to send (tomorrow?) a patch for the Guix Foundation website
to make it available, like "GNU Guix Days FOSDEM 2023" [1].

[1]: https://foundation.guix.info/events/index.html

I don’t know if it’s the right place to put notes about the content,
though? 樂

-- 
Tanguy