Re: guix fails to build on aarch64

[Chris Marusich]

Hi Pierre,

Thank you very much for the details!  I have added this information to
the existing bug report:

https://issues.guix.gnu.org/52943

Please direct further discussion regarding this bug there, so that
people looking at the bug report will see an accurate record of the
investigation so far.

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836


signature.asc
Description: PGP signature

Re: Alternative solution to stat storm problem

[Farid Zakaria]

I did forget to mention the point of LD_LIBRARY_PATH, that you can
still make use of LD_PRELOAD and I am also thinking about maybe using
something like dlopen-resolver[1] to further expand the NEEDED
section.

[1] https://github.com/Mic92/dlopen-resolver

On Sat, Jan 8, 2022 at 7:00 PM Farid Zakaria  wrote:
>
> Hi Ludovic,
>
> On Sat, Jan 8, 2022 at 1:22 PM Ludovic Courtès  wrote:
> >
> > Hi Farid,
> >
> > Farid Zakaria  skribis:
> >
> > > I have written a tool _shrinkwrap_ [2] that takes all transitive
> > > dynamic shared object dependencies (only those listed in DT_NEEDED)
> > > and turns them into an absolute path.
> > >
> > > This has the same result as caching the entries and avoids the
> > > unnecessary failed attempts at trying each RUNPATH entry.
> > >
> > > Using the same demo application _emacs_ shows as much as well:
> >
> > Nice!  I think that’s another interesting way to address the problem.
> >
> > I guess the advantage is that you don’t need the ld.so patch.  The
> > downside is that PatchELF needs to be able to write longer NEEDED
> > strings in the dynamic section, which it may not always be successful at
> > (I think?).
>
> I can't claim to be a ELF specification guru but I have not
> encountered that longer NEEDED strings to be a cause for failure.
> The emacs example is a pretty good test case because the transitive
> closure of all NEEDED libraries is quite large, which all seem to be
> added successfully to the ELF header.
>
> The benefit to me seems:
> 1 - does not need a glibc patch for functionality (although for other
> libc such as musl it might in this case
> https://www.openwall.com/lists/musl/2021/12/21/1)
> 2 - understanding the dependencies of an application become simpler
> 3 - there are esoteric cases where in fact libraries might link to the
> wrong libraries (although they are correct at build time) given a
> RUNPATH/RPATH since there are subtleties with the inheritance model.
>
> I'm actually researching ways to improve (3) as well through
> mentorship with Tom Scogland by researching alternative ways to do
> linking:
> - RUNPATH per NEEDED
> - the ability to specify whether a RUNPATH should be inherited or not
> to downstream dependencies
>
> > Also, I wonder if the absolute file names in NEEDED interfere with uses
> > of $LD_LIBRARY_PATH (making it impossible to force use of another
> > libxyz.so than the one that would be found in RUNPATH.)
>
> Correct. For a system with reproducibility in mind this can perhaps be
> a desired feature.
> It is the current limitation of the proposal.
>
> In fact, Carlos brought up a great philosophical question:
> "Is linking to libraries through a content-addressable value allowed
> for LGPL software?"
> What if the linked address also forced the content-address by having
> it resolve to something on IPFS ?
>
> > Thoughts?
> >
> > Thanks for sharing!
> >
> > Ludo’.

Re: Alternative solution to stat storm problem

[Farid Zakaria]

Hi Ludovic,

On Sat, Jan 8, 2022 at 1:22 PM Ludovic Courtès  wrote:
>
> Hi Farid,
>
> Farid Zakaria  skribis:
>
> > I have written a tool _shrinkwrap_ [2] that takes all transitive
> > dynamic shared object dependencies (only those listed in DT_NEEDED)
> > and turns them into an absolute path.
> >
> > This has the same result as caching the entries and avoids the
> > unnecessary failed attempts at trying each RUNPATH entry.
> >
> > Using the same demo application _emacs_ shows as much as well:
>
> Nice!  I think that’s another interesting way to address the problem.
>
> I guess the advantage is that you don’t need the ld.so patch.  The
> downside is that PatchELF needs to be able to write longer NEEDED
> strings in the dynamic section, which it may not always be successful at
> (I think?).

I can't claim to be a ELF specification guru but I have not
encountered that longer NEEDED strings to be a cause for failure.
The emacs example is a pretty good test case because the transitive
closure of all NEEDED libraries is quite large, which all seem to be
added successfully to the ELF header.

The benefit to me seems:
1 - does not need a glibc patch for functionality (although for other
libc such as musl it might in this case
https://www.openwall.com/lists/musl/2021/12/21/1)
2 - understanding the dependencies of an application become simpler
3 - there are esoteric cases where in fact libraries might link to the
wrong libraries (although they are correct at build time) given a
RUNPATH/RPATH since there are subtleties with the inheritance model.

I'm actually researching ways to improve (3) as well through
mentorship with Tom Scogland by researching alternative ways to do
linking:
- RUNPATH per NEEDED
- the ability to specify whether a RUNPATH should be inherited or not
to downstream dependencies

> Also, I wonder if the absolute file names in NEEDED interfere with uses
> of $LD_LIBRARY_PATH (making it impossible to force use of another
> libxyz.so than the one that would be found in RUNPATH.)

Correct. For a system with reproducibility in mind this can perhaps be
a desired feature.
It is the current limitation of the proposal.

In fact, Carlos brought up a great philosophical question:
"Is linking to libraries through a content-addressable value allowed
for LGPL software?"
What if the linked address also forced the content-address by having
it resolve to something on IPFS ?

> Thoughts?
>
> Thanks for sharing!
>
> Ludo’.

Re: Release v1.4 (or 2.0): process and schedule ?

[Chris Marusich]

Hi Maxim,

Maxim Cournoyer  writes:

> Hello Chris,
>
> Chris Marusich  writes:
>
>> Maxim Cournoyer  writes:
>>
>>> About the current status, I'm nearing on pushing a version-1.4.0 branch
>>> which is based on master with a few more (core-ish) updates.  There's
>>> still a few days ahead of that, so if you manage to get many of this
>>> kind of problems fixed & merged in master they can easily be included in
>>> the next release.
>>
>> There is a problem that currently prevents "guix pull" from succeeding
>> for powerpc64le-linux on master.  I'd like to resolve it before the
>> release if possible.  The problem is here, including a patch to fix it:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52940
>>
>> [...]
>
> Since the version-1.4.0 branch I've been polishing locally still hasn't
> been published nor built, there's still time to apply the patch without
> any consideration for world rebuilds to that branch (at this point we
> want the changes to be low risk ones though, but that sounds like one).

With Ludo's feedback, I was able to fix 52940 without rebuilding the
world in commit 195bb1fb9d55d8e5187d669c63a3cde747fc5f64 on master.  Can
you try merging master into your version-1.4.0 branch?

At this point in time, I'm unaware of any issues that would be
show-stoppers for for powerpc64le-linux.  As a reminder, issues
important to powerpc64le-linux can be seen by searching for issues
tagged with the "guix" user's powerpc64le-linux Debbugs usertag:

https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=powerpc64le-linux;users=guix

I'll keep my eye out for other potential powerpc64le-linux issues and
see what I can do to help in the days/weeks to come.

Now that the "guix" package is building successfully again on master, I
can finally build up-to-date versions of cuirass and
guix-build-coordinator.  Although it isn't directly related to the
release, I think I will resume my efforts to add a new powerpc64le-linux
node to the build farm.

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836


signature.asc
Description: PGP signature

Having a package browser on guix.gnu.org

[Ludovic Courtès]

Hi,

Luis Felipe  skribis:

> But I wonder if it is possible now to make the packages part use any of the 
> Postgres databases that already exist and allow traditional search without 
> JavaScript...

Former Outreachy intern Danjela Lura, together with Chris Baines, had
started developing a JS-free package browsing interface:

  https://lists.gnu.org/archive/html/guix-devel/2020-07/msg00050.html

Chris, could you tell us what the status is and what’s missing before we
can use it on the web site?

Thanks,
Ludo’.

Re: RFC: new syntax for inline patches

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

>   (arguments
> (list
> #:phases
> '(modify-phases %standard-phases
>   (add-after 'unpack 'i-dont-care
> (lambda _
>   (substitute* "this-file"
> (("^# some unique string, oh, careful! gotta \\(escape\\) 
> this\\." m)
>  (string-append m "\nI ONLY WANTED TO ADD THIS LINE!\n"

[...]

> There are a few reasons why we don’t use patches as often:
>
> 1. the source code is precious and we prefer to modify the original
> sources as little as necessary, so that users can get the source code as
> upstream intended with “guix build -S foo”.  We patch the sources
> primarily to get rid of bundled source code, pre-built binaries, or
> code that encroaches on users’ freedom.
>
> 2. the (patches …) field uses patch files.  These are annoying and
> inflexible.  They have to be added to dist_patch_DATA in gnu/local.mk,
> and they cannot contain computed store locations.  They are separate
> from the package definition, which is inconvenient.
>
> 3. snippets feel like less convenient build phases.  Snippets are not
> thunked, so we can’t do some things that we would do in a build phase
> substitution.  We also can’t access %build-inputs or %outputs.  (I don’t
> know if we can use Gexps there.)

I agree that #1 is overrated.

As for #3, we could make ‘snippet’ thunked (a snippet can be a gexp
already).  We cannot refer to build inputs there, but that’s on purpose:
snippets, like patches, are supposed to be architecture-independent and
unable to insert store file names.

[...]

> (We have something remotely related in etc/committer.scm.in, where we
> define a record describing a diff hunk.)
>
> Here’s a colour sample for the new bikeshed:
>
>   (arguments
> (list
>   #:patches
>   #~(patch "the-file"
>  ((line 10)
>   (+ "I ONLY WANTED TO ADD THIS LINE"))
>  ((line 3010)
>   (- "maybe that’s better")
>   (+ (string-append #$guix " is better"))
>   (+ "but what do you think?")

Like Attila my first reaction was skepticism.

… but thinking about it, we could have a  record,
similar to the  record you mention; it would be a file-like
object that, when lowered, would give an actual patch.

So you could write:

  (origin
;; …
(patches (list (computed-patch
 (hunk (line 10) (+ "new line") (- "old line"))

The good thing is that the implementation of  would be
entirely orthogonal, separate from the package machinery.

OTOH, if we do that, we might as well write the actual patch right away.

I wonder how frequent the pattern we’re discussing is.  I know I’ve used
it a few times, but I wonder if it warrants sophisticated tooling.

Thoughts?

Ludo’.

Re: Alternative solution to stat storm problem

[Ludovic Courtès]

Hi Farid,

Farid Zakaria  skribis:

> I have written a tool _shrinkwrap_ [2] that takes all transitive
> dynamic shared object dependencies (only those listed in DT_NEEDED)
> and turns them into an absolute path.
>
> This has the same result as caching the entries and avoids the
> unnecessary failed attempts at trying each RUNPATH entry.
>
> Using the same demo application _emacs_ shows as much as well:

Nice!  I think that’s another interesting way to address the problem.

I guess the advantage is that you don’t need the ld.so patch.  The
downside is that PatchELF needs to be able to write longer NEEDED
strings in the dynamic section, which it may not always be successful at
(I think?).

Also, I wonder if the absolute file names in NEEDED interfere with uses
of $LD_LIBRARY_PATH (making it impossible to force use of another
libxyz.so than the one that would be found in RUNPATH.)

Thoughts?

Thanks for sharing!

Ludo’.

Re: search-input-file vs (assoc-ref inputs)

[Ludovic Courtès]

Hi,

Zhu Zihao  skribis:

> Some of my concern about label-less style inputs.
>
> 1. How can we refer to a non-package input? Some code might use
> something like
>
> (inputs
>   `((".patch" ,(origin 

You can either keep labels or, what I would recommend, use gexps and
‘local-file’.  An example of that is commit
a21590dabfcef0aa008503ea981364b90750b07c.

> If I want to replace this patch, I can simply use list operations from
> SRFI-1 to manipulate it. But in label-less style, there's no label for a
>  object. Packagers may try to embed these objects into the build
> expression using `ungexp`. But I think it violates the dependency
> inversion principle(We don't rely on label, but rely on concrete
> object).

That’s true.  OTOH, I think one rarely wants to override a patch because
the patch is usually closely tied to the ‘source’ origin anyway.

But yeah, if you have a concrete example, we could see how well that
works there.

> 2. libgcc, libgcc is a specific output of gcc. IIUC in build expression,
> it shares label with gcc, gcc is an implicit input in many build
> system. It's not so convenience for me to refer libgcc.
>
> For example, I want to set up the `LD_LIBRARY_PATH` for testing. it's
> better to use `(string-append (this-package-inputs "libgcc") "/lib")`.
> But I can't do this, the label of libgcc is "hidden".
> `search-input-directory` doesn't work here because "/lib" is a common
> directory exists in many package. I have to write `(dirname
> (search-input-file input "libstdc++.so.6"))`, so ugly...

I’d do (dirname (search-input-file input "/lib/libstdc++.so.6")).
That’s not pretty, but I wouldn’t call it “ugly” either.  :-)

Before that, you would refer to a label that doesn’t actually appear in
the package’s input (because GCC is an implicit input), which wasn’t
better IMO.

As I wrote back in , there are idioms
we used before and that don’t have an obvious or pleasant translation in
the label-less style.  I think we should look together at those concrete
examples when we find them and see what we can come up with.

Thanks for your feedback!

Ludo’.

Re: New release of guile-git?

[Maxime Devos]

Nevermind, seems easy to work around with call-with-temporary-
directory. A new release of guile-git would still be nice, though.
Also, Erik Edrosa seems to have somehow disappeared from CC.


signature.asc
Description: This is a digitally signed message part

New release of guile-git?

[Maxime Devos]

Hi,

I wrote a patch to the git updater in Guix, making it able to
update packages like guile-next, emacs-next and minetest-throwing-arrows,
that simply point to the latest commit in the git repository at the
time the package definition was updated.

It uses the procedure 'remote-create-detached', introduced in
.

But that's not yet in any release, so I had to copy the definition
and use some @@ and (use-modules (git bindings) (system foreign)).

No other new procedures were needed.

Could a new version of guile-git, with remote-create-detached, be released?

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Guix Documentation Meetup

[Leo Famulari]

On Sat, Jan 08, 2022 at 11:24:35AM -0500, Matt wrote:
> Let me walk through what that looks like from my perspective.  I'm afraid, 
> however, that it comes across as aggressive, ungrateful, or demanding.  None 
> of those are my intent! I genuinely want to help but struggle to understand 
> the process.  My goal is to outline a "user story".
> 
> From my perspective, contributing to the cookbook looks as follows.  I've 
> tried to be factual and ask rhetorical questions. 
> 
> How do I contribute to the cookbook? I see no information in the cookbook 
> about how to do that. I'm looking at 
> https://guix.gnu.org/cookbook/en/guix-cookbook.html
> 
> The contribute page (https://guix.gnu.org/en/contribute/) links to this 
> mailing list. I am willing and ready to contribute. Now what?
> 
> I see the manual has a section on contributing: 
> https://guix.gnu.org/manual/en/html_node/Contributing.html#Contributing
> 
> I see nothing about how to contribute to documentation. 
> 
> Do I need to submit a patch? 
> How do I submit a patch? 
> Do I have to write in TexInfo?
> What is the roadmap from me spending hours authoring something to it being 
> available for review from experts or to being useful to others?

I see that this all seems confusing. If you have something to
contribute, you should just mail it to this list or guix-patches.
Definitely, we prefer you send patches, but if that is too hard, you can
send your contribution in *any* form.

Re: Guix Documentation Meetup

[Ricardo Wurmus]

Matt  writes:

>  > > I would like for Guix to host a community wiki (in addition to a more 
> discoverable official documentation).
>  > 
>  > That’s the purpose of the Cookbook, which is open to all contributors.
>
> The cookbook is a great resource. I'd like to contribute to it.

Cool, we’re accepting contributions in whatever form you are comfortable
with.  Of course, patches are the easiest for us, but you can also just
write plain text and send it as an email to guix-patc...@gnu.org or
guix-devel@gnu.org and ask for it to be added.

-- 
Ricardo

Re: Public key pinning in guix?

[Philip McGrath]

Hi,

On 1/7/22 16:24, Maxime Devos wrote:

The purpose is to resist a compromise of the CA system. More
concretely, if you now do "guix refresh -u minetest-moreores"
then a MITM that compromised a CA cannot secretly replace
minetest-moreores with a mod that mines bitcoin for the MITM,
or something.

Possibly also useful for "guix download", "guix import", "guix lint",
"guix build --with-latest=...".

A downside is that whenever content.minetest.net changes public keys,
the pinned public key in Guix needs to be updated. How often does this
happen? I wouldn't now. This could be partially automated with
a "./pre-inst-env guix update-the-pinned-keys" script, and there could
be an "GUIX_IGNORE_KEY_PINNING=yes" environment variable as escape
hatch.

WDYT, worth the trouble or not?



This sounds like HTTP Public Key Pinning (HPKP).[1] AIUI, HTTP Public 
Key Pinning was deprecated, and support has been removed from major 
browser engines by January 2020.[2][3][4] While it seemed like a good 
idea for reasons like the ones you list, apparently it not only proved 
very difficult for site administrators to configure, with severe 
consequences for mistakes, it also enabled potential ransomware attacks 
and other bad stuff.[6]


I never followed this feature closely and don't have a strongly-held 
opinion on the merits, but, if the "web platform" has deprecated this 
feature---more concretely, if it is Considered Harmful by sysadmins and 
servers are configured with the expectation that no one does this any 
more---I don't think it would improve reliability for Guix to 
unilaterally revive HPKP.


-Philip

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
[2]: https://scotthelme.co.uk/hpkp-is-no-more/
[3]: 
http://web.archive.org/web/20200618234723/https://www.fxsitecompat.dev/en-CA/docs/2019/http-public-key-pinning-is-no-longer-supported/

[4]: https://chromestatus.com/feature/5903385005916160
[5]: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr7p3rZ8/m/eNMwKPmUBAAJ

[6]: https://scotthelme.co.uk/using-security-features-to-do-bad-things/

Re: Guix Documentation Meetup

[Matt]

 > > I would like for Guix to host a community wiki (in addition to a more 
 > > discoverable official documentation).
 > 
 > That’s the purpose of the Cookbook, which is open to all contributors.

The cookbook is a great resource. I'd like to contribute to it.

Let me walk through what that looks like from my perspective.  I'm afraid, 
however, that it comes across as aggressive, ungrateful, or demanding.  None of 
those are my intent! I genuinely want to help but struggle to understand the 
process.  My goal is to outline a "user story".

>From my perspective, contributing to the cookbook looks as follows.  I've 
>tried to be factual and ask rhetorical questions. 

How do I contribute to the cookbook? I see no information in the cookbook about 
how to do that. I'm looking at 
https://guix.gnu.org/cookbook/en/guix-cookbook.html

The contribute page (https://guix.gnu.org/en/contribute/) links to this mailing 
list. I am willing and ready to contribute. Now what?

I see the manual has a section on contributing: 
https://guix.gnu.org/manual/en/html_node/Contributing.html#Contributing

I see nothing about how to contribute to documentation. 

Do I need to submit a patch? 
How do I submit a patch? 
Do I have to write in TexInfo?
What is the roadmap from me spending hours authoring something to it being 
available for review from experts or to being useful to others?

I see https://guix.gnu.org/manual/en/html_node/Commit-Access.html says I would 
need three people to vouche for me, have to apply for maintainership, and some 
other stuff I didn't read. 
Would anyone actually vouche for me at this point?

I have two documents written in Org:
1. http://excalamus.com/test-guix-case-study-plover-python-dictionary.html
2. http://excalamus.com/2021-10-06-guix-debug.html

Do I have to convert them to TexInfo?
Who will review them?
Is the layout and style appropriate for info distribution?
Are there any licensing concerns to be aware of?

To close, I apologise for how aggressive all the questions can feel. Reading 
over it is overwhelming, even for me.  I'm afraid it may come across as simply 
yelling "Why? Why? Why?"  I would like to help provide answers. However, it 
feels like myself and others are practically begging for direction on how to do 
that. Someone has the authority and means to address these issues. Who is that 
person and what is their gameplan for addressing the issues raised in this 
thread? How do I (and others) figure into that plan? How I and others fit into 
this community?

Thank you for your time and patience! (And for everyone, including you, 
Ricardo, who have contributed to making Guix something myself and others want 
to use and extend). 

Re: Guix Documentation Meetup

[Matt]

 > Someone was frustrated there was no wiki, so they started that, but it's not 
 > official at all. Miraheze hosts other wikis, like the bootstrappable wiki, I 
 > think it's ok, but if we had a wiki, it should rather be hosted on gnu or 
 > guix infrastructure.
 
Thank you for clarifying. I now see the footer says "unofficial". 

Re: Guix Documentation Meetup

[Josselin Poiret]

Hello everyone,
Matt  writes:

>  > I would like for Guix to host a community wiki
>
> Agreed. 
>
> Ironically, Guix already has two of them.
>
> 1. goto gnu.guix.org
> 2. Select wiki from the help menu
> 3. Discover that linked wiki is not a community wiki
> 4. Click the (supposed) community wiki: 
> https://guix.miraheze.org/wiki/Main_Page
>
> Is this the "official" Guix wiki? 
> If so, why is it not a direct link from the home page.
> Who hosts it? If I spend hours writing something, is it just going to 
> disappear some day?

If I remember correctly, this wiki was created by Jacob "Kreyren" Hrbek
 [1, 2], however they seem to have been banned from
IRC some time ago [3].  miraheze.org itself seems to be a wiki farm, but
I don't know if there are any advantages over LibrePlanet.  I think it
would be very possible to turn the current Group:Guix wiki into a proper
Community wiki, just that it's not used in that way currently.

[1] https://logs.guix.gnu.org/guix/2021-11-03.log#215121
[2] https://libreplanet.org/wiki/Special:Contributions/Kreyren
[3] https://logs.guix.gnu.org/guix/2021-11-28.log#015743

-- 
Josselin Poiret

Re: Guix Documentation Meetup

[Julien Lepiller]

Le 8 janvier 2022 14:41:53 GMT+01:00, Matt  a écrit :
>
> > I would like for Guix to host a community wiki
>
>Agreed. 
>
>Ironically, Guix already has two of them.
>
>1. goto gnu.guix.org
>2. Select wiki from the help menu
>3. Discover that linked wiki is not a community wiki
>4. Click the (supposed) community wiki: 
>https://guix.miraheze.org/wiki/Main_Page
>
>Is this the "official" Guix wiki? 
>If so, why is it not a direct link from the home page.
>Who hosts it? If I spend hours writing something, is it just going to 
>disappear some day?
>

Someone was frustrated there was no wiki, so they started that, but it's not 
official at all. Miraheze hosts other wikis, like the bootstrappable wiki, I 
think it's ok, but if we had a wiki, it should rather be hosted on gnu or guix 
infrastructure.

Re: GNU Guix maintainer rotation

[Edouard Klein]

Thank you Ludovic and Marius :)

And good luck to Efraim !


Maxim Cournoyer  writes:

> Hello Guix!
>
> I'd like to bring your attention to a change to the current Guix
> maintainers collective; in a nutshell, Ludovic and Marius are stepping
> down from maintainer-ship while Efraim is joining.
>
> I won't write more as you can find all the details in this blog post:
> https://guix.gnu.org/en/blog/2022/gnu-guix-maintainer-rotation/.
>
> Many thanks to Ludovic and Marius for their past roles as Guix
> co-maintainers, and a warm welcome to Efraim!
>
> Happy hacking!
>
> Maxim

Re: Guix Documentation Meetup

[Matt]

 > I would like for Guix to host a community wiki

Agreed. 

Ironically, Guix already has two of them.

1. goto gnu.guix.org
2. Select wiki from the help menu
3. Discover that linked wiki is not a community wiki
4. Click the (supposed) community wiki: https://guix.miraheze.org/wiki/Main_Page

Is this the "official" Guix wiki? 
If so, why is it not a direct link from the home page.
Who hosts it? If I spend hours writing something, is it just going to disappear 
some day?

Re: Guix Documentation Meetup

[calcium]

I would like for Guix to host a community wiki (in addition to a more 
discoverable official documentation).


That’s the purpose of the Cookbook, which is open to all contributors.



It is not a wiki. You can't edit and review easly, but must instead send a 
contribution to someone (IRC or email) which is teadious and discourage small 
and quick contributions.

And my point was about allowing a low effort wiki that may contain wrong or 
incomplete content (but quick to contribute/use and where there is no 
expectation of high quality).

And this seems to go against the current spirit of hte Guix Cookbook (High 
quality/Without mistakes examples/content about howto do a specific task)

Re: GNU Guix maintainer rotation

[Oliver Propst]

Right I guess that we should be glad that Efraim have steeped up as a 
maintainer for the project and of course thank Ludovic and Marius for 
the many years of service for Guix and free software.


--
Kinds regards Oliver Propst
https://twitter.com/Opropst

Re: Guix Documentation Meetup

[Ricardo Wurmus]

calcium  writes:

> I would like for Guix to host a community wiki (in addition to a more 
> discoverable official documentation).

That’s the purpose of the Cookbook, which is open to all contributors.

-- 
Ricardo

Re: Guix Documentation Meetup

[calcium]

I strongly agree with matt about the importance of discoverability that is 
currently lacking (`geiser-doc-symbol-at-point isn't enough).
Its pretty hard to find out how to do something beyond the basic usage.

I would like for Guix to host a community wiki (in addition to a more 
discoverable official documentation).

Because a collaborative wiki that encourages effortless and low quality content 
could alleviate the problem of discoverability and context.

This could serve as a stepping stone for users to understand the context (by 
reading what another user tried and failed to achieve) and to find possible 
solutions (avoiding the time sunk of dead-ends and maybe adapting an ugly hack 
into a cleaner solution, or even just using the ugly hack, instead of gving up 
on the use of Guix).

The low quality wiki could also motivate people to correct misconceptions and submit 
better approaches ("Someone is WRONG on the internet" https://xkcd.com/386/ ).