Re: version-1.4.0 branch updated

[Leo Famulari]

On Mon, Jan 10, 2022 at 07:31:45PM -0500, Maxim Cournoyer wrote:
> The CI hasn't yet been switched on to build the branch yet; let's give a
> bit more time for other changes like this to have a chance to be
> considered/merged and then switch it on!  Perhaps Wednesday.

It seems risky to me to put world-rebuilding changes on the release
branch, because we won't have time to squash the bugs that inevitably
appear after deployment before releasing.

However, what do you think about also adding a fix for #53005,
"cryptsetup-static aborts opening LUKS2 volume with Argon2i PBKDF"? The
proposed fix changes glibc:

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

Re: [PATCH] website: Announce Guix days!

[Luis Felipe]

On Monday, January 10th, 2022 at 10:44 PM, Luis Felipe 
 wrote:

> I'm attaching a patch that fixes the jagged text in the source SVG and adds a 
> variant of the poster. And here are PNGs from each of them:
> 

> Original (fixed text):
> 

> https://luis-felipe.gitlab.io/media/2022/01/Guix-Days-online-2022.png
> 

> Variant:
> 

> https://luis-felipe.gitlab.io/media/2022/01/Guix-Days-2022-Variant.png

Actually, since those little i-shaped things below the GuixDays text are 
supposed to represent people, not i(s), I think this version might be better:

https://luis-felipe.gitlab.io/media/2022/01/Guix-Days-2022-Variant-B.png

If you'd like to use this one for the post, I can send a new patch later.

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: version-1.4.0 branch updated

[Maxim Cournoyer]

Hi Ricardo,

Ricardo Wurmus  writes:

> Maxim Cournoyer  writes:
>
>> If nobody has another world rebuilding change deemed necessary in time
>> for the release, I suggest we enable substitutes on the branch soon, and
>> then get busy trying to get 'make dist' to succeed so that we can issue
>> a first RC.
>
> I’ve got some world rebuilding changes in wip-texlive.  I intended to
> add more, but they could be merged right now.  They fix broken font
> search in pdflatex, xelatex, and lualatex.

OK!  I've reviewed what's in wip-texlive, and it LGTM!  Feel free to
rebase the branch on top of version-1.4.0 and then merge into it.  I
don't intend to rewrite the branch at this point, so we can collaborate
on it.

The CI hasn't yet been switched on to build the branch yet; let's give a
bit more time for other changes like this to have a chance to be
considered/merged and then switch it on!  Perhaps Wednesday.

Thank you!

Maxim

Re: [PATCH] website: Announce Guix days!

[Luis Felipe]

I'm attaching a patch that fixes the jagged text in the source SVG and adds a 
variant of the poster. And here are PNGs from each of them:

Original (fixed text):
https://luis-felipe.gitlab.io/media/2022/01/Guix-Days-online-2022.png

Variant:
https://luis-felipe.gitlab.io/media/2022/01/Guix-Days-2022-Variant.png





From 8386923ea2f6d700998fae0f9811a017c61b3bb7 Mon Sep 17 00:00:00 2001
From: Luis Felipe 
Date: Mon, 10 Jan 2022 17:24:41 -0500
Subject: [PATCH] artwork: Update posters for Guix Days.

* logo/Guix-Days-2020.svg: Move to promotional/Guix-Days-Initial.svg and
fix jagged text.
* promotional/Guix-Days-Variant.svg: New poster.
---
 .../Guix-Days-Initial.svg | 158 ++--
 promotional/Guix-Days-Variant.svg | 799 ++
 2 files changed, 853 insertions(+), 104 deletions(-)
 rename logo/Guix-Days-2020.svg => promotional/Guix-Days-Initial.svg (71%)
 create mode 100644 promotional/Guix-Days-Variant.svg

diff --git a/logo/Guix-Days-2020.svg b/promotional/Guix-Days-Initial.svg
similarity index 71%
rename from logo/Guix-Days-2020.svg
rename to promotional/Guix-Days-Initial.svg
index 6c1ac06..98b2d07 100644
--- a/logo/Guix-Days-2020.svg
+++ b/promotional/Guix-Days-Initial.svg
@@ -2,24 +2,24 @@
 
 
 http://purl.org/dc/elements/1.1/;
-   xmlns:cc="http://creativecommons.org/ns#;
-   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
-   xmlns:svg="http://www.w3.org/2000/svg;
-   xmlns="http://www.w3.org/2000/svg;
-   xmlns:xlink="http://www.w3.org/1999/xlink;
-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape;
width="114.80407mm"
height="48.904305mm"
viewBox="0 0 114.80407 48.904305"
version="1.1"
id="svg4715"
-   inkscape:version="0.92.4 (5da689c313, 2019-01-14)"
-   sodipodi:docname="Guix-Days-2020.svg"
-   inkscape:export-filename="/home/ludo/src/guix-artwork/logo/Guix-Days-2019.png"
+   inkscape:version="1.1.1 (3bf5ae0d25, 2021-09-20)"
+   sodipodi:docname="Guix-Days-Initial.svg"
+   inkscape:export-filename="Guix-Days-2022.png"
inkscape:export-xdpi="169.83781"
-   inkscape:export-ydpi="169.83781">
+   inkscape:export-ydpi="169.83781"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape;
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
+   xmlns:xlink="http://www.w3.org/1999/xlink;
+   xmlns="http://www.w3.org/2000/svg;
+   xmlns:svg="http://www.w3.org/2000/svg;
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
+   xmlns:cc="http://creativecommons.org/ns#;
+   xmlns:dc="http://purl.org/dc/elements/1.1/;>
   
 
 
-
 
-
-  
-  
-  
-  
-  
-
 
+ inkscape:window-y="32"
+ inkscape:window-maximized="1"
+ showguides="false"
+ inkscape:pagecheckerboard="0"
+ inkscape:showpageshadow="false"
+ inkscape:snap-page="true" />
   
 
@@ -155,7 +119,6 @@
 image/svg+xml
 http://purl.org/dc/dcmitype/StillImage; />
-
   
 
   
