Re: swh-plugins-lv2: New variable [WIP] v2

[Ludovic Courtès]

Mark H Weaver  skribis:

> Ricardo Wurmus  writes:
>
>>> +(define-public swh-plugins-lv2
>>> +  (let ((commit "5098e09e255eaed14e0d40ca5e7e6dfcb782d7ea"))
>>
>> We usually don’t use full commit hashes.  You could probably trim it to
>> the first six characters or so.
>
> I would recommend using at least 10 characters, maybe more.  We should
> use enough characters to ensure that the commit id remains unique for as
> long as this package version remains in use -- keeping in mind that for
> purposes of reproducing old experiments, someone might try to build this
> package+version several years from now.

I sympathize with this.  I would think 10 digits is more than needed,
though: With 6 hex digits, it takes on average 16^6 = 16M commits before
the 6-digit ID is ambiguous, and with 8 hex digits that goes to
4 billion commits (Emacs has around 123,000 commits as an example.)

But anyway, to be super-safe, we could use the full SHA1 in the URL, but
strip it in the ‘version’ field so that it remains readable.

Thoughts?

Thanks,
Ludo’.

Re: swh-plugins-lv2: New variable [WIP] v2

[Ludovic Courtès]

Florian Paul Schmidt  skribis:

> fps@cherry ~/src/guix [env]$ ./pre-inst-env guix lint swh-plugins-lv2
> ;;; note: source file /home/fps/src/guix/gnu/packages/audio.scm
> ;;;   newer than compiled /home/fps/src/guix/gnu/packages/audio.go
> fps@cherry ~/src/guix [env]$
> -11-11-5098e09e255eaed14e0d40ca5e7e6dfcb782d7ea
> [formatting]...me]...ive]...
>
> See how the new prompt is in the middle of the lint output? I suspect
> broken terminfo entries or something (command editing in bash is
> seriously broken as well for commands longer than a line).. If I add a
> trailing whitespace in the package definition I get:

As discussed on IRC yesterday, this appears to be due to careless use of
‘\r’ in (guix scripts lint) to return to the beginning of the line,
which doesn’t actually erase the line (it does erase it in shell-mode,
but that’s probably an exception.)  Leo has ideas on how to fix it.

Thanks,
Ludo’.

Re: GNOME updater

[Efraim Flashner]

