Re: After installing Java, what should I set JAVA_HOME to?

[Chris Marusich]

Hi Zachary,

Zachary Kanfer  writes:

> I want Guix to be widely adopted, because I think it's a really cool
> piece of software that deserves more support. To that end, I want to
> write about how high switching costs "use Guix for everything" has,
> and how much I think Guix adoption will be harmed by this advice.

I agree with Ludo' when he says that "Guix shouldn't’t force you to use a
different kind of fork."  You ought to be able to install Java using
Guix, install Gradle using some other mechanism, and then use the Java
from Guix to build Gradle projects.  This is a reasonable thing to want
to do, especially since so much Java support is missing from Guix today.

However, in the long term, I believe the day will come when Guix can be
used to manage all (or at least most) of the stuff that something like
Gradle does today.  I hope that on that day, instead of using an
alternative like Gradle, we'll be able to develop our Java projects
using Guix, build them using Guix, and deploy them using Guix.  Java
developers will be able to enjoy all the benefits of Guix.  But unless
people contribute in this area, that day won't come quickly.  That's why
I asked you in my original email: "What's stopping you from using Guix
to do it [to build your project]?"  I wasn't criticizing you for using
Gradle; I was inviting you to help us figure out where the remaining
gaps are and how we can fill them in.

In the end, were you able to get Java from Guix working with Gradle?

-- 
Chris


signature.asc
Description: PGP signature

Re: locale warning and postgresql

[Leo Famulari]

On Tue, Nov 29, 2016 at 12:53:59AM +, Myles English wrote:
> 
> on [2016-11-28] at 23:37 Myles English writes:
> 
> > $ initdb --locale=en_GB -E UTF8 -D '/home/myles/pgdata-guix'
> > The files belonging to this database system will be owned by user "myles".
> > This user must also own the server process.
> >
> > initdb: invalid locale name "en_GB"
> 
> Excuse my arrogance, I thought that en_GB was important enough to make
> it into glibc-utf8-locales.  After installing glibc-locales it works.

Glibc-ut8-locales is a small subset of glibc-locales. It's partially
intended for test environments, where using the full set of locales
could be impractical:

$ guix size glibc-utf8-locales
store item   totalself
/gnu/store/bhj5xdwwd2dg770lmlks7hyny8vzjm9x-glibc-utf8-locales-2.24 6.3 
6.3 100.0%
total: 6.3 MiB
$ guix size glibc-locales 
store item   totalself
/gnu/store/hyi7svs0ds79wrcg5l0nr36zzjikqj7i-glibc-locales-2.24 474.5   
474.5 100.0%
total: 474.5 MiB

Almost two orders of magnitude difference!

Re: locale warning and postgresql

[Myles English]

on [2016-11-28] at 23:37 Myles English writes:

> $ initdb --locale=en_GB -E UTF8 -D '/home/myles/pgdata-guix'
> The files belonging to this database system will be owned by user "myles".
> This user must also own the server process.
>
> initdb: invalid locale name "en_GB"

Excuse my arrogance, I thought that en_GB was important enough to make
it into glibc-utf8-locales.  After installing glibc-locales it works.

Myles

Re: locale warning and postgresql

[Myles English]

on [2016-11-28] at 21:47 Alex Kost writes:

