Re: Python 3.5 start of update

[Diane Trout]

Hello,

Thank you for getting back to me.

> Also, the 'python-minimal' offered by `guix environment python-
> minimal`
> is likely the one that lives on the master branch, deployed by `guix
> pull`, unless you symlinked your git checkout to
> '~/.config/guix/latest'.
> 

I remembered --pure, but I keep forgetting the .config/guix/latest
symlink gets updated fairly frequently.

> Could you try something like this, having checked out the branch
> where
> you are attempting this upgrade:
> 
> `~/src/guix/pre-inst-env guix environment --pure python-minimal`
> 
> I would suggest '--container' but you'd have to make some changes to
> your system if you are on Debian.

I switched to trying to do this on a GuixSD VM.

With pre-inst-env guix environment --pure python-minimal I managed to
get an environment, and figured out some of the config flags from a run
of guix build python-minimal

Whats output in the build log looks like:

(environment variables setting path to bash that I didn't copy) 
--prefix=/gnu/store/wj1b0simlx4s9vdksc297043cg7ah9gf-python-minimal-3.5.1 
--enable-shared 
LDFLAGS=-Wl,-rpath=/gnu/store/wj1b0simlx4s9vdksc297043cg7ah9gf-python-minimal-3.5.1/lib
 --without-system-ffi

Does guix sort the config flags somehow? I wasn't sure if the LDFLAGS
could be defined between --arguments.

I had a list of several things I tried that didn't work but then I
asked why is python-minimal using --without-system-ffi? It occurred to
me to try building it with libffi and --with-system-ffi, and that
wonderfully did build. 

I hope this stream of consciousness made some sense. If --without-
system-ffi isn't actually important I can clean up the patch and submit
it after I've gotten some sleep.

(Mostly my previous patch plus commented out the current python-minimal 
(arguments...) and adding ("libffi" ,libffi) to the inputs)

Diane

Re: R packages do not show up as requisites

[Pjotr Prins]

On Sat, Mar 05, 2016 at 12:30:06AM +0100, Ludovic Courtès wrote:
> Pjotr Prins  skribis:
> 
> > Funny thing,
> >
> >   guix gc -R path
> >
> > on a package that has python modules and R packages as inputs only the
> > python inputs show up. Try for example r-munsell which has
> > r-colorspace as an input:
> >
> >   ./pre-inst-env guix package -i r-munsell
> >
> >r-munsell0.4.2 → 0.4.2 
> > /gnu/store/kwhzqrpcm8agl8q2v9n19rss060xs2j4-r-munsell-0.4.2
> >
> >   ./pre-inst-env guix gc -R 
> > /gnu/store/kwhzqrpcm8agl8q2v9n19rss060xs2j4-r-munsell-0.4.2
> >
> > Niente, nop, nada. 
> 
> That’s because r-munsell does not explicitly refer to r-colorspace.
> Instead, r-colorspace is a propagated input of r-munsell, and propagated
> inputs are something taken into account when building the profile (see
> the ‘manifest’ file in there), but not other at the lower levels.

It is funny how my misconceptions trip me up :). I thought inputs were
treated as dependencies. So, if I were to write a package I would have
to include r-colorspace both as an input AND a propagated input? From
your description that won't help (I actually tried, it does not)
because there are no *explicit* links inside the package. 

It is very interesting and relevant to Ruby and R packages because
they don't use the full store paths explicitly. I need to check how
python does include them (they appear to work), maybe Ricardo was
thinking about that too in the earlier discussions on builds.

It also explains why they did not show up in the generated SVG graphs.

You see, I noted these things, but it did not register as a problem
until I tried to archive :)

> > My problem is now that 'guix archive' won't include R modules because
> > they are not listed as requisites.
> >
> > Is there an easy fix?
> 
> You could do, say:
> 
>   guix package -i r-munsell -p foo
>   guix archive --export $(readlink foo) > t.nar
> 
> HTH!

Yes, that will help.

Pj.

Re: Guix vs GuixSD

[myglc2]

myglc2  writes: (paraphrased)

> I started experimenting with Nix and NixOS 6 weeks ago. 3 weeks ago I
> switched to guixSD. I found it difficult to determine exactly which
> parts of the volumminous (and tasty) Guix doc to read. To clarify my
> thoughts, I made diagrams of Guix and GuixSD. I intended to show the
> differences between Guix and GuixSD, but frankly, they seemed more
> alike than not.

+ 2.5 weeks ==> another diagram of the Guix-verse.

Comments?  Corrections?  TIA - George



guixvssd2.dot
Description: Binary data

Re: [PATCH 04/13] utils: Use '@' for separating package names and version numbers.

[Nils Gillmann]

l...@gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin  skribis:
>> +*** New syntax for separating package names and version numbers
>> +
>> +Use ‘@’ instead of ‘-’ as a separator.  This new separator is a reserved
>^^
> Maybe add: “, as in ‘gnupg@2.0’.”
>
>> +character which is not allowed both in package names and version numbers.
>
> Maybe add:
>
>   The old syntax to specify a package’s version—e.g., as “gnupg-2.0—is
>   obsolete and support for it will be removed in the future.
>
> OK with changes along these lines.
>
> Thanks a lot!  This closes another item towards 0.9.1.  \o/
>
> Ludo’.

