Re: core-updates-frozen branch merged

[Mathieu Othacehe]

Hey,

> That's it!  Enjoy the latest additions and improvements, and report any
> issues you encounter!

That's great news! Thanks to all the people that have been involved and
special thanks to you Maxim for your commitment.

Mathieu

Re: [core-updates-frozen] Attempt julia@1.6.4 (upgrade)

[zimoun]

Hi Maxim,

On Mon, 13 Dec 2021 at 22:20, Maxim Cournoyer  wrote:

> It'll have to be resolved on core-updates :-).

Well, Julia update can happen in master, IMHO.  Even, depending on the
release date, it appears to me doable for the next release. ;-)

Cheers,
simon

Re: core-updates-frozen branch merged

[zimoun]

Hi,

On Mon, 13 Dec 2021 at 20:34, Maxim Cournoyer  wrote:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).
>
> A tentative release preparation branch 'version-1.4.0' was then created
> from master, where release-specific enhancements can go.  Things broken
> on master as it stands should be fixed there, and we can cherry pick
> these fixes into the release branch.

Double yeah! \o/

Thanks for all involved to make it happen.

About the release, what is the draft schedule?

Cheers,
simon

Re: core-updates-frozen branch merged

[Timothy Sample]

Hi Maxim,

Maxim Cournoyer  writes:

> In case you hadn't taken notice, the core-update-frozen branch was
> finally merged into master.  So please reconfigure your remotes to avoid
> uploading any further work there :-).
>
> [...]
>
> That's it!  Enjoy the latest additions and improvements, and report any
> issues you encounter!
>
> Thank you,

Thank you Maxim!  I really appreciate the extra work you put in to get
this finished.  It was not an easy process, but your energy really kept
things moving.  I’ve been a happy c-u-f user for a while now, and the
updates are really terrific!

Here’s hoping the next one will be a little easier.  :)


-- Tim

Re: build system option to allow CPU optimizations?

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> zimoun  skribis:
>
>> On Wed, 24 Nov 2021 at 13:10, Ricardo Wurmus  wrote:
>>
>>> The build phases that patch out these features would have to check 
>>> for that build system option, much like they check the TESTS? 
>>> option before attempting to run tests.
>>
>> Then it could be a transformation.   The idea sounds good to me.
>
> I’ve been working on it last week with my HPC hat on.
>
> To be clear, I think in may cases, passing ‘-march’ like you suggest is
> the wrong approach; instead software should use (and usually does use)
> function multi-versioning:
>
>   https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/
>
> I found one case though where this is not possible: C++ header-only
> libraries such as Eigen contain hand-optimized vectorized routines,
> selected at build time, but we end up compiling Eigen users as the
> x86_64/AArch64 baseline, which is a waste.  (If you do know of other
> problematic cases, I’m interested in taking a look!)

I think that 'atlas' is such an example of a package that uses
multi-versioning but fails to build reproducibly depending on the exact
CPU it was built.  I've reported that here [0].

[0]  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51536

Thank you,

Maxim

Re: [core-updates-frozen] Attempt julia@1.6.4 (upgrade)

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

> Hi,
>
> First, I am not convinced that upgrade Julia from 1.6.3 to 1.6.4 is
> something to do now; especially when the branch is “frozen”.  Using
> patches #52117 [1], all failures are fixed for 1.6.3.
>
> 1: https://issues.guix.gnu.org/52117
>
>
> Here a rough attempt which replaces the source of 1.6.3 by 1.6.4 and
> many tests are deeply broken (broken precompile is not a good sign, at
> all ;-)).  Well, it seems expected regarding the complexity of the Julia
> stack. :-)
>
> Therefore, the upgrade requires various other upgrades elsewhere and
> probably some fixes with couple of patches.  As it had been for previous
> Julia upgrades. :-)
>
> Then, using this upgraded julia@1.6.4, there is a high probability that
> many julia-* packages would be broken too and thus they would require
> fixes.
>
> IMHO, if we want a working Julia in the delay for the merge, the best
> seems to just apply patch#52117 and let this Julia upgrade for another
> round.  For what my opinion is here. :-)

