unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Julien Lepiller <julien@lepiller.eu>
To: Kyle Andrews <kyle@posteo.net>
Cc: help-guix@gnu.org
Subject: Re: Mysteries of channel configuration during system reconfigure
Date: Sat, 11 Mar 2023 09:08:28 +0100	[thread overview]
Message-ID: <FE7F126F-E1C9-4259-BB84-8CEC0D893257@lepiller.eu> (raw)
In-Reply-To: <87bkl0dq2i.fsf@posteo.net>



Le 11 mars 2023 01:16:21 GMT+01:00, Kyle Andrews <kyle@posteo.net> a écrit :
>
>Julien Lepiller <julien@lepiller.eu> writes:
>
>> Does your /etc/channels.scm list the extra channels?
>
>At this point it does not. I "restored" a backup from my old computer
>into my home directory. Now I have several more channels than I had
>configured in generation one. Unfortunately, now my shepherd is broken
>just like on my old computer.
>
>I wish I understood how to experiment with e.g. virtual machines to
>better understand this process. However, there seems to be quite a large
>knowledge barrier. I also don't feel comfortable with my current
>capabilities exploring the Guix codebase to see what the relevant
>procedures are. There is a lot to learn!

I'm not sure what manages /etc/channels.scm, but I don't think Guix creates it? In any case, you use that file when pulling, so at the time you pull, you should list all the channels you want to use in that file.

>
>> "guix describe" will be more accurate about what channels your current
>> guix knows about.
>
>It's not clear to me what "your current guix" even is in my case. Does the latest pull define the current guix?

It should, but what I meant by that is "whatever your shell believes it should run when you type guix"

>
>On my old computer guix system describe shows a slightly older revision
>of Guix channels than guix describe. Meanwhile, the root user's guix describe shows just the one Guix channel with yet another commit.
>
>As a naive user, I'm understandably more scared that my computer will
>fail to boot if I upgrade, so I tend to run guix system reconfigure less
>frequently than guix pull.

If it fails to boot, you should still be able to select an older, known to work, generation at the grub screen. That's the magic of Guix :)

>
>> If you type "type guix" and "which guix", they should agree it's
>> ~/.config/guix/current/bin/guix, not something else like
>> ~/.guix-profile or ~/.guix-home or even /run/current-system
>
>I had never heard of the type command! I noticed type and which give
>different results for "type cd" and "which cd". I also noticed that which --all guix shows two lines: the latter being /run/current-system.

cd is a builtin, so "type cd" should tell you that. "which" will only look for a binary in your $PATH, so it should report that it can't find it.

type itself is a builtin, and it will tell you what a binary is, according to the shell. Bash and other shells have a cache of command name to location. When you use "type guix" it should tell you where it finds guix, according to that cache. If it's different from "which guix", which only looks in $PATH, not in the shell cache, it means you should refresh that cache with "hash guix" (I think hash is also a builtin).

If which does not tell it's your pulled guix (ie. ~/.config/guix/current/bin/guix), it means your $PATH is not set properly.

A guix command could come from different locations in your system. At least one is installed with your system at /run/current-system.

>
>I have to admit I'm not still sure what general insight I should be gleaning from your statement, however it sounds like it is pretty neat.
>
>> If you reconfigure as the root user, you should pull as the root
>> user. If you use sudo, which is recommended, make sure that the above
>> works properly with sudo too.
>
>I'm curious to learn more about your rationale for this statement as I
>was successful at building a second generation only once I used the "sudo" path with my non-root user.

Your user's and root's guix are different, as you noticed. So, I was just wondering whether you were doing something like su then reconfigure, or sudo guix. When you use su, you login as root, and use root's guix. When you sudo, you run the user program with root priviledges, which is quite different in that case.

With su, you run root's guix, so you should pull as root. With sudo, you run the user's guix, so you should pull as a user (don't pull with sudo, it will mess up rights in your home directory).

Also, I don't personnaly use the recommended way as I find sudo confusing. I wanted to make sure the above is correct, so does "guix describe" give you the same as "sudo guix describe"?

>
>Thanks for your help!


  reply	other threads:[~2023-03-11  8:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09  2:50 Mysteries of channel configuration during system reconfigure Kyle Andrews
2023-03-09  6:46 ` Julien Lepiller
2023-03-11  0:16   ` Kyle Andrews
2023-03-11  8:08     ` Julien Lepiller [this message]
2023-03-09 15:12 ` Luis Felipe
2023-03-09 15:37   ` Luis Felipe
2023-03-09 15:32 ` SeerLite
2023-03-09 17:58   ` Kyle Andrews

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FE7F126F-E1C9-4259-BB84-8CEC0D893257@lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=help-guix@gnu.org \
    --cc=kyle@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).