Re: [PATCH] doc: Clarify need to update search paths on foreign distro (was Re: Feedback of the GNU Guix manual)

[Matt]

 On Sat, 11 May 2024 10:14:15 +0200  pelzflorian (Florian Pelz)  wrote ---
> Instead, there already is advice for .config/guix/current documented in
> the Guix manual’s Getting Started section.  The advice should be a
> cross-reference that users should follow the steps from Getting Started,
> so search paths are set up properly instead of advising to set PATH and
> INFOPATH.
>
> The advice of setting PATH really should go away.

Sorry for the late and lengthy reply.  Life is life and when I returned to the 
issue I noticed that the problem is really that the concept of profiles could 
use some revision within the manual.  That will make for a rather complex 
change set.  I hoped to have one ready yet, again, life is life.  So, here are 
my thoughts and, after hearing yours, I can put together  the necessary changes 
if my points hold.

I see two fundamental issues:

1. should there be a single point of reference for the concept of "profile" and 
where should it be?

2. what information about profiles is relevant to addressing the reported issue 
and where is it?

We'll need to discuss possible solutions because, unfortunately, the concept of 
"profiles" isn't conveniently documented.

ISSUE 1 - should there be a single point of reference for the concept of 
"profile" and where should it be?

tl;dr create a new subsection for the profile concept

I find your suggestion reasonable; document concepts in a single place and then 
favor references to that place.  Unfortunately, there is currently no single 
place of reference for the concept of "profile".

Important facts about profiles are spread across the following sections (a list 
is given at the end of this section):