Seems I had not answered here; thanks for attempting my suggestion!  It
seems you were right that Julia (even for a patch version bump) is
picky.

It'll have to be resolved on core-updates :-).

Thanks,

Maxim

core-updates-frozen branch merged

[Maxim Cournoyer]

Hello Guix!

In case you hadn't taken notice, the core-update-frozen branch was
finally merged into master.  So please reconfigure your remotes to avoid
uploading any further work there :-).

A tentative release preparation branch 'version-1.4.0' was then created
from master, where release-specific enhancements can go.  Things broken
on master as it stands should be fixed there, and we can cherry pick
these fixes into the release branch.

That's it!  Enjoy the latest additions and improvements, and report any
issues you encounter!

Thank you,

Maxim

Re: bluetooth-service: addition config vaules

[Demis Balbach]

On 2021-12-11 14:57, Josselin Poiret wrote:

Hello,

I submitted a patch. ID: 52470.

Unfortunately I can't find it here for some reason:
https://issues.guix.gnu.org/52470

-- 
Best regards / Mit freundlichen Grüßen,
Demis Balbach


signature.asc
Description: PGP signature

Re: Guix Documentation Meetup

[Katherine Cox-Buday]

Blake Shaw  writes:

> Katherine Cox-Buday  writes:
>
> Katherine, reading a big deeper into your user experience report, its really
> so so helpful to have this concrete sort of step-by-step user experience
> report.

Definitely! The first step to resolution is a common understanding.

> Would you mind if I solicit the list for more reports like this for anyone
> who might feel like offering them?

I don't think I'm in a position to give you authority to do this, but I 
certainly don't mind :)

> And would you mind if I cite this in the presentation I'm gathering?

Not at all. I posted this to the public list for that reason.

Thanks for trying to take this on!

-- 
Katherine

Re: Any go expert willing to help with updating IPFS?

[Konrad Hinsen]

"Leo Famulari"  writes:

> It's likely that you need to use a newer version of Go.

Thanks, that did it! With go-1.17 it compiles fine.

Cheers,
  Konrad

Re: Flag day for simplified package inputs

[Jelle Licht]

Hello,

Ludovic Courtès  writes:

> Hi,
>
> Jelle Licht  skribis:
>
>> I will work on that. Do we already have a suitable 'bulk change' in the
>> repo? Or should we first run `guix style', and subsequently use that
>> commit as the first entry in the .git-blame-ignore-revs file?
>
> The latter I guess.

Attached what I was thinking of: I decided to go with integrating the
git-blame-ignore-revs file with our existing gitconfig situation. Let me
know what you think of the workflow and the documented changes after
running `guix style'.

>From 69926c94fb576e503d7838836cfd83066c39abcc Mon Sep 17 00:00:00 2001
From: Jelle Licht 
Date: Mon, 13 Dec 2021 16:08:22 +0100
Subject: [PATCH] maint: Ignore specified bulk changes in git blame.

* etc/git/git-blame-ignore-revs: New file.
* etc/git/gitconfig (blame): Add ignoreRevsFile.
* doc/guix.texi ("Invoking guix style"): Document git-blame-ignore-revs usage.

Signed-off-by: Jelle Licht 
---
 doc/guix.texi | 5 +
 etc/git/git-blame-ignore-revs | 0
 etc/git/gitconfig | 3 +++
 3 files changed, 8 insertions(+)
 create mode 100644 etc/git/git-blame-ignore-revs

diff --git a/doc/guix.texi b/doc/guix.texi
index 59651f996b..0c0293cc8e 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -12769,6 +12769,11 @@ Invoking guix style
 trigger any package rebuild.
 @end table
 
+When applying automated changes to many packages, consider adding that
+particular commit hash to @file{etc/git/git-blame-ignore-revs} in a
+follow-up commit.  This will allow @command{git blame}
+(@pxref{Configuring Git}) to automatically ignore the specified commits.
+
 @node Invoking guix lint
 @section Invoking @command{guix lint}
 
