Re: [PATCH 6/7] guix build: Add 'build-package'.

[Alex Kost]

Ludovic Courtès (2015-09-22 18:12 +0300) wrote:

> Alex Kost  skribis:
[...]
>> 'build-package' will be placed in (guix scripts), and it looks like a
>> rather general procedure.  For example, it may be used for something
>> like ‘guix build --package-from-file’ suggested by David:
>> .
>
> ‘guix package --install-from-file’ was committed but I don’t think it
> actually needs ‘build-package’.

David also suggested the same option for ‘guix build’, and that's what I
talked about (not ‘guix package’) — it wasn't implemented (presumably
because there was no ‘build-package’ analog).

>> From ce35de1359ae11a2e73f129db4f7685985f3d041 Mon Sep 17 00:00:00 2001
>> From: Alex Kost 
>> Date: Thu, 23 Jul 2015 16:16:41 +0300
>> Subject: [PATCH] scripts: Add 'build-package'.
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> * guix/scripts/system.scm (maybe-build): Move to ...
>> * guix/scripts.scm: ...here.
>>   (build-package): New procedure.
>>
>> Co-authored-by: Ludovic Courtès 
>
> OK!

Thank you, I have pushed this patch and the commits for the elisp side
you OKeyed a month ago.  So I also send the rest patches to finish this
"guix-devel.el" stuff.

-- 
Alex

[PATCH 2/2] emacs: Add 'guix-devel-build-package-definition'.

[Alex Kost]

Ludovic Courtès (2015-08-25 23:59 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-08-18 16:50 +0300) wrote:
>>
>>> Alex Kost  skribis:
>>>
 And finally, I'm afraid building guix package in a Geiser REPL may not
 be very useful because of 
 (you have wait for the REPL command to be finished before continuing to
 edit .scm-file).
>>>
>>> Bummer, indeed.  I wonder if that could be worked around by spawning a
>>> new Guile server thread that would be used to build the package, and
>>> opening a new Geiser REPL connected to that thread?  Maybe too complex,
>>> though.
>>
>> That's what I did for *Guix REPL*: it is a server by default, and there
>> is *Guix Internal REPL* which connects to it (there is a commentary
>> about it in "emacs/guix-backend.el").
>>
>> But I don't think it should be done here: as a user I expect that the
>> building will be performed in the current Geiser REPL, so it's up to me
>> (as a user) to decide what repl it is.
>>
>> Also to avoid that limitation, a user can just run another Geiser REPL
>> after the building begins, and can continue to edit a scheme file with
>> the help of the current REPL, while the building will continue in the
>> previous one.  (I will mention this in the manual)
>
> OK, sounds good!

Done.

Ludovic Courtès (2015-09-09 23:11 +0300) wrote:

> Alex Kost  skribis:
>
>> As a workaround for this issue it was proposed¹ to transform
>> ‘current-build-output-port’ into a procedure (I have checked that it
>> solves the problem).  What do you think about it?  Perhaps to make sure
>> that the port will be always the same define it like this:
>>
>> (define current-build-output-port (memoize current-error-port))
>>
>> Is it acceptable?
>
> No, ‘current-build-output-port’ should remain a SRFI-39 parameter so
> that callers can easily rebind it.
>
> However, perhaps the guix.el code could do:
>
>   (current-build-output-port (current-error-port))
>
> at startup; would that be doable?

Also done.  The workaround appeared to be not so ugly as I thought at
first, thanks for the pointer!

>From 8011d1c62b49c309ddba933d27fc4c86eabf60a2 Mon Sep 17 00:00:00 2001
From: Alex Kost 
Date: Fri, 24 Jul 2015 20:31:11 +0300
Subject: [PATCH 2/2] emacs: Add 'guix-devel-build-package-definition'.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested by Ludovic Courtès .

* emacs/guix-guile.el (guix-guile-definition-regexp): New variable.
  (guix-guile-current-definition, guix-guile-boolean): New functions.
* emacs/guix-devel.el: Require 'guix-base'.
  (guix-devel-repl-processes): New variable.
  (guix-devel-setup-repl, guix-devel-setup-repl-maybe): New functions.
  (guix-devel-build-package-definition): New command.
* doc/emacs.texi (Emacs Development): Document it.
---
 doc/emacs.texi  | 24 
 emacs/guix-devel.el | 40 
 emacs/guix-guile.el | 22 ++
 3 files changed, 86 insertions(+)

diff --git a/doc/emacs.texi b/doc/emacs.texi
index d44d329..b6f2701 100644
--- a/doc/emacs.texi
+++ b/doc/emacs.texi
@@ -659,4 +659,28 @@ want to use a module it defines, so you switch to the Geiser REPL and
 write @code{,use (some module)} there.  You may just use this command
 instead (@code{guix-devel-use-module}).
 
