Re: [PATCH] gnu: Add obnam.

[Arun Isaac]

> There is one user available in the build environment: "nobody". It could
> work to substitute "root" for "nobody" in the code that looks for users.
> The "mailutils" package does exactly that for tests. Can you try it?

Yes, I'll try to get the tests working, and let you know.


signature.asc
Description: PGP signature

Re: [PATCH] services: dovecot: Fix unix_listeners and fifo_listeners path types.

[Clément Lassieur]

Hi Ludovic,

> Clément Lassieur  skribis:
>
> Given that Andy okayed the patch, I think you should go ahead and push it!

Done, applied to master as eba560765a5afccbc5d3b64df410d89b1f79a18e.

There are two other patches concerning services:
http://lists.gnu.org/archive/html/guix-devel/2017-02/msg01154.html

Please, could someone do a review on these? :)

Thanks!
Clément

Re: core-updates: Python build failures

[Leo Famulari]

On Sat, Mar 11, 2017 at 08:50:32PM +0100, Marius Bakke wrote:
> I tried applying the upstream fix for 3.5:
> 
> https://hg.python.org/cpython/rev/337461574c90
> 
> However, the monster patch does not apply.

[...]

> Will try to dig out the other patches from 3.5 branch that this depends
> on tomorrow. I can't reproduce the getentropy() failure either,
> apparently it only occurs on kernels < 3.17.

Maybe we should update Python 3.5 instead, so that the patch applies. Or
update the kernels on the build farm machines.


signature.asc
Description: PGP signature

Re: gnu-patches back log

[Ludovic Courtès]

Hi Hartmut,

Hartmut Goebel  skribis:

> Am 06.03.2017 um 17:14 schrieb Ludovic Courtès:
>> add Reviewed-by tags
>
> Can git add this automatically? Otherwise it would mean additional
> manual work.

Actually Git already distinguishes between committer and author, so
you’re probably right.

Based on that, the attached Guile-Git program gives the number of
patches committed on behalf of someone else, and…  [drum roll] we get:

--8<---cut here---start->8---
scheme@(guile-user)> ,pp (sort (reviewers repo) reviewer<)
$6 = ((0 . "Nikita Karetnikov")
 (0 . "Cyril Roelandt")
 (0 . "John Darrington")
 (0 . "Jason Self")
 (0 . "Federico Beffa")
 (0 . "rekado")
 (0 . "Taylan Ulrich Bayırlı/Kammer")
 (0 . "Tomáš Čech")
 (0 . "Paul van der Walt")
 (0 . "Ben J. Woodcroft")
 (0 . "Alex Sassmannshausen")
 (0 . "Julien Lepiller")
 (1 . "Andy Wingo")
 (2 . "cyril")
 (2 . "Manolis Ragkousis")
 (2 . "Roel Janssen")
 (2 . "Tobias Geerinckx-Rice")
 (6 . "Christopher Allan Webber")
 (9 . "Hartmut Goebel")
 (13 . "Danny Milosavljevic")
 (17 . "Mathieu Lirzin")
 (29 . "Eric Bavier")
 (36 . "Andreas Enge")
 (38 . "David Craven")
 (40 . "Ben Woodcroft")
 (51 . "David Thompson")
 (52 . "Kei Kebreau")
 (68 . "宋文武")
 (81 . "Mark H Weaver")
 (88 . "Alex Kost")
 (94 . "Ricardo Wurmus")
 (99 . "Marius Bakke")
 (101 . "Efraim Flashner")
 (336 . "Leo Famulari")
 (641 . "Ludovic Courtès"))
--8<---cut here---end--->8---

Not sure if it’s 100% accurate, but it should be a good approximation.
To those with a 1-digit number, please take a look at
 and try to beat your fellow hackers!
:-)

Ludo’.

(use-modules (git)
 (git repository)
 (git reference)
 (git oid)
 (git tag)
 (git commit)
 (git structs);signature-email, etc.
 (srfi srfi-1)
 (srfi srfi-26)
 (ice-9 match)
 (ice-9 vlist))

