bug#26256: [PATCH 1/6] Revert "gnu: snappy: Update to 1.1.4."

bug#26256: [PATCH 1/6] Revert "gnu: snappy: Update to 1.1.4."

[Ludovic Courtès]

Hi Marius!

Marius Bakke <mbakke@fastmail.com> skribis:

> Rocksdb fails to build with this version.
>
> This reverts commit 9baab9aeeda394408290613c597bff1d96004dfb.

Sounds good, unless this introduces serious bugs or security issues.

Thanks,
Ludo’.

bug#26256: [PATCH 2/6] gnu: xmlstarlet: Disable failing tests.

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> * gnu/packages/xml.scm (xmlstarlet)[arguments]: Add phase to disable two tests.
> ---
>  gnu/packages/xml.scm | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/gnu/packages/xml.scm b/gnu/packages/xml.scm
> index 66eb63ade..bd2748287 100644
> --- a/gnu/packages/xml.scm
> +++ b/gnu/packages/xml.scm
> @@ -1033,6 +1033,16 @@ C++ programming language.")
>         (base32
>          "1jp737nvfcf6wyb54fla868yrr39kcbijijmjpyk4lrpyg23in0m"))))
>     (build-system gnu-build-system)
> +   (arguments
> +    '(#:phases
> +     (modify-phases %standard-phases
> +       (add-before 'check 'drop-failing-tests
> +         (lambda _
> +           ;; FIXME: Why are these tests failing.

If there’s a test log excerpt that would be worth adding in this
comment, that’s even better.  Otherwise go for it!

Ludo’.

bug#26256: [PATCH 3/6] gnu: Add ceph.

[Ludovic Courtès]

Heya!

Marius Bakke <mbakke@fastmail.com> skribis:

> From be372f4c3a278568872b0175ab308c08c1b02cc5 Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> Date: Tue, 27 Dec 2016 21:40:41 +0100
> Subject: [PATCH] gnu: Add ceph.
>
> * gnu/packages/storage.scm,
>   gnu/packages/patches/ceph-disable-cpu-optimizations.patch,
>   gnu/packages/patches/ceph-skip-collect-sys-info-test.patch,
>   gnu/packages/patches/ceph-skip-unittest_blockdev.patch: New files.
> * gnu/local.mk (GNU_SYSTEM_MODULES, dist_patch_DATA): Register it.

Great work!  Thanks for taking the time to look at all the details (SSE,
failing tests, licenses, etc.).

LGTM!

> +                  (for-each delete-file-recursively
> +                            '(;; TODO: Unbundle these:
> +                              ;"src/isa-l"
> +                              ;"src/lua"
> +                              ;"src/googletest"
> +                              ;"src/xxHash"
> +                              ;"src/zstd"
> +                              ;"src/civetweb"
> +                              ;"src/Beast"

Hopefully Lua and zstd would be easy to address, but yeah, we can leave
it for after.  :-)

Thank you,
Ludo’.

bug#26256: [PATCH 3/6] gnu: Add ceph.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>> +                  (for-each delete-file-recursively
>> +                            '(;; TODO: Unbundle these:
>> +                              ;"src/isa-l"
>> +                              ;"src/lua"
>> +                              ;"src/googletest"
>> +                              ;"src/xxHash"
>> +                              ;"src/zstd"
>> +                              ;"src/civetweb"
>> +                              ;"src/Beast"
>
> Hopefully Lua and zstd would be easy to address, but yeah, we can leave
> it for after.  :-)

Yes, it's on my priority list, but figured it's better to have it
available so that others can use it and help out. I keep picking this up
every few weeks, but the build takes hours and so it's very tiring work.

(also, poor Hydra!)

The TODO list is:

* make `ceph-disk` work for the tests (it works when installed)
* make it build on ARM (apparently libaio is unsupported there)
* unbundle more things
* services! (I need more hardware first though :-))

I'm committed to supporting this package, so please ping me about any
problems (in Guix, or on your test cluster ;-))

Also, I just built this to verify that it still works, but got two
different test failures on two different machines, suggesting some tests
are flaky. Perhaps I should just disable these two off the bat?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#26256: [PATCH 3/6] gnu: Add ceph.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> Also, I just built this to verify that it still works, but got two
> different test failures on two different machines, suggesting some tests
> are flaky. Perhaps I should just disable these two off the bat?

Nevermind, it was two very rare race conditions (one that only seems to
occur with -j16 and slow storage). Let's deal with them if it they turn
out to be not so rare.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#26256: [PATCH 3/6] gnu: Add ceph.

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> +                  (for-each delete-file-recursively
>>> +                            '(;; TODO: Unbundle these:
>>> +                              ;"src/isa-l"
>>> +                              ;"src/lua"
>>> +                              ;"src/googletest"
>>> +                              ;"src/xxHash"
>>> +                              ;"src/zstd"
>>> +                              ;"src/civetweb"
>>> +                              ;"src/Beast"
>>
>> Hopefully Lua and zstd would be easy to address, but yeah, we can leave
>> it for after.  :-)
>
> Yes, it's on my priority list, but figured it's better to have it
> available so that others can use it and help out. I keep picking this up
> every few weeks, but the build takes hours and so it's very tiring work.
>
> (also, poor Hydra!)
>
> The TODO list is:
>
> * make `ceph-disk` work for the tests (it works when installed)
> * make it build on ARM (apparently libaio is unsupported there)
> * unbundle more things
> * services! (I need more hardware first though :-))
>
> I'm committed to supporting this package, so please ping me about any
> problems (in Guix, or on your test cluster ;-))