+@item C-c . b
+Build a package defined by the current variable definition.  The
+building process is run in the current Geiser REPL.  If you modified the
+current package definition, don't forget to reevaluate it before calling
+this command---for example, with @kbd{C-M-x} (@pxref{To eval or not to
+eval,,, geiser, Geiser User Manual})
+(@code{guix-devel-build-package-definition}).
+
 @end table
+
+Unluckily, there is a limitation related to long-running REPL commands.
+When there is a running process in a Geiser REPL, you are not supposed
+to evaluate anything in a scheme buffer, because this will ``freeze''
+the REPL: it will stop producing any output (however, the evaluating
+process will continue---you will just not see any progress anymore).  Be
+aware: even moving the point in a scheme buffer may ``break'' the REPL
+if Autodoc (@pxref{Autodoc and friends,,, geiser, Geiser User Manual})
+is enabled (which is the default).
+
+So you have to postpone editing your scheme buffers until the running
+evaluation will be finished in the REPL.
+
+Alternatively, to avoid this limitation, you may just run another Geiser
+REPL, and while something is being evaluated in the previous REPL, you
+can continue editing a scheme file with the help of the current one.
diff --git a/emacs/guix-devel.el b/emacs/guix-devel.el
index ed82e33..6de49be 100644
--- a/emacs/guix-devel.el
+++ b/emacs/guix-devel.el
@@ -27,6 +27,7 @@
 (require 'guix-guile)
 (require 'guix-geiser)
 (require 'guix-utils)
+(require 'guix-base)
 
 

Re: IPython native kernel missing?

[Ricardo Wurmus]

Hi Craig,

>> I’m trying to package Jupyter (an improved version of IPython, from what
>> I’ve heard) and noticed that the tests for jupyter-client fail because
>> the native “python3” (or “python2”) kernel cannot be found.  According
>> to the documentation, this “kernel” should always be available and
>> doesn’t need to be installed.
>>
>> Looking around in the sources of python-ipython (an input to the Jupyter
>> packages I’m working on) I see that this file
>>
>> $out/lib/python2.7/site-packages/IPython/kernel/kernelspec.py
>>
>> contains hard-coded system paths:
>>
>> SYSTEM_KERNEL_DIRS = ["/usr/share/jupyter/kernels",
>>   "/usr/local/share/jupyter/kernels",
>>  ]
>>
>> Yet I have not found any directory named “kernels” in the output of the
>> python-ipython package.  Nor have I found any “kernel.json” files.  It
>> seems to me that IPython should install at least the native kernel at
>> some point, but currently doesn’t seem to include it.
>>
>> I would like to fix this, but I really don’t know anything about IPython
>> and I don’t even know what the word “kernel” describes in this context.
>> Could someone with an understanding of IPython please take a look at
>> this?
> IIRC we are using requirements.txt to determine all dependencies, which
> it seems is not used by this project.  This is possibly because the
> output is slightly different depending on the python version.
>
> setup.py includes the ipykernel package, but to get a full list of
> dependencies we need to install using pip in a virtualenv, then run pip
> freeze to generate requirements.txt.
>
> I've attached what I got as a result from python 2 and 3.

These are the requirements for Jupyter, right?  They seem familiar
because I have packaged a couple of those in the list.  I’ll try to
package the missing dependencies (in particular “ipykernel”) and add it
to the inputs to see if this makes a difference.

Thank you!

~~ Ricardo

Re: [PATCH] Gracefully handle incompatible locale data

[Ondřej Bílka]

On Tue, Sep 22, 2015 at 11:22:40PM +0200, Ludovic Courtès wrote:
> Ondřej Bílka  skribis:
> 
> > On Tue, Sep 22, 2015 at 05:27:55PM +0200, Ludovic Courtès wrote:
> >> With libc 2.22 people are starting to realize that libc does not
> >> guarantee that it can load locale data built with another libc version,
> >> but they learn it the hard way:
> >> 
> >>   loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof 
> >> (_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' 
> >> failed.
> >> 
> >> This patch changes such conditions to return EINVAL instead of aborting.
> >> 
> >> WDYT?
> >> 
> > While that assert is quite cryptic I dont see why just returning EINVAL is
> > better. How do you distinguish that its wrong locale version versus not
> > installed?
> 
> The rest of this function already returns EINVAL when something is
> fishy.  This patch makes the behavior more consistent.
> 
Then I take that back. But I don't see how this is reliable assertion to
detect different libc version. So could you as followup patch add
version field and check that instead this assert?

Re: [PATCH 2/3] gnu: Update python-fixtures

[Cyril Roelandt]

On 09/22/2015 09:16 PM, Thompson, David wrote:
> On Mon, Sep 21, 2015 at 6:31 PM, Cyril Roelandt  wrote:
>> * gnu/packages/python.scm (python-fixtures): Update.
>> * gnu/packages/python.scm (python-fixtures-0.3.16,
>>   python2-fixtures-0.3.16, python-pbr-0.11,
>>   python2-pbr-0.11): New variables.
>> * gnu/packages/python.scm (python-testrepository): Use python-fxitures-0.3.16
>>   instead of python-fixtures in the inputs.
> 
> One package update or new package per patch, please.
> 

I know it is usually done like this, but I feel this is a bit special,
since all these changes are only done in order to update
python-fixtures. I could have:

1) renamed python-fixtures to python-fixtures-0.3.16 and changed inputs
from "python-fixtures" to "python-fixtures-0.3.16" for all packages that
depend on fixtures
2) added python-pbr-0.11
3) added python-fixtures
4) changed inputs from "python-fixtures-0.3.16" to "python-fixtures" for
all packages that depend on fixtures

But I feel it would be incredibly confusing when looking at "git log". WDYT?

Cyril.

Re: [PATCH 2/2] emacs: Add 'guix-devel-build-package-definition'.

[Ludovic Courtès]

Alex Kost  skribis:

> From 8011d1c62b49c309ddba933d27fc4c86eabf60a2 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Fri, 24 Jul 2015 20:31:11 +0300
> Subject: [PATCH 2/2] emacs: Add 'guix-devel-build-package-definition'.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Suggested by Ludovic Courtès .
>
> * emacs/guix-guile.el (guix-guile-definition-regexp): New variable.
>   (guix-guile-current-definition, guix-guile-boolean): New functions.
> * emacs/guix-devel.el: Require 'guix-base'.
>   (guix-devel-repl-processes): New variable.
>   (guix-devel-setup-repl, guix-devel-setup-repl-maybe): New functions.
>   (guix-devel-build-package-definition): New command.
> * doc/emacs.texi (Emacs Development): Document it.

OK, thank you!

Ludo’.

[PATCH] Gracefully handle incompatible locale data

[Ludovic Courtès]

With libc 2.22 people are starting to realize that libc does not
guarantee that it can load locale data built with another libc version,
but they learn it the hard way:

  loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof 
(_nl_value_type_LC_COLLATE) / sizeof (_nl_value_type_LC_COLLATE[0]))' failed.