diff --git a/etc/git/git-blame-ignore-revs b/etc/git/git-blame-ignore-revs
new file mode 100644
index 00..e69de29bb2
diff --git a/etc/git/gitconfig b/etc/git/gitconfig
index c9ebdc8fa8..afa598c4e3 100644
--- a/etc/git/gitconfig
+++ b/etc/git/gitconfig
@@ -1,3 +1,6 @@
+[blame]
+	ignoreRevsFile = etc/git/git-blame-ignore-revs
+
 [diff "scheme"]
 	xfuncname = "^(\\(define.*)$"
 

base-commit: e765ad091d861c99eae9fdd402214a2e2e90ed4d
-- 
2.34.0


- Jelle

Re: Any go expert willing to help with updating IPFS?

[Leo Famulari]

It's likely that you need to use a newer version of Go.

On Mon, Dec 13, 2021, at 02:51, Konrad Hinsen wrote:
> Hi Guix,
>
> the version of IPFS in Guix is 0.8, and in view of the important changes
> introduced in 0.10, that's obsolete by now. Which is why I am trying to
> update to 0.11.
>
> My current package definition is attached. It fails, but provides no
> clear hint (to the Go ignorant that I am) about what is actually going
> wrong:
>
>starting phase `build'
>
> src/github.com/ipfs/go-ipfs/vendor/github.com/lucas-clemente/quic-go/internal/qerr/error_codes.go:6:2:
>  
> build constraints exclude all Go files in 
> /tmp/guix-build-go-ipfs-0.11.0.drv-0/src/github.com/ipfs/go-ipfs/vendor/github.com/lucas-clemente/quic-go/internal/qtls
>Building 'github.com/ipfs/go-ipfs/cmd/ipfs' failed.
>
> The build log then shows the results of `go env`, where nothing looks
> suspicious to me. Then another cryptic line:
>
>command "go" "install" "-v" "-x" "-ldflags=-s -w" 
> "github.com/ipfs/go-ipfs/cmd/ipfs" failed with status 1
>
> Does anyone have an idea for debugging this issue?
>
> Cheers,
>   Konrad.

Re: Guix Documentation Meetup

[Blake Shaw]

Katherine Cox-Buday  writes:

Katherine, reading a big deeper into your user experience report,
its really so so helpful to have this concrete sort of step-by-step
user experience report. Would you mind if I solicit the list
for more reports like this for anyone who might feel like offering them?
And would you mind if I cite this in the presentation I'm gathering?

-- 
“In girum imus nocte et consumimur igni”

Re: Guix Documentation Meetup

[Blake Shaw]

Katherine Cox-Buday  writes:

Katherine this is great material to chew on, much of which I can relate
to!  

-- 
“In girum imus nocte et consumimur igni”

Re: Guix Documentation Meetup

[Blake Shaw]

zimoun  writes:

Hi Simon, thanks for the input,
> Hi,
>
> On Sat, 11 Dec 2021 at 05:40, Blake Shaw 
> wrote:
>
>> --
>> tldr: is there also room to discuss contributing -- and possibly
>> doing a
>> sizeable makeover to -- the *Guile* documentation? If so, I could
>> give a
>> short 5 - 10 minutes presentation of what I think should be done (and
>> would volunteer to do).
>> --
>
> Cool!
>
> Minor comments trying to feed this worth proposal.
>
>> I don't know if this is the correct forum for it, but I personally
>> think
>> the biggest documentation obstacle in Guix at the moment isn't so much
>> in Guix, but instead in Guile. I found Guix via SICP & Racket about a
>> year ago, and I remained a happy Racket hacker until a couple months
>> ago
>> when I decided to devote my free time to learning Guile in hopes of
>> graduating to a Guix sensei one day.
>
> I agree that the learning path in Guile land is not always smooth.
> However, I do not think mastering Guile and/or its specificity is a
> requirement to be a “Guix sensei”.  Obviously, better Guile
> documentation improves the ecosystem, then it is an overall better. :-)

I mostly agree, and I used Guix for probably half a year before recently
deciding to dive into Guile seriously. But I still won't be able to,
say, write a `guix import` for a different package manager without
needing to spend ample time consulting the docs, bumping up against
confusions, etc. I want to get to the point that I'm able to take
on such matters with confidence, and so learning Guile seems important.   

>
>> While I've come to love Guile, compared to my experience with Racket
>> its
>> been quite burdensome for me to get in the hang of, something I
>> attribute
>> primarily to the structure of the docs, and not due to it being in any
>> way more difficult than Racket. While with Racket I was writing
>> useful programs in the standard #lang within my first week, with Guile
>> I often find that what should be almost trivial winds up with a lot of
>> time lost just trying to navigate and understand the docs. When I do
>> figure things out, it turns out to be no more difficult than the
>> equivalent
>> in Racket, but a lack of consistency in the path that leads there in
>> the
>> docs cause hangups, which has made trivial scripts that should take
>> an hour
>> become weekend projects.
>
> Well, I am not convinced it is because the structure of the docs.
> Instead, I think it is because it is missing docs. :-)
>
> If we compare apple to apple, here are the entry points:
>
> https://docs.racket-lang.org/
> https://www.gnu.org/software/guile/learn/
>
> and so the Guile manual
>
> https://www.gnu.org/software/guile/manual/guile.html
>
> is a reference manual, which correspond to, mainly
>
> https://docs.racket-lang.org/reference/
>
> and also,
>
> https://docs.racket-lang.org/guide/
>

I'm covering all this in a presentation I'll be putting together over
the coming weeks, including some visualization of the structure that I
think is helpful. I'd argue that `Hello Guix`, `Hello Scheme`,
`Programming in Scheme` and `Programming in C` serve a similar function
to `Quick`, `Continue` and `More` in the Racket docs.

> I am not convinced you started Racket by these ones. ;-)
>

I started with the Racket Guide! or really, with SICP and `#lang
sicp`, doing little bits of the Racket Guide along the way and that got
me interested in racket more generally.

But probably more importantly, I think like many programmers I
started writing little projects in Racket and read the docs along the
way. And thats where my analysis focuses: the documents should, and can,
be easier to navigate, allowing one to get in-and-out as needed, but
currently there are many related functions buried in disparate areas
usually without examples. Why FTW and POSIX in disparate parts of the
manual, things its obviously desirable to use in tandem? Why are there
multiple ways to do IO without a disclaimer as to which is prefered? If
there are 30 documented SRFIs, and most have only 1 or two sentences
written for most, but some contain a treasure trove of knowledge, many 
people will move on after linking into one or two SRFI entries and
forgoe the rest, and won't realize there are tranducers in guile.

All of this adds up to a fair amount of overhead imo, and I'm planning
to put together a report covering a structural analysis of it before the
end of the month.

> Indeed, one document on the Guile side vs two documents on Racket side;
> the Guile manual could be split, I do not know if the core issue here.
> Instead, IMHO, what is missing are all the others. :-) For instance,
>
> https://htdp.org/
>
> which is a really smooth introduction.  Somehow, it appears to me
> that it is missing an introduction, a similar document as,
>
>  https://www.gnu.org/software/emacs/manual/html_mono/eintr.html
>
I haven't read htdp, but its always at the top of recommendations
regarding Scheme literature (or PL 

Re: Any go expert willing to help with updating IPFS?

[Konrad Hinsen]

Konrad Hinsen  writes:

> My current package definition is attached.

Well, now it is:

(define-public go-ipfs
  (package
(name "go-ipfs")
(version "0.11.0")
(source
 (origin
   (method url-fetch/tarbomb)
   (uri (string-append
 "https://dist.ipfs.io/go-ipfs/v; version
 "/go-ipfs-source.tar.gz"))
   (sha256
(base32 "13pmj83hwpz6mk7x52qn0cjnfqxqw2qri3r0k4b270w3bafcccwm"))
   (file-name (string-append name "-" version "-source"
(build-system go-build-system)
(arguments
 '(#:unpack-path "github.com/ipfs/go-ipfs"
   #:import-path "github.com/ipfs/go-ipfs/cmd/ipfs"
   #:phases (modify-phases %standard-phases
  (add-before 'reset-gzip-timestamps 'make-files-writable
(lambda* (#:key outputs #:allow-other-keys)
  ;; Make sure .gz files are writable so that the
  ;; 'reset-gzip-timestamps' phase can do its work.
  (let ((out (assoc-ref outputs "out")))
(for-each make-file-writable
  (find-files out "\\.gz$"))
#t))
(native-inputs
 `(("python" ,python-minimal-wrapper)
   ("zsh" ,zsh)))