Awesome.

> Also, I just built this to verify that it still works, but got two
> different test failures on two different machines, suggesting some tests
> are flaky. Perhaps I should just disable these two off the bat?

Maybe best to disable them, yes.

Thanks!

Ludo’.

bug#26256: [PATCH 4/6] gnu: fio: Enable rbd support.

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> * gnu/packages/benchmark.scm (fio)[inputs]: Add ceph:lib.

Would be worth checking how this affects the closure size.  It’s a
developer tool though, so I’d argue that it’s less of a problem if the
closure size is increased noticeably in this cases.

Otherwise LGTM, thanks!

Ludo’.

bug#26256: [PATCH 4/6] gnu: fio: Enable rbd support.

[Marius Bakke]

[-- Attachment #1.1: Type: text/plain, Size: 605 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> * gnu/packages/benchmark.scm (fio)[inputs]: Add ceph:lib.
>
> Would be worth checking how this affects the closure size.  It’s a
> developer tool though, so I’d argue that it’s less of a problem if the
> closure size is increased noticeably in this cases.

ceph:lib increases fios closure size from 452.3 MiB to a good 738 MiB.

However, by moving the fio auxiliary scripts to a separate output, I
managed to get the baseline size down from 452.3 MiB to 75.3 MiB. See
attached patch. WDYT?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-gnu-fio-Install-python-scripts-in-separate-output.patch --]
[-- Type: text/x-patch, Size: 2180 bytes --]

From b942036bef17a4eacfd7406a9a5130fd2255252d Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Tue, 28 Mar 2017 00:08:36 +0200
Subject: [PATCH] gnu: fio: Install python scripts in separate output.

* gnu/packages/benchmark.scm (fio)[outputs]: New field.
[arguments]: Rename 'wrap-python-scripts' to 'move-outputs'. Keep wrapper.
---
 gnu/packages/benchmark.scm | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/gnu/packages/benchmark.scm b/gnu/packages/benchmark.scm
index ff5715d57..994bf1db2 100644
--- a/gnu/packages/benchmark.scm
+++ b/gnu/packages/benchmark.scm
@@ -64,13 +64,22 @@
              (let ((out (assoc-ref outputs "out")))
                (zero? (system* "./configure"
                                (string-append "--prefix=" out))))))
