Re: [PATCH 1/9] gnu: python-dateutils-2: Update to 2.5.3.

[Danny Milosavljevic]

Hi ng0,

I've fixed the typo in the commit message (s/dateutils/dateutil/) and applied 
to master, commit 6bd9ad6942d29163b87ca732ce562a098147513b. It causes rebuild 
of 56 packages.

Re: Guix package incubator (later a channel)

[Pjotr Prins]

On Tue, Feb 07, 2017 at 08:38:58PM +0100, Ricardo Wurmus wrote:
> This makes me wonder if the presumed benefits of an incubator could
> actually be realised.  I would like to advise against recommending an
> “incubator” procedure like this as an official alternative to
> submissions to the mailing list.

I don't have the intention of making the incubator a formal part of
the Guix package submission system, so there is no reason to recommend
it. It is also clear to me that the current workflow works for the
current and experienced package maintainers.  The current ML-based and
bug-tracking system remains the authoritative one. You don't have to
be involved with the incubator.

It is also clear to me that the current system has a high barrier to
entry and actively prevents people from starting up and even
continuing. So, I want an alternative. 

The incubator invites anyone to submit patches in their own way on
their own trees. These contributors are encouraged to work towards a
final patch which will be submitted to the ML - that is when you take
over.  Exactly what an incubator does: small chicks get to be full
grown and egg laying chicken (what happens to the males you don't want
to know).  Maybe some of us will never outgrow being chicks. It will
be a learning experience for me too.

The current state of affairs is that people are working off the main
ML and packages never make it into Guix. I am a case in point. I want
more people to track my 100+ packages. With the incubator I hope to
increase visibility of people dabbling in Guix. It is not a large step
since I have been working this way with a number of other people for
some time. You can check the logs of genenetwork/guix-bioinformatics
on github. Some packages made it into main line, including the ldc D
compiler.

So, it serves a purpose. It does not require your involvement. It may
lead to more people contributing. In the worst case, the incubator
fails as an experiment. Main choice now is that we move away from
github - and I think that is a good idea. If the GNU git repo could be
forked on savannah we would do that - but that is no option. So, I am
looking for an alternative. 

Pj.

Re: [PATCH] gnu: Add lshw.

[Leo Famulari]