(home-page "https://ipfs.io;)
(synopsis "Go implementation of IPFS, a peer-to-peer hypermedia protocol")
(description "IPFS is a global, versioned, peer-to-peer file system.  It
combines good ideas from Git, BitTorrent, Kademlia, SFS, and the Web.  It is
like a single bittorrent swarm, exchanging git objects.  IPFS provides an
interface as simple as the HTTP web, but with permanence built in.  You can
also mount the world at @code{/ipfs}.")
(license license:expat)))

Re: Organising Guix Days

[zimoun]

Hi Julien,

On Sat, 11 Dec 2021 at 02:37, Julien Lepiller  wrote:

> I think it's time to start organising the Guix Days, traditionally held
> around Fosdem.

Nice initiative!  Count on me for helping. :-)


> As for how it'll be organised. I propose to do something similar to
> what we need in November 2020. I'd love to get some talks from people
> outside the usual maintainers and commiters, to have an overview of the
> diversity of people and usage around Guix.

I agree.


> Last year, we asked speakers to prepare a video in advance, and they
> would only have an extended Q/discussion session. I think this year
> we should have the same process, but ask for a short (3-5 minutes) talk
> at the start of the session to refresh our minds on the main points of
> the presentation before discussions start.

In your views, the presentation is 3-5 minutes exposing the topic then
live discussion/Q  Or 3-5 minutes video then 10-20 minutes of live
presentation and then live Q?