- Section 4: Getting Started (1)
- Section 5.1: Features (and isn't indexed there) (1)
- Section 5.2: Invoking 'guix package' (13)
- Section 5.7: Invoking 'guix pull' (3)
- Section 8.8: Search Paths (1)
- Section 9.1: Invoking 'guix build' (1)
- Section 11.3: operating-system Reference (2), and
- Section 11.19.3: Service Reference (1)

Should we make Section 4: Getting Started the common reference point?

I say no.  The Getting Started section is intended to help readers get started 
with Guix and get a feel of what it's like.  Therefore, it should contain a 
simple how-to with minimal explanation.  As the GNU Press Styleguide[1] advises,

"Move slowly. Do not impose too much of a cognitive load at once on the reader."

I think the Getting Started section has too much profile information in it as 
is.  For example, GUIX_PYTHONPATH is a convention, hard-coded into package 
definitions whereas GUIX_PROFILE is a literary shorthand for the concept that 
multiple profiles may exist and that the profile is the $HOME/.guix-profile in 
this case.

Of all the sections that discuss profiles, Invoking 'guix package' contains the 
most information (13 facts).  It's also given as the point of reference by 5 
other sections:

1. Invoking 'guix pull' (twice)
2. Invoking 'guix shell'
3. Invoking 'guix environment'
4. Invoking 'guix build'
5. operating-system Reference

Should we make Invoking 'guix package' be the common reference point for 
profiles?

Again, I say no. AFAIU, profiles have two forms: a system profile, sometimes 
called the global profile, which manages Guix itself and user profiles, 
including "default" or "current", which dictate package accessibility.  While 
system and user profiles "work exactly" like each other (see Invoking guix 
pull), there are separate commands for each: 'guix package' is for user 
profiles and 'guix pull' is for the system profile.  It's easy to confuse all 
this.  Therefore, it would be better to have a separate section that explains 
profiles and let Invoking 'guix package' and Invoking 'guix pull' focus on the 
command options.

The best common reference point for profiles is in a new section just below 
Section 5.1: Features. As the Styleguide[1] says,

"Put important notes to the reader in subsections of their own. This tells the 
reader the notes really are important."

Profiles are first introduced in Section 4: Getting Started.  It does a good 
job introducing the idea and could actually provide less information.  The 
concept, however, is first explained in Section 5.1: Features.  The majority of 
Features is about how profiles are useful and a core concept of Guix.  I think 
we could switch the focus of Features to be about the benefits of the store, 
the symlink forest, transactions, control of the build environment, and 
provenance tracking and move the explanation and details of profiles to a new 
subsection.

Information about profiles grouped by section:

- Getting Started
  + A profile is a directory containing installed packages
- Features (not indexed)
  + A profile is a reference to the store kept in each user's home
directory managed by 'guix package'
- Invoking 'guix package'
  + a profile is a directory of installed packages
  + profiles exist per user
  + there exists a "default" 

Re: [PATCH] doc: Clarify need to update search paths on foreign distro (was Re: Feedback of the GNU Guix manual)

[pelzflorian (Florian Pelz)]

Hello Matt, Vagrant and all.  As I understand, we should not advice all
users to add these exports to .bashrc, because users with
guix-install.sh’s sys_create_init_profile or Debian’s
/etc/profile.d/guix.sh do not need it.

Instead, there already is advice for .config/guix/current documented in
the Guix manual’s Getting Started section.  The advice should be a
cross-reference that users should follow the steps from Getting Started,
so search paths are set up properly instead of advising to set PATH and
INFOPATH.

The advice of setting PATH really should go away.

Regards,
Florian

Re: [PATCH] doc: Clarify need to update search paths on foreign distro (was Re: Feedback of the GNU Guix manual)

[Matt]

  On Tue, 07 May 2024 22:41:33 +0200  Vagrant Cascadian  wrote --- 
  On 2024-05-07, m...@excalamus.com wrote:
   #+begin_quote
   6.7 L37 true for Guix System as well?
   The result of running ‘guix pull’ is a “profile” available 
under
   ‘~/.config/guix/current’ containing the latest Guix. Thus, 
make sure to
   add it to the beginning of your search path so that you use 
the latest
   version, and similarly for the Info manual (*note 
Documentation::):
  
   export PATH="$HOME/.config/guix/current/bin:$PATH"
   export 
INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
   #+end_quote
  
   As far as I know, exporting like this is only necessary on 
foreign distros.
  
   The attached patch makes this explicit.  It also provides 
information
   for people unfamiliar with the concept of a "search path" or 
how
   shells work by suggesting the exports be added to .bashrc and 
tries to
   clarify the consequences of not doing this.
  
  If the foreign distro has /etc/profile.d/*guix.sh installed, as
  implemented in the binary guix-install.sh script and also 
implemented in
  the Debian packaging, manually adding this is also arguably not
  necessary, unless they are using a shell that does not respect
  /etc/profile.d ... which, to my knowledge, is no different from Guix
  System really.
  
  There is also the issue of logging out and back in again (or 
manually
  adding the variables for one session), but that seems a little
  tangential, and again, is no different for Guix System than on 
foreign
  distros.

Should we remove the advice to update search paths and instead explain 
(IIUC) how guix.sh is added to /etc/profile.d?  Basically, does the reader need 
to take some action or is there some information about the system that would be 
relevant for  the reader regarding its use or maintenance?

Re: [PATCH] doc: Clarify need to update search paths on foreign distro (was Re: Feedback of the GNU Guix manual)

[Vagrant Cascadian]

On 2024-05-07, m...@excalamus.com wrote:
> #+begin_quote
> 6.7 L37 true for Guix System as well?
> The result of running ‘guix pull’ is a “profile” available under
> ‘~/.config/guix/current’ containing the latest Guix. Thus, make sure to
> add it to the beginning of your search path so that you use the latest
> version, and similarly for the Info manual (*note Documentation::):
>
> export PATH="$HOME/.config/guix/current/bin:$PATH"
> export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
> #+end_quote
>
> As far as I know, exporting like this is only necessary on foreign distros.
>
> The attached patch makes this explicit.  It also provides information
> for people unfamiliar with the concept of a "search path" or how
> shells work by suggesting the exports be added to .bashrc and tries to
> clarify the consequences of not doing this.

If the foreign distro has /etc/profile.d/*guix.sh installed, as
implemented in the binary guix-install.sh script and also implemented in
the Debian packaging, manually adding this is also arguably not
necessary, unless they are using a shell that does not respect
/etc/profile.d ... which, to my knowledge, is no different from Guix
System really.

There is also the issue of logging out and back in again (or manually
adding the variables for one session), but that seems a little
tangential, and again, is no different for Guix System than on foreign
distros.

live well,
  vagrant


signature.asc
Description: PGP signature

[PATCH] doc: Clarify need to update search paths on foreign distro (was Re: Feedback of the GNU Guix manual)

[Matt]

We're working through a list of feedback one item at a time:
https://lists.gnu.org/archive/html/guix-devel/2024-01/msg00117.html

We have completed the first five items.  The sixth item was fixed already in
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=cb3f833aaa5326e653b128bfd7b13d553f7c2a47

The next item reported is:

#+begin_quote
6.7 L37 true for Guix System as well?
The result of running ‘guix pull’ is a “profile” available under
‘~/.config/guix/current’ containing the latest Guix. Thus, make sure to
add it to the beginning of your search path so that you use the latest
version, and similarly for the Info manual (*note Documentation::):

export PATH="$HOME/.config/guix/current/bin:$PATH"
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
#+end_quote

As far as I know, exporting like this is only necessary on foreign distros.

The attached patch makes this explicit.  It also provides information for 
people unfamiliar with the concept of a "search path" or how shells work by 
suggesting the exports be added to .bashrc and tries to clarify the 
consequences of not doing this.

Unnecessary words were struck to reduce the overall word count.  According to 
M-x count-words-region, the patch adds only 6 words (which is less than the 7 
needed for "users of Guix on a foreign distro", itself hard to reduce).

0001-doc-Clarify-need-to-update-search-paths-on-foreign-d.patch
Description: Binary data

Re: foreign-distro?

[Development of GNU Guix and the GNU System distribution.]

Hi all,

Sorry to tell this - I don't think something like this would be even
possible to implement :/

AFAIK package definition fields like `(inputs)` don't just describe how
the package gets installed. They affect the actual build. So if we
really wanted this feature, we'd need to build 2 separate variants of a
package - one for Guix system and one for foreign distros.

In addition to looking like an overkill, such separate build variants
could also require changes to existing utilities like `guix copy`.

Besides all this, It it not that easy to determine whether Guix is
running under a foreign distro. One idea would be to check whether the
currently-running init system is Shepherd. But what if the user is
running Guix commands inside a Guix system chroot? The Shepherd process
is not going to be visible in such case

Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

Meet Kraków saints!   #18: blessed Józef Kowalski
Poznaj świętych krakowskich!  #18: błogosławiony Józef Kowalski
https://pl.wikipedia.org/wiki/Józef_Kowalski_(duchowny)
-- (sig_end)


On Wed, 23 Nov 2022 18:36:49 +0800
Zhu Zihao  wrote:

> If you want to left the choice to user. You can just don't patch it. Or
> you can always patch it because user can still use package transformer
> to specify a custom ffmpeg.
> 
> 
> jgart  writes:
> 
> > Does Guix have a declarative Guix API way of knowing if it is installing
> > a package into foreign distro versus Guix System?
> >
> > I'm thinking of a function like `foreign-distro?`:
> >
> > ```
> > (define-public peek
> >   (package
> >(name "peek")
> >...
> > (inputs 
> >   `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
> > ```
> >
> > The above includes ffmpeg in the inputs only if installing peek on a
> > foreign distro. It could additionally patch the ffmpeg executable in
> > a peek package phases if foreign-distro? returns #t.
> >
> > WDYT  
> 
> 




pgp1TxjUpspMU.pgp
Description: OpenPGP digital signature

Re: foreign-distro?

[Zhu Zihao]

If you want to left the choice to user. You can just don't patch it. Or
you can always patch it because user can still use package transformer
to specify a custom ffmpeg.


jgart  writes:

> Does Guix have a declarative Guix API way of knowing if it is installing
> a package into foreign distro versus Guix System?
>
> I'm thinking of a function like `foreign-distro?`:
>
> ```
> (define-public peek
>   (package
>(name "peek")
>...
> (inputs 
>   `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
> ```
>
> The above includes ffmpeg in the inputs only if installing peek on a
> foreign distro. It could additionally patch the ffmpeg executable in
> a peek package phases if foreign-distro? returns #t.
>
> WDYT


-- 
Retrieve my PGP public key:

  gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC

Zihao


signature.asc
Description: PGP signature

Re: foreign-distro?

[Jake Shilling]

I've experimented with the distinction in my config, because I wanted to
be able to add home-services conditionally (e.g. I wanted my GuixSD to
install a destop envrionment, but my work laptop to only setup emacs and
its dependencies).

My approache was to just parse the `/etc/os-release` file if it exists:
```
(define (os-release)
  (guard (_
  (else #f))
(call-with-input-file "/etc/os-release"
  (lambda (port)
(let loop ((line (read-line port))
   (result '()))
  (if (eof-object? line)
  (reverse result)
  (begin
(let* ((split (string-split line #\=))
   (key (string->symbol (car split)))
   (val (if (string-match "\".*\"" (cadr split))
(substring (cadr split) 1 (- (string-length 
(cadr split)) 1))
(string->symbol (cadr split
   (d (cons key val)))
  (loop (read-line port)
(cons d result))
```

Then I define a couple wrappers:

```
(define (linux-distro-id)
  (if (linux?)
  (assq-ref (os-release) 'ID)
  #f))

(define (guix-system?)
  (eq? (linux-distro-id) 'guix))
```

The config was never really fleshed out because I ended up just using my
GuixSD computer for work instead.

On 2022-11-20 23:08, Julien Lepiller wrote:

> Le Sun, 20 Nov 2022 14:54:40 -0600,
> jgart  a écrit :
>
>> Does Guix have a declarative Guix API way of knowing if it is
>> installing a package into foreign distro versus Guix System?
>> 
>> I'm thinking of a function like `foreign-distro?`:
>> 
>> ```
>> (define-public peek
>>   (package
>>(name "peek")
>>...
>> (inputs 
>>   `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
>> ```
>> 
>> The above includes ffmpeg in the inputs only if installing peek on a
>> foreign distro. It could additionally patch the ffmpeg executable in
>> a peek package phases if foreign-distro? returns #t.
>> 
>> WDYT
>> 
>
>
> Guix doesn't have a notion of foreign distro, it's all in your head,
> and there's no difference between Guix System and other distros in the
> Guix package manager's point of view :)
>
> To be more specific, Guix only knows what you current system is (that's
> captured by %current-system). It's probably x86_64-linux right know. As
> you can see, there's no place in there to tell it whether you're on a
> foreign distro or not.
>
> Lastly, I don't think I would want to differentiate the two cases,
> especially since it would mean that somehow Guix packages depend on
> something external. There's this idea that Guix packages should somehow
> be self-sufficient.
>

-- 
Best regards,
Jake Shilling


signature.asc
Description: PGP signature

Re: foreign-distro?

[Julien Lepiller]

Le Sun, 20 Nov 2022 14:54:40 -0600,
jgart  a écrit :

> Does Guix have a declarative Guix API way of knowing if it is
> installing a package into foreign distro versus Guix System?
> 
> I'm thinking of a function like `foreign-distro?`:
> 
> ```
> (define-public peek
>   (package
>(name "peek")
>...
> (inputs 
>   `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
> ```
> 
> The above includes ffmpeg in the inputs only if installing peek on a
> foreign distro. It could additionally patch the ffmpeg executable in
> a peek package phases if foreign-distro? returns #t.
> 
> WDYT
> 


Guix doesn't have a notion of foreign distro, it's all in your head,
and there's no difference between Guix System and other distros in the
Guix package manager's point of view :)

To be more specific, Guix only knows what you current system is (that's
captured by %current-system). It's probably x86_64-linux right know. As
you can see, there's no place in there to tell it whether you're on a
foreign distro or not.

Lastly, I don't think I would want to differentiate the two cases,
especially since it would mean that somehow Guix packages depend on
something external. There's this idea that Guix packages should somehow
be self-sufficient.

foreign-distro?

[jgart]

Does Guix have a declarative Guix API way of knowing if it is installing
a package into foreign distro versus Guix System?

I'm thinking of a function like `foreign-distro?`:

```
(define-public peek
  (package
   (name "peek")
   ...
(inputs 
  `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
```

The above includes ffmpeg in the inputs only if installing peek on a
foreign distro. It could additionally patch the ffmpeg executable in
a peek package phases if foreign-distro? returns #t.

WDYT

Re: nix installed with guix on a foreign distro

[jgart]

On Sat, 10 Sep 2022 02:45:46 +0200 Maxime Devos  wrote:
> would the effort be worth it?

This was more of a "I was just curious if I could get it to run" but yes
I agree on the effort not being worth it.

I'd rather spend my time working on something else.

Re: nix installed with guix on a foreign distro

[Maxime Devos]

On 10-09-2022 04:02, jgart wrote:

On Sat, 10 Sep 2022 02:45:46 +0200 Maxime Devos  wrote:

Worse, this is not just a service, but a distro.

I mean that I want to run nix, the package manager, not the distro.

Nix suffers from the holy trinity #~problem unlike Guix.

#$https://invidious.slipfox.xyz/watch?v=qjq2wVEpSsA


Nix comes with lots of packages, making it a distro.
Similarly to how you can install guix (distro) on top of a 'foreign 
distro' (e.g. Debian).


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: nix installed with guix on a foreign distro

[zimoun]

Hi,

On Tue, 26 Jul 2022 at 01:00, jgart  wrote:

> How can we make it easier to install nix with guix on a foreign distro?

Well, I think you need to manage some stuff by yourself.

For example, write the nix-daemon service for starting/stopping; it
depends on your distribution and it is probably some Systemd files.
Give a look at etc/guix-daemon.service for inspiration.

You also probably need to set the Nix store.

Maybe it is possible to share the daemon and/or the store with your
Guix; but I do not know if it would just work out of the box.


Cheers,
simon

Re: nix installed with guix on a foreign distro

[jgart]

On Sat, 10 Sep 2022 02:45:46 +0200 Maxime Devos  wrote:
> Worse, this is not just a service, but a distro.  

I mean that I want to run nix, the package manager, not the distro.

Nix suffers from the holy trinity #~problem unlike Guix.

#$ https://invidious.slipfox.xyz/watch?v=qjq2wVEpSsA

Re: nix installed with guix on a foreign distro

[Maxime Devos]

On 27-07-2022 00:50, jgart wrote:

What do you think Debian people should be providing to make it easier to run 
the guix installed nix package?

Or, what should I ask the Debian people if I decide to inquire with them?

all best,


Right, you want to install "nix" (a distro) with "guix" (a distro) on 
$FOREIGN_DISTRO (a distro) (let's assume Debian).


My answer is: why not install nix on $FOREIGN_DISTRO directly?  There 
appears to be a nice Debian package already
 (at least, I assume it is 
nice, I've never used nix).


I mean, this is service stuff, not just an application.  In theory I 
suppose that, with lots of work, Guix could support some kind of 
'foreign services', but I think you'll be better off (less effort, 
better integration) with installing the service directly, with 
$FOREIGN_DISTRO when available.


Worse, this is not just a service, but a distro.  You would be putting a 
distro inside a distro inside a distro ... that's too much nesting, at 
least for me.  Sounds interesting to observe from a distance though ...


Now I notice I haven't actually answered your question ... Let's say, 
they shouldn't be providing to make that use case easier -- if they 
really want to, then they can decide to do so, but see the stuff above, 
would the effort be worth it?


Greetings,
Maxime


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: nix installed with guix on a foreign distro

[Julien Lepiller]

It's a common limitation of packages that provide a server. Guix doesn't manage 
daemons on foreign distros, it's the role of your distro.

You might be able to set it up by installing as root, maybe manually copy the 
systemd service and hope that's enough. We can't support all methods of running 
daemons there exist on foreign distros, so you're on your own.

Le 27 juillet 2022 00:49:07 GMT+02:00, jgart  a écrit :
>On Tue, 26 Jul 2022 16:16:58 -0500 Nathan Dehnel  wrote:
>> I just installed the nix package provided by the host distro (not
>> guix). Seems to work fine.
>
>Hi Nathan,
>
>I've done that plenty of times before. That's usually how I install nix
>on a foreign distro (i.e. by using apt or xbps (void linux), etc.)
>
>What I'm asking about here is making it easy to install nix with guix on a 
>foreign distro.
>
>Currently, I can do the following on a foreign distro:
>
>`guix install nix`
>
>But the above will not set up the daemon service and create the build users, 
>etc...
>
>So, currently I'm not sure how we should go about supporting that on a foreign 
>distro...
>
>wdyt,
>
>jgart
>

Re: nix installed with guix on a foreign distro

[jgart]

On Tue, 26 Jul 2022 12:10:22 +0200 Maxime Devos  wrote:
> On 26-07-2022 08:00, jgart wrote:
> 
> > Hi Guixers,
> >
> > How can we make it easier to install nix with guix on a foreign distro?
> >
> > Guix System has a nix-service-type but there is no such thing on Debian.
> >
> > wdyt
> 
> This sounds like a question for Nix or Debian people to me, as AFAICT it 
> doesn't concern Guix.

What do you think Debian people should be providing to make it easier to run 
the guix installed nix package?

Or, what should I ask the Debian people if I decide to inquire with them?

all best,

jgart

Re: nix installed with guix on a foreign distro

[jgart]

On Tue, 26 Jul 2022 16:16:58 -0500 Nathan Dehnel  wrote:
> I just installed the nix package provided by the host distro (not
> guix). Seems to work fine.

Hi Nathan,

I've done that plenty of times before. That's usually how I install nix
on a foreign distro (i.e. by using apt or xbps (void linux), etc.)

What I'm asking about here is making it easy to install nix with guix on a 
foreign distro.

Currently, I can do the following on a foreign distro:

`guix install nix`

But the above will not set up the daemon service and create the build users, 
etc...

So, currently I'm not sure how we should go about supporting that on a foreign 
distro...

wdyt,

jgart

nix installed with guix on a foreign distro

[Nathan Dehnel]

I just installed the nix package provided by the host distro (not
guix). Seems to work fine.

Re: nix installed with guix on a foreign distro

[Maxime Devos]

On 26-07-2022 08:00, jgart wrote:


Hi Guixers,

How can we make it easier to install nix with guix on a foreign distro?

Guix System has a nix-service-type but there is no such thing on Debian.

wdyt


This sounds like a question for Nix or Debian people to me, as AFAICT it 
doesn't concern Guix.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

nix installed with guix on a foreign distro

[jgart]

Hi Guixers,

How can we make it easier to install nix with guix on a foreign distro?

Guix System has a nix-service-type but there is no such thing on Debian.

wdyt

Re: sssd, not nscd, foreign distro and release?

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Tue, 01 Mar 2022 at 18:24, Ludovic Courtès  wrote:
>> Ludovic Courtès  skribis:
>>> Chris Marusich  skribis:
>>>
 The Guix manual recommends running nscd:

 https://guix.gnu.org/manual/en/html_node/Application-Setup.html

 However, Fedora intends to remove it:

 https://fedoraproject.org/wiki/Changes/RemoveNSCD
>>>
>>> D’oh!  This is bad.  It might suggest that nscd will vanish from glibc
>>> as well, given it’s partly developed by the same group of people.
>>
>> Carlos O’Donell (of glibc) was kind enough to start a discussion
>> explaining why this is a concern for Guix (and Nix and others) and
>> proposing possible ways forward:
>>
>>   https://sourceware.org/pipermail/libc-alpha/2022-February/136741.html
>>
>> continued:
>>
>>   https://sourceware.org/pipermail/libc-alpha/2022-March/thread.html#136745
>
> What is the status of this?

Nothing has changed; we have too little weight in the upstream
discussion, so the most likely outcome is that we’ll have to adapt
somehow.

> Can it be blocking for the next release?

No, because it’s not implemented yet, but it’ll have to be addressed
soon enough.

Thanks,
Ludo’.

sssd, not nscd, foreign distro and release?

[zimoun]

Hi,

On Tue, 01 Mar 2022 at 18:24, Ludovic Courtès  wrote:
> Ludovic Courtès  skribis:
>> Chris Marusich  skribis:
>>
>>> The Guix manual recommends running nscd:
>>>
>>> https://guix.gnu.org/manual/en/html_node/Application-Setup.html
>>>
>>> However, Fedora intends to remove it:
>>>
>>> https://fedoraproject.org/wiki/Changes/RemoveNSCD
>>
>> D’oh!  This is bad.  It might suggest that nscd will vanish from glibc
>> as well, given it’s partly developed by the same group of people.
>
> Carlos O’Donell (of glibc) was kind enough to start a discussion
> explaining why this is a concern for Guix (and Nix and others) and
> proposing possible ways forward:
>
>   https://sourceware.org/pipermail/libc-alpha/2022-February/136741.html
>
> continued:
>
>   https://sourceware.org/pipermail/libc-alpha/2022-March/thread.html#136745

What is the status of this?  Can it be blocking for the next release?


Cheers,
simon

Re: How to use Guix with sssd, not nscd, on a foreign distro?

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> Chris Marusich  skribis:
>
>> The Guix manual recommends running nscd:
>>
>> https://guix.gnu.org/manual/en/html_node/Application-Setup.html
>>
>> However, Fedora intends to remove it:
>>
>> https://fedoraproject.org/wiki/Changes/RemoveNSCD
>
> D’oh!  This is bad.  It might suggest that nscd will vanish from glibc
> as well, given it’s partly developed by the same group of people.

Carlos O’Donell (of glibc) was kind enough to start a discussion
explaining why this is a concern for Guix (and Nix and others) and
proposing possible ways forward:

  https://sourceware.org/pipermail/libc-alpha/2022-February/136741.html

continued:

  https://sourceware.org/pipermail/libc-alpha/2022-March/thread.html#136745

Ludo’.

Re: How to use Guix with sssd, not nscd, on a foreign distro?

[Ludovic Courtès]

Hello,

Chris Marusich  skribis:

> The Guix manual recommends running nscd:
>
> https://guix.gnu.org/manual/en/html_node/Application-Setup.html
>
> However, Fedora intends to remove it:
>
> https://fedoraproject.org/wiki/Changes/RemoveNSCD

D’oh!  This is bad.  It might suggest that nscd will vanish from glibc
as well, given it’s partly developed by the same group of people.

AFAIK, nscd is the only way to allow glibc’s name service switch (NSS)
to be used on a system where multiple glibc versions might coexist.
This is a problem Fedora doesn’t have: there’s always a single glibc
package installed.

[...]

> The Fedora document explains that at least the hosts cache will be
> handled by systemd-resolved.  Can I expect Guix-built programs to "try
> to use systemd" when resolving host names, or is additional
> configuration likely to be required?

I suppose there’s a systemd-resolved NSS module, and /etc/nsswitch.conf
points to it.

> Regarding sssd specifically, how can I arrange for a Guix-built program
> to "try to use sssd" first?

The relevant glibc functions always check nsswitch.conf and use the
methods prescribed there.  When nscd is not running, they might end up
trying to dlopen libnss_sssd.so, which will usually fail.

One way to work around it is described here:

  https://lists.gnu.org/archive/html/guix-devel/2020-08/msg00168.html

But this is pretty much a last resort and not something we’d recommend
for general use.

HTH!

Ludo’.

Re: How to use Guix with sssd, not nscd, on a foreign distro?

[Lars-Dominik Braun]

Hi Chris,

> The Fedora document explains that at least the hosts cache will be
> handled by systemd-resolved.  Can I expect Guix-built programs to "try
> to use systemd" when resolving host names, or is additional
> configuration likely to be required?
as far as I know systemd also plugs into the nss mechanism, i.e. it’s
a shared library libnss_systemd.so from the host system, which would
be dlopen’ed.

> Regarding sssd specifically, how can I arrange for a Guix-built program
> to "try to use sssd" first?
I believe nscd is a glibc internal mechanism, which – if enabled –
will be queried before using the nsswitch mechanism. Thus it works to
circumvent the shared library dilemma on foreign systems. Programs do
not use sssd directly (that’s the whole point of nss/sssd). It plugs
into nsswitch just like systemd and therefore does nothing for our
use case.

nixOS seems to have the same problem, with suggestions for solutions like
[1].

So in conclusion I don’t think sssd is an appropriate replacement for
our use-case.

Cheers,
Lars

[1] https://github.com/NixOS/nixpkgs/pull/155655

How to use Guix with sssd, not nscd, on a foreign distro?

[Chris Marusich]

Hi,

The Guix manual recommends running nscd:

https://guix.gnu.org/manual/en/html_node/Application-Setup.html

However, Fedora intends to remove it:

https://fedoraproject.org/wiki/Changes/RemoveNSCD

The document says:

"The hosts cache will automatically be replaced by the one provided by
systemd-resolved. However, in order to restore caching functionality for
other caches provided by nscd, the system administrator will need to
install and/or configure sssd (by enabling sssd with authconfig, and
editing /etc/sssd/sssd.conf to enable it to work with nss)."

This poses a problem for people who use Fedora, like myself.  I tried to
set up sssd on my Fedora machine, but I couldn't get it to work.

Let's take a step back.  Why does the Guix manual recommend using nscd?
The Guix manual explains why in the link above.  To rephrase the manual,
my understanding is that if nscd is available, then a program using
glibc will "try to use nscd" first.  However, if nscd is not available,
then the program will attempt to dlopen shared objects, and in some
cases the program might dlopen an incompatible shared object from the
foreign distro (e.g., libnss_*.so files on Fedora, which may be
incompatible with the glibc used by a program that Guix built).

The Fedora document explains that at least the hosts cache will be
handled by systemd-resolved.  Can I expect Guix-built programs to "try
to use systemd" when resolving host names, or is additional
configuration likely to be required?

Regarding sssd specifically, how can I arrange for a Guix-built program
to "try to use sssd" first?  I know that the specific steps for how to
do this on Fedora might be different from other systems.  For example,
maybe on Fedora there is some fancy authselect/authconfig thing you can
do to configure everything more easily.  That's fine, and I will figure
out what to do at a higher level as needed.  However, for now I just
want to know the very basics: fundamentally, what configuration needs to
exist in order to ensure that Guix-built programs will "use" sssd, in
the same way that they would "use" nscd?  I want to avoid the kind of
problems that the manual discusses, but I want to do it with sssd.

I believe this will require changes to /etc/nsswitch.conf, as well as
configuration for sssd.  Anything else?  I have never written sssd
configuration files, and the sssd manual was not very approachable for
me, so I'm starting from essentially zero knowledge about sssd.  It
seems rather complex.  Has anyone tried setting up sssd and configuring
nsswitch to use it, in order to avoid the kinds of issues that the Guix
manual discusses?

Any tips would be welcome.  Maybe I should just switch back to Guix
System and avoid this headache, but I think there are lots of people out
there who use Fedora, so it would be good for Guix adoption if we can
have a recommended solution ready for people who are curious to try Guix
on Fedora.

-- 
Chris

PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836


signature.asc
Description: PGP signature

Re: Can't develop on foreign distro - core dump linking error

[zimoun]

Hi Hartmut,

On Sat, 02 Jan 2021 at 11:00, Hartmut Goebel  
wrote:

> guix package --manifest=$PWD/develop-profile.scm
> --profile=$PWD/.develop-profile
> active this profile
> make distclean ; bootstrap ; ./configure ; make

What does $PWD/develop-profile.scm contain?  Other said, does it work
when using the usual:

  guix environment guix
  ./bootstrap
  ./configure --localstatedir=/var/
  make

?

Hope that helps,
simon

Re: Can't develop on foreign distro - core dump linking error

[Pjotr Prins]

Have you tried building in a Guix container? See 'bullet proof' in my
guix-notes.

On Sat, Jan 02, 2021 at 11:00:27AM +0100, Hartmut Goebel wrote:
> Hi,
> 
> after happily developing guix on a foreign distro for quite some years
> (well, I had some issue now and then but was always able to recover),
> I'm no longer able to do so:
> 
> - "make" fails when linking guix-daemon with "undefined reference to
> `__twalk_r@GLIBC_PRIVATE'"
> 
> - ./pre-inst-env guix --help dumps core
> 
> Any ideas?
> 
> I tried
> 
> make distclean ; bootstrap ; ./configure ; make
> 
> with no success.
> 
> Environment:
> 
> guix 50812aaeb6c8c736a73547b781b8e47b8b345ed1
> 
> guix package --manifest=$PWD/develop-profile.scm
> --profile=$PWD/.develop-profile
> active this profile
> make distclean ; bootstrap ; ./configure ; make
> 
> -- 
> Regards
> Hartmut Goebel
> 
> | Hartmut Goebel  | h.goe...@crazy-compilers.com   |
> | www.crazy-compilers.com | compilers which you thought are impossible |
> 
> 

Can't develop on foreign distro - core dump linking error

[Hartmut Goebel]

Hi,

after happily developing guix on a foreign distro for quite some years
(well, I had some issue now and then but was always able to recover),
I'm no longer able to do so:

- "make" fails when linking guix-daemon with "undefined reference to
`__twalk_r@GLIBC_PRIVATE'"

- ./pre-inst-env guix --help dumps core

Any ideas?

I tried

make distclean ; bootstrap ; ./configure ; make

with no success.

Environment:

guix 50812aaeb6c8c736a73547b781b8e47b8b345ed1

guix package --manifest=$PWD/develop-profile.scm
--profile=$PWD/.develop-profile
active this profile
make distclean ; bootstrap ; ./configure ; make

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

foreign distro: QT5 loads/searchs plugins from wrong location

[Hartmut Goebel]

Hi,

before fling a bug, I jsut want to know whether I missed some update:

I just packages a simple GUI application using pythonqt5 and
python-poppler-qt. When running it fails with:

Could not load the Qt platform plugin "xcb" in "" even though it was
found.

When running with QT_DEBUG_PLUGINS=1 it reveals the cause:

QFactoryLoader::QFactoryLoader() checking directory path
"/usr/lib64/qt5/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() looking at
"/usr/lib64/qt5/plugins/platforms/KWinQpaPlugin.so"
Found metadata in lib
/usr/lib64/qt5/plugins/platforms/KWinQpaPlugin.so, metadata=
[… many lines skipped …]

Got keys from plugin meta data ("xcb")
QFactoryLoader::QFactoryLoader() checking directory path
"/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4/bin/platforms"
...
Cannot load library /usr/lib64/qt5/plugins/platforms/libqxcb.so:
(libQt5XcbQpa.so.5: cannot open shared object file: No such file or
directory)
QLibraryPrivate::loadPlugin failed on
"/usr/lib64/qt5/plugins/platforms/libqxcb.so" : "Cannot load library
/usr/lib64/qt5/plugins/platforms/libqxcb.so: (libQt5XcbQpa.so.5:
cannot open shared object file: No such file or directory)"

Looks like the plugin is search in the wrong location and also the list
of plgins.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |




signature.asc
Description: OpenPGP digital signature

Re: Qemu binfmt on foreign distro

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> I ran further tests. On Ubuntu 18.04, using qemu-user-static or
> qemu-user-binfmt makes no difference, they both fail.
>
> qemu-user-static works on Ubuntu 19.04 because of the addition of the
> 'F' flag, see:
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1815100.
>
> Adding the 'F' flag[1] manually on Ubuntu 18.04 also fixes the issue.

Right, so there are two things you need for emulated builds to work: (1)
the qemu-xyz program must be visible in the container, and (2) the
dynamic linker and shared libraries it refers to must also be visible.

The ‘F’ flag solves #1, and using a statically-linked QEMU solves #2.

> I could maybe add an entry to the documentation explaining that, in
> order for '--system' command to work on foreign distros, it is needed
> that:
>
> * A static version of qemu-user is used by binfmt
> * The 'F' flag is enabled for all binfmt installed entries

That has to be worded carefully: it’s only for foreign distros, and only
for architectures that the CPU doesn’t support (x86_64 can do i686, and
some AArch64 CPUs can do ARMv7).

Perhaps it could be a sub-section under “Application Setup”, linked from
the ‘--system’ documentation?

Thanks,
Ludo’.

Re: Qemu binfmt on foreign distro

[Mathieu Othacehe]

I ran further tests. On Ubuntu 18.04, using qemu-user-static or
qemu-user-binfmt makes no difference, they both fail.

qemu-user-static works on Ubuntu 19.04 because of the addition of the
'F' flag, see:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1815100.

Adding the 'F' flag[1] manually on Ubuntu 18.04 also fixes the issue.

I could maybe add an entry to the documentation explaining that, in
order for '--system' command to work on foreign distros, it is needed
that:

* A static version of qemu-user is used by binfmt
* The 'F' flag is enabled for all binfmt installed entries

Mathieu

[1]: https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html

Re: Qemu binfmt on foreign distro

[Mathieu Othacehe]

Oops pressed C-c C-c by mistake, sorry :p

So here is what is installed by Ubuntu:

--8<---cut here---start->8---
mathieu@cervin:~/guix$ ls /proc/sys/fs/binfmt_misc/ -al
-rw-r--r-- 1 root root 0 nov.  23 19:42 qemu-aarch64
-rw-r--r-- 1 root root 0 nov.  23 19:42 qemu-alpha
--8<---cut here---end--->8---

and,

--8<---cut here---start->8---
mathieu@cervin:~/guix$ cat /proc/sys/fs/binfmt_misc/qemu-aarch64 
enabled
interpreter /usr/bin/qemu-aarch64
flags: OC
offset 0
magic 7f454c46020101000200b700
mask ff00feff
--8<---cut here---end--->8---

Then when running:

guix build --system=armhf-linux hello

--8<---cut here---start->8---
The following derivation will be built:
   /gnu/store/174lzlz5ggw1gjck7qzkyw9qbi6izxql-hello-2.10.drv
building /gnu/store/174lzlz5ggw1gjck7qzkyw9qbi6izxql-hello-2.10.drv...
while setting up the build environment: executing 
`/gnu/store/50f18mlbj915vydqmm6nyvkh2b23vmf0-guile-2.2.6/bin/guile': No such 
file or directory
builder for `/gnu/store/174lzlz5ggw1gjck7qzkyw9qbi6izxql-hello-2.10.drv' failed 
with exit code 1
build of /gnu/store/174lzlz5ggw1gjck7qzkyw9qbi6izxql-hello-2.10.drv failed
View build log at 
'/var/log/guix/drvs/17/4lzlz5ggw1gjck7qzkyw9qbi6izxql-hello-2.10.drv.bz2'.
guix build: error: build of 
`/gnu/store/174lzlz5ggw1gjck7qzkyw9qbi6izxql-hello-2.10.drv' failed
--8<---cut here---end--->8---

And stracing guix daemon:

--8<---cut here---start->8---
[pid 21571] 
execve("/gnu/store/50f18mlbj915vydqmm6nyvkh2b23vmf0-guile-2.2.6/bin/guile", 
["guile", "--no-auto-compile", "-L", 
"/gnu/store/6y2hmc19rywag4p4akfl4g3vz4cv2948-module-import", 
"/gnu/store/dccz535kqh527828ilsb4lyicx9xbn7p-hello-2.10-guile-builder"], 
0x1fcda60 /* 12 vars */ 
[pid 21557] write(4, "gmlo\0\0\0\0\250\0\0\0\0\0\0\0@ build-started 
/gnu/store/174lzlz5ggw1gjck7qzkyw9qbi6izxql-hello-2.10.drv - armhf-linux 
/var/log/guix/drvs/17//4lzlz5ggw1gjck7qzkyw9qbi6izxql-hello-2.10.drv.bz2 
21571\n", 184) = 184
[pid 21557] select(20, [19], NULL, NULL, NULL 
[pid 21571] <... execve resumed> )  = -1 ENOENT (No such file or directory)
--8<---cut here---end--->8---

However, just noticed that if I install qemu-user-static instead of
qemu-user-binfmt, everything works well, not sure why :(.

So I guess I was making noise for nothing, sorry about that.

Mathieu

Re: Qemu binfmt on foreign distro

[Mathieu Othacehe]

Hello Ludo,

> How did you get ENOENT?  Was it because you had installed qemu/binfmt
> support from the host distro, and thus /usr/bin/qemu-whatever wasn’t
> found?

Yes that's it.

mathieu@cervin:~$ ls /proc/sys/fs/binfmt_misc/ -al
total 0
-rw-r--r-- 1 root root 0 nov.  23 19:27 qemu-aarch64
-rw-r--r-- 1 root root 0 nov.  23 19:27 qemu-arm
...

>
> How does it fail exactly, and what do you have in
> /proc/sys/fs/binfmt_misc?
>
> On Guix System, I get the expected behavior:
>
> --8<---cut here---start->8---
> $ sudo herd stop qemu-binfmt
> Service qemu-binfmt has been stopped.
> $ guix build -s aarch64-linux hello --check
> La jena derivo estos konstruata:
>/gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv
> building /gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv...
> @ unsupported-platform 
> /gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv aarch64-linux
> while setting up the build environment: a `aarch64-linux' is required to 
> build `/gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv', but I am 
> a `x86_64-linux'
> builder for `/gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv' 
> failed with exit code 1
> build of /gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv failed
> View build log at 
> '/var/log/guix/drvs/3j/4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv.bz2'.
> guix build: error: build of 
> `/gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv' failed
> --8<---cut here---end--->8---
>
> Thanks,
> Ludo’.

Re: Qemu binfmt on foreign distro

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> On a foreign distro, one can install QEMU and setup the binfmt mechanism
> (installing binfmt-support and qemu-user-static packages on
> Ubuntu). However, without the proper --chroot-directory arguments passed
> to guix-daemon, all binaries execution relying on binfmt will throw
> ENOENT from within the guix-daemon.

Yes, so what?  :-)

Commit 7bf2a70a4ffd976d50638d3b9f2ec409763157df expects ENOEXEC in this
case, and a meaningful error message is provided when that happens.

How did you get ENOENT?  Was it because you had installed qemu/binfmt
support from the host distro, and thus /usr/bin/qemu-whatever wasn’t
found?

> So I can see two solutions here:
>
> * Remove --system argument support for guix on foreign distributions
> (except when using this argument does not require binfmt support, 32
> bits build on a 64 bits machine).
>
> * Provide some kind of script that generates the correct guix-daemon
> command line, enabling binfmt support on foreign distros.
>
> Anyhow, the current behaviour where guix build --system=... fails
> misteriously because of an ENOENT error on a foreign distro is not
> acceptable in my opinion.

How does it fail exactly, and what do you have in
/proc/sys/fs/binfmt_misc?

On Guix System, I get the expected behavior:

--8<---cut here---start->8---
$ sudo herd stop qemu-binfmt
Service qemu-binfmt has been stopped.
$ guix build -s aarch64-linux hello --check
La jena derivo estos konstruata:
   /gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv
building /gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv...
@ unsupported-platform 
/gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv aarch64-linux
while setting up the build environment: a `aarch64-linux' is required to build 
`/gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv', but I am a 
`x86_64-linux'
builder for `/gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv' failed 
with exit code 1
build of /gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv failed
View build log at 
'/var/log/guix/drvs/3j/4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv.bz2'.
guix build: error: build of 
`/gnu/store/3j4nj1y86szk6ibaqp4yc09m2p1xmkr5-hello-2.10.drv' failed
--8<---cut here---end--->8---

Thanks,
Ludo’.

Qemu binfmt on foreign distro

[Mathieu Othacehe]

Hello,

When running a guix build command with --system argument set to a
foreign architecture, guix-daemon will use linux binfmt mechanism to
emulate binary execution.

On a Guix system, the qemu-binfmt-service-type service has to be
installed, so that linux binfmt mechanism is hooked to QEMU. This
service also adds a bunch of "--chroot-directory" arguments to
guix-daemon command line, so that QEMU and all its dependencies are
accessible from the guix-daemon chroot.

On a foreign distro, one can install QEMU and setup the binfmt mechanism
(installing binfmt-support and qemu-user-static packages on
Ubuntu). However, without the proper --chroot-directory arguments passed
to guix-daemon, all binaries execution relying on binfmt will throw
ENOENT from within the guix-daemon.

So I can see two solutions here:

* Remove --system argument support for guix on foreign distributions
(except when using this argument does not require binfmt support, 32
bits build on a 64 bits machine).

* Provide some kind of script that generates the correct guix-daemon
command line, enabling binfmt support on foreign distros.

Anyhow, the current behaviour where guix build --system=... fails
misteriously because of an ENOENT error on a foreign distro is not
acceptable in my opinion.

What do you think?

Thanks,

Mathieu

Re: KVM kernel module permission denied on foreign distro

[Giovanni Biscuolo]

Hi Pierre,

Pierre Neidhardt  writes:

> If I'm not mistaken, this is because you need to add the builders to the 'kvm'
> group.

yes! this solved the "Could not access KVM kernel module: Permission
denied" I had with "guix system vm" (both as user and root):

  $ for i in `seq -w 1 10`; do sudo usermod -G guixbuild,kvm guixbuilder$i; done
  $ sudo systemctl restart guix-daemon.service # since my init system is systemd

the fact that builds are made by a dedicated daemon using dedicated
unprivileged users (guixbuilder${i}) in an isolated environment is
pretty new to me and sometimes I forget it :-S

> From the manual ((guix) 2.4.1 Build Environment Setup):
>
> --8<---cut here---start->8---
> To use ‘guix system vm’ and related commands,
> you may need to add the build users to the ‘kvm’ group so they can
> access ‘/dev/kvm’, using ‘-G guixbuild,kvm’ instead of ‘-G guixbuild’
> (*note Invoking guix system::).
> --8<---cut here---end--->8---

I read that but skipped that because lazy people like me use installers
:-), so I used the shell installer script mentioned in "(guix)Binary
Installation" and that does not add guixbuilder${i} users to the kvm
group in "sys_create_build_user()" shell function

moreover, "(guix)Invoking guix system" should mention this in the "`vm`"
section, in case users (like me) skipped or misunderstood that part of
"(guix)Build Environment Setup" for any reason

tomorrow I'm going to propose a couple of patches to address both of the
above mentioned issues

Thanks!
Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Foreign distro GUIX_LOCPATH errors when installing from manual

[Spencer Baugh]

Ludovic Courtès  writes:
> I think we should do that only when GUIX_LOCPATH is unset, but yes, this
> is a good idea.
>
> I’m not sure how to implement it exactly; it seems cumbersome to ask
> users to write such a script.  Thoughts?

I think such a script should come with the tarball, and the manual
should direct users to copy it into place instead of making a symlink.

> Maybe the binary tarball should provide a short, readable ‘install.sh’
> script that would do everything the “Binary Installation” section
> describes, including this extra step?

This would be nice. But I would caution against a script eventually
becoming the primary means of installation of Guix on foreign
distros. If that happens, eventually I think the documentation will
become out of date and manual installation will become much harder.

Maybe that section of the documentation could be written in a literate
programming style which can be used to generate the install.sh? That
would be a nice way to keep both the documentation and the install.sh in
sync and up to date with changes.

Re: Foreign distro GUIX_LOCPATH errors when installing from manual

[Thomas Danckaert]

From: l...@gnu.org (Ludovic Courtès)
Subject: Re: Foreign distro GUIX_LOCPATH errors when installing from 
manual

Date: Mon, 11 Jul 2016 12:07:56 +0200

and that the installation instructions say to install glibc-locale 
(or

some other locale package) in root's profile.


They already say so under “Application Setup”, but maybe that 
should be

made more prominent?


The section does not explicitly tell to install these locales also 
for root.


Perhaps the daemon systemd configuration could be expanded to set a 
specific locale for the Guix build-daemon (currently it uses the host 
systems default locale settings), and a package for only that 
specific locale could be included in the binary tarball, installed in 
root's profile?  I'm not really familiar with the build daemon or 
locales, but I think that it doesn't matter so much which locale is 
set for the build daemon, as long as it is properly configured? (This 
is also related to your question about including glibc-utf8-locales 
in the binary tarball in the parallel thread)


Thomas

Re: Foreign distro GUIX_LOCPATH errors when installing from manual

[Ludovic Courtès]

Hello!

sba...@catern.com skribis:

> I was just getting started with Guix by installing it on my regular
> distro, Debian Jessie, by following the manual (which is really great -
> I tried installing Nix first but couldn't get it to work, the Guix
> manual is much better).
>
> The install was successful but I noticed two errors related to
> GUIX_LOCPATH which I had to fix by asking others for advice. Both happen
> when running guix package commands as a regular user, by running
> /usr/local/bin/guix.
>
> - substitute: warning: failed to install locale: Invalid argument
>
> This was a result of the daemon, running as root, not having
> GUIX_LOCPATH set in its environment.
>
> My solution was installing glibc-locale in root's profile, and adding:
>
> Environment=GUIX_LOCPATH=/root/.guix_profile/lib/locale
>
> to the [Service] section of the systemd unit file used to start the
> daemon. I suggest that this line should be added to the unit file
> shipped with guix,

Agreed.  Someone else made a similar suggestion and the patch is being
committed:

  https://lists.gnu.org/archive/html/guix-devel/2016-07/msg00223.html

> and that the installation instructions say to install glibc-locale (or
> some other locale package) in root's profile.

They already say so under “Application Setup”, but maybe that should be
made more prominent?

  
https://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Locales

> - warning: failed to install locale: Invalid argument
>
> This was a result of the user running guix not having GUIX_LOCPATH set
> in their current environment. But, keep in mind, the user is running
> guix through /usr/local/bin/guix, which is in fact a symlink to root's
> guix.
>
> I suggest that the appropriate solution is to instead of symlinking
> /usr/local/bin/guix to
> /var/guix/profiles/per-user/root/guix-profile/bin/guix, we should
> replace /usr/local/bin/guix with the following shell script:
>
> #!/bin/sh
> export 
> GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale
> /var/guix/profiles/per-user/root/guix-profile/bin/guix $*
>
> That is, root's guix should be run with root's locales.

I think we should do that only when GUIX_LOCPATH is unset, but yes, this
is a good idea.

I’m not sure how to implement it exactly; it seems cumbersome to ask
users to write such a script.  Thoughts?

Maybe the binary tarball should provide a short, readable ‘install.sh’
script that would do everything the “Binary Installation” section
describes, including this extra step?

Thanks,
Ludo’.

Foreign distro GUIX_LOCPATH errors when installing from manual

[sbaugh]

Hi,

I was just getting started with Guix by installing it on my regular
distro, Debian Jessie, by following the manual (which is really great -
I tried installing Nix first but couldn't get it to work, the Guix
manual is much better).

The install was successful but I noticed two errors related to
GUIX_LOCPATH which I had to fix by asking others for advice. Both happen
when running guix package commands as a regular user, by running
/usr/local/bin/guix.

- substitute: warning: failed to install locale: Invalid argument

This was a result of the daemon, running as root, not having
GUIX_LOCPATH set in its environment.

My solution was installing glibc-locale in root's profile, and adding:

Environment=GUIX_LOCPATH=/root/.guix_profile/lib/locale

to the [Service] section of the systemd unit file used to start the
daemon. I suggest that this line should be added to the unit file
shipped with guix, and that the installation instructions say to install
glibc-locale (or some other locale package) in root's profile.

- warning: failed to install locale: Invalid argument

This was a result of the user running guix not having GUIX_LOCPATH set
in their current environment. But, keep in mind, the user is running
guix through /usr/local/bin/guix, which is in fact a symlink to root's
guix.

I suggest that the appropriate solution is to instead of symlinking
/usr/local/bin/guix to
/var/guix/profiles/per-user/root/guix-profile/bin/guix, we should
replace /usr/local/bin/guix with the following shell script:

#!/bin/sh
export GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale
/var/guix/profiles/per-user/root/guix-profile/bin/guix $*

That is, root's guix should be run with root's locales.


Hopefully these can be fixed!