-         (add-after
-          'install 'wrap-python-scripts
-          (lambda* (#:key inputs outputs #:allow-other-keys)
-            (let ((out (assoc-ref outputs "out")))
-              (wrap-program (string-append out "/bin/fiologparser_hist.py")
-                `("PYTHONPATH" ":" prefix (,(getenv "PYTHONPATH"))))
-              #t))))))
+         (add-after 'install 'move-outputs
+           (lambda* (#:key outputs #:allow-other-keys)
+             (let ((out (assoc-ref outputs "out"))
+                   (utils (string-append (assoc-ref outputs "utils") "/bin")))
+               (mkdir-p utils)
+               (for-each (lambda (file)
+                           (let ((src (string-append out "/bin/" file))
+                                 (dst (string-append utils "/" file)))
+                             (link src dst)
+                             (delete-file src)))
+                         '("fio2gnuplot" "fio_latency2csv.py"
+                           "fiologparser_hist.py" "fiologparser.py"))
+               (wrap-program (string-append utils "/fiologparser_hist.py")
+                 `("PYTHONPATH" ":" prefix (,(getenv "PYTHONPATH"))))
+               #t))))))
+    (outputs '("out" "utils"))
     (inputs
      `(("libaio" ,libaio)
        ("gnuplot" ,gnuplot)
-- 
2.12.2


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#26256: [PATCH 4/6] gnu: fio: Enable rbd support.

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Marius Bakke <mbakke@fastmail.com> skribis:
>>
>>> * gnu/packages/benchmark.scm (fio)[inputs]: Add ceph:lib.
>>
>> Would be worth checking how this affects the closure size.  It’s a
>> developer tool though, so I’d argue that it’s less of a problem if the
>> closure size is increased noticeably in this cases.
>
> ceph:lib increases fios closure size from 452.3 MiB to a good 738 MiB.
>
> However, by moving the fio auxiliary scripts to a separate output, I
> managed to get the baseline size down from 452.3 MiB to 75.3 MiB. See
> attached patch. WDYT?
>
> From b942036bef17a4eacfd7406a9a5130fd2255252d Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> Date: Tue, 28 Mar 2017 00:08:36 +0200
> Subject: [PATCH] gnu: fio: Install python scripts in separate output.
>
> * gnu/packages/benchmark.scm (fio)[outputs]: New field.
> [arguments]: Rename 'wrap-python-scripts' to 'move-outputs'. Keep wrapper.

[...]

> +         (add-after 'install 'move-outputs
> +           (lambda* (#:key outputs #:allow-other-keys)
> +             (let ((out (assoc-ref outputs "out"))
> +                   (utils (string-append (assoc-ref outputs "utils") "/bin")))

Add a comment explaining that this saves X MiB on the closure.

> +    (outputs '("out" "utils"))

Maybe s/utils/bin/ if there aren’t any other binaries, otherwise LGTM!

Thank you!

Ludo’.

bug#26256: [PATCH 6/6] gnu: Add multipath-tools.

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> * gnu/packages/linux.scm (multipath-tools): New variable.

LGTM, thank you!

Ludo’.

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> * gnu/packages/linux.scm (userspace-rcu): New variable.

[...]

> +    (license
> +     ;; This library is distributed under LGPL2.1+, but includes some files
> +     ;; covered by other licenses. The LICENSE file has full details.
> +     (list license:lgpl2.1+
> +           license:gpl3+                         ; most tests are gpl2+; tap.sh is gpl3+
> +           license:bsd-2                         ; tests/utils/tap/tap.[ch]
> +           license:expat                         ; urcu/uatomic/*
> +           ;; A few files use different variants of the MIT/X11 license.
> +           (license:x11-style "file://LICENSE"
> +                              "See LICENSE in the distribution for details.")))))

It’s a case where it’d be enough to put lgpl2.1+ and gpl3+ IMO, since
that’s what effectively applies to the resulting work.

You could still mention the other licenses in the comment though.

Otherwise LGTM, thanks!

Ludo’.

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> * gnu/packages/linux.scm (userspace-rcu): New variable.
>
> [...]
>
>> +    (license
>> +     ;; This library is distributed under LGPL2.1+, but includes some files
>> +     ;; covered by other licenses. The LICENSE file has full details.
>> +     (list license:lgpl2.1+
>> +           license:gpl3+                         ; most tests are gpl2+; tap.sh is gpl3+
>> +           license:bsd-2                         ; tests/utils/tap/tap.[ch]
>> +           license:expat                         ; urcu/uatomic/*
>> +           ;; A few files use different variants of the MIT/X11 license.
>> +           (license:x11-style "file://LICENSE"
>> +                              "See LICENSE in the distribution for details.")))))
>
> It’s a case where it’d be enough to put lgpl2.1+ and gpl3+ IMO, since
> that’s what effectively applies to the resulting work.

Is this also true for the source code archive itself? As an end user,
looking at the license list and deciding to `guix build -S`, I would
expect the contents to match what's in the package definition.

Is this a distinction we should make? I.e. "source" license vs "product"
license. For Ceph, this would be the current license list in the first
instance and just lgpl2.1 and gpl2 for the built product.

Tricky! Moving the other licenses to the comments for this package, but
something to think about.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Marius Bakke <mbakke@fastmail.com> skribis:
>>
>>> * gnu/packages/linux.scm (userspace-rcu): New variable.
>>
>> [...]
>>
>>> +    (license
>>> +     ;; This library is distributed under LGPL2.1+, but includes some files
>>> +     ;; covered by other licenses. The LICENSE file has full details.
>>> +     (list license:lgpl2.1+
>>> +           license:gpl3+                         ; most tests are gpl2+; tap.sh is gpl3+
>>> +           license:bsd-2                         ; tests/utils/tap/tap.[ch]
>>> +           license:expat                         ; urcu/uatomic/*
>>> +           ;; A few files use different variants of the MIT/X11 license.
>>> +           (license:x11-style "file://LICENSE"
>>> +                              "See LICENSE in the distribution for details.")))))
>>
>> It’s a case where it’d be enough to put lgpl2.1+ and gpl3+ IMO, since
>> that’s what effectively applies to the resulting work.
>
> Is this also true for the source code archive itself? As an end user,
> looking at the license list and deciding to `guix build -S`, I would
> expect the contents to match what's in the package definition.
>
> Is this a distinction we should make? I.e. "source" license vs "product"
> license. For Ceph, this would be the current license list in the first
> instance and just lgpl2.1 and gpl2 for the built product.

Thinking more about this, the "output license" for Ceph would include
BSD-{2,3} as well (some erasure code stuff), but you catch my drift.

It makes sense to focus on the license you accept by using the package,
and mention whatever other source licenses that may be present as
source code comments instead.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 3024 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Marius Bakke <mbakke@fastmail.com> skribis:
>>>
>>>> * gnu/packages/linux.scm (userspace-rcu): New variable.
>>>
>>> [...]
>>>
>>>> +    (license
>>>> +     ;; This library is distributed under LGPL2.1+, but includes some files
>>>> +     ;; covered by other licenses. The LICENSE file has full details.
>>>> +     (list license:lgpl2.1+
>>>> +           license:gpl3+                         ; most tests are gpl2+; tap.sh is gpl3+
>>>> +           license:bsd-2                         ; tests/utils/tap/tap.[ch]
>>>> +           license:expat                         ; urcu/uatomic/*
>>>> +           ;; A few files use different variants of the MIT/X11 license.
>>>> +           (license:x11-style "file://LICENSE"
>>>> +                              "See LICENSE in the distribution for details.")))))
>>>
>>> It’s a case where it’d be enough to put lgpl2.1+ and gpl3+ IMO, since
>>> that’s what effectively applies to the resulting work.
>>
>> Is this also true for the source code archive itself? As an end user,
>> looking at the license list and deciding to `guix build -S`, I would
>> expect the contents to match what's in the package definition.
>>
>> Is this a distinction we should make? I.e. "source" license vs "product"
>> license. For Ceph, this would be the current license list in the first
>> instance and just lgpl2.1 and gpl2 for the built product.
>
> Thinking more about this, the "output license" for Ceph would include
> BSD-{2,3} as well (some erasure code stuff), but you catch my drift.
>
> It makes sense to focus on the license you accept by using the package,
> and mention whatever other source licenses that may be present as
> source code comments instead.

Sorry for spamming this discussion, but it's something that I haven't
seen discussed before and it's good to clarify a few of these points.

Ceph is also a prime example of a complex package covering lots of
licenses. Some of the ".so" files installed by Ceph are produced by
BSD-style code. However, they link to the main ceph libraries, which are
LGPL2.1. IIUC, LGPL2.1 "trumps" BSD here because of the strong copyleft.

Ceph also installs some erasure code ".so" files that do *not* link
against Ceph (as verified with readelf and ldd). They are covered by a
BSD-style license. These should then be mentioned separately, methinks,
because they are installed by this package and used by some of the
(L)GPL code.

Most of the Python libraries in Ceph are actually LGPL2.1+. These use
the main Ceph libraries, which are LGPL2.1 (no plus). AFAIU, the latter
still "wins", or should LGPL2.1+ be mentioned separately?

Please correct me if I'm wrong in any of these assumptions :-)

Perhaps the manual could be improved with a few clarification points,
although it's a complex issue that will vary on a case-by-case basis.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Sorry for spamming this discussion, but it's something that I haven't
> seen discussed before and it's good to clarify a few of these points.
>
> Ceph is also a prime example of a complex package covering lots of
> licenses. Some of the ".so" files installed by Ceph are produced by
> BSD-style code. However, they link to the main ceph libraries, which are
> LGPL2.1. IIUC, LGPL2.1 "trumps" BSD here because of the strong copyleft.

Right, copyleft licenses “win” over the non-copyleft ones.

> Ceph also installs some erasure code ".so" files that do *not* link
> against Ceph (as verified with readelf and ldd). They are covered by a
> BSD-style license. These should then be mentioned separately, methinks,
> because they are installed by this package and used by some of the
> (L)GPL code.

Yes, that makes sense to me.

> Most of the Python libraries in Ceph are actually LGPL2.1+. These use
> the main Ceph libraries, which are LGPL2.1 (no plus). AFAIU, the latter
> still "wins", or should LGPL2.1+ be mentioned separately?

I’d mention just LGPL2.1 since it “wins” over LGPL2.1+, but with a
comment explaining the situation.

(There’ll be a lot to read in that file! :-))

> Perhaps the manual could be improved with a few clarification points,
> although it's a complex issue that will vary on a case-by-case basis.

Indeed!  We also need clarifications on when to use “+” on GNU licenses,
since it’s never obvious to newcomers.

Thanks,
Ludo’.

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Ludovic Courtès]

Heya!

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Marius Bakke <mbakke@fastmail.com> skribis:
>>
>>> * gnu/packages/linux.scm (userspace-rcu): New variable.
>>
>> [...]
>>
>>> +    (license
>>> +     ;; This library is distributed under LGPL2.1+, but includes some files
>>> +     ;; covered by other licenses. The LICENSE file has full details.
>>> +     (list license:lgpl2.1+
>>> +           license:gpl3+                         ; most tests are gpl2+; tap.sh is gpl3+
>>> +           license:bsd-2                         ; tests/utils/tap/tap.[ch]
>>> +           license:expat                         ; urcu/uatomic/*
>>> +           ;; A few files use different variants of the MIT/X11 license.
>>> +           (license:x11-style "file://LICENSE"
>>> +                              "See LICENSE in the distribution for details.")))))
>>
>> It’s a case where it’d be enough to put lgpl2.1+ and gpl3+ IMO, since
>> that’s what effectively applies to the resulting work.
>
> Is this also true for the source code archive itself? As an end user,
> looking at the license list and deciding to `guix build -S`, I would
> expect the contents to match what's in the package definition.
>
> Is this a distinction we should make? I.e. "source" license vs "product"
> license. For Ceph, this would be the current license list in the first
> instance and just lgpl2.1 and gpl2 for the built product.

The intent was that ‘license’ would be the license that applies to the
combined work (the thing that you install), IOW the license that “wins”,
omitting build-time programs like ‘install-sh’ and similar scripts.

This is similar to what the Free Software Directory does but coarser
than what Debian does, for instance.

However that has always been under-specified, and a number of packages
list all the licenses that apply to various parts of the source, as you
did above.

> Tricky! Moving the other licenses to the comments for this package, but
> something to think about.

Yeah, tricky!

Ludo’.

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 1361 bytes --]

Marius,

On 25/03/17 21:30, Marius Bakke wrote:
> * gnu/packages/linux.scm (userspace-rcu): New variable.

This already exists as liburcu in datastructures.scm (I needed it for
the Knot DNS server), with two main differences:

> +    (native-inputs
> +     `(("perl-test-harness" ,perl-test-harness))) ; for the 'prove' command

Building liburcu with ‘perl’ or ‘perl-test-harness’ gives the same
result (Files=3, Tests=78). I know nothing about Perl. Is there a reason
to prefer ‘perl-test-harness’? It's about .5 MiB heavier.

> +    (license
> +     ;; This library is distributed under LGPL2.1+, but includes some files
> +     ;; covered by other licenses. The LICENSE file has full details.
> +     (list license:lgpl2.1+
> +           license:gpl3+                         ; most tests are gpl2+; tap.sh is gpl3+
> +           license:bsd-2                         ; tests/utils/tap/tap.[ch]
> +           license:expat                         ; urcu/uatomic/*
> +           ;; A few files use different variants of the MIT/X11 license.
> +           (license:x11-style "file://LICENSE"
> +                              "See LICENSE in the distribution for details.")))))
> +

Wow. As usual you're a lot better at sniffing out licences than I am.

I also prefer your ‘synopsis’ to mine.

Thanks!

T G-R


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 229 bytes --]

On 27/03/17 21:49, Tobias Geerinckx-Rice wrote:
> Wow. As usual you're a lot better at sniffing out licences than I am.

Now I see Ludo's comments. I tend to agree with them, but who really knows.

Kind regards,

T G-R


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Marius,
>
> On 25/03/17 21:30, Marius Bakke wrote:
>> * gnu/packages/linux.scm (userspace-rcu): New variable.
>
> This already exists as liburcu in datastructures.scm (I needed it for
> the Knot DNS server), with two main differences:

Aaaah.. how did I miss that, thanks!

>> +    (native-inputs
>> +     `(("perl-test-harness" ,perl-test-harness))) ; for the 'prove' command
>
> Building liburcu with ‘perl’ or ‘perl-test-harness’ gives the same
> result (Files=3, Tests=78). I know nothing about Perl. Is there a reason
> to prefer ‘perl-test-harness’? It's about .5 MiB heavier.

I don't know either, I just searched around for the `prove` command and
found it was in "perl-test-harness". Apparently it's in "perl" too!

>> +    (license
>> +     ;; This library is distributed under LGPL2.1+, but includes some files
>> +     ;; covered by other licenses. The LICENSE file has full details.
>> +     (list license:lgpl2.1+
>> +           license:gpl3+                         ; most tests are gpl2+; tap.sh is gpl3+
>> +           license:bsd-2                         ; tests/utils/tap/tap.[ch]
>> +           license:expat                         ; urcu/uatomic/*
>> +           ;; A few files use different variants of the MIT/X11 license.
>> +           (license:x11-style "file://LICENSE"
>> +                              "See LICENSE in the distribution for details.")))))
>> +
>
> Wow. As usual you're a lot better at sniffing out licences than I am.

Ha, but at least you got it right (per the other discussion on this
thread) ;-)

> I also prefer your ‘synopsis’ to mine.

I can update the synopsis of the existing package, and add @code{}
wrappers to your arguably better description; as well as adding comments
about the other licenses. How does that sound? :)

PS: The PGP signature of this email is bad. If you are in fact Tobias,
please reply with a signed email stating "I will not use important
software from my host distro any longer" :-P

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 746 bytes --]

Marius,

On 27/03/17 22:08, Marius Bakke wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>> I also prefer your ‘synopsis’ to mine.
> 
> I can update the synopsis of the existing package, and add @code{} 
> wrappers to your arguably better description; as well as adding 
> comments about the other licenses. How does that sound? :)

That sounds about perfect.

> PS: The PGP signature of this email is bad. If you are in fact
> Tobias, please reply with a signed email stating "I will not use
> important software from my host distro any longer" :-P

  $ grep gpg .thunderbird/*/prefs.js
  user_pref("extensions.enigmail.agentPath",
            "/home/nckx/.guix-profile/bin/gpg");

Checkmate, atheists.

T G-R


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

>> PS: The PGP signature of this email is bad. If you are in fact
>> Tobias, please reply with a signed email stating "I will not use
>> important software from my host distro any longer" :-P
>
>   $ grep gpg .thunderbird/*/prefs.js
>   user_pref("extensions.enigmail.agentPath",
>             "/home/nckx/.guix-profile/bin/gpg");
>
> Checkmate, atheists.

Oof. Can't blame your cat this time. Is anyone else seeing a bad
signature for id:cdd6892d-5182-ee07-7452-8df83136e3d0@tobias.gr ?

Are you able to reproduce the bad git signatures with GPG from Guix?

Maybe it is the cat after all.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 1094 bytes --]

Marius,

On 28/03/17 00:31, Marius Bakke wrote:
> Oof. Can't blame your cat this time. Is anyone else seeing a bad
> signature for id:cdd6892d-5182-ee07-7452-8df83136e3d0@tobias.gr?
> 
> Are you able to reproduce the bad git signatures with GPG from Guix?

Oh! I didn't mean to send you on the beginnings of a bug hunt. Turn
back. Trust me.

Yes, my gnupg's definitely dodgy, and it really is from Guix . I've gone
so far as to rm -rf /usr/bin/gpg* — no dice. I'm pretty sure it's
somehow caused by the unique... let's call it ‘legacy-rich’ Ubuntu
installation on this work laptop. It doesn't happen anywhere else.

However: that laptop has less than one month left as Important Work
Machine. Guess what's happening next? GuixSD is happening next.

Until then, I'm just going to ignore its quirks and live with the shame
(and not push any commits from this box, hook or no). I'll make sure
anything important's signed.

> Maybe it is the cat after all.

My cat is pure evil. I'm pretty sure she uses Windows.

...aanyway: ceph! \o/

Kind regards,

T G-R


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Marius,
>
> On 28/03/17 00:31, Marius Bakke wrote:
>> Oof. Can't blame your cat this time. Is anyone else seeing a bad
>> signature for id:cdd6892d-5182-ee07-7452-8df83136e3d0@tobias.gr?
>> 
>> Are you able to reproduce the bad git signatures with GPG from Guix?
>
> Oh! I didn't mean to send you on the beginnings of a bug hunt. Turn
> back. Trust me.
>
> Yes, my gnupg's definitely dodgy, and it really is from Guix . I've gone
> so far as to rm -rf /usr/bin/gpg* — no dice. I'm pretty sure it's
> somehow caused by the unique... let's call it ‘legacy-rich’ Ubuntu
> installation on this work laptop. It doesn't happen anywhere else.

Ok, good to know. It could be worth testing the memory. I guess we'll
find out after you've migrated to an entropy-free system :-)

> ...aanyway: ceph! \o/

I tried finding a soon.gif featuring a cephalopod, but this will do:

https://i.imgur.com/bMznpIo.gif :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#26256: [PATCH 5/6] gnu: Add userspace-rcu.

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>
>>> PS: The PGP signature of this email is bad. If you are in fact
>>> Tobias, please reply with a signed email stating "I will not use
>>> important software from my host distro any longer" :-P
>>
>>   $ grep gpg .thunderbird/*/prefs.js
>>   user_pref("extensions.enigmail.agentPath",
>>             "/home/nckx/.guix-profile/bin/gpg");
>>
>> Checkmate, atheists.
>
> Oof. Can't blame your cat this time. Is anyone else seeing a bad
> signature for id:cdd6892d-5182-ee07-7452-8df83136e3d0@tobias.gr ?

I do.

Ludo’.

bug#26256: [PATCH 0/6] Add ceph + multipath-tools.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> Hello! Here is a revised Ceph patch, and some collateral patches.
> I haven't yet tried running a Ceph cluster from Guix, but since
> most of the tests passes I'm not too worried.
>
> Marius Bakke (6):
>   Revert "gnu: snappy: Update to 1.1.4."
>   gnu: xmlstarlet: Disable failing tests.
>   gnu: Add ceph.
>   gnu: fio: Enable rbd support.
>   gnu: Add userspace-rcu.
>   gnu: Add multipath-tools.

I've pushed this series after taking the comments into account.

Hopefully Hydra can cope!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]