On Mon, 07 Dec 2015 23:40:13 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> I was distracted from important stuff and found myself writing a GNOME
> updater, brought to you in commit e80c0f8.
> 
> Useful, and at the same time scary:
> 
> --8<---cut here---start->8---
> $ ./pre-inst-env guix refresh -t gnome 
> gnu/packages/mail.scm:211:13: gmime would be upgraded from 2.6.19 to 2.6.20
> gnu/packages/gtk.scm:388:12: gdk-pixbuf would be upgraded from 2.32.1 to 
> 2.33.1
> gnu/packages/gtk.scm:573:12: gtk+ would be upgraded from 3.18.2 to 3.19.4
> gnu/packages/gtk.scm:482:12: at-spi2-atk would be upgraded from 2.18.1 to 
> 2.19.2
> gnu/packages/gtk.scm:340:12: gtksourceview would be upgraded from 3.18.1 to 
> 3.19.2
> gnu/packages/gtk.scm:826:13: pangomm would be upgraded from 2.38.1 to 2.39.1
> gnu/packages/gtk.scm:437:12: at-spi2-core would be upgraded from 2.18.1 to 
> 2.19.2
> gnu/packages/gtk.scm:875:13: gtkmm would be upgraded from 3.18.0 to 3.19.3
> gnu/packages/gtk.scm:852:13: atkmm would be upgraded from 2.24.1 to 2.24.2
> gnu/packages/gnome.scm:3237:13: gvfs would be upgraded from 1.24.1 to 1.26.2
> gnu/packages/gnome.scm:1302:13: libgnomeprint would be upgraded from 2.8.2 to 
> 2.18.8
> gnu/packages/gnome.scm:2553:13: aisleriot would be upgraded from 3.16.1 to 
> 3.18.2
> gnu/packages/gnome.scm:3538:13: yelp-tools would be upgraded from 3.16.1 to 
> 3.18.0
> gnu/packages/gnome.scm:1922:13: glib-networking would be upgraded from 2.46.1 
> to 2.47.1
> gnu/packages/gnome.scm:1762:13: dconf would be upgraded from 0.22.0 to 0.24.0
> gnu/packages/gnome.scm:1517:13: gnumeric would be upgraded from 1.12.17 to 
> 1.12.24
> gnu/packages/gnome.scm:3978:13: evolution-data-server would be upgraded from 
> 3.18.2 to 3.19.2
> gnu/packages/gnome.scm:1686:13: vte would be upgraded from 0.40.0 to 0.43.0
> gnu/packages/gnome.scm:1460:13: goffice would be upgraded from 0.10.14 to 
> 0.10.24
> gnu/packages/gnome.scm:331:13: gnome-keyring would be upgraded from 3.16.0 to 
> 3.18.3
> gnu/packages/gnome.scm:3890:13: mutter would be upgraded from 3.18.1 to 3.19.2
> gnu/packages/gnome.scm:748:13: glade would be upgraded from 3.8.4 to 3.19.0
> gnu/packages/gnome.scm:1340:13: libgnomeprintui would be upgraded from 2.8.2 
> to 2.18.6
> gnu/packages/gnome.scm:2589:13: devhelp would be upgraded from 3.16.1 to 
> 3.18.1
> gnu/packages/gnome.scm:462:13: gsettings-desktop-schemas would be upgraded 
> from 3.18.0 to 3.19.2
> gnu/packages/gnome.scm:2167:13: gnome-terminal would be upgraded from 3.16.0 
> to 3.19.1
> gnu/packages/gnome.scm:3806:13: gedit would be upgraded from 3.18.1 to 3.19.1
> gnu/packages/gnome.scm:3691:13: file-roller would be upgraded from 3.10.0 to 
> 3.16.4
> gnu/packages/gnome.scm:2121:13: gnome-mines would be upgraded from 3.16.0 to 
> 3.19.2
> gnu/packages/gnome.scm:2764:13: clutter-gst would be upgraded from 3.0.6 to 
> 3.0.14
> gnu/packages/gnome.scm:177:13: gnome-desktop would be upgraded from 3.18.1 to 
> 3.19.2
> gnu/packages/gnome.scm:2462:13: gnome-settings-daemon would be upgraded from 
> 3.16.0 to 3.18.2
> gnu/packages/gnome.scm:3159:12: eog would be upgraded from 3.16.2 to 3.19.2
> gnu/packages/gnome.scm:3479:13: yelp-xsl would be upgraded from 3.16.1 to 
> 3.18.1
> gnu/packages/gnome.scm:2890:13: grilo would be upgraded from 0.2.12 to 0.2.14
> gnu/packages/gnome.scm:300:13: libgnome-keyring would be upgraded from 3.6.0 
> to 3.12.0
> gnu/packages/gnome.scm:587:13: adwaita-icon-theme would be upgraded from 
> 3.16.2 to 3.18.0
> gnu/packages/gnome.scm:774:13: libcroco would be upgraded from 0.6.8 to 0.6.9
> gnu/packages/gnome.scm:398:13: evince would be upgraded from 3.18.1 to 3.18.2
> gnu/packages/gnome.scm:3503:13: yelp would be upgraded from 3.16.1 to 3.19.1
> gnu/packages/gnome.scm:2004:13: libsoup would be upgraded from 2.52.1 to 
> 2.53.2
> gnu/packages/gnome.scm:3373:13: epiphany would be upgraded from 3.16.3 to 
> 3.18.1
> gnu/packages/gnome.scm:2326:13: geocode-glib would be upgraded from 3.16.0 to 
> 3.18.0
> gnu/packages/gnome.scm:2795:13: libchamplain would be upgraded from 0.12.10 
> to 0.12.12
> gnu/packages/gnome.scm:3940:13: gnome-online-accounts would be upgraded from 
> 3.18.1 to 3.19.2
> gnu/packages/gnome.scm:2993:13: totem would be upgraded from 3.16.1 to 3.18.1
> gnu/packages/gnome.scm:2859:13: gnome-klotski would be upgraded from 3.16.1 
> to 3.19.1
> gnu/packages/gnome.scm:2736:13: clutter-gtk would be upgraded from 1.6.0 to 
> 1.6.6
> gnu/packages/gnome.scm:1612:13: seahorse would be upgraded from 3.16.0 to 
> 3.18.0
> gnu/packages/gnome.scm:2074:13: libsecret would be upgraded from 0.18 to 
> 0.18.3
> gnu/packages/gnome.scm:155:13: gnome-common would be upgraded from 3.14.0 to 
> 3.18.0
> gnu/packages/gnome.scm:4196:13: network-manager-applet would be upgraded from 
> 1.0.6 to 1.0.8
> gnu/packages/gnome.scm:837:13: librsvg would be upgraded from 2.40.11 to 
> 2.40.12
> gnu/packages/gnome.scm:2941:13: grilo-plugins would be upgraded from 

