Re: Submitting Patch for r-dyn Description for cran Package

[Ricardo Wurmus]

Hi,

thank you for your contribution!

Unfortunately, your email was way too big for me to even open :) Could
you please resend it with only the relevant changes?  The changes to the
“.po” files should not be part of the patch.

Let’s take a closer look at the R package you’ve added.

> +(define-public r-dyn
> +  (package
> +(name "r-dyn")
> +(version "0.2-9.6")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (cran-uri "dyn" version))
> +   (sha256
> +(base32
> + "16fqv9k7yxdgybwzafjkyqm16qpgqz13lcjpi6a1nc8xbzlzh0gb"
> +(build-system r-build-system)
> +(propagated-inputs
> + `(("r-zoo" ,r-zoo)))
> +(home-page "https://cran.r-project.org/web/packages/dyn;)
> +(synopsis "Time Series Regression")

Please make all worlds except for the first lowercase.

> +(description
> + "Time series regression. The dyn class interfaces ts, irts(), zoo() and
> +zooreg() time series classes to lm(), glm(), loess(), quantreg::rq(), 
> MASS::rlm(),
> + MCMCpack::MCMCregress(), quantreg::rq(), randomForest::randomForest() and 
> other
> + regression functions allowing those functions to be used with time series 
> including
> +specifications that may contain lags, diffs and missing values.")

The first sentence is just a sentence fragment.  Could you please turn
it into a full sentence?

Please leave two spaces between sentences.

The functions that are mentioned in the description should be wrapped in
@code{…} syntax.

Have you tried building this package?  (I have not.)

Please also add a copyright line to the very top of the file.

One more thing: in Guix we follow certain conventions when it comes to
commit messages.  You can take a look at previous commit messages (with
“git log”) to see examples.

In this case the message would look like this:

--8<---cut here---start->8---
gnu: Add r-dyn.

* gnu/packages/cran.scm (r-dyn): New variable.
--8<---cut here---end--->8---

Would you like to send an updated version of your patch?

Thanks again for giving this a try!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: split up python-pyqt or python-matplotlib?

[Hartmut Goebel]

Am 19.03.2018 um 17:55 schrieb Ludovic Courtès:
> I’m no Pythonista, but would it work to create “python-matplotlib-qt”,
> which would contain nothing but the Qt rendering backend?

This sounds like a good idea. Additionally I suggest doing to for *all*
(relevant) backends, eg. gtk+, tk, cairo. A lazy way would be to only
remove the inputs from 'python-matplot' and for 'python-matplot-qt' (et
al.) include no package but only the input. (Much like "meta" packages
in Debian).

List of backends [2]:

# GTK GTKAgg GTKCairo GTK3Agg GTK3Cairo
# MacOSX Qt4Agg Qt5Agg TkAgg WX WXAgg Agg Cairo GDK PS PDF SVG
# Template.


Names are are not case-sensitive [1]

With a typical installation of matplotlib, such as from a binary
installer or a linux distribution package, a good default backend will
already be set, allowing both interactive work and plotting from
scripts, with output to the screen and/or to a file, so at least
initially you will not need to use any of the methods given above. [1]

[1] https://matplotlib.org/faq/usage_faq.html#what-is-a-backend
[2] https://matplotlib.org/users/customizing.html#a-sample-matplotlibrc-file

-- 
Regards
Hartmut Goebel

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

Re: [Orchestration][RFC] A simple draft for channels

[Pjotr Prins]

On Mon, Mar 19, 2018 at 04:18:29PM -0400, myg...@gmail.com wrote:
> Other people bash them, but I have used git modules a lot for
> hierarchical bio analysis and never hit a real issue.  Maybe you could
> say more about the specific problem you see in this application?

No modules, please. Like I wrote, it only works if you don't really
change the modules. It is particularly bad when working with other
people.

> OK, but I prefer 'sudo git clean -dfx' because it innoculates me against
> any errors in 'make clean' logic. I should use ./pre-inst-env more ;-)

dfx. I'll look into that, thanks.

> I agree it is annoying, but maybe this is the cost of complete artistic
> source code freedom? And MIPS are so cheap these days, no?

My time is not exactly cheap. I can do something else, but it breaks
the flow. Which means I start looking at ways of avoiding updates. And
it happens too often.

> You can capture the .go files by checking them into disposable "deploy"
> branches which you cam either pull to the target machine or a push to a
> non-naked repo.

Awesome, that is a really bad-ass idea. I may just try it for fun!

Using branches that way is not exactly what git was meant for ;). 

> Am I missing something? - George

Yeah, the discussion is about channels. I.e., sharing bespoke binary
deployment. And making it really easy. And saving me and others from
pain. That is my itch to scratch.

Even so, I'll try sub-tree and dfx - they may help me ;).

Pj.

-- 

Re: Internship on Improve the user experience for the "guix package" command line tool (Outreachy)

[Ricardo Wurmus]

Hi Vijayalakshmi,

> I created a patch file for the package definition of python-logwrap that
> I'm including here. I'm a little unsure if my patch is right because my ./
> pre-inst-env.in guix build r-abbyyR fails with some error.

This looks like you haven’t actually built Guix.  The “.in” files are
templates containing @PLACEHOLDERS@; they are turned into their target
files at configuration time.

In short you need to do this:

guix environment guix
./bootstrap
./configure --localstatedir=/var
make

At that point you’ll have “pre-inst-env”, an actual executable script.

> Also, since we are going to be communicating regularly now,
> 1. I'd like to know the best times to contact you.

I’m checking mails daily, but not always able to respond within 6 hours.
I’ll try to get a reply out within 12 hours.  I’m located in Central
Europe, so my timezone is CET.

> 2. I need some help finishing my Outreachy application, so anytime in the
> next 2 days if you could set aside an hour for us to discuss the goals of
> the project etc it'll be great.

Sure; I have some days off this week, so I can reserve some time to
discuss this.  Have you read the full project description on the
Outreachy page already?  If so, do you have any questions about the
project description?

As you build and install packages with Guix you will probably notice
that often there is a lot of dense output.  I think you can get a better
appreciation for this project when you play a little with Guix and
observe in what situations it spews out a lot of text.

The project schedule isn’t totally rigid; if you find a part of this
project particularly interesting we can adapt and focus on that part
more.  But before we can decide this I think you need to become a little
more familiar with the problem first.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: [Orchestration][RFC] A simple draft for channels

[myglc2]

On 03/19/2018 at 19:31 Pjotr Prins writes:

> On Mon, Mar 19, 2018 at 02:21:35PM -0400, myg...@gmail.com wrote:
>> > Moving from one to the other, however, is too complicated and error
>> > prone. I can do it, but no one else really wants to. Even with my
>> > explanations it proves to be a royal pain.
>> 
>> How about making guix a submodule of the GeneNetwork repo?
>
> I don't like git submodules, unfortunately. I have plenty experience
> there, and often not good. It works as long as you don't update the
> modules ;)
>
> I am OK with two git trees, there is no tight coupling between
> GeneNetwork and Guix. But there is tight coupling between
> GUIX_PACKAGE_PATH (guix-bioinformatics tree) and guix. I could
> consider making guix-bioinformatics a module of guix. But I am sure I
> am in for pain there too.

Other people bash them, but I have used git modules a lot for
hierarchical bio analysis and never hit a real issue.  Maybe you could
say more about the specific problem you see in this application?

>> > Now I need a way to no longer rebuild all .go files for Guix tree
>> > updates/changes. Not only between switching branches, but also when
>> > just running 'git pull' from Guix savannah. I find I have to do that
>> > very often. So often that I don't even try running make anymore
>> > without make clean. Anyone here share that experience?
>> 
>> Yes the guix make does seem rather fragile ;-) So I usually do ...
>> 
>> guix environment guix  -M 4 -c 4 --ad-hoc help2man git strace
>> rm -fr /home/g1/.cache/guile/ccache/*
>> sudo git clean -dfx
>> git pull
>> ./bootstrap
>> ./configure --localstatedir=/var --sysconfdir=/etc
>> make -j 10
>> make -j 10 check
>
> Mine is comparable, but even more rigorous:
>
>   screen -S guix-build # I tend to build in screen
>   env -i /bin/bash --login --noprofile --norc
>   ./pre-inst-env guix environment guix --ad-hoc help2man git strace \
> pkg-config less vim binutils coreutils grep guile guile-git guile-json \
> gcc nss-certs --no-grafts
>   bash # you may want this shell
>   rm -rf autom4te.cache/ # to be sure
>   make clean
>   ./bootstrap
>   ./configure --localstatedir=/var
>   make clean# to be really sure
>   make clean-go # to be even surer
>   make -j 
>
> (forget the make check)

OK, but I prefer 'sudo git clean -dfx' because it innoculates me against
any errors in 'make clean' logic. I should use ./pre-inst-env more ;-)

> but, yes, the point is that I have to do this too often and it takes a
> long time. So much that I thrust my hand through the monitor every
> time I have to start again. It is costing me monitors.

I agree it is annoying, but maybe this is the cost of complete artistic
source code freedom? And MIPS are so cheap these days, no?

> And there are problems, usually with package updates that go out of
> sync between my trees.

guix as a submodule would avoid this, no?

>> This takes a while but it avoids me chasing spurious errors caused by
>> clashes between the state of my build directory and the upstream
>> changes ;-)
>
> I think we agree.
>
>> > One thing I could do is split out 3 git repos for every use case and
>> > update these individually not triggering rebuilds. And when I deploy
>> > on other machines move the complete repo across with .go files.
>> 
>> Have you considered a git-worktree for each of the development, testing
>> and production branches?
>
> Hmmm. That may be helpful. I should try that. 
>
> Still does not solve my deployment problems.

If it were me, I would do source deployment w/ 'git clone
--recurse-submodules', source update w/ 'git pull; git submodule update'
and try to use bespoke project code to check out development and testing
branches with git-subtree.

You can capture the .go files by checking them into disposable "deploy"
branches which you cam either pull to the target machine or a push to a
non-naked repo.

Am I missing something? - George

Re: Shepherd release!

[Andreas Enge]

On Mon, Mar 19, 2018 at 05:42:11PM +0100, Ludovic Courtès wrote:
> You probably need to run ‘gettextize’ first.

That is strange, why have I never heard about this command before?
Anyway, I tried, and it shows a lot of scary warnings:

...
Updating Makefile.am (backup is in Makefile.am~)
Updating configure.ac (backup is in configure.ac~)
Adding an entry to ChangeLog (backup is in ChangeLog~)

Please update po/Makevars so that it defines all the variables mentioned
in po/Makevars.template.
You can then remove po/Makevars.template.

Please run 'aclocal -I m4' to regenerate the aclocal.m4 file.
You need aclocal from GNU automake 1.9 (or newer) to do this.
Then run 'autoconf' to regenerate the configure file.

You might also want to copy the convenience header file gettext.h
from the 
/gnu/store/xd2ifxzy0wah00b4pj83djsqaw03793x-gettext-0.19.8.1/share/gettext 
directory into your package.
It is a wrapper around  that implements the configure --disable-nls
option.

Press Return to acknowledge the previous three paragraphs.


Then I just went ahead and did "autoreconf -vfi", but this yielded the
following error message:

autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
configure.ac:86: error: `po/Makefile.in' is already registered with 
AC_CONFIG_FILES.
../../lib/autoconf/status.m4:288: AC_CONFIG_FILES is expanded from...
configure.ac:86: the top level
autom4te: /gnu/store/mqjjsvkvpbgp9ykmi9jcylzw44qk1hr4-m4-1.4.18/bin/m4 failed 
with exit status: 1
aclocal: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1


Maybe I should follow the advice in the above "three paragraphs"?

$ aclocal -I m4
configure.ac:86: error: `po/Makefile.in' is already registered with 
AC_CONFIG_FILES.
../../lib/autoconf/status.m4:288: AC_CONFIG_FILES is expanded from...
configure.ac:86: the top level
autom4te: /gnu/store/mqjjsvkvpbgp9ykmi9jcylzw44qk1hr4-m4-1.4.18/bin/m4 failed 
with exit status: 1
aclocal: error: echo failed with exit status: 1


This looks like the previous analysis by David Pirotte:

On Fri, Mar 16, 2018 at 11:47:24PM -0300, David Pirotte wrote:
> Here there are two problems:
>
> 1-the configure.ac has a tipo
>
>   line 86, it has '... po/Makefile.in'
>   but it should be '... po/Makefile'
>
> 2-the po subdir does not have a Makefile.in


Andreas

Re: [Orchestration][RFC] A simple draft for channels

[Pjotr Prins]

On Mon, Mar 19, 2018 at 02:21:35PM -0400, myg...@gmail.com wrote:
> > Moving from one to the other, however, is too complicated and error
> > prone. I can do it, but no one else really wants to. Even with my
> > explanations it proves to be a royal pain.
> 
> How about making guix a submodule of the GeneNetwork repo?

I don't like git submodules, unfortunately. I have plenty experience
there, and often not good. It works as long as you don't update the
modules ;)

I am OK with two git trees, there is no tight coupling between
GeneNetwork and Guix. But there is tight coupling between
GUIX_PACKAGE_PATH (guix-bioinformatics tree) and guix. I could
consider making guix-bioinformatics a module of guix. But I am sure I
am in for pain there too.

> > Now I need a way to no longer rebuild all .go files for Guix tree
> > updates/changes. Not only between switching branches, but also when
> > just running 'git pull' from Guix savannah. I find I have to do that
> > very often. So often that I don't even try running make anymore
> > without make clean. Anyone here share that experience?
> 
> Yes the guix make does seem rather fragile ;-) So I usually do ...
> 
> guix environment guix  -M 4 -c 4 --ad-hoc help2man git strace
> rm -fr /home/g1/.cache/guile/ccache/*
> sudo git clean -dfx
> git pull
> ./bootstrap
> ./configure --localstatedir=/var --sysconfdir=/etc
> make -j 10
> make -j 10 check

Mine is comparable, but even more rigorous:

  screen -S guix-build # I tend to build in screen
  env -i /bin/bash --login --noprofile --norc
  ./pre-inst-env guix environment guix --ad-hoc help2man git strace \
pkg-config less vim binutils coreutils grep guile guile-git guile-json \
gcc nss-certs --no-grafts
  bash # you may want this shell
  rm -rf autom4te.cache/ # to be sure
  make clean
  ./bootstrap
  ./configure --localstatedir=/var
  make clean# to be really sure
  make clean-go # to be even surer
  make -j 

(forget the make check)

but, yes, the point is that I have to do this too often and it takes a
long time. So much that I thrust my hand through the monitor every
time I have to start again. It is costing me monitors.

And there are problems, usually with package updates that go out of
sync between my trees.

> This takes a while but it avoids me chasing spurious errors caused by
> clashes between the state of my build directory and the upstream
> changes ;-)

I think we agree.

> > One thing I could do is split out 3 git repos for every use case and
> > update these individually not triggering rebuilds. And when I deploy
> > on other machines move the complete repo across with .go files.
> 
> Have you considered a git-worktree for each of the development, testing
> and production branches?

Hmmm. That may be helpful. I should try that. 

Still does not solve my deployment problems.

Pj.
-- 

Re: [Orchestration][RFC] A simple draft for channels

[myglc2]

Hi Pjotr,

On 03/19/2018 at 13:04 Pjotr Prins writes:

> Let's start up again on this conversation in the context of
> deployment. I have a simple use case. For GeneNetwork we maintain
> GUIX_PACKAGE_PATH packages. It contains packages that ought to go in
> main line (such as python-gunicorn), but also packages that will never
> make it (such as a javascript twitter feed).
>
> Now we deploy multiple setups, which I'll simplify to development,
> testing and production here (there are more!). Each of these has a
> combination of a Guix git checkout and a GUIX_PACKAGE_PATH checkout.
>
> These git repo's are supposedly in sync with each other.
>
> Moving from one to the other, however, is too complicated and error
> prone. I can do it, but no one else really wants to. Even with my
> explanations it proves to be a royal pain.

How about making guix a submodule of the GeneNetwork repo?

> Now I need a way to no longer rebuild all .go files for Guix tree
> updates/changes. Not only between switching branches, but also when
> just running 'git pull' from Guix savannah. I find I have to do that
> very often. So often that I don't even try running make anymore
> without make clean. Anyone here share that experience?

Yes the guix make does seem rather fragile ;-) So I usually do ...

guix environment guix  -M 4 -c 4 --ad-hoc help2man git strace
rm -fr /home/g1/.cache/guile/ccache/*
sudo git clean -dfx
git pull
./bootstrap
./configure --localstatedir=/var --sysconfdir=/etc
make -j 10
make -j 10 check

This takes a while but it avoids me chasing spurious errors caused by
clashes between the state of my build directory and the upstream
changes ;-)

> One thing I could do is split out 3 git repos for every use case and
> update these individually not triggering rebuilds. And when I deploy
> on other machines move the complete repo across with .go files.

Have you considered a git-worktree for each of the development, testing
and production branches?

HTH - George

Re: Internship on Improve the user experience for the "guix package" command line tool (Outreachy)

[Vijayalakshmi Vedantham]

Got it. CC-ing them.

I created a patch file for the package definition of python-logwrap that
I'm including here. I'm a little unsure if my patch is right because my ./
pre-inst-env.in guix build r-abbyyR fails with some error.


Also, since we are going to be communicating regularly now,
1. I'd like to know the best times to contact you.
2. I need some help finishing my Outreachy application, so anytime in the
next 2 days if you could set aside an hour for us to discuss the goals of
the project etc it'll be great.

Thanks,
Vijayalakshmi

On Mon, Mar 19, 2018 at 6:10 AM, Ricardo Wurmus  wrote:

>
> Hi Vijayalakshmi,
>
> Thanks again for your first successful contribution to Guix!  Don’t
> forget to record your contribution on the Outreachy website.
>
> You may have noticed that there was a lot of output when running “guix
> build r-abbyyr”.  The same is true when running “guix package -i
> r-abbyyr”, which will install the package into your default profile
> after building it (when no pre-built package is offered by our build
> farm).  The project’s goal – among others — is to make all this output
> less intimidating, especially when using “guix package -i”.
>
> > I'm excited to continue working. What other tasks do you have in mind?
> > Should I add more packages or do something else?
>
> Let’s take a closer look at the package you created.
>
> The whole thing is a variable definition.  You defined the public
> variable “r-abbyyr” and bound a package value to it.  In Scheme that’s
> how you define a variable with the name “a” and a value of 12:
>
> (define a 12)
>
> Your package definition is not so different from that:
>
> (define r-abbyyr (package …))
>
> In Scheme whatever thing comes first in a parenthetical expression is
> usually either a procedure or a special form.  If it is a procedure,
> everything that follows is an argument.  Here’s an example:
>
> (+ 1 2 3 4 5 10)
>
> The first element in this expression is “+”, which is a procedure that
> adds its arguments.  All the numbers that follow are arguments to that
> procedure.  When this expression is evaluated, the result is the sum of
> all these numbers: 15.
>
> “package” is a special form that takes a bunch of fields and values and
> produces a package object.  Let’s look at one particular field that the
> “package” form provides: the “build-system” field.
>
> As an R package “r-abbyyr” used the “r-build-system”.  The value of the
> “r-build-system” variable is defined in “guix/build-system/r.scm”, and
> it completely describes how an R package is to be built with Guix.  We
> support more build systems in Guix, but all of them have the same
> features in common: they all provide so-called build phases that are
> executed in order.  Each build phase is just a procedure.
>
> As a next task I would suggest to browse the source code of Guix to see
> what build systems are offered by Guix.  The build phases for the R
> build system, for example, are defined as “%standard-phases” in
> “guix/build/r-build-system.scm”.
>
> Maybe you can try to create a package definition for another application
> that uses a different build system.  How about a simple Python package
> from pypi?  Where are the build phases for a Python package defined?
> What is the build system that is used for Python packages?
>
> PS: what do you think about Cc-ing the public guix-devel@gnu.org mailing
> list for future communication?  The benefit is that this list is
> archived and accessible by anyone, such as future contributors.  And in
> case I make a mistake and explain something poorly others will have a
> chance to correct me :)
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>
From 8251cc84c314ec575f4ec40da56939a2defe75f0 Mon Sep 17 00:00:00 2001
From: Vijayalakshmi 
Date: Mon, 19 Mar 2018 22:20:25 +0530
Subject: [PATCH 2/2] gnu: Add python-logwrap

* gnu/packages/python.scm (python-logwrap): New variable.
---
 gnu/packages/python.scm | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 05d3390..bb3a0b2 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -47,7 +47,8 @@
 ;;; Copyright © 2017 Brendan Tildesley 
 ;;; Copyright © 2018 Ethan R. Jones 
-;;;
+;;; Copyright © 2018 Vijayalakshmi Vedantham 
+
 ;;; This file is part of GNU Guix.
 ;;;
 ;;; GNU Guix is free software; you can redistribute it and/or modify it
@@ -524,6 +525,28 @@ pidof, tty, taskset, pmap.")
 planar geometric objects.  It is based on the @code{GEOS} library.")
 (license license:bsd-3)))
 
+(define-public python-logwrap
+  (package
+(name "python-logwrap")
+(version "3.2.1")
+(source
+ (origin
+   (method url-fetch)
+   

Re: pypi import certs issues

[ng0]

Ludovic Courtès transcribed 2.7K bytes:
> Hello,
> 
> ng0  skribis:
> 
> > on commit 72406062b9c3cdb6e9e30266f3cc31d0b2116b68 pypi import has issues:
> >
> > user@abyayala ~$ guix package -l | grep "nss-certs"
> > user@abyayala ~$ env | grep "SSL_"
> > GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt
> > SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
> > SSL_CERT_DIR=/home/user/.guix-profile/etc/ssl/certs:/etc/ssl/certs
> > user@abyayala ~$ guix import pypi readline
> > ;;; note: source file /home/user/.config/guix/latest/guix/download.scm
> > ;;;   newer than compiled 
> > /home/user/.config/guix/latest/guix/download.go
> > ;;; note: source file /home/user/.config/guix/latest/guix/download.scm
> > ;;;   newer than compiled 
> > /gnu/store/3abjgr7dws69089lrfkf0n92qww1946j-guix-0.14.0-9.bdf0c64/lib/guile/2.2/site-ccache/guix/download.go
> > ;;; note: source file /home/user/.config/guix/latest/guix/download.scm
> > ;;;   newer than compiled 
> > /run/current-system/profile/lib/guile/2.2/site-ccache/guix/download.go
> > Backtrace:
> >   11 (apply-smob/1 #)
> >   In ice-9/boot-9.scm:
> >   705:2 10 (call-with-prompt _ _ # > default-prompt-handleb&>)
> >   In ice-9/eval.scm:
> >   619:8  9 (_ #(#(#)))
> >   In guix/ui.scm:
> > 1501:12  8 (run-guix-command _ . _)
> > In guix/scripts/import.scm:
> >114:11  7 (guix-import . _)
> >In guix/scripts/import/pypi.scm:
> >84:19  6 (guix-import-pypi . _)
> >In guix/import/pypi.scm:
> >   274:17  5 (pypi->guix-package _)
> >   In ice-9/boot-9.scm:
> >   829:9  4 (catch srfi-34 # > 2db97e0 at guix/import/jsonb&> b&)
> >   In guix/import/json.scm:
> >   32:17  3 (_)
> >   In guix/http-client.scm:
> >   88:25  2 (http-fetch _ #:port _ 
> > #:text? _ #:buffered? _ # _ # _ # b&)
> >   In guix/build/download.scm:
> >   398:4  1 
> > (open-connection-for-uri _ #:timeout _ # _)
> >   296:6  0 (tls-wrap 
> > # _ # _)
> >
> > guix/build/download.scm:296:6: In procedure tls-wrap:
> > X.509 certificate of 'pypi.python.org' could not be verified:
> >   insecure-algorithm
> > signer-not-found
> >   invalid
> 
> I don’t see that.  Could it be that the certs you have in /etc/ssl are
> too old, or something along these lines?

But how? The system I have is build from the same commit (+ my 4 irrelevant, 
not SSL touching
packages on top of it). So nss-certs is system-wide, as it has always been, and 
that's what
used for our /etc/ssl/certs/

> Thanks,
> Ludo’.
> 
> 

Thanks,
-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is

Re: split up python-pyqt or python-matplotlib?

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

> “python-pyqt” depends on all of Qt.  “python-pyqt” is also an input to
> “python-matplotlib” because that package has a Qt rendering backend.
>
> I wonder if we can make this lighter by default.  The scientific Python
> stack depends on “python-matplotlib”, but it seems like a very expensive
> dependency as it pulls in *all* of Qt *and* Gtk+.
>
> Is it feasible to split up “python-pyqt”?  If not, can we reasonably
> decouple matplotlib from pyqt?

I’m no Pythonista, but would it work to create “python-matplotlib-qt”,
which would contain nothing but the Qt rendering backend?

That way, assuming rendering backends are searched for at run time,
people could choose to install python-matplotlib-qt if they need this
backend.  (Similar to what I did with ‘guile’ vs. ‘guile-readline’.)

HTH,
Ludo’.

Re: pypi import certs issues

[Ludovic Courtès]

Hello,

ng0  skribis:

> on commit 72406062b9c3cdb6e9e30266f3cc31d0b2116b68 pypi import has issues:
>
> user@abyayala ~$ guix package -l | grep "nss-certs"
> user@abyayala ~$ env | grep "SSL_"
> GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt
> SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
> SSL_CERT_DIR=/home/user/.guix-profile/etc/ssl/certs:/etc/ssl/certs
> user@abyayala ~$ guix import pypi readline
> ;;; note: source file /home/user/.config/guix/latest/guix/download.scm
> ;;;   newer than compiled /home/user/.config/guix/latest/guix/download.go
> ;;; note: source file /home/user/.config/guix/latest/guix/download.scm
> ;;;   newer than compiled 
> /gnu/store/3abjgr7dws69089lrfkf0n92qww1946j-guix-0.14.0-9.bdf0c64/lib/guile/2.2/site-ccache/guix/download.go
> ;;; note: source file /home/user/.config/guix/latest/guix/download.scm
> ;;;   newer than compiled 
> /run/current-system/profile/lib/guile/2.2/site-ccache/guix/download.go
> Backtrace:
>   11 (apply-smob/1 #)
>   In ice-9/boot-9.scm:
>   705:2 10 (call-with-prompt _ _ # default-prompt-handleb&>)
>   In ice-9/eval.scm:
>   619:8  9 (_ #(#(#)))
>   In guix/ui.scm:
> 1501:12  8 (run-guix-command _ . _)
> In guix/scripts/import.scm:
>114:11  7 (guix-import . _)
>In guix/scripts/import/pypi.scm:
>84:19  6 (guix-import-pypi . _)
>In guix/import/pypi.scm:
>   274:17  5 (pypi->guix-package _)
>   In ice-9/boot-9.scm:
>   829:9  4 (catch srfi-34 # at guix/import/jsonb&> b&)
>   In guix/import/json.scm:
>   32:17  3 (_)
>   In guix/http-client.scm:
>   88:25  2 (http-fetch _ #:port _ 
> #:text? _ #:buffered? _ # _ # _ # b&)
>   In guix/build/download.scm:
>   398:4  1 
> (open-connection-for-uri _ #:timeout _ # _)
>   296:6  0 (tls-wrap 
> # _ # _)
>
> guix/build/download.scm:296:6: In procedure tls-wrap:
> X.509 certificate of 'pypi.python.org' could not be verified:
>   insecure-algorithm
> signer-not-found
>   invalid

I don’t see that.  Could it be that the certs you have in /etc/ssl are
too old, or something along these lines?

Thanks,
Ludo’.

Re: guile-gdbm doesn't work with gdbm-1.14

[Ludovic Courtès]

Hello,

Mark H Weaver  skribis:

> iyzs...@member.fsf.org (宋文武) writes:
>
>> Hello, since version 1.14, gdbm doesn't export "gdbm_errno" anymore [1],
>> so the guile-gdbm ffi binding code [2] need updates now (I'm not
>> confident to do it myself...).

Thanks, Mark for the quick fix.

> --- /dev/null
> +++ b/gnu/packages/patches/guile-gdbm-ffi-support-gdbm-1.14.patch
> @@ -0,0 +1,53 @@
> +From 1da99396dc65993ba34ac0370ca5d6acda6a3322 Mon Sep 17 00:00:00 2001
> +From: Mark H Weaver 
> +Date: Sun, 18 Mar 2018 07:02:37 -0400
> +Subject: [PATCH] Add support for gdbm-1.14.
> +
> +As of gdbm-1.14, 'gdbm_errno' no longer exists as a binary interface.
> +It has been replaced by 'gdbm_errno_location', a function that returns
> +int*.  We now use this new interface if it's available.

Ian, could you consider applying this patch upstream?

Thanks!

Ludo’.

Re: Posts in languages other than English on help-guix?

[Ludovic Courtès]

Chris Marusich  skribis:

> From e817d96b6a52eb6450c2edb4e03ccbfdce30d9d6 Mon Sep 17 00:00:00 2001
> From: Chris Marusich 
> Date: Sat, 17 Mar 2018 19:40:13 +0100
> Subject: [PATCH] website: contacts: Add Japanese translation for help-guix.
>
> * website/apps/base/data.scm (contact-media): Add "jp" translation.

Awesome, please push!

(I’ll take care of the CVS sync afterwards.)

Thanks,
Ludo’.

Re: Posts in languages other than English on help-guix?

[Ludovic Courtès]

Hello,

julien lepiller  skribis:

> So, here is what I see and a patch to fix it. I think it won't work on
> IE <= 9, do we care?

I think we don’t.  :-)

> From 2e2146d16a999002a0f8f9f8d0d1fc4c3275ea62 Mon Sep 17 00:00:00 2001
> From: Julien Lepiller 
> Date: Mon, 19 Mar 2018 16:08:31 +0100
> Subject: [PATCH] website: contacts: Improve style.
>
> * website/apps/base/templates/components.scm (contact->shtml): Use flexbox.

Excellent, please push!

Thanks,
Ludo’.

Re: Shepherd release!

[Ludovic Courtès]

Andreas Enge  skribis:

> autoreconf: running: automake --add-missing --copy --force-missing
> configure.ac:17: error: required file 'build-aux/config.rpath' not found
> configure.ac:17: error: required file './ABOUT-NLS' not found
> autoreconf: automake failed with exit status: 1

You probably need to run ‘gettextize’ first.

HTH!

Ludo’.

Re: guile-gdbm doesn't work with gdbm-1.14

[Mark H Weaver]

Ricardo Wurmus  writes:

> Mark H Weaver  writes:
>
>> iyzs...@member.fsf.org (宋文武) writes:
>>
>>> Hello, since version 1.14, gdbm doesn't export "gdbm_errno" anymore [1],
>>> so the guile-gdbm ffi binding code [2] need updates now (I'm not
>>> confident to do it myself...).
>>>
>>> [1] 
>>> http://git.gnu.org.ua/cgit/gdbm.git/commit/?id=c175231e2781abd17eabf412cfb597654a076c7b
>>> [2] https://github.com/ijp/guile-gdbm/blob/master/gdbm.scm#L156
>>
>> Here's a preliminary fix.
>
> Thank you.
>
>> * gnu/packages/patches/guile-gdbm-ffi-support-gdbm-1.14.patch: New file.
>> * gnu/local.mk (dist_patch_DATA): Add it.
>> * gnu/packages/guile.scm (guile-gdbm-ffi)[native-inputs]: New field.
>> [inputs]: Move above arguments.  Add the patch, and the 'patch' program.
>> [propagated-inputs]: Move above arguments.
>> [arguments]: In the builder, add code to apply the patch.
>
> I don’t see the native-inputs field in the patch.

Indeed, sorry for the mistake in the commit log.  Initially I made them
native inputs, but then I moved them to 'inputs'.

> Shouldn’t the “patch” and “patch-file” inputs be native-inputs?

Yes.  However, I noticed that the package already assumes a native
build, because it runs 'guile' from 'inputs' to compile the Scheme code.
Also, I wasn't sure off-hand how native-inputs are handled in the
trivial-build-system.

For purposes of this commit, I didn't want to take on the job of also
fixing this package for cross-building, which I was likely to get wrong
without testing.  Given that I no longer use substitutes, that would
have been a big job.

Does that make sense?

  Mark

Re: Posts in languages other than English on help-guix?

[julien lepiller]

Le 2018-03-10 16:19, l...@gnu.org a écrit :

Hi Julien,

julien lepiller  skribis:


Oh, with the traditional version being on only one line, the following
paragraph (bug reporting) is indented with the "zh" box.

You could try adding a style="clear: both" to the last "p" block in
the contact-medium div, and add "; clear: both" on each div (if there
is a one-line paragraph, the next language block would be indented).


I don’t see the problem with IceCat 52.6.0-gnu1 from Guix:



Does this show up with different browsers?

Regardless, please feel free to commit something that works for you in
the guix-artwork.git repo.  I’m not much of a Web developer so any help
in that area is greatly appreciated.  :-)

Thanks,
Ludo’.


So, here is what I see and a patch to fix it. I think it won't work on 
IE <= 9, do we care?From 2e2146d16a999002a0f8f9f8d0d1fc4c3275ea62 Mon Sep 17 00:00:00 2001
From: Julien Lepiller 
Date: Mon, 19 Mar 2018 16:08:31 +0100
Subject: [PATCH] website: contacts: Improve style.

* website/apps/base/templates/components.scm (contact->shtml): Use flexbox.
---
 website/apps/base/templates/components.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/apps/base/templates/components.scm b/website/apps/base/templates/components.scm
index b7ec218..39c836b 100644
--- a/website/apps/base/templates/components.scm
+++ b/website/apps/base/templates/components.scm
@@ -124,7 +124,7 @@
 
 (define (language-tag lang)
   `(span (@ (class "button-little button-little-active")
-(style "float: left; text-align: center; width: 20px; vertical-align: middle"))
+(style "text-align: center; width: 20px; vertical-align: middle"))
  ,lang))
 
 (define (contact->shtml contact)
@@ -144,9 +144,9 @@
 ,(match (contact-description contact)
? string? languages) blurbs) ...)
 `(p ,@(map (lambda (language blurb)
- `(div (@ (style "margin: 0 10px 10px 0"))
+ `(div (@ (style "display: flex; align-items: center; margin: 0 10px 10px 0"))
,(language-tag language)
-   (div (@ (lang ,language)) ,blurb)))
+   (div (@ (lang ,language) (style "flex: 1")) ,blurb)))
languages
blurbs)))
(blurb
-- 
2.16.2

split up python-pyqt or python-matplotlib?

[Ricardo Wurmus]

Hi Guix,

“python-pyqt” depends on all of Qt.  “python-pyqt” is also an input to
“python-matplotlib” because that package has a Qt rendering backend.

I wonder if we can make this lighter by default.  The scientific Python
stack depends on “python-matplotlib”, but it seems like a very expensive
dependency as it pulls in *all* of Qt *and* Gtk+.

Is it feasible to split up “python-pyqt”?  If not, can we reasonably
decouple matplotlib from pyqt?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

pypi import certs issues

[ng0]

Hi,

on commit 72406062b9c3cdb6e9e30266f3cc31d0b2116b68 pypi import has issues:

user@abyayala ~$ guix package -l | grep "nss-certs"
user@abyayala ~$ env | grep "SSL_"
GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt
SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
SSL_CERT_DIR=/home/user/.guix-profile/etc/ssl/certs:/etc/ssl/certs
user@abyayala ~$ guix import pypi readline
;;; note: source file /home/user/.config/guix/latest/guix/download.scm
;;;   newer than compiled /home/user/.config/guix/latest/guix/download.go
;;; note: source file /home/user/.config/guix/latest/guix/download.scm
;;;   newer than compiled 
/gnu/store/3abjgr7dws69089lrfkf0n92qww1946j-guix-0.14.0-9.bdf0c64/lib/guile/2.2/site-ccache/guix/download.go
;;; note: source file /home/user/.config/guix/latest/guix/download.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/guix/download.go
Backtrace:
  11 (apply-smob/1 #)
  In ice-9/boot-9.scm:
  705:2 10 (call-with-prompt _ _ #)
  In ice-9/eval.scm:
  619:8  9 (_ #(#(#)))
  In guix/ui.scm:
1501:12  8 (run-guix-command _ . _)
In guix/scripts/import.scm:
   114:11  7 (guix-import . _)
   In guix/scripts/import/pypi.scm:
   84:19  6 (guix-import-pypi . _)
   In guix/import/pypi.scm:
  274:17  5 (pypi->guix-package _)
  In ice-9/boot-9.scm:
  829:9  4 (catch srfi-34 # b&)
  In guix/import/json.scm:
  32:17  3 (_)
  In guix/http-client.scm:
  88:25  2 (http-fetch _ #:port _ 
#:text? _ #:buffered? _ # _ # _ # b&)
  In guix/build/download.scm:
  398:4  1 (open-connection-for-uri 
_ #:timeout _ # _)
  296:6  0 (tls-wrap # _ # _)

guix/build/download.scm:296:6: In procedure tls-wrap:
X.509 certificate of 'pypi.python.org' could not be verified:
  insecure-algorithm
signer-not-found
  invalid

user@abyayala ~$ ^C
user@abyayala ~$ cat 
src/systems/old_systems/guixsd/workstations/abyayala/config.scm | grep 
"nss-certs"
  "nss-certs" ;certs
  

-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is

Re: [RFC] A simple draft for channels

[ng0]

Ricardo Wurmus transcribed 1.7K bytes:
> 
> myg...@gmail.com writes:
> 
> > Ricardo, AIUI, your channels don't work like this. But I am at a loss to
> > say how they will work in practice from the user's POV. If you could
> > write such a description it would sure help us understand the proposal
> > better.
> 
> This draft is similar to how Conda channels[1] work:
> 
> Conda packages are downloaded from remote channels, which are URLs
> to directories containing conda packages. The conda command searches
> a default set of channels, and packages are automatically downloaded
> and updated from http://repo.continuum.io/pkgs/. You can modify what
> remote channels are automatically searched. You might want to do
> this to maintain a private or internal channel.
> 
> [1]: https://conda.io/docs/user-guide/concepts.html#conda-packages
> 
> In our case a channel consists of a git repository with Guile module
> definitions and a channel description file.  Optionally, it points to a
> URL from where substitutes can be fetched.
> 
> Other than that it behaves like a Conda user would expect:
> 
>“Guix does not yet include ‘foolicious 2000’, but I know it has been
> packaged by someone else and made available on the
> ‘garlic-onion-sweat’ channel.  So I enable this channel, authorize
> its public key, and then install ‘foolicious 2000’.”
> 
> Users can add any number of channels; their modules will be downloaded
> and built (TODO: this might be dangerous, so try sandboxing), and then
> added to GUIX_PACKAGE_PATH.

Couldn't we include the use of GUILE_LOAD_PATH + GUILE_LOAD_COMPILED_PATH
as well, for custom definitions of services and other elements?
This would make the use of channels more independent from just being about
packages. Or does this fit into the second iteration already?

> The second iteration of this would involve some potluck ideas for extra
> safety and convenience.
> 
> --
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 
> 
> 
> 

-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is

Re: [Orchestration][RFC] A simple draft for channels

[ng0]

Pjotr Prins transcribed 2.7K bytes:
> Let's start up again on this conversation in the context of
> deployment. I have a simple use case. For GeneNetwork we maintain
> GUIX_PACKAGE_PATH packages. It contains packages that ought to go in
> main line (such as python-gunicorn), but also packages that will never
> make it (such as a javascript twitter feed).
> 
> Now we deploy multiple setups, which I'll simplify to development,
> testing and production here (there are more!). Each of these has a
> combination of a Guix git checkout and a GUIX_PACKAGE_PATH checkout.

This reads a bit like what I'm working on and experimenting with
indepently at the moment.
I'm still waiting on what the turnout of this channels RFC will be.

So: I have a combination of guix.git on some-commit + a couple of
package-path repositories (put into classes "ports" and "pkgs")
and another couple of repositories which include other data.
All of this is used to construct a specified variant of an operating
system. Updates happen with a simple command so far, nothing's worked
out in a way that can be exposed to public. GUIX_PACKAGE_PATH for me
locally is super long by now. Essentially parts that never make their
way into Guix for various reasons are kept in modular pieces outside
of Guix (there's more to it, but that would be derailing the thread).

> These git repo's are supposedly in sync with each other.
> 
> Moving from one to the other, however, is too complicated and error
> prone. I can do it, but no one else really wants to. Even with my
> explanations it proves to be a royal pain.
> 
> Especially with multiple people developing.

> The other thing is that it
> takes too long to rebuild the Guix repo. Even on 20+ cores we have to
> wait a significant amount of time. And things go wrong... 

Yep. This is not really good in the very long term.

> Otherwise, only good stuff. I can provide binary packages, that is
> great. It is just this git juggling and Guix repo building that is
> killing me.

Didn't we talk about building Guix itself on the build farm? What's
keeping us from doing so?

> Maybe the short term solution for us is to no longer use
> GUIX_PACKAGE_PATH, but to merge the differences in branches of the GNU
> Guix tree. That takes care of the syncing problem (though it will
> still be a headache). Maybe channels ought to be Guix git trees
> anyway, so that is one step in the right direction.

I think this (just guix trees) is not really good, at least for my goals.
I'd rather have a modular layout where you can define multiple repositories
and channels are an addition to Guix. Unless we have good reasons to remove
the current extension-like behavior I'd like to keep them.

> Now I need a way to no longer rebuild all .go files for Guix tree
> updates/changes. Not only between switching branches, but also when
> just running 'git pull' from Guix savannah. I find I have to do that
> very often. So often that I don't even try running make anymore
> without make clean. Anyone here share that experience?
> 
> One thing I could do is split out 3 git repos for every use case and
> update these individually not triggering rebuilds. And when I deploy
> on other machines move the complete repo across with .go files.
> 
> Maybe also stick it into a container so I can deploy all dependencies
> with it and update any substitute keys in user land.
> 
> HEY. Did I just invent a channel? 
> 
> If we allow channels to be architecture specific we could ship
> dependencies and .go files with the git tree. No rebuilds.
> 
> If we allow using containers we can update substitute keys for
> channels (like mine on http://guix.genenetwork.org).
> 
> The key updates are minor though. Main thing is to speed up deployment
> and make it less error prone.
> 
> Maybe we should start thinking that a channel is simply an
> architecture dependent Guix 'pack' of substitutes that includes the
> pre-built Guix git repo. When deployed in a container we can inject
> the keys. When this works we can design a pack repository, making the
> channels searchable.
> 
> Pj.
> 
> 
> 

-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is

[Orchestration][RFC] A simple draft for channels

[Pjotr Prins]

Let's start up again on this conversation in the context of
deployment. I have a simple use case. For GeneNetwork we maintain
GUIX_PACKAGE_PATH packages. It contains packages that ought to go in
main line (such as python-gunicorn), but also packages that will never
make it (such as a javascript twitter feed).

Now we deploy multiple setups, which I'll simplify to development,
testing and production here (there are more!). Each of these has a
combination of a Guix git checkout and a GUIX_PACKAGE_PATH checkout.

These git repo's are supposedly in sync with each other.

Moving from one to the other, however, is too complicated and error
prone. I can do it, but no one else really wants to. Even with my
explanations it proves to be a royal pain.

Especially with multiple people developing. The other thing is that it
takes too long to rebuild the Guix repo. Even on 20+ cores we have to
wait a significant amount of time. And things go wrong... 

Otherwise, only good stuff. I can provide binary packages, that is
great. It is just this git juggling and Guix repo building that is
killing me.

Maybe the short term solution for us is to no longer use
GUIX_PACKAGE_PATH, but to merge the differences in branches of the GNU
Guix tree. That takes care of the syncing problem (though it will
still be a headache). Maybe channels ought to be Guix git trees
anyway, so that is one step in the right direction.

Now I need a way to no longer rebuild all .go files for Guix tree
updates/changes. Not only between switching branches, but also when
just running 'git pull' from Guix savannah. I find I have to do that
very often. So often that I don't even try running make anymore
without make clean. Anyone here share that experience?

One thing I could do is split out 3 git repos for every use case and
update these individually not triggering rebuilds. And when I deploy
on other machines move the complete repo across with .go files.

Maybe also stick it into a container so I can deploy all dependencies
with it and update any substitute keys in user land.

HEY. Did I just invent a channel? 

If we allow channels to be architecture specific we could ship
dependencies and .go files with the git tree. No rebuilds.

If we allow using containers we can update substitute keys for
channels (like mine on http://guix.genenetwork.org).

The key updates are minor though. Main thing is to speed up deployment
and make it less error prone.

Maybe we should start thinking that a channel is simply an
architecture dependent Guix 'pack' of substitutes that includes the
pre-built Guix git repo. When deployed in a container we can inject
the keys. When this works we can design a pack repository, making the
channels searchable.

Pj.

Re: guile-gdbm doesn't work with gdbm-1.14

[Ricardo Wurmus]

Mark H Weaver  writes:

> iyzs...@member.fsf.org (宋文武) writes:
>
>> Hello, since version 1.14, gdbm doesn't export "gdbm_errno" anymore [1],
>> so the guile-gdbm ffi binding code [2] need updates now (I'm not
>> confident to do it myself...).
>>
>> [1] 
>> http://git.gnu.org.ua/cgit/gdbm.git/commit/?id=c175231e2781abd17eabf412cfb597654a076c7b
>> [2] https://github.com/ijp/guile-gdbm/blob/master/gdbm.scm#L156
>
> Here's a preliminary fix.

Thank you.

> * gnu/packages/patches/guile-gdbm-ffi-support-gdbm-1.14.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/guile.scm (guile-gdbm-ffi)[native-inputs]: New field.
> [inputs]: Move above arguments.  Add the patch, and the 'patch' program.
> [propagated-inputs]: Move above arguments.
> [arguments]: In the builder, add code to apply the patch.

I don’t see the native-inputs field in the patch.  Shouldn’t the “patch”
and “patch-file” inputs be native-inputs?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net