Re: Need people to help with kernel updates

[wolf]

On 2023-10-10 07:18:23 -0400, Leo Famulari wrote:
> On Mon, Oct 9, 2023, at 12:21, Wilko Meyer wrote:
> > I've seen the recent thread on making linux-libre
> > 6.5 the default kernel[0] and will have some time at hand later on
> > today. I could try to prepare a patch set doing this to get more
> > familiar with the process, which would then need a review. WDYT?
> 
> There's actually a patch for this already:
> 
> https://issues.guix.gnu.org/66409
> 
> But it seems to have failed the QA process:
> 
> https://qa.guix.gnu.org/issue/66409
> 
> Are you able to try applying the patch on the master branch and reporting 
> back?

The patch applies cleanly:

$ g am ~/Downloads/66409-0.mbox
Applying: gnu: linux-libre: Update to 6.5.6.
$ g l -2 --oneline --no-decorate 
a2f741df37 gnu: linux-libre: Update to 6.5.6.
f4e8baf380 gnu: nyxt: Update to 3.9.0.

> I figure that double-checking that it applies is the first to figuring out
> what's gone wrong.

Locally it builds well, verified by running:

$ guix shell -D guix -- ./pre-inst-env guix build linux-libre

The failure did happen in building derivation of guix-cli, and it was due to a
segmentation fault:

[ 32/ 50] compiling...   28.0% of 25 filesbuilder for 
`/gnu/store/sg8bhb53kam17997prnnrx4hyr17rqjq-guix-cli.drv' failed due to signal 
11 (Segmentation fault)
@ build-failed /gnu/store/sg8bhb53kam17997prnnrx4hyr17rqjq-guix-cli.drv - 1 
builder for `/gnu/store/sg8bhb53kam17997prnnrx4hyr17rqjq-guix-cli.drv' failed 
due to signal 11 (Segmentation fault)
cannot build derivation 
`/gnu/store/jphsmd16inbhq6mbbc4mi6kn1ri0g1hi-guix-cli-modules.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/zvd7snhdmklhk0rh93g4ln07kqdj13i8-guix-system-tests.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/7x6hhikczg937596kbkm139jq0q00c75-guix-ea4dc87ac-modules.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/hqr1jwlkp525nlr4my051gjphbg0b04z-guix-ea4dc87ac.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/vfzs38yiiqr6acwsm74rhcqvky2ayl1c-profile.drv': 1 dependencies 
couldn't be built
error: load-new-guix-revision: %exception (#< message: 
"build of `/gnu/store/vfzs38yiiqr6acwsm74rhcqvky2ayl1c-profile.drv' failed" 
status: 100>)

Backtrace:
  19 (primitive-load 
"/gnu/store/nwd4fqjp31mcch4r7cx1wnnhjccq94xj-guix-data-service-0.0.1-git.893cccf/bin/.guix-data-service-process-job-real")
In ice-9/boot-9.scm:
  1752:10 18 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix-data-service/database.scm:
   181:14 17 (_)
