bug#22695: Binary Installation bugs and suggestions

bug#22695: Binary Installation bugs and suggestions

[myglc2]

I attempted to perform 'Binary Installation' on Debian 8 following ...

https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation

last updated November 04, 2015


Bugs:

A) The 4 occurrences of '~root' should be replaced with '/root'

B) What does 'On hosts using the systemd init system, drop
   /root/.guix-profile/lib/systemd/system/guix-daemon.service in
   /etc/systemd/system.' mean.

   FWIW, I tried ...

cp /root/.guix-profile/lib/systemd/system/guix-daemon.service \
   /etc/systemd/system/guix-daemon.service

... which did not work.


Suggestions:

 1)'guix archive --authorize < /root/.guix-profile/share/guix/hydra.gnu.org.pub'

   ... produced ...

   'warning: failed to install locale: Invalid argument'

   It is not good that the first guix operation that root attempts
   throws a warning.  Apparently this is to be expected, as careful
   study of '2.6 Application Setup' might suggest.  As a minimum, we
   should advise root that the warning is expected.

2) 'And that’s it! For additional tips and tricks, see Application
   Setup.' should be changed to say something like, 'This completes
   root-level install of Guix, However each of your users will need to
   first set their Locales and, if they intend to use X Window system,
   X11 fonts, as described in '2.6 Application Setup' before Guix will
   be fully functional.

3) Is it possible for root to pre-configure locales and X11 fonts for
   users?

4) What do we mean by, 'The guix package must remain available in root’s
   profile, or it would become subject to garbage collection—in which
   case you would find yourself badly handicapped by the lack of the
   guix command.'

   What does root have to do to assure that 'The guix package remains
   available'?
   
5) We should tell root how to verify that the installation was
   successful.  If 'make guix-binary.system.tar.xz' is intended to do
   this, we need to explain where to run it and how to verify the
   result.
   
6) Should a root 'guix pull' be recommended?

7) Given the "invasive" nature of this install, an uninstall script, or,
   as a minimum, explicit instructions of how to remove Guix, really
   must be provided.

8) It seems unlikely that a typical sysadmin will be willing to install
   Guix following the instructions as they now stand. This might be
   addressed by providing a Guix package for popular distributions.
   
9) We leave the root user with no locales or X11 fonts.  Do we recommend
   this?

bug#22695: Binary Installation bugs and suggestions

[Thompson, David]

On Tue, Feb 16, 2016 at 8:41 AM, myglc2 <myglc2@gmail.com> wrote:
> I attempted to perform 'Binary Installation' on Debian 8 following ...
>
> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation
>
> last updated November 04, 2015
>
>
> Bugs:
>
> A) The 4 occurrences of '~root' should be replaced with '/root'

Not a bug.  '~root' expands to '/root' or whatever the root user's
home directory is.

> B) What does 'On hosts using the systemd init system, drop
>    /root/.guix-profile/lib/systemd/system/guix-daemon.service in
>    /etc/systemd/system.' mean.
>
>    FWIW, I tried ...
>
> cp /root/.guix-profile/lib/systemd/system/guix-daemon.service \
>    /etc/systemd/system/guix-daemon.service
>
> ... which did not work.

What didn't work, exactly?  I've personally done this on systemd
setups and it works fine.

> Suggestions:
>
>  1)'guix archive --authorize < /root/.guix-profile/share/guix/hydra.gnu.org.pub'
>
>    ... produced ...
>
>    'warning: failed to install locale: Invalid argument'
>
>    It is not good that the first guix operation that root attempts
>    throws a warning.  Apparently this is to be expected, as careful
>    study of '2.6 Application Setup' might suggest.  As a minimum, we
>    should advise root that the warning is expected.

This warning is unavoidable when the glibc on the host distro has
locales that our incompatible with the glibc that Guix uses.  It's
unfortunate, but *much time* was spent dealing with this headache
already, including time spent talking to glibc developers.

> 2) 'And that’s it! For additional tips and tricks, see Application
>    Setup.' should be changed to say something like, 'This completes
>    root-level install of Guix, However each of your users will need to
>    first set their Locales and, if they intend to use X Window system,
>    X11 fonts, as described in '2.6 Application Setup' before Guix will
>    be fully functional.

That sounds mostly fine, but I don't understand the X11 fonts part.  I
use Guix on foreign distros and have no such issues regarding fonts.

> 3) Is it possible for root to pre-configure locales and X11 fonts for
>    users?

