Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

[Alex Kost]

Andreas Enge (2014-10-30 16:36 +0300) wrote:

> On Thu, Oct 30, 2014 at 03:52:50PM +0300, Alex Kost wrote:
>> I don't understand why you call it a mistake.  It's just a package name
>> used by some distributions (and I think it's a good name).  Is there a
>> convention to use “…-fonts-ttf” in Guix?
>
> It may be a good name, but the Guix convention is to not choose names, but
> to simply use the upstream name. This is described in the packaging
> guidelines, section 6.5.2 of the documentation:
> "Both are usually the same and correspond to the lowercase conversion of
> the project name chosen upstream, with underscores replaced with hyphens".
> So liberation-fonts-ttf-2.00.1.tar.gz becomes liberation-fonts-ttf.
> (Admittedly "project name" is a bit vague; it means "tarball name", the
> aim is not to call all packages of the x.org system x-org, so that
> only one of them could be installed ;-)).
>
> And dejavu-fonts-ttf-2.34.tar.bz2 should become dejavu-fonts-ttf.
>
> And font-adobe-100dpi-1.0.3.tar.bz2 should have become font-adobe-100dpi,
> but apparently I made a mistake and called it font-adobe100dpi.
> Another mistake to correct. In particular, it is not called
> adobe-100dpi-fonts-pcf.

Thank you for the explanation, so a package with "Symbola" font
(http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00279.html)
should be called just "symbola"?

Re: Problems with downloading from https

[Alex Kost]

Andreas Enge (2014-10-30 15:38 +0300) wrote:

> On Thu, Oct 30, 2014 at 03:31:15PM +0300, Alex Kost wrote:
>> I think the latter is a bug.  IMHO it shouldn't be possible to install
>> several packages with the same name in one profile.
>
> Well, having python 2 and 3 is reasonable, and from what I saw in their
> naming scheme, it is entirely possible (the python binary being renamed
> to python 3). Qt 4 and 5 are, I think, another case. How about GTK+ 2 and 3?
>
> Of course we could rename the packages, but this is not our policy so far.

Actually I thought it was the policy.  I asked about that: search for
"intended" at
.

Such behavior is handled by ‘manifest-add’ currently.  Before that this
code was placed in “guix/scripts/package.scm” and it was there for a
I-don't-know-how-long time.

-- 
Alex

Re: Problems with downloading from https

[Alex Kost]

Ian Denhardt (2014-10-30 20:05 +0300) wrote:

> Quoting Alex Kost (2014-10-30 03:27:59)
>> As both python packages can co-exist in one profile, either python-2…
>> may be renamed into “python2” or python-3… into “python3”.  As python3
>> is the future, I think it would be better to have “python2” and “python”
>> (which is python3) packages.  Or maybe they shouldn't be renamed and we
>> can introduce a little collision instead by adding "…/bin/python"
>> symlink to python-3… package.
>
> Speaking as someone who's been on a distro that has python 3 as the
> default since 2.7 came out, and being a professional python developer
> working on codebases that often don't work on python 3, I don't really
> consider this a sensible default. I often have a symlink ahead of the
> system python binary in my path that points to python2. More
> importantly, I think it should be tunable. I *do* sometimes make use of
> having both available.

This is what you currently have: you can install both, and "python" would
be a link to "python2".

But installing 2 packages with the same name is not intended (to prevent
file names collision), so I think it would be better to rename one of the
pythons into "python2"/"python3".

-- 
Alex

Re: Font package naming convention

[Alex Kost]

Ludovic Courtès (2014-10-30 20:20 +0300) wrote:

[...]

> I think we must settle on a convention, and I would personally prefer to
> follow the principle of least surprise–i.e., choose a convention that is
> already widespread elsewhere.

I agree with that and I would prefer to see:

  ttf-bitstream-vera
  ttf-dejavu
  ttf-freefont
  ttf-liberation
  ttf-symbola

instead of (following the upstream name):

  ttf-bitstream-vera
  dejavu-fonts-ttf
  freefont-ttf
  liberation-fonts-ttf
  symbola

-- 
Alex

Re: Problems with downloading from https

[Ian Denhardt]

Quoting Alex Kost (2014-10-30 03:27:59)
> As both python packages can co-exist in one profile, either python-2…
> may be renamed into “python2” or python-3… into “python3”.  As python3
> is the future, I think it would be better to have “python2” and “python”
> (which is python3) packages.  Or maybe they shouldn't be renamed and we
> can introduce a little collision instead by adding "…/bin/python"
> symlink to python-3… package.

Speaking as someone who's been on a distro that has python 3 as the
default since 2.7 came out, and being a professional python developer
working on codebases that often don't work on python 3, I don't really
consider this a sensible default. I often have a symlink ahead of the
system python binary in my path that points to python2. More
importantly, I think it should be tunable. I *do* sometimes make use of
having both available.

-Ian


signature.asc
Description: signature

Re: [PATCH 1/2] gnu: Add numpy

[Federico Beffa]

On Wed, Oct 29, 2014 at 11:11 PM, Ludovic Courtès  wrote:
>> +(define python2-numpy-reference python-numpy-reference)
>> +
>> +(define python2-numpy-userguide python-numpy-userguide)
>
> These variables are unused and not needed, so they can be removed.

Ah, you are right.  I thought that 'package-with-python2' would change
all input prefixes from 'python' to 'python2'.

Please note that this patch will NOT build until the 'python-wrapper'
will be applied (but I tested it again with my previous
'python-wrapper' patch). It is my understanding that Andreas will look
into the 'python-wrapper' patch at a suitable time.

Regards,
Fede
From cab16a360bf478aef6feda8b1977d4318f87eeec Mon Sep 17 00:00:00 2001
From: Federico Beffa 
Date: Thu, 30 Oct 2014 17:10:35 +0100
Subject: [PATCH] gnu: Add numpy.

* gnu/packages/python.scm (python-numpy, python2-numpy): New variables.
---
 gnu/packages/python.scm | 88 +
 1 file changed, 88 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index c34bdc3..0e2f567 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -1832,3 +1832,91 @@ sources.")
 
 (define-public python2-sphinx
   (package-with-python2 python-sphinx))
