Today's talks! (formerly Schedule for FOSDEM 2022 available online)

[Pjotr Prins]

Today is our devroom with great Lisp talks by Will Byrd, Arun Isaac,
Manolis & Oliver and the Webbers! And two GNU Guix talks by Andrew
Tropin and Mathieu Othacehe :)

https://fosdem.org/2022/schedule/track/declarative_and_minimalistic_computing/

Don't miss out. Jonathan McHugh goes cowsay to build a nextgen issue
tracker and Ekaitz' RISC-V bootstrap talk is also very interesting. 

I can't believe we have such an amazing track again, thanks to
Manolis and Oliver.

Talks are recorded and will be available for viewing later. 

Pj.

On Tue, Jan 18, 2022 at 02:51:18PM +0100, Ludovic Courtès wrote:
> Hi Oliver,
> 
> Oliver Propst  skribis:
> 
> > Just a brief note about that the schedule for FOSDEM 2022 is now
> > available online at 
> > https://fosdem.org/2022/schedule/track/declarative_and_minimalistic_computing/
> > for who is interested in details about the talks.
> 
> I had overlooked this message—the program looks exciting, thumbs up!
> 
> Ludo’.
> 

Re: Clarifying blog post licensing

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Hello Guix!
>>>
>>> With a few exceptions, our blog posts do not have a license, which is
>>> not great as it prevents sharing and reuse, at least by those outside
>>> Guix circles (we discussed it in the past but never got around to fixing
>>> it).
>>>
>>> I’d like us to clarify that, with a footer on blog posts saying that,
>>> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
>>> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
>>> the manual).  Patch below.
>>>
>>> What do people think?
>>
>> Sounds good to me.  I'm curious though; why do we need CC-BY-SA,
>> additionally to GFDL?
>
> We don’t “need” it, but I think it’s nice to have since it’s used by
> many free culture projects out there, starting with Wikipedia.

Thanks for the information.

Maxim

Re: The way to promote GUIX package manager

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hi!
>
> Vagrant Cascadian  skribis:
>
>> The main two issues I'm aware of are...
>>
>> Issue with "guix pull" from the guix 1.2 version:
>>
>>   https://bugs.debian.org/1001833
>
> I believe this was fixed:
>
>   https://issues.guix.gnu.org/52694

Last week (or maybe two weeks ago, but no sooner than that) I ran “sudo
apt install guix” on a laptop with Debian and I followed the advice to
pull to the commit corresponding to 1.3.0.

Every time at the end I got this git error: “the requested type does not
match the type in the ODB”.

Would it have been any different had I pulled directly to the latest
version…?  Or is this unrelated?

(In the end I removed the Debian package and installed with
https://guix.gnu.org/install.sh; this was trickier than it should have
been, because the Debian package left behind a broken init service and
some state that I deleted manually.)

-- 
Ricardo

Re: cross compiling using qemu-user-static

[Maxime Devos]

Tobias Platen schreef op za 05-02-2022 om 18:23 [+0100]:
> > What does "type -p guix" return? $HOME/.guix-profile/bin/guix or
> > /usr/{local/,}bin/guix or something else?
> /usr/local/bin/guix

Looks like an old version.  I see two possibilities here:

  * Set up .bash_profile and .profile like documented in the manual
and login again.  For whatever reason, on my Debian system at
least, when I start a graphical session ~/.bash_profile and
~/.profile are ignored, so I have to do "bash --login" to start
a login shell to start doing up-to-date Guix stuff. 

  * If /usr/local/bin/guix is a symlink to
/var/guix/profiles/per-user/root/current-guix/bin/guix,
like on my Debian system, then updating root's guix
(sudo guix pull) should be sufficient -- it's a bit
unconventional and suboptimal but it should work.

Greetings,
Maxime.




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

Re: cross compiling using qemu-user-static

[Maxime Devos]