They would have to modify that user's package profile and
.bash_profile, which I don't think we would want to recommend.

> 4) What do we mean by, 'The guix package must remain available in root’s
>    profile, or it would become subject to garbage collection—in which
>    case you would find yourself badly handicapped by the lack of the
>    guix command.'
>
>    What does root have to do to assure that 'The guix package remains
>    available'?

Don't run 'guix package -r guix'.

> 5) We should tell root how to verify that the installation was
>    successful.  If 'make guix-binary.system.tar.xz' is intended to do
>    this, we need to explain where to run it and how to verify the
>    result.

'make guix-binary.system.tar.xz' is how you reproduce the binary
tarball, not how you verify the build was successful.

If the installation is successful, then running 'guix build hello' or
anything else like that should work.

> 6) Should a root 'guix pull' be recommended?

I don't think so.  It only affects the root user, and most people use
Guix as their regular user.  So, if anything, we should recommend
'guix pull' be run for their regular unprivileged user.

> 7) Given the "invasive" nature of this install, an uninstall script, or,
>    as a minimum, explicit instructions of how to remove Guix, really
>    must be provided.

The install is absolutely not invasive.  Guix is entirely
self-contained and does not affect the host distro at all.  Remove
/gnu and /var/guix and it is uninstalled.

> 8) It seems unlikely that a typical sysadmin will be willing to install
>    Guix following the instructions as they now stand. This might be
>    addressed by providing a Guix package for popular distributions.

This has been mentioned many times, but does anyone actually want to
step up and do the work?  Getting such packages into upstream distros
is unlikely because Guix does not conform to the FHS, but we can
provide the packages on our own website.

Personally, I feel that the instructions are so few that it's easy to
do by myself and it also informs me about what exactly is going on
with my system.

> 9) We leave the root user with no locales or X11 fonts.  Do we recommend
>    this?

Again, I don't understand the X11 fonts part, but this problem only
happens when the host distro uses a glibc with incompatible locales.

- Dave

bug#22695: Binary Installation bugs and suggestions

[Ricardo Wurmus]

myglc2 <myglc2@gmail.com> writes:

> I attempted to perform 'Binary Installation' on Debian 8 following ...
>
> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation
>
> last updated November 04, 2015

I suggest looking at the latest version of the manual in the repository
when using the latest version.  In a related bug report I already
commented that I think it would be good to host the latest version of
the manual on the website.

> Bugs:
>
> A) The 4 occurrences of '~root' should be replaced with '/root'

This is equivalent.  In bash “~root” expands to the home directory of
the root user, which usually is “/root”.

> B) What does 'On hosts using the systemd init system, drop
>    /root/.guix-profile/lib/systemd/system/guix-daemon.service in
>    /etc/systemd/system.' mean.
>
>    FWIW, I tried ...
>
> cp /root/.guix-profile/lib/systemd/system/guix-daemon.service \
>    /etc/systemd/system/guix-daemon.service
>
> ... which did not work.

How did it “not work”?  Dropping the file there does not start the
service automatically.  You’ll need to reload the service definitions
and then actually start the service.  But that’s really systemd
knowledge, and I don’t think it belongs in the Guix manual unless it’s
really short.

> Suggestions:
>
>  1)'guix archive --authorize < /root/.guix-profile/share/guix/hydra.gnu.org.pub'
>
>    ... produced ...
>
>    'warning: failed to install locale: Invalid argument'
>
>    It is not good that the first guix operation that root attempts
>    throws a warning.  Apparently this is to be expected, as careful
>    study of '2.6 Application Setup' might suggest.  As a minimum, we
>    should advise root that the warning is expected.

I wonder why we get this error in the first place.  I’d rather eliminate
the error than tell people to ignore it.

Any ideas what causes it?

> 2) 'And that’s it! For additional tips and tricks, see Application
>    Setup.' should be changed to say something like, 'This completes
>    root-level install of Guix, However each of your users will need to
>    first set their Locales and, if they intend to use X Window system,
>    X11 fonts, as described in '2.6 Application Setup' before Guix will
>    be fully functional.

The first item in the “Application Setup” section is about locales.  I
think it is sufficient the way it is now.  The section in question is
about how to install Guix.  Locales and X11 fonts are not required to
use Guix.

> 3) Is it possible for root to pre-configure locales and X11 fonts for
>    users?