(The post provides a better explanation but I am not sure to fully get
what you have in mind.)


> The Guix Days have never been a "real" conference, and always had a lot
> of room for discussions that start on the spot. I'd like to emulate
> this by keeping a lot of time out of the talk sessions to discuss
> whatever comes up naturally during our discussions.

A LibreAdventure [1 ]instance could help here.

1: 


> title: Announcing the second online Guix Days Conference
> date: 2021-12-10 00:00
> author: Guix Hackers
> slug: online-guix-days-2022-announce-1
> tags: Conference, Community
> ---

[...]

> # Until January 21: talks proposal
>
> Propose your talks by sending them to `guix-d...@gnu.org`.  Feel free to drop

This alias received a lot of spam, IIRC.  Do we use the same than past
year?  Or do we use guix-days2...@gnu.org?  And then drop it a couple of
weeks after the event.

> in `#guix` on irc.freenode.net to discuss what you would like to talk about
> before submitting. :)
>
> You can choose one of the following formats:
>
>  - Standard talk. 15-45 minutes pre-recorded presentation and a 5 minutes 
> lightning talk.
>The 5-minute presentation will be live, to refresh our minds, followed by
>a 30 minutes live Q
>  - BoF (birds of a feather, for a session with a small group who wants to talk
>about a specific topic) with no presentation. You may prepare something 
> live
>to spark conversations.

Although BoF is often used, last year, some people raised it is not so
common.  Naming is hard. ;-)  I am fine with this name, just to be sure
it is fine.