+
+(define python-numpy-reference
+  (origin
+(method url-fetch)
+(uri (string-append "mirror://sourceforge/numpy/reference.pdf"))
+(sha256 
+ (base32
+  "0izsmzazhd042ra6p7as2jhwx8713sc5gpn9s5nifwm68biwn0lp"
+
+(define python-numpy-userguide
+  (origin
+(method url-fetch)
+(uri (string-append "mirror://sourceforge/numpy/userguide.pdf"))
+(sha256 
+ (base32
+  "1z2xjlxldv01ad2775k9birg1hkqay5wbi5vmgz3rlr6dczvk77k"
+
+(define-public python-numpy
+  (package
+(name "python-numpy")
+(version "1.9.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "mirror://sourceforge/numpy"
+   "/numpy-" version ".tar.gz"))
+   (sha256
+(base32
+ "1xbzsb84wg32zx5ilgvkdp0lwfqrycwhh5a2q9nx5iwyjpgcxrpp"
+(build-system python-build-system)
+(inputs
+ `(("python-numpy-userguide" ,python-numpy-userguide)
+   ("python-numpy-reference" ,python-numpy-reference)
+   ("atlas" ,atlas)))
+(native-inputs
+ `(("python-nose" ,python-nose)  ; used by tests
+   ("gfortran" ,gfortran-4.8)))
+(outputs '("out" "doc")) ; doc is ca. 9MB
+(arguments
+ `(#:phases
+   (alist-cons-before
+'build 'set-environment-variables
+(lambda* (#:key inputs #:allow-other-keys)
+  (let* ((atlas-threaded
+  (string-append (assoc-ref inputs "atlas") 
+ "/lib/libtatlas.so"))
+ ;; On single core CPUs only the serial library is created.
+ (atlas-lib
+  (if (file-exists? atlas-threaded)
+  atlas-threaded
+  (string-append (assoc-ref inputs "atlas") 
+ "/lib/libsatlas.so"
+(setenv "ATLAS" atlas-lib)))
+;; TODO: generate documentation locally, including info files.  The
+;; documentation can be built from the source.  However, it needs
+;; matplotlib which we currently do not have.
+(alist-cons-after
+ 'install 'install-doc
+ (lambda* (#:key outputs inputs #:allow-other-keys)
+   (let ((doc (string-append (assoc-ref outputs "doc") 
+ "/share/doc/" ,name "-" ,version)))
+ (mkdir-p doc)
+ (copy-file (assoc-ref inputs "python-numpy-reference")
+(string-append doc "/reference.pdf"))
+ (copy-file (assoc-ref inputs "python-numpy-userguide")
+(string-append doc "/userguide.pdf"
+ ;; Tests can only be run after the library has been installed and not
+ ;; within the source directory.
+ (alist-cons-after
+  'install 'check
+  (lambda _ 
+(with-directory-excursion "/tmp"
+  (zero? (system* "python" "-c" "import numpy; numpy.test()"
+  (alist-delete 
+   'check 
+   %standard-phases))
+(home-page "http://www.numpy.org/";)
+(synopsis "Fundamental package for scientific computing with Python")
+(description "NumPy is the fundamental package for scientific computing
+with Python. It contains among other things: a powerful N-dimensional array
+object, sophisticated (broadcasting) functions, tools for integrating C/C++
+and Fortran code, useful linear algebra, Fourier transform, and random number
+capabilities.")
+(license bsd-3)))
+
+(define-public python2-numpy
+  (package-with-python2 python-numpy))
+
-- 
1.8.4

Re: Problems with downloading from https

[Ian Denhardt]

Quoting Alex Kost (2014-10-30 15:08:08)
> This is what you currently have: you can install both, and "python" would
> be a link to "python2".
> 
> But installing 2 packages with the same name is not intended (to prevent
> file names collision), so I think it would be better to rename one of the
> pythons into "python2"/"python3".

Yeah, I understood. I'd been thinking it would be nice to be able to
tune which one.

It actually wouldn't be a matter of "renaming" anything, so much as
getting rid of the symlink from one package -- on my arch system for
example,

* /usr/bin/python is a symlink to /usr/bin/python3
* /usr/bin/python3 is a symlink to /usr/bin/python3.4

In any case, I don't feel terribly strongly, but it feels like it
shouldn't be that hard to get the target of that symlink to be
user/sysadmin-configurable.

-Ian


signature.asc
Description: signature

[PATCH 2/3] gnu: Add perl-io-socket-ssl.

[Eric Bavier]

* gnu/packages/web.scm (perl-io-socket-ssl): New variable.
---
 gnu/packages/web.scm |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
index 1a42625..301e64b 100644
--- a/gnu/packages/web.scm
+++ b/gnu/packages/web.scm
@@ -572,3 +572,26 @@ unavailable.")
 library.")
 (license (package-license perl))
 (home-page 
"http://search.cpan.org/~szbalint/WWW-Curl-4.17/lib/WWW/Curl.pm";)))
+
+(define-public perl-io-socket-ssl
+  (package
+(name "perl-io-socket-ssl")
+(version "2.002")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "mirror://cpan/authors/id/S/SU/SULLR/"
+  "IO-Socket-SSL-" version ".tar.gz"))
+  (sha256
+   (base32
+"1mph52lw6x5v44wf8mw00llzi8pp6k5c4jnrnrvlacrlfv260jb8"
+(build-system perl-build-system)
+(propagated-inputs `(("perl-net-ssleay" ,perl-net-ssleay)))
+(synopsis "Nearly transparent SSL encapsulation for IO::Socket::INET")
+(description
+ "IO::Socket::SSL makes using SSL/TLS much easier by wrapping the
+necessary functionality into the familiar IO::Socket interface and providing
+secure defaults whenever possible.  This way existing applications can be made
+SSL-aware without much effort, at least if you do blocking I/O and don't use
+select or poll.")
+(license (package-license perl))
+(home-page "https://github.com/noxxi/p5-io-socket-ssl";)))
-- 
1.7.9.5

Different versions of a package in the same profile?

[Ludovic Courtès]

Andreas Enge  skribis:

> On Thu, Oct 30, 2014 at 03:31:15PM +0300, Alex Kost wrote:
>> I think the latter is a bug.  IMHO it shouldn't be possible to install
>> several packages with the same name in one profile.
>
> Well, having python 2 and 3 is reasonable, and from what I saw in their
> naming scheme, it is entirely possible (the python binary being renamed
> to python 3). Qt 4 and 5 are, I think, another case. How about GTK+ 2 and 3?

Actually, Qt 4 and 5 use non-versioned file names under bin/.

Technically it would be easy to allow the installation of different
versions of a package in the same profile, but I wonder about the
implications.

For instance, ‘-u foo’ would upgrade all the installed versions of
‘foo’, so you would end up with exactly the same version twice.

Ludo’.

[PATCH 0/3]: gnu: wget: Upgrade to 1.16.

[Eric Bavier]

This upgrade fixes CVE-2014-4877.  In the previous release, the testcases
would fail but be marked as "skipped".  That behavior changed to hard failures
in 1.16, thus the need for the additional native-input perl modules.

The libpsl input can be added at a later time (i.e. libpsl needs to be 
packaged).

`~Eric

Re: Font package naming convention

[Ludovic Courtès]

Andreas Enge  skribis:

> On Thu, Oct 30, 2014 at 06:20:46PM +0100, Ludovic Courtès wrote:
>> There’s no documented convention (yet), so it’s not a mistake strictly
>> speaking.  :-)
>
> We have a convention for package names, including fonts;

You mean the convention of choosing the upstream name, right?

> But we could choose another one close to the naming of python and perl modules
> if enough people wish to have special rules for fonts.

Yes, it would make sense to take this route for fonts and have something
akin to what Alex just suggested, because the upstream name is only
occasionally going match one’s expectations.

How does that sound?

Ludo’.

Re: Font package naming convention

[Alex Kost]

Andreas Enge (2014-10-30 22:17 +0300) wrote:

> On Thu, Oct 30, 2014 at 09:55:34PM +0300, Alex Kost wrote:
>> I agree with that and I would prefer to see:
>>   ttf-bitstream-vera
>>   ttf-dejavu
>>   ttf-freefont
>>   ttf-liberation
>>   ttf-symbola

I suggest this ↑  IIUC it is a common practice in other distributions.

>> instead of (following the upstream name):
>>   ttf-bitstream-vera
>>   dejavu-fonts-ttf
>>   freefont-ttf
>>   liberation-fonts-ttf
>>   symbola

Andreas prefers this ↑

> This is not quite consistent, as you sometimes drop "fonts", sometimes keep
> "font". Adapting the python convention (put "ttf-" in front, drop all other
> occurrences of "ttf" and resulting double dashes) would end up with:
>  ttf-bitstream-vera
>  ttf-dejavu-fonts
>  ttf-freefont
>  ttf-liberation-fonts
>  ttf-symbola

I don't suggest that ↑

> Dropping additonally all occurrences of "fonts" and "font" would end up with:
>  ttf-bitstream-vera
>  ttf-dejavu
>  ttf-free<-- somewhat silly
>  ttf-liberation
>  ttf-symbola

And I don't suggest that ↑

I'm against any strict binding to an upstream name.  Why should we stick
to a (potentially strange) upstream name if we know better how a package
should be called?

What do other people think?

Re: Font package naming convention

[Andreas Enge]

On Thu, Oct 30, 2014 at 06:20:46PM +0100, Ludovic Courtès wrote:
> There’s no documented convention (yet), so it’s not a mistake strictly
> speaking.  :-)

We have a convention for package names, including fonts; so strictly speaking
it is a mistake.

> I think we must settle on a convention, and I would personally prefer to
> follow the principle of least surprise–i.e., choose a convention that is
> already widespread elsewhere.

We need not settle on a convention as we already have one for packages.
But we could choose another one close to the naming of python and perl modules
if enough people wish to have special rules for fonts.

Andreas

Re: [PATCH] emacs: Add a name/version/synopsis heading in package-info buffers

[Alex Kost]

Ludovic Courtès (2014-10-30 16:16 +0300) wrote:

> Alex Kost  skribis:

[...]

>> Thanks again, I really like your suggestion, I just prefer to keep
>> previous possibilities instead of replacing them with the new ones.
>
> Yes, why not.  I’m a bit concerned about the cost of keeping several
> variants of different things, esp. because in practice almost only one
> variant would be tested.  WDYT?

I try to keep track of all possibilities :-)

>> Are you going to make a commit or should I do it?  (of course if you
>> don't have comments on my patch)
>
> Please go ahead!

OK, I'm attaching a patch.  Is “Co-authored-by …” enough or should you
be credited in some other way?

> I’m thinking perhaps we should do something similar for the description
> itself, like display it right below the synopsis.  Thoughts?

I think a simple heading may consist of just "name version" and other
parameters may be specified by a user.  For this purpose I added
‘guix-package-info-heading-params’ variable.  Do you think a description
should also be displayed in the heading by default?

>From 08cb220407388142adba3e6aa884dd0d2fd5a844 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Fri, 31 Oct 2014 00:11:55 +0300
Subject: [PATCH] emacs: Add package info heading.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Ludovic Courtès 

* emacs/guix-info.el: (guix-package-info-heading): New face.
  (guix-package-info-synopsis): Modify face.
  (guix-info-insert-entry-default, guix-package-info-insert-heading,
  guix-package-info-insert-with-heading): New procedures.
  (guix-package-info-heading-params, guix-info-insert-package-function,
  guix-info-insert-installed-function, guix-info-insert-output-function,
  guix-info-insert-generation-function): New variables.
---
 emacs/guix-info.el | 74 --
 1 file changed, 72 insertions(+), 2 deletions(-)

diff --git a/emacs/guix-info.el b/emacs/guix-info.el
index 551d79a..88363e5 100644
--- a/emacs/guix-info.el
+++ b/emacs/guix-info.el
@@ -198,7 +198,8 @@ ENTRIES should have a form of `guix-entries'."
   entries
   guix-info-delimiter))
 
-(defun guix-info-insert-entry (entry entry-type &optional indent-level)
+(defun guix-info-insert-entry-default (entry entry-type
+   &optional indent-level)
   "Insert ENTRY of ENTRY-TYPE into the current info buffer.
 If INDENT-LEVEL is non-nil, indent displayed information by this
 number of `guix-info-indent' spaces."
@@ -210,6 +211,18 @@ number of `guix-info-indent' spaces."
   (indent-rigidly region-beg (point)
   (* indent-level guix-info-indent)
 
+(defun guix-info-insert-entry (entry entry-type &optional indent-level)
+  "Insert ENTRY of ENTRY-TYPE into the current info buffer.
+Use `guix-info-insert-ENTRY-TYPE-function' or
+`guix-info-insert-entry-default' if it is nil."
+  (let* ((var (intern (concat "guix-info-insert-"
+  (symbol-name entry-type)
+  "-function")))
+ (fun (symbol-value var)))
+(if (functionp fun)
+(funcall fun entry)
+  (guix-info-insert-entry-default entry entry-type indent-level
+
 (defun guix-info-insert-param (param entry entry-type)
   "Insert title and value of a PARAM at point.
 ENTRY is alist with parameters and their values.
@@ -376,6 +389,12 @@ See `insert-text-button' for the meaning of PROPERTIES."
 (guix-define-buffer-type info package
   :required (id installed non-unique))
 
+(defface guix-package-info-heading
+  'type tty pc) (class color)) :weight bold)
+(t :height 1.6 :weight bold :inherit variable-pitch))
+  "Face for package name and version headings."
+  :group 'guix-package-info)
+
 (defface guix-package-info-name
   '((t :inherit font-lock-keyword-face))
   "Face used for a name of a package."
@@ -392,7 +411,8 @@ See `insert-text-button' for the meaning of PROPERTIES."
   :group 'guix-package-info)
 
 (defface guix-package-info-synopsis
-  '((t :inherit font-lock-doc-face))
+  'type tty pc) (class color)) :weight bold)
+(t :height 1.1 :weight bold :inherit variable-pitch))
   "Face used for a synopsis of a package."
   :group 'guix-package-info)
 
@@ -433,6 +453,40 @@ See `insert-text-button' for the meaning of PROPERTIES."
   "Face used if a package is obsolete."
   :group 'guix-package-info)
 
+(defvar guix-info-insert-package-function
+  #'guix-package-info-insert-with-heading
+  "Function used to insert a package information.
+It is called with a single argument - alist of package parameters.
+If nil, insert package in a default way.")
+
+(defvar guix-package-info-heading-params '(synopsis description)
+  "List of parameters displayed in a heading along with name and version.")
+
+(defun guix-package-info-insert-heading (entry)
+  "Insert the heading for package ENTRY.
+Show package name, version, and `guix-package

Re: [PATCH] emacs: Add a name/version/synopsis heading in package-info buffers

[Ludovic Courtès]

Alex Kost  skribis:

> OK, I'm attaching a patch.  Is “Co-authored-by …” enough or should you
> be credited in some other way?

It’s enough.

>> I’m thinking perhaps we should do something similar for the description
>> itself, like display it right below the synopsis.  Thoughts?
>
> I think a simple heading may consist of just "name version" and other
> parameters may be specified by a user.  For this purpose I added
> ‘guix-package-info-heading-params’ variable.  Do you think a description
> should also be displayed in the heading by default?

Yes, I like it this way.

Thanks!

Ludo’.

Font package naming convention

[Ludovic Courtès]

Alex Kost  skribis:

> Andreas Enge (2014-10-30 10:56 +0300) wrote:
>
>> On Thu, Oct 30, 2014 at 10:27:49AM +0300, Alex Kost wrote:
>>> Why should?  What about “ttf-dejavu”?  Should it be called
>>> “dejavu-fonts-ttf” then?
>>
>> Yes, that was a mistake, maybe inspired from the debian package name.
>> We should rename it.
>
> I don't understand why you call it a mistake.  It's just a package name
> used by some distributions (and I think it's a good name).  Is there a
> convention to use “…-fonts-ttf” in Guix?

There’s no documented convention (yet), so it’s not a mistake strictly
speaking.  :-)

>>> Then it shouldn't be prefixed with "ttf".  I suggest to use "ttf-…" name
>>> only for packages that provide truetype fonts only.  As for the other
>>> font packages, I think they should have "font"/"fonts" in their names,
>>> no matter would it be in the beginning (font-misc-ethiopic) or in the
>>> end (terminus-font).
>>
>> Then what if it contains other types of fonts? Texlive-data/texfm-dist/fonts
>> contains the following 20 subdirectories:
>> afm  cmap  fea  map   ofm   ovf  pfm  sfd tfm   type1
>> cid  enc   lig  misc  opentype  ovp  pk   source  truetype  vf
>> (not all of them are fonts, some are just metrics and some I do not know).
>> Would you suggest to use prefixes type1-, opentype-, pk- also?
>> Only if the package contains exactly one format? I think modifying our
>> package name rules for fonts will open a can of worms.
>
> I think they should be called “texlive-…”.
>
> What I see in "Arch Linux" is a lot of “ttf-…” packages (including
> “ttf-liberation” and “ttf-dejavu”).  IIUC Debian uses the same names for
> TrueType fonts.  And I like it.  But anyway, if “liberation-fonts-ttf”
> is the prefered variant, I'll fix my patch.  But I think “ttf-dejavu”
> should be renamed into “dejavu-fonts-ttf” at first.  And what about
> “freefont-ttf” and “ttf-bitstream-vera”?

I think we must settle on a convention, and I would personally prefer to
follow the principle of least surprise–i.e., choose a convention that is
already widespread elsewhere.

WDYT?

Ludo’.

Re: [PATCH 1/2] gnu: Add numpy

[Federico Beffa]

On Wed, Oct 29, 2014 at 11:20 PM, Andreas Enge  wrote:
> On Mon, Oct 27, 2014 at 09:26:41PM +0100, Federico Beffa wrote:
>> I get error messages that matplotlib is missing.  I started looking at
>> matplotlib as well, but I've found that, for the TkAgg back-end, it
>> needs TKinter which is part of the standard python libraries and it is
>> built if, during the build phase, tk is available.
>
> So we should add tk as an input to the python package?

That would be great!  In this way the python package should build the
Tkinter library which currently is missing.

[PATCH 1/3] gnu: Add perl-net-ssleay.

[Eric Bavier]

* gnu/packages/openssl.scm (perl-net-ssleay): New variable.
---
 gnu/packages/openssl.scm |   34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/openssl.scm b/gnu/packages/openssl.scm
index 563290d..141e105 100644
--- a/gnu/packages/openssl.scm
+++ b/gnu/packages/openssl.scm
@@ -23,7 +23,8 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
-  #:use-module (guix build-system gnu))
+  #:use-module (guix build-system gnu)
+  #:use-module (guix build-system perl))
 
 (define-public openssl
   (package
@@ -67,3 +68,34 @@
 "OpenSSL is an implementation of SSL/TLS")
(license license:openssl)
(home-page "http://www.openssl.org/";)))
+
+(define-public perl-net-ssleay
+  (package
+(name "perl-net-ssleay")
+(version "1.66")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "mirror://cpan/authors/id/M/MI/MIKEM/"
+  "Net-SSLeay-" version ".tar.gz"))
+  (sha256
+   (base32
+"0mxfdhz2fyc40a4myi1yfalf875v5wq1fm4qib9sj3chdm9zvy2v"
+(build-system perl-build-system)
+(inputs `(("openssl" ,openssl)))
+(arguments
+ `(#:phases (alist-cons-before
+ 'configure 'set-ssl-prefix
+ (lambda* (#:key inputs #:allow-other-keys)
+   (setenv "OPENSSL_PREFIX" (assoc-ref inputs "openssl")))
+ %standard-phases)))
+(synopsis "Perl extension for using OpenSSL")
+(description
+ "This module offers some high level convenience functions for accessing
+web pages on SSL servers (for symmetry, the same API is offered for accessing
+http servers, too), an sslcat() function for writing your own clients, and
+finally access to the SSL api of the SSLeay/OpenSSL package so you can write
+servers or clients for more complicated applications.")
+(license (package-license perl))
+(home-page "http://search.cpan.org/~mikem/Net-SSLeay-1.66/";)))
+
+
-- 
1.7.9.5

Re: Icecat not substituted

[Ludovic Courtès]

Andreas Enge  skribis:

> when issueing
>guix package -u icecat -n
> I see:
>
> The following package would be upgraded:   
>icecat   31.2.0 → 31.2.0 
> /gnu/store/rsf4pww335qqv7iyss54i8fmwr7kfm83-icecat-31.2.0
>
> The following derivations would be built:
>/gnu/store/wxfxjbbc268gxmbinb0bnckhxq6hik37-profile.drv
>/gnu/store/8lkrvrf0vl8bb4k6nqpsmimga1hyzz2x-icecat-31.2.0.drv
>/gnu/store/5g7kp7cw3r2pj8p013678h7qiic28zk2-info-dir.drv
>
> Other packages are downloaded from hydra, and there is an icecat for x86_64
> there.

With current v0.7-621-gb9113ad on x86_64, I get:

--8<---cut here---start->8---
$ LANGUAGE=C ./pre-inst-env guix build icecat -n
The following files would be downloaded:
   /gnu/store/rsf4pww335qqv7iyss54i8fmwr7kfm83-icecat-31.2.0
   /gnu/store/a16b6sadwv9am5ma3dsvk8l6xgbna4c8-gtk+-2.24.21
   /gnu/store/v9vr5jrhln38s4fnh4n6kz74djfynac1-pango-1.34.1
--8<---cut here---end--->8---

Could it be that you have local modifications triggering a rebuild?

Ludo’.

Re: [PATCH] emacs: Add a name/version/synopsis heading in package-info buffers

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2014-10-29 19:25 +0300) wrote:
>
>> Hello,
>>
>> What would think of a patch like this:
>
> [...]
>
>>  (defun guix-info-insert-entry (entry entry-type &optional indent-level)
>>"Insert ENTRY of ENTRY-TYPE into the current info buffer.
>>  If INDENT-LEVEL is non-nil, indent displayed information by this
>>  number of `guix-info-indent' spaces."
>>(let ((region-beg (point)))
>> +(guix-info-insert-heading entry)
>>  (mapc (lambda (param)
>> -(guix-info-insert-param param entry entry-type))
>> +;; The name, version, and synopsis are already displayed.
>> +(unless (memq param '(name version synopsis))
>> +  (guix-info-insert-param param entry entry-type)))
>>(guix-info-get-displayed-params entry-type))
>>  (when indent-level
>>(indent-rigidly region-beg (point)
>
> ‘guix-info-insert-entry’ is used to insert any type of information, not
> only packages, so you can see artifacts (empty lines and "–") in other
> "views".

Ah, OK.

> I'm attaching the modified version of your patch.  I added there several
> variables that allow a user to specify functions for displaying info
> (perhaps there will be several variants of displaying info in the
> future).  So if someone would like to return to the previous variant of
> displaying a package, he could do it with:
>
>   (setq guix-info-insert-package-function nil)

Sounds good!

> Thanks again, I really like your suggestion, I just prefer to keep
> previous possibilities instead of replacing them with the new ones.

Yes, why not.  I’m a bit concerned about the cost of keeping several
variants of different things, esp. because in practice almost only one
variant would be tested.  WDYT?

> Are you going to make a commit or should I do it?  (of course if you
> don't have comments on my patch)

Please go ahead!

I’m thinking perhaps we should do something similar for the description
itself, like display it right below the synopsis.  Thoughts?

Thanks,
Ludo’.

Changing python-wrapper to handle lib/ etc.

[Ludovic Courtès]

Andreas Enge  skribis:

> On Tue, Oct 28, 2014 at 10:34:48AM +0100, Ludovic Courtès wrote:
>> Ah right.  And what if you again remove Python from ‘inputs’, and add
>>   #:python ,python
>> to the arguments?
>> That means it will use the actual Python 3.x package, not the wrapper,
>> so everything will be visible.  The downside is that there will be no
>> ‘python’ command, only ‘python3’.
>> 
>> Perhaps the right fix will be to change ‘python-wrapper’ to symlink the
>> ‘lib’ sub-directory of ‘python’.
>
> As already stated, I think we should add python as a propagated input to
> python-wrapper. The symlinks are just needed between the differently named
> python and python3.
>
> Should we give this a try?

I think our messages crossed each other; I wrote:

  The other option would have been to add ‘python’ to ‘propagated-inputs’,
  which would also have taken care of sub-directories other than lib/.

  As a side-effect, it would also pull in the ‘python3’, ‘pydoc3’,
  etc. commands, but I think it cannot hurt.

So yes, I think we should try this.

What about making this change in a branch, letting Hydra build it, and
then merge it if nothing broke?

We’ll also need the patch from
 in
this branch.

Do you want to take care of it?  :-)

TIA,
Ludo’.

Re: Problems with downloading from https

[Ludovic Courtès]

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

> Mark H Weaver  skribis:

[...]

>> The reason is that guix/download.scm contains this code:
>>
>>   ;; Add GnuTLS to the inputs and to the load path.
>>   #~(eval-when (load expand eval)
>>   (set! %load-path
>> (cons (string-append #$(gnutls-package)
>>  "/share/guile/site")
>>   %load-path)))
>>   #~#t)
>
> Oops, my bad.  I think this code should be changed to use site/2.0,
> which is the standard search path specification.
>
>> For now, I think we should revert this commit and discuss it further
>> before proceeding.
>
> I would just fix the above code to append (effective-version).  WDYT?

Commit e0ea3f8 does that.

(We should keep discussing the more general issue though, of course.)

Ludo’.

Re: Problems with downloading from https

[Alex Kost]

Andreas Enge (2014-10-30 10:49 +0300) wrote:

> On Thu, Oct 30, 2014 at 10:27:59AM +0300, Alex Kost wrote:
>> I think such an "evil" case is just not handled currently.  If you have
>> python-3… installed and you install python-2… in the same profile, then
>> python-3… would be replaced, but if you install both packages in the
>> same command, then both would be installed.
>
> Interesting, I did not know this, but you are right:
>
> $ guix package -i python
> $ guix package -i python-2.7.6
> The following package will be upgraded:
>python   3.3.5 → 2.7.6   
> /gnu/store/iz5shg4py68mbccv2kkd0siv6ryfl3y1-python-2.7.6
>
> If you do instead
> $ guix package -i python python-2.7.6
>
> both packages are installed.
>
> I think the former behaviour is a bug. If I use "-i" and not "-u", a package
> should not be "upgraded", but added in every case, independently of its name.

I think the latter is a bug.  IMHO it shouldn't be possible to install
several packages with the same name in one profile.

-- 
Alex

Re: [PATCH 1/2] gnu: Add numpy

[Federico Beffa]

On Thu, Oct 30, 2014 at 6:03 PM, Andreas Enge  wrote:
> Okay. I think I should do this together with the changes to python-wrapper
> in the python branch to be created. For both python-2 and python-3?

Yes, please.  That will allow making a matplotlib package for both
versions of python.

Regards,
Fede

Re: [PATCH 1/2] gnu: Add numpy

[Andreas Enge]

On Thu, Oct 30, 2014 at 05:56:53PM +0100, Federico Beffa wrote:
> On Wed, Oct 29, 2014 at 11:20 PM, Andreas Enge  wrote:
> > So we should add tk as an input to the python package?
> 
> That would be great!  In this way the python package should build the
> Tkinter library which currently is missing.

Okay. I think I should do this together with the changes to python-wrapper
in the python branch to be created. For both python-2 and python-3?

Andreas

Re: Problems with downloading from https

[Ludovic Courtès]

Alex Kost  skribis:

> I think such an "evil" case is just not handled currently.  If you have
> python-3… installed and you install python-2… in the same profile, then
> python-3… would be replaced, but if you install both packages in the
> same command, then both would be installed.

Oh, really?  This must be a bug in ‘manifest-transaction-effects’ then, no?

Ludo’.

[PATCH 3/3] gnu: wget: Upgrade to 1.16.

[Eric Bavier]

* gnu/packages/wget.scm (wget)[source]: Upgrade to 1.16.
  [inputs]: Add libidn.
  [native-inputs]: Add python, perl-http-daemon, and
  perl-io-socket-ssl.
---
 gnu/packages/wget.scm |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/wget.scm b/gnu/packages/wget.scm
index fb5fbf6..674cc07 100644
--- a/gnu/packages/wget.scm
+++ b/gnu/packages/wget.scm
@@ -20,7 +20,10 @@
 (define-module (gnu packages wget)
   #:use-module (guix licenses)
   #:use-module (gnu packages gnutls)
+  #:use-module (gnu packages libidn)
+  #:use-module (gnu packages python)
   #:use-module (gnu packages perl)
+  #:use-module (gnu packages web)
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix build-system gnu))
@@ -28,7 +31,7 @@
 (define-public wget
   (package
 (name "wget")
-(version "1.15")
+(version "1.16")
 (source
  (origin
   (method url-fetch)
@@ -36,12 +39,17 @@
   version ".tar.xz"))
   (sha256
(base32
-"1yw0sk4mrs7bvga3c79rkbhxivmw8cs3b5wq3cglp1f9ai1mz2ni"
+"1rxhr3jmgbwryzl51di4avqxw9m9j1z2aak8q1npns0p184xsqcj"
 (build-system gnu-build-system)
+;; TODO: Add libpsl to inputs
 (inputs
- `(("gnutls" ,gnutls)))
+ `(("gnutls" ,gnutls)
+   ("libidn" ,libidn)))
 (native-inputs
- `(("perl" ,perl)))
+ `(("perl" ,perl)
+   ("python" ,python)   ;for testenv suite
+   ("perl-http-daemon" ,perl-http-daemon)
+   ("perl-io-socket-ssl" ,perl-io-socket-ssl)))
 (home-page "http://www.gnu.org/software/wget/";)
 (synopsis "Non-interactive command-line utility for downloading files")
 (description
-- 
1.7.9.5

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

[Andreas Enge]

On Thu, Oct 30, 2014 at 03:52:50PM +0300, Alex Kost wrote:
> I don't understand why you call it a mistake.  It's just a package name
> used by some distributions (and I think it's a good name).  Is there a
> convention to use “…-fonts-ttf” in Guix?

It may be a good name, but the Guix convention is to not choose names, but
to simply use the upstream name. This is described in the packaging
guidelines, section 6.5.2 of the documentation:
"Both are usually the same and correspond to the lowercase conversion of
the project name chosen upstream, with underscores replaced with hyphens".
So liberation-fonts-ttf-2.00.1.tar.gz becomes liberation-fonts-ttf.
(Admittedly "project name" is a bit vague; it means "tarball name", the
aim is not to call all packages of the x.org system x-org, so that
only one of them could be installed ;-)).

And dejavu-fonts-ttf-2.34.tar.bz2 should become dejavu-fonts-ttf. 

And font-adobe-100dpi-1.0.3.tar.bz2 should have become font-adobe-100dpi,
but apparently I made a mistake and called it font-adobe100dpi.
Another mistake to correct. In particular, it is not called
adobe-100dpi-fonts-pcf.


We have different naming rules for python and perl modules. We could also
agree on different naming rules for fonts. But they would need to be
consistent, in particular over different font formats, and mechanically
applicable. Personally, I do not see a pressing need.

Andreas

Re: Problems with downloading from https

[Andreas Enge]

On Thu, Oct 30, 2014 at 03:31:15PM +0300, Alex Kost wrote:
> I think the latter is a bug.  IMHO it shouldn't be possible to install
> several packages with the same name in one profile.

Well, having python 2 and 3 is reasonable, and from what I saw in their
naming scheme, it is entirely possible (the python binary being renamed
to python 3). Qt 4 and 5 are, I think, another case. How about GTK+ 2 and 3?

Of course we could rename the packages, but this is not our policy so far.

Andreas

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

[Alex Kost]

Andreas Enge (2014-10-30 10:56 +0300) wrote:

> On Thu, Oct 30, 2014 at 10:27:49AM +0300, Alex Kost wrote:
>> Why should?  What about “ttf-dejavu”?  Should it be called
>> “dejavu-fonts-ttf” then?
>
> Yes, that was a mistake, maybe inspired from the debian package name.
> We should rename it.

I don't understand why you call it a mistake.  It's just a package name
used by some distributions (and I think it's a good name).  Is there a
convention to use “…-fonts-ttf” in Guix?

>> Then it shouldn't be prefixed with "ttf".  I suggest to use "ttf-…" name
>> only for packages that provide truetype fonts only.  As for the other
>> font packages, I think they should have "font"/"fonts" in their names,
>> no matter would it be in the beginning (font-misc-ethiopic) or in the
>> end (terminus-font).
>
> Then what if it contains other types of fonts? Texlive-data/texfm-dist/fonts
> contains the following 20 subdirectories:
> afm  cmap  fea  map   ofm   ovf  pfm  sfd tfm   type1
> cid  enc   lig  misc  opentype  ovp  pk   source  truetype  vf
> (not all of them are fonts, some are just metrics and some I do not know).
> Would you suggest to use prefixes type1-, opentype-, pk- also?
> Only if the package contains exactly one format? I think modifying our
> package name rules for fonts will open a can of worms.

I think they should be called “texlive-…”.

What I see in "Arch Linux" is a lot of “ttf-…” packages (including
“ttf-liberation” and “ttf-dejavu”).  IIUC Debian uses the same names for
TrueType fonts.  And I like it.  But anyway, if “liberation-fonts-ttf”
is the prefered variant, I'll fix my patch.  But I think “ttf-dejavu”
should be renamed into “dejavu-fonts-ttf” at first.  And what about
“freefont-ttf” and “ttf-bitstream-vera”?

[sr #108678] Creating extra repository guix/artwork.git

[Ludovic Courtès]

URL:
  

 Summary: Creating extra repository guix/artwork.git
 Project: Savannah Administration
Submitted by: civodul
Submitted on: Fri 31 Oct 2014 06:20:07 PM GMT
Category: Developer Source Code Repositories
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: l...@gnu.org
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hello,

Would it be possible to create an extra Git repo for GNU Guix, as
guix/artwork.git?

This is the place where logos and artwork for Guix would go.

TIA!

Ludo'.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Patch-shebangs phase and created binaries

[Andreas Enge]

Hello,

should the final patch-shebangs phase not include the generated output
path (well, the bin subdirectory) in its $PATH?

In texlive I see lines such as
patch-shebang: ./texmf-dist/tex/luatex/lualibs/lualibs-compat.lua: warning: no 
binary for interpreter `texlua' found in $PATH

The file starts with 
#!/usr/bin/env texlua
and texlua is a binary created in the texlive output (actually, bin/texlua is
a symbolic link to the elf binary bin/luatex).

Andreas

Re: Font package naming convention

[Andreas Enge]

On Fri, Oct 31, 2014 at 06:58:40PM +0100, Andreas Enge wrote:
> On Fri, Oct 31, 2014 at 01:02:44AM +0300, Alex Kost wrote:
> > Andreas prefers this ↑
> I did not say this.

Sorry, I actually did prefer this ;-)  But I am open to discussion.

Andreas

Re: Font package naming convention

[Andreas Enge]

On Fri, Oct 31, 2014 at 01:02:44AM +0300, Alex Kost wrote:
> I suggest this ↑  IIUC it is a common practice in other distributions.

This is absolutely no argument for us! We have quite a few different
practices from other distributions (and some of them are more logical,
I think, like trying to stick to upstream instead of making our life
more difficult).

> Andreas prefers this ↑

I did not say this. I simply pointed out two different "algorithmic" naming
schemes in the sense that there is an algorithm transforming an upstream name
into a package name. Both have strange effects, I think.

> I'm against any strict binding to an upstream name.  Why should we stick
> to a (potentially strange) upstream name if we know better how a package
> should be called?

This is what we have done so far and it is part of the packaging guidelines.
Otherwise there would be absolutely no limit to renaming and bikeshedding.
What if you think that "foo" should be renamed "bar" and I think it should
be renamed "truc"?

If you want to make a suggestion of a naming scheme that others can follow,
please come up with a description of an algorithm as for python modules -
a transformation of an upstream name into a package name.

To be constructive (which is a bit difficult, as I am still not convinced
we should have a special naming scheme for fonts, but admittedly it has
advantages!), here are a few questions that we should answer:

1)
Do we want to have the font format as part of the name?
Not having it would make things easier for packages containing several
formats; a user looking only for special types of fonts would then have to
go through the package descriptions. We could then prepend "font" or "fonts"
to the package name and drop it from inside (or keep it additionally inside,
which would be somewhat strange, but would avoid strange names occurring for
"unifont", for instance).

2)
Do we distinguish between packages containing one font (possibly in several
variants), prepending it with "font-", and packages containing several
fonts, prepending it with "fonts-", or do we go with a common prefix?

3)
If we want to add the font format to the package name, which font formats
do we want to "support"? We need a complete list.

4)
For the sake of argument, assume we decided on ttf and otf in 2).
Then packages containing only ttf could be prepended with "ttf" or "ttf-font"
or something like this, likewise for packages containing only otf.
We could use the "file extension" such as "ttf", or any longer version
such as "true-type-fonts".

What would we do for packages containing exactly both?
None of them?
ttf and others?
otf and others?
ttf, otf and others?
There are several solutions to this.
Notice that if our list of font formats has n entries, we have 2^n-1 possible
combinations. So the longer the list, the less reasonable it seems to prepend
all contained formats.
Notice that such a naming scheme also puts the burden on the packager of
determining the exact list of font formats contained in an upstream package.

I think we need to provide answers to these questions and maybe others I
overlooked.

With the hope that this rather long message may advance the discussion,

Andreas

Re: [PATCH 0/3]: gnu: wget: Upgrade to 1.16.

[Ludovic Courtès]

Eric Bavier  skribis:

> This upgrade fixes CVE-2014-4877.  In the previous release, the testcases
> would fail but be marked as "skipped".  That behavior changed to hard failures
> in 1.16, thus the need for the additional native-input perl modules.

This all looks good to me, thank you!

Ludo’.

Re: Font package naming convention

[Ludovic Courtès]

Andreas Enge  skribis:

> On Fri, Oct 31, 2014 at 01:02:44AM +0300, Alex Kost wrote:

[...]

>> I'm against any strict binding to an upstream name.  Why should we stick
>> to a (potentially strange) upstream name if we know better how a package
>> should be called?
>
> This is what we have done so far and it is part of the packaging guidelines.

Yes, and I think we should stick to that for software packages, with the
already-documented exceptions of ‘perl-’ and ‘python-’.

Now, I think a good reason to add an exception for fonts is that it
would make it easier to search for them: a software package can be
searched by keyword quite reasonably (with ‘guix package --search’ &
co.), but this is not the case for a font.  Being able to type ‘guix
package -A ^font’ (say) is convenient.

Furthermore, unlike software packages, what matters here is the actual
name of the font or font collection, not the “system name” or “tarball
name.”

> 1)
> Do we want to have the font format as part of the name?
> Not having it would make things easier for packages containing several
> formats; a user looking only for special types of fonts would then have to
> go through the package descriptions. We could then prepend "font" or "fonts"
> to the package name and drop it from inside (or keep it additionally inside,
> which would be somewhat strange, but would avoid strange names occurring for
> "unifont", for instance).
>
> 2)
> Do we distinguish between packages containing one font (possibly in several
> variants), prepending it with "font-", and packages containing several
> fonts, prepending it with "fonts-", or do we go with a common prefix?
>
> 3)
> If we want to add the font format to the package name, which font formats
> do we want to "support"? We need a complete list.
>
> 4)
> For the sake of argument, assume we decided on ttf and otf in 2).
> Then packages containing only ttf could be prepended with "ttf" or "ttf-font"
> or something like this, likewise for packages containing only otf.
> We could use the "file extension" such as "ttf", or any longer version
> such as "true-type-fonts".

All good points, indeed.

I’m not completely sure we can come up with a strict algorithm for the
naming scheme that we will not want to change two weeks later.  ;-)

Here’s a possible answer to the above questions, informally:

  • Use ‘font-FOUNDRY-FAMILY’ or ‘font-FAMILY’ or
‘font-FOUNDRY-COLLECTION’ or ‘font-COLLECTION’ as the name.

Examples: ‘font-bitstream-vera’, ‘font-liberation’, ‘font-unifont’.

  • Use ‘font-.*-FORMAT’ only when there happens to be separate packages
for separate formats.  FORMAT would be the format short name, like
‘ttf’, ‘otf’, ‘type1’.

WDYT, fellow nitpickers?  :-)

IMO the goal should be to find something convenient for users.
Sometimes, maybe, there will be several valid choices for the package
name, but that’s fine, I think.

Ludo’.

[PATCH] gnu: ruby: Update to 2.1.4.

[David Thompson]

This patch updates Ruby to 2.1.4, which includes security fixes for 2
vulnerabilities.

More details here:
https://www.ruby-lang.org/en/news/2014/10/27/ruby-2-1-4-released/

Okay to push?

>From 12d39eb5145e42669748f172f9433ea8e6ead020 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Fri, 31 Oct 2014 18:57:30 -0400
Subject: [PATCH] gnu: ruby: Update to 2.1.4.

* gnu/packages/ruby.scm: Update.  Remove the now redundant readline patch.
---
 gnu/packages/ruby.scm | 43 ++-
 1 file changed, 18 insertions(+), 25 deletions(-)

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index a33daba..5cdd722 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -36,44 +36,37 @@
 (define-public ruby
   (package
 (name "ruby")
-(version "2.1.3")
+(version "2.1.4")
 (source
  (origin
(method url-fetch)
(uri (string-append "http://cache.ruby-lang.org/pub/ruby/";
(version-major+minor version)
-   "/ruby-" version ".tar.bz2"))
+   "/ruby-" version ".tar.xz"))
(sha256
 (base32
- "1mkndw0by11n6lyvq7dzly702yyqg5x0fcvfqrn9y4p49bw75kin"
+ "1ksgx1rn4wp80290399q6d26zpbx0nb3sxh45wl4wr58raxmrk71"
 (build-system gnu-build-system)
 (arguments
  `(#:test-target "test"
#:parallel-tests? #f
#:phases
-   (alist-cons-after
-;; Minor patch:
-;; https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/45225/diff/
-'unpack 'patch-readline
+   (alist-cons-before
+'configure 'replace-bin-sh
 (lambda _
-  (substitute* '("ext/readline/readline.c")
-(("Function ") "rl_hook_func_t ")))
-(alist-cons-before
- 'configure 'replace-bin-sh
- (lambda _
-   (substitute* '("Makefile.in"
-  "ext/pty/pty.c"
-  "io.c"
-  "lib/mkmf.rb"
-  "process.c"
-  "test/rubygems/test_gem_ext_configure_builder.rb"
-  "test/rdoc/test_rdoc_parser.rb"
-  "test/ruby/test_rubyoptions.rb"
-  "test/ruby/test_process.rb"
-  "test/ruby/test_system.rb"
-  "tool/rbinstall.rb")
- (("/bin/sh") (which "sh"
- %standard-phases
+  (substitute* '("Makefile.in"
+ "ext/pty/pty.c"
+ "io.c"
+ "lib/mkmf.rb"
+ "process.c"
+ "test/rubygems/test_gem_ext_configure_builder.rb"
+ "test/rdoc/test_rdoc_parser.rb"
+ "test/ruby/test_rubyoptions.rb"
+ "test/ruby/test_process.rb"
+ "test/ruby/test_system.rb"
+ "tool/rbinstall.rb")
+(("/bin/sh") (which "sh"
+%standard-phases)))
 (inputs
  `(("readline" ,readline)
("openssl" ,openssl)
-- 
2.1.1


-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

Re: [PATCH] gnu: ruby: Update to 2.1.4.

[Ludovic Courtès]

David Thompson  skribis:

> This patch updates Ruby to 2.1.4, which includes security fixes for 2
> vulnerabilities.
>
> More details here:
> https://www.ruby-lang.org/en/news/2014/10/27/ruby-2-1-4-released/
>
> Okay to push?

LGTM!

> From 12d39eb5145e42669748f172f9433ea8e6ead020 Mon Sep 17 00:00:00 2001
> From: David Thompson 
> Date: Fri, 31 Oct 2014 18:57:30 -0400
> Subject: [PATCH] gnu: ruby: Update to 2.1.4.
>
> * gnu/packages/ruby.scm: Update.  Remove the now redundant readline patch.
 ^
This should mention the variable name.

Ludo’.

Re: [PATCH] gnu: ruby: Update to 2.1.4.

[David Thompson]

Ludovic Courtès  writes:

> David Thompson  skribis:
>
>> From 12d39eb5145e42669748f172f9433ea8e6ead020 Mon Sep 17 00:00:00 2001
>> From: David Thompson 
>> Date: Fri, 31 Oct 2014 18:57:30 -0400
>> Subject: [PATCH] gnu: ruby: Update to 2.1.4.
>>
>> * gnu/packages/ruby.scm: Update.  Remove the now redundant readline patch.
>  ^
> This should mention the variable name.

Ugh. Of course I would forget something so basic.  Sorry for pushing
before you had a chance to review.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate

[sr #108678] Creating extra repository guix/artwork.git

[Assaf Gordon]

Update of sr #108678 (project administration):

  Status:None => Done   
 Assigned to:None => agn
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Hello,

I've created a new sub-repository. You can access it in the following ways:

Anonymous git access:
  git clone git://git.sv.gnu.org/guix/guix-artwork.git

Read/Write Access:
  git clone @git.sv.gnu.org:/srv/git/guix/guix-artwork.git

Web Access:
  http://git.sv.gnu.org/gitweb/?p=guix/guix-artwork.git
  http://git.sv.gnu.org/cgit/guix/guix-artwork.git



I'm closing this item,
but If there are any issues, please let me now.

Regards,
 - Assaf


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/