Only by traditional means: installing “glibc-locales” in a shared
location and augmenting /etc/profile to set GUIX_LOCPATH.  This is not

> 4) What do we mean by, 'The guix package must remain available in root’s
>    profile, or it would become subject to garbage collection—in which
>    case you would find yourself badly handicapped by the lack of the
>    guix command.'
>
>    What does root have to do to assure that 'The guix package remains
>    available'?

I think this means that the root user should not uninstall guix with
guix.

> 5) We should tell root how to verify that the installation was
>    successful.  If 'make guix-binary.system.tar.xz' is intended to do
>    this, we need to explain where to run it and how to verify the
>    result.

The install was successful if “guix package -i hello” (or similar)
works.  Building the binary is only really useful when hacking on a git
clone of the repository.  It’s only mentioned there to show that the
binary tarball isn’t special.  I do think it would be better to have
this in a footnote or somewhere else where it doesn’t hurt the flow.

> 6) Should a root 'guix pull' be recommended?

Depends.  I think it’s not so useful as users other than root will be
using Guix mostly.  For every Guix user “guix pull” (or installing from
git) is recommended, so root is not special.

> 7) Given the "invasive" nature of this install, an uninstall script, or,
>    as a minimum, explicit instructions of how to remove Guix, really
>    must be provided.

Guix doesn’t touch anything but /gnu, $prefix/etc/guix/acl, and
$localstatedir.  It can be uninstalled by removing these files.  I agree
that adding this information to the manual would not hurt.

> 8) It seems unlikely that a typical sysadmin will be willing to install
>    Guix following the instructions as they now stand. This might be
>    addressed by providing a Guix package for popular distributions.

Sysadmin here :) I installed it according to the instructions but also
expanded on them by setting up a shared store.  I’ll try to prepare an
RPM to simplify installation on distributions derived from Red Hat /
Fedora.

> 9) We leave the root user with no locales or X11 fonts.  Do we recommend
>    this?

I hardly ever use the root user’s Guix profile when using Guix on a
foreign distribution.  I don’t think root needs X11 fonts as it isn’t
supposed to have its own X session.

~~ Ricardo

bug#22695: Binary Installation bugs and suggestions

[myglc2]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> myglc2 <myglc2@gmail.com> writes:
>
>> I attempted to perform 'Binary Installation' on Debian 8 following ...
>>
>> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation
>>
>> last updated November 04, 2015
>
> I suggest looking at the latest version of the manual in the repository
> when using the latest version.  In a related bug report I already
> commented that I think it would be good to host the latest version of
> the manual on the website.

Sounds good. How does a naive user trying to install Guix for the first
time do that?

>> Bugs:
>>
>> A) The 4 occurrences of '~root' should be replaced with '/root'
>
> This is equivalent.  In bash “~root” expands to the home directory of
> the root user, which usually is “/root”.

Ninja trick. Did no know. Does it apply in non-bash shells?

>> B) What does 'On hosts using the systemd init system, drop
>>    /root/.guix-profile/lib/systemd/system/guix-daemon.service in
>>    /etc/systemd/system.' mean.
>>
>>    FWIW, I tried ...
>>
>> cp /root/.guix-profile/lib/systemd/system/guix-daemon.service \
>>    /etc/systemd/system/guix-daemon.service
>>
>> ... which did not work.
>
> How did it “not work”?  Dropping the file there does not start the
> service automatically.  You’ll need to reload the service definitions
> and then actually start the service.  But that’s really systemd
> knowledge, and I don’t think it belongs in the Guix manual unless it’s
> really short.

"Thompson, David" <dthompson2@worcester.edu> writes:
[...]
> What didn't work, exactly?  I've personally done this on systemd
> setups and it works fine.

When I reboot my Debian 8 server, guix-daemon is not running.

IMO, the Guix story is most appealing to a user at this point in time.
So you want to help a user-level person try out Guix on a machine they
happen to have root or sudo on. If you force them go off and learn all
about systemd they may well run out of gas and never insall Guix.

So I think you should tell them specifically how to make guix-daemon be
running after a reboot, or they will be reporting that as a bug.

>> Suggestions:
>>
>>  1)'guix archive --authorize < /root/.guix-profile/share/guix/hydra.gnu.org.pub'
>>
>>    ... produced ...
>>
>>    'warning: failed to install locale: Invalid argument'
>>
>>    It is not good that the first guix operation that root attempts
>>    throws a warning.  Apparently this is to be expected, as careful
>>    study of '2.6 Application Setup' might suggest.  As a minimum, we
>>    should advise root that the warning is expected.
>
> I wonder why we get this error in the first place.  I’d rather eliminate
> the error than tell people to ignore it.
>
> Any ideas what causes it?