>  - Lightning talk with a 5 minutes live presentation
>
> In addition to the format you would like to choose, please describe your 
> session
> with 10 lines or more (for lightning talks, at least 1 sentence).
>
> Once you have sent your proposal, you will be notified in the coming days
> whether your talk be part of the Guix Day. Submit earlier to get more time to
> prepare your session!
>
> Even for live presentation, please prepare a back-up pre-recorded talk, so
> we can play it if you cannot attend or have a technical problem during the
> Guix days. The deadline for short presentations (5 minutes) is February 4.
>
> We welcome all kinds of topics from the community, especially your own 
> experience
> with Guix, your cool projects that involve Guix in some way, infrastructure 
> around
> guix (translations, continuous integration, ...), and any subject you feel

  ^ Guix

> should be discussed during the conference.
>
> Have a look at the topics from [the last 
> conference](/blog/2020/online-guix-day-announce-1/)
> for ideas, but don't hesitate to innovate in your proposals!
>
> # January 21 (or before) - 28: prepare your talk
>
> The aim of the pre-recorded talks is to demonstrate new features, what you are
> hacking on, introduce the subject for easing the live question and answer
> sessions or BoFs.  These pre-recorded talks should be **15-45 minutes
> long**.  Feel free to ask if you need help with the recording.
>
> You are free to choose whichever storage platform you want (e.g., your own
> website, a PeerTube instance, a Nextcloud instance, etc.), but we will need to
> have access to the original file so we can publish it later on
> [audio-video.gnu.org](https://audio-video.gnu.org).  Your video must be
> released under a license that at least allows anyone to copy and share it, for
> any purpose.

Ahah!  Maybe one day, the ones of last year will be there first. ;-)


> You will have to release the video publicly before January 28, so everyone
> has a chance to see it before the conference.  If you are not able to do so
> (for instance your server cannot handle a huge load), you can alternatively
> send us a private link to the video and we will upload it on
> [audio-video.gnu.org](https://audio-video.gnu.org).  If you decide to do so,
> you will need to have the video ready by January 26.

No, 

Re: How to handle package udev rules?

[Γυψ]

Dear Danny,

thanks! That lead me on the right track. In fact it's just

> sudo -E guix ...

without the Varibale name. "-E" passes the whole environment to
sudo. Now the package works (at least on my system) and the Logitech
presenter can be used under EXWM+xcompmgr under guix-system - Great! I
would be willing to provide the package description and maintain it if
that's helpful. Have to find out about the necessary steps then...

Cheers,
Alex

On Sun, Dec 12 2021, 23:37:06, Danny Milosavljevic  
wrote:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> On Sun, 12 Dec 2021 21:58:14 +0100
> g...@member.fsf.org wrote:
>
>> If I change my operating-system config to inlcude udev-rules from
>> package "projecteur" everything works fine - at least if I do it as a
>> regular user. As soon as I sudo the guix system reconfigure command the
>> package is known but it's code is not. Error message is:
>> 
>> > $ sudo guix system reconfigure ~/etc/config.scm
>> > ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
>> > no code for module (projecteur)  
>> 
>> Could it be the case that sudo'ed the variable GUIX_PACKAGE_PATH is not
>> known or not interpreted correctly? Does the package need to reside
>> somewhere else than in GUIX_PACKAGE_PATH?
>
> Yeah, sudo is very paranoid. You need to pass -E GUIX_PACKAGE_PATH to it:
>
>sudo -E GUIX_PACKAGE_PATH guix system reconfigure ~/etc/config.scm
>
> [[End of PGP Signed Part]]



signature.asc
Description: PGP signature

Re: Guix Documentation Meetup

[zimoun]

Hi,

On Sat, 11 Dec 2021 at 05:40, Blake Shaw  wrote:

> --
> tldr: is there also room to discuss contributing -- and possibly doing a
> sizeable makeover to -- the *Guile* documentation? If so, I could give a
> short 5 - 10 minutes presentation of what I think should be done (and
> would volunteer to do).
> --

Cool!

Minor comments trying to feed this worth proposal.


> I don't know if this is the correct forum for it, but I personally think
> the biggest documentation obstacle in Guix at the moment isn't so much
> in Guix, but instead in Guile. I found Guix via SICP & Racket about a
> year ago, and I remained a happy Racket hacker until a couple months ago
> when I decided to devote my free time to learning Guile in hopes of
> graduating to a Guix sensei one day.

I agree that the learning path in Guile land is not always smooth.
However, I do not think mastering Guile and/or its specificity is a
requirement to be a “Guix sensei”.  Obviously, better Guile
documentation improves the ecosystem, then it is an overall better. :-)


