bug#22687: Online manual not updated automatically

[Chris Marusich]

Ricardo Wurmus  writes:

> Many other projects publish online manuals for both stable and
> development versions.  As our releases are a little far apart and we’re
> encouraging to do “guix pull” (so users really run the development
> version) I think it would indeed make sense to also publish an
> up-to-date version of the manual along with the manual for the latest
> release.

Does guix pull not update the manual?

- Chris

bug#22713: guix prints stray ^M characters

[Danny Milosavljevic]

There are some stray ^M characters in the (git) guix output:

accepted connection from pid 2640, user dannym
looking for the latest release of GNU gcc...^M  
  ^Mguix package: warning: ambiguous package specification `guile'
looking for the latest release of GNU guile...^M
  ^MThe following packages would be installed:

-

Easiest to see using "less test-suite.log" after there was a test failure.

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#22687: Online manual not updated automatically

[Mathieu Lirzin]

Florian Paul Schmidt  writes:

> On 16.02.2016 17:42, Andreas Enge wrote:
>> On Tue, Feb 16, 2016 at 05:33:27PM +0100, Ricardo Wurmus wrote:
>>> I was not courageous enough to suggest that, but this does sound
>>> like a good idea.
>> 
>> It is easy enough to have that courage when one is not the person
>> making the releases :-)
>
> Hmm, shouldn't that process be mostly automated? And if not, maybe
> it's worth thinking about how to do that. I guess from a functional
> point of view a release is just a function that takes a revision and
> has as its outputs installer images, binary installers, a new website,
> yada yada yada..

IIUC The problem is that making a release involves a lot a build power
that take long long time and makes it difficult to resolve unavoidable
issues encountered during the process.

I remember hearing Ludo explaining that the release process for Guix was
more involving than for the other software projects he experienced.

--
Mathieu Lirzin

bug#22695: Binary Installation bugs and suggestions

[Mathieu Lirzin]

myglc2  writes:

> Jookia <166...@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#22659: Collision of /bin/ld

[Leo Famulari]

On Mon, Feb 15, 2016 at 10:46:19PM -0500, Mark H Weaver wrote:
> Leo Famulari  writes:
> 
> > Invoking `guix environment guix`, I found this collision alarming. Do
> > you think it's a problem?
> >
> > I ran `guix pull` yesterday or the day before. Is there a way to
> > determine the git commit that corresponds with this version of Guix?
> >
> > I added the line breaks.
> >
> > warning: collision encountered:
> > /gnu/store/agnxzx1yza8ci0a1gz5pds8gdg8qmnz5-ld-wrapper-0/bin/ld
> > /gnu/store/dki0v5cvf1mhfz571k622xvzi1nyinl2-binutils-2.25.1/bin/ld 
> >
> > warning: arbitrarily choosing
> > /gnu/store/agnxzx1yza8ci0a1gz5pds8gdg8qmnz5-ld-wrapper-0/bin/ld
> 
> This collision is expected.  The 'ld' within ld-wrapper, generated from
> the template in gnu/packages/ld-wrapper.in, automatically adds -rpath
> arguments to the linker for each shared library, so that the runtime
> linker will be able to find them in their non-standard locations.

Okay, closing!

> 
>   Mark

bug#22707: IBus relies on possibly outdated ~/.cache/ibus/bus/registry

[Ricardo Wurmus]

I have an annoying little problem with IBus.  IBus creates a binary
registry in ~/.cache/ibus/bus on first start(?) which contains the full
paths to store items such as

/gnu/store/k3r...-ibus-1.5.11/libexec/ibus-dconf

The problem is that when updating the “ibus” package this registry is
invalid, but never invalidated or regenerated.  IBus will continue to
use the paths in the registry — even after they have disappeared after
“guix gc”.  This results in an unhelpful error when starting
“ibus-setup”:

Can not execute default config program

This is because it tries to run “$oldstoreitem/libexec/ibus-dconf”,
which has been removed by garbage collection.

The “.cache” directory is not part of the profile, of course, so we
cannot automatically rebuild it.  Looking at the code it seems that IBus
first looks for a system registry, but this registry cannot be right as
the user may have installed additional IBus input methods and the system
registry (wherever that may be) is not writeable.

Should we prevent a registry in the “.cache” directory to be used and
try to make IBus look for a registry that could be generated as part of
generating a new profile generation?

~~ Ricardo

bug#22695: Binary Installation bugs and suggestions

[myglc2]

Jookia <166...@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

[myglc2]

Ricardo Wurmus  writes:

> myglc2  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"  writes:
>> [...]
>>>
>>> Don't run 'guix package -r guix'.
>>
>> Cool, please say that.
>
> +1!
>
>> Ricardo Wurmus  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#21215: icecat can't be started by basename only

[Danny Milosavljevic]

Hi,

On Wed, 10 Feb 2016 22:03:21 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> l...@gnu.org (Ludovic Courtès) skribis:
> 
> > Danny Milosavljevic  skribis:
> >  
> >> right now on the GuixSD from the website I have about 12 copies of
> >> icecat installed in /gnu/store but I can start none of them by typing
> >>
> >>   $ icecat
> >>
> >> Why not?  
> >
> > See Taylan’s explanation from last month.
> >  
> >> Also, it isn't in Xfce4's Application Finder either (while for example
> >> HexChat is).  
> >
> > Is IceCat installed in the global profile, i.e., specified in the
> > ‘packages’ field of the ‘operating-system’ declaration, or is it
> > installed in your user profile?  
> 
> Ping!  :-)
> 
> Any update on this issue?  ()

I have a backup HDD with a copy of the installation from back then. 
I can connect it via USB enclosure. What should I check?

For the record, on the new GuixSD installation (including guix pull) which I'm 
using now, I can start icecat by typing "icecat". However, there's still no 
entry in the start menu - which is pretty annoying.

Also, icecat is in "gnu/packages/gnuzilla.scm". Weird. But ok...

Regards,
  Danny

bug#21216: glibc and linux-libre-headers

[Danny Milosavljevic]

Hi,

On Tue, 18 Aug 2015 21:23:40 +0200
l...@gnu.org (Ludovic Courtès) wrote:

> However, instead of installing the ‘glibc’ package, you may want to
> install the ‘gcc-toolchain’ package, which provides all the tools needed
> to do software development (GCC, libc, Binutils, the ‘ld wrapper’, etc.)

I tried that now - that works fine. 

Why can I install glibc (when it doesn't work anyway)? What's the difference?
Is it documented?

Thanks.

Regards,
   Danny

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#22687: Online manual not updated automatically

[Florian Paul Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16.02.2016 17:42, Andreas Enge wrote:
> On Tue, Feb 16, 2016 at 05:33:27PM +0100, Ricardo Wurmus wrote:
>> I was not courageous enough to suggest that, but this does sound
>> like a good idea.
> 
> It is easy enough to have that courage when one is not the person
> making the releases :-)

Hmm, shouldn't that process be mostly automated? And if not, maybe
it's worth thinking about how to do that. I guess from a functional
point of view a release is just a function that takes a revision and
has as its outputs installer images, binary installers, a new website,
yada yada yada..

Regards,
Flo


- -- 
https://fps.io
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWw1kKAAoJEA5f4Coltk8Z/6sH/1CuqcAbB+RC/b4bmyBkSJ0z
SlJBjkfs9BUxLtjzLXMn52t0dKOmA92CiVpZblTxb0M3rcruOY44Wlkc3J5PqP3U
Aqh+YzrowqKHBi+iikftiJYj9X7beh7rWxmM48nWkdtPTfLUYdbi5+AJtz7bwvQ8
ZHx5wilEVaUnXKyiora3V2Nm8bjGQXIfncvQy7rrON2XaNZut8ruIAI0FSn8F4xD
WPWP5tuTTdHJNCOSmsPr1kM2kmoBZ3hDs4BeJWbiTUMJTsh3G/P+z1XUBuoS3zWJ
CwYrTwZzulq9JTP10JdMOEBcoZ9/za3cpiHM2n8rA1CEpVKRKM/s9tnKZjl+oZ8=
=ODkW
-END PGP SIGNATURE-

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"  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"  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"  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

[Andreas Enge]

On Tue, Feb 16, 2016 at 11:19:34AM -0500, myglc2 wrote:
> "Thompson, David"  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#22687: Online manual not updated automatically

[Ricardo Wurmus]

Andreas Enge  writes:

> On Tue, Feb 16, 2016 at 11:06:40AM +0100, Ricardo Wurmus wrote:
>> Many other projects publish online manuals for both stable and
>> development versions.  As our releases are a little far apart and we’re
>> encouraging to do “guix pull” (so users really run the development
>> version) I think it would indeed make sense to also publish an
>> up-to-date version of the manual along with the manual for the latest
>> release.
>
> Or alternatively, release more often :-)

I was not courageous enough to suggest that, but this does sound like a
good idea.

> I wonder whether we should not make a point release after each security
> update instead of encouraging people to use "guix pull" (but we would
> quickly arrive at 0.9.9 now, after which only 1.0.0 would be a reasonable
> option to keep numerical and lexicographical ordering consistent).
> Or a point-point release as 0.9.0.1 and so on.

I would like that.  We could make patch releases for each time we merge
core-updates / security-fixes into master.

~~ Ricardo

bug#22695: Binary Installation bugs and suggestions

[myglc2]

Ricardo Wurmus  writes:

> myglc2  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"  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"  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  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"  writes:
[...]
> They would have to modify that user's package profile and
> 

bug#22687: Online manual not updated automatically

[Andreas Enge]

On Tue, Feb 16, 2016 at 11:06:40AM +0100, Ricardo Wurmus wrote:
> Many other projects publish online manuals for both stable and
> development versions.  As our releases are a little far apart and we’re
> encouraging to do “guix pull” (so users really run the development
> version) I think it would indeed make sense to also publish an
> up-to-date version of the manual along with the manual for the latest
> release.

Or alternatively, release more often :-)

I wonder whether we should not make a point release after each security
update instead of encouraging people to use "guix pull" (but we would
quickly arrive at 0.9.9 now, after which only 1.0.0 would be a reasonable
option to keep numerical and lexicographical ordering consistent).
Or a point-point release as 0.9.0.1 and so on.

Andreas

bug#22695: Binary Installation bugs and suggestions

[Ricardo Wurmus]

myglc2  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#22697: Rebuilding sources with svn-fetch won't refetch

[Jookia]

Hey there,

After building netpbm from source using no substitutes, running this command:

% guix build --source netpbm --check

Will use the checked out source files in /gnu/store rather than redownloading
from the project SVN repostiory. This is unlike this command:

% guix build --source guix --check

Which will refetch Guix from the project's Git repository.

Cheers,
Jookia.

bug#22695: Binary Installation bugs and suggestions

[Thompson, David]

On Tue, Feb 16, 2016 at 8:41 AM, myglc2  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

[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#22687: Online manual not updated automatically

[Ricardo Wurmus]

Leo Famulari  writes:

> I see the value of the online manual matching the version of the Guix
> binaries we distribute, but on the other hand, we get a lot of questions
> that are answered in the latest version of the manual.

Many other projects publish online manuals for both stable and
development versions.  As our releases are a little far apart and we’re
encouraging to do “guix pull” (so users really run the development
version) I think it would indeed make sense to also publish an
up-to-date version of the manual along with the manual for the latest
release.

~~ Ricardo

bug#22543: 404 in Manualpage

[Nils Gillmann]

Leo Famulari  writes:

> On Wed, Feb 03, 2016 at 02:41:04PM +0100, Nils Gillmann wrote:
>> The manual page
>> https://www.gnu.org/software/guix/manual/html_node/Requirements.html#Requirements
>> 
>> contains a link to
>> 
>> https://www.gnu.org/software/guix/manual/gnutls-guile/Guile-Preparations.html#Guile-Preparations
>> 
>> which give a 404. I am not familiar with what's supposed to be there, a
>> quick search for "gnutls-guile/Guile-Preparations.html" in duckduckgo gives 
>> me
>> http://www.gnutls.org/manual/gnutls-guile/Guile-Preparations.html as one
>> of 2 results.
>> 
>> Should I fix the link to this one and send in a patch?
>
> Yes, please!

So you think I should (and can?) fix it, while alex replies:

>> I don't think you can send a patch for this.  According to
>> :
>>
>>  (This page generated by the gendocs.sh¹ script.)

>> This "gendocs.sh" uses "texi2html" to convert our texinfo documentation
>> (see "doc/guix.texi" in the guix git repo) to the html page.  In
>> "guix.texi" the link you are talking about is a usual link to the
>> "gnutls-guile" manual.  I didn't look at "texi2html" but I believe by
>> default it just assumes that all the manuals are placed at
>> "www.gnu.org/software//manual/", so for "external" manuals the
>> generated links are false.  For example, there are also wrong links to
>> Geiser and Magit-Popup manuals.
>>
>> So I think it's a general thing for all generated manuals that are
>> placed on "gnu.org".
>>
>> ¹ http://git.savannah.gnu.org/cgit/gnulib.git/plain/build-aux/gendocs.sh
>>
>> -- 
>> Alex

Okay, so I guess it's related to #22651 and it#s not fixable the
way I want to (edit the source), or at least what I would want to
do is not optimal and it should be fixed in some other way.

Didn't look into it yet, but should we follow #22651 for the 404s?
-- 
ng

bug#22693: `guix refresh -u` updates other packages with same version

[Leo Famulari]

I've noticed that `guix refresh -u` will update extraneous packages if
they happen to have the same version and be in the same module.

For example, from commit d694230ab, you can reproduce the bug:

$ ./pre-inst-env guix environment guix -- ./pre-inst-env guix refresh -u 
python-pytest
$ git diff
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 3dd3862..ae14404 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -796,7 +796,7 @@ Python 3 support.")
 (define-public python-pycrypto
   (package
 (name "python-pycrypto")
-(version "2.6.1")
+(version "2.8.7")
 (source
  (origin
   (method url-fetch)
@@ -1565,7 +1565,7 @@ code introspection, and logging.")
 (define-public python-pytest
   (package
 (name "python-pytest")
-(version "2.6.1")
+(version "2.8.7")
 (source
  (origin
(method url-fetch)
@@ -1574,7 +1574,7 @@ code introspection, and logging.")
  version ".tar.gz"))
(sha256
 (base32
- "0g2w4p0n42wvz8rq4k6gnzpkakgz3g8sfanxk8jrsra9675snkcr"))
+ "1bwb06g64x2gky8x5hcrfpg6r351xwvafimnhm5qxq7wajz8ck7w"))
(modules '((guix build utils)))
(snippet
 ;; One of the tests involves the /usr directory, so it fails.