"Thompson, David" <dthompson2@worcester.edu> writes:
[...]
> This warning is unavoidable when the glibc on the host distro has
> locales that our incompatible with the glibc that Guix uses.  It's
> unfortunate, but *much time* was spent dealing with this headache
> already, including time spent talking to glibc developers.

The instructions should acknowledge that the warning may occur and can
safely be ignored.

>> 2) 'And that’s it! For additional tips and tricks, see Application
>>    Setup.' should be changed to say something like, 'This completes
>>    root-level install of Guix, However each of your users will need to
>>    first set their Locales and, if they intend to use X Window system,
>>    X11 fonts, as described in '2.6 Application Setup' before Guix will
>>    be fully functional.
>
> That sounds mostly fine, but I don't understand the X11 fonts part.  I
> use Guix on foreign distros and have no such issues regarding fonts.

My experience as a user of research GNU/Linux systems adminstered by
multiple people in multiple organizations is that fonts are all over the
map and a major pain. If Guix provides an out-of-the-box reproducible
X11 font experience that would be a fantastic feature for users like me.

But maybe it is unnecessary to specifically install X11 fonts?

If I install emacs, will it drag in the Guix X11 font set used to build
it?

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
[...]
> The first item in the “Application Setup” section is about locales.  I
> think it is sufficient the way it is now.  The section in question is
> about how to install Guix.  Locales and X11 fonts are not required to
> use Guix.

OK, but I don't think you want your users seeing recurrent warnings. IMO
it would be better to advise them to install locales than to let them
see a warning on every guix operation.

>> 3) Is it possible for root to pre-configure locales and X11 fonts for
>>    users?
>
> Only by traditional means: installing “glibc-locales” in a shared
> location and augmenting /etc/profile to set GUIX_LOCPATH.  This is not
>

"Thompson, David" <dthompson2@worcester.edu> writes:
[...]
> They would have to modify that user's package profile and
> .bash_profile, which I don't think we would want to recommend.

The use case I had in mind is that sysadmin uses Guix to provide a
specific Guix environment to support 1 or more "dumb" application users
(e.g, provide a stable specific version of R to a project team for the
duration of the project). In this case sysadmin does not want to burden
the team members with learning Guix.

Do we support such a case?

>> 4) What do we mean by, 'The guix package must remain available in root’s
>>    profile, or it would become subject to garbage collection—in which
>>    case you would find yourself badly handicapped by the lack of the
>>    guix command.'
>>
>>    What does root have to do to assure that 'The guix package remains
>>    available'?
>
> I think this means that the root user should not uninstall guix with
> guix.

"Thompson, David" <dthompson2@worcester.edu> writes:
[...]
>
> Don't run 'guix package -r guix'.

Cool, please say that.

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
[...]
>> 5) We should tell root how to verify that the installation was
>>    successful.  If 'make guix-binary.system.tar.xz' is intended to do
>>    this, we need to explain where to run it and how to verify the
>>    result.
>
> The install was successful if “guix package -i hello” (or similar)
> works.

Cool, lets tell them to do that.

> Building the binary is only really useful when hacking on a git
> clone of the repository.  It’s only mentioned there to show that the
> binary tarball isn’t special.  I do think it would be better to have
> this in a footnote or somewhere else where it doesn’t hurt the flow.

How about removing the tarball example entirely?

If I am sysadmin, I think a better thing to show me is how to build a
binary locally and see that, Yup, it matches the hydra substitute.

>> 6) Should a root 'guix pull' be recommended?
>
> Depends.  I think it’s not so useful as users other than root will be
> using Guix mostly.  For every Guix user “guix pull” (or installing from
> git) is recommended, so root is not special.

But doesn't root want/need to update guix?

>> 7) Given the "invasive" nature of this install, an uninstall script, or,
>>    as a minimum, explicit instructions of how to remove Guix, really
>>    must be provided.
>
> Guix doesn’t touch anything but /gnu, $prefix/etc/guix/acl, and
> $localstatedir.  It can be uninstalled by removing these files.  I agree
> that adding this information to the manual would not hurt.

FWIW, I used locate to look around for Guix detritus and I ended up with
this in my makefile:

uninstall:
        -rm -fr /gnu
        -rm -fr /var/guix
        -rm -f /root/.guix-profile
        -rm -fr /etc/guix
        -rm -f /usr/local/bin/guix
        -rm  /etc/systemd/system/guix-daemon.service
        -rm -fr /var/log
        -rm -fr /root/.config
        # don't forget to kill guix-daemon!
                                                                        

>> 8) It seems unlikely that a typical sysadmin will be willing to install
>>    Guix following the instructions as they now stand. This might be
>>    addressed by providing a Guix package for popular distributions.
>
> Sysadmin here :) I installed it according to the instructions but also
> expanded on them by setting up a shared store.  I’ll try to prepare an
> RPM to simplify installation on distributions derived from Red Hat /
> Fedora.

Sorry, buy you really don't sound like 'a typical sysadmin'.

In my experience, Mr. typical admin says, "if it's not in Yum or Aptitude I'm
not going there". 

A specific example, Mr. typical admin can not install the current
release of package A because it is not in the production yum for the
previous release of centos currently running. Mr. typical admin can not
build the package from sorce because it would 'take too much time'
and/or 'you are the only person asking for it'.

"Thompson, David" <dthompson2@worcester.edu> writes:
[...]
>
> This has been mentioned many times, but does anyone actually want to
> step up and do the work?  Getting such packages into upstream distros
> is unlikely because Guix does not conform to the FHS, but we can
> provide the packages on our own website.
>
> Personally, I feel that the instructions are so few that it's easy to
> do by myself and it also informs me about what exactly is going on
> with my system.

Agreed, when using my home servers. But a sysadmin with only a few hours
to understand Guix and many users potentially impacted will be much more
jumpy about the Guix install.

>> 9) We leave the root user with no locales or X11 fonts.  Do we recommend
>>    this?
>
> Again, I don't understand the X11 fonts part, but this problem only
> happens when the host distro uses a glibc with incompatible locales.

e.g. Debian and what else?

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
[...]
> I hardly ever use the root user’s Guix profile when using Guix on a
> foreign distribution.  I don’t think root needs X11 fonts as it isn’t
> supposed to have its own X session.