@@ -225,49 +188,36 @@
style="font-style:normal;font-weight:bold;font-size:144px;line-height:125%;font-family:Sans;-inkscape-font-specification:'Sans Bold';letter-spacing:0px;word-spacing:0px;fill:#33;fill-opacity:1;stroke:none"
d="m 667.1005,1220.7867 -11.87587,-16.0794 h 11.14098 l 6.73161,9.7593 6.81981,-9.7593 H 691.058 l -11.87586,16.0206 12.46377,16.9026 h -11.14096 l -7.40773,-10.4061 -7.31953,10.4061 h -11.14097 l 12.46378,-16.8438" />
   
-  
-30–31 JANUARY 2020BRUSSELS
-Days
-  
+  Days
+  19-20 FEBRUARY 2022ONLINE!
 
   
 
diff --git a/promotional/Guix-Days-Variant.svg b/promotional/Guix-Days-Variant.svg
new file mode 100644
index 000..61a5385
--- /dev/null
+++ b/promotional/Guix-Days-Variant.svg
@@ -0,0 +1,799 @@
+
+
+
+http://www.inkscape.org/namespaces/inkscape;
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
+   xmlns:xlink="http://www.w3.org/1999/xlink;
+   xmlns="http://www.w3.org/2000/svg;
+   xmlns:svg="http://www.w3.org/2000/svg;
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#;
+   xmlns:cc="http://creativecommons.org/ns#;
+   xmlns:dc="http://purl.org/dc/elements/1.1/;>
+  
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+
+  
+  
+  
+  
+
+
+  
+  
+
+
+
+  
+  
+
+
+
+  
+  
+
+
+
+
+  
+
+
+
+  
+  
+  
+
+  
+image/svg+xml
+http://purl.org/dc/dcmitype/StillImage; />
+  
+
+  
+  
+
+  
+  
+  
+ 

Re: version-1.4.0 branch updated

[Ricardo Wurmus]

Maxim Cournoyer  writes:

> If nobody has another world rebuilding change deemed necessary in time
> for the release, I suggest we enable substitutes on the branch soon, and
> then get busy trying to get 'make dist' to succeed so that we can issue
> a first RC.

I’ve got some world rebuilding changes in wip-texlive.  I intended to
add more, but they could be merged right now.  They fix broken font
search in pdflatex, xelatex, and lualatex.

-- 
Ricardo

Re: Return back original implementation for text-config serialization

[Liliana Marie Prikler]

Am Montag, dem 10.01.2022 um 12:49 +0300 schrieb Andrew Tropin:
> [T]he whole point of escape hatch is to make it possible to reuse
> existing files directly without any manipulation on them and importer
> should demonstrate how to do it.
That'd make more sense if the importer copied bashrc to some well-known
location (e.g. ~/.config/guix/data/.bashrc) and then used that rather
than the file it wishes to replace.  IIRC that was one suggested
behaviour of Guix Home in the past, but it didn't get approval because
users wouldn't typically ask for that copying to happen.  If you make
it so that plain-file is used normally, but add a switch to express
things in terms of local-file instead, that'd work.  

OTOH, I do think local-file is already well-documented on its own, so
perhaps it'd only take a cookbook entry to show it in combination with
Guix Home and an explanation as to why Guix Home doesn't do that
normally while explaining all the caveats.

> If importer internally do some manipulation (escaping) with the
> content of the file and places the result in the string in scheme
> file, user won't be able to replicate such process easily for other
> services, which not covered by the importer. If I understood
> correctly what you meant in the first message.
Yes, the user would have to manually quote every new line of code
they're adding, but they're free to use all other file-like objects,
including local-file.  Having (bashrc (local-file ".bashrc")), whether
implemented on top of slurp-file-gexp or not, is inherently dangerous,
though.

> > The point I'm making is that we shouldn't swap out one bad
> > abstraction for another, but pave the road towards good
> > abstractions, e.g. G-expressions in the way the rest of Guix
> > typically uses them.
> 
> Actually, for me, the original implementation looks consistent with
> how the rest of Guix treats G-expressions (uses already known
> abstraction) and only new one intoduces a new abstraction.
That's the point.  The old style works just like you'd expect it to, it
becomes a problem when you try to feed it stuff like slurp-file-gexp to
work around some limitations in a way I'm not convinced makes sense.

> [I]t's already possible to achieve the same [-- merging multiple
> bashrc snippets into a single file --] with gexps/file-like in both
> new and old text-config implementations.
I find the lack of services in your example concerning, but I'll take
your word for it.  In that case, using a gexp for bashrc in the typical
sense is probably the best idea, but we still need to do something with
the reliance on slurp-file-gexp.

Cheers

> 
PS:
> It's offtopic, but when you will have time please take a look at
> https://issues.guix.gnu.org/52388.
Hahaha, it's been a month, hasn't it?  There's some aesthetic
unpleasanties, so I'm not sure if I'll upstream it with slight
stylistic changes or give you some harsher feedback, but I'll try to
decide this weekend.

version-1.4.0 branch updated

[Maxim Cournoyer]

Hello,

I've pushed a version-1.4.0 branch refresh that tackled a few issues:

- #52269 (sitecustomize.py: Honor .pth files.)
- #52574 (glib: Fix cross-compilation.)
- #52411 (gnu: pciutils: Fix the conditional for the kmod input.)
- #52519 (gnu: glibmm-2.64: Fix libsigc++ propagation.)

Since touching sitecustomize.py was a world rebuilding change, I've
squeezed a few items picked from our guix-patches tracker or newly
authored, such as:

- update meson to 0.60.3 and undo workarounds introduced for
  0.60.2.
- update python to 3.9.9
- update cmake to 3.21.4
- update mesa to 21.3.2
- absorb binutils-next into binutils

and more!

You can find the changes introduced in the branch by issuing git log
'origin/master..origin/version-1.4.0'.

If nobody has another world rebuilding change deemed necessary in time
for the release, I suggest we enable substitutes on the branch soon, and
then get busy trying to get 'make dist' to succeed so that we can issue
a first RC.

We'll also need to write the website materials such as the release blog
post and edit that NEWS file with the most noteworthy changes that have
gone into this release since 1.3.0.

Thank you!

Maxim

Re: [PATCH] website: Announce Guix days!

[Luis Felipe]

Hi, Julien.