Re: GNOME updater

[Ludovic Courtès]

Efraim Flashner  skribis:

> A for gnome-3, the 3.19 series AFAIK is the beta/development releases for
> 3.20, so would we want to update to those numbers?

Good point, we probably don’t want those.

Fixed in c499125, which leads to a shorter list:

--8<---cut here---start->8---
$ ./pre-inst-env guix refresh -t gnome 
gnu/packages/mail.scm:211:13: gmime would be upgraded from 2.6.19 to 2.6.20
gnu/packages/gtk.scm:852:13: atkmm would be upgraded from 2.24.1 to 2.24.2
gnu/packages/gnome.scm:1612:13: seahorse would be upgraded from 3.16.0 to 3.18.0
gnu/packages/gnome.scm:1340:13: libgnomeprintui would be upgraded from 2.8.2 to 
2.18.6
gnu/packages/gnome.scm:3373:13: epiphany would be upgraded from 3.16.3 to 3.18.1
gnu/packages/gnome.scm:331:13: gnome-keyring would be upgraded from 3.16.0 to 
3.18.3
gnu/packages/gnome.scm:4196:13: network-manager-applet would be upgraded from 
1.0.6 to 1.0.8
gnu/packages/gnome.scm:837:13: librsvg would be upgraded from 2.40.11 to 2.40.12
gnu/packages/gnome.scm:3538:13: yelp-tools would be upgraded from 3.16.1 to 
3.18.0
gnu/packages/gnome.scm:3691:13: file-roller would be upgraded from 3.10.0 to 
3.16.4
gnu/packages/gnome.scm:1517:13: gnumeric would be upgraded from 1.12.17 to 
1.12.24
gnu/packages/gnome.scm:2764:13: clutter-gst would be upgraded from 3.0.6 to 
3.0.14
gnu/packages/gnome.scm:1762:13: dconf would be upgraded from 0.22.0 to 0.24.0
gnu/packages/gnome.scm:2941:13: grilo-plugins would be upgraded from 0.2.14 to 
0.2.16
gnu/packages/gnome.scm:3237:13: gvfs would be upgraded from 1.24.1 to 1.26.2
gnu/packages/gnome.scm:2553:13: aisleriot would be upgraded from 3.16.1 to 
3.18.2
gnu/packages/gnome.scm:2795:13: libchamplain would be upgraded from 0.12.10 to 
0.12.12
gnu/packages/gnome.scm:3479:13: yelp-xsl would be upgraded from 3.16.1 to 3.18.1
gnu/packages/gnome.scm:2074:13: libsecret would be upgraded from 0.18 to 0.18.3
gnu/packages/gnome.scm:2736:13: clutter-gtk would be upgraded from 1.6.0 to 
1.6.6
gnu/packages/gnome.scm:587:13: adwaita-icon-theme would be upgraded from 3.16.2 
to 3.18.0
gnu/packages/gnome.scm:1460:13: goffice would be upgraded from 0.10.14 to 
0.10.24
gnu/packages/gnome.scm:398:13: evince would be upgraded from 3.18.1 to 3.18.2
gnu/packages/gnome.scm:300:13: libgnome-keyring would be upgraded from 3.6.0 to 
3.12.0
gnu/packages/gnome.scm:2326:13: geocode-glib would be upgraded from 3.16.0 to 
3.18.0
gnu/packages/gnome.scm:2993:13: totem would be upgraded from 3.16.1 to 3.18.1
gnu/packages/gnome.scm:1302:13: libgnomeprint would be upgraded from 2.8.2 to 
2.18.8
gnu/packages/gnome.scm:2589:13: devhelp would be upgraded from 3.16.1 to 3.18.1
gnu/packages/gnome.scm:2890:13: grilo would be upgraded from 0.2.12 to 0.2.14
gnu/packages/gnome.scm:774:13: libcroco would be upgraded from 0.6.8 to 0.6.9
gnu/packages/gnome.scm:155:13: gnome-common would be upgraded from 3.14.0 to 
3.18.0
gnu/packages/gnome.scm:2462:13: gnome-settings-daemon would be upgraded from 
3.16.0 to 3.18.2
gnu/packages/glib.scm:409:13: libsigc++ would be upgraded from 2.6.1 to 2.6.2
--8<---cut here---end--->8---