OK, this may be a canard. I was thinking that a user might use X as root
running directly on a machine (which I don't do). Sorry.

bug#22695: Binary Installation bugs and suggestions

[Andreas Enge]

On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> "Thompson, David" <dthompson2@worcester.edu> writes:
> > What didn't work, exactly?  I've personally done this on systemd
> > setups and it works fine.
> When I reboot my Debian 8 server, guix-daemon is not running.

I had the same experience on my arm machines. So this might be a real bug.
Or does one need to do more than copy the file and reboot?

Andreas

bug#22695: Binary Installation bugs and suggestions

[Jookia]

On Tue, Feb 16, 2016 at 05:51:37PM +0100, Andreas Enge wrote:
> I had the same experience on my arm machines. So this might be a real bug.
> Or does one need to do more than copy the file and reboot?

You need to run 'systemctl start guix-daemon'.

> Andreas

bug#22695: Binary Installation bugs and suggestions

[myglc2]

Jookia <166291@gmail.com> writes:

> On Tue, Feb 16, 2016 at 05:51:37PM +0100, Andreas Enge wrote:
>> I had the same experience on my arm machines. So this might be a real bug.
>> Or does one need to do more than copy the file and reboot?
>
> You need to run 'systemctl start guix-daemon'.

on Debian 8 ...

cp /root/.guix-profile/lib/systemd/system/guix-daemon.service \
    /etc/systemd/system/guix-daemon.service

systemctl start guix-daemon
        
... runs guix-daemon, but after a reboot it is not running.

bug#22695: Binary Installation bugs and suggestions

[Mathieu Lirzin]

myglc2 <myglc2@gmail.com> writes:

> Jookia <166291@gmail.com> writes:
>
>> On Tue, Feb 16, 2016 at 05:51:37PM +0100, Andreas Enge wrote:
>>> I had the same experience on my arm machines. So this might be a real bug.
>>> Or does one need to do more than copy the file and reboot?
>>
>> You need to run 'systemctl start guix-daemon'.
>
> on Debian 8 ...
>
> cp /root/.guix-profile/lib/systemd/system/guix-daemon.service \
>     /etc/systemd/system/guix-daemon.service
>
> systemctl start guix-daemon
>         
> ... runs guix-daemon, but after a reboot it is not running.

IIUC the correct command to start guix-daemon at boot should be:

  systemctl enable guix-daemon

--
Mathieu Lirzin

bug#22695: Binary Installation bugs and suggestions

[Leo Famulari]

On Tue, Feb 16, 2016 at 05:51:37PM +0100, Andreas Enge wrote:
> On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> > "Thompson, David" <dthompson2@worcester.edu> writes:
> > > What didn't work, exactly?  I've personally done this on systemd
> > > setups and it works fine.
> > When I reboot my Debian 8 server, guix-daemon is not running.
> 
> I had the same experience on my arm machines. So this might be a real bug.
> Or does one need to do more than copy the file and reboot?

Standard systemd service installation:

$ cp foo.service where-you-want-it && systemctl daemon-reload && systemctl start foo.service

No reboot is necessary.

> 
> Andreas
> 
> 
> 
> 

bug#22695: Binary Installation bugs and suggestions

[Leo Famulari]

On Tue, Feb 16, 2016 at 02:50:48PM -0500, Leo Famulari wrote:
> On Tue, Feb 16, 2016 at 05:51:37PM +0100, Andreas Enge wrote:
> > On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> > > "Thompson, David" <dthompson2@worcester.edu> writes:
> > > > What didn't work, exactly?  I've personally done this on systemd
> > > > setups and it works fine.
> > > When I reboot my Debian 8 server, guix-daemon is not running.
> > 
> > I had the same experience on my arm machines. So this might be a real bug.
> > Or does one need to do more than copy the file and reboot?
> 
> Standard systemd service installation:
> 
> $ cp foo.service where-you-want-it && systemctl daemon-reload && systemctl start foo.service
> 
> No reboot is necessary.

I forgot a step:

$ cp foo.service where-you-want it && systemctl daemon-reload \
&& systemctl enable foo && systemctl start foo

You can start foo without enabling, but enabling is what makes it start
automatically.

> 
> > 
> > Andreas
> > 
> > 
> > 
> > 
> 
> 
> 

bug#22695: Binary Installation bugs and suggestions

[Jookia]

On Tue, Feb 16, 2016 at 02:53:07PM -0500, Leo Famulari wrote:
> $ cp foo.service where-you-want it && systemctl daemon-reload \
> && systemctl enable foo && systemctl start foo
> 
> You can start foo without enabling, but enabling is what makes it start
> automatically.

It definitely needs to go in the manual if both of us forget to write it.  :)

bug#22695: Binary Installation bugs and suggestions

[Jookia]

On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> Ninja trick. Did no know. Does it apply in non-bash shells?

Works on zsh here, though presumably that's due to Bash compatibility.

On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> >> B) What does 'On hosts using the systemd init system, drop
> >>    /root/.guix-profile/lib/systemd/system/guix-daemon.service in
> >>    /etc/systemd/system.' mean.
> >>
> >>    FWIW, I tried ...
> >>
> >> cp /root/.guix-profile/lib/systemd/system/guix-daemon.service \
> >>    /etc/systemd/system/guix-daemon.service
> >>
> >> ... which did not work.
> >
> > How did it “not work”?  Dropping the file there does not start the
> > service automatically.  You’ll need to reload the service definitions
> > and then actually start the service.  But that’s really systemd
> > knowledge, and I don’t think it belongs in the Guix manual unless it’s
> > really short.
> 
> "Thompson, David" <dthompson2@worcester.edu> writes:
> [...]
> > What didn't work, exactly?  I've personally done this on systemd
> > setups and it works fine.

> When I reboot my Debian 8 server, guix-daemon is not running.
> 
> IMO, the Guix story is most appealing to a user at this point in time.
> So you want to help a user-level person try out Guix on a machine they
> happen to have root or sudo on. If you force them go off and learn all
> about systemd they may well run out of gas and never insall Guix.
> 
> So I think you should tell them specifically how to make guix-daemon be
> running after a reboot, or they will be reporting that as a bug.

Yeah, it'd probably be good to have some simple instructions 'copy this to there
and run systemctl start guix-daemon' as well as creating the builderaccounts.

On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> "Thompson, David" <dthompson2@worcester.edu> writes:
> [...]
> > This warning is unavoidable when the glibc on the host distro has
> > locales that our incompatible with the glibc that Guix uses.  It's
> > unfortunate, but *much time* was spent dealing with this headache
> > already, including time spent talking to glibc developers.
> 
> The instructions should acknowledge that the warning may occur and can
> safely be ignored.