Tobias Platen schreef op za 05-02-2022 om 17:20 [+0100]:
> On Sat, 2022-02-05 at 17:09 +0100, Maxime Devos wrote:
> > Tobias Platen schreef op za 05-02-2022 om 16:14 [+0100]:
> > > Some time ago I was able to cross compile emacs to run on the
> > > OpenPandora[1] using guix. That seems to be broken:
> > > 
> > > guix pack --target=armhf-linux-gnu openssh emacs libhandy
> > > guix pack: error: gnu/packages/emacs.scm:77:2: emacs@27.2: build
> > > system
> > > `glib-or-gtk' does not support cross builds
> > 
> > Is your guix up to date?  Cross-compilation for 'glib-or-gtk' has
> > been
> > implemented in:
> > 
> > commit 881a5d26b2fdf9ccb222b26b2a533cd09ffc62c8
> > Author: Maxime Devos 
> > Date:   Tue Aug 24 11:06:53 2021 +0200
> > 
> I did a guix pull today.

Weird, if I do
‘guix pack --target=arm-linux-gnueabihf emacs libhandy openssh’
then it starts substituting source code and building:

> $ guix pack --target=arm-linux-gnueabihf emacs libhandy openssh
> De volgende distillaties zullen gebouwd worden:
>/gnu/store/c5svd5lbx26rysgm3r4ln89n1l74cif0-openssl-1.1.1m.drv
>
> /gnu/store/2scsyrlwbjy466p2dy2qay5fwwm6yp5x-glibc-cross-arm-linux-gnueabihf-2.33.drv
>
> /gnu/store/60x13abw5wr2yr1d0d6db2pspgbla1d0-linux-libre-headers-cross-arm-linux-gnueabihf-5.10.35.drv
>
> /gnu/store/6w9anqnsfpgjk90x4ldbq17m4g75g4lc-gcc-cross-arm-linux-gnueabihf-10.3.0.drv
>/gnu/store/55m8qc9ybxrrip3pizxbcka0axfp0z11-expat-2.4.4.drv
>
> 30,7 MB zal binnengehaald worden
>  expat-2.4.4.tar.xz  439KiB2.5MiB/s 00:00 
> [##] 100.0%
>  binutils-cross-arm-linux-gnueabihf-2.37  6.9MiB   1.9MiB/s 00:04 
> [##] 100.0%
>  gcc-cross-sans-libc-arm-linux-gnueabihf-10.3.0-lib  2.7MiB2.6MiB/s 00:01 
> [##] 100.0%
>  glibc-cross-arm-linux-gnueabihf-2.33  18.0MiB 1.7MiB/s 00:11 
> [##] 100.0%
>  ld-wrapper-arm-linux-gnueabihf-0  13KiB   2.1MiB/s 00:00 
> [##] 100.0%
>  openssl-1.1.1m.tar.xz  7.1MiB 3.2MiB/s 00:02 
> [##] 100.0%
>  gcc-cross-sans-libc-arm-linux-gnueabihf-10.3.0  14.8MiB   4.0MiB/s 00:04 
> [##] 100.0%
> /gnu/store/60x13abw5wr2yr1d0d6db2pspgbla1d0-linux-libre-headers-cross-arm-linux-gnueabihf-5.10.35.drv
>  bouwen...
> | 'unpack' fase^C

What does "type -p guix" return? $HOME/.guix-profile/bin/guix or
/usr/{local/,}bin/guix or something else?  What does "guix --version"
print?

Greetings,
Maxime


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

Re: cross compiling using qemu-user-static

[Maxime Devos]

Tobias Platen schreef op za 05-02-2022 om 17:20 [+0100]:
> On Sat, 2022-02-05 at 17:09 +0100, Maxime Devos wrote:
> > Tobias Platen schreef op za 05-02-2022 om 16:14 [+0100]:
> > > Some time ago I was able to cross compile emacs to run on the
> > > OpenPandora[1] using guix. That seems to be broken:
> > > 
> > > guix pack --target=armhf-linux-gnu openssh emacs libhandy
> > > guix pack: error: gnu/packages/emacs.scm:77:2: emacs@27.2: build
> > > system
> > > `glib-or-gtk' does not support cross builds
> > 
> > Is your guix up to date?  Cross-compilation for 'glib-or-gtk' has
> > been
> > implemented in:
> > 
> > commit 881a5d26b2fdf9ccb222b26b2a533cd09ffc62c8
> > Author: Maxime Devos 
> > Date:   Tue Aug 24 11:06:53 2021 +0200
> > 
> I did a guix pull today.

Weird, if I do
‘guix pack --target=arm-linux-gnueabihf emacs libhandy openssh’
then it starts substituting source code and building:

> $ guix pack --target=arm-linux-gnueabihf emacs libhandy openssh
> De volgende distillaties zullen gebouwd worden:
>/gnu/store/c5svd5lbx26rysgm3r4ln89n1l74cif0-openssl-1.1.1m.drv
>
> /gnu/store/2scsyrlwbjy466p2dy2qay5fwwm6yp5x-glibc-cross-arm-linux-gnueabihf-2.33.drv
>
> /gnu/store/60x13abw5wr2yr1d0d6db2pspgbla1d0-linux-libre-headers-cross-arm-linux-gnueabihf-5.10.35.drv
>
> /gnu/store/6w9anqnsfpgjk90x4ldbq17m4g75g4lc-gcc-cross-arm-linux-gnueabihf-10.3.0.drv
>/gnu/store/55m8qc9ybxrrip3pizxbcka0axfp0z11-expat-2.4.4.drv
>
> 30,7 MB zal binnengehaald worden
>  expat-2.4.4.tar.xz  439KiB2.5MiB/s 00:00 
> [##] 100.0%
>  binutils-cross-arm-linux-gnueabihf-2.37  6.9MiB   1.9MiB/s 00:04 
> [##] 100.0%
>  gcc-cross-sans-libc-arm-linux-gnueabihf-10.3.0-lib  2.7MiB2.6MiB/s 00:01 
> [##] 100.0%
>  glibc-cross-arm-linux-gnueabihf-2.33  18.0MiB 1.7MiB/s 00:11 
> [##] 100.0%
>  ld-wrapper-arm-linux-gnueabihf-0  13KiB   2.1MiB/s 00:00 
> [##] 100.0%
>  openssl-1.1.1m.tar.xz  7.1MiB 3.2MiB/s 00:02 
> [##] 100.0%
>  gcc-cross-sans-libc-arm-linux-gnueabihf-10.3.0  14.8MiB   4.0MiB/s 00:04 
> [##] 100.0%
> /gnu/store/60x13abw5wr2yr1d0d6db2pspgbla1d0-linux-libre-headers-cross-arm-linux-gnueabihf-5.10.35.drv
>  bouwen...
> | 'unpack' fase^C

What does "type -p guix" return? $HOME/.guix-profile/bin/guix or
/usr/{local/,}bin/guix or something else?

Greetings,
Maxime


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

Re: cross compiling using qemu-user-static

[Maxime Devos]

Tobias Platen schreef op za 05-02-2022 om 17:39 [+0100]:
> I was unaware that Guix already has that feature.
> But on my Talos II, I am using Guix on top of Debian,
> and I don't have Shepherd running. 

Debian has two packages for setting up binfmt: qemu-user-static and
qemu-user-binfmt. Perhaps even if qemu-user-binfmt doesn't work,
qemu-user-static does work?

Greetings,
Maxime.


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

Re: License of your contributions to the blog at guix.gnu.org

[Pierre Neidhardt]

Hi Ludo,

I agree.

Pierre


signature.asc
Description: PGP signature

Re: License of your contributions to the blog at guix.gnu.org

[Tatiana Sholokhova]

Hi! I agree.

On Sat, Feb 5, 2022, 08:47 Ludovic Courtès  wrote:

> Hello,
>
> I am emailing you on behalf of the GNU Guix project because you are the
> author or coauthor of one or more articles to the blog at
> .
>
> With a few exceptions, these articles do not have a clear license, which
> we would like to fix.  We propose to dual-license all the articles under
> CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections,
> no Front-Cover Texts, and no Back-Cover Texts.
>
> Do you agree with the proposed licensing terms for your contributions to
> the blog?
>
> If you do, please reply to this message to say so, keeping
> guix-devel@gnu.org Cc’d (if you already replied in the previous thread,
> you do not need to reply again).
>
> If you would prefer different licensing terms, or if you have any
> questions, feel free to ask them publicly on guix-devel@gnu.org or
> privately with guix-maintain...@gnu.org.
>
> The clarified license will allow us and others to reuse material in the
> manual, cookbook, and in other free cultural works.  See
> 
> for the initial discussion.
>
> Thanks in advance!
>
> Ludo’.
>

Re: License of your contributions to the blog at guix.gnu.org

[zimoun]

Hi,

On Sat, 5 Feb 2022 at 14:47, Ludovic Courtès  wrote:

> Do you agree with the proposed licensing terms for your contributions to
> the blog?

I agree.

Cheers,
simon

Re: License of your contributions to the blog at guix.gnu.org

[Mathieu Othacehe]

Hey Ludo,

> Do you agree with the proposed licensing terms for your contributions to
> the blog?

I agree.

Thanks,

Mathieu

Re: License of your contributions to the blog at guix.gnu.org

[Luis Felipe]

On Saturday, February 5th, 2022 at 1:47 PM, Ludovic Courtès  
wrote:

> Hello,
> 

> I am emailing you on behalf of the GNU Guix project because you are the
> author or coauthor of one or more articles to the blog at
> https://guix.gnu.org/en/blog.
> 

> With a few exceptions, these articles do not have a clear license, which
> we would like to fix. We propose to dual-license all the articles under
> CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections,
> no Front-Cover Texts, and no Back-Cover Texts.
> 

> Do you agree with the proposed licensing terms for your contributions to
> the blog?

☑ I agree.

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


signature.asc
Description: OpenPGP digital signature

License of your contributions to the blog at guix.gnu.org

[Ludovic Courtès]

Hello,

I am emailing you on behalf of the GNU Guix project because you are the
author or coauthor of one or more articles to the blog at
.

With a few exceptions, these articles do not have a clear license, which
we would like to fix.  We propose to dual-license all the articles under
CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections,
no Front-Cover Texts, and no Back-Cover Texts.

Do you agree with the proposed licensing terms for your contributions to
the blog?

If you do, please reply to this message to say so, keeping
guix-devel@gnu.org Cc’d (if you already replied in the previous thread,
you do not need to reply again).

If you would prefer different licensing terms, or if you have any
questions, feel free to ask them publicly on guix-devel@gnu.org or
privately with guix-maintain...@gnu.org.

The clarified license will allow us and others to reuse material in the
manual, cookbook, and in other free cultural works.  See

for the initial discussion.

Thanks in advance!

Ludo’.


signature.asc
Description: PGP signature

Re: cross compiling using qemu-user-static

[Maxime Devos]

Tobias Platen schreef op za 05-02-2022 om 16:14 [+0100]:
> So I think one could copy qemu-user-static for the target architecture
> into the build directory and execute native versions of the software.
> 
> [1] http://www.openpandora.org/

From a technical point of view, that's mostly native compilation from
Guix' perspective.  Try "guix pack --system=armhf-linux openssh emacs
libhandy" after setting up QEMU (see ‘Transparent Emulation with QEMU’
in the manual).

Greetings,
Maxime.


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

Re: cross compiling using qemu-user-static

[Maxime Devos]

Tobias Platen schreef op za 05-02-2022 om 16:14 [+0100]:
> guix pack --target=armhf-linux-gnu openssh emacs libhandy

FWIW the triple is arm-linux-gnueabihf.

Greetings,
Maxime.


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

Re: cross compiling using qemu-user-static

[Maxime Devos]

Tobias Platen schreef op za 05-02-2022 om 16:14 [+0100]:
> Some time ago I was able to cross compile emacs to run on the
> OpenPandora[1] using guix. That seems to be broken:
> 
> guix pack --target=armhf-linux-gnu openssh emacs libhandy
> guix pack: error: gnu/packages/emacs.scm:77:2: emacs@27.2: build system
> `glib-or-gtk' does not support cross builds

Is your guix up to date?  Cross-compilation for 'glib-or-gtk' has been
implemented in:

commit 881a5d26b2fdf9ccb222b26b2a533cd09ffc62c8
Author: Maxime Devos 
Date:   Tue Aug 24 11:06:53 2021 +0200

build-system/glib-or-gtk: Support cross-compilaton.

* guix/build-system/glib-or-gtk.scm
  (lower): Add 'implicit-cross-inputs?' argument.  Generate a bag
  when cross-compiling.
  (glib-or-gtk-cross-build): New procedure.

Greetings,
Maxime.


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

cross compiling using qemu-user-static

[Tobias Platen]

Some time ago I was able to cross compile emacs to run on the
OpenPandora[1] using guix. That seems to be broken:

guix pack --target=armhf-linux-gnu openssh emacs libhandy
guix pack: error: gnu/packages/emacs.scm:77:2: emacs@27.2: build system
`glib-or-gtk' does not support cross builds

So I think one could copy qemu-user-static for the target architecture
into the build directory and execute native versions of the software.

[1] http://www.openpandora.org/

Re: Guix Data Service client module

[Ludovic Courtès]

Hi!

Christopher Baines  skribis:

> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> Here’s a client module for the Guix Data Service, allowing you to access
>> a subset of the Guix Data Service interfaces from the comfort of your
>> REPL.

[...]

> I added some exports (included below) so that I could more easily use
> the module.
>
> Maybe open-data-service could have the url default to
> "https://data.guix.gnu.org;.

Sure!

> The only thing I can see that's required before merging though is the
> exports. I'm now thinking about this kind of thing (getting data out of
> the data service) in the context of patch/branch review.

I think there’s a couple of issues that would be nice to address in the
JSON API of the data service.

First, it’s unversioned, which will make it hard to maintain things
going forward.  How about adding, say, “/v1” to URL paths, similar to
what SWH does?

Second, there are places where I found inconsistencies or redundancy in
the API.  For instance there are several JSON schemas for things called
“branches” (see the FIXME in there).

The API to access package version history, which I think lots of users
are interested in, is not intuitive IMO:

--8<---cut here---start->8---
scheme@(guile-user)> (define s (open-data-service "https://data.guix.gnu.org;))
scheme@(guile-user)> (car (package-versions (lookup-package s "emacs")))
$20 = #< string: "27.2" branches: (#< name: "master" 
repository-id: 1>)>
scheme@(guile-user)> (car (package-version-history s (car 
(package-version-branches $20)) "emacs"))
$21 = #< version: "27.2" first-revision: #< 
commit: "cc33f50d0e2a7835e99913226cb4c4b0e9e961ae" date: #> 
last-revision: #< commit: "de38ccf2e0bb2fd21393925c296b65dca7499bd3" 
date: #>>
--8<---cut here---end--->8---

That said, I don’t have any suggestion on this one.

I also wonder if there’s a way to obtain a commit range for a given
package version, directly, without having to browse the list returned by
‘package-version-history’?

Thanks for taking a look!

Ludo’.

Re: Return back original implementation for text-config serialization

[Xinglu Chen]

Hi,

Andrew schrieb am Donnerstag der 20. Januar 2022 um 16:20 +03:

>>> 2. Looks strange implementation-wise.
>>>
>>> If we want to insert the file path to file-like object for new-style
>>> text-config internally we do something like
>>>
>>> (mixed-text-file ...
>>>  "source \" "\n"
>>>  #~(read-everything-from-file
>>> #$(computed-file "unecessary-file-name"
>>>#~#$(local-file "blabla.sh"
>>
>> When would one write such a thing?
>
> I have very same question :)
>
> It's what happens internally in current implementation, something like
> that goes to home-files-service-type.

From what I can tell, ‘home-files-service-type’ doesn’t seem to have
anything like that.  I am not able to find any usages for
‘computed-file’ in Guix Home services either.  I am missing something?


signature.asc
Description: PGP signature

Re: failure when rebuilding the past: long term?

[Ludovic Courtès]

Hi!

As a preamble, I’d like to say that what we’re doing in terms of time
traveling is ambitious; it’s never been done before, AFAIK.

And there are many pitfalls, as you write, mainly: disappearing source
(we’re working on it!), and, a bigger concern IMO, “non-deterministic”
build processes—in a broad sense: that includes build processes that
depend on CPU features, kernel versions, and other things not specified
in derivations.

I think we can address the latter, indirectly, with early cutoffs: if
two different derivations yield the same output, then we can consider
them equivalent and avoid rebuilding anything that depends on it,
instead just grafting them.  It helps in that it would allow users to
build ‘--without-tests’ and get an equivalent result, or to build with a
hypothetical ‘--in-virtual-machine’ or ‘--with-current-time=2020-01-01’
option.

zimoun  skribis:

>  3. Having all the sources is one thing, but being able to rebuild is
>  another.  Failure of OpenBLAS [0] is one example, of some mesboot [1]
>  or of texlive [2] are others.  It appears to me that something is
>  inadequate with the current workflow pushing all to master without any
>  automated* checks. Other said, failures as 8f9fd9b70c (value "Unbound
>  variable: ~S") (value (r-biobase) seems wrong by design.  Well,
>  ac6f677249 is another recent example.  Somehow, because the package
>  collection is becoming larger and larger (which is good!)  then it is
>  becoming harder and harder to maintain the consistency both forward and
>  backward.  For the last Guix revision, my rough estimate is that ~5% of
>  packages are broken and my guess is that this number is “independant”
>  of the package collection size.  However, I already have some
>  collection of unreachable commits by the time-machine and then for some
>  reachable commits, I do not have numbers for what is effectively
>  rebuildable.  As discussed in this thread [3], maybe Guix is moving too
>  fast; or better worded, maybe the current workflow is inadequate with
>  some goals of long term and build all from sources.  I do not know…  My
>  point here: do we provide a list of commits (release, others) where we
>  apply more care for long term?

It’s hard for committers to push evidently broken code, such as unbound
variables, because ‘guix lint’, ‘make’, & co. catch it.  Still, it would
be great if it never happened at all, and for that enforcing server-side
checks could help.

The next issue is broken builds.  Automation can definitely help, and
Chris Baines’ work on automated patch handling or anything along these
lines would be a step in the right direction.

Non-deterministic builds are probably harder to automatically identify,
yet it’s a bigger concern.

Besides, I think we should do some sort of CI for time traveling, to
make sure we can travel forward and backward for different revisions.
(I would love to see research institutes invest in this work.)

My 2¢,
Ludo’.

Re: [PATCH v2] doc: Add Writing Service Configuration section.

[Xinglu Chen]

Andrew schrieb am Donnerstag der 23. Dezember 2021 um 16:16 +03:

>> Also, is should there be any preference for using alists or list of
>> lists or vice versa?
>
> Now it should be clear that a -configuration record is preferable as a
> service value, lists and alists are special cases for auxiliray
> services and shouldn't be used in most cases.

But what is the preference between a list and an alist?  Why does
‘etc-service-type’ use

  '((file contents))

and ‘home-file-service-type’ use

  '((file . contents))

?

>>> +There is a module @code{gnu service configuration}, which contains
>>> +helpers simplifying configuration definition process.  Take a look at
>>> +@code{gnu services docker} module or grep for
>>> +@code{define-configuration} to find usage examples.
>>> +
>>> +@c Provide some examples, tips, and rationale behind @code{gnu service
>>> +@c configuration} module.
>>
>> Note that I already sent a patch that (at least tries to) document (gnu
>> service configuration)[1].
>>
>> One thing that is lacking is when to use (guix records) (which isn’t
>> documented yet) vs (gnu service configuration).  There should probably
>> be one or two paragraphs about that.
>>
>
> Saw it, I'll try to review and comment on it, when I'll get some spare
> time.  I'll keep this comment for now, and after the section about gnu
> service configuration module is merged, we will add links to it and
> provide more info and examples on implementing actual configurations.

It has already been merged now.  :-)

>>> +configuration file name, but in kebab-case: bashrc for bashrc,
>>
>> Not everyone might familiar with what exactly “kebab-case” means; we
>> should probably leave a footnote or something.
>>
>> “…@code{bashrc} for @file{.bashrc}…”
>>
>> It should also mention that preceding dots should be removed as well.
>> What should happend with files named ‘file.ext’?  Should the field be
>> named ‘file-ext’?
>
> Added a footnote, provided more expressive examples
> @code{bashrc} for @file{.bashrc},
> @code{bash-profile} for @file{.bash_profile},
> @code{tmux-conf} for @file{tmux.conf}, etc.

I suggested adding a footnote for the meaning of “kebab-case”.  I don’t
think these examples should just be in a footnote.  Footnotes are
usually used for stuff that might be distracting if put in the text; I
wouldn’t consider these examples distracting; they are very valuable.

>>> +bash-profile for bash_profile, etc.  The implementation for such fields
>>
>> “…@code{bash-profile} for @file{.bash_profile}.
>>
>> Also, many services have an ‘extra-content’, ‘extra-config’, or
>> ‘extra-options’ field.  In most cases these just take a string and
>> appends it to some configuration file.  Should these instead be named
>> ‘sshd_config’, ‘xserver-conf’, and ‘asound-config’, respectively?
>>
>
> I find this pattern purely-established (content vs conf vs options),
> unclear (you can never know where this extra content will be inserted
> until you take a look at implementation of serialization function)

That’s why we have documentation for all the fields.  Moreover, if it
wasn’t documented, the order of the contents of the fields of
‘home-bash-configuration’ aren’t obvious to the user either.

>>> +There is no any special requirements or
>>> +recommendations here, but it's necessary to make it possible to disable
>>> +all the effects of such fields to provide a user with an empty
>>> +configuration and let them generate it from scratch with only field for
>>> +configuration file.
>>
>> I don’t really understand what is meant by “let them generate it from
>> scratch with only field for configuration file”.  
>
> The good examples of the bad behavior are alsa and nginx service types,
> they always provide some boilerplate with reasonably good default
> configuration, but you can't alter it by setting some fields to #f or
> some other values.

That applies for the Bash service as well; it unconditionally adds stuff
to ~/.bash_profile.

> For nginx it's only partially true, you actually can use `file` field,
> but it will alter the effect of all other fields and will just use the
> file as nginx.conf, kinda conforms what I'm asking here, but makes all
> other fields useless.
>
> Added the following explanation to this item:
>
> --8<---cut here---start->8---
> For example, setting @code{guix-defaults?} to
> @code{#f} and @code{aliases} to @code{'()} will give user an ability to
> control the content of @file{.bashrc} solely by setting the value of
> @code{bashrc} field.
> --8<---cut here---end--->8---
>
>
>>
>> It doesn’t mention if a configuration record should cover all the
>> configuration options available in a configuration file.  For example,
>> the current ‘openssh-configuration’ has quite a few options, but these
>> obviously don’t cover all the options available in /etc/ssh/sshd_config,
>> which is why there is an “escape hatch”, ‘extra-content’ field.
>>
>> In 

Re: weird OpenBLAS time-machine

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> zimoun schreef op do 03-02-2022 om 03:19 [+0100]:
>> The issue is because concurrency.  If two time-machines are run
>> concurrently, they both update ~/.cache/guix/checkouts/ and the end
>> result is hard to predict.

Ah, glad you found out the culprit!

> FWIW it's a known issue but I can't find it on issues.guix.gnu.org.
> The (unimplemented) fix is to use worktrees, or don't checkout and use
> the libgit2 / (guix git) equivalent of
> "git show 46fc72b2bfee2a30a3c3f3320e7d84b4b2fd646e some-file".

Hmm I cannot find it either.  But yeah, probably better than worktrees
would be reading blobs directly off Git.

Thanks,
Ludo’.

Re: Investigating a reproducibility failure

[Ludovic Courtès]

Konrad Hinsen  skribis:

> There is obviously a trade-off between reproducibility and performance
> here.

I tried hard to dispel that belief: you do not have to trade one for the other.

Yes, in some cases scientific software might lack the engineering work
that allows for portable performance; but in those cases, there’s
‘--tune’.

  
https://hpc.guix.info/blog/2022/01/tuning-packages-for-a-cpu-micro-architecture/

We should keep repeating that message: reproducibility and performance
are not antithetic.  And I really mean it, otherwise fellow HPC
practitioners will keep producing unverifiable results on the grounds
that they cannot possibly compromise on performance!

Thanks,
Ludo’.

Re: Investigating a reproducibility failure

[Ludovic Courtès]

Hi!

Konrad Hinsen  skribis:

> To see the failure, do
>
>guix time-machine \
> --commit=7357b3d7a52eb5db1674012c50d308d792741c48 \
> -- build openblas

For the record, there’s still a substitute available for this one:

--8<---cut here---start->8---
$ guix time-machine --commit=7357b3d7a52eb5db1674012c50d308d792741c48 -- 
weather openblas
guile: warning: failed to install locale
computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  100.0% substitutes available (1 out of 1)
  at least 24.5 MiB of nars (compressed)
  78.3 MiB on disk (uncompressed)
  0.003 seconds per request (0.0 seconds in total)
  343.4 requests per second
[ugly but unimportant backtrace omitted…]
$ guix time-machine --commit=7357b3d7a52eb5db1674012c50d308d792741c48 -- build 
openblas
guile: warning: failed to install locale
/gnu/store/vax1vsg3ivf0r7j7n2xkbi1z3r0504l9-openblas-0.3.7
--8<---cut here---end--->8---

That doesn’t solve the fact that OpenBLAS compilation is not
reproducible, as zimoun noted¹, and we need to fix it, but at least this
colleague of yours should have been able to fetch substitutes, no?

Thanks,
Ludo’.

¹ https://issues.guix.gnu.org/51536

Re: Shepherd config file and GEXP semantics

[Ludovic Courtès]

Hi,

Attila Lendvai  skribis:

> (define (make-user-module)
>   (let ((m (make-fresh-user-module)))
> ;; The typical configuration file wants to do '(make  ...)', and
> ;; '(register-services ...)', so provide the relevant bindings by default.
> (module-use! m (resolve-interface '(oop goops)))
> (module-use! m (resolve-interface '(shepherd service)))
> m))
>
> (define (load-in-user-module)
>   (let ((user-module (make-user-module)))
> (save-module-excursion
>  (lambda ()
>(set-current-module user-module)
>(use-modules (nongnu services swarm-utils))
>
>;; this works, i.e. *log-directory* is not unbound upon execution:
>;; (eval '(lambda ()
>;;  *log-directory*)
>;;   user-module)
>
>(lambda () *log-directory*)
>

‘use-modules’ is a macro that should only be used at the top level, even
if it sometimes works in different contexts, for now.

Instead, you should use Guile’s first-class module API (info "(guile)
Module System Reflection").  As you noticed in the code you copied from,
you would call ‘module-use!’ and similar procedures.

I don’t see which module ‘*log-directory*’ is in, though.

HTH,
Ludo’.

Re: The way to promote GUIX package manager

[Ludovic Courtès]

Hi!

Vagrant Cascadian  skribis:

> The main two issues I'm aware of are...
>
> Issue with "guix pull" from the guix 1.2 version:
>
>   https://bugs.debian.org/1001833

I believe this was fixed:

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

Thanks,
Ludo’.

Re: Shepherd should not reboot on exit when running as root

[Ludovic Courtès]

Hello!

Arun Isaac  skribis:

> If shepherd is run as root, it assumes it is the init system and reboots
> the system. Since shepherd is not just an init system, but can also be
> used as a non-init process to manage other daemons, this is probably not
> good default behaviour. At the very least, it would be nice to have a
> command-line option to disable this behaviour.
>
> Just yesterday, I was tinkering with shepherd on a production server
> running Debian as the host system, and ended up accidentally rebooting
> it. Needless to say, I went through much pain and suffering! :-) I
> suppose I should count myself very lucky that it didn't halt the system!
> :-P

Oops, fixed in 7c380590164ea8ee40de46059d07e08a48963577, thanks!

Ludo’.

Re: missing patch for texlive-bin (e77412362f)

[zimoun]

Hi Tim,

On Fri, 04 Feb 2022 at 23:20, Timothy Sample  wrote:

> Yes.  I could add that commit to the database, evaluate it, and load all
> the sources.  I’m inclined not to, but I’m open to being convinced.  (I
> really like how simple the current system is conceptually.)

I understand.  Especially on the light of…

> That’s about it.  To my mind, “The History of the Guix Package Database”
> *is* the first parent walk that you describe.  Of course, that’s just my
> feeling.  There’s lots of room for disagreement there.  Basically, if
> you can’t reach a commit by starting at 1.0.0 and running ‘guix pull’
> without arguments, it doesn’t exist!

…this.  I agree that the aim is the guarantee of a preservation for
revisions only reachable by “guix pull”.

Aside PoG, this raises a point that I asked elsewhere.  The time-machine
is able to go any revisions, but 1. some revisions are known to fail and
2. only some revisions are preserved.  Therefore, something appears to
me missing: advertise about this collection of “working” revisions.

*working still a vague meaning. :-)

Well, I do not know via which mechanism?  Maybe add something as narinfo
or else attached to this collection of “working” revisions.  Then,

   guix time-machine --commit=1234abcd -- help

would warn that this 1234abcd is not part of this collection and there
is no guarantee it would work.

I do not know, I am thinking loud. :-)


> More or less.  Burning CPU is definitely the main thing holding back
> processing all the commits, but it would likely take a bit of effort to
> get code that works for around one hundred commits to work for
> thousands.  The second thing is diminishing returns.  Burning *way* more
> CPU to track down a couple sources feels a little wasteful to me.
>
> For me, the scope of PoG is perfect the way it is.  It’s big enough to
> be useful, but not so big to be overwhelming.  There are lots of serious
> problems to be addressed, too.

I understand and I agree.


Cheers,
simon

Re: Return back original implementation for text-config serialization

[Maxime Devos]

Andrew Tropin schreef op wo 26-01-2022 om 11:36 [+0300]:
> In addition to the problems I mentioned above:
> 
> 1. Mixed usage of two configuration languages (nginx-conf and lisp).
> 2. Having a string, which should be properly escaped (luckily for
> this
> example it's not a problem).

Mixing two configuration languages can be avoided by supporting
everything with records.

> 
> we also:
> 
> 3. Have to implement our own templating engine (using format function
> in this case) to share the values from guile with the config.

This seems to be the same for this list based configuration system
and record based configuraiton system; for the nginx example you gave,
all these lists with parentheses need to turned into something with
brackets that nginx understands anyway.

> 4.1. Don't know where extra-content goes. (It goes to http section
> not the
> end of the file, so we have to start with "}" to get a correct
> configuration).

Can be solved by adding missing options to the Guix service definition
(and documentation) when the need arises.

> 4.2. Don't control where it must be placed. (Can be important in
> other
> use cases, which I can share if needed).

Likewise.

> 5. Have inconsistent implementation of extra-config, extra-content,
> raw-lines
> and other escape hatches (We need to learn it everytime we write a
> new
> service configuration).

Likewise.

Also, the mapping of upstream configuration files to lists in Guix
seems far from obvious to me: in https://issues.guix.gnu.org/52698,
how am I supposed to know that 'us,ru' must be a symbol, why isn't
it a string?  If one of the strings for some property includes a
special character from the configuration language (say, '$'),
should it be escaped in Guix ((bindsym ... "[class=\"$100 dollars\"]"
...) or (bindsym ... "[class=\"\\$100 dollars\""]""))?

Why (bindsym ... "[class=\"foo\"]") instead of
(bindsym ... (= class "foo"))?

Why (bindsym ... exec emacsclient ...) and not
(bindsym ... exec (file-append emacs "/bin/emacsclient) ...)?
How am I supposed to know whether emacs is in the path or not,
and if it is, is this merely an implementation detail?

How would  I know if it's (bindsym ... exec emacsclient -c --eval
"'(eshell)'") or (bindsym ... "exec emacsclient -c --eval
\"'(eshell)'\"")?  Since the idea is to keep as close to the
configuration language as possible, shouldn't it be the second?

Why lists and not vectors?

Greetings,
Maxime.


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

Re: Clarifying blog post licensing

[Ludovic Courtès]

Hi,

Vagrant Cascadian  skribis:

> Just for clarity, do you mean the GFDL with a laundry-list of non-free
> anti-features excluded, like the guix manual:
>
>   Permission is granted to copy, distribute and/or modify this document
>   under the terms of the GNU Free Documentation License, Version 1.3 or
>   any later version published by the Free Software Foundation; with no
>   Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

Yes of course; the patch I proposed explicitly states that:

  https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00389.html

Thanks for asking!

Ludo’.

Re: Clarifying blog post licensing

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> With a few exceptions, our blog posts do not have a license, which is
>> not great as it prevents sharing and reuse, at least by those outside
>> Guix circles (we discussed it in the past but never got around to fixing
>> it).
>>
>> I’d like us to clarify that, with a footer on blog posts saying that,
>> unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
>> GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
>> the manual).  Patch below.
>>
>> What do people think?
>
> Sounds good to me.  I'm curious though; why do we need CC-BY-SA,
> additionally to GFDL?

We don’t “need” it, but I think it’s nice to have since it’s used by
many free culture projects out there, starting with Wikipedia.

Ludo’.

Re: File search

[Ludovic Courtès]

Hi,

Ryan Prior  skribis:

> On Friday, January 21st, 2022 at 9:03 AM, Ludovic Courtès  
> wrote:
>
>> The database for 18K packages is quite big:
>>
>> --8<---cut here---start->8---
>>
>> $ du -h /tmp/db*
>>
>> 389M /tmp/db
>>
>> 82M /tmp/db.gz
>>
>> 61M /tmp/db.zst
>>
>> --8<---cut here---end--->8---
>> [snip]
>> In terms of privacy, I think it’s better if we can avoid making
>> one request per file searched for. Off-line operation would be
>> sweet, and it comes with responsiveness; fast off-line search is
>> necessary for things like ‘command-not-found’ (where the shell
>> tells you what package to install when a command is not found).
>
> Offline operation is crucial, and I don't think it's desirable to download 
> tens or hundreds of megabytes. What about creating & distributing a bloom 
> filter per package, with members being file names? This would allow us to 
> dramatically reduce the size of data we distribute, at the cost of not giving 
> 100% reliable answers. We've established, though, that some information is 
> better than none, and the uncertainty can be resolved by querying a web 
> service or building the package locally and searching its directory.

My understanding is that Bloom filters are sets essentially, but here we
need more than that: we need to map files to package names.

Or am I misunderstanding what you have in mind?

Thanks,
Ludo’.

Re: File search

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> It used to be broken, but with the c-u-f merge the 'tlmgr' tool now
> works as expected to search for things in the local texlive.tlpdb
> database:
>
> $ guix shell --pure texlive-bin grep which coreutils sed gnupg -- tlmgr info 
> cite.sty
> tlmgr: cannot find package cite.sty, searching for other matches:
>
> Packages containing `cite.sty' in their title/description:
>
> Packages containing files matching `cite.sty':
> abntex2:
> texmf-dist/tex/latex/abntex2/abntex2cite.sty

Nice!

I think we really need a section in the manual on TeX Live usage, with
tips and tricks like this.

Ludo’.

Re: using an SRFI that is not available in Guile

[Ludovic Courtès]

Hi,

Attila Lendvai  skribis:

>> Another approach would be to use ‘define-record-type*’ and record all
>> the default values, including those derived from other fields (just like
>> the default ‘home-directory’ field of  is derived from
>> ‘name’.)
>>
>> Does that make sense?
>
>
> i think it does, but it would enforce a rather different code
> organization. right now i have a function called APPLY-CONFIG-DEFAULTS
> that is called at the beginning of each entry point to my service
> code. it makes sure that the input config is valid, and returns a new
> config object that has the defaults filled in. it has corss-referenced
> local variables and even some local functions.

[...]

> Ludovic, you're not too happy about the use of extra dependencies
> here, right? if so, can you please advise whether i can proceed with
> giving srfi-189 a try and see what it looks like (i.e. it's not off
> the table to get it accepted)? or do you have any other ideas?

I think I just don’t understand yet how the needs you describe differ
from those of the already available services.

Do you have a preliminary version of the service where you think
existing mechanisms are insufficient?  Sometimes I find it clearer to
discuss concrete cases.

Thanks,
Ludo’.

Re: Return back original implementation for text-config serialization

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Pardon my ignorance about Guix Home, but couldn't we have configuration
> as records by default, and the lower level, config stitching primitives
> still available to hand craft strings that could be used as the value of
> an 'extra-config' field, for example?
>
> It seems to me the use of records for configurations in Guix Home would
> be the natural choice, as Guix System users are already familiar with
> them and it leans to better discoverability/documentation.

Guix Home uses records for configuration and the same service as Guix
System, and I think it’s important that it remain this way for the
reasons you give and also from a maintenance viewpoint.

Ludo’.