> Also, if we don't want to use those releases, we should check if the
> other packages also use the odd (version minor-version) numbers as a
> symbol for beta/rc releases.

This is checked for GNU packages already, and I assume there’s no notion
of “unstable” releases on repos such as PyPI and CRAN?

Thanks for your feedback!

Ludo’.

Re: Test failure of ilmbase-2.2.0 on i686-linux (testBoxAlgo.cpp)

[Ludovic Courtès]

Hi Leo, and thanks for the perfect upstream bug report!

Leo Famulari  skribis:

> [1]
> http://lists.gnu.org/archive/html/bug-guix/2015-11/msg00179.html

Small comment: bug-g...@gnu.org is linked to the bug tracker at
.  It is best to refer to the bug by canonical
URL,  in this case, and to Cc:
22...@debbugs.gnu.org, so we keep track of the discussion.

I reckon this is probably not obvious to someone who hasn’t used
bugs.gnu.org before; maybe we should fix our documentation?

Thanks again,
Ludo’.

Re: [DMD] [PATCH] service: Change gid before uid when dropping privileges.

[Ludovic Courtès]

"Thompson, David"  skribis:

> On Mon, Dec 7, 2015 at 8:22 AM, Thompson, David
>  wrote:
>> On Sun, Dec 6, 2015 at 4:56 PM, Ludovic Courtès  wrote:
>>> "Thompson, David"  skribis:
>>>
 On Fri, Dec 4, 2015 at 3:00 AM, Ricardo Wurmus
  wrote:
>
> David Thompson  writes:
>
>> Found this little order of operations issue when trying to button up the
>> Transmission service.
>
> Looks fine to me.

 Thanks.  Now I need someone with commit access to dmd to apply it. :)
>>>
>>> Good point, should be fixed now!  (With the admin bit, even.  ;-))
>>
>> Thank you, Ludo.
>>
>>> Please take a look at the comments I made earlier.
>>
>> Noted.  You just beat me to addressing them. :)
>
> Oh, nevermind.  I thought that you fixed my commit for me, but you
> just gave me commit access.  ;)

There’s no free lunch.  :-)

Ludo’.

Re: python-matplotlib: should it propagate numpy?

[Ludovic Courtès]

Federico Beffa  skribis:

> On Sun, Dec 6, 2015 at 11:22 PM, Ludovic Courtès  wrote:
>> Federico Beffa  skribis:
>>
>>> Ricardo Wurmus  writes:
>>>
 Hi Guix,

 with a profile containing python-2.7.10 and python2-matplotlib I did
 this:

 
 [rwurmus@guix-builder:~] $ export
 GI_TYPELIB_PATH="$HOME/.guix-profile/lib/girepository-1.0"
 [rwurmus@guix-builder:~] $ export
 PYTHONPATH=$HOME/.guix-profile/lib/python2.7/site-packages
 [rwurmus@guix-builder:~] $ python
 Python 2.7.10 (default, Oct  9 2015, 22:48:33)
 [GCC 4.9.3] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.pyplot as plt
 Traceback (most recent call last):
   File "", line 1, in 
   File 
 "/home/rwurmus/.guix-profile/lib/python2.7/site-packages/matplotlib-1.4.2-py2.7-linux-x86_64.egg/matplotlib/__init__.py",
  line 180, in 
 from matplotlib.cbook import is_string_like
   File 
 "/home/rwurmus/.guix-profile/lib/python2.7/site-packages/matplotlib-1.4.2-py2.7-linux-x86_64.egg/matplotlib/cbook.py",
  line 33, in 
 import numpy as np
 ImportError: No module named numpy