On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> [...]
> > The first item in the “Application Setup” section is about locales.  I
> > think it is sufficient the way it is now.  The section in question is
> > about how to install Guix.  Locales and X11 fonts are not required to
> > use Guix.
> 
> OK, but I don't think you want your users seeing recurrent warnings. IMO
> it would be better to advise them to install locales than to let them
> see a warning on every guix operation.

Is there no way we can just ship Guix with a default en_US.UTF-8 locale and have
Guix set GUIX_LOCPATH if it's not done already when running? Though this
wouldn't really help for multilingual support I suppose.

On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> "Thompson, David" <dthompson2@worcester.edu> writes:
> [...]
> >
> > Don't run 'guix package -r guix'.
> 
> Cool, please say that.

Should 'guix package -r guix' be something that require a --force flag or
similiar if it's going to break things beyond belief?

On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> But doesn't root want/need to update guix?

Only if it wants to use the updated Guix.

On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> Agreed, when using my home servers. But a sysadmin with only a few hours
> to understand Guix and many users potentially impacted will be much more
> jumpy about the Guix install.

There's always the binary installation method, but I suppose a better questions
would be if it's a good idea to help people who don't understand Guix to install
it. System administrators might for example expect they can limit which software
is installed by their users but Guix doesn't do this.

bug#22695: Binary Installation bugs and suggestions

[Ricardo Wurmus]

myglc2 <myglc2@gmail.com> writes:

> The use case I had in mind is that sysadmin uses Guix to provide a
> specific Guix environment to support 1 or more "dumb" application users
> (e.g, provide a stable specific version of R to a project team for the
> duration of the project). In this case sysadmin does not want to burden
> the team members with learning Guix.
>
> Do we support such a case?

Yes.  I have been doing this for our cluster users for months before we
could make the changes in our environment that were needed to let users
manage their profiles by themselves.

We currently use Guix for shared per-group profiles, individual per-user
profiles, and per-project profiles.

You can install packages into a custom profile by using the “-p” flag,
e.g.

    guix package -p /path/to/shared/profile \
                 --install glibc-utf8-locales r r-genomation

Users would then have to add something like this to their
~/.bash_profile:

    eval $(guix package -p /path/to/shared/profile --search-paths=prefix)

or just add the result of the command in parentheses to the
~/.bash_profile.  This would prepend the “bin” directory of the profile
to the PATH and set other environment variables that are needed.

Then they could use an unchanging version of the “genomation” package
from within R, as defined in that profile.  (In the long run it would
make more sense to instantiate profiles using manifest files.)

Slightly off-topic: note that in this case installing R packages via
‘install.packages(...)’ is discouraged.  Some R packages link with
system libraries and unless you’re also adding the compiler toolchain to
your profile you would end up with binaries that are linked with the
system libc and thus cannot successfully be loaded by the R in your
profile, which is linked with libc from the Guix store.

I suggest going full Guix instead of mixing ‘install.packages(...)’ with
Guix stuff.  We have importers for CRAN and bioconductor, so packaging R
packages for Guix is usually really simple.  (I’ve used the importer to
generate package expressions for all of CRAN, but since I’m not using
them all I haven’t yet found motivation to submit patches for them.)

>>> 4) What do we mean by, 'The guix package must remain available in root’s
>>>    profile, or it would become subject to garbage collection—in which
>>>    case you would find yourself badly handicapped by the lack of the
>>>    guix command.'
>>>
>>>    What does root have to do to assure that 'The guix package remains
>>>    available'?
>>
>> I think this means that the root user should not uninstall guix with
>> guix.
>
> "Thompson, David" <dthompson2@worcester.edu> writes:
> [...]
>>
>> Don't run 'guix package -r guix'.
>
> Cool, please say that.

+1!

> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
> [...]
>>> 5) We should tell root how to verify that the installation was
>>>    successful.  If 'make guix-binary.system.tar.xz' is intended to do
>>>    this, we need to explain where to run it and how to verify the
>>>    result.
>>
>> The install was successful if “guix package -i hello” (or similar)
>> works.
>
> Cool, lets tell them to do that.

+1!

Would you be willing to send a patch?  (I’m pretty sure I’ll forget
doing this myself.)

