Re: doubly quoted list in gnu-build

[Wojtek Kosior via]

> hi,
> 
> why do the configure-flags and make-flags need to be doubly quote in the 
> gnu-build procedure?

Because later in that function they get unquoted inside a gexp using
`#$` (i.e. `ungexp`).

If you write a gexp like

> (let ((somelist '("a" "b" "c")))
>   #~(display #$somelist))

on the build side it will resolve to

> (display ("a" "b" "c"))

which will of course fail because `"a"` is not a proper function. You
instead want to get this

> (display '("a" "b" "c"))

which can be achieved by e.g. double-quoting the value that gets
ungexp'd, e.g. with

> (let ((somelist ''("a" "b" "c")))
>   #~(display #$somelist))

The following should also work for this list

> (let ((somelist '("a" "b" "c")))
>   #~(display '#$somelist))

In many places in Guix code a function `sexp->gexp` is also used
together with `'#$`. I suspect it does some extra stuff. I don't know
what exactly.

The relevant part where those double-quoted lists are used is

>#:locale #$locale
>#:bootstrap-scripts #$bootstrap-scripts
>#:configure-flags #$(if (pair? configure-flags)
>(sexp->gexp 
> configure-flags) ; here
>configure-flags)
>#:make-flags #$(if (pair? make-flags)
>   (sexp->gexp make-flags) 
>   ; here
>   make-flags)
>#:out-of-source? #$out-of-source?
>#:tests? #$tests?
>#:test-target #$test-target

When a double-quoted list is used, the "true" expression of each `if`
clause is used :)

Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!   #46: saint Stanisław Papczyński
Poznaj świętych krakowskich!  #46: święty Stanisław Papczyński
https://pl.wikipedia.org/wiki/Stanisław_Papczyński
-- (sig_end)


On Wed, 7 Dec 2022 00:14:51 -0600
jgart  wrote:

> hi,
> 
> why do the configure-flags and make-flags need to be doubly quote in the 
> gnu-build procedure?
> 
> (define* (gnu-build name inputs
> #:key
> guile source
> (outputs '("out"))
> (search-paths '())
> (bootstrap-scripts %bootstrap-scripts)
> (configure-flags ''()) ; here
> (make-flags ''()) ; here
> (out-of-source? #f)
> (tests? #t)
> (test-target "check")
> (parallel-build? #t)
> (parallel-tests? #t)
> (patch-shebangs? #t)
> (strip-binaries? #t)
> (strip-flags %strip-flags)
> (strip-directories %strip-directories)
> (validate-runpath? #t)
> (make-dynamic-linker-cache? #t)
> (license-file-regexp %license-file-regexp)
> (phases '%standard-phases)
> (locale "en_US.utf8")
> (system (%current-system))
> (build (nix-system->gnu-triplet system))
> (imported-modules %gnu-build-system-modules)
> (modules %default-modules)
> (substitutable? #t)
> allowed-references
> disallowed-references)
> 
> 




pgpokoOPYb9ah.pgp
Description: OpenPGP digital signature

doubly quoted list in gnu-build

[jgart]

hi,

why do the configure-flags and make-flags need to be doubly quote in the 
gnu-build procedure?

(define* (gnu-build name inputs
#:key
guile source
(outputs '("out"))
(search-paths '())
(bootstrap-scripts %bootstrap-scripts)
(configure-flags ''()) ; here
(make-flags ''()) ; here
(out-of-source? #f)
(tests? #t)
(test-target "check")
(parallel-build? #t)
(parallel-tests? #t)
(patch-shebangs? #t)
(strip-binaries? #t)
(strip-flags %strip-flags)
(strip-directories %strip-directories)
(validate-runpath? #t)
(make-dynamic-linker-cache? #t)
(license-file-regexp %license-file-regexp)
(phases '%standard-phases)
(locale "en_US.utf8")
(system (%current-system))
(build (nix-system->gnu-triplet system))
(imported-modules %gnu-build-system-modules)
(modules %default-modules)
(substitutable? #t)
allowed-references
disallowed-references)

Re: This is how you import a mailing list archives (e.g. guix-patches) into mu4e

[Mekeor Melire]

2022-12-06 12:33 zimon.touto...@gmail.com:

> On Mon, 05 Dec 2022 at 21:43, Mekeor Melire  wrote:
>
> > I guess, a disadvantage of using public-inbox is that it's not an
> > official service of the GNU Guix community.
>
> It is up to us to have an “official” instance. :-)  Well, I remember
> discussing how to setup a public-inbox instance for Guix but I fail to
> find the message (probably a discussion on guix-sysad...@gnu.org :-)).
>
> I mean the Guix project already serves https://issues.guix.gnu.org which
> is an improvement, IMHO, over https://bugs.gnu.org.  We could also have
> https://lists.guix.gnu.org serving ’public-inbox’es for the various
> Guix mailing lists.

Yes, it'd be lovely if there were official GNU Guix public-inboxes, I
agree. Personally, I just started to use yhetil.org as of today, for my
local copy of the mailing-lists. But it'd be much nicer to rely on an
official service. I should go and find that old thread in the
guix-sysadmin list.

Re: This is how you import a mailing list archives (e.g. guix-patches) into mu4e

[Mekeor Melire]

2022-12-05 20:03 k...@kyleam.com:

> On 12/05/22 09:45:41 +0100, zimoun wrote:

> > Personally, I use “git clone” from a public-inbox instance [1].
> >
> > git clone --mirror https://yhetil.org/guix-patches/1 \
> >   guix-patches/git/1.git
> >
> > where ’1’ can be also replace by ’0’ for the very old ones.
>
> In the case of guix-patches, there's not a 0.git.  I started it at 1.git
> to leave open the possibility of adding 0.git with the messages I was
> missing from the beginning of the list's history (from Feb 12, 2017 to
> March 27, 2017).  I'm not sure I'm ever going to do so at this point
> and, even if I did, reserving 0.git doesn't have much advantage over
> just adding the old messages on top of the existing epoch, so I probably
> should have just started it at 0.git.
>
> > Then the conversion from Git commit to maildir is done by a small script
> > [2], where all the job reads:
> >
> > --8<---cut here---start->8---
> > # Extract the message from each commit in the range and store it
> > # in the Maildir for notmuch to consume.
> > $git rev-list $range | while read sha; do
> > # : fatal: path 'm' does not exist in 
> > # and it can also raise issues with notmuch, as:
> > # Note: Ignoring non-mail file: $maildir/new/$sha
>
> A tree can either have m or d ("deleted" messages):
>
>   https://public-inbox.org/public-inbox-v2-format.html
>
> So you should be able to avoid this error by skipping d's.
>
> > $git show $sha:m > $maildir/new/$sha
> > done
> > --8<---cut here---end--->8---
> >
> > (Maybe better could be done and more robust are around.)
>
> No need to change what works, of course, but
> https://public-inbox.org/clients.html mentions l2md and impibe as tools
> for converting public-inbox archives to Maildir.
>
>  * https://git.kernel.org/pub/scm/linux/kernel/git/dborkman/l2md.git
>  * https://leahneukirchen.org/dotfiles/bin/impibe
>
> In terms of cloning archives, plain cloning and fetching with Git is
> fine, but, if you have public-inbox locally, you can instead use
> public-inbox-clone and public-inbox-fetch, which will handle some
> details for you (e.g, cloning underlying epochs and recognizing that new
> epochs have been added):
>
>  $ public-inbox-clone https://yhetil.org/guix-patches
>
> Another option for fetching that's nice if you're mirror multiple repos
> is grokmirror:
>
>  * https://git.kernel.org/pub/scm/utils/grokmirror/grokmirror.git/about/
>  * example setup for guix: 
> https://yhetil.org/guix-patches/878scww903@kyleam.com/
>
> Both grokmirror and public-inbox-clone/fetch make use of the manifests
> that are published for public-inbox archives:
>
>   $ curl -fSsL https://yhetil.org/manifest.js.gz | gzip -d | \
> jq -r 'keys | .[] | select(contains("guix"))'
>   /guix-bugs/git/0.git
>   /guix-devel/git/0.git
>   /guix-patches/git/1.git
>   /guix-science/git/0.git
>   /guix-user/git/0.git
>
> Then there's of course also public-inbox's lei (local email interface).
> I won't get into that, but, for anyone interested, here are messages
> where I've given some examples:
>
>  * https://yhetil.org/emacs-devel/87wnh22w7o@kyleam.com
>  * https://yhetil.org/guix-devel/87y1zcljq3@kyleam.com

Thank you both for sharing your approaches.

As I personally use isync / mbsync to fetch the emails of my
email-accounts via IMAP into maildirs (which I then proceed to index
with mu and read with mu4e), I prefer to use the same tech stack to
fetch the mailing-list archives. And I now accomplished this with the
attached isync-configuration. Note that, as Kyle noted, I needed to use
the "0" path sometimes, and the "1" path other times. Also, you might
want to set and adapt MaxMessages to fit your needs.

IMAPAccount guix-bugs
Host news.yhetil.org
User arbitrary
AuthMechs ANONYMOUS
SSLType IMAPS
SSLVersions TLSv1.2

IMAPStore guix-bugs-remote
Account guix-bugs

MaildirStore guix-bugs-local
Inbox /home/user/path/to/maildirs/guix-bugs/inbox
Path /home/user/path/to/maildirs/guix-bugs/
SubFolders Verbatim

Channel guix-bugs
Far :guix-bugs-remote:yhetil.gnu.guix.bugs.0
Near :guix-bugs-local:
CopyArrivalDate yes
Create Near
ExpireUnread yes
# MaxMessages 10
Sync Pull
SyncState *

IMAPAccount guix-devel
Host news.yhetil.org
User arbitrary
AuthMechs ANONYMOUS
SSLType IMAPS
SSLVersions TLSv1.2

IMAPStore guix-devel-remote
Account guix-devel

MaildirStore guix-devel-local
Inbox /home/user/path/to/maildirs/guix-devel/inbox
Path /home/user/path/to/maildirs/guix-devel/
SubFolders Verbatim

Channel guix-devel
Far :guix-devel-remote:yhetil.gnu.guix.devel.1
Near :guix-devel-local:
CopyArrivalDate yes
Create Near
ExpireUnread yes
# MaxMessages 10
Sync Pull
SyncState *

IMAPAccount guix-help
Host news.yhetil.org
User arbitrary
AuthMechs ANONYMOUS
SSLType IMAPS
SSLVersions TLSv1.2

IMAPStore guix-help-remote
Account guix-help

MaildirStore guix-help-local
Inbox 

Re: This is how you import a mailing list archives (e.g. guix-patches) into mu4e

[Kyle Meyer]

zimoun writes:

> I fetch from yhetil.org (Git) and then convert to MailDir because I use
> Notmuch as indexer (and reader :-)).  And I do not want to duplicate the
> storage.  Therefore, after fetching and converting, the Git repo is
> garbage collected,
>
> --8<---cut here---start->8---
>   echo $head > $gitdir/shallow
>   $git gc --quiet --prune=all
> --8<---cut here---end--->8---
>
> https://gitlab.com/zimoun/my-conf/-/blob/master/.local/bin/sync-public-inboxes.sh#L94-99
>
> For instance, the current size of guix-patches on my machine is 152K
> compared to the complete guix-patches Git repo of 277M.

Nice.  Maintaining a shallow clone certainly makes sense.

> Well, I have not investigated much with ’grokmirror’ and
> ’public-inbox-fetch’ and maybe it would also work smoothly with the same
> trick; avoiding many manual plumbing.

I haven't used it myself (unsurprisingly I have an interest in keeping
yhetil.org's inboxes replicated on my local machine), but I think you
can keep grokmirror clones shallow by hooking up its grok-pi-piper to
the post-update hook. Here's a relevant bit from grokmirror's docs:

--8<---cut here---start->8---
[DEFAULT]
# To start piping public-inbox messages into your inbox, simply
# install procmail and add the following line to your ~/.procmailrc:
# DEFAULT=$HOME/Maildir/
# You can now read your mail with "mutt -f ~/Maildir/"
pipe = /usr/bin/procmail
# Once you've successfully piped the messages, you generally
# don't need them any more. If you set shallow = yes, then
# the repository will be configured as "shallow" and all succesffully
# processed messages will be pruned from the repo.
# This will greatly reduce disk space usage, especially on large archives.
# You can always get any number of them back, e.g. by running:
# git fetch _grokmirror master --deepen 100
shallow = yes
--8<---cut here---end--->8---

The Guix Days! (FOSDEM 2023)

[Simon Tournier]

Dear all,

We are organizing the Guix Days, satellite to FOSDEM.  Guix Days are 2
days for hacking and discussion open to everybody interested in Guix,
from core developer to newcomer.

When?  The 2 days right before FOSDEM:
  Thursday and Friday, February 2nd and 3rd, 2023.

Where?  The usual place in Brussels:
  Institute of Cultural Affairs (ICAB), Rue Amedee Lynen 8, 1210 Brussels

More details here:

https://libreplanet.org/wiki/FOSDEM2023-guix-days

Guix Days are free to attend!  We can only receive up to 40 people for
the Guix Days (previously, we had 35) and we need to reserve the
catering.  So, please sign up on the LibrePlanet link above (add your
name as Participants) if you intend to come.  If we happen to have too
many people to attend the meeting, the first 40 who signed up have a
guaranteed entry.  If you don't want to subscribe to the wiki, you can
send a request to Pjotr, Manolis or myself.

See some past editions:

https://libreplanet.org/wiki/Group:Guix


FOSDEM is an awesome free software conference and almost everyone who
goes once keeps coming because there is something for everyone.  The
conference is back as a physical conference.  Please check the devroom
“Declarative and Minimalistic Computing”.  Among many other devrooms
[1].

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

See some last years amazing FOSDEM program:

  https://archive.fosdem.org/2020/schedule
  https://archive.fosdem.org/2019/schedule


Hope to see you there!

1: 

Re: How to make audio devices available with guix shell --container

[Elias Kueny]

On Mon, Dec 05 2022, kiasoc5 wrote:

About the sound, I believe you will need to expose the pulseaudio
and/or pipewire sockets. You can reference bubblewrap configuration
since it also works by sharing/exposing files.

https://wiki.archlinux.org/title/Bubblewrap/Examples#Chromium


Thank you, that helped me progress. I noticed there were errors about not being 
able to connect to DBUS, now the following got rid of those:
guix shell -C -N -P --no-cwd \
--share=/dev/ \
--preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose="$XAUTHORITY" \
--preserve='^DBUS_.*' --expose=/var/run/dbus/system_bus_socket \
--expose="$XDG_RUNTIME_DIR/pulse" \
ungoogled-chromium -- chromium --app="https://meet.jit.si;

With this, I can use the microphone (there is no default microphone available, 
but my internal microphone can be selected and works), but I still have no 
sound.
ALSA throws the error "The field ipc_gid must be a valid group (create group 
audio)", and indeed /etc/group in the container doesn't contain an audio group (only 
users and overflow).

But `--expose=/etc/group` prevents the creation of the container with the error 
"guix shell: error: rename-file: Device or resource busy".
So the next question is: how does one uses groups in the container?

Re: This is how you import a mailing list archives (e.g. guix-patches) into mu4e

[zimoun]

Hi Kyle,

On Mon, 05 Dec 2022 at 20:03, Kyle Meyer  wrote:

> In terms of cloning archives, plain cloning and fetching with Git is
> fine, but, if you have public-inbox locally, you can instead use
> public-inbox-clone and public-inbox-fetch, which will handle some
> details for you (e.g, cloning underlying epochs and recognizing that new
> epochs have been added):
>
>  $ public-inbox-clone https://yhetil.org/guix-patches
>
> Another option for fetching that's nice if you're mirror multiple repos
> is grokmirror:
>
>  * https://git.kernel.org/pub/scm/utils/grokmirror/grokmirror.git/about/
>  * example setup for guix: 
> https://yhetil.org/guix-patches/878scww903@kyleam.com/

I fetch from yhetil.org (Git) and then convert to MailDir because I use
Notmuch as indexer (and reader :-)).  And I do not want to duplicate the
storage.  Therefore, after fetching and converting, the Git repo is
garbage collected,

--8<---cut here---start->8---
echo $head > $gitdir/shallow
$git gc --quiet --prune=all
--8<---cut here---end--->8---

https://gitlab.com/zimoun/my-conf/-/blob/master/.local/bin/sync-public-inboxes.sh#L94-99

For instance, the current size of guix-patches on my machine is 152K
compared to the complete guix-patches Git repo of 277M.


Well, I have not investigated much with ’grokmirror’ and
’public-inbox-fetch’ and maybe it would also work smoothly with the same
trick; avoiding many manual plumbing.

Thanks for sharing.

Cheers,
simon

Re: This is how you import a mailing list archives (e.g. guix-patches) into mu4e

[zimoun]

Hi,

On Mon, 05 Dec 2022 at 21:43, Mekeor Melire  wrote:

> I guess, a disadvantage of using public-inbox is that it's not an
> official service of the GNU Guix community.

It is up to us to have an “official” instance. :-)  Well, I remember
discussing how to setup a public-inbox instance for Guix but I fail to
find the message (probably a discussion on guix-sysad...@gnu.org :-)).

I mean the Guix project already serves https://issues.guix.gnu.org which
is an improvement, IMHO, over https://bugs.gnu.org.  We could also have
https://lists.guix.gnu.org serving ’public-inbox’es for the various
Guix mailing lists.

Cheers,
simon

Re: Drafting a Guix blog post on the FHS container

[Ludovic Courtès]

Hello!

John Kehayias  skribis:

> One question: what is appropriate or recommended for examples concerning 
> things like pre-built binaries? As an example, I had tested the FHS container 
> by running the Siril appimage, which has since been packaged for Guix (nice 
> work!). There are ones that I don't see that happening for anytime soon, like 
> an Electron-based app. Something like VSCodium is very popular, free (as in 
> freedom and I believe the FSDG sense), but just not something you can package 
> fully from source due to JavaScript as I understand it. It runs in the FHS 
> container.

A good example might be a free application not currently packaged in
Guix, for example due to being full of JavaScript, or nightly builds as
you wrote provided by an upstream project.

> Here is a current (rough!) draft. For the ease of plain text email I've 
> exported from the org source to text with some light edits:

Note that the blog takes Markdown¹, but hopefully the Org-to-markdown
export works well.

¹ https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts

The post looks great to me!  I have minor suggestions below:

> GNU Guix is different from most other GNU/Linux distributions and
> perhaps nowhere is that more obvious than the organization of the
> filesystem: Guix does not conform to the [File Hierarchy Standard]
> (FHS). In practical terms, this means there is no global `/lib'

It’s “Filesystem Hierarchy Standard”.

> To that end, we've [recently added] a new option for Guix containers,
> `--emulate-fhs' (or `-F'). This will set up an environment in the

Perhaps s/Guix containers/`guix shell`/ and add a few words about what
‘guix shell --container’ does (you can link to the manual or blog post).

> container that follows FHS expectations, so that libraries are visible
> in `/lib' in the container, as an example. Additionally, for the more
> technically-minded, the [`glibc' used in this container] will read from
> a global cache in `/etc/ld.so.cache' contrary to the behavior in [Guix
> otherwise].

Since the ld.so.cache issue is more involved (compared to simply having
/lib and /bin), maybe you can move it after the “ls /bin” example?

> Contrast that with `/bin' on a Guix system:
> ,
>  ls /bin -la
> `
>
> lrwxrwxrwx  1  root  root   61  Dec  3  16:37  sh  ->  
> /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/sh

You can show ‘ls /lib’ too.  :-)

Actually you can use or get inspiration from this animated GIF if you
like:

  https://web.fdn.fr/~lcourtes/tmp/guix-shell-fhs.gif

> useful. For example, there may be software that is free and conforms to
> the FSDG Guix follows, yet is not feasible to be [packaged] by our

s/FSDG/Free System Distribution Guidelines (FSDG)/

Thanks,
Ludo’.