Re: Multiple profiles with Guix Home
On 2022-05-23 19:05, Liliana Marie Prikler wrote:
> Hi,
>
> Am Montag, dem 23.05.2022 um 16:14 +0300 schrieb Andrew Tropin:
>> The discussion seems too heated and bloated, it's hard to reasonably
>> address arguments mentioned around, so I'll just post some thoughts
>> and a possible way to somehow proceed.
>>
>> I suggest to split the bigger idea into smaller pieces, play with the
>> implementation locally/in fork/branch and see how it goes:
>>
>> 1. home-profiles-paths-service-type. It will allow to add code for
>> sourcing profiles in setup-environment script and thus implement
>> workflows with multiple profiles. Such profiles can be managed
>> externally or in the future built as a part of home environment.
> How about home-profile-loader-service-type as a name instead? That
> would imply that it's purpose is to load profiles.
Looks ok for me.
>> 2. home-[additional-]profiles-service-type. It will allow to build
>> profiles from list of packages, optionally add a profile to
>> home-profiles-paths. It will make ~/.guix-
>> home/profiles/{emacs,web,etc}
>>
>> To make it possible for other service to utilize multiple profiles,
>> this service will be extandable with values like that:
>>
>> `((default . ,(list curl wget))
>> (web . ,(list browser-ad-block-plugin))
>> (emacs . ,(list emacs emacs-cider emacs-modus-themes)))
> I don't think I agree with this choice. To satisfy both my own use
> case of serving profiles in different locations from another and
> another issue being raised w.r.t. configuring the location of the
> .guix-home profile, I think we should make a triple of location,
> optional short name, and manifest (which may be generated from packages
> implicitly). WDYT?
>
This service is intended for profiles managed by Guix Home, so every
profile MUST be a part of home-environment (~/.guix-home is a symlink to
it). I don't see any meaningful reasons to make it possible to
customize the path inside home-environment.
If you want to have profiles like ~/work/my-project/guix-profile or
~/.guix/profiles/my-python-environment managed by Guix Home you can
implement home-external-profiles-service-type, which can extended
activation service or any other impure tricks, but I would advice
against it. I suggest either manage a profile with
home-[additional-]-profiles or manage them externally and load with
home-profile-paths/home-profile-loader.
>> 3. Maybe migrate ~/.guix-home/profile to ~/.guix-
>> home/profiles/default.
> Kinda agree, but with the caveat in (2). Uniformity or chaos should be
> a user choice :)
>
>> I still can see a lot of potential problems related to search paths,
>> however part of them can be solved by duplicating packages in
>> different profiles or using dummy packages like emacs-consumer:
>> https://git.sr.ht/~abcdw/rde/tree/master/item/rde/packages/emacs.scm#L56
> Or by making search paths first class in manifests, as also discussed
> elsewhere.
>
>> [...]
>> Liliana, if you still into it, I suggest to start with something
>> similiar to what I described above, share the draft implementation
>> and intermediate results/impression in a separate thread and continue
>> the further discussion.
> Considering the above, I think a rough roadmap would be:
> 1. Implementing home-profiles-service-type (to build the profiles)
> 2. Implementing home-profile-loader-service-type
This one looks simplier and also independent from #1, so I would
recommend to start with it. Also, it's very likely that
home-profiles-service-type will be extending
home-profile-loader-service-type
> 3. ???
> 4. Deprecate the existing home-profile-service-type in favor of the new
> profile service type pair and/or implement it in terms of it.
> where (1) and (2) could be done by two people/teams in parallel.
The migration should be quite simple here.
JFYI: The design of Guix Home is flexible, essential services can be
completely customized, even symlink-manager can be removed or
substituted with something else (for example to make a read-only home
workflow proposed by Julien Lepiller in guix-home-manager). This is
also used in rde to substitute home-shell-profile-service-type with
alternative implementation:
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features.scm#L234
This way you can experiment with multi-profile approach even without
modifying existing code.
>
> Given that the task has been simplified, I think I might start coding
> on it, but I can't promise any particular deadline. At the moment,
> both my day job and review work delay any other contributions towards
> Guix.
>
> Cheers
I also advice to treat it as an experiment. IMO Guix Home should be
relatively conservative, stable and simple. Other advanced workflows
in most cases should be implemented and maintained separately and be
optionally pluggable in Guix Home by overriding essential services or
any other way. In cases such workflows demonstrates their benifits
without compromising simplicity, they can be in
Re: Multiple profiles with Guix Home
Hi, Am Dienstag, dem 24.05.2022 um 14:55 +0300 schrieb Andrew Tropin: > On 2022-05-23 19:05, Liliana Marie Prikler wrote: > > [...] > > I don't think I agree with this choice. To satisfy both my own use > > case of serving profiles in different locations from another and > > another issue being raised w.r.t. configuring the location of the > > .guix-home profile, I think we should make a triple of location, > > optional short name, and manifest (which may be generated from > > packages implicitly). WDYT? > > > > This service is intended for profiles managed by Guix Home, so every > profile MUST be a part of home-environment (~/.guix-home is a symlink > to it). I don't see any meaningful reasons to make it possible to > customize the path inside home-environment. Why though? The decision to restrict Guix Home to dotfiles was already a bad one that has since been overturned, so I think we should carefully evaluate why "~/.guix-home" even is special. In my point of view, any path that is prefixed with the user's home ought to be fair game, as should be constructing intermediate per-user profile symlinks in /var/guix. > If you want to have profiles like ~/work/my-project/guix-profile or > ~/.guix/profiles/my-python-environment managed by Guix Home you can > implement home-external-profiles-service-type, which can extended > activation service or any other impure tricks, but I would advice > against it. I suggest either manage a profile with > home-[additional-]-profiles or manage them externally and load with > home-profile-paths/home-profile-loader. Pardon me if I was confusing, but I meant to have one service defining the existence of ~/work/my-project/guix-profile (that being home- profiles-service-type) and another to load it (that being home-profile- loader-service-type). Admittedly, the existing way of specifying a profile that is loaded becomes more work then, so perhaps we can add some syntactic sugar to that, so that both services get extended at once. > > Considering the above, I think a rough roadmap would be: > > 1. Implementing home-profiles-service-type (to build the profiles) > > 2. Implementing home-profile-loader-service-type > > This one looks simplier and also independent from #1, so I would > recommend to start with it. Also, it's very likely that > home-profiles-service-type will be extending > home-profile-loader-service-type I thought about it for some while, but I really don't think either is easier than the other, particularly in the way I described it, where home-profiles-service-type and home-profile-loader-service-type are orthogonal to each other. > > 3. ??? > > 4. Deprecate the existing home-profile-service-type in favor of the > > new profile service type pair and/or implement it in terms of it. > > where (1) and (2) could be done by two people/teams in parallel. > > The migration should be quite simple here. > > JFYI: The design of Guix Home is flexible, essential services can be > completely customized, even symlink-manager can be removed or > substituted with something else (for example to make a read-only home > workflow proposed by Julien Lepiller in guix-home-manager). This is > also used in rde to substitute home-shell-profile-service-type with > alternative implementation: > https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features.scm#L234 I'm not sure if I'm that fond of this design choice – it reminds me a bit about OOP horrors I was forced to learn. Anyway, I don't think it's relevant, as... > This way you can experiment with multi-profile approach even without > modifying existing code. I was planning to run guix home from checkout with $HOME in /tmp anyway for testing purposes. > > Given that the task has been simplified, I think I might start > > coding on it, but I can't promise any particular deadline. At the > > moments both my day job and review work delay any other > > contributions towards Guix. > > > > Cheers > > I also advice to treat it as an experiment. IMO Guix Home should be > relatively conservative, stable and simple. Other advanced workflows > in most cases should be implemented and maintained separately and be > optionally pluggable in Guix Home by overriding essential services or > any other way. In cases such workflows demonstrates their benifits > without compromising simplicity, they can be included. I initially planned for the new stuff to be backwards compatible by way of sanitizers. That probably still works for the design we have currently, though YMMV. Cheers
Re: Test US mirror for bordeaux.guix.gnu.org and slow downloading of substitutes
Hi Christopher, So its strange, I do: wget https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 --2022-05-25 05:32:12-- https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 185.233.100.56, 2a0c:e300::58 Connecting to bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)|185.233.100.56|:443... connected. ...and then it just remains stalled there. wget appears to work fine in generat though, just not with guix. Any idea why this might be happening? Could bordeaux be blocking IPs in Singapore? Best, Blake --- Blake Shaw Director, SWEATSHOPPE sweatshoppe.org --- On Tue, May 24, 2022 at 5:52 AM Blake Shaw wrote: > > Hi Christopher, > > Here in Singapore download speed has gone from bad to worse over the > last two weeks, so bad that I was having to --fallback often and wound > up setting up a cuirass instance to continuously build a collection of > manifests I'm working with (which solved the issue). Not at my machine > atm but will wget stellarium and send the results when I am. > > Best, > Blake > > --- > Blake Shaw > Director, SWEATSHOPPE > sweatshoppe.org > --- > > On Fri, May 20, 2022 at 11:09 PM Christopher Baines wrote: > > > > Hey! > > > > So the nar-herder came in to existence at the end of last year (2021) > > and while the main use at the time was addressing the lack of storage on > > bayfront, I also hoped to improve the situation regarding mirrors for > > substitutes. > > > > I'm not in a great situation to test this though, as my usual internet > > connection is slow enough that a closer mirror probably won't make much > > difference. > > > > So, one thing that I'd be interested in, is hearing from anyone who > > thinks they get worse download performance from bordeaux.guix.gnu.org or > > ci.guix.gnu.org than they get when downloading other > > things. Importantly, it would be good to know roughly where > > (geographically) the machine doing the downloading is, and some data to > > show the difference. > > > > For example, I'm in the United Kingdom in Europe, and this is the output > > from wget downloading a ~200M file from bordeaux.guix.gnu.org: > > > > → wget > > https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 > > --2022-05-20 16:49:56-- > > https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 > > Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 2a0c:e300::58, > > 185.233.100.56 > > Connecting to bordeaux.guix.gnu.org > > (bordeaux.guix.gnu.org)|2a0c:e300::58|:443... connected. > > HTTP request sent, awaiting response... 200 OK > > Length: 208615205 (199M) [text/plain] > > Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.6’ > > > > 078vr3r8mn3yrwzwxw64 100%[==>] 198.95M 4.24MB/s > > in 46s > > > > 2022-05-20 16:50:43 (4.31 MB/s) - > > ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.6’ saved > > [208615205/208615205] > > > > > > Also, I've setup a US based (Hetzner data center, east coast) mirror of > > bordeaux.guix.gnu.org: > > > > https://bordeaux-us-east-mirror.cbaines.net/ > > > > So, I'd also be interested in seeing how that performs for people, and > > how it compares against bordeaux.guix.gnu.org, which is hosted in France > > in Europe. > > > > Here's my output from wget: > > > > → wget > > https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 > > --2022-05-20 16:50:44-- > > https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 > > Resolving bordeaux-us-east-mirror.cbaines.net > > (bordeaux-us-east-mirror.cbaines.net)... 5.161.49.48 > > Connecting to bordeaux-us-east-mirror.cbaines.net > > (bordeaux-us-east-mirror.cbaines.net)|5.161.49.48|:443... connected. > > HTTP request sent, awaiting response... 200 OK > > Length: 208615205 (199M) [text/plain] > > Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.7’ > > > > 078vr3r8mn3yrwzwxw64 100%[==>] 198.95M 4.17MB/s > > in 47s > > > > 2022-05-20 16:51:32 (4.22 MB/s) - > > ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.7’ saved > > [208615205/208615205] > > > > > > Now, performance is probably a bit more complicated than just download > > speed. The US mirror holds the narinfo information locally, which should > > enable it to respond to requests more quickly, reducing latency, but > > this is a little harder to test. > > > > Thanks, > > > > Chris
Re: Test US mirror for bordeaux.guix.gnu.org and slow downloading of substitutes
Hi Blake, Blake Shaw 写道： Any idea why this might be happening? Could bordeaux be blocking IPs in Singapore? This is *completely* unrelated. bordeaux (bayfront) is currently running out of RAM and has been doing so, quite heroically, for more than an hour now. Because of that it's currently refusing connections[0]. Now is not the time to test bordeaux. Sorry. Kind regards, T G-R [0]: Including SSH, so no easy fix… signature.asc Description: PGP signature
Arun Isaac Presentation on guix-forge this Saturday
hi guixers! I'd like to invite you this Saturday to a presentation on guix-forge by Arun Isaac: https://guix-forge.systemreboot.net/ guix-forge empowers users to bring their own forge (BYOF). It's a much needed project with an design focus on statelessness and minimalism. Arun will be presenting on guix-forge this Saturday at 16:00 UTC. Here's the room invite link: https://meet.nixnet.services/b/jga-nze-hgu-1qg hope to see ya there, jgart https://whereis.みんな/ https://litterbox.whereis.みんな/
Re: Why does sh in the build environment ignore SIGINT and SIGQUIT?
Hi, --- Original Message --- On Monday, May 23rd, 2022 at 11:25 PM, Foo Chuan Wei wrote: > On 2022-05-23 03:14 +, Foo Chuan Wei wrote: > > > `(invoke "sh" "-c" "trap")` is merely a trivial example for > > demonstrating that the shell ignores SIGINT and SIGQUIT. This might be > > significant if the build step invokes the shell to do something more > > significant (e.g. to build something). > > > > Anyway, I found that this behavior is possibly related to one specified > > by POSIX [1]: > > > > > 2.11. Signals and Error Handling > > > > > > If job control is disabled (see the description of set -m) when the > > > shell executes an asynchronous list, the commands in the list shall > > > inherit from the shell a signal action of ignored (SIG_IGN) for the > > > SIGINT and SIGQUIT signals. > > > Maybe not. Guix's `invoke` procedure uses Guile's `system*` procedure, > which ignores SIGINT and SIGQUIT as can be seen in Guile's source code: > https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/posix.c?h=v3.0.8#n1524 > > > Do you have a solution to this problem? > > > Guile's `system` procedure does not have this problem (compare > `(system "bash -c trap")` with `(system* "bash" "-c" "trap")`). > One possible solution is to replace `invoke` with `system`: While `system` may not show the problem that `system*`, note that they aren't strictly interchangeable. To quote https://www.gnu.org/software/guile/manual/html_node/Processes.html#index-system_002a: "system* is similar to system, but accepts only one string per-argument, and performs no shell interpretation. The command is executed using fork and execlp. Accordingly this function may be safer than system in situations where shell interpretation is not required." Cheers, Kaelyn > > diff --git a/gnu/packages/sml.scm b/gnu/packages/sml.scm > index 04411c02c3..fafdba9a3f 100644 > --- a/gnu/packages/sml.scm > +++ b/gnu/packages/sml.scm > @@ -175,10 +175,14 @@ function interface, and a symbolic debugger.") > "sml.boot.amd64-unix/SMLNJ-BASIS/.cm/amd64-unix/basis-common.cm")) > > ;; Build. > - (invoke "./config/install.sh" "-default" > - (if (string=? "i686-linux" ,(%current-system)) > - "32" > - "64")) > + (let ((exit-code > + (system (string-append "./config/install.sh -default " > + (if (string=? "i686-linux" > + ,(%current-system)) > + "32" > + "64") > + (unless (zero? exit-code) > + (error (format #f "Exit code: ~a" exit-code > > ;; Undo the binary patch. > (for-each
Re: Test US mirror for bordeaux.guix.gnu.org and slow downloading of substitutes
Hi Guix, On Tue, May 24, 2022 at 3:40 PM Blake Shaw wrote: > > wget > https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 > > Could bordeaux be blocking IPs in Singapore? That command also stalls in Fremont, Calif., in the continental US (run on Guix). Kind regards Felix Lechner * * * $ wget https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 --2022-05-24 15:41:57-- https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 2a0c:e300::58, 185.233.100.56 Connecting to bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)|2a0c:e300::58|:443... connected. $ wget -4 https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 --2022-05-24 15:44:32-- https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 185.233.100.56 Connecting to bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)|185.233.100.56|:443... connected.
Re: Arun Isaac Presentation on guix-forge this Saturday
jgart 写道： I'd like to invite you this Saturday to a presentation on guix-forge by Arun Isaac: Magical: I can probably make it this time. Kind regards, T G-R signature.asc Description: PGP signature
Re: Arun Isaac Presentation on guix-forge this Saturday
On Wed, 25 May 2022 01:45:07 +0200 Tobias Geerinckx-Rice wrote: > jgart 写道： > > I'd like to invite you this Saturday to a presentation on > > guix-forge by Arun Isaac: > > Magical: I can probably make it this time. > > Kind regards, > > T G-R Glad to hear you'll make it. till Sat, jgart
A corner case of broken reproducibility
Hiya Guix, I imagine many folks are aware of this outcome, but from a quick search of the archive I didnt find a discussion. I decided to create a new user for building the lighter profile to deploy in Singapore. Not knowing beyond the surface of how user profiles operate at the Linux level, I changed my user name in my config without adding a new user, thinking that only building a system with one profile will be faster (with the servers having problems I'm having to fallback quite a bit, so every bit of time saved helps) But when I run $guix system roll-back, the account is broken. If I set the password again as root and then try to log back in, it crashes during loggin and in returned to the login menu. If I try to login with $sudo su blake2b, I get the error: Permission denied: /home/blake2b/.bashrc. if I remove bashrc and then try to continue, the error happens again. And its the same if I reconfigure with the new user. So it seems this is a corner case of somewhat severe non-reproducibity (you can't even access the environment). I'm guessing it has something to do with setuid, perhaps the access rights are given to a strictly different user even if the name is the same. Is there any fix to this? Ez, Blake
Re: Arun Isaac Presentation on guix-forge this Saturday
Guix-forge aims to replace github and gitlab. I don't know how much Arun will show, but I would like to note that under their guidance we have replaced the github issue trackers, kanban boards, and CI for the genenetwork project. https://ci.genenetwork.org/ https://issues.genenetwork.org/ In all it is *much* nicer to work with. We still have github as a backend for most git repos, but the main thing is that we are not delivered to github functionality and may move off to gitea or cgit any time: https://git.genenetwork.org/ Important stuff! Pj. On Tue, May 24, 2022 at 06:26:56PM -0500, jgart wrote: > hi guixers! > > I'd like to invite you this Saturday to a presentation on guix-forge by Arun > Isaac: > > https://guix-forge.systemreboot.net/ > > guix-forge empowers users to bring their own forge (BYOF). It's a much > needed project with an design focus on statelessness and minimalism. > > Arun will be presenting on guix-forge this Saturday at 16:00 UTC. > > Here's the room invite link: > > https://meet.nixnet.services/b/jga-nze-hgu-1qg > > hope to see ya there, > > jgart > > https://whereis.みんな/ > https://litterbox.whereis.みんな/ > >
