bug#35864: ~/.local/bin is missing in default PATH on Guix System

[Giovanni Biscuolo]

Hi Florian,

this is not a bug, it's a feature :-)

the "semantic" reason not to include ~/.local/bin in default path is to
clearly state "use Guix" (even on foreign distros) to allow users to
install packages and avoid the ~//bin _broken_ workaround

IMHO at most ~/.local/bin is useful for user written scripts (but I
prefer ~/bin for mine)

"pelzflorian (Florian Pelz)"  writes:

> On Thu, May 23, 2019 at 09:31:09PM +0200, Tobias Geerinckx-Rice wrote:
>> pelzflorian (Florian Pelz) wrote:
>> > Adding ~/.local/bin to the PATH is common on other distros.

[...]

> My motivation was that I would have liked a uniform standard to exist
> for offering uniform, simple compilation instructions

I can't understand what ~/.local/bin have to do with *compilation*: do
you mean installation?

...and AFAIU no distribution on earth install packages (or links) in
~/.local/bin

Guix deploys in ~/.guix-profile/bin/ linking from the store... and it's
awesome :-)

[...]

> for how-to-install sections in software project README files.

It's easier to add instructions on how to add ~/.local/bin in $PATH, no?
:-)

anyway software projects that want to help users to install (without
root permissions) in a sane way should define a Guix package, no more
workarounds please

[...]

> Many other distributions are discussed at my stackexchange link from
> before.

not Guix nor Nix, IMHO it's because they choose to depart from the
problematic FSH and derivatives long time ago and for this reason they
are generally ignored when discussing FSH issues

> I did not know about ~/bin being conventional, but others mention it
> too.  I do not like ~/bin for the reasons you stated:

do you mean you don't like it because it's not hidden? :-)

I don't like ~/.local/bin because it's ".local":

«Care should be taken when placing architecture-dependent binaries in
this place, which might be problematic if the home directory is shared
between multiple hosts with different architectures.»
(from [1])

[...]

last but not least, probably systemd file-hieracy [1] is one of the
*problematic* things of systemd ecosystem we should avoid

...I even ignored the existance of systemd file-hieracy: an init system
defining a filesystem hieracy standard: mumble...




Happy hacking! Gio'.



[1] https://www.freedesktop.org/software/systemd/man/file-hierarchy.html

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[Ricardo Wurmus]

pelzflorian (Florian Pelz)  writes:

> Currently for a simple GTK application of mine, on other distros I run
> it by
>
> dont-hang
>
> but on Guix I have to run it with:
>
> LD_LIBRARY_PATH=/gnu/store/b9p5rhhci7w1zgvv4j0fm2izk86cgnyd-gtk+-3.24.7/lib:/gnu/store/z7myqdqz5i4ahw57l5hagdkmzwz5g2wv-pango-1.42.4/lib:/gnu/store/5yaa39a8rvq8xdv8h37n29sxfmnlcv12-atk-2.32.0/lib:/gnu/store/4d8rc6vjkhsk1b20rigz0nzl7zffn4b5-cairo-1.16.0/lib:/gnu/store/h7wv1qgpascffzi5xlpagnc0hpiv2523-gdk-pixbuf+svg-2.38.1/lib:/gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib:$LD_LIBRARY_PATH
>  PATH=$HOME/.local/bin:$PATH dont-hang
>
> Adding ~/.local/bin to the path would remove the small part on the
> right.  Patching ninja could probably remove the need for
> LD_LIBRARY_PATH.

Specifying the RUNPATH during compilation would allow you to get rid of
LD_LIBRARY_PATH.  What build system are you using?

-- 
Ricardo

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[pelzflorian (Florian Pelz)]

On Fri, May 24, 2019 at 12:36:14AM +0200, pelzflorian (Florian Pelz) wrote:
> My motivation was that I would have liked a uniform standard to exist
> for offering uniform, simple compilation instructions in tutorials
> like mine
>  or
> for how-to-install sections in software project README files.  I
> therefore believe such standardization efforts should be supported,
> even though Guix has good reason to ignore some other aspects of the
> file-system hierarchy standard.
> 

Currently for a simple GTK application of mine, on other distros I run
it by

dont-hang

but on Guix I have to run it with:

LD_LIBRARY_PATH=/gnu/store/b9p5rhhci7w1zgvv4j0fm2izk86cgnyd-gtk+-3.24.7/lib:/gnu/store/z7myqdqz5i4ahw57l5hagdkmzwz5g2wv-pango-1.42.4/lib:/gnu/store/5yaa39a8rvq8xdv8h37n29sxfmnlcv12-atk-2.32.0/lib:/gnu/store/4d8rc6vjkhsk1b20rigz0nzl7zffn4b5-cairo-1.16.0/lib:/gnu/store/h7wv1qgpascffzi5xlpagnc0hpiv2523-gdk-pixbuf+svg-2.38.1/lib:/gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib:$LD_LIBRARY_PATH
 PATH=$HOME/.local/bin:$PATH dont-hang

Adding ~/.local/bin to the path would remove the small part on the
right.  Patching ninja could probably remove the need for
LD_LIBRARY_PATH.

Regards,
Florian

bug#35853: gnome-tweaks unable to manage gnome shell extentions

[Jack Hill]

I don't know why I didn't think the terminal output said anything useful. 
On a second look, it really does appear to:


```
$ gnome-tweaks

** (..gnome-tweaks-real-real:2439): WARNING **: 22:15:34.941: Failed to load 
shared library 'libsoup-2.4.so.1' referenced by the typelib: libsoup-2.4.so.1: 
cannot open shared object file: No such file or directory
WARNING : Error detecting shell
Traceback (most recent call last):
  File 
"/gnu/store/1fv652flfj50j5w916nggw7d9v6cy1mi-gnome-tweaks-3.28.1/lib/python3.7/site-packages/gtweak/tweaks/tweak_group_shell_extensions.py",
 line 219, in __init__
ego = ExtensionsDotGnomeDotOrg(version)
  File 
"/gnu/store/1fv652flfj50j5w916nggw7d9v6cy1mi-gnome-tweaks-3.28.1/lib/python3.7/site-packages/gtweak/egowrapper.py",
 line 25, in __init__
self._session = Soup.Session.new()
GLib.GError: g-invoke-error-quark: Could not locate soup_session_new: 
libsoup-2.4.so.1: cannot open shared object file: No such file or directory (1)
WARNING : Error detecting shell
Traceback (most recent call last):
  File 
"/gnu/store/1fv652flfj50j5w916nggw7d9v6cy1mi-gnome-tweaks-3.28.1/lib/python3.7/site-packages/gtweak/tweaks/tweak_group_shell_extensions.py",
 line 53, in __init__
self._swInfo = Gio.DesktopAppInfo.new("org.gnome.Software.desktop")
TypeError: constructor returned NULL

(..gnome-tweaks-real-real:2439): Gtk-WARNING **: 22:15:36.303: 
gtk_window_present_with_time() should not be called with 0, or GDK_CURRENT_TIME 
as a timestamp, the timestamp should instead be gathered at the time the user 
initiated the request for the window to be shown
```

In particular, "Error detecting shell" only appears in the 
tweak_group_shell_extensions.py [0].


[0] 
https://gitlab.gnome.org/GNOME/gnome-tweaks/blob/ee2a669b867894b1f8d58edad861e02ec690c5fe/gtweak/tweaks/tweak_group_shell_extensions.py#L63

I haven't yet looked into why it's hitting those error conditions.

Best,
Jack

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[pelzflorian (Florian Pelz)]

On Thu, May 23, 2019 at 09:31:09PM +0200, Tobias Geerinckx-Rice wrote:
> pelzflorian (Florian Pelz) wrote:
> > Adding ~/.local/bin to the PATH is common on other distros.
> 
> This is what still needs to be established: is it?  Which ones? Is it merely
> a side-effect of them using systemd?  And most crucially: does it mean that
> Guix needs to add it too?  What about ~/bin?
> 

My motivation was that I would have liked a uniform standard to exist
for offering uniform, simple compilation instructions in tutorials
like mine
 or
for how-to-install sections in software project README files.  I
therefore believe such standardization efforts should be supported,
even though Guix has good reason to ignore some other aspects of the
file-system hierarchy standard.

I checked now and systemd Parabola iso images and installed systems do
not include ~/.local/bin; neither does an installed Arch system I
looked at, despite their claim to follow
.
I believe this may have to do with their tendency to ship programs
mostly like their upstream developers ship them, which would apply to
GNU Guix as well.  Many other distributions are discussed at my
stackexchange link from before.

