Re: [PATCH] gnu: r: Update to 3.3.2

[Ben Woodcroft]

Hi Raoul, good to see you here.


On 17/12/16 03:16, Ra wrote:

* gnu/packages/statistics.scm (r): Update to 3.3.2.


I successfully built R and all of its 243 dependencies on x86_64, and 
except for the previously failing shogun, all built successfully. So I 
think it is OK for master.


Unless anyone objects, I'll push it to master tomorrow.


Thanks for the patch.

ben

Re: gnu: Add syncthing.

[Leo Famulari]

On Fri, Dec 16, 2016 at 01:48:57PM +0100, Petter wrote:
> On 2016-12-16 02:52, Leo Famulari wrote:
> > On Thu, Dec 15, 2016 at 10:06:59PM +0100, Petter wrote:
> > > I've prefixed most of the packages with "golang-" now. However,
> > > there are
> > > some
> > > packages already starting with "golang-", f.ex.
> > > "golang-org-x-text-unicode-norm",
> > > and I left those alone. It's inconsistent, but I felt this was
> > > preferable to
> > > names like "golang-golang-org-x-text-unicode-norm". What do you think?
> > 
> > That's the right way. It fits the package naming guidelines:
> > 
> > https://www.gnu.org/software/guix/manual/html_node/Package-Naming.html
> 
> I'm able to interpret your answer both ways, should I make it
> "golang-golang-org-x-text-unicode-norm"?

I'm sorry to be unclear :)

I meant to say that the package should be called 
"golang-org-x-text-unicode-norm".

This matches what we do for Python packages:

If a project already contains the word python, we drop this; for
instance, the module python-dateutil is packaged under the names
python-dateutil and python2-dateutil. If the project name starts with py
(e.g. pytz), we keep it and prefix it as described above. 

https://www.gnu.org/software/guix/manual/html_node/Python-Modules.html

