Re: guix running advice: correct?
Ah, the guix pull profile comming first is not absolute. It's simply that some users might have installed guix in their default profile, and if that profile comes before guix pull, that huix will be used. Any guix upgrade will then doongrade your profile. This shouldn't be ppssible anymore, since guix should do the right thing now when setting the shell profile files, and it would warn if you attempted a dpongrade. Le 5 février 2023 00:16:37 GMT+01:00, Kyle Andrews a écrit : > >Julien Lepiller writes: > >> Hi Andy, >> >> I'm the author of this advice. I think it's still correct. It's mostly >> sanity checks that you would run to ensure you can get packages from >> this channel. Most of it is scattered around the manual, mostly in the >> manual installation documentation. >> >> ~/.config/guix/current is where your new guix (the one you pulled with >> the channel) is installed. If it's not first in $PATH, you're at risk >> that some other guix will be used instead. >> >> hash is a command that removes an entry from the shell's cache. If >> this is your first pull, the guix you used comes from another location >> that is recorded by the shell, so you have to clear the cache to use >> the newly pulled guix. If your guix already comes from the correct >> location, it'll be useless but it won't hurt. >> >> HTH! >> >> Le 3 janvier 2023 06:31:25 GMT+01:00, Andy Tai a écrit : >>>Hi, from this page >>>https://framagit.org/tyreunom/guix-android/-/blob/master/README.md >>> >>>Important checks >>>Make sure your guix environment is set up properly. You need to have >>>~/.config/guix/current as the first item in your $PATH or you're going >>>to run into troubles. Additionally, after running guix pull, make sure you >>>run hash guix in any open terminal to make sure bash's cache is cleared of >>>the old guix binary location. >>> >>>I wonder if the above is correct, as I do not recall seeing anything in >>>Guix doc mentioning such advice or something to that effect (unless I >>>missed it) > >Interesting. I too had never heard about this PATH recommendation and it >seems contrary to some advice I do remember given in the cookbook about >working with multiple profiles. For me, activating an extra profile >places it's /bin and /sbin directories at the beginning of my PATH. I can >only find ~/.config/guix/current/bin burried quite deep near the end. > >Do you have any advice on how regular end users could follow your >recommendation? > >My naive hope would be that end users wouldn't have to think about >it. Ideally if its that dangerous then updating the path would happen >automatically when sourcing the etc/profile file inside a profile >directory. > >Should the Guix Profiles in Practice section of the cookbook be updated >to reflect this? > > > >
Re: attempt to create a profile
Simon Tournier writes: > Hi, > > On Wed, 28 Dec 2022 at 15:09, Gottfried wrote: > >> Which commands can I use to enter and close my new profile? > > To enter, you just need to ’source path/to/some-profile/etc/profile’. > > However, you cannot “deactivacte“; unset the environment variables and > restore the previous ones. Maybe, the easiest is: > >bash >source path/to/some-profile/etc/profile >…do some stuff… >exit > > Instead, you can run > > guix shell -p path/to/some-profile/etc/profile > …do some stuff… > exit > > which does the same thing as above. > > >> ...and also at start up that I can choose which profile to open? > > What do you mean by “choose”? > > >> guix package --profile=/home/gfp/projects/musescore-3.6.2.guix-profile >> >> and beforehand I created the directory "projects" and >> "Musescore-3.6.2" in the directory "projects" >> in my /home/gfp/ directory >> (I did that because it said: " >> file or directory was not found" >> >> but it didn't work. >> "warning: nothing to do" was the answer. >> >> Where was my mistake? > > It is missing the option -i (or -m). For instance, > > guix package -i musescore -p projects/musescore-3.6.2.guix-profile > > > Cheers, > simon Thank you Gottfried for asking this question and thank you Simon for providing these examples. I didn't realize I could use guix shell with an already installed and named profile. This suggests a follow-up question: Is it possible to use guix shell to activate multiple existing profiles in a particular order to explicitly test for incompatibilities when combining profiles? I have been using multiple existing profiles mainly in the hope it would spare my poor underpowered and aging laptop the burden of having to do a long system update ordeal all at once. This seemed to me especially useful when there would be conflicts which would require uninstalling something and then redoing a lot of work. However, it has not worked out as well as I could have hoped. For one thing, I have found Emacs to be quite confused as to whether some documentation or command completions are available or not. For another thing, I found that if there was an explicitly recognized problem, it would usually be related to an issue with package definitions on my personal channel or in the main Guix channel and I would then have to run guix pull. After do that operation, I believed I would have to update everything again anyway. I had just read a discussion on this forum where it was mentioned that mixing guix executables from different guix generations would be asking for trouble and that the only way to make sure things would work correctly was to keep ~/.config/guix/current/bin~ at the front of our PATH. Maybe this is an example where this issue is relevant? I have had many issues which I have reported but these have all turned out to be unreproducible in a single dedicated profile. In conclusion, I'm a bit surprised that activating multiple profiles at once is so easily found and recommended in the cookbook. It seems to me like there are many underemphasized gotchas with respect to reproducibility and usability which come from it and as far as I can tell, the main developers of Guix do not use it that way. If it is going to be recommended as atleast a possibility for advanced users, then it would be nice to be able to formally test that usage through ~guix shell~.
Re: guix running advice: correct?
Julien Lepiller writes: > Hi Andy, > > I'm the author of this advice. I think it's still correct. It's mostly > sanity checks that you would run to ensure you can get packages from > this channel. Most of it is scattered around the manual, mostly in the > manual installation documentation. > > ~/.config/guix/current is where your new guix (the one you pulled with > the channel) is installed. If it's not first in $PATH, you're at risk > that some other guix will be used instead. > > hash is a command that removes an entry from the shell's cache. If > this is your first pull, the guix you used comes from another location > that is recorded by the shell, so you have to clear the cache to use > the newly pulled guix. If your guix already comes from the correct > location, it'll be useless but it won't hurt. > > HTH! > > Le 3 janvier 2023 06:31:25 GMT+01:00, Andy Tai a écrit : >>Hi, from this page >>https://framagit.org/tyreunom/guix-android/-/blob/master/README.md >> >>Important checks >>Make sure your guix environment is set up properly. You need to have >>~/.config/guix/current as the first item in your $PATH or you're going >>to run into troubles. Additionally, after running guix pull, make sure you >>run hash guix in any open terminal to make sure bash's cache is cleared of >>the old guix binary location. >> >>I wonder if the above is correct, as I do not recall seeing anything in >>Guix doc mentioning such advice or something to that effect (unless I >>missed it) Interesting. I too had never heard about this PATH recommendation and it seems contrary to some advice I do remember given in the cookbook about working with multiple profiles. For me, activating an extra profile places it's /bin and /sbin directories at the beginning of my PATH. I can only find ~/.config/guix/current/bin burried quite deep near the end. Do you have any advice on how regular end users could follow your recommendation? My naive hope would be that end users wouldn't have to think about it. Ideally if its that dangerous then updating the path would happen automatically when sourcing the etc/profile file inside a profile directory. Should the Guix Profiles in Practice section of the cookbook be updated to reflect this?
Re: setting up a new printer
Hi Tobias,
thanks very much.
I must have been blind that evening.
I changed the _ and - already, but it didn’ work either.
Now I checked everything again and changed again the name.
Now I can print in emacs.
I am happy.
Thanks again for your help.
Kind regards
Gottfried
Am 03.02.23 um 18:47 schrieb Tobias Geerinckx-Rice:
But note the different name (not URL): '-' vs. the '_' expected by emacs/lpr.
I don't know why I expected that. Call it intuition.
I've never actually printed from emacs and can't help you there, but I would
reconfigure emacs to use the same ('-') name if possible.
Kind regards,
T G-R
Sent on the go. Excuse or enjoy my brevity.
--
OpenPGP_0x61FAF349C9FB7F94.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