I read through this, and I think I have to read the whole thread
again. So the new 0.9.1 way for writing $PN-$PV is no longer "-"
but "@" as in libreoffice@10.0.0 ? Or is this simply a hydra
/ some other part of architecture thing?


-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

Re: [PATCH 04/13] utils: Use '@' for separating package names and version numbers.

[Mathieu Lirzin]

l...@gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin  skribis:
>
>> The concern of backward compability that Ludo raised, have made the work
>> more challenging than changing things in place.  As a consequence it was
>> not clear to me what should/can change or not.  To keep my mind clear, I
>> have decided to leave the emacs part unchanged.  So the true reason is
>> exhaustion.  :)
>
> Sorry that this had this effect!

not Breaking "userspace" is a valid concern that deserves care.  so
please don't be sorry.

-- 
Mathieu Lirzin

Re: fonts.scm -> packaging "un-fonts", download isses

[Andreas Enge]

On Fri, Mar 04, 2016 at 12:53:39PM +0100, Nils Gillmann wrote:
> What counts for us is what we deliver, therefore the version
> packaged, therefore GPL2 with no exception.

gpl2+, unless the "upgrade" is explicitly excluded in the package
(the license itself allows to upgrade it otherwise).

Andreas

Vigra and libreoffice

[Andreas Enge]

Hello,

the attached patch updates vigra to a recent git snapshot. Yesterday I
had created an additional package vigra-rc, but since the current vigra
does not build any more, I think we may as well replace it. If I got the
version numbers right, things should update smoothly to this vigra and
later to 1.11.0.

With yesterday's package libreoffice built correctly. Since today vigra
rebuilt, I am trying it once again to be sure and will let a build of
libreoffice run overnight.

Till then, I am taking comments.

Andreas

>From f5085b66675f84d6118d5019ce941e2fcd2f6fcc Mon Sep 17 00:00:00 2001
From: Andreas Enge 
Date: Sat, 5 Mar 2016 00:30:56 +0100
Subject: [PATCH] gnu: vigra: Update to a development snapshot.

* gnu/packages/image.scm (vigra): Update to a git snapshot to fix build
  problems with the current python-numpy.
---
 gnu/packages/image.scm | 105 ++---
 1 file changed, 55 insertions(+), 50 deletions(-)

diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index f287054..2d2f0f2 100644
--- a/gnu/packages/image.scm
+++ b/gnu/packages/image.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2013, 2015 Andreas Enge 
+;;; Copyright © 2013, 2015, 2016 Andreas Enge 
 ;;; Copyright © 2014, 2015, 2016 Mark H Weaver 
 ;;; Copyright © 2014, 2015 Alex Kost 
 ;;; Copyright © 2014 Ricardo Wurmus 
@@ -44,6 +44,7 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system cmake)
   #:use-module (srfi srfi-1))