> Ludovic Courtès (2016-11-28 21:48 +0100) wrote:
>
>> Hi Myles,
>>
>> Myles English  skribis:
>>
>>> I have always had trouble with my locale after installing guix on Arch
>>> Linux (with zsh and a basic window manager, bspwm).  I have set
>>> GUIX_LOCPATH in ~/.zshenv and it appears correct in my shell.  The
>>> system-wide locale looks right.  When I install postgresql it gives the
>>> usual "warning: failed to install locale: Invalid argument".  When I try
>>> to initialise a database cluster, passing the locale doesn't work.
>>>
>>> Does anyone using Arch Linux and a basic WM know which file to put
>>> GUIX_LOCPATH in so that the warning goes away?
>>>
>>> How can I find out what guix thinks its locale is or what are available?
>>>
>>> Is there a way to use initdb even though there is a locale warning?
>>>
>>> Shell experiments:
>>>
>>> $ locale
>>> LANG=en_GB.UTF-8
>>> LC_CTYPE="en_GB.UTF-8"
>>> LC_NUMERIC="en_GB.UTF-8"
>>> LC_TIME="en_GB.UTF-8"
>>> LC_COLLATE="en_GB.UTF-8"
>>> LC_MONETARY="en_GB.UTF-8"
>>> LC_MESSAGES="en_GB.UTF-8"
>>> LC_PAPER="en_GB.UTF-8"
>>> LC_NAME="en_GB.UTF-8"
>>> LC_ADDRESS="en_GB.UTF-8"
>>> LC_TELEPHONE="en_GB.UTF-8"
>>> LC_MEASUREMENT="en_GB.UTF-8"
>>> LC_IDENTIFICATION="en_GB.UTF-8"
>>> LC_ALL=
>>>
>>> $ echo $GUIX_LOCPATH
>>> /home/myles/.guix-profile/lib/locale
>>
>> What does “ls $GUIX_LOCPATH/2.24” show?
>>
>> You must make sure you have the ‘glibc-locales’ or ‘glibc-utf8-locales’
>> that correspond to the glibc version of the program you are using (if
>> you just installed postgresql, it’s using glibc 2.24.)
>>
>> Then you need to make sure GUIX_LOCPATH is set both in the environment
>> of the postgresql daemon, and in the environment of the commands you
>> invoke (initdb, etc.).
>
> Including the guix-daemon, as this warning:
>
>>> $ guix package -i postgresql
>>> warning: failed to install locale: Invalid argument
>>> The following package will be upgraded:
>>>postgresql   9.5.3 -> 9.5.3  
>>> /gnu/store/sfgg20a7jnwfisajsvqdijjm2zj905az-postgresql-9.5.3
>
> comes from the daemon, so make sure your "guix-daemon.service" has a
> line like this:
>
>   Environment=GUIX_LOCPATH=/root/.guix-profile/lib/locale

Thank you, I hadn't installed glibc-utf8-locales for root.  Perhaps this
step could be added to the documentation in "2.6.1 Locales"?

I also might have been using --locale wrong but I still can't get initdb
to use one:


$ initdb --locale=en_GB -E UTF8 -D '/home/myles/pgdata-guix'
The files belonging to this database system will be owned by user "myles".
This user must also own the server process.

initdb: invalid locale name "en_GB"


$ initdb --locale=en_GB.UTF-8 -E UTF8 -D '/home/myles/pgdata-guix'
The files belonging to this database system will be owned by user "myles".
This user must also own the server process.

initdb: invalid locale name "en_GB.UTF-8"


$ initdb -D '/home/myles/pgdata-guix'
The files belonging to this database system will be owned by user "myles".
This user must also own the server process.

initdb: invalid locale settings; check LANG and LC_* environment
variables


Any ideas?

Myles

Re: locale warning and postgresql

[Alex Kost]

Ludovic Courtès (2016-11-28 21:48 +0100) wrote:

> Hi Myles,
>
> Myles English  skribis:
>
>> I have always had trouble with my locale after installing guix on Arch
>> Linux (with zsh and a basic window manager, bspwm).  I have set
>> GUIX_LOCPATH in ~/.zshenv and it appears correct in my shell.  The
>> system-wide locale looks right.  When I install postgresql it gives the
>> usual "warning: failed to install locale: Invalid argument".  When I try
>> to initialise a database cluster, passing the locale doesn't work.
>>
>> Does anyone using Arch Linux and a basic WM know which file to put
>> GUIX_LOCPATH in so that the warning goes away?
>>
>> How can I find out what guix thinks its locale is or what are available?
>>
>> Is there a way to use initdb even though there is a locale warning?
>>
>> Shell experiments:
>>
>> $ locale
>> LANG=en_GB.UTF-8
>> LC_CTYPE="en_GB.UTF-8"
>> LC_NUMERIC="en_GB.UTF-8"
>> LC_TIME="en_GB.UTF-8"
>> LC_COLLATE="en_GB.UTF-8"
>> LC_MONETARY="en_GB.UTF-8"
>> LC_MESSAGES="en_GB.UTF-8"
>> LC_PAPER="en_GB.UTF-8"
>> LC_NAME="en_GB.UTF-8"
>> LC_ADDRESS="en_GB.UTF-8"
>> LC_TELEPHONE="en_GB.UTF-8"
>> LC_MEASUREMENT="en_GB.UTF-8"
>> LC_IDENTIFICATION="en_GB.UTF-8"
>> LC_ALL=
>>
>> $ echo $GUIX_LOCPATH
>> /home/myles/.guix-profile/lib/locale
>
> What does “ls $GUIX_LOCPATH/2.24” show?
>
> You must make sure you have the ‘glibc-locales’ or ‘glibc-utf8-locales’
> that correspond to the glibc version of the program you are using (if
> you just installed postgresql, it’s using glibc 2.24.)
>
> Then you need to make sure GUIX_LOCPATH is set both in the environment
> of the postgresql daemon, and in the environment of the commands you
> invoke (initdb, etc.).