On Monday, January 10th, 2022 at 5:16 PM, Julien Lepiller jul...@lepiller.eu 
wrote:

> Attached is the full patch, with the blog post, banner and logo. I'll
> 

> push on Wednesday if there is no answer.

I tried the patch locally and found some issues:

The link from the banner to the blog post fails:

#+begin_src
(div
 (@ (class "message-box msg-info"))
 (p ,(G_ `("Online conference February 19-20. "
   ,(G_ `(a
  (@ (href "/blog/2020/online-guix-days-2022-announce-1/"))
  "Learn more"))
   "!"
#+end_src

I think the correct URL path should be:

/en/blog/2022/online-guix-days-2022-announce-1/

That is, with language tag and year 2022.

In the blog post, I see that:

1. Part of the text in the image looks jagged. I can patch the source SVG later 
to fix that, and send you an updated PNG.
2. IRC information is referring to irc.freenode.net instead of libera.
3. Link to the last conference fails. It reads:

[the last conference](/blog/2020/online-guix-day-announce-1/)

I think the correct path should be:

/en/blog/2020/online-guix-day-announce-1/

publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: ImageMagick from 2020?

[zimoun]

Hi Maxime,

Thanks!

On Mon, 10 Jan 2022 at 19:36, Maxime Devos  wrote:

> guix download 
> https://git.centos.org/sources/ImageMagick/c7/ed27964d872abc81dc2388d333874766058a9b5d
> [downloading]
> 1jxjxhnvznpbdigry2cgxx94cx6k6y3rs40a464n5yln29s1qlz1

Then after,

cp 
/gnu/store/qv9adcfsvhm79sinv36dznvzzvw0db5y-ed27964d872abc81dc2388d333874766058a9b5d
/tmp/ImageMagick-6.9.10-68.tar.xz
guix download file:///tmp/ImageMagick-6.9.10-68.tar.xz

and life can be back as usual. :-)

> It might be interesting to teach (guix build download) to fallback to
> the archives of CentOS, Debian, ...

I think it could be a nice idea.


Cheers,
simon

Re: ImageMagick from 2020?

[Maxime Devos]

Timothy Sample schreef op ma 10-01-2022 om 13:01 [-0500]:
> Hi zimoun,
> 
> zimoun  writes:
> 
> > We probably do not have this item.  Since it is 'xz', it is somehow
> > expected because it is works in progress.
> 
> XZ support is working in Disarchive now.  I’m hosting quite a few XZ
> specifications at .
> 
> > Can someone confirm we do not effectively have this item in our infra?
> 
> According to my logs, I tried to get it a month ago and it failed then,
> too.  If you track it down, let me know and I’ll ingest it.

From repology, I found that CentOS c7 has ImageMagick 6.9.10-68:

https://git.centos.org/rpms/ImageMagick/blob/c7/f/SPECS/ImageMagick.spec

CentOS keeps its copy of the source code at

https://git.centos.org/sources/ImageMagick/c7/

there are two files there, seems like they are named after some kind of
hash?

To determine the hash, you can look at
https://git.centos.org/rpms/ImageMagick/blob/c7/f/.ImageMagick.metadata

It's this file you need:

https://git.centos.org/sources/ImageMagick/c7/ed27964d872abc81dc2388d333874766058a9b5d

The hash checks out:

guix download 
https://git.centos.org/sources/ImageMagick/c7/ed27964d872abc81dc2388d333874766058a9b5d
[downloading]
1jxjxhnvznpbdigry2cgxx94cx6k6y3rs40a464n5yln29s1qlz1

It might be interesting to teach (guix build download) to fallback to
the archives of CentOS, Debian, ...

Greetings,
Maxime.


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

Re: Alternative solution to stat storm problem

[Tom Scogland]

Hi Ludovic, thanks for your thoughts.

You’re right, the LD_LIBRARY_PATH will not change the loading order, but using 
LD_PRELOAD will by the same mechanism we’re using, pre-filling the cache with a 
library at the same soname.  As part of other explorations we’re doing around 
tweaking or wrapping the loader, it may be possible to get semantics like 
LD_LIBRARY_PATH other ways, but at the moment the goal is to make a program 
that will correctly load all the dependencies it would have loaded were it run 
in the same environment it was built in, despite LD_LIBRARY_PATH or RUNPATH in 
dependencies or similar.  Making a little tool that would override the same way 
LD_LIBRARY_PATH would have would be relatively straightforward though, would 
that be worth exploring do you think?

-Tom

On 8 Jan 2022, at 19:05, Farid Zakaria wrote:

> 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://urldefense.us/v3/__https://github.com/Mic92/dlopen-resolver__;!!G2kpM7uM-TzIFchu!gFf3bOVCBsw_Ld35XMHl8Y0nYb0k7ikmOrOuo5SGPLCLqrCqx5qaP3giJkQTBeRD1A$
>
> 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://urldefense.us/v3/__https://www.openwall.com/lists/musl/2021/12/21/1__;!!G2kpM7uM-TzIFchu!gFf3bOVCBsw_Ld35XMHl8Y0nYb0k7ikmOrOuo5SGPLCLqrCqx5qaP3giJkSfjFvBcw$
>>  )
>> 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: ImageMagick from 2020?

[Timothy Sample]

Hi zimoun,

zimoun  writes:

> We probably do not have this item.  Since it is 'xz', it is somehow
> expected because it is works in progress.

XZ support is working in Disarchive now.  I’m hosting quite a few XZ
specifications at .

> Can someone confirm we do not effectively have this item in our infra?

According to my logs, I tried to get it a month ago and it failed then,
too.  If you track it down, let me know and I’ll ingest it.


-- Tim

ImageMagick from 2020?

[zimoun]

Hi,

Trying to get 'hs-to-coq' working, I am travelling back in 2020 with
commit: 1ac4004502.  Then, I hit ImageMagick mismtach.

--8<---cut here---start->8---
$ guix time-machine --commit=1ac4004502 -- build imagemagick
guile: warning: failed to install locale
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
building 
/gnu/store/ngslsnxgy9syjs97cb7yv4744hllr6vx-ImageMagick-6.9.10-68.tar.xz.drv...