On Tue, Feb 07, 2017 at 06:00:37PM +0100, Marius Bakke wrote:
> "Boskovits, Gábor"  writes:
> 
> > +(define-public lshw
> 
> Pushed as 189d8422573bdcb9392dad76426ab3e9518017ec !

Woo-hoo! I missed this one recently. Thanks Gábor and Marius!


signature.asc
Description: PGP signature

Re: Packaging leiningen (feedback desired)

[Catonano]

2017-02-08 0:00 GMT+01:00 Ben Woodcroft :

> Hi Danny, Alex,
>
>
> On 07/02/17 18:19, Danny Milosavljevic wrote:
>
>> Hmmm... works for me with:
>>
>> $ java -cp "${HOME}/.guix-profile/share/java/clojure-1.8.0.jar"
>> clojure.main
>>
>> (Note: java -> /gnu/store/4lnjmsr4szhqyixy238xjl83k8h5f0ck-icedtea-3.2.0/
>> bin/java)
>>
>> Also works within guix environment --ad-hoc clojure.
>>
> I was unable to use that command with that exact environment (clojure
> doesn't propagate any java), but it does work when icedtea is added i.e.
>
> guix environment --container --ad-hoc clojure icedtea
>
> I'm not expert enough to comment on whether the clojure package itself
> needs to be changed, but this is a workaround at least.
> ben
>
>
>
>
>
The Clojure compilation target is the Jvm. Any Clojure based software needs
a Jvm in order to run

And the Clojure REPL is a Clojure based program. Without a Jvm it won' t
run.

I don' t remember now if the compiler is written in Java or in Clojure.
Anyway, the compiler too needs a Jvm in order to run.

That is to say that as far as I understand both Clojure and Guix, a Java
runtime should be a propagated input of any Clojure package.

Re: Packaging leiningen (feedback desired)

[Ben Woodcroft]

Hi Danny, Alex,

On 07/02/17 18:19, Danny Milosavljevic wrote:

Hmmm... works for me with:

$ java -cp "${HOME}/.guix-profile/share/java/clojure-1.8.0.jar" clojure.main

(Note: java -> 
/gnu/store/4lnjmsr4szhqyixy238xjl83k8h5f0ck-icedtea-3.2.0/bin/java)

Also works within guix environment --ad-hoc clojure.
I was unable to use that command with that exact environment (clojure 
doesn't propagate any java), but it does work when icedtea is added i.e.


guix environment --container --ad-hoc clojure icedtea

I'm not expert enough to comment on whether the clojure package itself 
needs to be changed, but this is a workaround at least.

ben

Re: [PATCH 00/10] ocaml patches

[Ben Woodcroft]

Hi Julien,

On 08/02/17 06:16, Julien Lepiller wrote:

On Tue, 31 Jan 2017 21:58:05 +0100
Julien Lepiller  wrote:


Here is the next series of patches. I think I took into account all
of your previous remarks, so it should be faster.

Julien Lepiller (10):
   gnu: Add ocaml-fieldslib.
   gnu: Add ocaml-ppx-core.
   gnu: Add ocaml-ppx-optcomp.
   gnu: Add ocaml-ppx-driver.
   gnu: Add ocaml-cppo.
   gnu: Add ocaml-ppx-deriving.
   gnu: Add ocaml-ppx-type-conv.
   gnu: Add ocaml-ppx-inline-test.
   gnu: Add ocaml-ppx-bench.
   gnu: Add ocaml-ppx-compare.

  gnu/packages/ocaml.scm | 255
+ 1 file changed, 255
insertions(+)


Up?

Can I push them?

I've been meaning to review these patches but haven't found the time..

If they pass 'guix lint' then I would think it is OK to push them. 
Thanks for your efforts on the OCaml front.

ben

Re: FOSDEM 2017 what a success!!

[Christopher Allan Webber]

Ludovic Courtès writes:

> It confirmed my feeling that one of the greatest things about Guile and
> Guix is the people.  Thanks for the great talks and the good time we’ve
> had!

+1.  The Guile/Guix devroom has been some of the most fun I've ever had
at a conference.  I'm sure 2018 will be great too, and I'm looking
forward to all the things that will happen in the next year! :)

 - Chris

Re: Guix package incubator (later a channel)

[ng0]

On 17-02-07 20:38:58, Ricardo Wurmus wrote:
> 
> Hi Pjotr,
> 
> during the panel on the Future of Guix we all agreed that there is a
> need to lower the barrier to entry for package submissions to Guix, so
> it is good to start a discussion about actionable steps we can take to
> make this happen.
> 
> > After yesterday's FOSDEM discussion I propose to set up a 'Guix
> > incubator' git tree using Gitlab. The master branch will track the
> > main Guix master but project can run on forked trees and branches. The
> > idea is to have patches prepared by new committers or by people who
> > simply prefer to use a web-based git environment. Each of these trees
> > can become a guix channel - once we have channels to support that.
> 
> During the panel we had a question from the audience about alternative
> tools, e.g. to allow a workflow that is not email-based.  While I can
> understand the desire to use a workflow that you may be used to from
> other projects (this goes both ways) there is a danger in establishing
> alternatives to the channels on which we accept contributions.
> 
> At this point in the evolution of Guix we have many more contributors
> than people who can mentor the contributors, polish their patches for
> inclusion upstream, or provide constructive comments.  Having so many
> people contribute is great!  But it also means that we need to be
> careful with our limited number of mentors.
> 
> I see two possible outcomes of establishing an additional “incubator”
> repository: it might fragment our review community as some people will
> try to upstream incubator patches and others handle mailing list
> patches; another outcome is that the incubator never gets accepted by
> reviewers and mentors because it is more work, leading to growing
> parallel infrastructure and second-class code.  Neither of these
> outcomes is desirable in my opinion.
> 
> > It won't hamper the normal process since ready patches still get
> > compiled and submitted through the mailing list (ML). In fact it may
> > help scale the review process by getting peer reviewers involved. The
> > idea is that we have an incubator environment before the ML which
> > allows for playful learning and tracking of patches that may (or may
> > not) make it into main line. I think it is very important to have a
> > low barrier to entry when it comes to submitting package recipes.
> 
> I appreciate your desire to reduce the work load of reviewers/mentors on
> the mailing list.  I have some doubts about whether this approach would
> be feasible, though.  There already *are* external repositories outside
> of Guix, either implemented to be used with GUIX_PACKAGE_PATH (such as
> your own “genenetwork/guix-bioinformatics” repo or the MDC’s
> “guix-bimsb”) or as forks of Guix (e.g. public versions of what most
> Guix developers do locally to add packages).  I have not seen any
> concerted efforts to upstream package definitions from either of these
> classes of repositories.
> 
> This makes me wonder if the presumed benefits of an incubator could
> actually be realised.  I would like to advise against recommending an
> “incubator” procedure like this as an official alternative to
> submissions to the mailing list.
> 
> Our workflow involving the mailing list is far from perfect.  We had
> further discussions over post-FOSDEM dinner and drinks and there seemed
> to be consensus among the people present (including long time
> contributors, reviewers, and successful mentors) that it would be a
> great improvement to keep track of package contributions in a separate
> Debbugs instance (e.g. one “bug” per package submission).  It gives us a
> way to track the state of things more easily, it accomodates people who
> prefer to use a web browser, it permits us to continue to use email, and
> it doesn’t force yet another account onto submitters.
> 
> Admittedly, the web interface that Debbugs comes with is kinda bland and
> hard to use, so a second step would be to develop a better UI frontend
> to Debbugs that would be closer to what people expect from an issue
> tracker.
> 
> This was discussed before at
> 
> and we could request a separate Debbugs instance for
> “guix-packa...@gnu.org” *right now* if we wanted to.
> 
> What do other people think about this?
> 
> --
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 
> 

The here mentioned debbugs solution would work now and it would have
an immediate 
effect. I really welcome this solution as a first step to try out
alternatives and I would make use of it.

Regarding the approach Pjotr suggested: would it be like
https://wiki.gentoo.org/wiki/Gentoo_Github ( See also:
https://wiki.gentoo.org/wiki/Gentoo_Github#See_also ) ?

I do share the voiced concerns - there are little reviewers, and while the
situation with reviews is bad it is really a people problem. Tools can
improve access for newcom

Re: Guix package incubator (later a channel)

[ng0]

On 17-02-07 12:59:22, Christopher Allan Webber wrote:
> Pjotr Prins writes:
> 
> > On Mon, Feb 06, 2017 at 09:44:48PM +, ng0 wrote:
> >> Just a reply on the notabug question (I don't have much time otherwise):
> >> Notabug will eventually move to an instance of pagure.io, you can read
> >> about this in their own issues where I asked about some question back
> >> then (no link, sorry .. my name was 'ng0' back on there). Developing
> >> with pagure might be easier (fedora and surrounding communities)
> >> compared to the situation they describe in the issue.
> >> I started packaging pagure for this reason, which is about ~85% done
> >> (services + pagure itself left to wrap it up ... pagure itself is more
> >> or less done, just the service are needed. I'm more than happy to pass
> >> this on (could rebase the pagure patch), as I know I have taken on some
> >> tasks which would be better handled by different people :)
> >> That is in case you want to use a GuixSD as a host, otherwise you should
> >> not have many problems.
> >
> > That would be a great result :). Also pagure looks very interesting -
> > simpler than gitlab. I like simple.
> 
> It does look good:
> 
>   Open data: Sources, doc, ticket and pull-requests meta-data are
>   available in the web interface but also in git repos which can thus be
>   cloned and changed locally.
> 
> That's really appealing.
> 

The only thing we found (not answered, but I didn't check so far with
pagure development team) is that issues and pull requests are read-only
git repositories. Maybe our short trip into pagure was too short to
answer this, but it looked like read-only, no push. One reason why I
want an local instance to play with so I can check wether my
feature-issues are really issues or just pagure.io instance
configuration settings.
Also no trace of the "pull requests" across different hosted
instance of it, but that can be solved aswell later.

I agree with Pjotr, doesn't matter for now, might matter later.


-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: [PATCH 00/10] ocaml patches

[Julien Lepiller]

On Tue, 31 Jan 2017 21:58:05 +0100
Julien Lepiller  wrote:

> Here is the next series of patches. I think I took into account all
> of your previous remarks, so it should be faster.
> 
> Julien Lepiller (10):
>   gnu: Add ocaml-fieldslib.
>   gnu: Add ocaml-ppx-core.
>   gnu: Add ocaml-ppx-optcomp.
>   gnu: Add ocaml-ppx-driver.
>   gnu: Add ocaml-cppo.
>   gnu: Add ocaml-ppx-deriving.
>   gnu: Add ocaml-ppx-type-conv.
>   gnu: Add ocaml-ppx-inline-test.
>   gnu: Add ocaml-ppx-bench.
>   gnu: Add ocaml-ppx-compare.
> 
>  gnu/packages/ocaml.scm | 255
> + 1 file changed, 255
> insertions(+)
> 

Up?

Can I push them?

Re: Guix package incubator (later a channel)

[Ricardo Wurmus]

Hi Pjotr,

during the panel on the Future of Guix we all agreed that there is a
need to lower the barrier to entry for package submissions to Guix, so
it is good to start a discussion about actionable steps we can take to
make this happen.

> After yesterday's FOSDEM discussion I propose to set up a 'Guix
> incubator' git tree using Gitlab. The master branch will track the
> main Guix master but project can run on forked trees and branches. The
> idea is to have patches prepared by new committers or by people who
> simply prefer to use a web-based git environment. Each of these trees
> can become a guix channel - once we have channels to support that.

During the panel we had a question from the audience about alternative
tools, e.g. to allow a workflow that is not email-based.  While I can
understand the desire to use a workflow that you may be used to from
other projects (this goes both ways) there is a danger in establishing
alternatives to the channels on which we accept contributions.

At this point in the evolution of Guix we have many more contributors
than people who can mentor the contributors, polish their patches for
inclusion upstream, or provide constructive comments.  Having so many
people contribute is great!  But it also means that we need to be
careful with our limited number of mentors.

I see two possible outcomes of establishing an additional “incubator”
repository: it might fragment our review community as some people will
try to upstream incubator patches and others handle mailing list
patches; another outcome is that the incubator never gets accepted by
reviewers and mentors because it is more work, leading to growing
parallel infrastructure and second-class code.  Neither of these
outcomes is desirable in my opinion.

> It won't hamper the normal process since ready patches still get
> compiled and submitted through the mailing list (ML). In fact it may
> help scale the review process by getting peer reviewers involved. The
> idea is that we have an incubator environment before the ML which
> allows for playful learning and tracking of patches that may (or may
> not) make it into main line. I think it is very important to have a
> low barrier to entry when it comes to submitting package recipes.

I appreciate your desire to reduce the work load of reviewers/mentors on
the mailing list.  I have some doubts about whether this approach would
be feasible, though.  There already *are* external repositories outside
of Guix, either implemented to be used with GUIX_PACKAGE_PATH (such as
your own “genenetwork/guix-bioinformatics” repo or the MDC’s
“guix-bimsb”) or as forks of Guix (e.g. public versions of what most
Guix developers do locally to add packages).  I have not seen any
concerted efforts to upstream package definitions from either of these
classes of repositories.

This makes me wonder if the presumed benefits of an incubator could
actually be realised.  I would like to advise against recommending an
“incubator” procedure like this as an official alternative to
submissions to the mailing list.

Our workflow involving the mailing list is far from perfect.  We had
further discussions over post-FOSDEM dinner and drinks and there seemed
to be consensus among the people present (including long time
contributors, reviewers, and successful mentors) that it would be a
great improvement to keep track of package contributions in a separate
Debbugs instance (e.g. one “bug” per package submission).  It gives us a
way to track the state of things more easily, it accomodates people who
prefer to use a web browser, it permits us to continue to use email, and
it doesn’t force yet another account onto submitters.

Admittedly, the web interface that Debbugs comes with is kinda bland and
hard to use, so a second step would be to develop a better UI frontend
to Debbugs that would be closer to what people expect from an issue
tracker.

This was discussed before at

and we could request a separate Debbugs instance for
“guix-packa...@gnu.org” *right now* if we wanted to.

What do other people think about this?

--
Ricardo

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

Re: Guix package incubator (later a channel)

[Christopher Allan Webber]

Pjotr Prins writes:

> On Mon, Feb 06, 2017 at 09:44:48PM +, ng0 wrote:
>> Just a reply on the notabug question (I don't have much time otherwise):
>> Notabug will eventually move to an instance of pagure.io, you can read
>> about this in their own issues where I asked about some question back
>> then (no link, sorry .. my name was 'ng0' back on there). Developing
>> with pagure might be easier (fedora and surrounding communities)
>> compared to the situation they describe in the issue.
>> I started packaging pagure for this reason, which is about ~85% done
>> (services + pagure itself left to wrap it up ... pagure itself is more
>> or less done, just the service are needed. I'm more than happy to pass
>> this on (could rebase the pagure patch), as I know I have taken on some
>> tasks which would be better handled by different people :)
>> That is in case you want to use a GuixSD as a host, otherwise you should
>> not have many problems.
>
> That would be a great result :). Also pagure looks very interesting -
> simpler than gitlab. I like simple.

It does look good:

  Open data: Sources, doc, ticket and pull-requests meta-data are
  available in the web interface but also in git repos which can thus be
  cloned and changed locally.

That's really appealing.

[PATCH 4/6] gnu: Add python-pycosat

[Muriithi Frederick Muriuki]

* gnu/packages/python.scm (python-pycosat): New variable.
---
 gnu/packages/python.scm | 20 
 1 file changed, 20 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 44704b2..170107a 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12605,3 +12605,23 @@ faster ones are not available.")
  it with different test data, and make it appear as multiple test cases")
 (license (license:non-copyleft
   "https://github.com/txels/ddt/blob/master/LICENSE.md";
+
+(define-public python-pycosat
+  (package
+(name "python-pycosat")
+(version "0.6.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "pycosat" version))
+   (sha256
+(base32
+ "1kl3wh1f47rc712n4bmwplbx3fqz3x9i1b587jrbpmvdva4c8f6l"
+(build-system python-build-system)
+(home-page
+ "https://github.com/ContinuumIO/pycosat";)
+(synopsis "Bindings to picosat (a SAT solver)")
+(description
+ "This package provides efficient Python bindings to picosat on the C 
level, i.e.
+ when importing pycosat, the picosat solver becomes part of the Python process 
itself")
+(license license:expat)))
-- 
2.1.4

Re: [PATCH] gnu: Add python-rst2ansi

[Frederick Muriithi]

You may ignore this thread. It has been superceded by newer, cleaner commit

-- 
Frederick M. Muriithi

Re: [PATCH] gnu: Add new package definitions

[Frederick Muriithi]

You may ignore this thread. It has been superceded by newer, cleaner commit

[PATCH 5/6] gnu: Add python-typing

[Muriithi Frederick Muriuki]

* gnu/packages/python.scm (python-typing): New variable.
---
 gnu/packages/python.scm | 20 
 1 file changed, 20 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 170107a..ef3d9bd 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12625,3 +12625,23 @@ faster ones are not available.")
  "This package provides efficient Python bindings to picosat on the C 
level, i.e.
  when importing pycosat, the picosat solver becomes part of the Python process 
itself")
 (license license:expat)))
+
+(define-public python-typing
+  (package
+(name "python-typing")
+(version "3.5.3.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "typing" version))
+   (sha256
+(base32
+ "08gz3grrh3vph5ib1w5x1ssnpzvj077x030lx63fxs4kwg3slbfa"
+(build-system python-build-system)
+(home-page
+ "https://docs.python.org/3.5/library/typing.html";)
+(synopsis "Type Hints for Python")
+(description "This module supports type hints as specified by PEP 484.  
The most
+ fundamental support consists of the types Any, Union, Tuple, Callable, 
TypeVar, and
+ Generic.  For full specification please see PEP 484")
+(license license:psfl)))
-- 
2.1.4

[PATCH 1/6] gnu: Add python-rst2ansi

[Muriithi Frederick Muriuki]

* gnu/packages/python.scm (python-rst2ansi): New variable.
---
 gnu/packages/python.scm | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index d53eea1..b57e9a7 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12536,3 +12536,26 @@ console.")
 This implementation is slow (hence the project name) but still useful when
 faster ones are not available.")
 (license license:asl2.0)))
+
+(define-public python-rst2ansi
+  (package
+(name "python-rst2ansi")
+(version "0.1.5")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "rst2ansi" version))
+   (sha256
+(base32
+ "0vzy6gd60l79ff750scl0sz48r1laalkl6md6dwzah4dcadgn5qv"
+(build-system python-build-system)
+(native-inputs
+ `(("python-docutils" ,python-docutils)))
+(home-page
+ "https://github.com/Snaipe/python-rst-to-ansi";)
+(synopsis
+ "Python rst converter to ansi-decorated console output")
+(description
+ "Python module dedicated to rendering RST (reStructuredText) documents to
+ ansi-escaped strings suitable for display in a terminal")
+(license license:expat)))
-- 
2.1.4

[PATCH 6/6] gnu: Add python-ruamel.ordereddict

[Muriithi Frederick Muriuki]

* gnu/packages/python.scm (python-ruamel.ordereddict): New variable.
---
 gnu/packages/python.scm | 28 
 1 file changed, 28 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index ef3d9bd..e1e4e74 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12645,3 +12645,31 @@ faster ones are not available.")
  fundamental support consists of the types Any, Union, Tuple, Callable, 
TypeVar, and
  Generic.  For full specification please see PEP 484")
 (license license:psfl)))
+
+(define-public python-ruamel.ordereddict
+  (package
+(name "python-ruamel.ordereddict")
+(version "0.4.9")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "ruamel.ordereddict" version))
+   (sha256
+(base32
+ "1xmkl8v9l9inm2pyxgc1fm5005yxm7fkd5gv74q7lj1iy5qc8n3h"
+(build-system python-build-system)
+(arguments
+ `(#:python ,python-2))
+(home-page
+ "https://bitbucket.org/ruamel/ordereddict";)
+(synopsis
+ "Version of dict that keeps keys in insertion resp. sorted order")
+(description
+ "This is an implementation of an ordered dictionary with Key Insertion 
Order (KIO:
+ updates of values do not affect the position of the key), Key Value Insertion 
Order
+ (KVIO, an existing key's position is removed and put at the back).  The 
standard library
+ module OrderedDict, implemented later, implements a subset of ordereddict 
functionality.
+Sorted dictionaries are also provided.  Currently only with Key Sorted Order 
(KSO, no
+ sorting function can be specified, but a transform can be specified to apply 
on the key
+ before comparison (e.g. string.lower))")
+(license license:expat)))
-- 
2.1.4

[PATCH 2/6] gnu: Add python-flake8-polyfill

[Muriithi Frederick Muriuki]

* gnu/packages/python.scm (python-flake8-polyfill): New variable.
---
 gnu/packages/python.scm | 21 +
 1 file changed, 21 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index b57e9a7..b39d8b1 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12559,3 +12559,24 @@ faster ones are not available.")
  "Python module dedicated to rendering RST (reStructuredText) documents to
  ansi-escaped strings suitable for display in a terminal")
 (license license:expat)))
+
+(define-public python-flake8-polyfill
+  (package
+(name "python-flake8-polyfill")
+(version "1.0.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "flake8-polyfill" version))
+   (sha256
+(base32
+ "02gn2wxvh9vnf7m7dld7ca4l60mg5c370hv3swwppkngwaqmcw67"
+(build-system python-build-system)
+(inputs
+ `(("python-flake8" ,python-flake8)))
+(home-page "https://gitlab.com/pycqa/flake8";)
+(synopsis "Polyfill package for Flake8 plugins")
+(description
+ "This package that provides some compatibility helpers for Flake8 plugins 
that
+ intend to support Flake8 2.x and 3.x simultaneously")
+(license license:expat)))
-- 
2.1.4

[PATCH 3/6] gnu: Add python-ddt

[Muriithi Frederick Muriuki]

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index b39d8b1..44704b2 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12580,3 +12580,28 @@ faster ones are not available.")
  "This package that provides some compatibility helpers for Flake8 plugins 
that
  intend to support Flake8 2.x and 3.x simultaneously")
 (license license:expat)))
+
+(define-public python-ddt
+  (package
+(name "python-ddt")
+(version "1.1.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (pypi-uri "ddt" version))
+   (sha256
+(base32
+ "1c00ikkxr7lha97c81k938bzhgd4pbwamkjn0h4nkhr3xk00zp6n"
+(build-system python-build-system)
+(native-inputs
+ `(("python-mock" ,python-mock)
+   ("python-nose" ,python-nose)))
+(inputs
+ `(("python-six" ,python-six)
+   ("python-pyyaml" ,python-pyyaml)))
+(home-page "https://github.com/txels/ddt";)
+(synopsis "Data-Driven/Decorated Tests")
+(description "DDT (Data-Driven Tests) allows you to multiply one test case 
by running
+ it with different test data, and make it appear as multiple test cases")
+(license (license:non-copyleft
+  "https://github.com/txels/ddt/blob/master/LICENSE.md";
-- 
2.1.4

playing nice with other OSs

[Federico Beffa]

Hi,

I'm looking into the possibility of installing GuixSD in parallel with
another operating system on a single machine (dual boot).  Looking
into the code (gnu system grub) I see that the GRUB "linux" and
"initrd" commands are hardwired into the code.  This appears to make
the definition of a  for another operating system
(GNU/Hurd, NetBSD, Windows, ...) impossible.  Am I right, or am I
overlooking something?

If the above is correct and we want to make GuixSD play nicely with
others, then I suppose that we will have to modify the 
record.  I see two possibilities:

* We could try to generalize the fields along the lines of linux ->
kernel, initrd -> kernel-boot-helpers, ...

* Define operating system specific records such as ,
, , ..., where the content of
the fields for the systems not handled by GuixSD would come from the
user operating-system file configuration.

I personally prefer the second approach. What do you think?

Regards,
Fede

Re: Running services in containers

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Those who didn’t have the luck to be at FOSDEM missed this not-so-visual
> demo I made of a Shepherd service running in a container.  :-)
>
> I’ve polished the thing on my way back and pushed the result, using
> BitlBee as an example:
>
>   
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=63302a4e55241a41eab4c21d7af9fbd0d5817459
>   
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=a062b6ca99ad61c9df473fe49a93d69f9698c59d
>

This is very cool!  I’m amazed at how you got this ready in time for
your talk.  I’m sure you didn’t just keep this under wraps for weeks :)

--
Ricardo

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

Re: [PATCH] gnu: Add new package definitions

[Frederick Muriithi]

On Tue, Feb 7, 2017 at 7:24 PM, Danny Milosavljevic
 wrote:
> Hi,
>
> +(name "python-pycosat")
> +(version "0.6.1")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append
> + 
> "https://pypi.python.org/packages/76/0f/16edae7bc75b79376f2c260b7a459829785f";
> + "08e463ecf74a8ccdef62dd4a/pycosat-"
> + version
> + ".tar.gz"))
>
> Please use (uri (pypi-uri "pycosat" version)). Or does it fail?
>

Okay. Let me fix that.

> +(name "python-ruamel.ordereddict")
> +(version "0.4.9")
> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append
> + 
> "https://pypi.python.org/packages/b1/17/97868578071068fe7d115672b52624d421ff";
> + "24e5e802f65d6bf3ea184e8f/ruamel.ordereddict-"
> + version
> + ".tar.gz"))
>
> pypi-uri
>
> +   (sha256
> +(base32
> + "1xmkl8v9l9inm2pyxgc1fm5005yxm7fkd5gv74q7lj1iy5qc8n3h"
> +(build-system python-build-system)
>
> +(arguments
> + `(#:python ,python-2))
>
> Why does python-ruamel.ordereddict use python-2? (as opposed to 
> python2-ruamel.ordereddict using python-2 and python-ruamel.ordereddict using 
> python)

So far, I have tried to build python-ruamel.ordereddict with python3,
but it fails in the build_ext stage (building C extensions), with
python3, but passes with python2.


-- 
Frederick M. Muriithi

Re: [PATCH] gnu: Add lshw.

[Marius Bakke]

"Boskovits, Gábor"  writes:

> +(define-public lshw
> +  (package
> +(name "lshw")
> +(version "B.02.18")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append "http://www.ezix.org/software/";
> +  "files/lshw-" version
> +  ".tar.gz"))
> +  (sha256
> +   (base32
> +"0brwra4jld0d53d7jsgca415ljglmmx1l2iazpj4ndilr48yy8mf"
> +(build-system gnu-build-system)
> +(arguments
> +  `(#:phases (modify-phases %standard-phases (delete 'configure));no 
> configure
> +#:tests? #f
> +#:make-flags
> +  (list (string-append "PREFIX=" (assoc-ref %outputs "out")
> +(synopsis "Hardware Lister (lshw)")
> +(description
> + "lshw (Hardware Lister) is a small tool to provide detailed
> +information on the hardware configuration of the machine.  It can
> +report exact memory configuration, firmware version, mainboard
> +configuration, CPU version and speed, cache configuration, bus speed,
> +etc. on DMI-capable x86 or EFI (IA-64) systems and on some PowerPC
> +machines (​PowerMac G4 is known to work).")
> +(home-page "http://www.ezix.org/project/wiki/HardwareLiSter";)
> +(license gpl2)))

Thank you for this! I moved it to linux.scm, added a copyright line for
you and changed the URLs to use HTTPS. Also did very minor tweaks to
description.

Pushed as 189d8422573bdcb9392dad76426ab3e9518017ec !


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add new package definitions

[Danny Milosavljevic]

Hi,

+(name "python-pycosat")
+(version "0.6.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ 
"https://pypi.python.org/packages/76/0f/16edae7bc75b79376f2c260b7a459829785f";
+ "08e463ecf74a8ccdef62dd4a/pycosat-"
+ version
+ ".tar.gz"))

Please use (uri (pypi-uri "pycosat" version)). Or does it fail?

+(name "python-ruamel.ordereddict")
+(version "0.4.9")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ 
"https://pypi.python.org/packages/b1/17/97868578071068fe7d115672b52624d421ff";
+ "24e5e802f65d6bf3ea184e8f/ruamel.ordereddict-"
+ version
+ ".tar.gz"))

pypi-uri

+   (sha256
+(base32
+ "1xmkl8v9l9inm2pyxgc1fm5005yxm7fkd5gv74q7lj1iy5qc8n3h"
+(build-system python-build-system)

+(arguments
+ `(#:python ,python-2))

Why does python-ruamel.ordereddict use python-2? (as opposed to 
python2-ruamel.ordereddict using python-2 and python-ruamel.ordereddict using 
python)

Re: 01/01: gnu: grub-efi: Really build the EFI variant.

[Marius Bakke]

Ludovic Courtès  writes:

> civodul pushed a commit to branch master
> in repository guix.
>
> commit ef753a1a8f9e7c971957abfda9b672a7728cd073
> Author: Ludovic Courtès 
> Date:   Tue Feb 7 11:14:09 2017 +0100
>
> gnu: grub-efi: Really build the EFI variant.
> 
> Fixes a regression introduced in
> d846834fc2b2f76aa2e258685bc211edd31866c5 where '--with-platform=efi'
> would no longer be passed.
> 
> * gnu/packages/grub.scm (grub-efi)[arguments]: Provide a default value
> for #:configure-flags.

[...]

> @@ -139,8 +139,8 @@ menu to select one of the installed operating systems.")
> ;; Search for 'OVMF' in "tests/util/grub-shell.in".
> #:tests? #f
> ,@(substitute-keyword-arguments (package-arguments grub)
> -   ((#:configure-flags flags) `(cons* "--with-platform=efi"
> -  ,flags))
> +   ((#:configure-flags flags ''())
> +`(cons "--with-platform=efi" ,flags))
> ((#:phases phases)
>  `(modify-phases ,phases
> (add-after 'patch-stuff 'use-absolute-efibootmgr-path

Thank you for this! I did test grub-efi with the new grub release, but
then afterwards checked whether the #:configure-flags were still needed.

I will be more careful about this in the future.


signature.asc
Description: PGP signature

Re: [Sharing store/state between Nix and Guix]: How stable is it?

[rohit yadav]

On Mon, Feb 6, 2017 at 11:50 PM, Pjotr Prins 
wrote:

> On Mon, Feb 06, 2017 at 04:14:04PM -0600, rohit yadav wrote:
> >Hi,
> >Is there anyone who has experimented with above mentioned idea? In
> theory
> >it may be possible, I am just wondering how stable is it? Assuming, I
> >installed a package with guix, it should change the database, create
> a new
> >profile. As long as ~/.nix-profile or ~/.guix-profile points to
> current
> >profile I should see the changes in list of packages in the current
> >generation. So, at higher level it should almost be indistinguishable
> >whether nix or guix is used to manage the profiles.
>
> Yes, it is perfectly safe and some people do that. Note that I would
> not *share* the DB and store - just have them separate and they
> coexist fine.
>
Actually my question was whether DB and Store can be shared. Guix and Nix
only changes the databases depending on what is installed and updating the
current generation.​

>
> >Is there any plan to change the nix core completely (reimplement using
> >scheme guile) in the future?
>
> When someone feels the itch it may happen. At FOSDEM someone joked
> that we should support the Nix language in Guix - i.e., write a Nix to
> Guile interpreter to support Nix packages live in Guix. Alternatively
> run two daemons.
>
​- Yes, that may be useful. This way we can benefit from the work of NixOS
community.​

>
> Pj.
>
> --
>

Re: [Install guix packages to non-default]: Unable to build derivation hello

[rohit yadav]

​Hi,

Thanks for fixing the linux-libre (I am yet to try). However, my other
question is why linux-libre is required to build hello?

Thanks,
Rohit​

On Tue, Feb 7, 2017 at 7:56 AM, Ludovic Courtès  wrote:

> Hello,
>
> rohit yadav  skribis:
>
> > Starting download of
> > /home/royadav/opt/guix/local/gnu/store/gc4i3fsgliw4y7j4kc6ad1574h7qhd
> vb-linux-libre-4.4.18-gnu.tar.xz
>
> [...]
>
> > ERROR: download failed "
> > http://mirror.hydra.gnu.org/file/fsgliw4y7j4kc6ad1574h7qhdvb-
> linux-libre-4.4.18-gnu.tar.xz/sha256/0k8k17in7dkjd9d8zg3i8l1ax466db
> a6bxw28flxizzyq8znljps"
> > 404 "Not Found"
>
> Ooh, there’s a bug here.  The URL should be:
>
>   https://mirror.hydra.gnu.org/file/linux-libre-4.4.18-gnu.tar.xz/sha256/
> 0k8k17in7dkjd9d8zg3i8l1ax466dba6bxw28flxizzyq8znljps
>
> (Compare the part right after “/file.”)
>
> I believe this is fixed by 328f7cbe435d79d61f57129d9e3ee90404d6bfda.
>
> Now, you can either build and install guix-daemon from ‘master’, or
> simply make sure to do:
>
>   export NIX_STORE=/home/royadav/opt/guix/local/gnu/store
>
> in the environment where guix-daemon runs.
>
> If you’re using systemd, I guess you can add this setting in the unit
> file.
>
> Once you’ve done that, you should be able to download this tarball from
> mirror.hydra.gnu.org transparently.
>
> HTH!
>
> Ludo’.
>

[PATCH] gnu: Add new package definitions

[Frederick Muriithi]

The patches add new package definitions. The packages are independent
of each other.

-- 
Frederick M. Muriithi
From 30a446254e4a488b891ee3b9a7eebfb3bc65cb90 Mon Sep 17 00:00:00 2001
From: Muriithi Frederick Muriuki 
Date: Tue, 7 Feb 2017 18:00:25 +0300
Subject: [PATCH 1/3] gnu: Add python-pycosat

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 6562df4..419255b 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12590,3 +12590,27 @@ faster ones are not available.")
  it with different test data, and make it appear as multiple test cases")
 (license (license:non-copyleft
   "https://github.com/txels/ddt/blob/master/LICENSE.md";
+
+(define-public python-pycosat
+  (package
+(name "python-pycosat")
+(version "0.6.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://pypi.python.org/packages/76/0f/16edae7bc75b79376f2c260b7a459829785f";
+ "08e463ecf74a8ccdef62dd4a/pycosat-"
+ version
+ ".tar.gz"))
+   (sha256
+(base32
+ "1kl3wh1f47rc712n4bmwplbx3fqz3x9i1b587jrbpmvdva4c8f6l"
+(build-system python-build-system)
+(home-page
+ "https://github.com/ContinuumIO/pycosat";)
+(synopsis "Bindings to picosat (a SAT solver)")
+(description
+ "This package provides efficient Python bindings to picosat on the C level, i.e.
+ when importing pycosat, the picosat solver becomes part of the Python process itself")
+(license license:expat)))
-- 
2.1.4

From f1bff5976dbb8b943ec73355732ddfd6b8d24ad1 Mon Sep 17 00:00:00 2001
From: Muriithi Frederick Muriuki 
Date: Tue, 7 Feb 2017 18:08:34 +0300
Subject: [PATCH 2/3] gnu: Add python-typing

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 419255b..9b23760 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12614,3 +12614,27 @@ faster ones are not available.")
  "This package provides efficient Python bindings to picosat on the C level, i.e.
  when importing pycosat, the picosat solver becomes part of the Python process itself")
 (license license:expat)))
+
+(define-public python-typing
+  (package
+(name "python-typing")
+(version "3.5.3.0")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://pypi.python.org/packages/b6/0c/53c42edca789378b8c05a5496e689f44e5dd";
+ "82bc6861d1ae5a926ee51b84/typing-"
+ version
+ ".tar.gz"))
+   (sha256
+(base32
+ "08gz3grrh3vph5ib1w5x1ssnpzvj077x030lx63fxs4kwg3slbfa"
+(build-system python-build-system)
+(home-page
+ "https://docs.python.org/3.5/library/typing.html";)
+(synopsis "Type Hints for Python")
+(description "This module supports type hints as specified by PEP 484.  The most
+ fundamental support consists of the types Any, Union, Tuple, Callable, TypeVar, and
+ Generic.  For full specification please see PEP 484")
+(license license:psfl)))
-- 
2.1.4

From 84995a2a5726ab624d238795eead23e08ec9a024 Mon Sep 17 00:00:00 2001
From: Muriithi Frederick Muriuki 
Date: Tue, 7 Feb 2017 18:21:54 +0300
Subject: [PATCH 3/3] gnu: Add python-ruamel.ordereddict

* gnu/packages/python.scm (python-ruamel.ordereddict): New varible.
---
 gnu/packages/python.scm | 32 
 1 file changed, 32 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 9b23760..c0ccf6c 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12638,3 +12638,35 @@ faster ones are not available.")
  fundamental support consists of the types Any, Union, Tuple, Callable, TypeVar, and
  Generic.  For full specification please see PEP 484")
 (license license:psfl)))
+
+(define-public python-ruamel.ordereddict
+  (package
+(name "python-ruamel.ordereddict")
+(version "0.4.9")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://pypi.python.org/packages/b1/17/97868578071068fe7d115672b52624d421ff";
+ "24e5e802f65d6bf3ea184e8f/ruamel.ordereddict-"
+ version
+ ".tar.gz"))
+   (sha256
+(base32
+ "1xmkl8v9l9inm2pyxgc1fm5005yxm7fkd5gv74q7lj1iy5qc8n3h"
+(build-system python-build-system)
+(arguments
+ `(#:python ,python-2))
+(home-page
+ "https://bitbucket.org/ruamel/ordereddict";)
+(synopsis
+ "Version of dict that keeps keys in insertion resp. sorted order")
+(description
+ "This is an implementation of an ordered dictionary with Key Insertion Order (KIO:
+ updates of values do not affect

[PATCH] gnu: Add python-ddt

[Frederick Muriithi]

-- 
Frederick M. Muriithi
From a87ecb1e19a2463ba1223415bc066f135e21ca5b Mon Sep 17 00:00:00 2001
From: Muriithi Frederick Muriuki 
Date: Tue, 7 Feb 2017 17:35:01 +0300
Subject: [PATCH] gnu: Add python-ddt

* gnu/packages/python.scm (python-ddt): New variable.
---
 gnu/packages/python.scm | 29 +
 1 file changed, 29 insertions(+)

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 73a467f..6562df4 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12561,3 +12561,32 @@ faster ones are not available.")
  "This package that provides some compatibility helpers for Flake8 plugins that
  intend to support Flake8 2.x and 3.x simultaneously")
 (license license:expat)))
+
+(define-public python-ddt
+  (package
+(name "python-ddt")
+(version "1.1.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://pypi.python.org/packages/83/96/21a2cef2962a07768854d411a97366292669";
+ "3173887560895e962cf952c9/ddt-"
+ version
+ ".tar.gz"))
+   (sha256
+(base32
+ "1c00ikkxr7lha97c81k938bzhgd4pbwamkjn0h4nkhr3xk00zp6n"
+(build-system python-build-system)
+(native-inputs
+ `(("python-mock" ,python-mock)
+   ("python-nose" ,python-nose)))
+(inputs
+ `(("python-six" ,python-six)
+   ("python-pyyaml" ,python-pyyaml)))
+(home-page "https://github.com/txels/ddt";)
+(synopsis "Data-Driven/Decorated Tests")
+(description "DDT (Data-Driven Tests) allows you to multiply one test case by running
+ it with different test data, and make it appear as multiple test cases")
+(license (license:non-copyleft
+  "https://github.com/txels/ddt/blob/master/LICENSE.md";
-- 
2.1.4

Re: [PATCH] gnu: dub: Patch pkg-config name.

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> On Fri, 03 Feb 2017 17:49:38 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> I think ‘dub-build-system’ could add it as an implicit input, much like
>> ‘gnu-build-system’ adds binutils as an implicit input.
>
> Okay, but it's directly used only by dub (it its function of building D 
> packages).
>
> I don't think D packages themselves even know what pkg-config is.
>
> The ldc 1.1.0 sources don't even mention "pkg-config" once - neither do any 
> of the D packages I tried except gtk-d. That one mentions it in comments how 
> to invoke gdc (which we didn't package) and rdmd (rdmd source itself doesn't 
> mention pkg-config either) - both are in shell expressions like gdc CoreGL.d 
> `pkg-config gtkd-3 gl --cflags --libs` and rdmd `pkg-config gtkd-3 --cflags` 
> -L-lGL -L-ldl CoreGL.d). No non-comment reference at all.

OK.

> That said, we could add pkg-config as an implicit input so that if D packages 
> decided to directly use it in the future they'd pick up the same one.

Yeah.

>> Or we could simply let people add pkg-config as an input when it’s
>> necessary, just like we do for ‘gnu-build-system’ packages.
>
> dub itself does automatically use pkg-config.
> It's as if make always used pkg-config (whether you write "pkg-config" into a 
> Makefile or not).
>
> Also, if pkg-config is not available dub will silently fallback to guessing. 
> It will not fail (and that's bad!).

OK.

Well I think the conclusion is that (1) we really need to make sure DUB
has pkg-config around one way or another, and (2) of all the solutions
we discussed, I don’t see one that is significantly “better” than the
other (it was worth discussing them though, because in many cases
there’s a solution that “looks better”).

So I’d say proceed as you prefer.

Thanks for taking the time to explain!

Ludo’.

Re: [Install guix packages to non-default]: Unable to build derivation hello

[Ludovic Courtès]

Hello,

rohit yadav  skribis:

> Starting download of
> /home/royadav/opt/guix/local/gnu/store/gc4i3fsgliw4y7j4kc6ad1574h7qhdvb-linux-libre-4.4.18-gnu.tar.xz

[...]

> ERROR: download failed "
> http://mirror.hydra.gnu.org/file/fsgliw4y7j4kc6ad1574h7qhdvb-linux-libre-4.4.18-gnu.tar.xz/sha256/0k8k17in7dkjd9d8zg3i8l1ax466dba6bxw28flxizzyq8znljps";
> 404 "Not Found"

Ooh, there’s a bug here.  The URL should be:

  
https://mirror.hydra.gnu.org/file/linux-libre-4.4.18-gnu.tar.xz/sha256/0k8k17in7dkjd9d8zg3i8l1ax466dba6bxw28flxizzyq8znljps

(Compare the part right after “/file.”)

I believe this is fixed by 328f7cbe435d79d61f57129d9e3ee90404d6bfda.

Now, you can either build and install guix-daemon from ‘master’, or
simply make sure to do:

  export NIX_STORE=/home/royadav/opt/guix/local/gnu/store

in the environment where guix-daemon runs.

If you’re using systemd, I guess you can add this setting in the unit
file.

Once you’ve done that, you should be able to download this tarball from
mirror.hydra.gnu.org transparently.

HTH!

Ludo’.

Re: CDN Mirrors for GNU Guix

[Ludovic Courtès]

Hello Tom,

Tom Li  skribis:

> Currently, GNU Guix is still in the early stage of development, and there is 
> a great
> lack of mirrors worldwide. For example. in my region, using GNU Guix is 
> incredibly
> slow, the speed is around 4 KiB/s and rendering it almost unusable.

Woow, that sounds really extreme!  Do you always have such a bandwidth,
or did you just happen to be unlucky somehow at that time?

Regardless, I agree that we should have more mirrors and a wider
distribution.

> Therefore, I created two CDN mirrors of https://mirror.hydra.gnu.org/, by 
> using
> CloudFlare and Amazon CloudFront's service. I know some have the concerns 
> about
> such type of centralized corporation-controlled service. Personally, I have 
> done my
> best to minimized the security risks (HTTPS only, untouched signatures) and 
> set ip
> up faithfully. Please use it according to your own judgement.
>
> they are available at:
>
> * https://guix-cloudflare.tomli.me/
> * https://guix-amazon.tomli.me/
>
> Since they are identical mirrors of Hydra, you just need to use 
> `--substitute-urls=`
> in order to use it.

Nice!  (Though I should say that I hate CloudFare for essentially
preventing Tor users from accessing what they host.)

I think it may be time to arrange so that mirror.hydra.gnu.org (or some
other host name?) can somehow redirect users to external mirrors.  I’m
not sure how to achieve this, so if anyone has experience in this area,
help is welcome!

Thanks,
Ludo’.

Running services in containers

[Ludovic Courtès]

Hi Guix!

Those who didn’t have the luck to be at FOSDEM missed this not-so-visual
demo I made of a Shepherd service running in a container.  :-)

I’ve polished the thing on my way back and pushed the result, using
BitlBee as an example:

  
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=63302a4e55241a41eab4c21d7af9fbd0d5817459
  
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=a062b6ca99ad61c9df473fe49a93d69f9698c59d

It works nicely!  The BitlBee daemon shares its network and user
namespaces with the system but otherwise has a private /tmp and a
private /var/run and only has access to /var/lib/bitlbee and /gnu/store.

It should make it harder for an attacker to usefully exploit a remote
code execution vulnerability such as the one recently reported¹.

Of course BitlBee is a simple example, but I think it’d be nice to
investigate what it takes to do the same for other services in the
future.  I’d like to write a post about it at some point.

Ludo’.

¹ https://bugs.bitlbee.org/ticket/1281

Re: problem of guix refresh

[Ludovic Courtès]

Hello,

tumashu  skribis:

> --
> bash-4.4$ guix refresh

[...]

> In guix/scripts/refresh.scm:
>  288: 7 [check-for-package-update # # # ...]
> In guix/import/cpan.scm:
>  274: 6 [latest-release #]
> In ice-9/boot-9.scm:
>  160: 5 [catch srfi-34 # 
> ...]
> In guix/import/json.scm:
>   32: 4 [#]
> In guix/http-client.scm:
>  241: 3 [loop #]
> In guix/build/download.scm:
>  486: 2 [open-connection-for-uri # # #f ...]
>  382: 1 [tls-wrap # "api.metacpan.org" ...]
> In unknown file:
>?: 0 [handshake #]
>
> ERROR: In procedure handshake:
> ERROR: Throw to key `gnutls-error' with args `(# 警告信息。> handshake)'.

My guess is that this is telling you that api.metacpan.org could not be
authenticated due to the lack of X.509 (HTTPS) certificates.

Could you make sure to define ‘SSL_CERT_DIR’ and have certificates
available, as described here:

  https://www.gnu.org/software/guix/manual/html_node/X_002e509-Certificates.html

?

HTH!

Ludo’.

[PATCH] gnu: Add python-flake8-polyfill

[Frederick Muriithi]

Add new package definition

-- 
Frederick M. Muriithi
From cec340f69e3f386a375a3661551d2d13521f06e9 Mon Sep 17 00:00:00 2001
From: Muriithi Frederick Muriuki 
Date: Tue, 7 Feb 2017 16:45:08 +0300
Subject: [PATCH] gnu: Add python-flake8-polyfill

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

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index d53eea1..73a467f 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -12536,3 +12536,28 @@ console.")
 This implementation is slow (hence the project name) but still useful when
 faster ones are not available.")
 (license license:asl2.0)))
+
+(define-public python-flake8-polyfill
+  (package
+(name "python-flake8-polyfill")
+(version "1.0.1")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://pypi.python.org/packages/71/6e/dd7e0f0ddf146213d0cc0b963b3d4c643482";
+ "3ebe3992c29b523182bbf785/flake8-polyfill-"
+ version
+ ".tar.gz"))
+   (sha256
+(base32
+ "02gn2wxvh9vnf7m7dld7ca4l60mg5c370hv3swwppkngwaqmcw67"
+(build-system python-build-system)
+(inputs
+ `(("python-flake8" ,python-flake8)))
+(home-page "https://gitlab.com/pycqa/flake8";)
+(synopsis "Polyfill package for Flake8 plugins")
+(description
+ "This package that provides some compatibility helpers for Flake8 plugins that
+ intend to support Flake8 2.x and 3.x simultaneously")
+(license license:expat)))
-- 
2.1.4

Re: pre-push signature hook error reporting

[Ludovic Courtès]

Marius Bakke  skribis:

> Leo Famulari  writes:
>
>> On Fri, Jan 20, 2017 at 03:05:42PM +0100, Ludovic Courtès wrote:
>>> For the pre-push hook, the overhead seems reasonable (perhaps we could
>>> limit the range to commits after the first signed commit to avoid
>>> looping for no reason?) and an improvement.
>>
>> Here is a patch for the hook that I've been using for the past couple weeks.
>>
>> For the common use case of pushing new commits to an existing branch, I
>> don't notice the hook at all, except when it catches my mistakes.
>
> Thanks a lot for this! I haven't tested it, but the code LGTM.

Ditto, thank you!

Ludo’.

Re: [PATCH] gnu: Add python-alabaster

[Frederick Muriithi]

On Sat, Feb 4, 2017 at 7:32 PM, Danny Milosavljevic
 wrote:
> Comparing them, the existing alabaster packagespec lists bsd-3 as license. 
> But you list license:non-copyleft 
> "https://github.com/bitprophet/alabaster/blob/master/LICENSE";. Is it actually 
> different?
>
> It seems  
> specifies "Some rights reserved" in addition to mostly bsd-3. I wonder 
> whether we should use your license reference instead...
>

I guess you could leave it as bsd-3 for now. I am still on a learning
curve, and so, since I could not quite tell which license it was, I
preferred to err on the side of caution and point to it directly,
since the repo did not explicitly state it was bsd-3

-- 
Frederick M. Muriithi

GuixSD lvm support

[Gábor Boskovits]

I have seen an earlier attempt to add lvm support to guixsd.
I would like to know the status of lvm support, and willing to assist with
it.

[PATCH 0/15]: Add pplacer and OCaml dependencies.

[Ben Woodcroft]

Hi there.

I'm quite happy to send these patches in, pplacer has been near the top 
of my most wanted list since I started contributing. There's two parts 
that are a little out of the ordinary:


1) Unfortunately pplacer requires the outdated OCaml 4.01, so I adapted 
the package-with-python2 approach.


2) The pplacer package itself is made up of an OCaml part, plus some 
Python scripts, so I made the scripts a different package and propagated 
that package.


Thanks in advance for any review.

ben.

>From c65a1ebb914e87849a93c056df9648895213a65b Mon Sep 17 00:00:00 2001
From: Ben Woodcroft 
Date: Mon, 2 Jan 2017 17:18:59 +1000
Subject: [PATCH 01/15] gnu: Add ocaml-4.01.

* gnu/packages/ocaml.scm (ocaml-4.01): New variable.
---
 gnu/packages/ocaml.scm | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm
index 9a0bc9112..2026def09 100644
--- a/gnu/packages/ocaml.scm
+++ b/gnu/packages/ocaml.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2016 Jan Nieuwenhuizen 
 ;;; Copyright © 2016 Efraim Flashner 
 ;;; Copyright © 2016, 2017 Julien Lepiller 
+;;; Copyright © 2017 Ben Woodcroft 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -211,6 +212,36 @@ functional, imperative and object-oriented styles of programming.")
 ;; distributed under lgpl2.0.
 (license (list license:qpl license:lgpl2.0
 
+(define-public ocaml-4.01
+  (package
+(inherit ocaml)
+(version "4.01.0")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+"http://caml.inria.fr/pub/distrib/ocaml-";
+(version-major+minor version)
+"/ocaml-" version ".tar.xz"))
+  (sha256
+   (base32
+"03d7ida94s1gpr3gadf4jyhmh5rrszd5s4m4z59daaib25rvfyv7"
+(arguments
+ (substitute-keyword-arguments (package-arguments ocaml)
+   ((#:phases phases)
+`(modify-phases ,phases
+   (replace 'build
+ (lambda _
+   ;; Specifying '-j' at all causes the build to fail.
+   (zero? (system* "make" "world.opt"
+   (replace 'check
+ (lambda _
+   (with-directory-excursion "testsuite"
+ (zero? (system*
+ "make"
+ "all"
+ (string-append
+  "TOPDIR=" (getcwd) "/.."
+
 (define-public opam
   (package
 (name "opam")
-- 
2.11.0


>From 59f91446e99562a290b86514b3c143b00c0ef053 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft 
Date: Mon, 2 Jan 2017 22:29:28 +1000
Subject: [PATCH 02/15] gnu: Add ocaml4.01-findlib.

* gnu/packages/ocaml.scm (ocaml4.01-findlib): New variable.
---
 gnu/packages/ocaml.scm | 8 
 1 file changed, 8 insertions(+)

diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm
index 2026def09..00640cd4a 100644
--- a/gnu/packages/ocaml.scm
+++ b/gnu/packages/ocaml.scm
@@ -837,6 +837,14 @@ compilation and linkage, there are new frontends of the various OCaml
 compilers that can directly deal with packages.")
 (license license:x11)))
 
+(define-public ocaml4.01-findlib
+  (package
+(inherit ocaml-findlib)
+(name "ocaml4.01-findlib")
+(native-inputs
+ `(("m4" ,m4)
+   ("ocaml" ,ocaml-4.01)
+
 ;; note that some tests may hang for no obvious reason.
 (define-public ocaml-ounit
   (package
-- 
2.11.0


>From b236357c4dedfaa77fddcb2fdec3d7203ec72764 Mon Sep 17 00:00:00 2001
From: Ben Woodcroft 
Date: Mon, 2 Jan 2017 22:23:34 +1000
Subject: [PATCH 03/15] build-system: Add package-with-ocaml4.01.

* guix/build-system/ocaml.scm (default-ocaml4.01, default-ocaml4.01-findlib,
package-with-explicit-ocaml, package-with-ocaml4.01,
strip-ocaml4.01-variant): New variables.
---
 guix/build-system/ocaml.scm | 92 -
 1 file changed, 91 insertions(+), 1 deletion(-)

diff --git a/guix/build-system/ocaml.scm b/guix/build-system/ocaml.scm
index f4f57b5ad..7fba1c261 100644
--- a/guix/build-system/ocaml.scm
+++ b/guix/build-system/ocaml.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016, 2017 Julien Lepiller 
+;;; Copyright © 2017 Ben Woodcroft 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -15,7 +16,6 @@
 ;;;
 ;;; You should have received a copy of the GNU General Public License
 ;;; along with GNU Guix.  If not, see .
-
 (define-module (guix build-system ocaml)
   #:use-module (guix store)
   #:use-module (guix utils)
@@ -25,7 +25,10 @@
   #:use-module (guix build-system gnu)
   #:use-module (guix packages)
   #:use-module (ice-9 match)
+  #:use-module (srfi srfi-1)
   #:export (%ocaml-build-system-modules
+package-with-ocaml4.01
+strip-ocaml4.01-variant
 ocaml-build
 ocaml-build-system))
 
@@ -71,6 +74,93 @@
   (let ((module (resolve-i

Re: Packaging leiningen (feedback desired)

[Danny Milosavljevic]

Hmmm... works for me with:

$ java -cp "${HOME}/.guix-profile/share/java/clojure-1.8.0.jar" clojure.main

(Note: java -> 
/gnu/store/4lnjmsr4szhqyixy238xjl83k8h5f0ck-icedtea-3.2.0/bin/java)

Also works within guix environment --ad-hoc clojure.