I did not know about ~/bin being conventional, but others mention it
too.  I do not like ~/bin for the reasons you stated:

On Thu, May 23, 2019 at 04:55:28PM +0200, Tobias Geerinckx-Rice wrote:
> My theory is that it's intended for users of graphical file browsers (where
> the traditional ~/bin is a bit too prominent even for my tastes), but I use
> it too.
> 


> I'm was just interested in the (ideally: your) arguments for doing so, not a
> link to a discussion site.  If it really breaks things that should work, I'm
> all in favour of adding it to the default skeleton, if not /etc/profile
> itself.
>

I am not aware of it fixing any breakage, except Python pip according
to the Debian bug report
 (I did not
try to confirm this), but Guix does not (need to?) have a package for
pip anyway.

Regards,
Florian

bug#35865: compute-guix-derivation failed to compute the derivation for Guix

[Keith Thompson]

After submitting that report, I ran "guix pull" again, with no
intervening commands.  The system sat idle for about 28 hours
between the two attempts. The second command completed without error.

I have partial output of the successful command (about 1800
lines). I'm not including it here, but let me know if you want to
see it. (Ask for a copy of "guix-bug2".)

-- Keith Thompson

bug#35874: “guix pull” fails on setlocale

[Ricardo Wurmus]

This is a store corruption bug.

The problem appears to be that I accidentally ran the daemon with the
wrong GUIX_DATABASE_DIRECTORY.  The localstatedir is /gnu/var, not /var.

In an attempt to simplify my complicated cluster setup, I wanted to
switch from the git checkout to “guix pull”.  I was able to use the Guix
client from “guix pull”, but not the daemon, because of the
localstatedir difference.

When I started the daemon from “guix pull” without having set
GUIX_DATABASE_DIRECTORY and I asked Guix to build something I noticed
this error message:

   guix pull: error: cannot unlink 
`/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/gconv': Directory 
not empty

Wait, “unlink”?  Of course: when a build is not found in the database,
but the store contains an item of the same name the daemon will remove
the existing directory.

In my case, the daemon did not realize that it couldn’t ever find
anything interesting in the database, because it looked in the wrong
localstate directory.  So it partially removed store items and then
aborted, leaving the store in a broken state.

Can we make the daemon detect that its understanding of the site differs
from that of the Guix client?

--
Ricardo

bug#35874: “guix pull” fails on setlocale

[Ricardo Wurmus]

Hi Guix,

I’m getting this weird error on “guix pull”:

--8<---cut here---start->8---
[rwur...@max147.mdc-berlin.net:~] $ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   e26d628
Computing Guix derivation for 'x86_64-linux'... \@ build-started 
/gnu/store/pryjyasqnhc69qqjsbvv5f1ksi25mjdc-libgit2-0.28.tar.xz.drv - 
x86_64-linux 
/gnu/var/log/guix/drvs/pr//yjyasqnhc69qqjsbvv5f1ksi25mjdc-libgit2-0.28.tar.xz.drv
 2110   
  |@ build-log 2110 252
Backtrace:
   2 (primitive-load "/gnu/store/lgad0sg02p56jadwqrq674250d5?")
In ice-9/eval.scm:
619:8  1 (_ #f)
In unknown file:
   0 (setlocale 6 "en_US.utf8")

ERROR: In procedure setlocale:
In procedure setlocale: Invalid argument
builder for 
`/gnu/store/pryjyasqnhc69qqjsbvv5f1ksi25mjdc-libgit2-0.28.tar.xz.drv' failed 
with exit code 1
@ build-failed 
/gnu/store/pryjyasqnhc69qqjsbvv5f1ksi25mjdc-libgit2-0.28.tar.xz.drv - 1 builder 
for `/gnu/store/pryjyasqnhc69qqjsbvv5f1ksi25mjdc-libgit2-0.28.tar.xz.drv' 
failed with exit code 1
cannot build derivation 
`/gnu/store/nj6zd6gn3x1rf08ayxxwd1v0fyg71v9c-libgit2-0.28.2.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/82x55s3m26j3rpq45ppijzvvh3rhxhsb-guile-git-0.2.0.drv': 1 
dependencies couldn't be built
Backtrace:
In ./guix/store.scm:
   1667:8 19 (_ _)
   1667:8 18 (_ _)