This patch changes such conditions to return EINVAL instead of aborting.

WDYT?

Thanks,
Ludo’.

2015-10-22  Ludovic Courtès  

* locale/loadlocale.c (_nl_intern_locale_data): Change assertion
on CNT to a conditional jump to 'puntdata'.

diff --git a/locale/loadlocale.c b/locale/loadlocale.c
index fdba6e9..e04e720 100644
--- a/locale/loadlocale.c
+++ b/locale/loadlocale.c
@@ -122,8 +122,9 @@ _nl_intern_locale_data (int category, const void *data, size_t datasize)
 	{
 #define CATTEST(cat)		\
 	case LC_##cat:		\
-	  assert (cnt < (sizeof (_nl_value_type_LC_##cat)		  \
-			 / sizeof (_nl_value_type_LC_##cat[0])));	  \
+	  if (cnt >= (sizeof (_nl_value_type_LC_##cat)		\
+		  / sizeof (_nl_value_type_LC_##cat[0])))	\
+	goto puntdata;	\
 	  break
 	  CATTEST (NUMERIC);
 	  CATTEST (TIME);

Re: [PATCH] Add XJackFreak.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> From e2a9d5bd613da81a050875af5f580da87dfa08b9 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Sat, 19 Sep 2015 13:16:38 +0200
> Subject: [PATCH] gnu: Add XJackFreak.
>
> * gnu/packages/audio.scm (xjackfreak): New variable.

[...]

> +   (list (string-append "docdir=" (assoc-ref %outputs "out")
> +"/share/doc/"))

Assuming the doc goes to PREFIX/share/doc/xjackfreak (and not just
PREFIX/share/doc), it LGTM.

Thanks!

Ludo’.

Re: modprobe on guix

[Petter]

> One solution would be to provide a /etc/environment file containing the
> right value for LINUX_MODULE_DIRECTORY (‘sudo’ honors that, according to
> sudoers(5).)

Yes, this is interesting. When i considered this previously i
prematurely put it aside because it requires PAM, and i wrongly
concluded our sudo wasn't configured with PAM (based on package
definition). On second look, i see PAM is on by default for Linux
distributions when building sudo; also running  sudo -V  as root user
confirms this. However, creating /etc/environment and putting stuff
there doesn't have any effect for me. But i believe the reason is that a
module needs to be added to linux-pam, namely pam_env[1].

I'd like to have a go at this and see if i can make a patch for this.

Maybe it makes sense to put /all/ the environment variables, especially
for root operations, in /etc/environment? From what i understand
variables from outside this file will not be expanded, so if not it
would mean duplicating definitions. Also, having this as a
just-for-those-sudo-users would be easy for root users to miss
updating. Then obviously root logins would have to make use of this file
as well, but i'm sure that can be arranged. I'll look more into this.

[1] http://www.linux-pam.org/Linux-PAM-html/sag-pam_env.html

Petter

[PATCH 0/2] lint: Texinfo again.

[Mathieu Lirzin]

As a follow up of

  

I have tried to implement the requested changes.  There is a problem with
‘check-end-of-sentence-space’ because Texinfo conversion implicitly add
missing spaces so they are not detected by ‘guix lint’.  Maybe we should check
this on the raw description instead?


Mathieu Lirzin (2):
  lint: Check non-translated package descriptions.
  lint: Accept '`' character.

 guix/scripts/lint.scm | 19 +++
 guix/ui.scm   |  1 +
 2 files changed, 12 insertions(+), 8 deletions(-)

-- 
2.5.1

[PATCH 1/2] lint: Check non-translated package descriptions.

[Mathieu Lirzin]

* guix/ui.scm (texi->plain-text): Export.
* guix/scripts/lint.scm (check-description-style): Use it instead of
  'package-description-string'.
---
 guix/scripts/lint.scm | 17 ++---
 guix/ui.scm   |  1 +
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/guix/scripts/lint.scm b/guix/scripts/lint.scm
index 8224f54..a52a9eb 100644
--- a/guix/scripts/lint.scm
+++ b/guix/scripts/lint.scm
@@ -143,12 +143,14 @@ monad."
 (_ "description should not be empty")
 'description)))
 
-  (define (check-texinfo-markup package)
-"Check that PACKAGE description can be parsed as a Texinfo fragment."
+  (define (check-texinfo-markup description)
+"Check that DESCRIPTION can be parsed as a Texinfo fragment.  If the
+markup is valid return a plain-text version of DESCRIPTION, otherwise #f."
 (catch 'parser-error
-  (lambda () (package-description-string package))
+  (lambda () (texi->plain-text description))
   (lambda (keys . args)
-(emit-warning package (_ "Texinfo markup in description is invalid")
+(emit-warning package (_ "Texinfo markup in description is invalid"))
+#f)))
 
   (define (check-proper-start description)
 (unless (or (properly-starts-sentence? description)
@@ -179,9 +181,10 @@ by two spaces; possible infraction~p at ~{~a~^, ~}")
   (let ((description (package-description package)))
 (when (string? description)
   (check-not-empty description)
-  (check-texinfo-markup package)
-  (check-proper-start description)
-  (check-end-of-sentence-space description
+  (and=> (check-texinfo-markup description)
+ (lambda (texi)
+   (check-proper-start texi)
+   (check-end-of-sentence-space texi))
 
 (define (check-inputs-should-be-native package)
   ;; Emit a warning if some inputs of PACKAGE are likely to belong to its
diff --git a/guix/ui.scm b/guix/ui.scm
index 4a3630f..055f2c2 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -75,6 +75,7 @@
 switch-symlinks
 config-directory
 fill-paragraph
+texi->plain-text
 package-description-string
 string->recutils
 package->recutils

[PATCH 2/2] lint: Accept '`' character.

[Mathieu Lirzin]

* guix/scripts/lint.scm (properly-starts-sentence?): Accept Texinfo
  highlighting commands as a sentence start.
---
 guix/scripts/lint.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/scripts/lint.scm b/guix/scripts/lint.scm
index a52a9eb..74989a6 100644
--- a/guix/scripts/lint.scm
+++ b/guix/scripts/lint.scm
@@ -129,7 +129,7 @@ monad."
   (exit 0))
 
 (define (properly-starts-sentence? s)
-  (string-match "^[(\"'[:upper:][:digit:]]" s))
+  (string-match "^[(\"'`[:upper:][:digit:]]" s))
 
 (define (starts-with-abbreviation? s)
   "Return #t if S starts with what looks like an abbreviation or acronym."

[PATCH] Add Zope Public License.

[Ricardo Wurmus]

>From ccc79ada2f48569a57cb310040e38d4c52904171 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Tue, 22 Sep 2015 13:43:53 +0200
Subject: [PATCH] licenses: Add Zope Public License.

* guix/licenses.scm (zpl2.1): New variable.
---
 guix/licenses.scm | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/guix/licenses.scm b/guix/licenses.scm
index c3b76af..7e05b32 100644
--- a/guix/licenses.scm
+++ b/guix/licenses.scm
@@ -61,6 +61,7 @@
 sleepycat
 vim
 x11 x11-style
+zpl2.1
 zlib
 fsf-free))
 
@@ -382,6 +383,11 @@ which may be a file:// URI pointing the package's tree."
 "Check the URI for details.  "
 comment)))
 
+(define zpl2.1
+  (license "Zope Public License 2.1"
+   "http://directory.fsf.org/wiki?title=License:ZopePLv2.1;
+   "https://www.gnu.org/licenses/license-list.html#Zope2.0;))
+
 (define zlib
   (license "Zlib"
"http://www.gzip.org/zlib/zlib_license.html;
-- 
2.1.0

Re: [PATCH] emacs: Improve 'guix-prettify-regexp'.

[Alex Kost]

Ludovic Courtès (2015-09-21 19:01 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-09-20 19:43 +0300) wrote:
>>
>>> Alex Kost  skribis:
>> [...]
  (defcustom guix-prettify-regexp
 -  (rx "/"
 -  (or "nix" "gnu")
 -  "/store/"
 +  (rx "/" (or "store" "nar" "log") "/"
>>>
>>> Maybe explicitly show in a comment the URLs and file names that we
>>> intend to match.
>>
>> OK, I'll add this comment.  BTW, are there any other places where we can
>> meet these hashes?
>
> Hmm no, at least not yet.

OK, thanks, pushed.

-- 
Alex

Re: [PATCH 1/1] gnu: recutils: Add libuuid to native-inputs.

[Ludovic Courtès]

Leo Famulari  skribis:

> * gnu/packages/databases.scm (recutils)[native-inputs]: Add "libuuid".

Applied, thanks!

Ludo’.

Re: IPython native kernel missing?

[Craig Barneses]

Hi Ricardo,


On 21/09/15 16:28, Ricardo Wurmus wrote:
> Hi Guix,
>
> I’m trying to package Jupyter (an improved version of IPython, from what
> I’ve heard) and noticed that the tests for jupyter-client fail because
> the native “python3” (or “python2”) kernel cannot be found.  According
> to the documentation, this “kernel” should always be available and
> doesn’t need to be installed.
>
> Looking around in the sources of python-ipython (an input to the Jupyter
> packages I’m working on) I see that this file
>
> $out/lib/python2.7/site-packages/IPython/kernel/kernelspec.py
>
> contains hard-coded system paths:
>
> SYSTEM_KERNEL_DIRS = ["/usr/share/jupyter/kernels",
>   "/usr/local/share/jupyter/kernels",
>  ]
>
> Yet I have not found any directory named “kernels” in the output of the
> python-ipython package.  Nor have I found any “kernel.json” files.  It
> seems to me that IPython should install at least the native kernel at
> some point, but currently doesn’t seem to include it.
>
> I would like to fix this, but I really don’t know anything about IPython
> and I don’t even know what the word “kernel” describes in this context.
> Could someone with an understanding of IPython please take a look at
> this?

looking at setup.py [0] it seems to be a separate module that is pulled
in when setup.py is run. 

Are we depending on requirements.txt to give us this information, as
this seems to be absent from this project?

if so, I've attached a requirements.txt for python 2 and 3 generated
from version in pypi.  I expect the reason that it is not included in
the package is that it's different depending on the python version.


Regards

Craig

[0] https://github.com/jupyter/jupyter/blob/master/setup.py
decorator==4.0.2
ipykernel==4.0.3
ipython==4.0.0
ipython-genutils==0.1.0
ipywidgets==4.0.3
Jinja2==2.8
jsonschema==2.5.1
jupyter==1.0.0
jupyter-client==4.0.0
jupyter-console==4.0.2
jupyter-core==4.0.6
MarkupSafe==0.23
mistune==0.7.1
nbconvert==4.0.0
nbformat==4.0.0
notebook==4.0.4
path.py==8.1.1
pexpect==3.3
pickleshare==0.5
ptyprocess==0.5
Pygments==2.0.2
pyzmq==14.7.0
qtconsole==4.0.1
simplegeneric==0.8.1
terminado==0.5
tornado==4.2.1
traitlets==4.0.0
backports.ssl-match-hostname==3.4.0.2
certifi==2015.9.6.2
decorator==4.0.2
functools32==3.2.3.post2
ipykernel==4.0.3
ipython==4.0.0
ipython-genutils==0.1.0
ipywidgets==4.0.3
Jinja2==2.8
jsonschema==2.5.1
jupyter==1.0.0
jupyter-client==4.0.0
jupyter-console==4.0.2
jupyter-core==4.0.6
MarkupSafe==0.23
mistune==0.7.1
nbconvert==4.0.0
nbformat==4.0.0
notebook==4.0.4
path.py==8.1.1
pexpect==3.3
pickleshare==0.5
ptyprocess==0.5
Pygments==2.0.2
pyzmq==14.7.0
qtconsole==4.0.1
simplegeneric==0.8.1
terminado==0.5
tornado==4.2.1
traitlets==4.0.0

Re: IPython native kernel missing?

[Craig Barnes]

Hi Ricardo,

On 21/09/15 16:28, Ricardo Wurmus wrote:
> Hi Guix,
>
> I’m trying to package Jupyter (an improved version of IPython, from what
> I’ve heard) and noticed that the tests for jupyter-client fail because
> the native “python3” (or “python2”) kernel cannot be found.  According
> to the documentation, this “kernel” should always be available and
> doesn’t need to be installed.
>
> Looking around in the sources of python-ipython (an input to the Jupyter
> packages I’m working on) I see that this file
>
> $out/lib/python2.7/site-packages/IPython/kernel/kernelspec.py
>
> contains hard-coded system paths:
>
> SYSTEM_KERNEL_DIRS = ["/usr/share/jupyter/kernels",
>   "/usr/local/share/jupyter/kernels",
>  ]
>
> Yet I have not found any directory named “kernels” in the output of the
> python-ipython package.  Nor have I found any “kernel.json” files.  It
> seems to me that IPython should install at least the native kernel at
> some point, but currently doesn’t seem to include it.
>
> I would like to fix this, but I really don’t know anything about IPython
> and I don’t even know what the word “kernel” describes in this context.
> Could someone with an understanding of IPython please take a look at
> this?
IIRC we are using requirements.txt to determine all dependencies, which
it seems is not used by this project.  This is possibly because the
output is slightly different depending on the python version.

setup.py includes the ipykernel package, but to get a full list of
dependencies we need to install using pip in a virtualenv, then run pip
freeze to generate requirements.txt.

I've attached what I got as a result from python 2 and 3.


Cheers

Craig

decorator==4.0.2
ipykernel==4.0.3
ipython==4.0.0
ipython-genutils==0.1.0
ipywidgets==4.0.3
Jinja2==2.8
jsonschema==2.5.1
jupyter==1.0.0
jupyter-client==4.0.0
jupyter-console==4.0.2
jupyter-core==4.0.6
MarkupSafe==0.23
mistune==0.7.1
nbconvert==4.0.0
nbformat==4.0.0
notebook==4.0.4
path.py==8.1.1
pexpect==3.3
pickleshare==0.5
ptyprocess==0.5
Pygments==2.0.2
pyzmq==14.7.0
qtconsole==4.0.1
simplegeneric==0.8.1
terminado==0.5
tornado==4.2.1
traitlets==4.0.0
backports.ssl-match-hostname==3.4.0.2
certifi==2015.9.6.2
decorator==4.0.2
functools32==3.2.3.post2
ipykernel==4.0.3
ipython==4.0.0
ipython-genutils==0.1.0
ipywidgets==4.0.3
Jinja2==2.8
jsonschema==2.5.1
jupyter==1.0.0
jupyter-client==4.0.0
jupyter-console==4.0.2
jupyter-core==4.0.6
MarkupSafe==0.23
mistune==0.7.1
nbconvert==4.0.0
nbformat==4.0.0
notebook==4.0.4
path.py==8.1.1
pexpect==3.3
pickleshare==0.5
ptyprocess==0.5
Pygments==2.0.2
pyzmq==14.7.0
qtconsole==4.0.1
simplegeneric==0.8.1
terminado==0.5
tornado==4.2.1
traitlets==4.0.0

Re: IPython native kernel missing?

[Craig Barnes]

Hi Ricardo,
>>> I’m trying to package Jupyter (an improved version of IPython, from what
>>> I’ve heard) and noticed that the tests for jupyter-client fail because
>>> the native “python3” (or “python2”) kernel cannot be found.  According
>>> to the documentation, this “kernel” should always be available and
>>> doesn’t need to be installed.
>>>
>>> Looking around in the sources of python-ipython (an input to the Jupyter
>>> packages I’m working on) I see that this file
>>>
>>> $out/lib/python2.7/site-packages/IPython/kernel/kernelspec.py
>>>
>>> contains hard-coded system paths:
>>>
>>> SYSTEM_KERNEL_DIRS = ["/usr/share/jupyter/kernels",
>>>   "/usr/local/share/jupyter/kernels",
>>>  ]
>>>
>>> Yet I have not found any directory named “kernels” in the output of the
>>> python-ipython package.  Nor have I found any “kernel.json” files.  It
>>> seems to me that IPython should install at least the native kernel at
>>> some point, but currently doesn’t seem to include it.
>>>
>>> I would like to fix this, but I really don’t know anything about IPython
>>> and I don’t even know what the word “kernel” describes in this context.
>>> Could someone with an understanding of IPython please take a look at
>>> this?
>> IIRC we are using requirements.txt to determine all dependencies, which
>> it seems is not used by this project.  This is possibly because the
>> output is slightly different depending on the python version.
>>
>> setup.py includes the ipykernel package, but to get a full list of
>> dependencies we need to install using pip in a virtualenv, then run pip
>> freeze to generate requirements.txt.
>>
>> I've attached what I got as a result from python 2 and 3.
> These are the requirements for Jupyter, right?  They seem familiar
> because I have packaged a couple of those in the list.  I’ll try to
> package the missing dependencies (in particular “ipykernel”) and add it
> to the inputs to see if this makes a difference.
yes only Jupyter, the steps I used where

mkvirtualenv jupyter
pip install jupyter
# lots of busyness ...
pip freeze > requirements.txt

Of course you probably only need to make sure that the requirements
listed in setup.py are in you package as the rest are dependencies of
those.

Thank you for packaging this.


Craig

Re: [PATCH 1/3] gnu: Add python-pip.

[Mathieu Lirzin]

Cyril Roelandt  writes:

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

[...]

> +(home-page "https://pip.pypa.io/;)
> +(synopsis
> +  "The PyPA recommended tool for installing Python packages")
   ^^^

IMO Pypa recommandations are not relevant in Guix context.  What about
something more neutral like “Xenophobic package manager”? ;) Just
kidding.

I would prefer 

(synopsis "Package manager for Python software")

> +(description
> +  "Pip is a package manager for Python software, that finds packages on 
> the
> +Python Package Index (PyPI).")

It would be nice to have a more verbose description, for example
describing its main features...  Sorry I can't help much :)

> +(license license:expat)))
> +
> +(define-public python2-pip
> +  (package-with-python2 python-pip))

Otherwise LGTM!

--
Mathieu Lirzin

Re: [PATCH 1/2] gnu: glibc/linux: Rename "linux-headers" input to "kernel-headers".

[Ludovic Courtès]

Manolis Ragkousis  skribis:

> Updated all the files referring to linux-headers in gnu/packages. The
> part of the patch referring to
> glibc/hurd was kept out, as there is no glibc/hurd in master.
>
> Is it okay to push it to core-updates?

Sorry, because of delay on my side, this will have to go to ‘wip-hurd’.
We can merge it in the next ‘core-updates’ though (hopefully we can
close and reopen ‘core-updates’ in a few days.)

> From b5d724cae502e8bf664b71045f4053e6d35a98df Mon Sep 17 00:00:00 2001
> From: Manolis Ragkousis 
> Date: Mon, 7 Sep 2015 14:01:51 +0300
> Subject: [PATCH] gnu: packages: Change label from "linux-headers" to
>  "kernel-headers".
>
> * gnu/packages/base.scm (glibc)[propagated-inputs, arguments]: Change to 
> "kernel-headers".
> * gnu/packages/commencement.scm 
> (glibc-final-with-bootstrap-bash)[propagated-inputs]: Same
> * gnu/packages/cross-base.scm (cross-gcc)[native-inputs]: Same.
>   (cross-libc)[propagated-inputs, arguments]: Same.
> * gnu/packages/make-bootstrap.scm (%glibc-stripped)[inputs, arguments]: Same.

LGTM.

Thanks!

Ludo’.

Re: modprobe on guix

[Ludovic Courtès]

Petter  skribis:

>> One solution would be to provide a /etc/environment file containing the
>> right value for LINUX_MODULE_DIRECTORY (‘sudo’ honors that, according to
>> sudoers(5).)
>
> Yes, this is interesting. When i considered this previously i
> prematurely put it aside because it requires PAM, and i wrongly
> concluded our sudo wasn't configured with PAM (based on package
> definition). On second look, i see PAM is on by default for Linux
> distributions when building sudo; also running  sudo -V  as root user
> confirms this. However, creating /etc/environment and putting stuff
> there doesn't have any effect for me. But i believe the reason is that a
> module needs to be added to linux-pam, namely pam_env[1].

Oh, I see.  Presumably, you need to add ‘pam_env’ to the list of modules
for ‘sudo’, which is currently hardcoded in ‘base-pam-services’ in the
misnamed (gnu system linux) module.

> I'd like to have a go at this and see if i can make a patch for this.

That’d be great!

> Maybe it makes sense to put /all/ the environment variables, especially
> for root operations, in /etc/environment? From what i understand
> variables from outside this file will not be expanded, so if not it
> would mean duplicating definitions. Also, having this as a
> just-for-those-sudo-users would be easy for root users to miss
> updating. Then obviously root logins would have to make use of this file
> as well, but i'm sure that can be arranged. I'll look more into this.

What other variables do you have in mind?

Thanks,
Ludo’.

Re: [PATCH] Add Zope Public License.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> From ccc79ada2f48569a57cb310040e38d4c52904171 Mon Sep 17 00:00:00 2001
> From: Ricardo Wurmus 
> Date: Tue, 22 Sep 2015 13:43:53 +0200
> Subject: [PATCH] licenses: Add Zope Public License.
>
> * guix/licenses.scm (zpl2.1): New variable.

Sure!

Ludo’.

Re: [PATCH 11/19] gnu: Add r-knitr.

[Ludovic Courtès]

Ricardo Wurmus  skribis:

>> I'm not sure if it's correct, but I changed the license from gpl3+ to
>> gpl2+ to keep it consistent with the r-markdown package
>> (https://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility). Thanks
>> for figuring that out.
>
> actually, the author responded and said that “GPL” in the package’s
> DESCRIPTION file just means “any GPL version”.  Here’s the comment:
>
>https://github.com/yihui/knitr/issues/566#issuecomment-140095735
>
> The licensing guidelines for R packages state that
>
>“Abbreviations GPL and LGPL are ambiguous and usually taken to mean
>any version of the license”
>
> In this case “gpl2+” is probably correct, but you may want to add a
> comment above the ‘(license ...)’ expression to state that any GPL
> version may be picked by users here.
>
> What do others think?

I agree with your suggestion.

Ludo’.

Re: [PATCH 2/3] gnu: Update python-fixtures

[Mathieu Lirzin]

I can't help much about the circular dependency problem.  I think it is
important to avoid propagation of inputs from old versions, but I don't
know if this is feasible.  Here are my usual cosmetic comments :)


Cyril Roelandt  writes:

> * gnu/packages/python.scm (python-fixtures): Update.
> * gnu/packages/python.scm (python-fixtures-0.3.16,
>   python2-fixtures-0.3.16, python-pbr-0.11,
>   python2-pbr-0.11): New variables.
> * gnu/packages/python.scm (python-testrepository): Use python-fxitures-0.3.16
^^^
fixtures
>   instead of python-fixtures in the inputs.

[...]

> +(define-public python-pbr-0.11
> +  (package
> +(name "python-pbr")
> +(version "0.11.0")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append
> + "https://pypi.python.org/packages/source/p/pbr/pbr-;
> + version ".tar.gz"))
> +   (sha256
> +(base32
> + "0v9gb7gyqf7q9s99l0nnjj9ww9b0jvyqlwm4d56pcyinxydddw6p"
> +(build-system python-build-system)
> +(arguments
> + `(#:tests? #f)) ;; Most tests seem to use the Internet.

 `(#:tests? #f));most tests seem to use the internet

--
Mathieu Lirzin

Re: [PATCH 6/7] guix build: Add 'build-package'.

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2015-09-08 23:10 +0300) wrote:
>
>> Alex Kost  skribis:

[...]

>>> Ludovic Courtès (2015-08-26 14:12 +0300) wrote:
>>>
 Maybe ‘build-package’ could go to (guix packages)?
>>>
>>> ‘build-package’ uses ‘show-…’ procedures from (guix ui) module.  I
>>> thought that adding this module to (guix packages) was not desired, or
>>> is it OK?
>>
>> Right, sorry.  So maybe leave in (guix build scripts) with a comment
>> explaining that it doesn’t have a better place and is for use by the
>> Emacs UI.  (Make sure to use the monadic style as suggested in a
>> previous message.)
>
> So I suppose this comment is not needed anymore (right?) as

Correct.

> 'build-package' will beplaced in (guix scripts), and it looks like a
> rather general procedure.  For example, it may be used for something
> like ‘guix build --package-from-file’ suggested by David:
> .

‘guix package --install-from-file’ was committed but I don’t think it
actually needs ‘build-package’.

> From ce35de1359ae11a2e73f129db4f7685985f3d041 Mon Sep 17 00:00:00 2001
> From: Alex Kost 
> Date: Thu, 23 Jul 2015 16:16:41 +0300
> Subject: [PATCH] scripts: Add 'build-package'.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> * guix/scripts/system.scm (maybe-build): Move to ...
> * guix/scripts.scm: ...here.
>   (build-package): New procedure.
>
> Co-authored-by: Ludovic Courtès 

OK!

Thanks,
Ludo’.

Re: [PATCH] gnu: commencement: Add support for a native GNU/Hurd system.

[Ludovic Courtès]

Manolis Ragkousis  skribis:

> From 877ff9bab11056c221b4d325561e16a46a9ff09d Mon Sep 17 00:00:00 2001
> From: Manolis Ragkousis 
> Date: Thu, 17 Sep 2015 12:24:17 +0300
> Subject: [PATCH] gnu: commencement: Add support for a native GNU/Hurd system.
>
> * gnu/packages/commencement.scm (kernel-headers-boot0): New procedure.
>   (flex-boot0, bison-boot0, gnumach-headers-boot0, mig-boot0,
>   hurd-headers-boot0, hurd-minimal-boot0, hurd-kernel-headers-boot0, 
> ld-wrapper-boot0): New variables.
>   (%boot1-inputs): Add ld-wrapper-boot0.
>   (glibc-final-with-bootstrap-bash)[propagated-inputs]: Replace with 
> kernel-headers-boot0.
>   [inputs]: Add "mig".
>   (glibc-final)[arguments]: Replace with kernel-headers-boot0.

LGTM.  (Please keep lines in commit logs below 80 columns though.)

Since we are about to merge ‘core-updates’, this has to go to ‘wip-hurd’
for now.

In the next ‘core-updates’ cycle, I plan to look at ‘wip-hurd’ and
cherry-pick the last things from there.

Thanks, and apologies for the delay!

Ludo’.