Starting download of 
/gnu/store/5qw3rrbk7679kd11147ks6jjcffmvv8m-ImageMagick-6.9.10-68.tar.xz
>From 
>https://sunsite.icm.edu.pl/packages/ImageMagick/ImageMagick-6.9.10-68.tar.xz...
download failed 
"https://sunsite.icm.edu.pl/packages/ImageMagick/ImageMagick-6.9.10-68.tar.xz; 
404 "Not Found"

Starting download of 
/gnu/store/5qw3rrbk7679kd11147ks6jjcffmvv8m-ImageMagick-6.9.10-68.tar.xz
>From 
>http://mirrors-usa.go-parts.com/mirrors/ImageMagick/ImageMagick-6.9.10-68.tar.xz...
following redirection to 
`https://go-parts.com/mirrors/ImageMagick/ImageMagick-6.9.10-68.tar.xz'...
downloading from 
http://mirrors-usa.go-parts.com/mirrors/ImageMagick/ImageMagick-6.9.10-68.tar.xz...
 ImageMagick-6.9.10-68.tar.xz   
70.7MiB/s 00:00 | 48KiB transferred
sha256 hash mismatch for 
/gnu/store/5qw3rrbk7679kd11147ks6jjcffmvv8m-ImageMagick-6.9.10-68.tar.xz:
  expected hash: 1jxjxhnvznpbdigry2cgxx94cx6k6y3rs40a464n5yln29s1qlz1
  actual hash:   1j2r0l2j8yglhnbhi7pj14fv38zaxvxs6v6wx462fn6x1cq4xr00
hash mismatch for store item 
'/gnu/store/5qw3rrbk7679kd11147ks6jjcffmvv8m-ImageMagick-6.9.10-68.tar.xz'
build of 
/gnu/store/ngslsnxgy9syjs97cb7yv4744hllr6vx-ImageMagick-6.9.10-68.tar.xz.drv 
failed
View build log at 
'/var/log/guix/drvs/ng/slsnxgy9syjs97cb7yv4744hllr6vx-ImageMagick-6.9.10-68.tar.xz.drv.bz2'.
cannot build derivation 
`/gnu/store/xg2zdql0gpyavx2s4kv408gdvmpn18c5-imagemagick-6.9.10-68.drv': 1 
dependencies couldn't be built
guix build: error: build of 
`/gnu/store/xg2zdql0gpyavx2s4kv408gdvmpn18c5-imagemagick-6.9.10-68.drv' failed
--8<---cut here---end--->8---


We probably do not have this item.  Since it is 'xz', it is somehow
expected because it is works in progress.

Can someone confirm we do not effectively have this item in our infra?

(It would mean that 1818 dependent packages thus not "lost".)

Cheers,
simon

[PATCH] website: Announce Guix days!

[Julien Lepiller]

Le Thu, 06 Jan 2022 20:54:29 +0100,
zimoun  a écrit :

> Hi Julien,
> 
> On Sat, 11 Dec 2021 at 02:37, Julien Lepiller 
> wrote:
> 
> > I suggest that we have these days right after Fosdem, Monday and
> > Tuesday. This should give us just a few more days to prepare, as I
> > think we're starting pretty late already. If you prefer to have
> > them before fosdem, I can change the blog post of course.  
> 
> What is the final decision?  No strong opinion on the date, so let
> pick the ones your proposed.  How does it sound?
> 

Sorry that I haven't been working on that before. Since we're already
this late, I suggest to postpone the guix days and have them two weeks
later. this should give us enough time to rest from Fosdem madness and
prepare :)

Attached is the full patch, with the blog post, banner and logo. I'll
push on Wednesday if there is no answer. Could one of our maintainers
resurrect the old guix-days email alias? It would contain the
maintainers, me and Simon for now. Anyone else interested?

> 
> > Also, we need to secure a BBB instance :)  
> 
> Well, I think we will find one.  Fosshost is not an option though.
> 
> 
> Cheers,
> simon

>From b1ed3af5838b65293441f62e5d6447357be849b4 Mon Sep 17 00:00:00 2001
From: Julien Lepiller 
Date: Mon, 10 Jan 2022 18:05:05 +0100
Subject: [PATCH] website: Add conference announcement.

* website/posts/online-guix-days-2022-announce-1.md: New file.
* website/static/blog/img/Guix-Days-online-2022.png: New file.
* website/apps/base/templates/theme.scm: Add announce banner.
---
 website/apps/base/templates/theme.scm |   9 +-
 .../posts/online-guix-days-2022-announce-1.md | 126 ++
 .../static/blog/img/Guix-Days-online-2022.png | Bin 0 -> 25862 bytes
 3 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 website/posts/online-guix-days-2022-announce-1.md
 create mode 100644 website/static/blog/img/Guix-Days-online-2022.png

diff --git a/website/apps/base/templates/theme.scm b/website/apps/base/templates/theme.scm
index 81815b6..8fe188c 100644
--- a/website/apps/base/templates/theme.scm
+++ b/website/apps/base/templates/theme.scm
@@ -120,7 +120,14 @@
  (body
   ,(navbar #:active-item active-menu-item)
 
-  ;; NOTE: Comment this message out when it is not needed anymore.
+  ;; NOTE: Comment these messages out when they are not needed anymore.
+  (div
+   (@ (class "message-box msg-info"))
+   (p ,(G_ `("Online conference February 19-20. "
+ ,(G_ `(a
+(@ (href "/blog/2020/online-guix-days-2022-announce-1/"))
+"Learn more"))
+ "!"
   ;(div
   ; (@ (class "message-box msg-info"))
   ; (p ,(G_ `("Online conference November 22nd. "
diff --git a/website/posts/online-guix-days-2022-announce-1.md b/website/posts/online-guix-days-2022-announce-1.md
new file mode 100644
index 000..4e5c512
--- /dev/null
+++ b/website/posts/online-guix-days-2022-announce-1.md
@@ -0,0 +1,126 @@
+title: Announcing the second online Guix Days Conference
+date: 2022-01-10 00:00
+author: Guix Hackers
+slug: online-guix-days-2022-announce-1
+tags: Conference, Community
+---
+
+The Guix hackers are very happy to announce the second online Guix Days
+Conference on **19 & 20 February 2022**.  This conference is open to everyone
+and will be held entirely online.  Want to speak?  Submit your proposal!
+
+Important dates:
+
+1. **February 8**: Deadline for talks proposal.
+1. **February 12**: Deadline for releasing your pre-recorded talks.
+1. **February 14**: Release of the schedule.
+1. **February 19**: Conference day!
+1. **February 20**: Conference day!
+
+![Guix Days logo](/static/blog/img/Guix-Days-online-2022.png)
+
+The agenda of these two days is:
+
+ - pre-recorded talks with live question and answer sessions
+ - birds of a feather (BoF) sessions
+ - lightning round talks, if possible
+ - retrospective and future of Guix
+ - hack together
+
+Talks will be released **before** the conference day, **watch them as soon
+as possible**! And **no registration fee**.
+
+# Until February 8: talks proposal
+
+Propose your talks by sending them to `guix-d...@gnu.org`.  Feel free to drop
+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.
+ - 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 

Re: Guix Documentation Meetup

[André A . Gomes]

Matt  writes:

>  > I'm not connected with Guix with any way - a mere enthusiast and
>  > observer.
>
> I'm not sure what you mean.  Being excited about something and taking
> the time to observe it, like listening to music, is a connection,
> right?

I mentioned because ultimately the final word isn't mine :)

> I'm curious, what makes you feel not connected with Guix?

I feel connected "philosophically" as a (basic) user, but not as a
contributor.  Guix, by itself, is a complex system.  Honestly, I suck at
using Guile in a project of this scale (no, I don't think the
documentation is poor).  I have some understanding in Emacs and
slime/common lisp systems, but I still need to dive into geiser.  There
are difficulties of other sorts as well.  This is a Unix system and that
fact alone requires knowledge and experience.  I assume that most core
contributors are/were involved in other efforts such as Debian, Arch,
Gentoo, etc.  Besides experience in "system administration" and HPC.

I don't know how many people in the community have
non-CS/Unix/programming backgrounds so I share some personal thoughts
below.  It's not that I want to share my life, but it might resonate
with the experiences of others.

My background is in theoretical physics and pure maths.  I never cared
about computers or computation, until I had to find a job circa 2018.  I
landed on a wind energy company which owns a supercomputer (running
GNU/Linux of course), and without me realising, I was being "forced" to
be a software developer.  I had to learn a lot and fast.  Soon, I
understood that the bottleneck on the success of a given project isn't
in the lack of domain-specific/scientific knowledge, but in the lack of
robust (software) tools and "software knowledge" in general.  Most
"scientists" think: "these IT/programmers can't do their work properly".
This division ("scientists" and "programmers") is toxic.  Yes, it's VERY
hard to find people who do both well.  Guix a step towards tearing this
wall apart for good.  It's not by chance that Guix has a strong presence
on HPC.  (Yes, it's hell to depend on an admin to install stuff).  It's
interesting to note that the effort comes from the "programmers" side.
I think the bottleneck on Guix's world domination is precisely because
"scientists" generally make little effort in that regard.  It's hard to
make "non-sexy" things look sexy.  Go and tell a "data-scientist" about
reproducible builds.  Good luck.

It's ok if things are overwhelming and hard.  Things eventually click
and start to make sense.  


--
André A. Gomes
"Free Thought, Free World"

Re: "make dist" fails ... en@boldquote: warning: PO file headder missing or invalid

[Mathieu Othacehe]

Hello,

>> > I've also in the past implored to set up a ci job for "make dist" to
>> > make it at least easier to figure out which commits trigger these
>> > issues... how can I help move that forward? :)
>
> Mathieu, what does Cuirass need to make that happens?

That would require to have a derivation running an equivalent of the
"make dist" command, in the same spirit as the "tarball-jobs" procedure
of the (gnu ci) module I guess.

Thanks,

Mathieu

Re: Guix wiki

[Josua Stingelin]

Hi Matt,

Thanks for the summary!

Disclaimer: I'm currently not a guix user.
I've been following the gnunet for a while so I felt qualified to comment.

> Concern 1: guix will be soon be distributed over gnunet
> 
>   I'm not familiar with gnunet.  Has this come to fruition? Are the
>   two mutually exclusive? Is it not possible to host the same text
>   using both gnunet and www? If the www wiki would mirror the gnunet
>   wiki, is there something that prevents gnunet mirroring www?

Guix could provide an endpoint in the gnunet network for users that prefer to
use it. However there's no reason to prevent it from being accessible using the
current TCP/IP stack.

The goal of gnunet is to replace the TCP/IP stack. It is built as an overlay
and underlay network. It can run on TCP/IP but could also replace it. Every
application using TCP/IP would have to be converted to use gnunet or
gnunet would have to emulate TCP/IP. Until then they'll run in parallel.

> Concern 5: having a wiki may confuse what the primary source of documentation 
> is (i.e. the manual)
> 
>   I'm not sure I understand why this is a problem. Of course,
>   confusion should be minimized.  But the primary source of
>   documentation should be the one that best helps the user.  Ideally,
>   that is the manual.  Is there a negative consequence for the primary
>   source not being the manual?  For example, how many of you have used
>   the Arch wiki to solve problems for something other than the Arch
>   system?  Is that a problem?

I suppose that depends on the user. As a new linux user I tended to only use
the information available for my distro. Only after knowing the differences
from the distros have I started to use a wider spectrum for information.

That may primarily be a question of the target audience for guix?

> Concern 8: the manual should have all the examples necessary for people to 
> understand how to tweak things
> 
>   Agreed.  Contributing to documentation also shouldn't be as
>   difficult as it currently is, but here we are.  Let's figure it out
>   together. :)

What about an online editing interface (analogous to Wikipedia) where everyone
can make edit suggestions.  Optimally directly converted to a patch by the
software.  Changes to the cookbook would have to be merged by the maintainers
and the community based wiki could either have a group of editors or a
consensus based workflow.


Personally I believe having one resource for information to be the preferred
solution. Maybe the Gentoo wiki could be a source of inspiration on what we'd
like to achieve?  (https://wiki.gentoo.org/wiki/Main_Page)

Kind Regards,
Josua


signature.asc
Description: PGP signature

Planet of Guix-related posts?

[zimoun]

Hi,

My two points are:

 1. we could have a Guix planet -- we should avoid the cathedral for
quick recipes
 2. too many different goals are directed to the Cookbook


Well, my point is: instead of cathedral with an authority accepting
patches after review, why not a web syndication (bazaar) as a Planet
collecting various blogs.  This would help to stay aware.  For
instance, I read,

https://planet.haskell.org/
https://ocaml.org/community/planet/
https://planet.emacslife.com/
https://planet.scheme.org/

and many others and for Guix-related, basically, I use Ludo's toots as
such Planet.  Thanks Ludo. ;-)

Bah, I do not know if many blogs about Guix are around and how
frequently they would be updated.

Similarly, some time ago, an "awesome list" had been started and now,
quickly searching, I find 2:

https://github.com/techenthusiastsorg/awesome-guix
https://sr.ht/~lle-bout/awesome-guix/

Therefore, doing so...

On Sat, 8 Jan 2022 at 17:25, Matt  wrote:

> I have two documents written in Org:
> 1. http://excalamus.com/test-guix-case-study-plover-python-dictionary.html

(On a side note between parenthesis, we should avoid to fall into the
"Package Definition" tutorial fallacy; as explained here for monads
https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/.
And I wrote one post about monad and another about Packaging. ;-)
However, I think the official documentation has enough materials for
starting to package. End of parenthesis.)


> 2. http://excalamus.com/2021-10-06-guix-debug.html

...it is possible to individually write using our preferred tools and
managed our way.

 Moreover, for instance, times to times, I write entries to my "blog":

https://simon.tournier.info/posts/

For example, this edited

had been published before there
.

Therefore, maybe people not afraid to write to their own blog but
afraid (or not knowing how to) to submit patches would provide
material for the official blog post, who knows. :-)