@@ -545,58 +546,62 @@ graphics image formats like PNG, BMP, JPEG, TIFF and 
others.")
(home-page "http://freeimage.sourceforge.net";)))
 
 (define-public vigra
-  (package
-   (name "vigra")
-   (version "1.10.0")
-   (source
- (origin
-   (method url-fetch)
-   (uri (string-append "https://hci.iwr.uni-heidelberg.de/vigra/vigra-";
-   version "-src.tar.gz"))
-   (sha256 (base32
- "16d0jvz3k49niljg9qvvlyxxl15yk0300xkymvyznlmvn1hs7m22"
-   (build-system cmake-build-system)
-   (inputs
-`(("boost" ,boost)
-  ("fftw" ,fftw)
-  ("fftwf" ,fftwf)
-  ("hdf5" ,hdf5)
-  ("ilmbase" ,ilmbase) ; propagated by openexr, but needed explicitly
-   ; to create a configure-flag
-  ("libjpeg" ,libjpeg)
-  ("libpng" ,libpng)
-  ("libtiff" ,libtiff)
-  ("openexr" ,openexr)
-  ("python" ,python-2) ; print syntax
-  ("python2-numpy" ,python2-numpy)
-  ("zlib" ,zlib)))
-   (native-inputs
-`(("doxygen" ,doxygen)
-  ("python2-nose" ,python2-nose)
-  ("python2-sphinx" ,python2-sphinx)))
-   (arguments
-`(#:test-target "check"
-  #:configure-flags
-(list "-Wno-dev" ; suppress developer mode with lots of warnings
-  (string-append "-DVIGRANUMPY_INSTALL_DIR="
- (assoc-ref %outputs "out")
- "/lib/python2.7/site-packages")
-  ;; OpenEXR is not enabled by default.
-  "-DWITH_OPENEXR=1"
-  ;; The header files of ilmbase are not found when included
-  ;; by the header files of openexr, and an explicit flag
-  ;; needs to be set.
-  (string-append "-DCMAKE_CXX_FLAGS=-I"
- (assoc-ref %build-inputs "ilmbase")
- "/include/OpenEXR"
-   (synopsis "Computer vision library")
-   (description
-"VIGRA stands for Vision with Generic Algorithms.  It is an image
+  (let ((commit "a378732"))
+(package
+ (name "vigra")
+ (version (string-append "1.10.0-1-" commit))
+ (source
+  (origin
+   (method git-fetch)
+   (uri (git-reference
+ (url "https://github.com/ukoethe/vigra.git";)
+ (commit commit)))
+   (file-name (string-append name "-" version))
+   (sha256
+(base32
+  "0gvbfrnss1vnkmajsv716yy317j4mx5kn1rxrblxqqyghws47jm5"
+ (build-system cmake-build-system)
+ (inputs
+  `(("boost" ,boost)
+("fftw" ,fftw)
+("fftwf" ,fftwf)
+("hdf5" ,hdf5)
+("ilmbase" ,ilmbase) ; propagated by openexr, but needed explicitly
+ ; to create a configure-flag
+("libjpeg" ,libjpeg)
+("libpng" ,libpng)
+("libtiff" ,libtiff)
+("openexr" ,openexr)
+("python" ,python-2) ; print syntax
+("python2-numpy" ,python2-numpy)
+("zlib" ,zlib)))
+ (native-inputs
+  `(("doxygen" ,doxygen)
+("python2-nose" ,python2-nose)
+("python2-sphinx" ,python2-sphinx)))
+ (arguments
+  `(#:test-target "check"
+#:configure-flags
+  (list "-Wno-dev" ; suppress developer mode with lots of warnings
+(string-append "-DVIGRANUMP

Re: R packages do not show up as requisites

[Ludovic Courtès]

Pjotr Prins  skribis:

> Funny thing,
>
>   guix gc -R path
>
> on a package that has python modules and R packages as inputs only the
> python inputs show up. Try for example r-munsell which has
> r-colorspace as an input:
>
>   ./pre-inst-env guix package -i r-munsell
>
>r-munsell0.4.2 → 0.4.2 
> /gnu/store/kwhzqrpcm8agl8q2v9n19rss060xs2j4-r-munsell-0.4.2
>
>   ./pre-inst-env guix gc -R 
> /gnu/store/kwhzqrpcm8agl8q2v9n19rss060xs2j4-r-munsell-0.4.2
>
> Niente, nop, nada. 

That’s because r-munsell does not explicitly refer to r-colorspace.
Instead, r-colorspace is a propagated input of r-munsell, and propagated
inputs are something taken into account when building the profile (see
the ‘manifest’ file in there), but not other at the lower levels.

> My problem is now that 'guix archive' won't include R modules because
> they are not listed as requisites.
>
> Is there an easy fix?

You could do, say:

  guix package -i r-munsell -p foo
  guix archive --export $(readlink foo) > t.nar

HTH!

Ludo’.

Re: [PATCH 04/13] utils: Use '@' for separating package names and version numbers.

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> Alex Kost  writes:
>
>> Mathieu Lirzin (2016-02-29 03:28 +0300) wrote:
>>
>> [...]
>>> I have left the emacs interface untouched.
>>
>> Hm, I wonder why?  You already had the required changes in your initial
>> patch.  Anyway, I'm attaching the patch with these changes.  The only
>> difference from your original patch is replacing 'package-full-name'
>> with 'make-package-specification' in "guix-main.scm".
>
> The concern of backward compability that Ludo raised, have made the work
> more challenging than changing things in place.  As a consequence it was
> not clear to me what should/can change or not.  To keep my mind clear, I
> have decided to leave the emacs part unchanged.  So the true reason is
> exhaustion.  :)

Sorry that this had this effect!

Ludo’.

Re: OpenSSL “DROWN” vulnerability & grafts

[Ludovic Courtès]

Efraim Flashner  skribis:

> efraim@debian-netbook:~/workspace/guix$ time ./pre-inst-env guix package -u 
> && time ./pre-inst-env guix package -u && time ./pre-inst-env guix package -u
>
> real  15m0.833s
> user  5m53.268s
> sys   1m26.056s
>
> real  14m27.095s
> user  5m50.848s
> sys   1m25.156s
>
> real  14m37.017s
> user  5m55.564s
> sys   1m30.536s
>
> so I don't think the substitute info is the part that's slowing it down.
> Conky shows me both guix hand guix-daemon working, so more likely something
> else, like figuring out the substitutions.

Terrible.  Commit d4da602 should improve the situation.  You’re welcome
to try again and report back!

l...@gnu.org (Ludovic Courtès) skribis:

> A potentially disturbing thing with the new code is that it starts
> building/downloading things early, typically before it has written “The
> following derivations will be built”; see
> .

With commit c90cb5c, the grafting code tries hard to avoid building: it
uses substitute information, when available, to determine the run-time
dependencies of packages (which in turn allows it to decide whether the
package needs to be grafted.)

Ludo’.

Re: [PATCH 04/13] utils: Use '@' for separating package names and version numbers.

[Mathieu Lirzin]

Hi,

Alex Kost  writes:

> Mathieu Lirzin (2016-02-29 03:28 +0300) wrote:
>
> [...]
>> I have left the emacs interface untouched.
>
> Hm, I wonder why?  You already had the required changes in your initial
> patch.  Anyway, I'm attaching the patch with these changes.  The only
> difference from your original patch is replacing 'package-full-name'
> with 'make-package-specification' in "guix-main.scm".

The concern of backward compability that Ludo raised, have made the work
more challenging than changing things in place.  As a consequence it was
not clear to me what should/can change or not.  To keep my mind clear, I
have decided to leave the emacs part unchanged.  So the true reason is
exhaustion.  :)

-- 
Mathieu Lirzin

[PATCH] Add un-fonts (new patch, closes old thread)

[Nils Gillmann]

This adds the fontset un-fonts and closes the old thread on it.

I made the file being served from sdf.org available on
krosos.sdf.org/static/unix/ and as soon as I get the okay from
any other location (potentially in-berlin.de) I will change the
location. Sdf.org is really permanent, but I prefer to move it to
a place which could serve it via tls.

>From 2dcb24a8ea630311743bc8b661c57db0ffcb5be9 Mon Sep 17 00:00:00 2001
From: Nils Gillmann 
Date: Fri, 4 Mar 2016 23:04:16 +0100
Subject: [PATCH] gnu: Add un-fonts.

* gnu/packages/fonts.scm (font-un-fonts): New variable.
---
 gnu/packages/fonts.scm | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 69e195d..141664e 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -628,3 +628,66 @@ Unicode's Basic Multilingual Plane.  The package also includes
 utilities to ease adding new glyphs to the font.")
 (home-page "http://unifoundry.com/unifont.html";)
 (license license:gpl2+)))
+
+(define-public font-un-fonts
+  (package
+(name "font-un-fonts")
+(version "1.0.2")
+;; origin server is serving us broken MIME
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"http://krosos.sdf.org/static/unix/";
+"un-fonts-core-" version "-080608" ".tar.gz"))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+"13liaz2pmww3aqabm55la5npd08m1skh334ky7qfidxaz5s742iv"
+(build-system trivial-build-system)
+(arguments
+ `(#:modules ((guix build utils))
+   #:builder
+   (begin
+ (use-modules (guix build utils))
+
+ (let ((tar  (string-append (assoc-ref %build-inputs "tar")
+"/bin/tar"))
+   (PATH (string-append (assoc-ref %build-inputs "gzip")
+"/bin"))
+   (font-dir (string-append %output "/share/fonts/truetype"))
+   (doc-dir  (string-append %output "/share/doc/" ,name)))
+   (setenv "PATH" PATH)
+   (system* tar "xvf" (assoc-ref %build-inputs "source"))
+   (mkdir-p font-dir)
+   (mkdir-p doc-dir)
+   (chdir (string-append "un-fonts"))
+   (for-each (lambda (ttf)
+   (copy-file ttf
+  (string-append font-dir "/"
+ (basename ttf
+ (find-files "." "\\.ttf$"))
+   (for-each (lambda (doc)
+   (copy-file doc
+  (string-append doc-dir "/"
+ (basename doc
+ '("COPYING" "README"))
+(native-inputs
+ `(("source" ,source)
+   ("tar" ,tar)
+   ("gzip" ,gzip)))
+(home-page "https://kldp.net/projects/unfonts/";)
+(synopsis
+ "Un-fonts is a collection of Korean fonts")
+(description
+ "Un-fonts is a family of mainly Korean fonts.
+It contains the following fonts and styles:
+
+UnBatang, UnBatangBold: serif
+UnDotum, UnDotumBold: sans-serif
+UnGraphic, UnGraphicBold: sans-serif style
+UnDinaru, UnDinaruBold, UnDinaruLight
+UnPilgi, UnPilgiBold: script
+UnGungseo: cursive, brush-stroke
+")
+;; GPL + embed exception for documents / images
+(license license:gpl2+)))
-- 
2.6.3


thanks,
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

Re: GNU Guix diagram

[myglc2]

Amirouche Boubekki  writes:

> Le 2016-03-04 04:31, myglc2 a écrit :
>> Upon installing GuixSD a month ago I found it difficult to get a
>> grip on
>> GNU Guix' stucture. Because I like pictures I made a diagram showing
>> what I think I now understand about how GNU Guix' works. I am thinking
>> it might be helpful to Guix newcomers. Comments &/or corrections would
>> be most welcome. - George
>
> This kind of incorrect because there is a directory which stores every
> installed (or past installed) software which is linked inside profiles
> (system, users, and custom profiles).

Thanks. I agree that generations are a key feature of guix. But they
seem secondary to showing where guix packages are, how they are
referenced, and how to install & update them. I also chose not to show
generations because the diagram is at the limit of complexity that can
be reasonably digested. Generations might be the subject of another
diagram

> Users can't install program in the system profile, it can only be done
> through system config.scm.

Thanks. I tried to suggest this by using a different color for system
components and showing 'sudo' for system operations. Can you suggest a
better way to handle it?

Re: [PATCH 12/13] gnu: Add python-rarfile.

[Leo Famulari]

On Fri, Mar 04, 2016 at 01:42:11PM +0100, Ricardo Wurmus wrote:
> 
> Leo Famulari  writes:
> 
> > * gnu/packages/python.scm (python-rarfile, python2-rarfile): New
> > variables.
> > * gnu/packages/patches/python-rarfile-fix-tests.patch: New file.
> > * gnu-system.am (dist_patch_DATA): Add it.
> > ---
> 
> [...]
> 
> > +(propagated-inputs
> > + `(("libarchive" ,libarchive)))
> > +(home-page "https://github.com/markokr/rarfile";)
> > +(synopsis "RAR archive reader for Python")
> > +(description "This is Python module for RAR archive reading. The 
> > interface
> > +is made as zipfile like as possible.")
> > +(license isc)))
> 
> Does this actually work?  I assumed that our “libarchive” package has no
> support for RAR archives.

I don't know. The libarchive documentation in
'share/man/man5/libarchive-formats.5.gz' does list RAR as a supported
format.

I added python-rarfile since the beets build process fails when it can't
find it. I'd be surprised if it's really necessary though.

In the beets source tarball, the string "rarfile" appears as a test
requirement, and in 'beets/importer.py'. The importer is what a user
invokes to add music to the beets database. Rarfile is not imported as a
module by importer.py, so its absence shouldn't have any effect until a
user actually tries to exercise the feature, if my (weak) understanding
of Python is correct.

I built a beets variant without rarfile, and tested the import
functionality. It works as expected on uncompressed directories. It
fails on archives, but it does that even without this change.

So, what should I do? Patch "rarfile" out of setup.py or package
python-rarfile?

New template for 'guix-packages' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'guix-packages' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/guix-packages-0.9.1.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

http://www.fdn.fr/~lcourtes/tmp/guix-0.9.1tp.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New template for 'guix' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'guix' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/guix-0.9.1.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

http://www.fdn.fr/~lcourtes/tmp/guix-0.9.1tp.tar.gz

We can arrange things so that translated PO files are automatically e-mailed
to you when they arrive.  Ask at the address below if you want this.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

R packages do not show up as requisites

[Pjotr Prins]

Funny thing,

  guix gc -R path

on a package that has python modules and R packages as inputs only the
python inputs show up. Try for example r-munsell which has
r-colorspace as an input:

  ./pre-inst-env guix package -i r-munsell

   r-munsell0.4.2 → 0.4.2 
/gnu/store/kwhzqrpcm8agl8q2v9n19rss060xs2j4-r-munsell-0.4.2

  ./pre-inst-env guix gc -R 
/gnu/store/kwhzqrpcm8agl8q2v9n19rss060xs2j4-r-munsell-0.4.2

Niente, nop, nada. 

So you need R_LIBRARY_PATH set to run it. 

My problem is now that 'guix archive' won't include R modules because
they are not listed as requisites.

Is there an easy fix?

Pj.

Re: GSoC ideas

[Manolis Ragkousis]

Hey

On 03/02/16 23:31, Ludovic Courtès wrote:
> Do you have examples of GNU/Linux uses that would make no sense?
> 

After a quick look in mount's man page I think that maybe Roland was
referring to some flags (like relatime for example) that when passed to
mount, expect the Linux kernel to handle the filesystem in a specific way.

> Other options include calling out to the ‘settrans’ command (inelegant
> IMO), writing Guile bindings for some of the Hurd libraries, and/or some
> sort of a MiG in Scheme (neat but takes some time!).

We could have a guile wrapper for the ‘settrans’ command that could
cover our needs. Isn't this feasible? WDYT?

Manolis

Re: [PATCH] gnu: cross-gcc-arguments: Disable libitm, libvtv and, libsanitizer.

[Manolis Ragkousis]

I updated the patch with an explanation and a link to this discussion.

Manolis
>From dc8154ef19bc28886f350f42c49fb7995eefcec8 Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis 
Date: Tue, 16 Feb 2016 15:06:33 +0200
Subject: [PATCH] gnu: cross-gcc-arguments: Disable libitm, libvtv and
 libsanitizer.

* gnu/packages/cross-base.scm (cross-gcc-arguments)[arguments]: Add
  "--disable-libitm", "--disable-libvtv" and "--disable-libsanitizer"
  when libc is not present.
---
 gnu/packages/cross-base.scm | 8 
 1 file changed, 8 insertions(+)

diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 8bd599c..bd7a1e7 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -120,6 +120,14 @@ may be either a libc package or #f.)"
"--disable-libquadmath"
"--disable-decimal-float" ;would need libc
"--disable-libcilkrts"
+
+   ;; When target is any OS other than 'none' these
+   ;; libraries will fail if there is no libc
+   ;; present. See
+   ;; 
+   "--disable-libitm"
+   "--disable-libvtv"
+   "--disable-libsanitizer"
)))
 
  ,(if libc
-- 
2.7.2

Re: GNU Guix diagram

[John Darrington]

On Thu, Mar 03, 2016 at 10:31:47PM -0500, myglc2 wrote:
 Upon installing GuixSD a month ago I found it difficult to get a grip on
 GNU Guix' stucture. Because I like pictures I made a diagram showing
 what I think I now understand about how GNU Guix' works. I am thinking
 it might be helpful to Guix newcomers. Comments &/or corrections would
 be most welcome. - George

The problem with pictures is, that whilst it is true that "A picture paints
a thousand words" - it paints a thousand different words to a thousand 
different people.

J'



-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: fonts.scm -> packaging "un-fonts", download isses

[Nils Gillmann]

Changing to archive.org as recommended does not fix the mime
type:


building path(s) 
`/gnu/store/7fgpnklam8v0fbklqzmgir2ryg3hb79n-font-un-fonts-1.0.2.tar.gz'

Starting download of 
/gnu/store/7fgpnklam8v0fbklqzmgir2ryg3hb79n-font-un-fonts-1.0.2.tar.gz
>From 
>https://web.archive.org/web/20160304052853/http://kldp.net/frs/download.php/4695/un-fonts-core-1.0.2-080608.tar.gz...
following redirection to 
`https://web.archive.org/web/20150807013056/http://kldp.net/frs/download.php/4695/un-fonts-core-1.0.2-080608.tar.gz'...
ERROR: Bad media-type header component: .gz

failed to download 
"/gnu/store/7fgpnklam8v0fbklqzmgir2ryg3hb79n-font-un-fonts-1.0.2.tar.gz" from 
"https://web.archive.org/web/20160304052853/http://kldp.net/frs/download.php/4695/un-fonts-core-1.0.2-080608.tar.gz";
builder for 
`/gnu/store/lans15ffv24v073jrjadaqs8i307369y-font-un-fonts-1.0.2.tar.gz.drv' 
failed to produce output path 
`/gnu/store/7fgpnklam8v0fbklqzmgir2ryg3hb79n-font-un-fonts-1.0.2.tar.gz'
cannot build derivation 
`/gnu/store/2sax0df6xyd1gazvx2wbajc7yg2lzgj6-font-un-fonts-1.0.2.drv': 1 
dependencies couldn't be built
guix build: error: build failed: build of 
`/gnu/store/2sax0df6xyd1gazvx2wbajc7yg2lzgj6-font-un-fonts-1.0.2.drv' failed

-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

Re: Guix Europe

[Jan Nieuwenhuizen]

Andreas Enge writes:

>https://enge.fr/blog/2016/03/foundation-of-guix-europe/

Yay!
Greetings, Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Register as a GSoC mentor

[Ludovic Courtès]

To all potential GSoC mentors (even if you’re unsure yet): please
email José and Giuseppe as explained below to register as a mentor.

Thanks!

Ludo’.

--- Begin Message ---
Hi,

please send these information to me and José  for each
of you who wants to apply as a mentor.

Id:
Name:
Email:
AltEmail:
Phone:
Project:

Phone and AltEmail are not going to be shared publicly, but are helpful
to us in case we have to communicate quickly with a mentor.

Thanks,
Giuseppe

--- End Message ---

Re: GSoC strikes again

[Ludovic Courtès]

Nils Gillmann  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Good news!  GNU has been accepted as a mentoring organization for
>> Google’s Summer of Code (GSoC).  So if you’d like to help Guix & GNU and
>> on top of that get a paycheck, now is the time to see how you can help!
>> Ideas have been collected for Guix, GuixSD, and the Shepherd at:
>>   https://libreplanet.org/wiki/Group:Guix/GSoC-2016
>
> Would it be better to post a news item (they are fed from or to
> savannah, right?) and link to this or put a GsoC thing which
> links to the gnu projects listing for the GsoC 2016 in the banner
> of the guix page?

I was planning to post a news items within a few days, indeed.

Ludo’.

Re: [PATCH 12/13] gnu: Add python-rarfile.

[Ricardo Wurmus]

Leo Famulari  writes:

> * gnu/packages/python.scm (python-rarfile, python2-rarfile): New
> variables.
> * gnu/packages/patches/python-rarfile-fix-tests.patch: New file.
> * gnu-system.am (dist_patch_DATA): Add it.
> ---

[...]

> +(propagated-inputs
> + `(("libarchive" ,libarchive)))
> +(home-page "https://github.com/markokr/rarfile";)
> +(synopsis "RAR archive reader for Python")
> +(description "This is Python module for RAR archive reading. The 
> interface
> +is made as zipfile like as possible.")
> +(license isc)))

Does this actually work?  I assumed that our “libarchive” package has no
support for RAR archives.

~~ Ricardo

Re: GNU Guix diagram

[Amirouche Boubekki]

Le 2016-03-04 04:31, myglc2 a écrit :
Upon installing GuixSD a month ago I found it difficult to get a grip 
on

GNU Guix' stucture. Because I like pictures I made a diagram showing
what I think I now understand about how GNU Guix' works. I am thinking
it might be helpful to Guix newcomers. Comments &/or corrections would
be most welcome. - George


This kind of incorrect because there is a directory which stores every
installed (or past installed) software which is linked inside profiles
(system, users, and custom profiles).

Users can't install program in the system profile, it can only be done
through system config.scm.

--
Amirouche ~ amz3 ~ http://www.hyperdev.fr

Re: fonts.scm -> packaging "un-fonts", download isses

[Nils Gillmann]

Ricardo Wurmus  writes:

> Nils Gillmann  writes:
>
>> Ricardo Wurmus  writes:
>>
>>> Nils Gillmann  writes:
>>>
 Followup:

 I just downloaded the debian package of the fonts and looked at
 its content, particulary the README.Debian.

 According to them, upstream looks dead, a licensing issue (use of
 pure GPL) exists and has been reported years ago, but was never
 acted upon. The Debian file was signed in May 2012.
>>>
>>> Upstream[1] says this about the license:
>>>
>>>   2 저작권
>>>
>>>   은글꼴의 저작권은 GPL + (문서/이미지에 대한)embed 예외 조항이 포함되어
>>>   은글꼴을 사용한 출판 및 디자인에 대해 상업용,비상업용 목적으로
>>>   사용하는 데에 아무런 문제가 없습니다.
>>>
>>> [1]: http://kldp.net/projects/unfonts
>>>
>>> If I understand correctly, this means that the fonts are released under
>>> GPL + embed exception (for documents / images).  README.Debian seems to
>>> be outdated.  The upstream note is from 2012/12/29.
>>>
>>> ~~ Ricardo
>>>
>>>
>>
>> Oh, that's good news, thanks.
>> As (license:) for the package, is it still gpl2 or is this GPL +
>> something I could find in fonts.scm ?
>
> I did not see any restriction to a particular version of the GPL, but I
> didn’t look very carefully.  If no particular version is mentioned you
> can just use “gpl3+” (because “GPL” means “any version of the GPL”).
> Add the embed exception in a comment above the license field.
>
> I do suggest you check the sources once more, though.  Just grep for
> “GPL” and see if they mention the GPL version.
>
> ~~ Ricardo

cat COPYING:

  GNU GENERAL PUBLIC LICENSE
   Version 2, June 1991

 Copyright (C) 1989, 1991 Free Software Foundation, Inc.
 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.
(etc)

quote from the COPYING delivered with the latest packaged
version available. They might have changed the website, but they
did not update the package.
What counts for us is what we deliver, therefore the version
packaged, therefore GPL2 with no exception.


wdyt?
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

Re: GSoC strikes again

[Nils Gillmann]

l...@gnu.org (Ludovic Courtès) writes:

> Good news!  GNU has been accepted as a mentoring organization for
> Google’s Summer of Code (GSoC).  So if you’d like to help Guix & GNU and
> on top of that get a paycheck, now is the time to see how you can help!
> Ideas have been collected for Guix, GuixSD, and the Shepherd at:
>   https://libreplanet.org/wiki/Group:Guix/GSoC-2016

Would it be better to post a news item (they are fed from or to
savannah, right?) and link to this or put a GsoC thing which
links to the gnu projects listing for the GsoC 2016 in the banner
of the guix page?

wdyt?
-- 
ng
irc://loupsycedyglgamf.onion:67/~NiAsterisk
https://psyced.org:34443/NiAsterisk/
EDN: https://wiki.c3d2.de/Echt_Dezentrales_Netz/en

Re: Guix Europe

[Alex Sassmannshausen]

Andreas Enge writes:

> Dear Guixers,
>
> some of you have already spotted documents concerning a mysterious entity
> called "Guix Europe" appear in the maintenance-git repo. So now I have a
> pleasant announcement to make... But wait - I am not going to write it all up
> a second time. Read on here:
>https://enge.fr/blog/2016/03/foundation-of-guix-europe/
>
> Happy guixing,
>
> Andreas

Yay! Vive l'association! :-)

Alex

Re: Exim security update

[Ludovic Courtès]

Leo Famulari  skribis:

> I just updated Exim from 4.86 to 4.86.2, fixing CVE-2016-1531 [0].

Thanks for the heads-up!

Ludo’.

Re: [PATCH] po: Drop removed file 'weechat.scm'.

[Ludovic Courtès]

Justus Winter  skribis:

> Quoting Chris Marusich (2016-03-03 16:47:13)
>> Is it not necessary to also do something about the other files that
>> mention weechat's prevoius location? For example:
>> 
>> --8<---cut here---start->8---
>> $ grep -r gnu/packages/weechat .
>> ./po/packages/da.po:#: gnu/packages/weechat.scm:92
>> ./po/packages/da.po:#: gnu/packages/weechat.scm:93
>> ./po/packages/pl.po:#: gnu/packages/weechat.scm:92
>> ./po/packages/pl.po:#: gnu/packages/weechat.scm:93
>> ./po/packages/POTFILES.in:gnu/packages/weechat.scm
>> --8<---cut here---end--->8---
>
> I guess you're right in general, but I've looked at the two files and
> they don't contain localized strings for weechat, so we're not losing
> translations.
>
> I don't know who is responsible for updating the files.

Usually I commit them when the Translation Project sends us updates.

Ludo’.

Re: Guix Europe

[Ludovic Courtès]

Andreas Enge  skribis:

> some of you have already spotted documents concerning a mysterious entity
> called "Guix Europe" appear in the maintenance-git repo. So now I have a
> pleasant announcement to make... But wait - I am not going to write it all up
> a second time. Read on here:
>https://enge.fr/blog/2016/03/foundation-of-guix-europe/

Woohoo, thanks!

Ludo’, a happy member.  :-)

Re: GNU Guix diagram

[Adam Pribyl]

On Thu, 3 Mar 2016, myglc2 wrote:


Upon installing GuixSD a month ago I found it difficult to get a grip on
GNU Guix' stucture. Because I like pictures I made a diagram showing
what I think I now understand about how GNU Guix' works. I am thinking
it might be helpful to Guix newcomers. Comments &/or corrections would
be most welcome. - George


I agree this deserves explanation, as this is not a common approach in 
mainstream distros. As I do understand this now, I can hardly judge this 
image will be understood by newcomer, but if this is a part of guix doc + 
the explanation in words (is it not there?), then it would be definitely 
good.


Adam Pribyl

Re: [PATCH 04/13] utils: Use '@' for separating package names and version numbers.

[Alex Kost]

Ludovic Courtès (2016-03-03 19:55 +0300) wrote:

> Alex Kost  skribis:
>
>> Sorry if it was discussed but why 'package-full-name' from (guix
>> packages) wasn't changed?
>
> I think I was afraid that existing uses in unexpected place would break,
> such as when using the full name as anchor names in HTML.
>
> But then I also remember a version of ‘package-full-name’ that took an
> optional separator that defaulted to ‘@’.  I forgot the details!  :-)
> I don’t think it’s crucial though.  WDYT?

I don't have an opinion on changing 'package-full-name' as I have no
idea what may be broken after this change.  As there are no visible
breaks now, it can be left unchanged I believe.

>> Also I have a question regarding hydra.  Will hydra jobs still have
>> such names as "git-2.6.3" or will they also be changed to "git@2.6.3"?
>
> I would leave them unchanged.

Great, that's what I thought, thanks!

>> From 2dbfe087905cc08715bba0f4d4dd0093fd93372b Mon Sep 17 00:00:00 2001
>> From: Alex Kost 
>> Date: Thu, 3 Mar 2016 12:53:03 +0300
>> Subject: [PATCH 1/2] emacs: Use '@' to separate package names and version
>>  numbers.
>>
>> This is a followup to commit 1b846da8c372bee78851439fd9e72b2499115e5a.
>>
>> * emacs/guix-base.el (guix-package-name-specification): Use "@" instead
>> of "-".
>> * emacs/guix-main.scm (name+version->full-name): Likewise.
>> (package-inputs-names): Use 'make-package-specification' instead of
>> 'package-full-name'.
>> (full-name->name+version): Update the docstring.
>> * emacs/guix-ui-package.el (guix-packages-by-name): Likewise.
>
> Looks good.  I forgot about these places where the “full name” matters,
> sorry about that.

It's not your fault, I didn't remember about this place either :-)

>> From c6825b189f7b5d908c5fbe36d933fbe187cbc4bd Mon Sep 17 00:00:00 2001
>> From: Alex Kost 
>> Date: Thu, 3 Mar 2016 12:55:21 +0300
>> Subject: [PATCH 2/2] emacs: hydra: Use '-' to separate job names and version
>>  numbers.
>>
>> * emacs/guix-hydra.el (guix-hydra-job-name-specification): New procedure.
>> * emacs/guix-ui-package.el (guix-package-info-insert-systems)
>> (guix-package-list-latest-builds): Use it.
>
> OK!

Thanks!  I have committed both patches.

-- 
Alex

Re: [PATCH] gnu: Add Augeas.

[Ricardo Wurmus]

Leo Famulari  writes:

> On Thu, Mar 03, 2016 at 05:16:05PM +0100, Ricardo Wurmus wrote:
>> 
>> Ludovic Courtès  writes:
>> 
>> > Ricardo Wurmus  skribis:
>> >
>> >> Leo Famulari  writes:
>> >>
>>  +(build-system gnu-build-system)
>>  +;; Marked as "required" in augeas.pc
>>  +(propagated-inputs
>>  + `(("libxml2" ,libxml2)))
>> >
>> > I find it clearer to put the comment right below ‘propagated-inputs’.
>> >
>> >>> Is there really no way to avoid this?
>> >>
>> >> I don’t know.
>> >
>> > The problem is that I don’t think it works to put an absolute file name
>> > in the ‘Requires’ field of a ‘.pc’ file, so I don’t think we can avoid
>> > it unfortunately.
>> >
>> > However, since Augeas is a library, the propagated input is acceptable:
>> > in practice, people probably won’t have it in their main environment,
>> > but rather in a ‘guix environment’ thing, or in a dedicated development
>> > profile.
>> 
>> Augeas is both a library and a command line tool.  For a command line
>> tool propagation is ugly and I’d like to avoid it.
>> 
>> What should I best do in this case?
>
> What is the effect of a wrapper compared to propagation? My
> understanding is that the wrapped environment is only visible to the
> wrapped binary. Is that correct? If so, it seems less intrusive to the
> user's profile.

A person using the command line tool probably won’t need a wrapper and
doesn’t need propagation either.  They only just use the tool.

However, a programme using augeas as a library *does* need the input to
be propagated as pkg-config will otherwise claim that augeas could not
be loaded.  Such programme would have to add libxml2 to its inputs.  We
achieve this for all users of augeas by propagating libxml2.

As far as I can see there is no way to reconcile these two opposing
forces in a single package.  We don’t have a way to say that an input
should only be propagated if the package is not a leaf node in the graph
(i.e. installed directly into a user’s profile).

~~ Ricardo