>>>
 
>>>
>>> Yeah, we should propagate numpy really.
>>
>> So, what’s the status of this discussion?  To propagate or not to
>> propagate?  :-)
>
> I just tried out using matplotlib without numpy and it actually works:
>
> --
> $ ipython
> Python 3.4.3 (default, Jan  1 1970, 00:00:01)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 3.2.1 -- An enhanced Interactive Python.
> ? -> Introduction and overview of IPython's features.
> %quickref -> Quick reference.
> help  -> Python's own help system.
> object?   -> Details about 'object', use 'object??' for extra details.
>
> In [1]: import matplotlib.pyplot as plt
>
> In [2]: t = range(5)
>
> In [3]: plt.plot(t, t)
> Out[3]: []
>
> In [4]: plt.show()
>
> --
>
> Therefore, despite numpy being the standard data crunching base
> format, I don't think we need to propagate it.

OK, sounds reasonable.  Thanks for checking!

Ludo’.

[PATCH] gnu: rxvt-unicode: Add the terminal capability data.

[Mathieu Lirzin]

>From 00d45cdc47bd0d031d0870155e24fa814dad4833 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Sun, 6 Dec 2015 21:58:03 +0100
Subject: [PATCH] gnu: rxvt-unicode: Add the terminal capability data.

This adds the necessary terminal capability data which are not provided
by Ncurses due to a personal conflict between the respective
maintainers.  See
https://lists.gnu.org/archive/html/bug-ncurses/2009-10/msg00031.html.

* gnu/packages/xdisorg.scm (rxvt-unicode)[native-inputs]: Add ncurses.
[arguments]: Set the destination of the terminfo files.
---
 gnu/packages/xdisorg.scm | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm
index 4b5308c..df8aa99 100644
--- a/gnu/packages/xdisorg.scm
+++ b/gnu/packages/xdisorg.scm
@@ -40,6 +40,7 @@
   #:use-module (gnu packages gettext)
   #:use-module (gnu packages glib)
   #:use-module (gnu packages gnome)   ;for libgudev
+  #:use-module (gnu packages ncurses)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages python)
   #:use-module (gnu packages linux)