Last, we have to distinguish between "temporary" content and
well-maintained documentation.  We discussed many times the Cookbook
and I think what we are trying with a limited success that this
document fits too much goals at the same time.  For instance, if I
would have to send a patch for fixing Wikipedia typo or adding a quick
paragraph about preconditioner of linear system, I would never just do
one or the other.  The Cookbook is currently too rigid for quick
half-backed recipes.

In my views, for what they are worth, I think the level of
documentation should be:

 - manual as it is now
 - cookbook turned into a step by step comprehensive tutorial
 - wiki being a how-to-quickly-fix, similar to Arch wiki for instance

We have Guix manual which is really great.  We have Guile manual which
is really great once you know what you want.  What is missing in a
document in the middle and something similar to a wiki where it is
easy to edit and change.

For what the analogy is worth, Emacs manual and Emacs Lisp manual are
doing their job as manual.  However, if one is new to programming, the
document An Introduction to Programming in Emacs Lisp [1] is a great
resource because it is in the middle, IMHO.  The Cookbook should act
similarly.  Something as an official kind-of tutorial.

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

And somewhere an easy to edit half-maintained not-really reviewed wiki
where anyone could provide their material.


Cheers,
simon

Re: Branch with only available substitutes ?

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

Also thanks for your reply, I'll try it ;)