> While I've come to love Guile, compared to my experience with Racket its
> been quite burdensome for me to get in the hang of, something I attribute
> primarily to the structure of the docs, and not due to it being in any
> way more difficult than Racket. While with Racket I was writing
> useful programs in the standard #lang within my first week, with Guile
> I often find that what should be almost trivial winds up with a lot of
> time lost just trying to navigate and understand the docs. When I do
> figure things out, it turns out to be no more difficult than the equivalent
> in Racket, but a lack of consistency in the path that leads there in the
> docs cause hangups, which has made trivial scripts that should take an hour
> become weekend projects.

Well, I am not convinced it is because the structure of the docs.
Instead, I think it is because it is missing docs. :-)

If we compare apple to apple, here are the entry points:

https://docs.racket-lang.org/
https://www.gnu.org/software/guile/learn/

and so the Guile manual

https://www.gnu.org/software/guile/manual/guile.html

is a reference manual, which correspond to, mainly

https://docs.racket-lang.org/reference/

and also,

https://docs.racket-lang.org/guide/

I am not convinced you started Racket by these ones. ;-)

Indeed, one document on the Guile side vs two documents on Racket side;
the Guile manual could be split, I do not know if the core issue here.
Instead, IMHO, what is missing are all the others. :-) For instance,

https://htdp.org/

which is a really smooth introduction.  Somehow, it appears to me
that it is missing an introduction, a similar document as,

 https://www.gnu.org/software/emacs/manual/html_mono/eintr.html


> I know this isn't the Guile list, but when I've written on this topic in
> the IRC I've had no response, which make me think docs could be a
> bit of a bikeshedding topic in the community. But as Guile is
> fundamental to Guix and theres a lot of crossover btwn the communities,
> it seems like this could be a good time to raise these suggestions.

I agree.  For what it is worth, I tried once to quickly explain monad,
with the aim of “Store Monad“ in mind,

https://guix.gnu.org/manual/devel/en/guix.html#The-Store-Monad

After several discussions with strong Guix hackers, it appears to me
that they missed the general concept of monad, at least it was vague.
Therefore, I tried to write a simple explanation,

https://simon.tournier.info/posts/2021-02-03-monad.html

Bah, the other part has never seen the light, another story. :-)  Long
time ago, Pierre wrote down a quick introduction to Scheme, which ended
into the Cookbook,

https://guix.gnu.org/cookbook/en/guix-cookbook.html#Scheme-tutorials

>From my point of view, the missing documentation is the one between
newcomer and Reference manual.  For instance, setup a Guix/Guile
environment is not straightforward; Geiser helps, but even after some
time, I am often still fighting against it, and I do not know what
exists outside the Emacs world.


On the Guile land, one feature which really annoys me is the poor
discoverability from REPL; for an instance,

--8<---cut here---start->8---
$ guix repl
scheme@(guix-user)> ,a fold-packages
scheme@(guix-user)> ,use(gnu packages)
scheme@(guix-user)> ,a fold-packages
(gnu packages): fold-packages   #
scheme@(guix-user)> ,d fold-packages
Call (PROC PACKAGE RESULT) for each available package defined in one of
MODULES that matches SELECT?, using INIT as the initial value of RESULT.  It
is guaranteed to never traverse the same package twice.
--8<---cut here---end--->8---

well, IPython, GHCi, UTop (to name some I use) provide a complete
different experience.  Well, maybe resuming this discussion [1] is
worth.

1: 


> I've jotted down some notes on