Including the guix-daemon, as this warning:

>> $ guix package -i postgresql
>> warning: failed to install locale: Invalid argument
>> The following package will be upgraded:
>>postgresql9.5.3 -> 9.5.3  
>> /gnu/store/sfgg20a7jnwfisajsvqdijjm2zj905az-postgresql-9.5.3

comes from the daemon, so make sure your "guix-daemon.service" has a
line like this:

  Environment=GUIX_LOCPATH=/root/.guix-profile/lib/locale

-- 
Alex

Problems adding multiple file systems (e.g., /home partition)

[Daniel Drake]

Hi all.

I'm transitioning from arch to guixsd.  I've built off of the 
bare-bones.scm example, but I'm having trouble adding a second file 
system (my home partition).  Without a dependency argument to ensure 
that root gets mounted prior to home, the system fails to boot to a prompt.


I've noted the dependencies member of the file-system object:  "This is 
a list of  objects representing file systems that must be 
mounted before (and unmounted after) this one."


In the preamble, I define the root file-system:

  (define vol-root (file-system  (device "vol-root")  (title 'label) 
(mount-point "/")  (type "ext4")))


Then I add the root file system to the file-systems list, along with the 
file-system for the home directory:


  (operating-system
...
(file-systems
  (cons*
vol-root
(file-system  (device "vol-home")  (title 'label)  (mount-point 
"/home")  (type "ext4")  (dependencies '(vol-root)) )

%base-file-systems))
...

When I try to instantiate (via guix system init /mnt/etc/config.scm 
/mnt), I get a multi-line error that states:
  gnu/services/base.scm:255:2: In procedure 
dependency->shepherd-service-name:
  gnu/services/base.scm:225:2: Throw to key 'match-error' with args 
`("match" "no matching pattern" vol-root)'.



I found a related issue in one of the IRC logs that modified the 
dependencies argument like this:

  (dependencies (list vol-root))
within the file-system object for the home directory.
In that instance, the error seems almost resolvable:
guix system: error: `file-system-/home' requires 'file-system-/', which 
is not provided by any service


In this case, it seems like the service that mounts root has not been 
created at the point that the home directory service needs it.


If anyone can shed some light into what actually needs to be placed in 
the dependencies list, that would be quite helpful.  I'm new to guile, 
but I've done some hacking in emacs-lisp.


Thank you.
- Daniel

Re: locale warning and postgresql

[Ludovic Courtès]

Hi Myles,

Myles English  skribis:

> I have always had trouble with my locale after installing guix on Arch
> Linux (with zsh and a basic window manager, bspwm).  I have set
> GUIX_LOCPATH in ~/.zshenv and it appears correct in my shell.  The
> system-wide locale looks right.  When I install postgresql it gives the
> usual "warning: failed to install locale: Invalid argument".  When I try
> to initialise a database cluster, passing the locale doesn't work.
>
> Does anyone using Arch Linux and a basic WM know which file to put
> GUIX_LOCPATH in so that the warning goes away?
>
> How can I find out what guix thinks its locale is or what are available?
>
> Is there a way to use initdb even though there is a locale warning?
>
> Shell experiments:
>
> $ locale
> LANG=en_GB.UTF-8
> LC_CTYPE="en_GB.UTF-8"
> LC_NUMERIC="en_GB.UTF-8"
> LC_TIME="en_GB.UTF-8"
> LC_COLLATE="en_GB.UTF-8"
> LC_MONETARY="en_GB.UTF-8"
> LC_MESSAGES="en_GB.UTF-8"
> LC_PAPER="en_GB.UTF-8"
> LC_NAME="en_GB.UTF-8"
> LC_ADDRESS="en_GB.UTF-8"
> LC_TELEPHONE="en_GB.UTF-8"
> LC_MEASUREMENT="en_GB.UTF-8"
> LC_IDENTIFICATION="en_GB.UTF-8"
> LC_ALL=
>
> $ echo $GUIX_LOCPATH
> /home/myles/.guix-profile/lib/locale

What does “ls $GUIX_LOCPATH/2.24” show?

You must make sure you have the ‘glibc-locales’ or ‘glibc-utf8-locales’
that correspond to the glibc version of the program you are using (if
you just installed postgresql, it’s using glibc 2.24.)

Then you need to make sure GUIX_LOCPATH is set both in the environment
of the postgresql daemon, and in the environment of the commands you
invoke (initdb, etc.).

HTH!

Ludo’.

Re: After installing Java, what should I set JAVA_HOME to?

[Hartmut Goebel]

Hi,

as Ricardo already wrote, bootstrapping Java packages from source is a
nightmare since gradle requires itself for building. And it requires a
lot of other Java packages which again require gradle for building. This
Gordian Knot can be cut by someone brave and knowledgeable about the
.pom files or whatever is the Java-way for describing the build-process.

I tried doing some work on this and gave up.

Am 28.11.2016 um 06:15 schrieb Zachary Kanfer:
> means that I can no longer follow any tutorial I find, since the
> tutorials I'm using are Gradle and Clojure tutorials

When using gradle for building your software, you should be able to
follow the tutorial. Yo only need to install gradle itself from (what
they call) "source.

-- 
Regards
Hartmut Goebel

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

Re: StumpWM package doesn't work

[Ludovic Courtès]

Andy Patterson  skribis:

> On Sun, 27 Nov 2016 21:43:23 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> iyzs...@member.fsf.org (宋文武) skribis:
>> 
>> > Toni Reina  writes:
>> >  
>> >> Hello,
>> >>
>> >> I'm trying to install `sbcl-stumpwm` package and looks like it
>> >> doesn't work correctly. It's installed with no errors, but it
>> >> doesn't generate the stumpwm binary file.
>> >>
>> >> The following package will be installed:
>> >>sbcl-stumpwm
>> >> 0.9.9   /gnu/store/z92ri0kgjdavkp7llav1db0dia44sbid-sbcl-stumpwm-0.9.9
>> >>
>> >> ls /gnu/store/z92ri0kgjdavkp7llav1db0dia44sbid-sbcl-stumpwm-0.9.9  
>> >> -> lib  share  
>> >>  
>> >
>> > It's in the "bin" output of sbcl-stumpwm package, you can get it
>> > with:
>> >
>> > guix package -i sbcl-stumpwm:bin  
>> 
>> It might be clearer to have an “out” and a “lib” output (instead of
>> “bin” and “out”).  WDYT, Andy & 宋文武?
>
> I think that would basically shift the awkwardness from package
> installation over to package development, since it would then be
> required that all dependants of stumpwm use the lib output in the
> inputs field (but only on sbcl? - since ecl binaries aren't supported
> just yet). 

OK but there’s only one dependent:

--8<---cut here---start->8---
$ guix refresh -l sbcl-stumpwm
A single dependent package: sbcl-stumpwm-with-slynk-0.9.9
--8<---cut here---end--->8---

So I think it would be preferable to do it the way I suggest, no?

> I think the best way to clarify things would be to merge the outputs,
> although this carries a ~61MiB (~11MiB compressed) extra cost. In the
> case of stumpwm, I guess that the library isn't all that useful without
> the binary, so that might be ok.

Could be an option, but not great.

> Another alternative would be to create a separate package like with
> sbcl-stumpwm-with-slynk.
>
> I think what might be at the root of the issue though is that multiple
> outputs aren't discoverable enough. The page at
>  doesn't list them
> AFAICT, and entering guix package -i sbcl-stumpwm into a shell and
> mashing tab only lists one entry for the package, when I think it
> should be two.

Good points!  We can certainly address these two issues quite easily.

Thanks for your feedback!

Ludo’.