@@ -529,23 +530,28 @@ compact configuration syntax.")
   (package
 (name "rxvt-unicode")
 (version "9.21")
-(source
-  (origin
-(method url-fetch)
-(uri (string-append
-  "http://dist.schmorp.de/rxvt-unicode/;
-  name "-"
-  version
-  ".tar.bz2"))
-(sha256
-  (base32
-"0swmi308v5yxsddrdhvi4cch88k2bbs2nffpl5j5m2f55gbhw9vm"
+(source (origin
+  (method url-fetch)
+  (uri (string-append "http://dist.schmorp.de/rxvt-unicode/;
+  name "-" version ".tar.bz2"))
+  (sha256
+   (base32
+"0swmi308v5yxsddrdhvi4cch88k2bbs2nffpl5j5m2f55gbhw9vm"
 (build-system gnu-build-system)
+(arguments
+ ;; This sets the destination when installing the necessary terminal
+ ;; capability data which are not provided by Ncurses due to a personal
+ ;; conflict between the respective maintainers.  See
+ ;; https://lists.gnu.org/archive/html/bug-ncurses/2009-10/msg00031.html.
+ '(#:make-flags (list (string-append "TERMINFO="
+ (assoc-ref %outputs "out")
+ "/share/terminfo"
 (inputs
  `(("libXft" ,libxft)
("libX11" ,libx11)))
 (native-inputs
- `(("perl" ,perl)
+ `(("ncurses" ,ncurses) ;trigger the installation of terminfo data
+   ("perl" ,perl)
("pkg-config" ,pkg-config)))
 (home-page "http://software.schmorp.de/pkg/rxvt-unicode.html;)
 (synopsis "Rxvt clone with XFT and unicode support")
-- 
2.6.3

Re: armhf build machines

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Leo Famulari  skribis:
>>
>>> On Mon, Dec 07, 2015 at 11:36:46AM +0100, Andreas Enge wrote:
 On Mon, Dec 07, 2015 at 11:14:24AM +0200, Efraim Flashner wrote:
 > The impression I got from looking at the build farm thank-yous on the 
 > website
 > was that we have lowered requirements for what we're looking for in armhf
 > build machines, at least in terms of RAM. In terms of freedom the 
 > Raspberry
 > Pi 2 isn't great, but in terms of cost its pretty inexpensive.  Is this
 > something we'd be interested in?
 
 We are waiting for two new Novena boards that should arrive before the
 end of the year. The current bottleneck is not the build machines, but 
 hydra;
 already now the build farm could sustain more jobs in parallel, but we
 artificially limit them. So I would say that there is currently no need
 to add more build machines. This may change if we get a physical machine
 for hydra.
>>>
>>> What sort of machine would be appropriate for hydra?
>>
>> Something rather big: say 8+ cores, 16+G RAM, fast disk of 3T at least.
>
> I would also add that it should run Libreboot, for which the ASUS
> KGPE-D16 is currently the best supported server-class motherboard.

Right, I would prefer it as well; I hope we can find such rackable
servers.

If it turns out that all we can buy in practice is an ME-backdoored
server, I *might* be willing to take it, with the understanding that it
would become less and less of a single point of trust (assuming more of
our package builds become reproducible, and other users publish binaries
as well.)

WDYT?

Ludo’.

Re: armhf build machines

[Mark H Weaver]

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

> Mark H Weaver  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Leo Famulari  skribis:
>>>
 What sort of machine would be appropriate for hydra?
>>>
>>> Something rather big: say 8+ cores, 16+G RAM, fast disk of 3T at least.
>>
>> I would also add that it should run Libreboot, for which the ASUS
>> KGPE-D16 is currently the best supported server-class motherboard.
>
> Right, I would prefer it as well; I hope we can find such rackable
> servers.
>
> If it turns out that all we can buy in practice is an ME-backdoored
> server,

Under what set of circumstances would this be the case?  The ASUS
KGPE-D16 is widely available.  It's even available pre-flashed with
Libreboot from minifree.org, the company run by Francis Rowe, the
creator of Libreboot.

> I *might* be willing to take it, with the understanding that it
> would become less and less of a single point of trust (assuming more of
> our package builds become reproducible, and other users publish binaries
> as well.)

If hydra is compromised, then its private key could be stolen and
facilitate targetted delivery of malicious binary substitutes to
individual users.  The existence of other users who run 'guix challenge'
would not prevent that, afaict.

Anyway, to my mind, the security issues are secondary.  We should avoid
running non-free software wherever feasible.  It is now fairly easy for
us to arrange for hydra.gnu.org to run 100% free software from the boot
firmware up.  Given this, and our commitment to free software, I'm
surprised that we would not make this a priority.

More thoughts?

  Regards,
Mark

Re: Test failure of ilmbase-2.2.0 on i686-linux (testBoxAlgo.cpp)

[Mark H Weaver]

[added 22...@debbugs.gnu.org to the CC list]

Leo Famulari  writes:

> Greetings from Guix! [0]
>
> We're having trouble building ilmbase-2.2.0 for the i686 architecture on
> Linux, with gcc-4.9.3.
>
> The build process fails during testing. Specifically, it fails
> testBoxAlgo, like this:
>
> ImathTest: testBoxAlgo.cpp:892: void {anonymous}::boxMatrixTransform(): 
> Assertion `b21 == b2' failed.
> /gnu/store/isxqjfaglyfsbcv75y8qbqbph8v28ykr-bash-4.3.39/bin/bash: line 5:  
> 4565 Aborted ${dir}$tst
>
> On our mailing list, this was suggested as the nature of the problem
> [1]:
> On Mon, Nov 30, 2015 at 10:14:49PM +0200, Ludovic Courtès wrote:
>> Right.  This sounds very much like a rounding issue, whereby the
>> epsilon in floating-point number comparisons is to strict for 32-bit
>> machines.

Given that ilmbase builds successfully in Guix on x86_64, mips64el, and
armhf, and only fails on i686, I believe that Ludovic's suggestion is
right on the mark.

The issue is that the x87 instruction set (used on 32-bit Intel systems
without SSE) uses 80-bit double-extended precision internally.  When
these 80-bit results are later converted to 64-bit doubles, they are
rounded a second time.  This "double rounding" results in larger
round-off errors than would occur when rounding only once to 64-bit
doubles, as is done when using x86_64, SSE2, or other architectures.
For more on this, see:

  https://en.wikipedia.org/wiki/Rounding#Double_rounding

Quoting from that page:

  Some computer languages and the IEEE 754-2008 standard dictate that in
  straightforward calculations the result should not be rounded twice.
  This has been a particular problem with Java as it is designed to be
  run identically on different machines, special programming tricks have
  had to be used to achieve this with x87 floating point.[1][2]

  [1] Samuel A. Figueroa (July 1995). "When is double rounding
  innocuous?". ACM SIGNUM Newsletter (ACM) 30 (3):
  21–25. doi:10.1145/221332.221334.

  [2] Roger Golliver (October 1998). "Efficiently producing default
  orthogonal IEEE double results using extended IEEE
  hardware". Intel.
  

Hope this helps,

  Mark

Re: [PATCH] gtk+: Support GUIX_GTK{2,3}_PATH variables.

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> From 11f502281064525a067c1453cd2b7b663bf6c3bb Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus 
>> Date: Thu, 3 Dec 2015 08:32:06 +0100
>> Subject: [PATCH 2/3] gnu: gtk+: Add patch to support GUIX_GTK3_PATH.
>>
>> * gnu/packages/patches/gtk3-respect-GUIX_GTK3_PATH: New file.
>> * gnu-system.am (dist_patch_DATA): Add it.
>> * gnu/packages/gtk.scm (gtk+) [source]: Add patch.
>> [native-search-paths]: Add search path for GUIX_GTK3_PATH.
>
> LGTM.
>
> This will have to go to a separate branch.  We’ll get Hydra to build it
> once it’s done with the security updates.

Could you push them to a new branch then?  I have no control over what
Hydra builds and I assume you’d want to rebase them on top of the
security updates.

> I agree with Andy that this needs to be discussed with upstream though.
> Could you open a bug on their tracker and explain the problem and
> proposed solution?

Yes, I’ll take care of this.

~~ Ricardo

Re: Test failure of ilmbase-2.2.0 on i686-linux (testBoxAlgo.cpp)

[Leo Famulari]

On Tue, Dec 08, 2015 at 06:06:25PM +0100, Ludovic Courtès wrote:
> Hi Leo, and thanks for the perfect upstream bug report!
> 
> Leo Famulari  skribis:
> 
> > [1]
> > http://lists.gnu.org/archive/html/bug-guix/2015-11/msg00179.html
> 
> Small comment: bug-g...@gnu.org is linked to the bug tracker at
> .  It is best to refer to the bug by canonical
> URL,  in this case, and to Cc:
> 22...@debbugs.gnu.org, so we keep track of the discussion.

D'oh! I made a note of this practice in the past but it slipped my mind.

> 
> I reckon this is probably not obvious to someone who hasn’t used
> bugs.gnu.org before; maybe we should fix our documentation?

It's a good idea, especially for new packagers like me. I suppose under
packaging there could be a brief description of how to write a good bug
report in general as well as Guix-specific things like how to reference
the bug. As well as a reminder to practice rubber-duck debugging before
sending the bug report ;)

> 
> Thanks again,
> Ludo’.

Re: [PATCH] gnu: rxvt-unicode: Add the terminal capability data.

[Leo Famulari]

On Tue, Dec 08, 2015 at 06:18:50PM +0100, Mathieu Lirzin wrote:
> From 00d45cdc47bd0d031d0870155e24fa814dad4833 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin 
> Date: Sun, 6 Dec 2015 21:58:03 +0100
> Subject: [PATCH] gnu: rxvt-unicode: Add the terminal capability data.
> 
> This adds the necessary terminal capability data which are not provided
> by Ncurses due to a personal conflict between the respective
> maintainers.  See
> https://lists.gnu.org/archive/html/bug-ncurses/2009-10/msg00031.html.
> 
> * gnu/packages/xdisorg.scm (rxvt-unicode)[native-inputs]: Add ncurses.
> [arguments]: Set the destination of the terminfo files.
> ---
>  gnu/packages/xdisorg.scm | 30 ++
>  1 file changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm
> index 4b5308c..df8aa99 100644
> --- a/gnu/packages/xdisorg.scm
> +++ b/gnu/packages/xdisorg.scm
> @@ -40,6 +40,7 @@
>#:use-module (gnu packages gettext)
>#:use-module (gnu packages glib)
>#:use-module (gnu packages gnome)   ;for libgudev
> +  #:use-module (gnu packages ncurses)
>#:use-module (gnu packages perl)
>#:use-module (gnu packages python)
>#:use-module (gnu packages linux)
> @@ -529,23 +530,28 @@ compact configuration syntax.")
>(package
>  (name "rxvt-unicode")
>  (version "9.21")
> -(source
> -  (origin
> -(method url-fetch)
> -(uri (string-append
> -  "http://dist.schmorp.de/rxvt-unicode/;
> -  name "-"
> -  version
> -  ".tar.bz2"))
> -(sha256
> -  (base32
> -"0swmi308v5yxsddrdhvi4cch88k2bbs2nffpl5j5m2f55gbhw9vm"
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append "http://dist.schmorp.de/rxvt-unicode/;
> +  name "-" version ".tar.bz2"))
> +  (sha256
> +   (base32
> +"0swmi308v5yxsddrdhvi4cch88k2bbs2nffpl5j5m2f55gbhw9vm"
>  (build-system gnu-build-system)
> +(arguments
> + ;; This sets the destination when installing the necessary terminal
> + ;; capability data which are not provided by Ncurses due to a personal
> + ;; conflict between the respective maintainers.  See
> + ;; https://lists.gnu.org/archive/html/bug-ncurses/2009-10/msg00031.html.

I think it's best not to describe the issue in these terms in the
codebase. I don't know the situation, but if it is as you say, I think
it will never get better as things like this "cement" the conflict in
source code. Also, ncurses seems to be capitalized only at the beginning
of a sentence. How about this:

This sets the destination when installing the necessary terminal
capability data, which are not provided by ncurses. See
https://lists.gnu.org/archive/html/bug-ncurses/2009-10/msg00031.html

> + '(#:make-flags (list (string-append "TERMINFO="
> + (assoc-ref %outputs "out")
> + "/share/terminfo"
>  (inputs
>   `(("libXft" ,libxft)
> ("libX11" ,libx11)))
>  (native-inputs
> - `(("perl" ,perl)
> + `(("ncurses" ,ncurses) ;trigger the installation of terminfo 
> data
> +   ("perl" ,perl)
> ("pkg-config" ,pkg-config)))
>  (home-page "http://software.schmorp.de/pkg/rxvt-unicode.html;)
>  (synopsis "Rxvt clone with XFT and unicode support")
> -- 
> 2.6.3
> 
> 

Missing configure

[Andreas Enge]

Hello,

the source code of numactl-2.0.10 is missing the "configure" file (and
potentially other files generated by the autotoools). Could you create
the tarball via the command "make dist"? This creates all necessary files
so that users who want to compile the package can do so without running
"autogen.sh", which means without installing the autotools themselves,
and by simply running the classic "./configure && make check && make install".

Incidentally, it will also simplify the packaging work for gnu/linux
distributions.

Andreas

Re: [PATCH] Update numactl

[Andreas Enge]

On Sun, Oct 18, 2015 at 07:35:44PM +0200, Ludovic Courtès wrote:
> Pfff…  Could you email upstream and ask them to run ‘make dist’ next
> time?  It’s really weird: They used to do it, and it looks as if they
> had forgotten.  :-/

No, they did not use the autotools and had just a Makefile.

Andreas

Re: [PATCH] Update numactl

[Andreas Enge]

On Sat, Oct 17, 2015 at 11:18:25PM +0200, Andreas Enge wrote:
> It does not build on arm. On debian, hwloc does not depend on libnuma
> on the armel and armhf architectures:
>https://packages.debian.org/jessie/libhwloc5
> So maybe we could make it an input only for non-arm architectures?

What do you think of this suggestion?

Andreas