In ./guix/gexp.scm:
708:2 17 (_ _)
In ./guix/monads.scm:
482:9 16 (_ _)
In ./guix/gexp.scm:
   573:13 15 (_ _)
In ./guix/store.scm:
   1667:8 14 (_ _)
In ./guix/gexp.scm:
708:2 13 (_ _)
In ./guix/monads.scm:
482:9 12 (_ _)
In ./guix/gexp.scm:
   573:13 11 (_ _)
In ./guix/store.scm:
   1667:8 10 (_ _)
In ./guix/gexp.scm:
708:2  9 (_ _)
In ./guix/monads.scm:
482:9  8 (_ _)
In ./guix/gexp.scm:
   573:13  7 (_ _)
In ./guix/store.scm:
   1667:8  6 (_ _)
  1690:38  5 (_ #)
In ./guix/packages.scm:
   936:16  4 (cache! # # ?)
In ./guix/grafts.scm:
314:4  3 (graft-derivation # # # ?)
192:4  2 (references-oracle # #)
   201:20  1 (_ _ _)
In ./guix/store.scm:
  1203:15  0 (_ # _ _)

./guix/store.scm:1203:15: Throw to key `srfi-34' with args `(#)'.
guix pull: error: You found a bug: the program 
'/gnu/store/2mjaq8zxq60ifqxj3fra7f8gyxxccypm-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"e26d628b0fabf5a0aa7c4164a9558c66c61e02ab"; system: "x86_64-linux";
host version: "ebd45195dd10eea9ce2c563697989bd4b27dfdd3"; pull-version: 1).
Please report it by email to .
--8<---cut here---end--->8---

I’m using “guix” from the result of a previous “guix pull”, but it’s the
same if I use a git checkout.

The daemon is probably a little special.  I’m using the daemon from a
git checkout inside of an environment for “guix”, because localstatedir
in my case is /gnu/var.

I also tried using the daemon from the same “guix pull” tree, after
setting GUIX_DATABASE_DIRECTORY=/gnu/var/guix/db and
GUIX_STATE_DIRECTORY=/gnu/var/guix.

Here’s how I launch the daemon:

--8<---cut here---start->8---
#!/bin/bash

export GUIX_PROFILE=/gnu/var/guix/profiles/custom/guix-remote/.guix-profile

# We need this to augment the GUILE_LOAD_PATH such that it includes
# the Guile bindings to gnutls.  Sourcing the whole profile is
# overkill, but who cares, eh?
source ${GUIX_PROFILE}/etc/profile

# Fix locale warnings
export GUIX_LOCPATH=${GUIX_PROFILE}/lib/locale

# Fix certificate validation
export SSL_CERT_DIR=${GUIX_PROFILE}/etc/ssl/certs/
#export GUIX_DATABASE_DIRECTORY=/gnu/var/guix/db
#export GUIX_STATE_DIRECTORY=/gnu/var/guix

#/gnu/remote/.guix-pull/bin/guix-daemon \
#/gnu/remote/guix/pre-inst-env guix-daemon \
exec /gnu/remote/guix/pre-inst-env guix-daemon \
 --disable-log-compression \
 --build-users-group=guix-builder \
 --listen=141.80.186.209: \
 --substitute-urls="https://berlin.guixsd.org https://mirror.hydra.gnu.org"; 
$@
--8<---cut here---end--->8---

All communication with the daemon happens over network; the local socket
is not involved, but this doesn’t seem to make any difference here.

The simplest reproducer is to run Guile where the daemon runs and to
evaluate setlocale:

--8<---cut here---start->8---
[rwurmus@guix-builder:~] (716) $ 
/gnu/store/r658y3cgpnf99nxjxqgjiaizx20ac4k0-guile-2.2.4/bin/guile
guile: warning: failed to install locale
warning: failed to install locale: Invalid argument
GNU Guile 2.2.4
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

bug#35872: messages that are redundant can be eliminated?

[Andy Tai]

on my guix installation (on an Ubuntu system but that detail should not
matter)

after running

%guix pull && guix package -u

these were printed:

...
New in this revision:
  ...
hint: Run `guix pull --news' to view the complete list of package changes.

hint: After setting `PATH', run `hash guix' to make sure your shell refers
to `/home/.../.config/guix/current/bin/guix'.

guix package: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

The following packages will be upgraded:
   glibc-locales 2.28 → 2.28
/gnu/store/acl2wxzzkkcjv74rlqswdf9p8pwddlmk-glibc-locales-2.28
   meson 0.50.0 → 0.50.0
/gnu/store/zc6r8b1rx3q7lqd8kvvpnm38ky925kmj-meson-0.50.0
   guile 2.2.4 → 2.2.4
/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4
   font-adobe-source-han-sans:cn 1.004 → 1.004
/gnu/store/zf59mg6g0afay9458aarh0rqcz852hhb-font-adobe-source-han-sans-1.004-cn
   fontconfig 2.13.1 → 2.13.1
/gnu/store/cnafj0dn09qzy23xnrrjsq5zcdj4739j-fontconfig-2.13.1
   epiphany 3.28.3.1 → 3.28.3.1
/gnu/store/n56bdjhqgq7a4a6ndqc3aymyrzvs12hl-epiphany-3.28.3.1
   gnome-terminal 3.28.2 → 3.28.2
/gnu/store/r6i61wji0qmv9fqdyk65kx73nzxw8v80-gnome-terminal-3.28.2

nothing to be done

Now there seems nothing to be done during the guix package -u step so these
messages
glibc-locales 2.28 → 2.28...
were confusing and probably not necessary?

bug#35856: Unable to boot on iMac, likely because of UUIDs

[pelzflorian (Florian Pelz)]

On Thu, May 23, 2019 at 10:18:27PM +0200, pelzflorian (Florian Pelz) wrote:
> I will mention your observations on UUIDs on the
> grub-devel mailing list.
>

No, I will not report there.  They know enough.

bug#35856: Unable to boot on iMac, likely because of UUIDs

[pelzflorian (Florian Pelz)]

On Thu, May 23, 2019 at 03:12:44PM +0200, Francisco Gómez wrote:
> Built an image after doing `guix pull`, it works! Thanks!
> 

Thank you for reporting back.  Please respond to 35...@debbugs.gnu.org
as well next time.  I will mention your observations on UUIDs on the
grub-devel mailing list.

Regards,
Florian

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[Jesse Gibbons]

(from the digest)
>Date: Thu, 23 May 2019 17:31:38 +0200
>From: "pelzflorian (Florian Pelz)" 
>To: Ricardo Wurmus 
>Cc: 35...@debbugs.gnu.org
>Subject: bug#35864: ~/.local/bin is missing in default PATH on Guix
>   System
>Message-ID: <20190523153138.6kspxwfzeisntll5@pelzflorian.localdomain>
>Content-Type: text/plain; charset=us-ascii
>
>[...]
>
>Adding ~/.local/bin to the PATH is common on other distros.  When
>compiling and installing software as a user without making a package
>for it, I want to configure it with --prefix=$HOME/.local so I can
>install without sudo.  Then I want to be able to run:
>
>myprog
>
>instead of
>
>PATH=$HOME/.local/bin myprog
>
>In particular, I want instructions to work on all distros, even though
>Debian failed/fails to do this at the moment too.
>
>Regards,
>Florian
>

I personally think including $HOME/.local/bin in PATH by default is
unnecessary because the Guix package manager lets non-root users
install packages and installs from source with the --no-substitutes
option. However if some people don't want take the time to write and
debug a package definition for programs they want to install that are
not included in guix by default, installing to $HOME/.local remains a
valid option.

The simplest way to resolve this is probably to include it in the
skeleton folder in your OS definition (flexible design FTW, am I
right?). Maybe there can be a service to allow this option without
everyone who wants it writing the code themselves?

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[Tobias Geerinckx-Rice]

pelzflorian (Florian Pelz) wrote:

That link doesn't support adding (or not adding) it.


The people who responded accept that it is a bug in Ubuntu.


Whoa!  This is not a fair summary.  The only ‘bug’ there is that 
Ubuntu (and RHEL's?) *implementation* was buggy, nothing more.


Nowhere is it implied that a distribution not adding .local/bin to 
people's PATH is in any way ’buggy’.


Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[Tobias Geerinckx-Rice]

pelzflorian (Florian Pelz) wrote:

Adding ~/.local/bin to the PATH is common on other distros.


This is what still needs to be established: is it?  Which ones? 
Is it merely a side-effect of them using systemd?  And most 
crucially: does it mean that Guix needs to add it too?  What about 
~/bin?


I'm was just interested in the (ideally: your) arguments for doing 
so, not a link to a discussion site.  If it really breaks things 
that should work, I'm all in favour of adding it to the default 
skeleton, if not /etc/profile itself.


When compiling and installing software as a user without making 
a package
for it, I want to configure it with --prefix=$HOME/.local so I 
can

install without sudo.  Then I want to be able to run:

myprog

instead of

PATH=$HOME/.local/bin myprog


You can already easily add custom directories to $PATH in your 
.bash_profile, if my understanding of bash's complicated set of 
configuration files is still accurate.  That's where I set it, 
anyway:


 ~ λ grep PATH= .bash_profile 
 PATH="$HOME/.local/bin:$PATH"


and it's always worked fine.  :-)

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[pelzflorian (Florian Pelz)]

On Thu, May 23, 2019 at 04:55:28PM +0200, Tobias Geerinckx-Rice wrote:
> > .
> 
> That link doesn't support adding (or not adding) it.
> 

The people who responded accept that it is a bug in Ubuntu.

Regards,
Florian

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[pelzflorian (Florian Pelz)]

On Thu, May 23, 2019 at 04:17:38PM +0200, Ricardo Wurmus wrote:
> 
> pelzflorian (Florian Pelz)  writes:
> 
> > ~/.local/bin should be added to the PATH environment variable by
> > default, see
> > .
> 
> They say that this is specified in the systemd file-hierarchy
> specification.  We already ignore most of this specification (see any
> entry mentioning /usr, for example).
> 
> I think we can safely ignore this specification.
> 


Adding ~/.local/bin to the PATH is common on other distros.  When
compiling and installing software as a user without making a package
for it, I want to configure it with --prefix=$HOME/.local so I can
install without sudo.  Then I want to be able to run:

myprog

instead of

PATH=$HOME/.local/bin myprog

In particular, I want instructions to work on all distros, even though
Debian failed/fails to do this at the moment too.

Regards,
Florian

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[Tobias Geerinckx-Rice]

pelzflorian (Florian Pelz) wrote:

~/.local/bin should be added to the PATH environment variable by
default, see


So ~/.local/bin is a relatively recent systemd thing[1], replacing 
the conventional ~/bin.


My theory is that it's intended for users of graphical file 
browsers (where the traditional ~/bin is a bit too prominent even 
for my tastes), but I use it too.


It's trivial to augment $PATH yourself, whether or not your 
distribution is systemd-based.



.


That link doesn't support adding (or not adding) it.

Kind regards,

T G-R

[1]: 
https://www.freedesktop.org/software/systemd/man/file-hierarchy.html


signature.asc
Description: PGP signature

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[Ricardo Wurmus]

pelzflorian (Florian Pelz)  writes:

> ~/.local/bin should be added to the PATH environment variable by
> default, see
> .

They say that this is specified in the systemd file-hierarchy
specification.  We already ignore most of this specification (see any
entry mentioning /usr, for example).

I think we can safely ignore this specification.

--
Ricardo

bug#35865: compute-guix-derivation failed to compute the derivation for Guix

[Keith Thompson]

I'm running Guix, installed from guix-system-install-1.0.1.x86_64-linux.iso,
in a VirtualBox VM.  I encountered an error running "guix pull". A very quick
look at the mailing list archives suggests that this may be similar to
 bug#35723.

Output:

$ guix pull
Migrating profile generations to '/var/guix/profiles/per-user/kst'...
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   ea54133
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
1.8 MB will be downloaded:
   /gnu/store/rq5hbb52rv7i9p86kqwd2as4hm8sa1fd-compute-guix-derivation
   /gnu/store/aczwfrfb0s7glkizqs524ssh6ih0vq24-module-import
   /gnu/store/jgs3ahcnslhjgla1b5m2pxclkpb2110d-module-import-compiled
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
downloading from
https://ci.guix.gnu.org/nar/gzip/cb1q91aqw07hkryc6z78sl6sqbzra6hs-config.scm...
 config.scm  503B

   112KiB/s 00:00 [##] 100.0%

downloading from
https://ci.guix.gnu.org/nar/gzip/7aw8rli88rhhvgfga9j6bv4fg70aq498-git.scm...
 git.scm  101B

 6KiB/s 00:00 [##] 100.0%

downloading from
https://ci.guix.gnu.org/nar/gzip/qc2q3yfm6z282igf4nh5hl2pv18jscrk-hash.scm...
 hash.scm  132B

17KiB/s 00:00 [##] 100.0%

downloading from
https://ci.guix.gnu.org/nar/gzip/aczwfrfb0s7glkizqs524ssh6ih0vq24-module-import...
 module-import  2KiB

   282KiB/s 00:00 [##] 100.0%

downloading from
https://ci.guix.gnu.org/nar/gzip/jgs3ahcnslhjgla1b5m2pxclkpb2110d-module-import-compiled...
 module-import-compiled  1.8MiB

   1.5MiB/s 00:01 [##] 100.0%

downloading from
https://ci.guix.gnu.org/nar/gzip/rq5hbb52rv7i9p86kqwd2as4hm8sa1fd-compute-guix-derivation...
 compute-guix-derivation  854B

   138KiB/s 00:00 [##] 100.0%

Computing Guix derivation for 'x86_64-linux'... |@ substituter-started
/gnu/store/mn3ymm3f2r4xjqf8m9fgmadh6b8p6fvr-glibc-utf8-locales-2.28
/gnu/store/ncknl03pkmamrxg7q9nxi1rn1qhvwbi9-guix-1.0.1/libexec/guix/substitute
|guix substitute: error: connect: Connection timed out
@ substituter-failed
/gnu/store/mn3ymm3f2r4xjqf8m9fgmadh6b8p6fvr-glibc-utf8-locales-2.28
256 fetching path
`/gnu/store/mn3ymm3f2r4xjqf8m9fgmadh6b8p6fvr-glibc-utf8-locales-2.28'
failed with exit code 1
@ substituter-started
/gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1
/gnu/store/ncknl03pkmamrxg7q9nxi1rn1qhvwbi9-guix-1.0.1/libexec/guix/substitute
killing process 1578
killing process 1578: No such process
\Backtrace:
In ./guix/store.scm:
   1667:8 19 (_ _)
In ./guix/gexp.scm:
708:2 18 (_ _)
In ./guix/monads.scm:
482:9 17 (_ _)
In ./guix/gexp.scm:
   573:13 16 (_ _)
In ./guix/store.scm:
   1667:8 15 (_ _)
In ./guix/gexp.scm:
   1139:2 14 (_ _)
In ./guix/monads.scm:
482:9 13 (_ _)
In ./guix/gexp.scm:
   1136:6 12 (_ _)
In ./guix/store.scm:
   1667:8 11 (_ _)
In ./guix/gexp.scm:
708:2 10 (_ _)
In ./guix/monads.scm:
482:9  9 (_ _)
In ./guix/gexp.scm:
   573:13  8 (_ _)
In ./guix/store.scm:
   1667:8  7 (_ _)
   1667:8  6 (_ _)
  1690:38  5 (_ #)
In ./guix/packages.scm:
   936:16  4 (cache! # # ?)
In ./guix/grafts.scm:
314:4  3 (graft-derivation # # # ?)
192:4  2 (references-oracle # #)
   201:20  1 (_ _ _)
In ./guix/store.scm:
  1203:15  0 (_ # _ _)

./guix/store.scm:1203:15: Throw to key `srfi-34' with args
`(#)'.
guix pull: error: You found a bug: the program
'/gnu/store/rq5hbb52rv7i9p86kqwd2as4hm8sa1fd-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"ea54133367aad77a9e941fba18fe57ab3e1ab5d9"; system: "x86_64-linux";
host version: "1.0.1"; pull-version: 1).
Please report it by email to .

bug#35864: ~/.local/bin is missing in default PATH on Guix System

[pelzflorian (Florian Pelz)]

~/.local/bin should be added to the PATH environment variable by
default, see
.

Regards,
Florian

bug#35863: `guix import hackage random` fails due to mysterious CRLF-related trouble

[Robert Vollmert]

$ curl http://hackage.haskell.org/package/random-1.1/random.cabal > random.cabal
$ guix import hackage -s < random.cabal
 (at line 49, column 0)d token : 
Syntax error: unexpected end of input
guix import: error: failed to import cabal file from standard input
$ tr -d '\r'  < random.cabal | guix import hackage -s
(package …)

There’s nothing obviously wrong in the cabal file around line 49. The file seems
to have consistent CRLF line endings and doesn’t seem to have any non-ASCII
characters. (I can see that `canonical-newline-port` might well be buggy around
UTF8.)