Re: ️ Install every Guix package ️

[宋文武]

"jgart"  writes:

> Hi Guixers,
>
> How would you approach writing a script that installs every Guix package 
> exhaustively for your current revision?
>
> I'm thinking of something similar to `all-packages` on PyPi but for every 
> Guix package (the whole wide ️).
>
> https://pypi.org/project/all-packages/


Maybe guix package -m manifest.scm:

--8<---cut here---start->8---
(use-modules
 (srfi srfi-1)
 (ice-9 match)
 (gnu packages)
 (guix packages))

;;; copied from guix/scripts/weather.scm.
(define (all-packages)
  "Return the list of public packages we are going to query."
  (delete-duplicates
   (fold-packages (lambda (package result)
(match (package-replacement package)
  ((? package? replacement)
   (cons* replacement package result))
  (#f
   (cons package result
  '()

  ;; Dismiss deprecated packages but keep hidden packages.
  #:select? (negate package-superseded))
   eq?))

(packages->manifest (all-packages))
--8<---cut here---end--->8---

No idea how long it will be :)

Builds of https://guix.gnu.org/{packages,sources}.json

[Ludovic Courtès]

Hello Guix!

Until now, the files https://guix.gnu.org/{packages,sources}.json were
built as part of the web site’s build process, via Haunt.  Since these
files provide metadata about packages available in the tip of the Guix
repo, this required getting an inferior for that, and fiddling with it.

This was expensive and made the build process rather complicated (on
bayfront, which currently hosts the web site, missing substitutes would
often cause the web site to not build within the allocate 1h time slot;
this is why recent blog posts took hours to get there).

Thus I moved the former (apps packages builder) module of the web site
to a script in maintenance.git, and had it run as a periodic mcron job
populating /srv/package-metadata, with nginx serving these two files
from that directory:

  5664984 * hydra: web: Add mcron job to build /packages.json and /sources.json.
  318db3e * hydra: Add 'build-package-metadata.scm' script.

I then removed the corresponding bits in guix-artwork.git:

  fe11359 website: Remove references to the latest Guix in '.guix.scm'.
  f71ca12 website: Remove (apps packages builder).

I reconfigured both berlin and bayfront, so they’re now using this
method to build and publish these files.

Feedback welcome!

Ludo’.

Re: Has ci.guix.gnu.org stopped building?

[Leo Famulari]

On Wed, Jan 04, 2023 at 02:58:41PM -0500, Leo Famulari wrote:
> The issue seems to lie in the range of guix.git commits
> e84f17e..8e883dc, which are about Kodi and Wayland.
> 
> Ricardo is taking a look.

This was fixed with commit 658c09333da095edf6e1b3c5e351a7bfa3c87354

Re: Has ci.guix.gnu.org stopped building?

[Leo Famulari]

On Wed, Jan 04, 2023 at 09:43:11AM +0100, Mathieu Othacehe wrote:
> Yes the master specification has not been evaluated since December 30.
> It looks like all subsequent evaluations are never finishing which
> causes a database slots starvation causing even more evaluations to
> fail.
> 
> A good way to investigate that is often to run `make cuirass-jobs`
> locally. I'll try to do that today or tomorrow.

The issue seems to lie in the range of guix.git commits
e84f17e..8e883dc, which are about Kodi and Wayland.

Ricardo is taking a look.

Re: Drafting a Guix blog post on the FHS container

[John Kehayias]

Hi Jim,

On Wed, Jan 04, 2023 at 06:07 PM, Jim Newsome wrote:

> Thanks, looks good, and the command in your patch also works for me.
>

Great, thanks for testing!

> I agree that passing and exposing XAUTHORITY seems better. Experimentally, 
> sharing the directory
> read-only also works (using `--expose` instead of `--share`) also works, but 
> I'm not familiar enough with
> this mechanism to be confident that'll work for everyone, or whether making 
> it read-only is worth the
> fuss.
>

Ah, you are right, that seems to be just fine for VSCodium and Tor, in my quick 
test. I think I'll change that.

> Btw it turns out that `libevent` and `openssl@1` can be dropped; they're 
> already bundled. All together,
> here's my current "best" version:
>
> ```
> guix shell --container --network --emulate-fhs \
> --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY \
> alsa-lib bash coreutils dbus-glib file gcc:lib grep gtk+ \
> libcxx pciutils sed \
> -- ./start-tor-browser.desktop -v
> ```

Nice, thanks for that too! I tried eliminating a few random inputs, but they 
were needed. It is difficult sometimes to get a really minimal set, but this 
looks good to me.

John

Re: Drafting a Guix blog post on the FHS container

[Jim Newsome]

On Wed, Jan 4, 2023, at 5:47 PM, John Kehayias wrote:
> Hi Jim,
> 
> On Fri, Dec 16, 2022 at 05:39 PM, Jim Newsome wrote:
> 
> > Sorry for (presumably) breaking threading; I came across this online and
> > don't see a way to set my in-reply-to-email header properly.
> >
> > Anyways just thought I'd mention that I recently learned about this
> > feature, and was able to use it to get a downloaded [Tor Browser Bundle]
> > running with:
> >
> >
> > ```
> > guix shell \
> >--container \
> >--network \
> >--emulate-fhs \
> >--preserve='^DISPLAY$'
> >--share=/run/user/$(id -u)/gdm \
> >openssl@1 \
> >libevent \
> >pciutils \
> >dbus-glib \
> >bash \
> >libgccjit \
> >libcxx \
> >gtk+ \
> >coreutils \
> >grep \
> >sed \
> >file \
> >alsa-lib \
> >-- \
> >./start-tor-browser.desktop -v
> > ```
> >
> > `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to get
> > access to the display. I'm not sure the second parameter is universally
> > correct; I reverse-engineered it via roughly `ps aux | grep -- -auth`.
> >
> > The `-v` parameter to the browser script keeps it from trying to
> > background itself, which otherwise causes the container and browser to
> > terminate.
> >
> > It'd ultimately be nice to package the Tor Browser Bundle properly for
> > guix, but it's nice to be able to use it this way in the meantime.
> 
> Thanks again for this! I slightly modified it for the blog post, which you 
> can see in draft form at . I used 
> 'gcc:lib' instead of 'libgccjit' as it is smaller, and changed the needed 
> display options to be like the previous ones I had. Yours didn't work for me 
> since it looks like it relies on sharing something from GDM, which I don't 
> use. But do let me know if my version doesn't work for you.
> 
> Also gave you credit for this example; if you prefer not to be mentioned by 
> name/link to the mailing list for any reason, just let me know.
> 
> Oh, and we do have some (older) patches for building the Tor Browser from 
> source, but I don't know if they currently work: 
>  Your example was great though, something 
> very useful!
> 
> John

Thanks, looks good, and the command in your patch also works for me.

I agree that passing and exposing XAUTHORITY seems better. Experimentally, 
sharing the directory read-only also works (using `--expose` instead of 
`--share`) also works, but I'm not familiar enough with this mechanism to be 
confident that'll work for everyone, or whether making it read-only is worth 
the fuss.

Btw it turns out that `libevent` and `openssl@1` can be dropped; they're 
already bundled. All together, here's my current "best" version:

```
guix shell --container --network --emulate-fhs \
--preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY \
alsa-lib bash coreutils dbus-glib file gcc:lib grep gtk+ \
libcxx pciutils sed \
-- ./start-tor-browser.desktop -v
```

Re: Drafting a Guix blog post on the FHS container

[John Kehayias]

Hi Jim,

On Fri, Dec 16, 2022 at 05:39 PM, Jim Newsome wrote:

> Sorry for (presumably) breaking threading; I came across this online and
> don't see a way to set my in-reply-to-email header properly.
>
> Anyways just thought I'd mention that I recently learned about this
> feature, and was able to use it to get a downloaded [Tor Browser Bundle]
> running with:
>
>
> ```
> guix shell \
>--container \
>--network \
>--emulate-fhs \
>--preserve='^DISPLAY$'
>--share=/run/user/$(id -u)/gdm \
>openssl@1 \
>libevent \
>pciutils \
>dbus-glib \
>bash \
>libgccjit \
>libcxx \
>gtk+ \
>coreutils \
>grep \
>sed \
>file \
>alsa-lib \
>-- \
>./start-tor-browser.desktop -v
> ```
>
> `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to get
> access to the display. I'm not sure the second parameter is universally
> correct; I reverse-engineered it via roughly `ps aux | grep -- -auth`.
>
> The `-v` parameter to the browser script keeps it from trying to
> background itself, which otherwise causes the container and browser to
> terminate.
>
> It'd ultimately be nice to package the Tor Browser Bundle properly for
> guix, but it's nice to be able to use it this way in the meantime.

Thanks again for this! I slightly modified it for the blog post, which you can 
see in draft form at . I used 'gcc:lib' 
instead of 'libgccjit' as it is smaller, and changed the needed display options 
to be like the previous ones I had. Yours didn't work for me since it looks 
like it relies on sharing something from GDM, which I don't use. But do let me 
know if my version doesn't work for you.

Also gave you credit for this example; if you prefer not to be mentioned by 
name/link to the mailing list for any reason, just let me know.

Oh, and we do have some (older) patches for building the Tor Browser from 
source, but I don't know if they currently work: 
 Your example was great though, something 
very useful!

John

Re: [PATCH guix-artwork v4] website: posts: Add Dissecting Guix, Part 1: Derivations.

[Ludovic Courtès]

Heya (,

"("  skribis:

> * website/posts/dissecting-guix-1-derivations.md: New blog post.

Finally pushed!  It should show up online soon.  Looking forward to
part 2.  :-)

> +`guix repl` provides the `,lower` command to create derivations quickly:
> +
> +```scheme
> +,lower irssi
> +(pk $1) ;use the $N variable automatically bound by the REPL
> +;;; (# /gnu/store/drjfddvlblpr635jazrg9kn5azd9hsbj-irssi-1.4.3.drv => 
> /gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3 7f3bff4a6370>)
> +```

I took the liberty to turn this into a sample session to give a better
idea of what people would type and see at their REPL.

Thanks,
Ludo’.

Re: advanced?

[Ludovic Courtès]

Hello,

(Cc: Luis, for the web site design.)

Simon Josefsson  skribis:

> Ludovic Courtès  writes:
>
>> Or if we do want to explain more, then perhaps we need a list of
>> features that would also include things like Docker/VM image generation,
>> declarative home environments, etc.  But that’s broader topic.
>
> Yes, that makes sense.  I'm not the best person to summarize it, but
> starting pointers if someone wants to take it further:
>
> * Dedication to free software goals and the GNU community
>
> * Shepherd init system written in Guile
>
> * Declarative stateless system configurations
>
> * Transactional upgrades and roll-backs
>
> * Reproducible build environments
>
> * Designed towards bootstrappable builds
>
> Maybe this fits better directly in the Introduction section of the
> manual?  https://guix.gnu.org/manual/en/html_node/Introduction.html

I guess we should rework the “Introduction” and “Features” sections,
which were written in the early days.

The points you list above are a great starting point, and I guess that
would also be a good fit for the front page; currently there’s no
“feature list” there.  That old “Guix in action” video also ought to be
replaced.

Luis, do you have ideas as to how we could present things?

Thanks,
Ludo’.

Re: advanced?

[Ludovic Courtès]

Hi Simon and all,

Simon Josefsson via "Development of GNU Guix and the GNU System
distribution."  skribis:

> From aac8f6d1fb382b9f9120b7cd51dc80e8ef07cc03 Mon Sep 17 00:00:00 2001
> From: Simon Josefsson 
> Date: Sat, 26 Nov 2022 22:35:15 +0100
> Subject: [PATCH] website: Reduce use of 'advanced' term.
>
> ---
>  website/apps/base/templates/about.scm | 4 ++--
>  website/apps/base/templates/home.scm  | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)

It’s been a month and it looks like there wasn’t any opposition to this
change, so I went ahead and pushed it.

Thanks,
Ludo’.

Re: LaTeX packaging policy

[Ludovic Courtès]

Nguyễn Gia Phong  skribis:

> On 2023-01-04 at 08:11+01:00, Reza Housseini wrote:
>> What about size? Does [propagating all build inputs]
>> not bloat up profile sizes?
>
> I'm new to Guix, but aren't both build inputs
> and propagated build inputs required at run time?
> IIUC the only difference is that the propagated ones' env
> is, ehm, propagated all the way up instead of just
> to the direct dependee.

No, inputs are not necessarily available at run time.  An input is kept
at run time (as a “reference”) if and only if guix-daemon finds a
reference to it in the build product.

Ludo’.

Re: Has ci.guix.gnu.org stopped building?

[Mathieu Othacehe]

Hello Leo,

> According to the web interface, ci.guix.gnu.org stopped building things
> on December 31, with evaluation 79343.
>
> Is this true? What's wrong?

Yes the master specification has not been evaluated since December 30.
It looks like all subsequent evaluations are never finishing which
causes a database slots starvation causing even more evaluations to
fail.

A good way to investigate that is often to run `make cuirass-jobs`
locally. I'll try to do that today or tomorrow.

Thanks,

Mathieu