Hi,
As some extra info:
`guix shell` by default does what `guix environment --ad-hoc` did.
And `guix shell --development` is what `guix environment` was.
They are equivalent, but the flags might be confusing at the beginning!
Happy hacking!
Ekaitz
[ElenQ Technology](https://elenq.tech)
Ethical
Hello : )
Thank you both! I did not know that. I previously mistakenly thought
"environment = shell", but did not know, that I would have to add `-D` or
`--development` to actually make an equivalent call. So `guix shell`, I guess,
is more nuanced then, than `guix environment`.
An
Zelphir Kaltstahl writes:
> I am messing around again with updating a package and according to my
> own guide from previous adventures, I have to run the following
> command to generate the `pre-inst-env` script, in the root directory
> of the guix sources:
>
>
>
Hi,
Isn't `guix environment guix` equivalent to `guix shell -D guix`?
I think you are missing a -D there so it's adding a shell with guix and not
with its development dependencies.
Hope that helps,
Ekaitz
[ElenQ Technology](https://elenq.tech)
Ethical Innovation
--- Origin
ssing around again with updating a package and according to my own
>> guide from previous adventures, I have to run the following command to
>> generate the `pre-inst-env` script, in the root directory of the guix
>> sources:
>>
>>
>> guix environment guix
:
guix environment guix -- ./bootstrap
But then I remembered, that actually `guix shell` is the newer thing and
changed it to:
guix shell guix -- ./bootstrap
However, this does not work. I get an error:
$ guix shell guix -- ./bootstrap
+ find po/doc -type f -name guix
Hello Guix developers!
I am messing around again with updating a package and according to my own guide
from previous adventures, I have to run the following command to generate the
`pre-inst-env` script, in the root directory of the guix sources:
guix environment guix -- ./bootstrap
Hi Robin & Attila,
Attila Lendvai skribis:
> FWIW, i'm new to Guix, and it was enough to read the --help output to
> understand how --file works, but i still don't know what manifests are
> (even though i'm regularly using `guix package -m
> /path/to/manifest.scm`, which i have copied from somew
> as an alternative for '-l'/'--load' there.) I often write simple
> packages in individual files, outside of the guix repo or any kind of
> proper channel setup, and I don't see much point in requiring every such
> package to have its own single-package manifest, although it wouldn't be
> too diff
gt;> - guix build --file
>> - guix package --file
>>
>> and then there's:
>> - guix environment --load
>> - guix pack # has neither
>>
>> i'd propose to change guix environment to also use --file, but maybe i'm
>> overlooking something, so
Hi,
On Thu, 23 Sept 2021 at 22:49, Ludovic Courtès wrote:
> ‘guix environment --load’ could be similarly deprecated, either to be
> eventually removed or to be renamed to ‘--file’.
I would like to point this really really long thread [1] about
modifying the CLI vs backward compatibiliti
Hi Attila,
Attila Lendvai skribis:
> i was writing the documentation of a guix.scm file, and i realized that
> there's an inconsistency among the three most used commands in this context:
>
> so, there's:
> - guix build --file
> - guix package --file
>
> and
dear all,
i was writing the documentation of a guix.scm file, and i realized that there's
an inconsistency among the three most used commands in this context:
so, there's:
- guix build --file
- guix package --file
and then there's:
- guix environment --load
- guix pack # h
Em sáb., 17 de abr. de 2021 às 13:10, Ludovic Courtès escreveu:
> Hi Vinícius,
Hi Ludovic,
> What we could do is add a ‘--uid’ option to ‘guix environment’ and/or a
> ‘--host-name’ option.
>
> WDYT?
The --host-name option would work for me. That'd be enough to control
xp
Hi Vinícius,
Vinícius dos Santos Oliveira skribis:
> Right now my hostname is leaking to the container and that is certainly a
> hint to my main persona.
AFAICS, ‘guix environment -C’ already starts contains in a separate UTS
namespace (see ‘%namespaces’ in (gnu build linux-cont
On Fri, 16 Apr 2021 17:09:26 +0100
pkill9 wrote:
> darth-cheney asked in IRC if from inside a guix environment you would
> install the packages instead of pip/node, and maybe having guix
> install packages to current guix environment would be a good idea.
>
> Possible issue
Hi,
This could be trouble. Sometimes, when I'm hacking on Guix in an
environment created using `guix environment guix`, I install a package
to my main user profile using `./pre-inst-env guix install ...`. The
behaviour you suggest would interfere with this.
Regards,
Arun
signatur
darth-cheney asked in IRC if from inside a guix environment you would
install the packages instead of pip/node, and maybe having guix install
packages to current guix environment would be a good idea.
Possible issue would be how to change the current guix environment to
the new profile, without
Some programs (e.g. xpra) create files based on the hostname and it'd be
useful to have control of this parameter.
There's another reason to have custom hostnames within the container as
well. From the guix manual[1]:
While this will limit the leaking of user identity through home paths and
> eac
Julien Lepiller writes:
> Le 23 mars 2021 18:25:38 GMT-04:00, c4t0 a écrit :
>>
>>Hi,
>>
>>I'm having trouble importing a package from hackage, so I tried to
>>debug
>>the import source code. After cloning guix I found that I can't start a
>
Le 23 mars 2021 18:25:38 GMT-04:00, c4t0 a écrit :
>
>Hi,
>
>I'm having trouble importing a package from hackage, so I tried to
>debug
>the import source code. After cloning guix I found that I can't start a
>pure environment:
>
>guix environment gui
Hi,
I'm having trouble importing a package from hackage, so I tried to debug
the import source code. After cloning guix I found that I can't start a pure
environment:
guix environment guix --pure --ad-hoc help2man git strace
Command 'lesspipe' is available in the foll
Hi,
Ricardo Wurmus skribis:
> strace reveals more. For example, some time is lost searching libraries
> and other files. (At least the excessive library searches should
> already have been mitigated by changes on the core-updates branch.)
> This includes reading .go files, .scm files, reading
s
> profile/environment manipulation (because they’re essentially the same)
> and one that can set them up for use. In that world you’d do
>
> $ guix environment $(guix profile -m manifest.scm -i additional-package)
For the record, such command (as “profile manager”) had been discussed,
f
-process
"guix" nil nil nil
"bash" "-c"
"if [ -f ... ]; then
guix environment --profile=...
else
guix environment --root=...
fi")
--8<---cut here---end--->8---
which is more cumbersome
ne that can set them up for use. In that world you’d do
$ guix environment $(guix profile -m manifest.scm -i additional-package)
to get a temporary profile/environment and
# add a few packages
$ guix profile -p /path -m manifest.scm -i additional-package
/path
# remove one
$ guix profile
art----->8---
$ guix environment -l ./build-scripts/guix.scm -r my-root -p my-profile
guix environment: error: '--profile' cannot be used with package options
--8<---cut here---end--->8---
Instead, I'd like the following behaviour:
-
Pierre Neidhardt writes:
> It seems to be some thing more than just Guix commands being slow.
> On my machine
>
>
> --8<---cut here---start----->8---
> $ time guix environment --help >/dev/null
>
> real 0m0.345s
> --8<--
Lars-Dominik Braun writes:
>> My only complaint is that it's still a bit slow:
>> Is there anything we can do to speed this up?
> yeah, true. I’m think it’s still computing and building derivations, for
> example using manifest->derivation for `prof-drv` and then again
> built-derivations for `pr
Hi Pierre,
> My only complaint is that it's still a bit slow:
> Is there anything we can do to speed this up?
yeah, true. I’m think it’s still computing and building derivations, for
example using manifest->derivation for `prof-drv` and then again
built-derivations for `prof-drv`. Maybe if we make
Hi Pierre,
On Thu, 11 Mar 2021 at 21:04, Pierre Neidhardt wrote:
> My only complaint is that it's still a bit slow:
>
> --8<---cut here---start->8---
> time guix environment -C --profile=/my/profile -- exit
>
> real 0m2.372s
Hi,
> Can I ask: What is your use-case? Why not extend the existing profile
> using `guix package -p /path -i foobar`?
I'm making a script that uses guix containers for running applications
isolated from eachother, and I have a single profile for each
application. I want to be able to start the c
Hi Pierre,
> Do you have a link?
sorry, I meant, I wrote the patch that added the --profile switch, see
https://issues.guix.gnu.org/46291
> I'd love to see this merged! :)
The patch above is already merged.
Cheers,
Lars
signature.asc
Description: PGP signature
Hi,
> guix environment doesn't allow --ad-hoc to be used when --profile is
> set. I propose to have --ad-hoc add more packages to the container when
> using it with --profile.
I wrote the patch that adds this feature to `guix environment`. The idea
was to have a way to turn an ex
guix environment doesn't allow --ad-hoc to be used when --profile is
set. I propose to have --ad-hoc add more packages to the container when
using it with --profile.
Thoughts?
Lee Fallat 写道：
Hey,
Hi, welcome, and thanks for the patch!
I responded on IRC (mail client's being stupid) but you don't seem
to be on-line, so here's a less ephemeral copy:
There's a list specifically for patches (unimaginatively named
guix-patches@), tracked together with bug-guix@ over
11 @@ they should be defined in @file{.bash_profile}, which is sourced only by
log-in shells. @xref{Bash Startup Files,,, bash, The GNU Bash Reference
Manual}, for details on Bash start-up files.}.
+Exiting from a guix environment is the same as exiting from the shell, and will
+place the
On Mon, 07 Dec 2020 05:51:05 +0900
yasu wrote:
> Hi Zimoun,
>
> I tried as you suggested but it didn't work...
>
>
>root@guix ~# echo "kernel.unprivileged_userns_clone = 1" >
>/etc/sysctl.d/local.conf
>-bash: /etc/sysctl.d/local.conf: No such file or directory
This could mean you
This issue seems to be gone for me with kernel 5.10.x.
I guess it was a kernel bug then.
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hi,
On Mon, 07 Dec 2020 at 21:35, Pierre Neidhardt wrote:
>> Thanks, that gives us a clue. So all or part of the path
>> '/proc/sys/kernel' is missing?
>
> Nope, my /proc/sys/kernel has 121 direct files and directories :/
Well, it is expected. And now all is clear. Explanations starting
ther
Hi Pierre,
> # echo 1 > /proc/sys/kernel/unprivileged_userns_clone
> -bash: /proc/sys/kernel/unprivileged_userns_clone: No such file or
> directory
Thanks, that gives us a clue. So all or part of the path
'/proc/sys/kernel' is missing?
Best regards,
Paul.
Hi Paul,
> Can you try, as root on Guix System:
>
> $ echo 1 > /proc/sys/kernel/unprivileged_userns_clone
# echo 1 > /proc/sys/kernel/unprivileged_userns_clone
-bash: /proc/sys/kernel/unprivileged_userns_clone: No such file or directory
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Hi Pierre,
On Mon, 07 Dec 2020 at 12:57, Pierre Neidhardt wrote:
> Guix' bug?
You get something as:
$ guix environment -C guix
guix environment: error: cannot create container: unprivileged user cannot
create user namespaces
guix environment: error: please set
/proc/sy
Just FYI (sorry to interject) , my original email was stripped of html
elements? anyway, I was referring to this link
https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do#comment442083_209533
-Yasu
> On Dec 7, 2020, at 21:31, Paul Garlick
Hi!
I can reproduce the issue since I 'recondigure'd my Guix System.
I'm on cebfb29abb151ede95696181d2446c63504593d7.
Guix' bug?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hi Pierre,
Can you try, as root on Guix System:
$ echo 1 > /proc/sys/kernel/unprivileged_userns_clone
If you could report success or failure that would be helpful; the
unprivileged-user-namespace-supported? test in gnu/build/linux-
container.scm should be the same irrespective of the underlying
"1"
>
> As root, you just do:
>
> echo 1 > /proc/sys/kernel/unprivileged_userns_clone
>
> then “guix environment -C” should work as expected. To do the trick
> automatically with Sheperd, I do not know, but I am sure that the
> systemd equivalent
>
>
Hi Zimoun,
I tried as you suggested but it didn't work...
root@guix ~# echo "kernel.unprivileged_userns_clone = 1" >
/etc/sysctl.d/local.conf
-bash: /etc/sysctl.d/local.conf: No such file or directory
root@guix ~# sysctl --system
root@guix ~# logout
~$ g
Hi,
Please try the recommendation. Have you tried it?
please set /proc/sys/kernel/unprivileged_userns_clone to "1"
As root, you just do:
echo 1 > /proc/sys/kernel/unprivileged_userns_clone
then “guix environment -C” should work as expected. To do the trick
automatically wi
yasu 写道：
Now, I don't use Debian at all (I use Guix System) and do you
think
this is a Bug in Guix (in that this Debian specific word should
never
even be mentioned in Guix?)
It's not Debian-specific. It is a bug in Guix.
It should try to create a namespace and properly report an error
iff
and do you think
this is a Bug in Guix (in that this Debian specific word should never
even be mentioned in Guix?)
To summarize this bug again:
The Bug:
The container command no longer works, after the commit
8bc5ca5160db3d82bd5b6b2b7ed80c96f42bd33e.
guix environment -C
Additional I
Hi Pj,
Thank you for you reply (and your wonderful Hacking Guide
https://gitlab.com/pjotrp/guix-notes/blob/master/HACKING.org)!
I tried the command and it didn't work...
I use Guix System (not a foreign distribution) as described at the
bottom :-)
-Yasu
On Fri, 2020-12-04 at 19:55 +0100, Pjo
On Fri, Dec 04, 2020 at 05:32:08PM +0100, zimoun wrote:
> Have you tried to do the recommandation?
>
> please set /proc/sys/kernel/unprivileged_userns_clone to "1"
As root:
echo 1 > /proc/sys/kernel/unprivileged_userns_clone
Yes, it is common on Debian and such.
Pj.
Hi everyone!
I use both:
* Guix System with Linux(non-Libre) Kernel, straight on my desktop PC
* Guix System on Linux subsystem on Windows 10
(https://github.com/giuliano108/guix-packages/blob/master/notes/Guix-on-WSL2.md)
on Microsoft Surface Book
and both started to exhibit the same problem w
compile ./pre-inst-env .
> […]
>> I hope this is a bug that can be fixed. Otherwise, it looks like I
>> won't be able to compile pre-inst-env?
>
> Is “guix environment --pure” not enough?
>
> --
> Ricardo
; ~/co/guix (master)$ guix environment -C guix
> guix environment: error: cannot create container: unprivileged user cannot
> create user namespaces
> guix environment: error: please set
> /proc/sys/kernel/unprivileged_userns_clone to "1"
Have you tried to do the recommandation
Hi Yasu,
> I rely on the -C option below to compile ./pre-inst-env .
[…]
> I hope this is a bug that can be fixed. Otherwise, it looks like I
> won't be able to compile pre-inst-env?
Is “guix environment --pure” not enough?
--
Ricardo
Hi Guix Development,
I rely on the -C option below to compile ./pre-inst-env .
guix environment -C guix
(I learned the technique through
https://gitlab.com/pjotrp/guix-notes/blob/master/INSTALL.org -
./pre-inst-env just won't compile correctly unless I follow the
instructions on the
Hi,
Zhu Zihao skribis:
> "guix environment --container" is a very useful feature for me to
> isolate the untrusted software. But sadly it lacks a interface for user
> to use it in Lisp programming.
The interface to containers is in (gnu build linux-container), though
it’
Leo Prikler writes:
> For the record, what you do want is something à la
> (call-in-container-environment THUNK MANIFEST . KWARGS)
> where manifest is the Guix environment manifest, THUNK is a procedure
> to call with 0 arguments and KWARGS is a list of options for things you
> mi
given that your stated goal is to port container
> > entry
> > scripts [I read this as "the script called by the container at
> > entry"]
> > to Guile, would it not make sense to have
> >
> > (guix-environment [ENVIRONMENT OPTIONS] "--" &quo
gt; code through Guix environments, so you'd have to build that on your
> own. However, given that your stated goal is to port container entry
> scripts [I read this as "the script called by the container at entry"]
> to Guile, would it not make sense to have
>
> (guix-
Hello,
Am Mittwoch, den 04.11.2020, 11:49 +0800 schrieb Zhu Zihao
> "guix environment --container" is a very useful feature for me to
> isolate the untrusted software. But sadly it lacks a interface for
> user
> to use it in Lisp programming.
>
> In (guix scri
"guix environment --container" is a very useful feature for me to
isolate the untrusted software. But sadly it lacks a interface for user
to use it in Lisp programming.
In (guix scripts environment), only `guix-environment` is exported. but
it process unix style command line op
Hey,
I was toying with the idea of automatically detecting discrepancies in
environment variables, so I tried the attached patch, which would check
/proc/PID/environ compared to the profile’s search path variables.
Unfortunately, that doesn’t work because Bash for instance does not
change its own
ging guix could also have a check added
>>> to guix
>>> doctor.
>
> Interesting. Any idea how this particular issue could be checked for?
> If we can come up with an automated way to determine that “something’s
> wrong”, we might as well get ‘guix environment’ to disp
Any idea how this particular issue could be checked for?
If we can come up with an automated way to determine that “something’s
wrong”, we might as well get ‘guix environment’ to display a hint.
> Also because I share my shell and other configuration files across
> distributions, it's n
Brendan Tildesley writes:
Doom Emacs has a tool `doom doctor' for diagnosing common
errors. Perhaps there
could be a `guix doctor' that would check for such things. `guix
offload test'
is already somewhat like that but for offloading, althought it
could improve.
Any bug report from a user w
Doom Emacs has a tool `doom doctor' for diagnosing common errors.
Perhaps there could be a `guix doctor' that would check for such things.
`guix offload test' is already somewhat like that but for offloading,
althought it could improve. Any bug report from a user where the
solution is to tell t
Hello Guix!
One thing that often trips up newcomers, especially on other distros, is
the interaction of ‘guix environment’ and ‘.bashrc’ etc. when it comes
to setting environment variables. Often the first experience is “why
doesn’t ‘guix environment’ set environment variables correctly?”.
The
I've sent a patch: #41041.
signature.asc
Description: PGP signature
On Tue, Apr 21, 2020 at 10:50:09PM +0200, Pierre Neidhardt wrote:
> Makes sense, thank you for the details.
>
> What about adding the above example to the manual page of `guix environment'??
Take a look at the existing docs on X.509 Certificates and see if we can
impro
On 21/04/2020 22:50, Pierre Neidhardt wrote:
Makes sense, thank you for the details.
What about adding the above example to the manual page of `guix environment'??
Good idea. I suppose it's not just Web browsers that will need this. I
remember occasional certificate problems wh
On Tue, Apr 21, 2020 at 06:17:58PM +0200, Pierre Neidhardt wrote:
> Note that the "--expose=/etc/ssl/certs/" is important.
>
> Should we consider this a bug? If not, then should we document
> it?
No, it's not a bug.
TLS X.509 certificates need to be looked up dynamically at run-time,
because th
It works!
--8<---cut here---start->8---
guix environment -C -N --expose=/etc/machine-id --expose=/etc/ssl/certs/ \
--share=$HOME/.local/share/eolie/=$HOME/.local/share/eolie/ \
--ad-hoc dbus eolie coreutils nss-certs -- \
env DISPLAY=$DISPLAY eol
Hi Pierre,
I think you need the nss-certs package in the environment, to start. Does
adding them help?
- John
Hi!
I'd like to run browsers in `guix environment` which seems to be a good
idea! :)
IceCat has been discussed in the past. Now I'd like to run
WebKitGTK-based browsers.
Let's try with Eolie for now, since it seems to have less issues than,
say, Epiphany.
--8<-
On Fri 20 Dec 2019 22:08, Ricardo Wurmus writes:
> zimoun writes:
>
>> - I propose the name "guix shell"
>
> This is not a bad idea, especially considering that “guix environment”
> was meant to get shebang support, so that you could use it as the
> interp
Hi Ricardo,
On Fri, 20 Dec 2019 22:08:48 +0100
Ricardo Wurmus wrote:
> zimoun writes:
>
> > - I propose the name "guix shell"
>
> This is not a bad idea, especially considering that “guix environment”
> was meant to get shebang support, so that you could u
Hi Ricardo,
> I wonder if we should simply bump the version number to indicate that
> this is a breaking change?
That's a possibility, but who ever looks at Guix version numbers?
> Another more difficult option would be to do what responsible API
> developers on the web do: to version their API
kind of “strong” trauma is
fairly easy to spot in advance."
Well, I understand when speaking about Python. Are we comparing the
number of Guix users with the number of Python users? Are we comparing
the number of changes between Python 2 and 3 with the change of the
default "guix environm
Hi zimoun,
zimoun writes:
> Konrad's example. So, nothing new on the table; except you are
> starting to throw "feelings" with the "traumatic change" words.
I do not see this as feelings, but as strategy. That’s what the article
is about: Many small breakages add up, and repeated changes to
best
tutorial about using Guix for
> reproducible research. It shows several uses of "guix environment", some
> of them without '–add-hoc' or '–inputs-of'. I know my examples will
> cease to work in a few months. What am I supposed to do about this?
I wonder if
zimoun writes:
> - I propose the name "guix shell"
This is not a bad idea, especially considering that “guix environment”
was meant to get shebang support, so that you could use it as the
interpreter in a script that handles the environment configuration.
It is also shorter.
--
Ricardo
would we
> > frame it in the set of commands?
>
> I vote for discussing the second point before the first one. Names
> should reflect the functionality behind them.
The starting point seems:
- https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html
- what do you feel missing about "guix environment"?
Considering my use-case, I am mostly aligned with "The future of 'guix
environment'".
All the best,
simon
gt; both. I even had to use one that executed with either 2 or 3, but gave
> different results. It takes a lot of motivation to persist.
Except that "guix environment" will raise warnings.
Whatever.
> For guix, there's the additional issue that we use the reproducibility
>
d there are
> situations where viewpoints are different. That is OK.
I am fine. :-)
Life is about managing disagreements.
And I am probably a typical grouchy French. ;-)
Well, if we go back in time, the story is:
- the original author of "guix environment" is not happy with t
Hi Simon,
> Assuming "guix environment" would stay and following the proposed
> plan, you would need to add GUIX_ENVIRONMENT_DEPRECATED=1 on the top
> of your script. In this would not be a problem for travelling back in
> time.
The problem is not how I update my scripts -
about a unified command for constructing environments and profiles
declaratively? In other words, combine "guix environment" and the
declarative parts of "guix package". We could probably get rid of
the somewhat obscure "guix environment -r" in the process.
Cheers,
Konrad.
s a bit too easy. If I can no longer pull, because
>> that breaks my Emacs or Gnome, then Guix is broken for me: I can no
>> longer update my system without first adjusting my config.
>
> So you expect that we would push a patch changing "guix environment"
> and in the
On Thu, 19 Dec 2019 at 17:31, Ludovic Courtès wrote:
> The hard question then becomes: what do we call it? I vote against
> abbreviations. :-)
"guix shell"?
Cheers,
simon
onger pull, because
> that breaks my Emacs or Gnome, then Guix is broken for me: I can no
> longer update my system without first adjusting my config.
So you expect that we would push a patch changing "guix environment"
and in the same time break "guix pull, isn't it?
Otherwise
people using Guix is not so high (yet!), so 2. I am almost
> sure we can name the people using "guix environment" in scripts ;-).
I’m not so sure. Guix is already used in scientific workflows, and there
is existing third-party documentation about using `guix environment`.
And can you
d to give users a bit of
>> time so they can start adjusting before deprecation is in effect.
>
> #4 is trickiest for another reason: there is no future-proof use of
> "guix environment" that works right now and will continue to work. Nor
> is there any way to see, when
ething else in
> >> the past and the change happened the in ".
> >
> > Concrete example: I am writing a tutorial about using Guix for
> > reproducible research. It shows several uses of "guix environment", some
> > of them without '–add-hoc'
mple: I am writing a tutorial about using Guix for
> reproducible research. It shows several uses of "guix environment", some
> of them without '–add-hoc' or '–inputs-of'. I know my examples will
> cease to work in a few months. What am I supposed to do abo
appened the in ".
>
> Concrete example: I am writing a tutorial about using Guix for
> reproducible research. It shows several uses of "guix environment", some
> of them without '–add-hoc' or '–inputs-of'. I know my examples will
> cease to work in a
producible research. It shows several uses of "guix environment", some
of them without '–add-hoc' or '–inputs-of'. I know my examples will
cease to work in a few months. What am I supposed to do about this?
> First, I am not convinced that there is not so much scripts
Forgot to add:
┌──┐
│ guile -c '(use-modules (ice-9 session))(apropos "env") │
├──┤
│ (guile): getenv #
>b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the
> > >> new behaviour.
> > > That sounds like a good plan to me.
> > >
> > > #4 is the trickiest, and I think it’d be good to give users a bit of
> > > time so they can start ad
1 - 100 of 283 matches
Mail list logo