(define commit-author*
  (compose signature-name commit-author))
(define commit-committer*
  (compose signature-name commit-committer))

(define-syntax-rule (false-if-git-error exp)
  (catch 'git-error
(lambda () exp)
(const #f)))

(define* (fold-commits proc seed repo
   #:key
   (start (reference-target
   (repository-head repo)))
   end)
  "Call PROC on each commit of REPO, starting at START (an OID), and until
END if specified."
  (let loop ((commit (commit-lookup repo start))
 (result seed))
(let ((parent (false-if-git-error (commit-parent commit
  (if parent
  (if (and end (oid=? (commit-id parent) end))
  (proc parent result)
  (loop parent (proc parent result)))
  result

(define (reviewers repo)
  "Return a list of review count/committer pairs."
  (define vhash
(fold-commits (lambda (commit result)
(if (string=? (commit-author* commit)
  (commit-committer* commit))
result
(vhash-cons (commit-committer* commit) #t
result)))
  vlist-null
  repo))

  (define committers
(delete-duplicates
 (fold-commits (lambda (commit result)
 (cons (commit-committer* commit)
   result))
   '()
   repo)))

  (map (lambda (committer)
 (cons (vhash-fold* (lambda (_ count)
  (+ 1 count))
0
committer
vhash)
   committer))
   committers))

(define (reviewer< r1 r2)
  (match r1
((count1 . name1)
 (match r2
   ((count2 . name2)
(< count1 count2))

(libgit2-init!)

(define repo
  (repository-open "."))

Re: Introducing ‘guix pack’

[Chris Marusich]

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

> Hello Guix!
>
> I had it on my to-do list and Andy said he’d like to have something like
> that to publish Guile 2.2 binaries: the ‘guix pack’ command below is a
> generalization of the code that builds the Guix binary tarball¹.  It
> creates a bundle of the closure of the given packages, with a profile
> containing all the packages.

Very cool!

> lrwxrwxrwx root/root 0 1970-01-01 01:00 
> ./gnu/store/ynafk7v924xil993dqbx4mxxnm9ifsi6-profile/bin/guild -> 
> /gnu/store/62hqgi4cac0f70v1ycsvv985fl3l1hzr-guile-next-2.1.7/bin/guild

Why does a relative path ./gnu/store/... point to an absolute path
/gnu/store/...?  I would have thought it would be "relative to
relative", or "absolute to absolute", not "relative to absolute".
Perhaps I'm missing something.

What is the expected method for extracting the tarball?  Can you 'cd' to
any directory and run a command like 'tar -xf the_file', or does the
current working directory have to be '/'?

> I’d like to move support for Docker (currently in ‘guix archive’) to
> this new command because I think it’s more appropriate: ‘guix archive’
> is supposed to be rather low-level so it would not create a profile, for
> instance.

My understanding is that one use case for this command is to make it
easy to deploy software (and the closure of its dependencies) using
Docker, in the case (maybe always? I'm not too familiar with Docker)
where you cannot run Guix inside of the Docker instance.  If you could
run Guix, I imagine you would not need this solution, since you could
just install it via the usual Guix mechanisms (e.g., 'guix package -i
foo').

Another use case seems to be specifically the creation of a tarball
containing Guix to enable a binary installation of it (you mentioned
that was the inspiration for this feature).

What other use cases do you imagine?  Is the intent to make it easy to
deploy software (and the closure of its dependencies) to any place where
you either can't or don't want to install Guix first?

> (define* (self-contained-tarball name profile
>  #:key deduplicate?)
>   "Return a self-contained tarball containing a store initialized with the
> closure of PROFILE, a derivation.  The tarball contains /gnu/store, /var/guix,
> and PROFILE is available as /root/.guix-profile."

Why is it necessary to include /var/guix?  I'm thinking about the case
where you're using this to package something other than Guix, e.g., some
other piece of software for deployment in a Docker instance.

>   ;; Note: there is not much to gain here with deduplication and
>   ;; there is the overhead of the '.links' directory, so turn it
>   ;; off.
>   (populate-single-profile-directory %root
>  #:profile #$profile
>  #:closure "profile"
>  #:deduplicate? #f)

When you say "there is not much to gain here," do you mean "it is
unlikely that duplication will occur"?  If so, why is that true?

-- 
Chris


signature.asc
Description: PGP signature

Re: [PATCH] gnu: cuirass: Update to 0.0.1 revision 5.

[Ludovic Courtès]

Mathieu Othacehe  skribis:

> * gnu/packages/ci.scm (cuirass): Update to 0.0.1 revision 5.

Applied, thanks!

Ludo'.

Re: core-updates: Python build failures

[Marius Bakke]

Leo Famulari  writes:

> On Fri, Mar 10, 2017 at 10:46:34PM +0100, Marius Bakke wrote:
>> It looks like Hydra ran out of entropy which caused a bunch of failures.
>> 
>> From the 'python-minimal' build:
>> 
>> if test "no" != "yes"; then \
>> ./Programs/_freeze_importlib \
>> ./Lib/importlib/_bootstrap_external.py Python/importlib_external.h; \
>> fi
>> Fatal Python error: getentropy() failed
>
> Python is not compatible with current versions of glibc on older Linux
> kernels (it builds fine for me on a recent kernel):
>
> Bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=1410175
>
> Discussion of a fix:
> https://bugs.python.org/issue29157
>
> I can't work on it today. Everyone else should feel free :)

I tried applying the upstream fix for 3.5:

https://hg.python.org/cpython/rev/337461574c90

However, the monster patch does not apply.

patching file Python/random.c
Hunk #2 succeeded at 39 (offset -1 lines).
Hunk #3 succeeded at 54 (offset -1 lines).
Hunk #4 succeeded at 65 (offset -1 lines).
Hunk #5 FAILED at 77.
Hunk #6 FAILED at 143.
Hunk #7 FAILED at 162.
Hunk #8 FAILED at 203.
Hunk #9 FAILED at 236.
Hunk #10 succeeded at 350 (offset -27 lines).
Hunk #11 succeeded at 374 (offset -27 lines).
Hunk #12 succeeded at 506 (offset -27 lines).
Hunk #13 succeeded at 525 (offset -27 lines).

Will try to dig out the other patches from 3.5 branch that this depends
on tomorrow. I can't reproduce the getentropy() failure either,
apparently it only occurs on kernels < 3.17.


signature.asc
Description: PGP signature

Re: Should synopsis handle texinfo markup?

[John Darrington]

On Sat, Mar 11, 2017 at 10:27:57PM +0300, Alex Kost wrote:
 Hello, I've noticed that several packages contain "@code" structures in
 their synopses, but only 'description' field supports texinfo markup.
 For example, look at:
 
   guix package -s ruby-minitest-bonus-assertions
 
 So I wonder, should these synopses be adjusted to remove @code things,
 or would it be better to make sysnopses support it?

... and, if we decide that synopses may not have Texinfo markup, then we
should have guix lint check for it.

J'

-- 
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] gnu: Add obnam.

[Marius Bakke]

Arun Isaac  writes:

>> I noticed this program and some of the libraries it uses, requires a
>> package called "CoverageTestRunner" to run unit tests. Currently tests
>> are simply skipped.
>
> I tried packaging the tests too. But, the tests require the root user
> and group to be present. The build environment does not have the root
> user and group. So, the tests fail. Can anything be done about this?

There is one user available in the build environment: "nobody". It could
work to substitute "root" for "nobody" in the code that looks for users.
The "mailutils" package does exactly that for tests. Can you try it?

TIA!


signature.asc
Description: PGP signature

Re: [PATCH 0/2] ImageMagick 7

[Leo Famulari]

On Wed, Jan 11, 2017 at 03:18:38PM -0500, Leo Famulari wrote:
> Hydra finished evaluating the imagemagick-updates branch on
> x86_64-linux:
> 
> https://hydra.gnu.org/eval/109433?full=1=master#tabs-now-fail
> 
> It's a surprisingly small number of failures! But, I wonder how many
> packages that use ImageMagick use the "command-line API" and actually
> test it.
> 
> So, I think we should carefully check each package that uses ImageMagick
> directly to see if they are ready. We can check their commit logs and
> bug trackers for anything related to ImageMagick.
> 
> It's a short list, and I'll start looking into a2ps and awesome:

Hydra is chronically low on disk space. We don't have the resources to
keep the historical substitutes for the imagemagick-updates branch's
jobset [0], which hasn't seen any activity in a couple months.

I'll delete the jobset in the next day or so unless there is more work
on this task.

Since the upstream maintainers will support ImageMagick 6 for at least
~9 more years, I think it's fine to stick with 6 while other distros
with more volunteer-power evaluate which packages are able to use the
new API.

[0]
https://hydra.gnu.org/jobset/gnu/imagemagick-updates


signature.asc
Description: PGP signature

core-updates: Python build failures

[Leo Famulari]

On Fri, Mar 10, 2017 at 10:46:34PM +0100, Marius Bakke wrote:
> It looks like Hydra ran out of entropy which caused a bunch of failures.
> 
> From the 'python-minimal' build:
> 
> if test "no" != "yes"; then \
> ./Programs/_freeze_importlib \
> ./Lib/importlib/_bootstrap_external.py Python/importlib_external.h; \
> fi
> Fatal Python error: getentropy() failed

Python is not compatible with current versions of glibc on older Linux
kernels (it builds fine for me on a recent kernel):

Bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1410175

Discussion of a fix:
https://bugs.python.org/issue29157

I can't work on it today. Everyone else should feel free :)


signature.asc
Description: PGP signature

Re: [PATCH] gnu: grep: Fix for gnulib library.

[rennes]

Hello Ludovic, Manolis,


Looks like we missed this ‘core-updates’ cycle.  :-/

To apply it without triggering a full rebuild, you could instead add a
phase that invokes ‘patch’ to apply it, only when the 
cross-compilation

target or system is GNU/Hurd.

Like:

  ,@(if (gnu/hurd?)
`((add-before 'configure 'patch …))
'())  ;nothing

Could you try that?


Even though this would work, maybe we should wait for the next
core-updates circle in order to avoid more (if (hurd)..) patches.



Yes, we can wait for the next cycle.

Re: [PATCH] gnu: grep: Fix for gnulib library.

[Manolis Ragkousis]

Hello Ludo,

On 03/11/2017 01:31 PM, Ludovic Courtès wrote:
> Hi!
> 
> ren...@openmailbox.org skribis:
> 
>> From f76585a44afdc41187df768eec79fb723713cf0c Mon Sep 17 00:00:00 2001
>> From: rennes 
>> Date: Tue, 21 Feb 2017 23:21:49 -0600
>> Subject: [PATCH] gnu: grep: Fix for gnulib library.
>>
>> * gnu/packages/patches/grep-gnulib-lock.patch: New file. 
>>  
>> * gnu/local.mk (dist_patch_DATA): Add it.
> 
> Looks like we missed this ‘core-updates’ cycle.  :-/
> 
> To apply it without triggering a full rebuild, you could instead add a
> phase that invokes ‘patch’ to apply it, only when the cross-compilation
> target or system is GNU/Hurd.
> 
> Like:
> 
>   ,@(if (gnu/hurd?)
> `((add-before 'configure 'patch …))
> '())  ;nothing
> 
> Could you try that?

Even though this would work, maybe we should wait for the next
core-updates circle in order to avoid more (if (hurd)..) patches.

Rene WDYT?

Manolis

Re: [PATCH] gnu: Add emacs-memoize.

[Arun Isaac]

> Please email guix-patc...@gnu.org for future patches (info "(guix)
> Submitting Patches").

Sure! I didn't realize the patch submission mailing list had changed.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add ghc-unexceptionalio.

[Ludovic Courtès]

rsiddharth  skribis:

> * gnu/packages/haskell.scm (ghc-unexceptionalio): New variable.

Pushed, thank you!

Ludo’.

Re: bug#24544: 2.1.4 tarball install fails on GuixSD

[Ludovic Courtès]

Andy Wingo  skribis:

> On Sun 25 Sep 2016 21:22, Jan Nieuwenhuizen  writes:
>
>> ld-wrapper: error: attempt to use impure library 
>> "/home/janneke/guile-2.1.4/lib/libguile-2.2.so"
>> collect2: error: ld returned 1 exit status
>> libtool:   error: error: relink 'guile-readline.la' with the above 
>> command before installing it
>
> This is because Guix is silly and thinks that even when you are
> installing to /rando/prefix/that/you/like that it's bad to link to
> thinks outside /gnu/store.
>
> The workaround is to export GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yesplease.
> (Actually any value.)
>
> The real fix is to prevent ld-wrapper from carping for normal installs
> to non-store prefixen!

Do you mean we should change the default?  That is,
GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yes by default, and gnu-build-system
would set it to “no”.

Ludo’.

Re: [PATCH] gnu: grep: Fix for gnulib library.

[Ludovic Courtès]

Hi!

ren...@openmailbox.org skribis:

> From f76585a44afdc41187df768eec79fb723713cf0c Mon Sep 17 00:00:00 2001
> From: rennes 
> Date: Tue, 21 Feb 2017 23:21:49 -0600
> Subject: [PATCH] gnu: grep: Fix for gnulib library.
>
> * gnu/packages/patches/grep-gnulib-lock.patch: New file.  
> 
> * gnu/local.mk (dist_patch_DATA): Add it.

Looks like we missed this ‘core-updates’ cycle.  :-/

To apply it without triggering a full rebuild, you could instead add a
phase that invokes ‘patch’ to apply it, only when the cross-compilation
target or system is GNU/Hurd.

Like:

  ,@(if (gnu/hurd?)
`((add-before 'configure 'patch …))
'())  ;nothing

Could you try that?

Also please avoid reindenting the package at the same time as it makes
the patch a bit noisier.  :-)

Thanks,
Ludo’.

Re: [PATCH 1/2] build: Use an up to date copy of texinfo.tex

[Ludovic Courtès]

John Darrington  skribis:

> * build-aux/texinfo.tex,ref: New file, copied from texlive-minimal
> * bootstrap: Use it, if newer than the texinfo.tex from automake.

Sorry for the delay.

I think we should not add texinfo.tex to our repo.  As you discussed in
the rest of the thread, it’s supposed to be copied by “automake -a”, so
we might want to wait for a new Automake release.

Also, the canonical source for texinfo.texi is Texinfo, not TeX Live.

Ludo’.

Re: [PATCH] services: dovecot: Fix unix_listeners and fifo_listeners path types.

[Ludovic Courtès]

Hi Clément,

Clément Lassieur  skribis:

>>> Well, maybe here "lmtp" is not the section name, but the path, relative
>>> to "base_dir".  Sould I update the documentation to specify that "path"
>>> may be relative to "base_dir" too?
>>
>> Sure, anyway patch LGTM.  Thanks for taking the time to explain.
>
> My pleasure!  Here is the new version, with updated documentation:
> http://lists.gnu.org/archive/html/guix-devel/2017-02/msg01112.html

Given that Andy okayed the patch, I think you should go ahead and push it!

Thanks,
Ludo’.

Re: Dealing with CVEs that apply to unspecified package versions

[Ludovic Courtès]

Leo Famulari  skribis:

> On Mon, Mar 06, 2017 at 10:36:48PM +0100, Ludovic Courtès wrote:
>> Unfortunately, there’s no way to know whether such CVEs are actually
>> fixed at a specific package version or not, and they’re not uncommon.
>> Consequently, ‘guix lint -c cve’ would now report old CVEs that possibly
>> no longer apply to our package versions.
>
> I didn't notice any change in what the CVE checker reports after
> applying the diff. Did I miss a step?

You need to first clear your cache:

  rm -rf ~/.cache/guix/cve

Here’s the before/after diff I get:

--- /home/ludo/src/guix/cve-before.txt	2017-03-11 12:01:57.908151863 +0100
+++ /home/ludo/src/guix/cve-after.txt	2017-03-11 12:04:24.283399193 +0100
@@ -1,20 +1,42 @@
+gnu/packages/tls.scm:218:2: gnutls@3.5.8: probably vulnerable to CVE-2014-3467, CVE-2014-3468, CVE-2014-3469
 gnu/packages/backup.scm:186:2: libarchive@3.2.1: probably vulnerable to CVE-2016-8687, CVE-2016-8688, CVE-2016-8689
-gnu/packages/base.scm:754:2: glibc@2.23: probably vulnerable to CVE-2016-3075, CVE-2016-5417
-gnu/packages/base.scm:502:2: glibc@2.24: probably vulnerable to CVE-2016-6323
-gnu/packages/base.scm:788:2: glibc@2.21: probably vulnerable to CVE-2015-1781, CVE-2015-7547, CVE-2014-7817, CVE-2014-8121
+gnu/packages/base.scm:278:2: coreutils@8.25: probably vulnerable to CVE-2014-9471
+gnu/packages/base.scm:767:2: glibc@2.22: probably vulnerable to CVE-2016-3706, CVE-2016-4429, CVE-2015-7547, CVE-2015-8776, CVE-2015-8777, CVE-2015-8778, CVE-2015-8779, CVE-2014-5119, CVE-2014-9761
+gnu/packages/base.scm:789:2: glibc@2.21: probably vulnerable to CVE-2016-3706, CVE-2016-4429, CVE-2015-1781, CVE-2015-7547, CVE-2014-5119, CVE-2014-7817, CVE-2014-8121
 gnu/packages/base.scm:155:2: tar@1.29: probably vulnerable to CVE-2016-6321
-gnu/packages/base.scm:766:2: glibc@2.22: probably vulnerable to CVE-2015-7547, CVE-2015-8776, CVE-2015-8777, CVE-2015-8778, CVE-2015-8779, CVE-2014-9761
+gnu/packages/base.scm:503:2: glibc@2.24: probably vulnerable to CVE-2016-3706, CVE-2016-4429, CVE-2016-6323, CVE-2014-5119
+gnu/packages/base.scm:755:2: glibc@2.23: probably vulnerable to CVE-2016-3075, CVE-2016-3706, CVE-2016-4429, CVE-2016-5417, CVE-2014-5119
+gnu/packages/bash.scm:269:2: bash@4.4.A: probably vulnerable to CVE-2016-9401
+gnu/packages/busybox.scm:31:2: busybox@1.26.0: probably vulnerable to CVE-2016-6301
 gnu/packages/compression.scm:210:4: bzip2@1.0.6: probably vulnerable to CVE-2016-3189
-gnu/packages/image.scm:296:2: libtiff@4.0.7: probably vulnerable to CVE-2017-5563, CVE-2016-10095
-gnu/packages/image.scm:487:2: openjpeg@2.1.2: probably vulnerable to CVE-2016-9112, CVE-2016-9113, CVE-2016-9114, CVE-2016-9115, CVE-2016-9116, CVE-2016-9117, CVE-2016-9118
+gnu/packages/databases.scm:329:2: mariadb@10.1.21: probably vulnerable to CVE-2016-6664
+gnu/packages/databases.scm:720:2: sqlite@3.15.1: probably vulnerable to CVE-2015-3717
+gnu/packages/databases.scm:254:2: mysql@5.7.17: probably vulnerable to CVE-2014-0001
+gnu/packages/databases.scm:666:2: sqlite@3.14.1: probably vulnerable to CVE-2015-3717
+gnu/packages/gcc.scm:410:2: libiberty@4.9.4: probably vulnerable to CVE-2016-2226, CVE-2016-4487, CVE-2016-4488, CVE-2016-4489, CVE-2016-4490, CVE-2016-4491, CVE-2016-4492, CVE-2016-4493
+gnu/packages/ghostscript.scm:64:2: lcms@2.6: probably vulnerable to CVE-2016-10165
+gnu/packages/gnome.scm:5393:4: byzanz@0.2-1.f7af3a5: probably vulnerable to CVE-2015-2785
+gnu/packages/gstreamer.scm:99:2: gstreamer@1.10.4: probably vulnerable to CVE-2017-5847, CVE-2017-5848, CVE-2016-9446
+gnu/packages/image.scm:487:2: openjpeg@2.1.2: probably vulnerable to CVE-2016-7163, CVE-2016-9112, CVE-2016-9113, CVE-2016-9114, CVE-2016-9115, CVE-2016-9116, CVE-2016-9117, CVE-2016-9118, CVE-2016-9675
+gnu/packages/image.scm:296:2: libtiff@4.0.7: probably vulnerable to CVE-2017-5563, CVE-2016-10095, CVE-2016-9453, CVE-2015-8781, CVE-2015-8782, CVE-2015-8783, CVE-2015-8784
+gnu/packages/image.scm:505:2: openjpeg@1.5.2: probably vulnerable to CVE-2016-7163, CVE-2016-9675
+gnu/packages/linux.scm:3063:2: ecryptfs-utils@111: probably vulnerable to CVE-2016-1572
+gnu/packages/lynx.scm:35:2: lynx@2.8.9dev.11: probably vulnerable to CVE-2016-9179
 gnu/packages/mail.scm:1081:2: dovecot@2.2.27: probably vulnerable to CVE-2016-8652
 gnu/packages/monitoring.scm:34:2: nagios@4.2.4: probably vulnerable to CVE-2016-10089
 gnu/packages/mp3.scm:231:2: libmp3splt@0.9.2: probably vulnerable to CVE-2017-5665
 gnu/packages/mp3.scm:264:2: mp3splt@2.6.2: probably vulnerable to CVE-2017-5666, CVE-2017-5851
+gnu/packages/openldap.scm:36:2: openldap@2.4.44: probably vulnerable to CVE-2015-3276
 gnu/packages/perl.scm:50:2: perl@5.24.0: probably vulnerable to CVE-2016-1238
-gnu/packages/php.scm:65:2: php@7.0.14: probably vulnerable to CVE-2017-5340, CVE-2016-10158, CVE-2016-10159, CVE-2016-10160, CVE-2016-10161, CVE-2016-10162, CVE-2016-7479
+gnu/packages/php.scm:65:2: php@7.0.14: probably vulnerable to CVE-2017-5340, 

Re: MMMMM

[ng0]

Pjotr Prins transcribed 0.1K bytes:
> Only one way and that is up :)
> 
> Pj.
> 

To quote B. Lightyear (or Woody?):

"To infinity and beyond!"

--
ng0 - who's currently documenting all the processes for people to get
involved in the specialized blend of GuixSD, so more packages will be
upstreamed in the future. More on it and announcement email in ~2 - 3
weeks when the server is ready.

Re: Leaving the guix project

[ng0]

Ludovic Courtès transcribed 1.6K bytes:
[…] 
> Perhaps you take hardware support in GNU/Linux for granted.  When I
> started using GNU/Linux, things like sound support or graphics mode
> support or webcams would often be missing—things were a lot more
> difficult in practice.  It’s the dedicated work of volunteers that
> brought us drivers for all this.

I remember the struggle of getting wifi to work on Zenwalk with no
easy internet access to search for what works and what doesn't, and the
support was super limited in the late 90s / early 2000s.
What we have in 2017 is a mountain of resources, yet I still hope for
intel to become supported out of the box in -libre, some support for AC
wifi, etc.

I like your decision to work closer on hardware, David. If I had the
personal resources for it, I'd work my way towards it aswell.
I wish you all the best for your new efforts and projects, maybe our
paths cross again in this small world of hacking.

[…]
> Ludo’.
> 

Re: [PATCH] gnu: Add emacs-memoize.

[Ludovic Courtès]

Arun Isaac  skribis:

> * gnu/packages/emacs.scm (emacs-memoize): New variable.

Applied, thanks!

Please email guix-patc...@gnu.org for future patches (info "(guix)
Submitting Patches").

Ludo’.

Re: MMMMM

[Pjotr Prins]

Only one way and that is up :)

Pj.