>> Sysadmin here :) I installed it according to the instructions but also
>> expanded on them by setting up a shared store.  I’ll try to prepare an
>> RPM to simplify installation on distributions derived from Red Hat /
>> Fedora.
>
> Sorry, buy you really don't sound like 'a typical sysadmin'.

Oh, well :)

> In my experience, Mr. typical admin says, "if it's not in Yum or Aptitude I'm
> not going there". 
>
> A specific example, Mr. typical admin can not install the current
> release of package A because it is not in the production yum for the
> previous release of centos currently running. Mr. typical admin can not
> build the package from sorce because it would 'take too much time'
> and/or 'you are the only person asking for it'.

Heh, I think I know (an instance of) that person (template)!

I seem to remember that there’s an RPM for OpenSUSE somewhere, but I’m
not sure what the status is.  In my opinion it would be desirable to
have the .spec file to generate the RPM in the Guix sources.

~~ Ricardo

bug#22695: Binary Installation bugs and suggestions

[myglc2]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> myglc2 <myglc2@gmail.com> writes:
>
>> The use case I had in mind is that sysadmin uses Guix to provide a
>> specific Guix environment to support 1 or more "dumb" application users
>> (e.g, provide a stable specific version of R to a project team for the
>> duration of the project). In this case sysadmin does not want to burden
>> the team members with learning Guix.
>>
>> Do we support such a case?
>
> Yes.  I have been doing this for our cluster users for months before we
> could make the changes in our environment that were needed to let users
> manage their profiles by themselves.
>
> We currently use Guix for shared per-group profiles, individual per-user
> profiles, and per-project profiles.
>
> You can install packages into a custom profile by using the “-p” flag,
> e.g.
>
>     guix package -p /path/to/shared/profile \
>                  --install glibc-utf8-locales r r-genomation
>
> Users would then have to add something like this to their
> ~/.bash_profile:
>
>     eval $(guix package -p /path/to/shared/profile --search-paths=prefix)
>
> or just add the result of the command in parentheses to the
> ~/.bash_profile.  This would prepend the “bin” directory of the profile
> to the PATH and set other environment variables that are needed.
>
> Then they could use an unchanging version of the “genomation” package
> from within R, as defined in that profile.  (In the long run it would
> make more sense to instantiate profiles using manifest files.)

Fantastic. You have just described one of the fantasy use cases that
have propelled me to spend a few weeks learning first NixOS and now
Guix.

> Slightly off-topic: note that in this case installing R packages via
> ‘install.packages(...)’ is discouraged.  Some R packages link with
> system libraries and unless you’re also adding the compiler toolchain to
> your profile you would end up with binaries that are linked with the
> system libc and thus cannot successfully be loaded by the R in your
> profile, which is linked with libc from the Guix store.
>
> I suggest going full Guix instead of mixing ‘install.packages(...)’ with
> Guix stuff.  We have importers for CRAN and bioconductor, so packaging R
> packages for Guix is usually really simple.  (I’ve used the importer to
> generate package expressions for all of CRAN, but since I’m not using
> them all I haven’t yet found motivation to submit patches for them.)

I have bite marks from the same dog. I agree this is the way to go.

>>>> 4) What do we mean by, 'The guix package must remain available in root’s
>>>>    profile, or it would become subject to garbage collection—in which
>>>>    case you would find yourself badly handicapped by the lack of the
>>>>    guix command.'
>>>>
>>>>    What does root have to do to assure that 'The guix package remains
>>>>    available'?
>>>
>>> I think this means that the root user should not uninstall guix with
>>> guix.
>>
>> "Thompson, David" <dthompson2@worcester.edu> writes:
>> [...]
>>>
>>> Don't run 'guix package -r guix'.
>>
>> Cool, please say that.
>
> +1!
>
>> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
>> [...]
>>>> 5) We should tell root how to verify that the installation was
>>>>    successful.  If 'make guix-binary.system.tar.xz' is intended to do
>>>>    this, we need to explain where to run it and how to verify the
>>>>    result.
>>>
>>> The install was successful if “guix package -i hello” (or similar)
>>> works.
>>
>> Cool, lets tell them to do that.
>
> +1!
>
> Would you be willing to send a patch?  (I’m pretty sure I’ll forget
> doing this myself.)

Will do once I get my Guix space suit fully inflated ;=)

bug#22695: Binary Installation bugs and suggestions

[Ludovic Courtès]

Commit c8e26887eda99d1cd7b89772ff642854a6b78ebd incorporates your
suggestions; closing this bug..  Thanks again!

Ludo’.