zimoun  writes:

> Hi,
>
> In case you missed it:
>
> 
>
> which does not solve the issue but helps. :-)
>
>
> On Sun, 9 Jan 2022 at 22:10, Nicolas Graves via Development of GNU
> Guix and the GNU System distribution.  wrote:
>
>> I find myself often waiting for heavy packages (ungoogled-chromium,
>> cargo...) to be built as substitutes before updating my system and I
>> find it a bit long to my personal taste.
>>
>> Would it be possible to add a branch in guix sources following only
>> available substitutes, so that each time I pull, I can immediatly
>> and quickly update. Or would that need to stay as someone's personal
>> project ?
>
> Adding what you are proposing would not change your "complaint". ;-)
> Each time you would pull, you would stay on the same revision because
> the substitutes would not be ready yet and so no quick update.  You
> would have to wait and run again "guix pull" later, probably staying
> on the same revision because the substitutes would not be ready.  In
> the meantime, you would miss new features or new security fixes for
> others of some packages you are using.
>
> However, I agree that's annoying.  Some time ago (before the link
> above), I used a script along these lines:
>
> #!/bin/bash
>
> # url-cache-directory from guix/git.scm
> # pjmkgl... = hash("https://git.savannah.gnu.org/git/guix.git;)
> CACHE=~/.cache/guix/checkouts
> CHECKOUT=${CACHE}/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq
>
> printf "Updating local checkout:\n'$CHECKOUT'..."
> git -C $CHECKOUT fetch -q
> echo " done."
>
> guix pull --commit=$(git -C $CHECKOUT\
>  log \
>  --before=$(date --date='2 weeks ago' +%Y-%m-%d) \
>  --format="%h" | head -n1)   \
>  $@
>
> echo "done."
> exit 0
>
> to lag by 2 week behind origin/master and so be almost sure to have
> the substitutes -- if their build success-ed. ;-)
>
> Well, yeah it's annoying to run "guix pull", check with "guix
> weather", and depending on the result upgrade or not -- note that the
> exit status cannot be used [1].  When all that could be automatized.
> #47929, as Mathieu said, is grouping "guix pull" and "guix weather".
> Maybe we could imagine an option to "guix upgrade" coupling "guix
> weather"; somehow the converse of 'no-substitutes' or the converse of
> 'fallback', i.e., do not try to locally build if the substitutes is
> not available.  I do not know.
>
> 1: 
>
> Cheers,
> simon

Re: Branch with only available substitutes ?

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

Thanks all for your answer.

Of course Maxime, wasn't meant to be mean or anything.

I'm actually willing to help, although a bit limited in time in the
coming weeks.

What would be needed to help your pending patch @Mathieu ? Not sure if
my scheme is already good enough, but I can try and take a look.

Cheers,

Nicolas

Mathieu Othacehe  writes:

> Hello,
>
>> Short answer: yes, but someone has to not just ask whether it's
>> possible or tell it ‘should be easy’, and actually implement all this.
>> Also, have a look at channel-with-substitutes-available.
>> It's not sufficiently general for your use case though.
>
> There's also a pending patch extending this procedure to support
> manifests: https://issues.guix.gnu.org/47929.
>
> It still needs some work but it could be conceptually close from what
> Nicolas is asking.
>
> Mathieu

