From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gary Johnson Subject: Re: Scripting guix in guile (Konrad Hinsen) Date: Thu, 05 Sep 2019 20:35:18 -0400 Message-ID: <87sgpa1cu1.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:54998) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i62Du-0002Si-Sx for help-guix@gnu.org; Thu, 05 Sep 2019 20:35:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i62Ds-0006Db-Ag for help-guix@gnu.org; Thu, 05 Sep 2019 20:35:34 -0400 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]:43754) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i62Ds-0006BR-0t for help-guix@gnu.org; Thu, 05 Sep 2019 20:35:32 -0400 Received: by mail-pf1-x42f.google.com with SMTP id d15so3060077pfo.10 for ; Thu, 05 Sep 2019 17:35:31 -0700 (PDT) In-reply-to: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Konrad Hinsen Cc: help-guix@gnu.org Hi Konrad, Just in case you hadn't thought of this yet, you can ensure that /usr/bin/env exists on any Guix system by consing the following entry onto the list of services under your operating-system definition. (extra-special-file "/usr/bin/env" (file-append coreutils "/bin/env")) Then your scripts could just use #!/usr/bin/env and work natively on GuixSD or a foreign distribution. Here's what the services entry looks like in my operating-system definition as an example: (services (cons* (extra-special-file "/usr/bin/env" (file-append coreutils = "/bin/env")) (postgresql-service #:extension-packages (list postgis)) (service bitlbee-service-type) (service docker-service-type) %desktop-services)) It's one extra step to explain in your tutorial, but if any of your students are already curious/brave enough to have installed GuixSD, they should be capable of adding that one line to the config.scm file (containing the operating-system definition) that they already had to create at OS install time. Then they just run `guix system reconfigure config.scm`, and they've got /usr/bin/env added to their system. No reboot. No delay. Just on with the show! YMMV, Gary help-guix-request@gnu.org writes: > Send Help-Guix mailing list submissions to > help-guix@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/help-guix > or, via email, send a message with subject or body 'help' to > help-guix-request@gnu.org > > You can reach the person managing the list at > help-guix-owner@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Help-Guix digest..." > > > Today's Topics: > > 1. Report on environment variable issues (Tirifto) > 2. Re: rust:cargo (libcurl) vs. CURL_CA_BUNDLE (David Loyall) > 3. Re: adding environment variables to /etc/config.scm > (Jonathan Lane) > 4. Re: Report on environment variable issues (Mikhail Kryshen) > 5. Re: Scripting guix in guile (Konrad Hinsen) > 6. Re: Help defining a trivial package. (Pierre-Henry F.) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 3 Sep 2019 21:25:50 +0200 > From: Tirifto > To: help-guix@gnu.org > Subject: Report on environment variable issues > Message-ID: <20190903212550.517dbf78@posteo.cz> > Content-Type: text/plain; charset=3DUTF-8 > > Hello! > > I am running Guix on Parabola GNU+Linux-libre (a libre derivative of > Arch Linux), and have had issues with environment variables in two > instances. I'm not asking for help, but I'm not sure if this is > appropriate for the bug list, either, so here we go. > > Firstly, when running GNOME Shell (native on Parabola), I tried > integrating it with Guix, so that applications installed with Guix > would be visible to GNOME Shell. I tried doing this by extending the > environment variable =E2=80=98$XDG_DATA_DIRS=E2=80=99, which is empty by = default, > but that made GNOME Shell crash on login. > > After some investigation, it turned out that GNOME Shell falls back on > a certain default value when the variable is empty, which already > contains paths that GNOME Shell needs to function properly. So when the > user extends the existing value of =E2=80=98$XDG_DATA_DIRS=E2=80=99 with = another path, > the variable is no longer empty, so GNOME Shell never gets to fall back > to the paths it actually needs, and crashes instead. > > The solution was to manually add the paths to the extension/definition. > I used =E2=80=98/usr/local/share:/usr/share=E2=80=99; not sure if that's = all there was > to it, but GNOME Shell could work with it. See also this Parabola bug: > > https://labs.parabola.nu/issues/2388 > > Secondly, I find that the program =E2=80=98youtube-dl=E2=80=99 (native on= Parabola) > doesn't work properly when I define environment variables for SSL > Certificates as advised by the Guix manual, like so: > > export SSL_CERT_DIR=3D"$HOME/.guix-profile/etc/ssl/certs" > export SSL_CERT_FILE=3D"$HOME/.guix-profile/etc/ssl/certs/ca-certif\ > icates.crt" > > youtube-dl then complains about being unable to get local issuer > certificates. On the other hand, when the variables are undefined, Guix > complains about certificates, for a change (e.g. when running =E2=80=98gu= ix > weather=E2=80=99). > > My current solution is to comment the variables out in my ~/.profile, > and only export them in the terminal when I'm about to use Guix. > > I don't know if these are reliably reproducible, and whether they > should be fixed somewhere, or just better documented, but I hope the > info can help! > > Best wishes > // Tirifto > > > > ------------------------------ > > Message: 2 > Date: Tue, 3 Sep 2019 19:16:48 -0500 > From: David Loyall > To: Ludovic Court=C3=A8s > Cc: help-guix@gnu.org > Subject: Re: rust:cargo (libcurl) vs. CURL_CA_BUNDLE > Message-ID: > > Content-Type: text/plain; charset=3D"UTF-8" > >> This was discussed recently on IRC: >> http://logs.guix.gnu.org/guix/2019-08-29.log#102010 >> Unfortunately we didn=E2=80=99t reach a conclusion. > > Ok, thank you. Unfortunately that user's pastebins expired so I was > not able to compare with my own `ltrace` output. > >> The =E2=80=98ltrace -e getenv=E2=80=99 trick I gave might give us >> clues about relevant environment variables. > > Ok, let's see: > > sebboh@geeks ~$ ltrace -e getenv cargo -vv install rustfmt-nightly > libcrypto.so.1.0.0->getenv("SSL_CERT_FILE") > =3D > "/home/sebboh/.guix-profile/etc/s"... > libcrypto.so.1.0.0->getenv("SSL_CERT_DIR") > =3D > "/home/sebboh/.guix-profile/etc/s"... > Updating crates.io index > libcurl.so.4->getenv("no_proxy") > =3D nil > libcurl.so.4->getenv("NO_PROXY") > =3D nil > libcurl.so.4->getenv("https_proxy") > =3D nil > libcurl.so.4->getenv("HTTPS_PROXY") > =3D nil > libcurl.so.4->getenv("all_proxy") > =3D nil > libcurl.so.4->getenv("ALL_PROXY") > =3D nil > libcurl.so.4->getenv("no_proxy") > =3D nil > libcurl.so.4->getenv("NO_PROXY") > =3D nil > libcurl.so.4->getenv("http_proxy") > =3D nil > libcurl.so.4->getenv("all_proxy") > =3D nil > libcurl.so.4->getenv("ALL_PROXY") > =3D nil > libcrypto.so.1.0.0->getenv("OPENSSL_ALLOW_PROXY_CERTS") > =3D nil > libcurl.so.4->getenv("no_proxy") > =3D nil > libcurl.so.4->getenv("NO_PROXY") > =3D nil > libcurl.so.4->getenv("http_proxy") > =3D nil > libcurl.so.4->getenv("all_proxy") > =3D nil > libcurl.so.4->getenv("ALL_PROXY") > =3D nil > libcrypto.so.1.0.0->getenv("OPENSSL_ALLOW_PROXY_CERTS") > =3D nil > libcurl.so.4->getenv("no_proxy") > =3D nil > libcurl.so.4->getenv("NO_PROXY") > =3D nil > libcurl.so.4->getenv("http_proxy") > =3D nil > libcurl.so.4->getenv("all_proxy") > =3D nil > libcurl.so.4->getenv("ALL_PROXY") > =3D nil > libcrypto.so.1.0.0->getenv("OPENSSL_ALLOW_PROXY_CERTS") > =3D nil > libcurl.so.4->getenv("no_proxy") > =3D nil > libcurl.so.4->getenv("NO_PROXY") > =3D nil > libcurl.so.4->getenv("https_proxy") > =3D nil > libcurl.so.4->getenv("HTTPS_PROXY") > =3D nil > libcurl.so.4->getenv("all_proxy") > =3D nil > libcurl.so.4->getenv("ALL_PROXY") > =3D nil > error: failed to download from > `https://crates.io/api/v1/crates/rustfmt-nightly/1.4.6/download` > > Caused by: > [60] SSL peer certificate or SSH remote key was not OK (server > certificate verification failed. CAfile: none CRLfile: none) > +++ exited (status 101) +++ > > I investigated this `OPENSSL_ALLOW_PROXY_CERTS` variable and I > concluded that I am not using any such cert--I believe in this case > libcurl checks an environment variable but would not act on the > result? Anyway, I don't use a proxy. (I just confirmed crates.io is > not on the blacklist at work.) > > Well, I'm not sure what to check next. I can tell you that the values > of SSL_CERT_FILE and SSL_CERT_DIR seem to be correct (even though the > ltrace output truncates them). > > Cheers, thanks, > --sebboh > > > > ------------------------------ > > Message: 3 > Date: Tue, 03 Sep 2019 19:04:59 -0700 > From: "Jonathan Lane" > To: Ludovic Court=C3=A8s > Cc: > Subject: Re: adding environment variables to /etc/config.scm > Message-ID: > Content-Type: text/plain; charset=3DUTF-8 > > On Tue Sep 3, 2019 at 11:27 AM Ludovic Court=C3=A8s wrote: >> Hello Jonathan, > >> Indeed, on Guix System one is not supposed to modify config files in >> place. >> >> Instead, you declare every aspect of your system config in your >> =E2=80=98operating-system=E2=80=99 declaration, and then run =E2=80=98re= configure=E2=80=99 so that it=E2=80=99s >> in effect. >> >> To add environment variables to /etc/environment, you would =E2=80=9Cext= end=E2=80=9D >> =E2=80=98session-environment-service-type=E2=80=99, like so: >> >> (simple-service 'cogl-variable session-environment-service-type >> '(("COGL_ATLAS_DEFAULT_BLIT_MODE" . "framebuffer"))) >> >> The expression above provides a service that you can add to the list in >> the =E2=80=98services=E2=80=99 field of your =E2=80=98operating-system= =E2=80=99 declaration. >> >> HTH! >> >> Ludo=E2=80=99. > > This worked perfectly, thanks! > > Jonathan > > --posted from Guix System, now with working Xorg > > > > > ------------------------------ > > Message: 4 > Date: Wed, 04 Sep 2019 05:30:29 +0300 > From: Mikhail Kryshen > To: Tirifto , help-guix@gnu.org > Subject: Re: Report on environment variable issues > Message-ID: <87r24wpzcq.fsf@home.localdomain> > Content-Type: text/plain; charset=3D"utf-8" > > Tirifto writes: > >> After some investigation, it turned out that GNOME Shell falls back on >> a certain default value when the variable is empty, which already >> contains paths that GNOME Shell needs to function properly. So when the >> user extends the existing value of =E2=80=98$XDG_DATA_DIRS=E2=80=99 with= another path, >> the variable is no longer empty, so GNOME Shell never gets to fall back >> to the paths it actually needs, and crashes instead. > > GNOME does this in accordance with XDG Base Directory Specification, see > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.h= tml > > "If $XDG_DATA_DIRS is either not set or empty, a value equal to > /usr/local/share/:/usr/share/ should be used."