In guix-data-service/jobs/load-new-guix-revision.scm:
  2177:13 16 (_ #)
In guix-data-service/utils.scm:
61:17 15 (call-with-time-logging "processing revision 
ea4dc87ac1c7913111d491433543f8a67bf778dc" _)
In ice-9/boot-9.scm:
  1752:10 14 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix-data-service/database.scm:
   181:14 13 (_)
In guix-data-service/jobs/load-new-guix-revision.scm:
  2133:24 12 (_ #)
In ice-9/boot-9.scm:
  1747:15 11 (with-exception-handler # _ #:unwind? _ #:unwind-for-type _)
  1752:10 10 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
  1752:10  9 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/store.scm:
   659:37  8 (thunk)
In guix-data-service/jobs/load-new-guix-revision.scm:
  1724:11  7 (load-new-guix-revision # 
# "1" 
"ea4dc87ac1c7913111d491433543f8a67bf778dc" #:skip-system-tests? _)
  1409:10  6 (channel-derivations-by-system->guix-store-item _ _)
In guix-data-service/utils.scm:
61:17  5 (call-with-time-logging "building the channel derivation" _)
In guix/store.scm:
  1417:15  4 (_ # _ _)
In ice-9/boot-9.scm:
  1685:16  3 (raise-exception _ #:continuable? _)
  1685:16  2 (raise-exception _ #:continuable? _)
  1780:13  1 (_ #< message: "build of 
`/gnu/store/vfzs38yiiqr6acwsm74rhcqvky2ayl1c-profile.drv' failed" status: 100>)
In unknown file:
   0 (backtrace #)

I do not know enough yet to debug further.

> 
> On CI, at least the 6.5.6 kernel package was built:
> 
> http://ci.guix.gnu.org/eval/831643
>

W.

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


signature.asc
Description: PGP signature

Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[wolf]

On 2023-09-12 08:56:15 -0400, Maxim Cournoyer wrote:
> Hi,
> 
> Josselin Poiret  writes:
> 
> > Hi,
> >
> > Maxim Cournoyer  writes:
> >
> >> That's no longer true, as of libgit2 v1.7.0 [0].  I already have it
> >> packaged in a branch, but I need to iron out dependent breakages.
> >>
> >> [0]  https://github.com/libgit2/libgit2/releases/tag/v1.7.0
> >>
> >> So given there's no technical reasons not to use libgit2, I'd use that
> >> and keep the closure size down.
> >
> > There's still the `git gc` problem though.
> 
> It's klunky, but a workaround is to locally clone the checkout anew using
> libgit2, as suggested here [0].

While the comment does suggest a workaround, I would recommend to read the
comment right below it before using it.  I am not sure if Guix would be affected
by those mentioned concurrency issues, but sounds like something that needs to
be understood in detail.

> We could also try to contribute to libgit2 toward adding proper support for a
> 'gc' action.
> 
> [0]  https://github.com/libgit2/libgit2/issues/3247#issuecomment-486585944
> 
> -- 
> Thanks,
> Maxim
> 

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


signature.asc
Description: PGP signature

Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[wolf]

On 2023-09-11 17:17:24 +0200, Simon Tournier wrote:
> Hi,
> 
> On Mon, 11 Sep 2023 at 16:23, Ludovic Courtès  wrote:
> 
> > Note that the patch series adds a hard dependency on Git.
> > This is because the existing ‘git-fetch’ code depends on Git,
> > which is itself motivated by the fact that Git supports
> > shallow clones and libgit2/Guile-Git doesn’t.
> 
> Going this path, I appears to me worth to revisit the proposal:
> 
> RFC: libgit2 is slow/inefficient; switch to git command?
> Maxim Cournoyer 
> Mon, 21 Nov 2022 21:21:02 -0500
> id:87cz9fpw4x@gmail.com
> https://yhetil.org/guix/87cz9fpw4x@gmail.com
> https://lists.gnu.org/archive/html/guix-devel/2022-11
> 
> I know it is not an option for now to parse the output of ’git’ commands
> in order to keep the features of (guix git), (guix channels), etc.
> 
> However, this discussion was mentioning an implementation of
> clone/checkout in pure Racket supporting shallow checkout.  Considering
> the current level of integration, I thought the next Big Plan™ was to
> gradually move bits of Guile-Git to being pure Scheme, maybe based on
> the Racket implementation of ’clone’ as a starting point.
> 
> Personally, I do not have a strong opinion about the Big Plan™.  I note
> that the introduction of Git as a hard dependency is a slippery slope
> considering the current state of libgit2.  Here, it starts with “git
> clone”, then “git gc” (unsupported by libgit2) is also in the pipes
> (#65720 [1]).  And after timing, I am almost sure that many operations
> using Guile-Git will be slower than their plain Git counter-parts.  And
> we will start to parse the output of ’git’ plumbing commands.

If you don't mind me asking, why is that so problematic approach?  Git's
plumbing commands are intended to be used in scripts, so I am unsure what the
problem is.

I cannot recall a single instance when some tooling I have at home or wrote for
work stopped working due to git changing.  I guess there likely are such
instances, but would be interested in examples if someone has a list.

> Slippery slope for pushing Guile-Git out, no?

Guile-git does not seem to be in the best place currently, when I was putting
together the script I sent to #65720, I tried to use the info manual, and the
best way to describe it is "incomplete".  Some behaviors are... surprising.

Arguably that is the impression I got based on one morning of trying to use it,
so it is probably inaccurate description and lacks some details.

> 
> And I do not speak about the closure.  Is it possible to extract the
> command ’git-clone’ from git-minimal?  It would reduce the size, no?
> 
> 
> Cheers,
> simon
> 
> 1: https://issues.guix.gnu.org/65720
> 

-- 
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 build from git failure: missing sections in German, French, etc. doc translations？

[wolf]

On 2023-09-08 21:26:56 +0200, Julien Lepiller wrote:
> Hi Andy,
> 
> Thanks for the report! You might need a more recent po4a for it to work 
> properly. Could try to guix pull, and enter a new shell for building guix?
> 
> Le 8 septembre 2023 20:43:05 GMT+02:00, Andy Tai  a écrit :
> >Checking out the latest origin/master head, building guix fails:
> >
> >make[2]: Entering directory '/share/software/guix/guix.git/po/packages'
> >make[2]: Nothing to be done for 'all'.
> >make[2]: Leaving directory '/share/software/guix/guix.git/po/packages'
> >make[2]: Entering directory '/share/software/guix/guix.git'
> >  MAKEINFO doc/guix.info
> >  MAKEINFO doc/guix.de.info
> >  MAKEINFO doc/guix.fr.info
> >  MAKEINFO doc/guix.es.info
> >  MAKEINFO doc/guix.pt_BR.info
> >contributing.pt_BR.texi:1338: @menu reference to nonexistent node
> >`Configuring Git'
> >contributing.pt_BR.texi:1339: @menu reference to nonexistent node
> >`Sending a Patch Series'
> >contributing.de.texi:1447: @menu reference to nonexistent node `Configuring 
> >Git'
> >contributing.de.texi:1448: @menu reference to nonexistent node
> >`Sending a Patch Series'
> >contributing.fr.texi:1389: @menu reference to nonexistent node `Configuring 
> >Git'
> >contributing.fr.texi:1390: @menu reference to nonexistent node
> >`Sending a Patch Series'
> >make[2]: *** [Makefile:4969: doc/guix.de.info] Error 1
> >make[2]: *** Waiting for unfinished jobs
> >make[2]: *** [Makefile:5099: doc/guix.fr.info] Error 1
> >make[2]: *** [Makefile:5164: doc/guix.pt_BR.info] Error 1
> >
> >
> >the script I used to build guix from git is attached
>

FWIW I did run into the same problem this morning and can confirm, guix pull
does resolve the issue.

W.

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


signature.asc
Description: PGP signature

Re: Building from git

[wolf]

On 2023-09-08 11:47:56 +0200, Wojtek Kosior wrote:
> Hello Josselin
> 
> > wolf  writes:
> > 
> > > Hmm, but the recipe for the authenticate rule comes from the (possibly)
> > > compromised source, no?  So the attacker can just modify the recipe 
> > > instead of
> > > the command going the authentication.  Am I missing something?  
> > 
> > You can use a previously trusted guix to do the authentication.  `make
> > authenticate` is here for committers to check that their commits are all
> > properly signed before pushing (it's used as a pre-push hook).
> 
> From my understanding of the documentation, `make authenticate` is not
> just for committers but for all people who do a `git pull` in Guix tree
> and want to verify that the newly pulled commits do come from the
> committers. It it is not the case, then the documentation should
> probably be modified to make it clear.
> 
> The recipe is not from an untrusted source mecause the Makefile is not
> tracked by git. Rather, it gets generated when first building Guix. And
> — as the documentation instructs — the initial checkout gets
> authenticated with `guix git authenticate` rather than with `make
> authenticate` so it can't get compromised that easily.
> 
> Had someone managed to serve us a commit that adds another Makefile
> with a backdoor, git would report a conflict upon pulling. I believe
> this is what the implementors had in mind. Please clarify if this is
> wrong.

Yes, I believe this reasoning is wrong.  Even ignoring the fact that people
might run git clean or use worktrees, you can just attack the Makefile.am.  I
created a new commit in my checkout:

commit b3b378ad8f725f16be0602113e7f2d2afd89a920 (HEAD -> master)
Author: x 
Date:   Fri Sep 8 11:04:44 2023 +

this commit is so not signed and valid

diff --git a/Makefile.am b/Makefile.am
index 922913355c..e5f7c37491 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -883,10 +883,7 @@ channel_intro_signer = BBB0 2DDF 2CEA F6A8 0D1D  E643 
A2A0 6DF2 A33A 54FA
 GUIX_GIT_KEYRING = origin/keyring
 authenticate:
$(AM_V_at)echo "Authenticating Git checkout..." ;   \
-   guix git authenticate   \
-   --keyring=$(GUIX_GIT_KEYRING)   \
-   --cache-key=channels/guix --stats   \
-   "$(channel_intro_commit)" "$(channel_intro_signer)"
+   echo "Don't worry, your checkout is just fine... :)"
 
 # Assuming Guix is already installed and the daemon is up and running, this
 # rule builds from $(srcdir), creating and building derivations.

guix git authenticate fails, as expected:

Authenticating commits 9edb3f6 to b3b378a (1 new commits)...

[##]guix
 git: error: commit b3b378ad8f725f16be0602113e7f2d2afd89a920 lacks a signature

The missing new line after ] is somewhat meh, but it correctly fails.  However
make authenticate does pass:

$ guix shell -D guix guix --pure -- make authenticate
 cd . && /bin/sh /home/wolf/src/guix/build-aux/missing automake-1.16 --gnu 
Makefile
Makefile.am:896: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS
 cd . && /bin/sh ./config.status Makefile depfiles
config.status: creating Makefile
config.status: executing depfiles commands
Authenticating Git checkout...
Don't worry, your checkout is just fine... :)

I mean, if make authenticate is just for the convenience of the committers, then
this is completely fine.  But the documentation does not currently read that
way.

> 
> I do see 1 loophole here, though. One could serve a compromised
> makefile under the name "GNUmakefile" and `make authenticate` would
> happily choose it over the non-compromised "Makefile". I was planning
> to start a new thread about it for some time... but this one seems like
> a just as appropriate place to mention the issue.
> 
> It shouldn't be hard to fix. It boils down to having ./configure create
> a GNUmakefile as well. Perhaps as a symlink to the original Makefile?
> 
> Best,
> Wojtek
> 
> -- (sig_start)
> website: https://koszko.org/koszko.html
> fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
> follow me on Fediverse: https://friendica.me/profile/koszko/profile
> 
> ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ 
> c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
> ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? 
> U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
> -- (sig_end)
> 
> 
> On Fri, 08 Sep 2023 11:10:37 +0200 Josselin Poiret  wrote:
> 
> > Hi,
> > 
> > wolf  writes:
> > 
> &g

Re: Building from git

[wolf]

On 2023-09-07 14:06:05 +0200, Simon Tournier wrote:
> Hi,
> 
> On Sat, 02 Sep 2023 at 11:03, Nicolas Débonnaire  
> wrote:
> 
> > guix shell -D guix --pure
> > ./bootstrap
> > ./configure --localstatedir=/var --syscondir=/etc
> > make
> 
> [...]
> 
> > Error: fontconfig:Didn't find expected font family. Perhaps URW Type 1
> > fonts need installing?
> 
> Hum, weird.  That’s because the documentation seems failing, I guess.
> 
> Could you share which Git commit you are building?  And using which Guix
> revision, before guix shell, what is the output of “guix describe“?
> 
> 
> 
> 
> > Then if I run make authenticate as stated in the documentation it
> > fails with the error: guix: command not found.
> 
> Yeah, I think that’s expected because ’make’ failed.  Quoting:
> 
> If anything fails, take a look at installation instructions (*note
> Installation::) or send a message to the mailing list
> .
> 
>From there on, you can authenticate all the commits included in 
> your
> checkout by running:
> 
>  make authenticate
> 
> However, hum maybe there is bug with that command on pure environment.
> The manual is maybe inaccurate.
> 
> The Makefile does not run ‘guix git authenticate’ using ./pre-inst-env.
> And that’s probably to ensure the source of trust.  If one corrupt the
> commit that is built, then ’make authenticate’ would authenticate the
> corruption because it would run the corrupted newly built guix command.
> Currently, ’make authenticate’ run one guix command that had already
> been authenticated.  Well, that’s my understanding.

Hmm, but the recipe for the authenticate rule comes from the (possibly)
compromised source, no?  So the attacker can just modify the recipe instead of
the command going the authentication.  Am I missing something?

> 
> 
> Cheers,
> simon
> 

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


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[wolf]

On 2023-09-05 16:01:17 +0200, Simon Tournier wrote:
> Hi Katherine,
> 
> Thank you for your extensive analysis.  I concur.
> 
> On Wed, 30 Aug 2023 at 10:11, Katherine Cox-Buday  
> wrote:
> 
> > 3. We should reify a way for Guix, the project, to measure, and track 
> > progress,
> >     against long-term goals. Particularly when they're social and not 
> > strictly
> >     technical.
> 
> That is the most difficult part, IMHO.  Well, what are the long-term
> goals? :-)
> 
> I am almost sure we will get various answers depending on people.  Let
> say the long-term goals of the Guix project are: Liberating, Dependable
> and Hackable.  Then how do you give concrete quantities that we can
> measure or track?
> 
> And it is always difficult, if not impossible, to measure or track some
> goals that are not technical but social.  For example, how do you
> measure being welcoming or being a safe place for all?
> 
> Do not take me wrong, I strongly think we must think again and again on
> that point for improving.  It’s just easier to tackle technical bug. :-)
> 
> 
> >    11. Try and get each commit message close to correct and commit.
> 
> > I view steps 1-10 as pretty standard "development" steps common to most
> > projects, although 11 compounds the effort in 10.
> 
> Maybe I am doing incorrectly but I have never thought much about that.
> 
> For that point #11, from my point of view, it is as with any other
> project.  I start by running “git log --grep=” for getting inspiration.
> 
> Well, as a rule of thumb, I am doing something like:
> 
> --8<---cut here---start->8---
> top-module: submodule: one line summary.
> 
> Fixes .
> Reported by Jane Doe 
> 
> * path/to/file.scm (variable):[sub-part]: Description of the change.
> [otherpart]: Other description.
> * path/to/other/file.scm (other-variable): Description.
> --8<---cut here---end--->8---
> 
> In case of doubt, I am just running “git log --grep=” looking for
> similar thing, as said. :-)
> 
> 
> >    12. Run `guix lint`
> >    13. Run `guix style` (this is still in the manual although I have since
> >    learned this is not actually advisable).
> >    14. Review the changes these tools have made, and fix things.
> >    15. Run `guix build --rounds=2 ` to check for idempotency.
> >    16. Run `make` to ensure you didn't break anything elsewhere in Guix.
> >    17. Run `guix size` to ensure the closure isn't becoming bloated.
> >    18. Build all the packages that depend on this package.
> >    19. Run `guix pull --url=/path/to/your/checkout 
> > --profile=/tmp/guix.master` to
> >    ensure you didn't break Guix in a different way.
> 
> > In other projects I've worked with, steps 12-19 are commonly done in a CI
> > pipeline, and courteous people will try to save CI resources by running 
> > these
> > steps locally first using some kind of environment identical to what CI runs
> > (sometimes a container is used for this. I think Guix has better options!).
> > Sometimes this is not feasible due to asymmetric resources. But having the
> > option to let CI manage this process is very nice.
> 
> For instance, I am not seeing “make check”. ;-)  And that omission makes
> very clear the cognitive overhead we are speaking about!

I personally am glad it is not there, since I never (in ~9 months toying with
Guix) had all the checks pass on the clear master.  There are always one or two
failing tests.

But I guess this was supposed to be taken as "run make check' and make sure
nothing new is broken".  Is there a command for that?

> 
> Here I see two annoyances:
> 
>  1. The number of subcommands and steps.
>  2. Each subcommand has a list of options to digest.
> 
> Well, CI is helpful here, for sure.  However, it would be helpful to
> have a script similar as etc/teams.scm or etc/committer.scm that would
> help to run all these steps.
> 
> It does not mean that all these steps need to be run before each
> submission.  However having a tool would help irregular contributors or
> newcomers; it would decrease the cognitive overhead i.e., that overhead
> would be pushed to some script and it would reinforce confidence.
> 
> Now someone™ needs to implement this script. ;-)
> 
> 
> >    20. Run `git format-patch -1 --cover-letter [--reroll-count]`
> >    21. Run `./pre-inst-env ./etc/teams.scm cc-members ` to get 
> > the CC flags for Git
> >    22. Remember that if you're sending multiple patches, an email first 
> > has to be
> >    sent to `guix-patc...@gnu.org` to get an ID, and then...
> >    23. Run `git send-email --to guix-patches  `
> 
> Well, my grey hair are biasing my opinion. ;-)  From my point of view,
> the most annoying is #22.
> 
> Vagrant suggested [1] to send patches as attachment.  I am not convinced
> it will be better.  Well, it will for submitting but will not for
> following series.  For instance, let consider:
> 
> 

Re: How can we decrease the cognitive overhead for contributors?

[wolf]

On 2023-09-05 22:43:04 +0200, Liliana Marie Prikler wrote:
> Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:
> > Liliana Marie Prikler  writes:
> > > Uhm, we have snippets?
> > 
> > Well, those are exclusive to Emacs :)  And without regard to /that/
> > issue, I do think that there's a problem if the commit format is so
> > complex that it's not trivial for anyone new to the project to write
> > them out manually.
> By definition, no amount of typing is non-trivial, safe for the empty
> amount, which good luck trying to commit your changes by pure mouse
> movements, I guess?
> 
> Now, if you excuse my French, I think the problem isn't really as much
> that people struggle to type out the perfect ChangeLog on the first
> try, which also makes it odd to request a linter.  Bear in mind that
> committers will sign off anything that appears convincing enough, even
> if there are smaller mistakes in the message.  Trust me, I've been
> there and seen that; and also done it myself.
> 
> Instead, we have seen in this thread appeals to age, appeals to
> perceived lack of personal benefit, and now appeals to typing effort,
> none of which really make that great of an argument against the
> ChangeLog style, especially when they come in combination with a
> refusal to make use of already provided tools.

I went through the snippets, and through the GNU documentation[0] and I am still
not clear on how exactly should the commit message for a change in
.dir-locals.el look like.  Maybe I did miss some tools or documentation?

The "you can check the commit history for example" advice from the 22.6 page of
documentations gives me 4 different styles in last 4 commits.  Ok, just joking,
3 styles, the 4th is a typo (`* .dir-localsl.el: Add ...').

0: https://www.gnu.org/prep/standards/html_node/Change-Logs.html

> I think we're starting to see the moving of the goal post as the actual game
> here. 
> 
> Maybe it's time to take a step back and instead of asking “How can we
> decrease the cognitive overhead for contributors?”, we should perhaps
> ask “For which contributors do we want to/can we decrease the cognitive
> overhead?”

While I do risk taking this slightly more off topic, I personally am more
interested in what can be done to help the committers, not contributors.  My
biggest grievance with trying to contribute is not the process nor the tools,
but the lack of reviews.  Having a patch sitting there without any reaction nor
feedback is frustrating.  Do you see any process/tooling changes that could help
on this front, even if they would make life harder for the contributors?

> We have drifted much from the original post that discussed moms with full-time
> jobs, who struggle to do “difficult” tasks (simplified wording; may change the
> meaning of the OP a little).  Now, I personally struggle to see how your
> personal preference for communication media, commit message style, and other
> things that were discussed in any of the preceding threads actually correlate
> with being a parent.  However, I do know that with its 150 million users, most
> people of the world don't have a Github account.  Being one of the 4 billion
> email users out there is a comparably low barrier of entry imho.  So, whose
> cognitive overhead do you want to reduce (besides the obvious "my own", which
> everyone always tries)?
>

W.

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


signature.asc
Description: PGP signature

Re: Pinned/fixed versions should be a requirement.

[wolf]

On 2023-09-04 21:59:47 -0500, Distopico wrote:
> 
> In my experience using Guix and attempting to make contributions, I've
> noticed that the vast majority of times when a library breaks, it's
> because one of its dependencies changed version. For instance,
> referencing something like `rust-my-lib-1`, where "1" refers to the
> semver "1.x" of the package, e.g., "1.0.32", and `rust-foo` depends on
> `rust-my-lib == 1.0.32`. However, in some other package got updated to
> "1.0.34" so `rust-foo` will break. I've seen this happen a lot with
> Haskell and Rust libraries.
> 
> Many libraries in different languages don't follow semver, which can
> lead to cases like `rust-serde-json`, which, between versions "1.0.97"
> and "1.0.98," changed its dependency from `indexmap` "1.x" to "2.x,"
> causing several packages like rust-analyzer to break. I've also observed
> this in Haskell with packages like "text."
> 
> This is problematic because:
> 
> - Over time, it becomes more vulnerable to libraries/packages
>   breaking.
> 
> - It makes reproducible software more challenging, as "1.x" can
>   encompass many versions.
> 
> - Debugging becomes difficult since that package could be a deep
>   dependency in the system package dependency chain, such as
>   Rust/Haskell/NPM, etc.
> 
> - It makes it more likely that if a dependency changes, many
>   packages will need to be updated/rebuilt due to that change.
> 
> For these reasons, I believe that pinned versions should be a
> requirement in libraries, always specifying the exact dependency, for
> example, `rust-serde-json-1.0.98`.
> 
> This brings the following benefits:
> 
> - Fewer packages will be prone to rebuilding when changing the
>   definition of a library.
> 
> - Reduced likelihood of libraries/packages breaking.
> 
> - Easier maintenance of packages and libraries without fear of
>   breaking others or having to update many.
> 
> There could be some potential disadvantages:
> 
> - The list of library versions may grow larger, making it harder to
>   detect orphaned or unused versions.

I was recently thinking about this, and I think this should be solvable by
introducing a boolean flag (auto-dependency?) to the package definition stating
whether the package was added intentionally, or just as an auto-imported
dependency.  The importer (when running as -r) would set it to #t for all except
the top-level package.

After that we could have a clean up script that would delete all packages that
have this flag set to #t and are not referenced from any packages that have the
flag set to #f.  That should ensure that the list of packages does get cleaned
up eventually.

> 
> Additionally, I believe that a command to list the dependency tree of a
> package would be ideal for easier debugging.
> 
> Regards!

W.

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


signature.asc
Description: PGP signature

Re: questionable advice about Geiser load path setting

[wolf]

On 2023-09-04 21:41:44 -0400, Maxim Cournoyer wrote:
> Hello,
> 
> wolf  writes:
> 
> [...]
> 
> > Geiser seems to add the project root (I assume based on the git) into the 
> > load
> > path automatically.  geiser-repl-current-project-function seems to be set by
> > default, and rest is described in the docs: (geiser)Customization and tips, 
> > Init
> > files and load paths.
> >
> > Maybe it once was necessary to set this, I am not sure it still is the case.
> >
> > I also use (setq geiser-repl-per-project-p t) and everything seems to just 
> > work
> > out of the box.
> 
> I haven't followed up with the latest Geiser features, but if what you
> wrote is true, then it would be nice to streamline our .dir-locals.el
> and simply set geiser-repl-per-project-p to t (as a directory-local
> variable).
> 
> Would you like to see if that continues working the same, across
> e.g. Git worktrees of Guix checkouts?

Seems to work as one would expect.  My Guix checkout is in /home/wolf/src/guix,
those in /tmp are worktrees.  I pressed C-c C-z in each of these files, a new
REPL was spawned for each of them.  After that I evaluated the snippet to verify
the paths.

/home/wolf/src/guix/gnu/packages/linux.scm:

(values (car %load-path) (car %load-compiled-path))
$8 = "/home/wolf/src/guix"
$9 = "/home/wolf/src/guix"

/tmp/guix-a/gnu/packages/linux.scm:

(values (car %load-path) (car %load-compiled-path))
$5 = "/tmp/guix-a"
$6 = "/tmp/guix-a"

/tmp/guix-b/gnu/packages/linux.scm:

(values (car %load-path) (car %load-compiled-path))
$5 = "/tmp/guix-b"
$6 = "/tmp/guix-b"

C-c C-z in /tmp/guix-b/gnu/packages/abduco.scm reused the already running REPL
for the guix-b.

> 
> -- 
> Thanks,
> Maxim
>

W.

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


signature.asc
Description: PGP signature

Re: How can we decrease the cognitive overhead for contributors?

[wolf]

On 2023-09-02 21:08:12 +0200, Csepp wrote:
> 
> paul  writes:
> 
> > Hello Giovanni,
> >
> > I get that you really don't find the web based workflow to bring enough 
> > advantages to justify the migration, but first please consider the picture 
> > that
> > Katherine sent and that we are evaluating the adequateness of the email 
> > medium as a FOSS contribution management tool over email. 
> >
> > If we lower the bar for contributions more people are gonna be invested in 
> > Guix and will have interest in becoming committer and reviewer. My
> > impression today is not that there aren't enough resources to cover 
> > reviews, the bottleneck is the total time that committers are able to 
> > dedicate to
> > reviewing (potentially re-reviewing if some other non-committer contributor 
> > has already done a first review) and actually commiting changes.
> >
> > I have many contributions opened more than a year ago where (sometimes also 
> > because of me obviously, we're all working after work here) the
> > interactions on the issue are separated by many weeks, sometimes even 
> > months.
> >
> > To ease that bottleneck we just need to give more time to committers or to 
> > increase the number of committers. All the automation and process changes
> > we evaluate should be focused on either one of this two goals. I don't have 
> > evidence that any web forge will help (maybe someone has?), but I wouldn't
> > throw it out of the window just because it does not ease the current review 
> > process.
> >
> > cheers
> >
> > giacomo
> 
> To second this, I'd like to note for the record that on fedi at least
> 1-2 people told me that they chose Nix over Guix because they don't want
> to deal with the email based workflow.  At least one of these people is
> a highly skilled programmer with decades of experience.

Since we are collecting anecdotal data here, I pretty much stopped contributing
to Alpine after they stopped using the mailing list.  The friction (for me)
increased a lot compared to just calling git send-email.

From my circle of acquaintances, all people who picked Nix did it because they
did not like Guix' purism regarding software freedom and wanted something that
"gets the job done".

I am skeptical regarding people picking based on web vs. email flows, there are
more important differences.

> 
> While I mostly argued for Sourcehut, I think the pull-based alternatives
> should also be kept in mind.
> 

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


signature.asc
Description: PGP signature

Re: Updates for Go

[wolf]

On 2023-08-22 13:14:05 +, Attila Lendvai wrote:
> > each package for those two to work properly. Also, while having pinned
> > versions of dependencies upstream seems like the consensus, I'm not sure
> > we'd like doing that, be it for the exponential CI work that would be
> > required.
> 
> 
> not arguing either way, FWIW:
> 
> - rumour has it that golang compiles very fast, and

Usually people claiming this assume there is already a compiler cache present.
The compiler heavily caches the work done.

Sure, golang compiles faster than C++ for example, but anecdotal data point: at
$DAYJOB we had to start persisting the compiler cache to make CI fast enough.

> 
> - IIUC currently the go build system in guix does not reuse build artifacts, 
> i.e. it recompiles everything for each leaf package.
> 
> -- 
> • attila lendvai
> • PGP: 963F 5D5F 45C7 DFCD 0A39
> --
> “What you do speaks so loud I cannot hear what you say.”
>   — Ralph Waldo Emerson (1803–1882)
> 
> 

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


signature.asc
Description: PGP signature

Re: Relaxing the restrictions for store item names

[wolf]

On 2023-08-24 12:21:24 +0200, Julien Lepiller wrote:
> Le 24 août 2023 10:41:23 GMT+02:00, Msavoritias  a 
> écrit :
> >
> >What I am saying here is that:
> >Its easy to see from our very US centric tech culture why everybody
> >should just use ASCII because "This is how it is". But there is very
> >little reasons why we shouldn't strive to be more inclusive of all
> >cultures.
> >Especially since nowadays where we have tools like Unicode that make our
> >lives easier compared to US or nothing of 30-40 years ago.
> >Just imagine how many good programmers we are missing because they don't
> >want/can't learn English or don't have an ASCII keyboard.
> >
> >MSavoritias
> >
> >MSavoritias  writes:
> >
> >> Nguyễn Gia Phong  writes:
> >>
> >>> [[PGP Signed Part:Undecided]]
> >>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>  Nguyễn Gia Phong  writes:
>  > I think the distinction must be made here between Guix and GuixSD.
>  >
>  > The packaging software should support full localization,
>  > but the distro should target the least common denominator.
> 
>  Depends what do we mean the "distro" here.
>  If I can pick arabic or chinese in the installation as a display
>  language and also I am able to use an arabic/chinese keyboard sounds
>  good to me.
> >>>
> >>> I meant GuixSD.  I agree a distribution based on Guix Systems
> >>> shouldn't meet any obstacle declaring packages with non-ASCII names.
> >>> That you can type arabic and chinese and I can type hangul
> >>> and most latin characters doesn't mean names having all of the above
> >>> will be accessible to either of us or a third person.
> >>>
> >>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>  Regarding the initial question it was about package names to my
>  understanding. Specifically package names in the store to use unicode
>  characters. Which makes perfect sense there because some packages dont
>  use ascii names.
> >>>
> >>> It does, but as said before, whether this is desireable depends
> >>> on the target audience.  The purpose of API is to be used,
> >>> i.e. it would be useless if even just one user can't type it.
> >>>
> >> Well we already have that don't we? What I mean is that ASCII names cant
> >> be typed by all keyboards layouts easily. So what you are saying already
> >> happens. Thats why I always have an ASCII layout available as a
> >> secondary, next to my non ASCII. I bet every person that uses packages
> >> with names other than english can add a seperate layout.
> >>
> >>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
>  Regarding the broken install example, most (all?) base
>  packages use ASCII due to unix historical baggage.
>  So you shouldn't need to type anything non ASCII
>  to fix an install with only basic packages.
> >>>
> >>> Due to historical baggage, most (all?) keyboard layouts can fall
> >>> back to ASCII alphanumerics.  A broken install was given
> >>> as the worst case; there's no reason any other packages
> >>> should be less accessible based on the users' culture.
> >>>
> >>
> >> But they are already aren't they? Because if I want to add a package
> >> with the Greek alphabet or the Japanese one I have to transliterate it
> >> into ASCII which is always going to be worse and people won't be able to
> >> find the package. Because they won't know we changed the name. Plus they
> >> will have to change the layout. Same as an ASCII user would have to do.
> >>
> >>> I suggest, in an international context such as GuixSD,
> >>> for every package to have a ASCII name.  It'd of course
> >>> be better if a correctly written name is also available.
> >>>
> >>
> >> So you propose two names? Sure if that can be done I don't see why not. 
> >> Either way not
> >> having unicode names is a bug. Also to note: Most of the world speaks
> >> Unicode. So its more for compatibility purposes i guess (?) rather than
> >> to be "international".
> >>
> >> MSavoritias
> >
> >
> 
> There are two things discussed here:
> 
> 1. A restriction in the daemon prevents using unicode in store item names.
> 
> I think this is an issue worth fixing, as it would allow users to define 
> their own store items more easily. For instance, I might want to make a file 
> with non-ascii name a file-like item, eg.
> 
> (local-file "fond d'écran.jpg")

Out of curiosity, do you have an idea how would the list of allowed characters
look like?  Anything except / and \0?  Or something more restrictive?

> 
> 2. Naming policy for packages in the Guix channel
> 
> I don't think we should distribute packages that have non-ascii characters in 
> their names. Of course I don't know all keyboards that exist out there, but I 
> don't think you can find a programmer that can't type an ascii character, or 
> a guix user that can't at least type "guix" in their terminal.
> 
> For discoverability, we could add the real non-ascii name in the package 
> description.
> 

-- 
There are only 

Re: questionable advice about Geiser load path setting

[wolf]

On 2023-08-26 07:27:22 -0400, brian via Development of GNU Guix and the GNU 
System distribution. wrote:
> Csepp  writes:
> 
> > The docs contain this recommended Emacs setting:
> >
> > @lisp
> > ;; @r{Assuming the Guix checkout is in ~/src/guix.}
> > (with-eval-after-load 'geiser-guile
> >   (add-to-list 'geiser-guile-load-path "~/src/guix"))
> > @end lisp
> >
> > I haven't been using it for a while because I remember it causing
> > trouble whenever I was working on other Guile projects.  I have been
> > running Emacs inside ./pre-inst-env instead, which seems to work just as
> > well, if not better.
> >
> > I'd like to make an amendment to the relevant docs, but would welcome
> > some info on why it was originally written this way, maybe there are use
> > cases I'm missing.
> 
> I agree that it's bad advice, since it assumes the only reason to use
> Guile is to hack on Guix. I also think it's not necessary, since
> ‘.dir-locals.el’ in the Guix root should be taking care of this for you
> already. I don't use the manual addition to ‘load-path’ you quote above,
> and Geiser seems to work fine (within the bounds of Geiser's definition
> of “fine”, anyway).

Geiser seems to add the project root (I assume based on the git) into the load
path automatically.  geiser-repl-current-project-function seems to be set by
default, and rest is described in the docs: (geiser)Customization and tips, Init
files and load paths.

Maybe it once was necessary to set this, I am not sure it still is the case.

I also use (setq geiser-repl-per-project-p t) and everything seems to just work
out of the box.


> 
> The downside of using dir-locals is that Emacs yells quite loudly about unsafe
> variables being set.

In emacs 29 it should be possible to whitelist it, so it will stop being so
annoying.

> Another option may be direnv or bufenv? I haven't tried them myself, but have
> heard good things.
> 
> -bjc
>

W.

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


signature.asc
Description: PGP signature