* Re: Scripting guix in guile (Konrad Hinsen)
[not found] <mailman.1897.1567596117.2071.help-guix@gnu.org>
@ 2019-09-06 0:35 ` Gary Johnson
2019-09-06 8:48 ` Konrad Hinsen
0 siblings, 1 reply; 5+ messages in thread
From: Gary Johnson @ 2019-09-06 0:35 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: help-guix
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 <tirifto@posteo.cz>
> To: help-guix@gnu.org
> Subject: Report on environment variable issues
> Message-ID: <20190903212550.517dbf78@posteo.cz>
> Content-Type: text/plain; charset=UTF-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 ‘$XDG_DATA_DIRS’, 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 ‘$XDG_DATA_DIRS’ 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 ‘/usr/local/share:/usr/share’; 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 ‘youtube-dl’ (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="$HOME/.guix-profile/etc/ssl/certs"
> export SSL_CERT_FILE="$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 ‘guix
> weather’).
>
> 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 <david@the-good-guys.net>
> To: Ludovic Courtès <ludo@gnu.org>
> Cc: help-guix@gnu.org
> Subject: Re: rust:cargo (libcurl) vs. CURL_CA_BUNDLE
> Message-ID:
> <CA+4fW6mVX0hte+4SjDbgBNrr=uxW7G+ECHO6dhOh43xZ2tsNDA@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
>> This was discussed recently on IRC:
>> http://logs.guix.gnu.org/guix/2019-08-29.log#102010
>> Unfortunately we didn’t 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 ‘ltrace -e getenv’ 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")
> =
> "/home/sebboh/.guix-profile/etc/s"...
> libcrypto.so.1.0.0->getenv("SSL_CERT_DIR")
> =
> "/home/sebboh/.guix-profile/etc/s"...
> Updating crates.io index
> libcurl.so.4->getenv("no_proxy")
> = nil
> libcurl.so.4->getenv("NO_PROXY")
> = nil
> libcurl.so.4->getenv("https_proxy")
> = nil
> libcurl.so.4->getenv("HTTPS_PROXY")
> = nil
> libcurl.so.4->getenv("all_proxy")
> = nil
> libcurl.so.4->getenv("ALL_PROXY")
> = nil
> libcurl.so.4->getenv("no_proxy")
> = nil
> libcurl.so.4->getenv("NO_PROXY")
> = nil
> libcurl.so.4->getenv("http_proxy")
> = nil
> libcurl.so.4->getenv("all_proxy")
> = nil
> libcurl.so.4->getenv("ALL_PROXY")
> = nil
> libcrypto.so.1.0.0->getenv("OPENSSL_ALLOW_PROXY_CERTS")
> = nil
> libcurl.so.4->getenv("no_proxy")
> = nil
> libcurl.so.4->getenv("NO_PROXY")
> = nil
> libcurl.so.4->getenv("http_proxy")
> = nil
> libcurl.so.4->getenv("all_proxy")
> = nil
> libcurl.so.4->getenv("ALL_PROXY")
> = nil
> libcrypto.so.1.0.0->getenv("OPENSSL_ALLOW_PROXY_CERTS")
> = nil
> libcurl.so.4->getenv("no_proxy")
> = nil
> libcurl.so.4->getenv("NO_PROXY")
> = nil
> libcurl.so.4->getenv("http_proxy")
> = nil
> libcurl.so.4->getenv("all_proxy")
> = nil
> libcurl.so.4->getenv("ALL_PROXY")
> = nil
> libcrypto.so.1.0.0->getenv("OPENSSL_ALLOW_PROXY_CERTS")
> = nil
> libcurl.so.4->getenv("no_proxy")
> = nil
> libcurl.so.4->getenv("NO_PROXY")
> = nil
> libcurl.so.4->getenv("https_proxy")
> = nil
> libcurl.so.4->getenv("HTTPS_PROXY")
> = nil
> libcurl.so.4->getenv("all_proxy")
> = nil
> libcurl.so.4->getenv("ALL_PROXY")
> = 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" <jon@dorsal.tk>
> To: Ludovic Courtès <ludo@gnu.org>
> Cc: <help-guix@gnu.org>
> Subject: Re: adding environment variables to /etc/config.scm
> Message-ID: <BWQULMK8V3TT.3N6O7DFZ4U3QG@suika>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue Sep 3, 2019 at 11:27 AM Ludovic Courtès 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
>> ‘operating-system’ declaration, and then run ‘reconfigure’ so that it’s
>> in effect.
>>
>> To add environment variables to /etc/environment, you would “extend”
>> ‘session-environment-service-type’, 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 ‘services’ field of your ‘operating-system’ declaration.
>>
>> HTH!
>>
>> Ludo’.
>
> 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 <mikhail@kryshen.net>
> To: Tirifto <tirifto@posteo.cz>, help-guix@gnu.org
> Subject: Re: Report on environment variable issues
> Message-ID: <87r24wpzcq.fsf@home.localdomain>
> Content-Type: text/plain; charset="utf-8"
>
> Tirifto <tirifto@posteo.cz> 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 ‘$XDG_DATA_DIRS’ 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.html
>
> "If $XDG_DATA_DIRS is either not set or empty, a value equal to
> /usr/local/share/:/usr/share/ should be used."
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Scripting guix in guile (Konrad Hinsen)
2019-09-06 0:35 ` Scripting guix in guile (Konrad Hinsen) Gary Johnson
@ 2019-09-06 8:48 ` Konrad Hinsen
2019-09-06 10:28 ` Tobias Geerinckx-Rice
2019-09-06 20:56 ` Gary Johnson
0 siblings, 2 replies; 5+ messages in thread
From: Konrad Hinsen @ 2019-09-06 8:48 UTC (permalink / raw)
To: Gary Johnson; +Cc: help-guix
Hi Gary,
> 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.
I hadn't thought of this for the simple reason that I didn't know about
this mechanism. It looks very useful, thanks for the pointer!
Is there any reason why this isn't defined by default? That would solve
portability problems for lots of scripts, and I don't see any
disadvantage caused by this link.
Cheers,
Konrad
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Scripting guix in guile (Konrad Hinsen)
2019-09-06 8:48 ` Konrad Hinsen
@ 2019-09-06 10:28 ` Tobias Geerinckx-Rice
2019-09-07 16:51 ` Konrad Hinsen
2019-09-06 20:56 ` Gary Johnson
1 sibling, 1 reply; 5+ messages in thread
From: Tobias Geerinckx-Rice @ 2019-09-06 10:28 UTC (permalink / raw)
To: help-guix, 35910-done; +Cc: Gary Johnson
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
Konrad,
Konrad Hinsen 写道:
> Is there any reason why this isn't defined by default? That
> would solve
> portability problems for lots of scripts, and I don't see any
> disadvantage caused by this link.
It is now!
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Scripting guix in guile (Konrad Hinsen)
2019-09-06 8:48 ` Konrad Hinsen
2019-09-06 10:28 ` Tobias Geerinckx-Rice
@ 2019-09-06 20:56 ` Gary Johnson
1 sibling, 0 replies; 5+ messages in thread
From: Gary Johnson @ 2019-09-06 20:56 UTC (permalink / raw)
To: Konrad Hinsen; +Cc: help-guix
Hi Konrad,
Fair enough. I was pleasantly surprised to discover that trick while
digging through the Guix manual several months ago. In the Guix info
pages, the documentation for it can be found under this path:
System Configuration -> Services -> Base Services -> extra-special-file
I'm not one of the Guix developers. I'm just a user, but my guess as to
why it isn't defined by default is that a big part of the GuixSD
mindset/philosophy AFAICT is to ensure that as little as possible is
installed under the usual FHS file tree (e.g., /usr, /bin, /sbin, /etc,
...). Instead as much of the OS as is technically feasible is installed
under /gnu/store.
This makes reproducing the same OS setup on a different machine a matter
of just running a handful of Guix commands on a blank hard drive
partition and feeding them your operating-system definition and package
manifest (both encoded as Scheme objects, of course). It also reduces
the likelihood of any file collisions when using the Guix package
manager on a foreign distro.
Since you're teaching a tutorial on Guix, you no doubt already grok all
of this, so my apologies for any redundancy here. In short, I just guess
/usr/bin/env isn't there because it doesn't need to be there for most
day-to-day Guix usage. If it is useful to a user, they can add the
extra-special-file service to their operating-system definition as per
my example.
That being said, if /usr/bin/env were added by default to the
special-files-service-type (which is part of %base-services), I'd
certainly not complain, and I think it would save quite a few users the
time that I spent digging through the manual for that particular
solution.
Good luck and happy hacking!
Gary
Konrad Hinsen <konrad.hinsen@fastmail.net> writes:
> Hi Gary,
>
>> 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.
>
> I hadn't thought of this for the simple reason that I didn't know about
> this mechanism. It looks very useful, thanks for the pointer!
>
> Is there any reason why this isn't defined by default? That would solve
> portability problems for lots of scripts, and I don't see any
> disadvantage caused by this link.
>
> Cheers,
> Konrad
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Scripting guix in guile (Konrad Hinsen)
2019-09-06 10:28 ` Tobias Geerinckx-Rice
@ 2019-09-07 16:51 ` Konrad Hinsen
0 siblings, 0 replies; 5+ messages in thread
From: Konrad Hinsen @ 2019-09-07 16:51 UTC (permalink / raw)
To: Tobias Geerinckx-Rice, help-guix
On 06/09/2019 12:28, Tobias Geerinckx-Rice wrote:
>
> Konrad Hinsen 写道:
>> Is there any reason why this isn't defined by default? That would solve
>> portability problems for lots of scripts, and I don't see any
>> disadvantage caused by this link.
>
> It is now!
Great, thanks!
Konrad
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-09-07 16:51 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.1897.1567596117.2071.help-guix@gnu.org>
2019-09-06 0:35 ` Scripting guix in guile (Konrad Hinsen) Gary Johnson
2019-09-06 8:48 ` Konrad Hinsen
2019-09-06 10:28 ` Tobias Geerinckx-Rice
2019-09-07 16:51 ` Konrad Hinsen
2019-09-06 20:56 ` Gary Johnson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).