Re: "make dist" fails ... en@boldquote: warning: PO file headder missing or invalid

[zimoun]

Hi,

On Sat, 8 Jan 2022 at 01:47, Vagrant Cascadian  wrote:

> > I've also in the past implored to set up a ci job for "make dist" to
> > make it at least easier to figure out which commits trigger these
> > issues... how can I help move that forward? :)

Mathieu, what does Cuirass need to make that happens?


Cheers,
simon

Re: Guix Documentation Meetup

[Matt]

 > Please don't misinterpret the following comments.  But I don't see how the 
 > 1st one
 > could land in a cookbook.  

You're fine, I more or less agree with you. I think something like it with a 
different package would be helpful.  What I wrote probably isn't it.

 > Yes, I'm not a fan of wiki.  Regardless, the
 > efforts of such a wiki should perhaps land outside the scope of Guix
 > (i.e. it should be non-"official").

I started a thread to talk about a Guix wiki. I'd like to hear  more of your 
thoughts about it.

 > I'm not connected with Guix with any way - a mere enthusiast and
 > observer.

I'm not sure what you mean.  Being excited about something and taking the time 
to observe it, like listening to music, is a connection, right?  

This conversation is a great example of how documentation affects community and 
engagement.  Your perspective is valuable!  

I'm curious, what makes you feel not connected with Guix?

 > I hope you continue to write great articles like these!

I appreciate the encouragement.  Thank you.

Re: Guix Documentation Meetup

[Matt]

> Also if I understand things correctly there are 
 > actually plans to host a documentation meetup this Saturday (maybe at 
 > around 10:30 AM ET as the last ones).
 
Thank you!  I should be able to attend.

Is that January 15, at 10:30 am EST using 
https://meet.nixnet.services/b/jga-rtw-ahw-yky?

Was that announced anywhere?

> I'm sure your participation and potential contributions to the 
> documentation meetup would be very welcome at this point in time :)

I hope so. I look forward to meeting everyone and hearing their thoughts.

Re: Branch with only available substitutes ?

[zimoun]

Hi,

In case you missed it:



which does not solve the issue but helps. :-)


On Sun, 9 Jan 2022 at 22:10, Nicolas Graves via Development of GNU
Guix and the GNU System distribution.  wrote:

> I find myself often waiting for heavy packages (ungoogled-chromium,
> cargo...) to be built as substitutes before updating my system and I
> find it a bit long to my personal taste.
>
> Would it be possible to add a branch in guix sources following only
> available substitutes, so that each time I pull, I can immediatly
> and quickly update. Or would that need to stay as someone's personal
> project ?

Adding what you are proposing would not change your "complaint". ;-)
Each time you would pull, you would stay on the same revision because
the substitutes would not be ready yet and so no quick update.  You
would have to wait and run again "guix pull" later, probably staying
on the same revision because the substitutes would not be ready.  In
the meantime, you would miss new features or new security fixes for
others of some packages you are using.

However, I agree that's annoying.  Some time ago (before the link
above), I used a script along these lines:

--8<---cut here---start->8---
#!/bin/bash

# url-cache-directory from guix/git.scm
# pjmkgl... = hash("https://git.savannah.gnu.org/git/guix.git;)
CACHE=~/.cache/guix/checkouts
CHECKOUT=${CACHE}/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq

printf "Updating local checkout:\n'$CHECKOUT'..."
git -C $CHECKOUT fetch -q
echo " done."

guix pull --commit=$(git -C $CHECKOUT\
 log \
 --before=$(date --date='2 weeks ago' +%Y-%m-%d) \
 --format="%h" | head -n1)   \
 $@

echo "done."
exit 0
--8<---cut here---end--->8---

to lag by 2 week behind origin/master and so be almost sure to have
the substitutes -- if their build success-ed. ;-)

Well, yeah it's annoying to run "guix pull", check with "guix
weather", and depending on the result upgrade or not -- note that the
exit status cannot be used [1].  When all that could be automatized.
#47929, as Mathieu said, is grouping "guix pull" and "guix weather".
Maybe we could imagine an option to "guix upgrade" coupling "guix
weather"; somehow the converse of 'no-substitutes' or the converse of
'fallback', i.e., do not try to locally build if the substitutes is
not available.  I do not know.

1: 

Cheers,
simon

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-09 20:44, Liliana Marie Prikler wrote:

> Hi,
>
> Am Sonntag, dem 09.01.2022 um 20:48 +0300 schrieb Andrew Tropin:
>> On 2022-01-09 12:19, Liliana Marie Prikler wrote:
>> 
>> > Hi Andrew,
>> > 
>> > Am Sonntag, dem 09.01.2022 um 12:12 +0300 schrieb Andrew Tropin:
>> > 
>> > > Before fee0bc serialization for text-config worked this way:
>> > > --8<---cut here---start->8---
>> > > `("string here"
>> > >   ,#~"string valued gexp"
>> > >   "source \"
>> > >   ,(local-file "blabla.sh"))
>> > > --8<---cut here---end--->8---
>> > > 
>> > > would yield something like:
>> > > 
>> > > --8<---cut here---start->8---
>> > > string here
>> > > string valued gexp
>> > > source \
>> > > /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>> > > --8<---cut here---end--->8---
>> > > 
>> > > [...]
>> > > 
>> > > The new text-config serialization implementation (after fee0bc
>> > > commit) doesn't support gexps and tries to insert the literal
>> > > content
>> > > of the file in place where file-like object was used[.]
>> > I agree that the old one looks nicer in this context, but wasn't
>> > the new one introduced to solve the issue of (slurp-file-gexp) in
>> > the importer?  Meaning whichever way we go, we need something that
>> > allows us to insert literal file contents of another file at more
>> > or less G- exp compile time.
>> > 
>> 
>> From my experience the usage of slurp-file-gexp is somewhat really
>> rare, so I didn't upstream it originally, keeping in mind that it is
>> possible to use the gexp mentioned below directly and that later we
>> can add slurp-file-gexp or alternative if necessary.  Just missed
>> that importer already uses it.
>> 
>> We could just do something like that instead of slurp-file-gexp:
>> --8<---cut here---start->8---
>> #~(call-with-input-file #$(local-file "./files/bashrc")
>>     (@ (ice-9 textual-ports) get-string-all))
>> --8<---cut here---end--->8---
>> 
>> Or just take the implementation
>> https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/gnu/home-services-utils.scm#L90
>> and rename it to read-file-content-gexp or somewhat more apropriate
>> and use it.
> Using ill-defined slurp-patterns at all just adds ways of shooting
> yourself in the foot.  You're turning Guix into an ouroboros that reads
> itself inside-out.  Better restrict such patterns to where they cause
> the least harm and make their effects very explicit.

Not sure what you mean.

>> > Perhaps that issue could be solved, if instead the importer just
>> > reads the file contents and declares it as a variable as in (define
>> > %bashrc " ;; Original contents of bashrc ") (define bashrc (plain-
>> > file %bashrc)).
>> > 
>> > WDYT?
>> 
>> Another possible solution, but I would prefer to stick with the
>> direct usage of gexp with the code for reading a file, because
>> importer is intended for creation of an example configuration and
>> user will need to continue the work on it and copying the content of
>> bashrc and other configs to scheme files, escaping string can be a
>> little tedious.
> There is certainly a tradeoff here, but I think explicitly showing
> (plain-file CONTENT) is the right approach here.  Users are going to
> figure out mixed-text-file exists soon enough.  As for proper string
> escaping, that's not really an excuse imo -- pretty-print exists and
> you can use it. 

Yep, of course it possible, but I mean that the whole point of escape
hatch is to make it possible to reuse existing files directly whithout
any manipulation on them and importer should demonstrate how to do it.
If importer internally do some manipulation (escaping) with the content
of the file and places the result in the string in scheme file, user
won't be able to replicate such process easily for other services, which
not covered by the importer. If I understood correctly what you meant in
the first message.

>> read-everything-from-file is just a shorthand for
>> 
>> --8<---cut here---start->8---
>> #~(begin
>>     (use-modules (ice-9 rdelim))
>>     (with-fluids ((%default-port-encoding "UTF-8"))
>>   (with-input-from-file #$COMPUTED_FILE_CALL_HERE read-string)))
>> --8<---cut here---end--->8---
>> 
>> a gexp used in
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386
>> 
>> The example was already verbose, so I decided to simplify it a little
>> bit.
>> 
>> Actually, it's very similar to what slurp-file-gexp does, but it's
>> moved inside serializer and hidden from user.  Why not to give it to
>> the user and eleminate two more layers of wrapping in gexps and file-
>> likes.
> That's like saying "memory management already exists, 

Re: Guix Documentation Meetup

[Oliver Propst]

Hi Matt I thanks for your very elaborate and insightful mail. As a Guix 
user and enthusiast I definitely agree that documentation is important 
for the project. Also if I understand things correctly there are 
actually plans to host a documentation meetup this Saturday (maybe at 
around 10:30 AM ET as the last ones).


On 2022-01-08 05:52, Matt wrote:

I want to be a part of this.  I feel like I've been rubbing two sticks
together while it seems some people out there have Zippo lighters

Cool.


One final question:

  How might announcements of the "Guix Documentation Meetup" (and
"Guix Packaging Meetup)" be made more prominent?

I check the mailing list from time to time, but missed the
announcements because they were buried.  Maybe meetings could be
announced on info-guix?


Sounds as good ideas to me and something that I think the project should 
consider.



If they become regular, maybe put them on
https://guix.gnu.org/en/contribute/?  FWIW, I'm willing to be present
so that a documentation meetup could run monthly. I'm an FSF member
and could use the FSF Jitsi service if I needed to host it.  I've not
used Big Blue Button before.


I'm sure your participation and potential contributions to the 
documentation meetup would be very welcome at this point in time :)

Re: Guix Documentation Meetup

[André A . Gomes]

Matt  writes:

>  > I see that this all seems confusing.
>
> Thank you for your response and for acknowledging my perspective.
> Yes, I find many things about the documentation process confusing. I
> can't speak for others, but I get the strong sense that I'm not alone
> in that feeling.

You're not alone, but honestly I think Guix's efforts are heroic to say
the least.  How many software has no documentation at all?  I always
gaze at the quality of Guix's manual.

> First, the packaging tutorial is, I believe, a reasonable candidate
> for the cookbook.  It's ready for feedback toward inclusion, not
> direct inclusion.  The software being packaged isn't ideal as it
> involves concepts which may detract from the main subject of
> packaging, like stenography. It's also for a plugin and not standalone
> software.  Demonstrating the final package requires demonstrating the
> parent application which again detracts from the main subject of
> packaging.  Finally, it's written using active voice which conveys
> authority on the topic, authority I don't actually have. This was my
> first attempt at packaging.
>
> Second, the troubleshooting post is not, in my option, suited for the
> cookbook. It is, however, a good candidate for a wiki page (similar to
> Arch wiki sections on troubleshooting).  The last time a wiki was
> talked about, it seems, was in 2015. I'll start a thread for that.

Please don't misinterpret the following comments.  You're doing
something valuable for the community by the mere fact of talking about
Guix - your writings are valuable!  But I don't see how the 1st one
could land in a cookbook.  Regarding the 2nd and the wiki, as someone
(perhaps you) already noted, wikis generally host low quality content.
Guix's documentation has a ton of examples, perhaps even too many for an
expository kind of text.  Yes, I'm not a fan of wiki.  Regardless, the
efforts of such a wiki should perhaps land outside the scope of Guix
(i.e. it should be non-"official").

I'm not connected with Guix with any way - a mere enthusiast and
observer.

I hope you continue to write great articles like these!


--
André A. Gomes
"Free Thought, Free World"

Re: Branch with only available substitutes ?

[Mathieu Othacehe]

Hello,

> Short answer: yes, but someone has to not just ask whether it's
> possible or tell it ‘should be easy’, and actually implement all this.
> Also, have a look at channel-with-substitutes-available.
> It's not sufficiently general for your use case though.

There's also a pending patch extending this procedure to support
manifests: https://issues.guix.gnu.org/47929.

It still needs some work but it could be conceptually close from what
Nicolas is asking.

Mathieu