> > > Finally, there's a telemetry configuration in Syncthing. It is opt-in;
> > > but it will ask the user after a few hours if they want to join. The
> > > plan is to disable the question, however I suspect I've messed up the
> > > build system in that area, so this takes some more looking in to.
> > 
> > Personally, I'm fine with the upstream "opt-in" nag warning. It only
> > shows up when you open the Syncthing web interface; it's not an
> > intrusive desktop "notification". Once the user has said "yes" or "no",
> > it doesn't appear again until Syncthing makes a change to what
> > information they collect.
> > 
> > But, if people think our package should never ask, I don't mind if we
> > disable the request, as long as we share our changes with the Syncthing
> > project and they don't notice anything broken.
> 
> I'll make an attempt at this while the jury is out, primarily to
> retrieve the ability to edit files. (Either I broke it, or I need to
> learn how to use (snippet).

I applied the following diff to my package, and it made Syncthing
generate new configuration files with telemetry disabled. However, this
requires some of the tests to be adjusted. This caveat makes me wonder
if it's the right place to make the change, although I didn't find
another place with my limited Go knowledge.

diff --git a/gnu/packages/syncthing.scm b/gnu/packages/syncthing.scm
index 0ef38fcae..c67e85039 100644
--- a/gnu/packages/syncthing.scm
+++ b/gnu/packages/syncthing.scm
@@ -61,6 +61,13 @@
  (setenv "GOBIN" (assoc-ref outputs "out"))
  #t))
 
+ (add-after 'unpack 'disable-telemetry
+   (lambda _
+ (with-directory-excursion "src/github.com/syncthing/syncthing"
+   (substitute* "lib/config/optionsconfiguration.go"
+ (("json:\\\"urAccepted\\\"")
+   "json:\"urAccepted\" default:\"-1\"")
+
  (add-before 'build 'increase-test-timeout
(lambda _
  (substitute* "src/github.com/syncthing/syncthing/build.go"

> Yes! Help please. The meta-data part is tricky and time consuming, I'd
> rather spend my Guix time on the build system than descriptions
> etc. Synopsis and descriptions are just stuff i found on their
> home-page.

Okay, I'll work on this and put it on a Git branch somewhere.

> > Don't forget the revision counter :)
> 
> Oh, I didn't see the need for it, with version being:
> "20160522.452c976".
> 
> Should version really be: "20160522-1.452c976"? I don't see revision
> here contributing any value.

[...]

> > > +(define-public golang-github-com-cznic-bufs
> > > +  (let ((commit "3dcccbd7064a1689f9c093a988ea11ac00e21f51"))
> > > +(package
> > > +  (name "golang-github-com-cznic-bufs")
> > > +  (version (string-append "20160818." (string-take commit 7)))
> > 
> > Is this string '20160818' the date of the commit? If the package has no
> > releases, we use '0.0.0' in place of the version.
> 
> Yes. I figure this is best because some later project we'll package
> may be pinned to an earlier commit of a library, and then what?
> Incrementing the revision number would suggest this was of newer date,
> when it's not, and make the older commit appear as the newest version
> of the two to Guix.

We didn't really make a decision in the previous discussion:

https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00422.html

If Go packages have to use specific commits of their dependencies, then
we'll need to specify that version each time we use the package.

If we decide to use the date anyways, remember that commit timestamps
tend not to be chronologically ordered. The "push" timestamp would be
more meaningful.

I don't know the best 

Re: [PATCH] gnu: tor: Recommend torsocks.

[Hartmut Goebel]

Am 15.12.2016 um 11:37 schrieb ng0:
> -applications based on the TCP protocol.")
> +applications based on the TCP protocol.
> +To @code{torify} applications (to take measures to ensure that an 
> application,
> +which has not been designed for use with Tor such as ssh, will use only Tor 
> for

Even if his is already pushed: An empty line for making the new text
another paragraph would be fine.

-- 
Regards
Hartmut Goebel

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

Re: 01/01: gnu: python-pyopenssl: Disable tests.

[Marius Bakke]

Leo Famulari  writes:

> On Fri, Dec 16, 2016 at 02:21:47PM +0100, Marius Bakke wrote:
>> Leo Famulari  writes:
>> > On Wed, Dec 14, 2016 at 05:38:04PM +, Marius Bakke wrote:
>> >> +(arguments
>> >> + ;; FIXME: Some tests fail with "NameError: name 'long' is not 
>> >> defined".
>> >> + '(#:tests? #f))
>> >
>> > Do you think this indicates a real problem? Or is the issue limited to
>> > the tests?
>> 
>> I dug a bit further into this, and the problem is likely that PYTHONPATH
>> is incomplete at test time. Moving 'check after 'install and adding a
>> proper PYTHONPATH seems to work, but now I ran into a test needing
>> network access.
>> 
>> https://github.com/pyca/pyopenssl/blob/16.2.0/tests/test_ssl.py#L1186
>> 
>> I'll prepare a patch to remove that test entirely, unless someone knows
>> a clever way to check for network access and conditionally skip it
>> (which I'm sure upstream would be happy to accept).
>
> I think it's fine to simply skip or remove that test.

Way ahead of you: 7c6bf660d8a455090f4c140c5b2849f1b58f2fe3 :-)


signature.asc
Description: PGP signature

Re: 01/01: gnu: python-pyopenssl: Disable tests.

[Leo Famulari]

On Fri, Dec 16, 2016 at 02:21:47PM +0100, Marius Bakke wrote:
> Leo Famulari  writes:
> > On Wed, Dec 14, 2016 at 05:38:04PM +, Marius Bakke wrote:
> >> +(arguments
> >> + ;; FIXME: Some tests fail with "NameError: name 'long' is not 
> >> defined".
> >> + '(#:tests? #f))
> >
> > Do you think this indicates a real problem? Or is the issue limited to
> > the tests?
> 
> I dug a bit further into this, and the problem is likely that PYTHONPATH
> is incomplete at test time. Moving 'check after 'install and adding a
> proper PYTHONPATH seems to work, but now I ran into a test needing
> network access.
> 
> https://github.com/pyca/pyopenssl/blob/16.2.0/tests/test_ssl.py#L1186
> 
> I'll prepare a patch to remove that test entirely, unless someone knows
> a clever way to check for network access and conditionally skip it
> (which I'm sure upstream would be happy to accept).

I think it's fine to simply skip or remove that test.

Thanks!


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add python-xopen.

[Leo Famulari]

On Thu, Dec 15, 2016 at 11:02:29AM +0100, Tobias Geerinckx-Rice wrote:
> Marius,
> 
> On 15/12/16 10:20, Marius Bakke wrote:
> > Why not use 'pypi-uri' here? Otherwise LGTM.
> 
> What would that give us?

From what I can tell, GitHub automatically generates snapshot tarballs
of Git tags. These tarballs are usually not real "release" tarballs that
have been prepared by the upstream maintainers. Sometimes this isn't the
case, but it seems to be for these "untitled" v$version.tar.gz tarballs.

We have tools to automatically update packages fetched from PyPi.

And using pypi-uri removes another URL that we need to maintain.

Is there a reason not to use PyPi?


signature.asc
Description: PGP signature

Chicken security bugs [was Re: [pe...@more-magic.net: Irregex packages should be updated to 0.9.6]]

[Leo Famulari]

On Fri, Dec 16, 2016 at 02:33:19PM -0500, Leo Famulari wrote:
> We fixed this bug in our guile-irregex package in commit fb73f07a0fe,
> but our chez-irregex and chicken packages are still vulnerable.

Also note that (I believe) our chicken package is vulnerable to
CVE-2016-{6830,6831}:

http://lists.nongnu.org/archive/html/chicken-announce/2016-08/msg2.html


signature.asc
Description: PGP signature

[pe...@more-magic.net: Irregex packages should be updated to 0.9.6]

[Leo Famulari]

With Peter's permission, I'm forwarding this message from guix-security
to guix-devel.

We fixed this bug in our guile-irregex package in commit fb73f07a0fe,
but our chez-irregex and chicken packages are still vulnerable.

Note the updated discussion on the chez-irregex bug tracker:

https://github.com/fedeinthemix/chez-irregex/issues/1

- Forwarded message from Peter Bex  -

Date: Thu, 15 Dec 2016 20:40:00 +0100
From: Peter Bex 
To: guix-secur...@gnu.org
Subject: Irregex packages should be updated to 0.9.6
User-Agent: Mutt/1.5.23 (2014-03-12)

Hello there,

I'm not a Guix user, but I noticed that Guix has several repackaged
versions of the "irregex" portable regular expression engine for Scheme.
I'm a co-maintainer of the upstream package and I'd like to point out
a vulnerability we've found in it, CVE-2016-9954.

See the announcement at
http://www.openwall.com/lists/oss-security/2016/12/14/18
and the CHICKEN Scheme announcement at
http://lists.gnu.org/archive/html/chicken-announce/2016-12/msg0.html
(currently no released version has a fix for this issue)

The specific Irregex packages in question are:

- chicken.  See above.  It will be fixed in 4.12, once it is released.
- chez-irregex.  I reported the issue for this port as
   https://github.com/fedeinthemix/chez-irregex/issues/1
- guile-irregex.  I couldn't find a repository for this package, so
   I'm assuming this is a direct packaging of the portable upstream code
   from irregex itself.  The tarball published on the author's site has
   now also been updated to 0.9.6.

Especially the guile-irregex package could be an important one if Guix
itself makes use of irregex for processing user-provided regexes,
because it can eat up all available memory if left unrestricted.

Cheers,
Peter Bex



- End forwarded message -


signature.asc
Description: PGP signature

Re: [PATCH 6/6] gnu: Add grub-efi.

[Marius Bakke]

Ludovic Courtès  writes:

> Hi Marius,
>
> Marius Bakke  skribis:
>
>> Ludovic Courtès  writes:
>>
>> From 940c03c7dcddec019e27f6eb1470aeab4db57799 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke 
>> Date: Thu, 20 Oct 2016 17:26:52 +0100
>> Subject: [PATCH] gnu: Add grub-efi.
>>
>> * gnu/packages/grub.scm (grub-efi): New variable.
>
> [...]
>
>> +(name "grub-efi")
>> +(synopsis (string-append (package-synopsis grub) " (UEFI version)"))
>
> Please use a literal string for ‘synopsis’; use of ‘string-append’ like
> this prevents i18n.
>
>> + `(#:tests? #f ; FIXME: 40 failures, 24 skipped, 17 passed.
>
> It would be good to investigate, especially if the tests pass in the
> ‘grub’ package.
>
> Also, what’s the rationale for making ‘grub-efi’ separate instead of
> incorporating the changes in ‘grub’ proper?  Are there issues around the
> portability of ‘efibootmgr’, or an increased closure size?

 This is a good point. The only difference with "--with-platform=efi" is
 that another directory is created in place of the i386-pc directory. It
 is perfectly possible to build multiple platforms and copying the
 platform-specific stuff to $out/lib -- grub will pick the correct
 platform at runtime. This is what the Gentoo ebuild does.
>>>
>>> Are you saying that a GRUB compiled with UEFI support will no longer
>>> work out-of-the-box on non-UEFI machines, unless platform-specific stuff
>>> is moved like you suggest?
>>
>> Ha, no, it was just a long-winded and intoxicated way of saying what you
>> proposed should work fine. :)
>
> It turns out I have an immediate need ;-), so I pushed this as commit
> 3eee16130d858ae96510ec1c7d38d31290de2699.  Let me know if that doesn’t
> seem right!

I think you need to compile with '--with-platform=efi' as well. Check
/gnu/store/...grub-.../lib/grub. I still use a custom 'grub-efi'
expression (attached, needs adaption to 3eee16). Otherwise grub won't
have the required install files, even if it could detect the platform.

Relatedly, I think the way to build a 'multi-grub' is to have one
expression for each supported grub platform, and then consolidate
out/lib/grub from each.

> Now there are things I didn’t quite get.  Apparently you’re supposed to
> have a /boot/efi as a vfat partition, and ‘grub-install’ is supposed to
> detect it and install the EFI stuff, or so I thought (info "(grub)
> Installing GRUB using grub-install").
>
> However, ‘grub-install’ still seems to be installing for “i386-pc”
> instead of EFI.
>
> What am I missing?

IIRC grub-install will detect and install for the running mode (pc, efi,
etc). So in a classic chicken-and-egg situation, you need to be booted
with UEFI mode for grub to select the correct installation platform!

I worked around this by installing grub from a UEFI live CD, copy and
adapt the grub.cfg from an existing (BIOS) GuixSD installation, then
coerce the GuixSD system to use EFI from that point..



signature.asc
Description: PGP signature
>From 1ca87a51f55f0b05f89eed707c1485b94f3d7d16 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Thu, 20 Oct 2016 17:26:52 +0100
Subject: [PATCH] gnu: Add grub-efi.

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

diff --git a/gnu/packages/grub.scm b/gnu/packages/grub.scm
index ef7395e95..1cb835695 100644
--- a/gnu/packages/grub.scm
+++ b/gnu/packages/grub.scm
@@ -164,3 +164,26 @@ on the same computer; upon booting the computer, the user is presented with a
 menu to select one of the installed operating systems.")
 (license gpl3+)
 (properties '((cpe-name . "grub2")
+
+(define-public grub-efi
+  (package
+(inherit grub)
+(name "grub-efi")
+(synopsis (string-append (package-synopsis grub) " (UEFI version)"))
+(inputs
+ `(("efibootmgr" ,efibootmgr)
+   ,@(package-inputs grub)))
+(arguments
+ `(#:tests? #f ; FIXME: 40 failures, 24 skipped, 17 passed.
+   ,@(substitute-keyword-arguments (package-arguments grub)
+   ((#:configure-flags flags) `(cons* "--with-platform=efi"
+  ,flags))
+   ((#:phases phases)
+`(modify-phases ,phases
+   (add-after 'patch-stuff 'use-absolute-efibootmgr-path
+ (lambda* (#:key inputs #:allow-other-keys)
+   (substitute* "grub-core/osdep/unix/platform.c"
+ (("efibootmgr")
+  (string-append (assoc-ref inputs "efibootmgr")
+ "/sbin/efibootmgr")))
+   #t)
-- 
2.11.0

[PATCH] gnu: r: Update to 3.3.2

[Ra]

* gnu/packages/statistics.scm (r): Update to 3.3.2.
---
  gnu/packages/statistics.scm | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index 6cdd694..72c5430 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -101,7 +101,7 @@ be output in text, PostScript, PDF or HTML.")
  (define-public r
(package
  (name "r")
-(version "3.3.1")
+(version "3.3.2")
  (source (origin
(method url-fetch)
(uri (string-append "mirror://cran/src/base/R-"
@@ -109,7 +109,7 @@ be output in text, PostScript, PDF or HTML.")
version ".tar.gz"))
(sha256
 (base32
-"1qm9znh8akfy9fkzzi6f1vz2w1dd0chsr6qn7kw80lqzhgjrmi9x"
+"0k2i9qdd83g09fcpls2198q4ykxkii5skczb514gnx7mx4hsv56j"
  (build-system gnu-build-system)
  (arguments
   `(#:make-flags
--
1.9.1

Re: [PATCH 6/6] gnu: Add grub-efi.

[Danny Milosavljevic]

Did you add (grub grub-efi) in your  in your system config? 
Or another package with --with-platform=efi ?

Re: [PATCH 6/6] gnu: Add grub-efi.

[Ludovic Courtès]

Hi Marius,

Marius Bakke  skribis:

> Ludovic Courtès  writes:
>
> From 940c03c7dcddec019e27f6eb1470aeab4db57799 Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Thu, 20 Oct 2016 17:26:52 +0100
> Subject: [PATCH] gnu: Add grub-efi.
>
> * gnu/packages/grub.scm (grub-efi): New variable.

 [...]

> +(name "grub-efi")
> +(synopsis (string-append (package-synopsis grub) " (UEFI version)"))

 Please use a literal string for ‘synopsis’; use of ‘string-append’ like
 this prevents i18n.

> + `(#:tests? #f ; FIXME: 40 failures, 24 skipped, 17 passed.

 It would be good to investigate, especially if the tests pass in the
 ‘grub’ package.

 Also, what’s the rationale for making ‘grub-efi’ separate instead of
 incorporating the changes in ‘grub’ proper?  Are there issues around the
 portability of ‘efibootmgr’, or an increased closure size?
>>>
>>> This is a good point. The only difference with "--with-platform=efi" is
>>> that another directory is created in place of the i386-pc directory. It
>>> is perfectly possible to build multiple platforms and copying the
>>> platform-specific stuff to $out/lib -- grub will pick the correct
>>> platform at runtime. This is what the Gentoo ebuild does.
>>
>> Are you saying that a GRUB compiled with UEFI support will no longer
>> work out-of-the-box on non-UEFI machines, unless platform-specific stuff
>> is moved like you suggest?
>
> Ha, no, it was just a long-winded and intoxicated way of saying what you
> proposed should work fine. :)

It turns out I have an immediate need ;-), so I pushed this as commit
3eee16130d858ae96510ec1c7d38d31290de2699.  Let me know if that doesn’t
seem right!

Now there are things I didn’t quite get.  Apparently you’re supposed to
have a /boot/efi as a vfat partition, and ‘grub-install’ is supposed to
detect it and install the EFI stuff, or so I thought (info "(grub)
Installing GRUB using grub-install").

However, ‘grub-install’ still seems to be installing for “i386-pc”
instead of EFI.

What am I missing?

Thanks!

Ludo’.

Re: ‘guix refresh’ broken on master?

[Ludovic Courtès]

Hello!

Tobias Geerinckx-Rice  skribis:

> Commit 3e0c036 (‘import: Add importer for rust crates’) reliably breaks
> all calls to ‘guix refresh’ for me:

This is because your installation lacks Guile-JSON, probably.  Fixed in
commit 99ec0cb397453802788e7095724dcfbca3ca1723.

The ‘list-updaters’ macro in (guix scripts refresh) ensures that only
updaters that are actually available at run time are visible.

Thanks!

Ludo’.

Re: Graphical GuixSD Installer

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> John Darrington  writes:
>
>> There is a new branch called "wip-installer" providing a graphical
>> installer for GuixSD.  A screenshot of it in action is attached.
>>
>> We want GuixSD to be accessible to as many people as possible,
>> including people who may not (yet) be comfortable using bash and/or
>> guile.
>
> Amazing work! I really appreciate that this initiative lowers the
> technical knowledge required for having a GuixSD system.
>
>> It uses guile-ncurses so that will have to be installed and be
>> in your load path.
>
> Would it make sense to add a check for it at configure time and
> conditionally compile and install the modules only if 'guile-ncurses' is
> found, like what is done for 'guile-json'?

I agree (though that can be done further down the road).

Ludo’.

Re: [PATCH] gnu: Add Greek Aspell dictionary

[Ludovic Courtès]

Theodoros Foradis  skribis:

> * gnu/packages/aspell.scm (aspell-dict-el): New variable.

Applied, thanks!

Ludo'.

Re: ‘guix refresh’ broken on master?

[David Craven]

> This is because your installation lacks Guile-JSON, probably.  Fixed in
> commit 99ec0cb397453802788e7095724dcfbca3ca1723.

Ah that was easier than expected.

Re: Emacs-Guix released outside from Guix

[Ludovic Courtès]

Howdy!

Ricardo Wurmus  skribis:

> If you go through with the move please double check that the Guix
> sources are in a state that’s ready for release.  It would be terrible
> to have a botched release.  (Frankly, I’m a little uncomfortable about
> such a big change right before the release, but maybe I’m just being
> nervous about doing the release myself this time…)

It’s fine to postpone the change until after the release if we’re afraid
of last-minute breakage (which is not unlikely).

Ludo’.

Re: Graphical GuixSD Installer

[Luis Felipe López Acevedo]

On 2016-12-16 06:08, John Darrington wrote:

There is a new branch called "wip-installer" providing a graphical
installer for GuixSD.  A screenshot of it in action is attached.

We want GuixSD to be accessible to as many people as possible,
including people who may not (yet) be comfortable using bash and/or
guile.

Testers and hackers are wanted!

To try out the installer run:

 guix system installer

It uses guile-ncurses so that will have to be installed and be
in your load path.


Great! I sure want to test this. Thanks, John :)


--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.org/

Re: [PATCH] gnu: Add python-xopen.

[Marius Bakke]

Tobias Geerinckx-Rice  writes:

> Marius,
>
> On 15/12/16 10:20, Marius Bakke wrote:
>> Why not use 'pypi-uri' here? Otherwise LGTM.
>
> What would that give us?

Good question. Pypi archives are sometimes smaller than the raw sources
or otherwise "prepared", but I guess no inherent benefits.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: tor: Recommend torsocks.

[Kei Kebreau]

Kei Kebreau  writes:

> ng0  writes:
>
>> Hi, I see this received no feedback so far. Can someone review
>> this? Or is it already on someones list?
>>
>> Thanks.
>>
>> ng0  writes:
>>
>>> * gnu/packages/tor.scm (tor)[description]: Recommend torsocks.
>>> ---
>>>  gnu/packages/tor.scm | 9 +
>>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/gnu/packages/tor.scm b/gnu/packages/tor.scm
>>> index e6fbf6e..f0970ef 100644
>>> --- a/gnu/packages/tor.scm
>>> +++ b/gnu/packages/tor.scm
>>> @@ -54,9 +54,6 @@
>>>   `(("zlib" ,zlib)
>>> ("openssl" ,openssl)
>>> ("libevent" ,libevent)))
>>> -
>>> -;; TODO: Recommend `torsocks' since `torify' needs it.
>>> -
>>>  (home-page "https://www.torproject.org/;)
>>>  (synopsis "Anonymous network router to improve privacy on the 
>>> Internet")
>>>  (description
>>> @@ -66,7 +63,11 @@ somebody watching your Internet connection from learning 
>>> what sites you
>>>  visit, and it prevents the sites you visit from learning your physical
>>>  location.  Tor works with many of your existing applications, including
>>>  web browsers, instant messaging clients, remote login, and other
>>> -applications based on the TCP protocol.")
>>> +applications based on the TCP protocol.
>>> +To @code{torify} applications (to take measures to ensure that an 
>>> application,
>>> +which has not been designed for use with Tor such as ssh, will use only 
>>> Tor for
>>> +internet connectivity, and also ensures that there are no leaks from DNS, 
>>> UDP or
>>> +the application layer) you need to install @code{torsocks}.")
>>>  (license bsd-3)))
>>>  
>>>  (define-public torsocks
>>> -- 
>>> 2.10.1
>>>
>>>
>
> LGTM. :)

Seeing no protest, this was pushed as fc9286d03a79837d70d8f209521d73f6b18d171b.


signature.asc
Description: PGP signature

Re: Graphical GuixSD Installer

[Christopher Allan Webber]

John Darrington writes:

> There is a new branch called "wip-installer" providing a graphical
> installer for GuixSD.  A screenshot of it in action is attached.
>
> We want GuixSD to be accessible to as many people as possible,
> including people who may not (yet) be comfortable using bash and/or
> guile.
>
> Testers and hackers are wanted!
>
> To try out the installer run:
>
>  guix system installer
>
> It uses guile-ncurses so that will have to be installed and be
> in your load path.

Wowee!  I'm so excited this is moving forward!

Re: [PATCH] gnu: kdbusaddons: Embed path to kdeinit5, avoid dependency cycles.

[Thomas Danckaert]

From: l...@gnu.org (Ludovic Courtès)
Subject: Re: [PATCH] gnu: kdbusaddons: Embed path to kdeinit5, avoid 
dependency cycles.

Date: Thu, 15 Dec 2016 17:06:19 +0100


Other options that come to mind: (1) make ‘QT_PLUGIN_PATH’ and
‘QML2_IMPORT_PATH’ search paths of ‘kinit’; or (2) add a “profile 
hook”
that creates a file containing the search path, and patch kinit to 
honor

that file somehow.

Option 1 sounds better, but ‘QT_PLUGIN_PATH’ really belongs to Qt, 
not

to kinit.


I think adding QT_PLUGIN_PATH to kinit (and a number of other KDE 
packages) could be justified. KDE applications heavily rely on 
QT_PLUGIN_PATH (and use a different path than the default path used 
by Qt: ${PREFIX}/lib/plugins instead of ${PREFIX}/plugins).  See for 
example the section on environment variables at 
https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source


However, I'm not sure it's enough: as far as I understand, 
search-paths will only work for packages directly installed in a 
user's profile, but KDE applications often need plugins provided by 
their dependencies (e.g. for kdevelop, plugins from kdevplatform and 
kinit must be found on the QT_PLUGIN_PATH, but a user who installs 
kdevelop shouldn't be forced to install kinit and kdevplatform in 
their profile?). (Perhaps I misunderstand how search-paths works)


So, provided option (2) can somehow find the paths of dependencies as 
well, maybe that's better? (Are there examples of such a “profile 
hook” somewhere?  I didn't find anything in the manual).


+;; This version of kdbusaddons does not use kinit as an input, 
and is used to
+;; build kinit-bootstrap, as well as bootstrap versions of all 
kinit

+;; dependencies which also rely on kdbusaddons.
+(define kdbusaddons-bootstrap
+  (package
+(inherit kdbusaddons)
+(source (origin
+  (inherit (package-source kdbusaddons))
+  (patches '(


Since ‘kdbusaddons’ doesn’t have any patches, you can omit this 
‘source’

field.


This commit adds a patch to kdbusaddons (the one that adds the kinit 
store directory), so I think does become necessary?



[...]

Isn’t it enough to do:

  (define kinit-bootstrap
((package-input-rewriting `((,kdbusaddons . 
,kdbusaddons-bootstrap)))

 kinit))

?  Remember that ‘package-input-rewriting’ replaces inputs 
recursively.


Yes, ..., yes it is :-) I had this nagging feeling that tracking the
dependency chain like that could be automated, and therefore probably
already _had_ been automated in guix :-) I didn't pay attention to the
word “recursive”... would have saved me a lot of work (you should have
seen the first versions of this patch O_o).

You can check with ‘guix graph -e '(@ (gnu packages kde) 
kdeinit-bootstrap)'’

whether you’re really getting what you want.


tangentially: this seems to work only if I make the kinit-bootstrap 
package a public variable?


diff --git a/gnu/packages/patches/kdbusaddons-kinit-path.patch 
b/gnu/packages/patches/kdbusaddons-kinit-path.patch

new file mode 100644
index 000..97c7319
--- /dev/null
+++ b/gnu/packages/patches/kdbusaddons-kinit-path.patch
@@ -0,0 +1,15 @@
+Add placeholder for kinit's store path.


s/path/file name/ please.  :-)

In GNU “path” traditionally means “search path.”


I'm happy to comply, but note that the info manual does talk about 
store paths.  Should this be changed?


  https://www.gnu.org/software/guix/manual/html_node/The-Store.html

(Also, I chose “store directory” instead of “store file name”)

Thomas
>From e6c66e9d1daafee8907fa03db2f4c11104aab2b5 Mon Sep 17 00:00:00 2001
From: Thomas Danckaert 
Date: Tue, 6 Dec 2016 14:55:39 +0100
Subject: [PATCH] gnu: kdbusaddons: Embed kinit store dir, avoid dependency
 cycles.

kdbusaddons needs to know the location of the kdeinit5 executable,
provided by kinit. kinit depends on kdbusaddons, so we add bootstrap
versions of all packages in the dependency chain from kinit to
kdbusaddons to avoid cyclic dependencies.

* gnu/packages/kde-frameworks.scm (kinit-bootstrap,
  kdbusaddons-bootstrap): New variables.
  (kdbusaddons)[inputs]: Add kinit-bootstrap.
  [source,arguments]: Add patch and substitution to embed
  kinit-bootstrap's store directory in the code.
* gnu/packages/patches/kdbusaddons-kinit-file-name.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
---
 gnu/local.mk   |  1 +
 gnu/packages/kde-frameworks.scm| 36 --
 .../patches/kdbusaddons-kinit-file-name.patch  | 15 +
 3 files changed, 49 insertions(+), 3 deletions(-)
 create mode 100644 gnu/packages/patches/kdbusaddons-kinit-file-name.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index c6cb55b..f7b661c 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -639,6 +639,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/isl-0.11.1-aarch64-support.patch	\
   %D%/packages/patches/jbig2dec-ignore-testtest.patch		\
   

Re: Shutdown of googlecode end of the year - we have affected packages!

[ng0]

Hartmut Goebel  writes:

> Am 14.12.2016 um 22:32 schrieb Tobias Geerinckx-Rice:
>> python.scm: (home-page "https://code.google.com/p/py-bcrypt;)
>
> I assume, this package can be removed at all. It is only used as input
> by python-passlib, but python-passlib should not require
> "python-py-bcrypt", but "pyth0n-bcrypt". See
> 

No, please don't remove it.  I need this package for pagure,
which is a git based scm I'm currently finishing.

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

-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

Re: 01/01: gnu: python-pyopenssl: Disable tests.

[Marius Bakke]

Leo Famulari  writes:

> On Wed, Dec 14, 2016 at 05:38:04PM +, Marius Bakke wrote:
>> mbakke pushed a commit to branch python-tests
>> in repository guix.
>> 
>> commit 30e0229a1713e77dc0397dfb4ee6af4ac6a00443
>> Author: Marius Bakke 
>> Date:   Wed Dec 14 18:34:48 2016 +0100
>> 
>> gnu: python-pyopenssl: Disable tests.
>> 
>> * gnu/packages/python.scm (python-pyopenssl, 
>> python2-pyopenssl)[arguments]:
>> Set #:tests? #f.
>> [native-inputs]: Add python-pytest.
>> ---
>>  gnu/packages/python.scm |5 +
>>  1 file changed, 5 insertions(+)
>> 
>> diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
>> index cd6ed1c..ebe0194 100644
>> --- a/gnu/packages/python.scm
>> +++ b/gnu/packages/python.scm
>> @@ -6585,11 +6585,16 @@ message digests and key derivation functions.")
>>  (base32
>>   "0vji4yrfshs15xpczbhzhasnjrwcarsqg87n98ixnyafnyxs6ybp"
>>  (build-system python-build-system)
>> +(arguments
>> + ;; FIXME: Some tests fail with "NameError: name 'long' is not defined".
>> + '(#:tests? #f))
>
> Do you think this indicates a real problem? Or is the issue limited to
> the tests?

I dug a bit further into this, and the problem is likely that PYTHONPATH
is incomplete at test time. Moving 'check after 'install and adding a
proper PYTHONPATH seems to work, but now I ran into a test needing
network access.

https://github.com/pyca/pyopenssl/blob/16.2.0/tests/test_ssl.py#L1186

I'll prepare a patch to remove that test entirely, unless someone knows
a clever way to check for network access and conditionally skip it
(which I'm sure upstream would be happy to accept).


signature.asc
Description: PGP signature

Re: Graphical GuixSD Installer

[David Craven]

Well anyway, I've stated my opinion. I'll withdraw from further
discussion on this topic. If someone has a solution to the guix
refresh problem from
http://lists.gnu.org/archive/html/guix-devel/2016-12/msg00638.html,
let me know.

Re: gnu: Add syncthing.

[Petter]

On 2016-12-16 02:52, Leo Famulari wrote:

On Thu, Dec 15, 2016 at 10:06:59PM +0100, Petter wrote:

Hi again,

I've prefixed most of the packages with "golang-" now. However, there 
are

some
packages already starting with "golang-", f.ex.
"golang-org-x-text-unicode-norm",
and I left those alone. It's inconsistent, but I felt this was 
preferable to

names like "golang-golang-org-x-text-unicode-norm". What do you think?


That's the right way. It fits the package naming guidelines:

https://www.gnu.org/software/guix/manual/html_node/Package-Naming.html


I'm able to interpret your answer both ways, should I make it
"golang-golang-org-x-text-unicode-norm"?


Finally, there's a telemetry configuration in Syncthing. It is opt-in;
but it will ask the user after a few hours if they want to join. The
plan is to disable the question, however I suspect I've messed up the
build system in that area, so this takes some more looking in to.


Personally, I'm fine with the upstream "opt-in" nag warning. It only
shows up when you open the Syncthing web interface; it's not an
intrusive desktop "notification". Once the user has said "yes" or "no",
it doesn't appear again until Syncthing makes a change to what
information they collect.

But, if people think our package should never ask, I don't mind if we
disable the request, as long as we share our changes with the Syncthing
project and they don't notice anything broken.


I'll make an attempt at this while the jury is out, primarily to
retrieve the ability to edit files. (Either I broke it, or I need to
learn how to use (snippet).


Many of my comments below are about tedious things. Let us know if you
are getting sick of working on these packages, and I will help :) This
includes improving the descriptions.


Yes! Help please. The meta-data part is tricky and time consuming, I'd
rather spend my Guix time on the build system than descriptions
etc. Synopsis and descriptions are just stuff i found on their
home-page.


Date: Thu, 15 Dec 2016 21:42:03 +0100
Subject: [PATCH] gnu: Add Syncthing.

* gnu/packages/syncthing.scm: New file.


Cool!


+(define-public syncthing



+(source (origin
+  (method git-fetch)
+  (uri (git-reference
+(url "https://github.com/syncthing/syncthing/;)
+(commit (string-append "v" version
+  (file-name (string-append name "-" version 
"-checkout"))


We should use the Syncthing release tarball:

https://github.com/syncthing/syncthing/releases/download/v0.14.14/syncthing-source-v0.14.14.tar.gz


Totally agree! However, tarballs are currently unsupported... due to,
hm, let's say "because very good reasons noone can be blamed for,
particularly and especially not me".

Ok, I messed up the build system :P Removed too much code
apparently. I'm working on getting this back.


+(arguments
+ `(#:import-path "github.com/syncthing/syncthing"


What do you think about having the go-build-system try to automatically
generate the import-path based on the source URL, with the option for
the packager to set it manually, as shown here?

For many of the packages in this patch (which will eventually be split
into one package per patch ;) ), that auto-generated import-path
could be correct.

I think that an (arguments) field indicates that the package's build
scripts have deviated from the standard. If a Guix build system 
requires

all of its packages to do something in (arguments), the build system
should be extended :)


This is my goal, and I tried to accomplish this initially, because as
you can see for git checkouts most of the time import-path is url
minus scheme://. But I was unable to retrieve the url in the build
phases. So I did it like this instead, to get something that worked;
also something like #:import-path is required where import-path can't
be derived from the url.

I would need concrete help with this, that is getting the url and
perhaps what (method) was used.


+   #:phases
+   (modify-phases %standard-phases
+ (replace 'delete-files
+   (lambda _
+ (delete-file-recursively 
"src/github.com/syncthing/syncthing/vendor")))

+
+ (replace 'build
+   (lambda* (#:key inputs #:allow-other-keys)
+ (with-directory-excursion 
"src/github.com/syncthing/syncthing"
+   (zero? (system* "go" "run" "build.go" "install" 
"syncthing" "-no-upgrade")

+
+ (replace 'install
+   (lambda _
+ (copy-recursively 
"src/github.com/syncthing/syncthing/bin/"
+   (string-append (assoc-ref %outputs 
"out") "/bin"))

+ (copy-recursively "pkg"
+   (string-append (assoc-ref %outputs 
"out") "/pkg"))

+ (copy-recursively "src"
+   (string-append (assoc-ref %outputs 
"out") "/src")))

+


Does this package need to use custom build and install phases?


Yes. They use their 

Re: Graphical GuixSD Installer

[David Craven]

I assume that the main reason for people not wanting to add
dependencies is because it complicates bootstrapping guix for new
platforms (which I don't understand well enough yet). I don't think
that you can build a gnu system that doesn't rely on ncurses or an
alternative implementation. guile-ncurses (0.7MB) and guile-json
(0.1MB) are hardly large enough to warrant a fuss otherwise :)

Re: Graphical GuixSD Installer

[David Craven]

> Err ... How would they manage to do that before anything has been installed?

guix-install would be a package added to the installation-os
derivation in gnu/system/install.scm, no?

Re: Graphical GuixSD Installer

[David Craven]

> Would it make sense to add a check for it at configure time and
> conditionally compile and install the modules only if 'guile-ncurses' is
> found, like what is done for 'guile-json'?

Doesn't this just complicate things? How about decoupling things
instead? Put the installer in a separate repo and make it a regular
guix package? Or keep it in the same repo and make it a guix package.
Then if someone wants to use guix-install they can say guix package -i
guix-install. I'd suggest the same for guix refresh since people are
against adding a json dependency. We could even go as far as making
each guix command a package. Then we can be a little more galant with
dependencies and if someone only wants to use guix-build and
guix-package they only have to install those.

Graphical GuixSD Installer

[John Darrington]

There is a new branch called "wip-installer" providing a graphical
installer for GuixSD.  A screenshot of it in action is attached.

We want GuixSD to be accessible to as many people as possible,
including people who may not (yet) be comfortable using bash and/or
guile.

Testers and hackers are wanted!

To try out the installer run:

 guix system installer

It uses guile-ncurses so that will have to be installed and be
in your load path.


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



signature.asc
Description: Digital signature

Re: [PATCH 0/2] python-sympy: Update to 1.0.

[Hartmut Goebel]

Am 15.12.2016 um 19:14 schrieb Marius Bakke:
>   gnu: Add python-mpmath.
>   gnu: python-sympy: Update to 1.0.

Both LGTM.

-- 
Regards
Hartmut Goebel

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

Re: Shutdown of googlecode end of the year - we have affected packages!

[Hartmut Goebel]

Am 14.12.2016 um 22:32 schrieb Tobias Geerinckx-Rice:
> python.scm: (home-page "https://code.google.com/p/py-bcrypt;)

I assume, this package can be removed at all. It is only used as input
by python-passlib, but python-passlib should not require
"python-py-bcrypt", but "pyth0n-bcrypt". See


-- 
Regards
Hartmut Goebel

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

Re: gnu: Add Go build system.

[Petter]

On 2016-12-16 03:05, Leo Famulari wrote:

On Sun, Dec 11, 2016 at 01:17:48AM +0100, Petter wrote:

+(define* (build #:key import-path #:allow-other-keys)
+  (system* "go" "install" import-path))
+
+(define* (install #:key inputs outputs #:allow-other-keys)
+  (copy-recursively "bin" (string-append (assoc-ref outputs "out") 
"/bin"))
+  (copy-recursively "pkg" (string-append (assoc-ref outputs "out") 
"/pkg"))
+  (copy-recursively "src" (string-append (assoc-ref outputs "out") 
"/src")))


It looks like `go install` knows "where" to install the files, but
installs them in the wrong place, and then we copy them into place in
the install phase. I think it's inefficient to move the files twice.

Can the build phase use something like `go build`, followed by the
install phase using `go install` to move the files directly to the
package's output directory in /gnu/store?


The differences between `go install` and `go build` here is that `go
install` compiles and moves the result to $GOPATH/bin (unless GOBIN is
set to somewhere else).

`go build` compiles (always from source I believe) and leaves the
resulting binary in current directory.

`go install` compiles and also creates package objects in pkg/ which I
believe is a compiled object that is compiled once and then reused,
unless source is changed. Not sure if timestamps are used to determine
whether source has changed, and how that works on Guix.

Optimizations could be made for sure, I will look at this at
convenience.

On 2016-12-16 05:49, Leo Famulari wrote:

On Sun, Dec 11, 2016 at 01:17:48AM +0100, Petter wrote:

From 4c0597a95ae3cd111ef12d675edf501c559458ba Mon Sep 17 00:00:00 2001
From: Petter 
Date: Sun, 11 Dec 2016 01:10:09 +0100
Subject: [PATCH] gnu: Add Go build system.

* guix/build-system/go.scm: New file
* guix/build/go-build-system.scm: New file.


Another question: does this build system try to run tests? In my own
Syncthing packaging I used `go run build.go test`, but I noticed that
your Syncthing package built with this build system doesn't seem to run
the tests.


No. It only builds/installs at the moment. Tests, docs,
cross-compilation and other things (if there are more things), are not
dealt with at this point.

Note that Syncthing uses their own build program (build.go). This is
atypical. There will be a test phase, and Syncthing will override this
with their way of running tests.

Regarding cross-compilation. Go supports: 386, amd64, amd64p32, arm,
arm64, mips64, mips64le, ppc64, ppc64le and s390x as far as I can
tell. With mips32 being added in February. I have yet to discover how
the build system should deal with cross-compilations. The Go part is
easy, just set the GOARCH environment variable before compiling.
`GOARCH=mips64 go install ...`

Re: ‘guix refresh’ broken on master?

[David Craven]

Ah there does seem to be a problem.

First this hunk is in the wrong patch:

 diff --git a/guix/scripts/refresh.scm b/guix/scripts/refresh.scm
index f8fb3f80c..72f51cbff 100644
--- a/guix/scripts/refresh.scm
+++ b/guix/scripts/refresh.scm
@@ -39,6 +39,7 @@
   %kernel.org-updater))
   #:use-module (guix import elpa)
   #:use-module (guix import cran)
+  #:use-module (guix import crate)
   #:use-module (guix import hackage)
   #:use-module (guix gnupg)
   #:use-module (gnu packages)

It should have gone in the next one called Add updater for rust
crates. The updater depends on guile-json so this means that all of
guix refresh depends on guile-json.

[PATCH] gnu: r: Update to 3.3.2

[Ra]

* gnu/packages/statistics.scm (r): Update to 3.3.2.
---
 gnu/packages/statistics.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index 6cdd694..72c5430 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -101,7 +101,7 @@ be output in text, PostScript, PDF or HTML.")
 (define-public r
   (package
 (name "r")
-(version "3.3.1")
+(version "3.3.2")
 (source (origin
   (method url-fetch)
   (uri (string-append "mirror://cran/src/base/R-"
@@ -109,7 +109,7 @@ be output in text, PostScript, PDF or HTML.")
   version ".tar.gz"))
   (sha256
(base32
-"1qm9znh8akfy9fkzzi6f1vz2w1dd0chsr6qn7kw80lqzhgjrmi9x"
+"0k2i9qdd83g09fcpls2198q4ykxkii5skczb514gnx7mx4hsv56j"
 (build-system gnu-build-system)
 (arguments
  `(#:make-flags
--
1.9.1

[PATCH] doc: Mention "guix pull" during installation.

[Petter]

Hi,

Some new users don't run `guix pull` before installing, and can have a 
less good experience because of this. Proposing a patch to add this to 
the manual.


Thanks,
PetterFrom 2340158e5454cbb3050840821bf0fd1965d2fe79 Mon Sep 17 00:00:00 2001
From: Petter 
Date: Fri, 16 Dec 2016 09:28:32 +0100
Subject: [PATCH] doc: Mention "guix pull" during installation.

* doc/guix.texi (Proceeding with the Installation): Add "guix pull".
---
 doc/guix.texi | 8 
 1 file changed, 8 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 46ed451..cda90ed 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -6863,6 +6863,14 @@ rather than kept in memory.  This is necessary because the first phase of
 the @command{guix system init} command (see below) entails downloads or
 builds to @file{/gnu/store} which, initially, is an in-memory file system.
 
+At this point it is advisable to update the system, especially if the
+installer is more than a few weeks old. Then most, if not all, packages
+will be available as substitutes.
+
+@example
+guix pull
+@end example
+
 Next, you have to edit a file and
 provide the declaration of the operating system to be installed.  To
 that end, the installation system comes with three text editors: GNU nano
-- 
2.10.1