Re: [PATCH] DRAFT: gnu: icecat: Update to 52.0.2-gnu1; add fixes from ESR 52.1.

[Mark H Weaver]

Mark H Weaver  writes:

> Mark H Weaver  writes:
>> Here's a draft patch to update GNU IceCat to 52.0.2-gnu1, with
>> additional fixes cherry-picked from upstream ESR 52.1.  It seems to work
>> well on my system, except that my GNOME 3 session has locked up a couple
>> of times while testing it[*].
>
> I built a slightly modified version of this package with 'libnotify'
> support removed (removing it from both 'inputs' and from the
> 'arrange-to-link-libxul-with-libraries-it-might-dlopen' phase), and also
> attempting (but failing) to downgrade to gtk+-2.  The resulting IceCat
> still uses gtk+-3, but so far it has not locked up my GNOME session.
>
> My hypothesis is that when 'libnotify' support is enabled, somehow a bug
> in gnome-shell is triggered.

My experiments so far seem to support this hypothesis.  Since removing
'libnotify' support, I've had no problems with IceCat 52 in GNOME 3.

I've now pushed the IceCat 52 update to master, along with the related
security updates for NSS and Graphite2.

  Mark

Re: [PATCH] Makefile.am: add a target that lists patches no longer used

[Eric Bavier]

On Thu, 20 Apr 2017 15:15:46 -0400
Leo Famulari  wrote:

> On Tue, May 19, 2015 at 01:34:10AM +0200, Cyril Roelandt wrote:
> > * list-useless-patches.sh: New file.
> > * Makefile.am (check-for-useless-patches): New target.  
> 
> We should make use of this somehow!

Attached is my own shot at this.  It does not make use of git, so
should be fine as a regular test.  It doesn't check whether the files
listed in dist_patch_DATA actually exist, because `make dist` already
checks that.  I suppose it might be nice, if git a git checkout, to
check whether the used patches are all known to git...

Anyhow, currently the test fails with the following log output:

---BEGIN test-suite.log
FAIL: tests/patches
===

test-name: distributed patches are used
location: /home/bavier/projects/guix/tests/patches.scm:50
source:
+ (test-equal
+   "distributed patches are used"
+   '()
+   (lset-difference
+ string=?
+ distributed-patches
+ used-patches))
expected-value: ()
actual-value: 
("/home/bavier/projects/guix/gnu/packages/patches/ath9k-htc-firmware-binutils.patch"
 "/home/bavier/projects/guix/gnu/packages/patches/ath9k-htc-firmware-gcc.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/coreutils-cut-huge-range-test.patch"
 "/home/bavier/projects/guix/gnu/packages/patches/gawk-shell.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/gcc-libiberty-printf-decl.patch"
 
"/home/bavier/projects/guix/gnu/packages/patches/gcc-4.9.3-mingw-gthr-default.patch"
 "/home/bavier/projects/guix/gnu/packages/patches/gcj-arm-mode.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/glibc-bootstrap-system.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/grub-CVE-2015-8370.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/grub-gets-undeclared.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/grub-freetype.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/guile-arm-fixes.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/icu4c-CVE-2017-7867-CVE-2017-7868.patch"
 
"/home/bavier/projects/guix/gnu/packages/patches/icu4c-reset-keyword-list-iterator.patch"
 "/home/bavier/projects/guix/gnu/packages/patches/ldc-disable-tests.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/ldc-1.1.0-disable-dmd-tests.patch"
 
"/home/bavier/projects/guix/gnu/packages/patches/ldc-1.1.0-disable-phobos-tests.patch"
 "/home/bavier/projects/guix/gnu/packages/patches/libgit2-use-after-free.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/libxslt-CVE-2016-4738.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/mplayer2-theora-fix.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/patchelf-rework-for-arm.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/pcre-CVE-2017-7186.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/perl-net-ssleay-disable-ede-test.patch"
 "/home/bavier/projects/guix/gnu/packages/patches/readline-7.0-mingw.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/soprano-find-clucene.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch"
 
"/home/bavier/projects/guix/gnu/packages/patches/util-linux-CVE-2017-2616.patch"
 
"/home/bavier/projects/guix/gnu/packages/patches/xf86-video-ast-remove-mibstore.patch"
 
"/home/bavier/projects/guix/gnu/packages/patches/xf86-video-intel-compat-api.patch"
 
"/home/bavier/projects/guix/gnu/packages/patches/xf86-video-intel-glibc-2.20.patch")
result: FAIL

test-name: used patches are distributed
location: /home/bavier/projects/guix/tests/patches.scm:54
source:
+ (test-equal
+   "used patches are distributed"
+   '()
+   (lset-difference
+ string=?
+ used-patches
+ distributed-patches))
expected-value: ()
actual-value: 
("/home/bavier/projects/guix/gnu/packages/patches/python-pbr-fix-man-page-support.patch"
 "/home/bavier/projects/guix/gnu/packages/patches/jacal-fix-texinfo.patch" 
"/home/bavier/projects/guix/gnu/packages/patches/vsearch-unbundle-cityhash.patch"
 
"/home/bavier/projects/guix/gnu/packages/patches/hmmer-remove-cpu-specificity.patch")
result: FAIL
--END test-suite.log-
From 751f10e180994db6c0df722c2b226e174d3b7a28 Mon Sep 17 00:00:00 2001
From: Eric Bavier 
Date: Thu, 20 Apr 2017 23:17:14 -0500
Subject: [PATCH] tests: Add patch use test.

* tests/patches.scm: New test.
* Makefile.am (SCM_TESTS): Add it.
(AM_TESTS_ENVIRONMENT): Export dist_patch_DATA.
---
 Makefile.am   |  8 ++--
 tests/patches.scm | 54 ++
 2 files changed, 60 insertions(+), 2 deletions(-)
 create mode 100644 tests/patches.scm

diff --git a/Makefile.am b/Makefile.am
index a997ed8b9..5cd9be814 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -307,7 +307,8 @@ SCM_TESTS =	\
   tests/scripts-build.scm			\
   tests/containers.scm\
   tests/pack.scm\
-  tests/import-utils.scm
+  tests/import-utils.scm			\
+  

Re: 01/02: gnu: qemu: Update to 2.9.0 [security fixes].

[Mark H Weaver]

l...@famulari.name (Leo Famulari) writes:

> lfam pushed a commit to branch master
> in repository guix.
>
> commit dfa663c963a7c0745f18cbfab4b45eb335742602
> Author: Leo Famulari 
> Date:   Fri Apr 7 09:03:28 2017 -0400
>
> gnu: qemu: Update to 2.9.0 [security fixes].
> 
> Fixes CVE-2017-{5857,5973,5987,6058,6505,7377,7471,7718}.

Thanks for this!  Obviously it's an important security update, but:

On my x86_64 system running GuixSD, 'grub' now fails to build from
source.  Three times in a row, the 'grub_cmd_set_date' has failed.
Here's the relevant excerpt from test-suite.log (lightly formatted):

  FAIL: grub_cmd_set_date
  ===
  
  qemu-system-i386: Trying to execute code outside RAM or ROM at 0xef53
  This usually means one of the following happened:
  
  (1) You told QEMU to execute a kernel for the wrong machine type, and
  it crashed on startup (eg trying to run a raspberry pi kernel on a
  versatilepb QEMU machine)
  
  (2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU
  executed a ROM full of no-op instructions until it fell off the end
  
  (3) Your guest kernel has a bug and crashed by jumping off into nowhere
  
  This is almost always one of the first two, so check your command line
  and that you are using the right type of kernel for this machine.
  If you think option (3) is likely then you can try debugging your
  guest with the -d debug options; in particular -d guest_errors will
  cause the log to include a dump of the guest register state at this
  point.
  
  Execution cannot continue; stopping here.
  
  Test failed: 2017-04-21 00:08:44 Friday

The build appears to have succeeded on Hydra:

  https://hydra.gnu.org/eval/109616?filter=grub

Unfortunately the substitute is not yet available, so for the moment I'm
stuck.  I'll look into disabling this test for now.

Has anyone else seen this?

  Mark

Re: [PATCH] DRAFT: gnu: icecat: Update to 52.0.2-gnu1; add fixes from ESR 52.1.

[Mark H Weaver]

Mark H Weaver  writes:
> Here's a draft patch to update GNU IceCat to 52.0.2-gnu1, with
> additional fixes cherry-picked from upstream ESR 52.1.  It seems to work
> well on my system, except that my GNOME 3 session has locked up a couple
> of times while testing it[*].

I built a slightly modified version of this package with 'libnotify'
support removed (removing it from both 'inputs' and from the
'arrange-to-link-libxul-with-libraries-it-might-dlopen' phase), and also
attempting (but failing) to downgrade to gtk+-2.  The resulting IceCat
still uses gtk+-3, but so far it has not locked up my GNOME session.

My hypothesis is that when 'libnotify' support is enabled, somehow a bug
in gnome-shell is triggered.

  Mark

[PATCHES] gnu: nss: Update to 3.30.2 [fixes CVE-2017-5461].

[Mark H Weaver]

These patches update nss to 3.30.2 and disable long b64 tests which fail
on some systems including armhf.  I'll push them soon after some light
testing.

 Mark


From c1ba9c385a23ede10cb5e79c24f66dbb86c1f6fe Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Thu, 20 Apr 2017 14:55:31 -0400
Subject: [PATCH 1/2] gnu: nss: Update to 3.30.2 [fixes CVE-2017-5461].

* gnu/packages/gnuzilla.scm (nss): Update to 3.30.2.
---
 gnu/packages/gnuzilla.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index 87695329c..59f790a6e 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -194,7 +194,7 @@ in the Mozilla clients.")
 (define-public nss
   (package
 (name "nss")
-(version "3.30")
+(version "3.30.2")
 (source (origin
   (method url-fetch)
   (uri (let ((version-with-underscores
@@ -205,7 +205,7 @@ in the Mozilla clients.")
   "nss-" version ".tar.gz")))
   (sha256
(base32
-"1agkkwb51si4raw46p44vl3d0l7wzvdjcblpcdjjz6aymq6h1h58"))
+"096frzvyp3z257x84rxknscfgsbavzh2a0gyibx7kvmw4vzpfjhd"))
   ;; Create nss.pc and nss-config.
   (patches (search-patches "nss-pkgconfig.patch"
"nss-increase-test-timeout.patch"
-- 
2.12.2

From e07aa7534aa97617ce15fa07c244dc6f901af92f Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Thu, 20 Apr 2017 17:42:52 -0400
Subject: [PATCH 2/2] gnu: nss: Disable long b64 tests.

Suggested by Marius Bakke  in
.

* gnu/packages/patches/nss-disable-long-b64-tests.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/gnuzilla.scm (nss)[source]: Add patch.
---
 gnu/local.mk   |  1 +
 gnu/packages/gnuzilla.scm  |  1 +
 .../patches/nss-disable-long-b64-tests.patch   | 34 ++
 3 files changed, 36 insertions(+)
 create mode 100644 gnu/packages/patches/nss-disable-long-b64-tests.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index ec27e8765..ed3683f19 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -814,6 +814,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/ngircd-handle-zombies.patch		\
   %D%/packages/patches/ninja-zero-mtime.patch			\
   %D%/packages/patches/node-9077.patch\
+  %D%/packages/patches/nss-disable-long-b64-tests.patch		\
   %D%/packages/patches/nss-increase-test-timeout.patch		\
   %D%/packages/patches/nss-pkgconfig.patch			\
   %D%/packages/patches/ntfs-3g-CVE-2017-0358.patch		\
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index 59f790a6e..fd058d022 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -208,6 +208,7 @@ in the Mozilla clients.")
 "096frzvyp3z257x84rxknscfgsbavzh2a0gyibx7kvmw4vzpfjhd"))
   ;; Create nss.pc and nss-config.
   (patches (search-patches "nss-pkgconfig.patch"
+   "nss-disable-long-b64-tests.patch"
"nss-increase-test-timeout.patch"
 (build-system gnu-build-system)
 (outputs '("out" "bin"))
diff --git a/gnu/packages/patches/nss-disable-long-b64-tests.patch b/gnu/packages/patches/nss-disable-long-b64-tests.patch
new file mode 100644
index 0..612d94128
--- /dev/null
+++ b/gnu/packages/patches/nss-disable-long-b64-tests.patch
@@ -0,0 +1,34 @@
+Disable long b64 tests, which consistently fail on armhf.
+This is based on an excerpt of the following upstream patch:
+
+  https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7
+
+(we exclude the part of the upstream patch that reverts
+an earlier failed attempt, and adapt the file names)
+
+diff --git a/gtests/util_gtest/util_b64_unittest.cc b/gtests/util_gtest/util_b64_unittest.cc
+--- a/nss/gtests/util_gtest/util_b64_unittest.cc
 b/nss/gtests/util_gtest/util_b64_unittest.cc
+@@ -63,17 +63,19 @@ TEST_F(B64EncodeDecodeTest, EncDecTest) 
+ 
+ TEST_F(B64EncodeDecodeTest, FakeDecTest) { EXPECT_TRUE(TestFakeDecode(100)); }
+ 
+ TEST_F(B64EncodeDecodeTest, FakeEncDecTest) {
+   EXPECT_TRUE(TestFakeEncode(100));
+ }
+ 
+ // These takes a while ...
+-TEST_F(B64EncodeDecodeTest, LongFakeDecTest1) {
++TEST_F(B64EncodeDecodeTest, DISABLED_LongFakeDecTest1) {
+   EXPECT_TRUE(TestFakeDecode(0x));
+ }
+-TEST_F(B64EncodeDecodeTest, LongFakeEncDecTest1) { TestFakeEncode(0x3fff); }
+-TEST_F(B64EncodeDecodeTest, LongFakeEncDecTest2) {
++TEST_F(B64EncodeDecodeTest, DISABLED_LongFakeEncDecTest1) {
++  TestFakeEncode(0x3fff);
++}
++TEST_F(B64EncodeDecodeTest, DISABLED_LongFakeEncDecTest2) {
+   EXPECT_FALSE(TestFakeEncode(0x4000));
+ }
+ 
+ }  // namespace nss_test
-- 
2.12.2



signature.asc
Description: PGP signature

[PATCH] gnu: graphite2: Add fixes for CVE-2017-5436 and other bugs

[Mark H Weaver]

This adds selected fixes for graphite2 from the upstream repository,
including a fix for CVE-2017-5436.  I intend to push it soon, after some
light testing on my system.

 Mark


From 302e0815aab8ebe889872a260645bf7c886bf147 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Thu, 20 Apr 2017 15:10:54 -0400
Subject: [PATCH] gnu: graphite2: Add fixes for CVE-2017-5436 and other bugs.

* gnu/packages/fontutils.scm (graphite2)[replacement]: New field.
(graphite2/fixed): New variable.
* gnu/packages/patches/graphite2-CVE-2017-5436.patch,
gnu/packages/patches/graphite2-check-code-point-limit.patch,
gnu/packages/patches/graphite2-fix-32-bit-wrap-arounds.patch,
gnu/packages/patches/graphite2-non-linear-classes-even-number.patch:
New files.
* gnu/local.mk (dist_patch_DATA): Add them.
---
 gnu/local.mk   |  4 +
 gnu/packages/fontutils.scm | 22 +
 gnu/packages/patches/graphite2-CVE-2017-5436.patch | 25 ++
 .../patches/graphite2-check-code-point-limit.patch | 50 
 .../graphite2-fix-32-bit-wrap-arounds.patch| 93 ++
 .../graphite2-non-linear-classes-even-number.patch | 26 ++
 6 files changed, 220 insertions(+)
 create mode 100644 gnu/packages/patches/graphite2-CVE-2017-5436.patch
 create mode 100644 gnu/packages/patches/graphite2-check-code-point-limit.patch
 create mode 100644 gnu/packages/patches/graphite2-fix-32-bit-wrap-arounds.patch
 create mode 100644 gnu/packages/patches/graphite2-non-linear-classes-even-number.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 1fe24038d..ec27e8765 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -625,7 +625,11 @@ dist_patch_DATA =		\
   %D%/packages/patches/gobject-introspection-absolute-shlib-path.patch \
   %D%/packages/patches/gobject-introspection-cc.patch		\
   %D%/packages/patches/gobject-introspection-girepository.patch	\
+  %D%/packages/patches/graphite2-CVE-2017-5436.patch		\
+  %D%/packages/patches/graphite2-check-code-point-limit.patch	\
   %D%/packages/patches/graphite2-ffloat-store.patch		\
+  %D%/packages/patches/graphite2-fix-32-bit-wrap-arounds.patch	\
+  %D%/packages/patches/graphite2-non-linear-classes-even-number.patch \
   %D%/packages/patches/grep-timing-sensitive-test.patch		\
   %D%/packages/patches/grub-CVE-2015-8370.patch			\
   %D%/packages/patches/grub-gets-undeclared.patch		\
diff --git a/gnu/packages/fontutils.scm b/gnu/packages/fontutils.scm
index 7e7234960..cc6d1df59 100644
--- a/gnu/packages/fontutils.scm
+++ b/gnu/packages/fontutils.scm
@@ -376,6 +376,7 @@ applications should be.")
   (package
(name "graphite2")
(version "1.3.9")
+   (replacement graphite2/fixed)
(source
  (origin
(method url-fetch)
@@ -400,6 +401,27 @@ and returns a sequence of positioned glyphids from the font.")
(license license:lgpl2.1+)
(home-page "https://github.com/silnrsi/graphite;)))
 
+(define graphite2/fixed
+  (package
+(inherit graphite2)
+(name "graphite2")
+(version "1.3.9")
+(replacement #f)
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://github.com/silnrsi/graphite/releases/;
+   "download/" version "/" name "-" version ".tgz"))
+   (patches (search-patches
+ "graphite2-ffloat-store.patch"
+ "graphite2-check-code-point-limit.patch"
+ "graphite2-CVE-2017-5436.patch"
+ "graphite2-fix-32-bit-wrap-arounds.patch"
+ "graphite2-non-linear-classes-even-number.patch"))
+   (sha256
+(base32
+ "0rs5h7m340z75kygx8d72cps0q6yvvqa9i788vym7585cfv8a0gc"))
+
 (define-public potrace
   (package
 (name "potrace")
diff --git a/gnu/packages/patches/graphite2-CVE-2017-5436.patch b/gnu/packages/patches/graphite2-CVE-2017-5436.patch
new file mode 100644
index 0..d7383ec8d
--- /dev/null
+++ b/gnu/packages/patches/graphite2-CVE-2017-5436.patch
@@ -0,0 +1,25 @@
+From 1ce331d5548b98ed8b818532b2556d6f2c7a3b83 Mon Sep 17 00:00:00 2001
+From: Martin Hosken 
+Date: Thu, 9 Mar 2017 22:04:04 +
+Subject: [PATCH] Ensure features have enough space. Fix from Mozilla
+
+---
+ src/FeatureMap.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/FeatureMap.cpp b/src/FeatureMap.cpp
+index b8c8405..83bd5f6 100644
+--- a/src/FeatureMap.cpp
 b/src/FeatureMap.cpp
+@@ -275,7 +275,7 @@ bool FeatureRef::applyValToFeature(uint32 val, Features & pDest) const
+ else
+   if (pDest.m_pMap!=_pFace->theSill().theFeatureMap())
+ return false;   //incompatible
+-pDest.reserve(m_index);
++pDest.reserve(m_index+1);
+ pDest[m_index] &= ~m_mask;
+ pDest[m_index] |= (uint32(val) << m_bits);
+ return true;
+-- 
+2.12.2
+
diff --git a/gnu/packages/patches/graphite2-check-code-point-limit.patch b/gnu/packages/patches/graphite2-check-code-point-limit.patch
new file 

Re: NSS test failure on armhf

[Marius Bakke]

Mark H Weaver  writes:

> Marius Bakke  writes:
>
>> Marius Bakke  writes:
>>
> It turns out that the bug fix in 3.30.1 is critical: it fixes
> CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
> has since been released, so I'm currently testing it and will push an
> update to it soon.  Any issues on armhf will need to be dealt with in
> another way.

 Mark,

 I checked this. The upstream 3.30 branch[0] contains a fix, but it was
 not picked to the 3.30.2 release which only contains certificate
 changes[1].

 Squashing these two commits into one should fix the problem (the first
 fix was incomplete[2]):

 https://hg.mozilla.org/projects/nss/rev/802ec96a8dd1
 https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7
>
> Good find, thank you!  Since seeing the above post, I prepared my own
> patches to update NSS to 3.30.2 and disable the long b64 tests.
>
> And now I see you've prepared your own patch that only updates to
> 3.30.1.  I'm not sure why we would consider rebuilding everything with
> 3.30.1 when 3.30.2 already exists, even if the only changes are to
> certs.
>
> I'll push this batch of patches soon, including fixes to graphite2 and
> the icecat update, after a bit more testing.

Great, thanks! I could not find any compelling reason to use the 3.30.2
tarball (other than disk space on builders), and found the version
"mismatch" with between 'nss-certs' and 'nss' more distinctive.

However, after diffing 3.30.1 and 3.30.2, it seems certificate changes
also bump the library version:

https://hg.mozilla.org/projects/nss/diff/dc97a4930479/lib/ckfw/builtins/nssckbi.h

So I guess we should keep updating these together to the extent possible.


signature.asc
Description: PGP signature

Re: ld-wrapper is broken in core-updates due to guile-2.2 (host running guile-2.0)

[Ludovic Courtès]

Hello,

Sergei Trofimovich  skribis:

> Efraim noticed core-updates breakage on package libgpg-error.
>
> TL;DR:
>
>   ld-wrapper package embeds guile-2.2 interpreter
>   to interpret ld.go bytecode built by guile-2.0.
>   I have no idea how to fix it but still decided to
>   share my findings so far.
>
> Longer story:

[...]

> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/base.scm#n458
>
> (define* (make-ld-wrapper name #:key
>   (target (const #f))
>   binutils
>   (guile (canonical-package guile-2.0))
>   (bash (canonical-package bash))
>   (guile-for-build guile))
> ...
> (arguments
>  (let ((target (target (%current-system
>`(#:guile ,guile-for-build
>  #:modules ((guix build utils))
>  #:builder (begin
> ...
>(chmod ld #o555)
>(compile-file ld #:output-file go))
>
> Which guile is being used here for compile-file? 'build-for-build'
> or current host's guile? Looks like the requirement here is that
> both mush be of the same version.

Indeed, good catch!  You were on the right track.

I believe this is fixed by this commit:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates=78dea6f1d4a85dd9571ccbd604239912ba3a18b8

The problem here is that ‘ld-wrapper’ in commencement.scm was defined in
such a way that #:guile and #:guile-for-build did not match, so we ended
up compiling with 2.0 (%bootstrap-guile) and running with 2.2
(guile-final).

Thank you!

Ludo’.

Re: NSS test failure on armhf

[Mark H Weaver]

Marius Bakke  writes:

> Marius Bakke  writes:
>
 It turns out that the bug fix in 3.30.1 is critical: it fixes
 CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
 has since been released, so I'm currently testing it and will push an
 update to it soon.  Any issues on armhf will need to be dealt with in
 another way.
>>>
>>> Mark,
>>>
>>> I checked this. The upstream 3.30 branch[0] contains a fix, but it was
>>> not picked to the 3.30.2 release which only contains certificate
>>> changes[1].
>>>
>>> Squashing these two commits into one should fix the problem (the first
>>> fix was incomplete[2]):
>>>
>>> https://hg.mozilla.org/projects/nss/rev/802ec96a8dd1
>>> https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7

Good find, thank you!  Since seeing the above post, I prepared my own
patches to update NSS to 3.30.2 and disable the long b64 tests.

And now I see you've prepared your own patch that only updates to
3.30.1.  I'm not sure why we would consider rebuilding everything with
3.30.1 when 3.30.2 already exists, even if the only changes are to
certs.

I'll push this batch of patches soon, including fixes to graphite2 and
the icecat update, after a bit more testing.

 Thanks!
   Mark

[sr #109299] Creating a 'cuirass' Git repository for Guix

[Assaf Gordon]

Update of sr #109299 (project administration):

  Status:None => Done   
 Assigned to:None => agn
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

done.


Anonymous git access:
  git clone git://git.sv.nongnu.org/guix/guix-cuirass.git

Read/Write Access:
  git clone @git.sv.nongnu.org:/srv/git/guix/guix-cuirass.git

Web Access:
  http://git.sv.nongnu.org/cgit/guix/guix-cuirass.git
  http://git.sv.nongnu.org/gitweb/?p=guix/guix-cuirass.git

sub-repository 'guix-cuirass.git' created.

Anonymous git access:
  git clone git://git.sv.nongnu.org/guix/guix-cuirass.git

Read/Write Access:
  git clone @git.sv.nongnu.org:/srv/git/guix/guix-cuirass.git

Web Access:
  http://git.sv.nongnu.org/cgit/guix/guix-cuirass.git
  http://git.sv.nongnu.org/gitweb/?p=guix/guix-cuirass.git


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: NSS test failure on armhf

[Marius Bakke]

Marius Bakke  writes:

>>> It turns out that the bug fix in 3.30.1 is critical: it fixes
>>> CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
>>> has since been released, so I'm currently testing it and will push an
>>> update to it soon.  Any issues on armhf will need to be dealt with in
>>> another way.
>>
>> Mark,
>>
>> I checked this. The upstream 3.30 branch[0] contains a fix, but it was
>> not picked to the 3.30.2 release which only contains certificate
>> changes[1].
>>
>> Squashing these two commits into one should fix the problem (the first
>> fix was incomplete[2]):
>>
>> https://hg.mozilla.org/projects/nss/rev/802ec96a8dd1
>> https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7
>
> Here is a patch that updates to 3.30.1 and disables the b64 test.
>
> I'm building it on x86_64 now, but think it should be safe to push.
>
> What do you think?
>
> From 7f1a8eda567edb851e0f2cd1f08c6ac07e8a45cd Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Thu, 20 Apr 2017 21:36:21 +0200
> Subject: [PATCH] gnu: nss: Update to 3.30.1 [fixes CVE-2017-5461].
>
> * gnu/packages/patches/nss-disable-b64_unittest.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/gnuzilla.scm (nss): Update to 3.30.1.
> [source]: Use it.

This built successfully on x86_64. Here's an excerpt from the log:

'B64EncodeDecodeTest: DISABLED_LongFakeDecTest1' SKIPPED
'B64EncodeDecodeTest: DISABLED_LongFakeEncDecTest1' SKIPPED
'B64EncodeDecodeTest: DISABLED_LongFakeEncDecTest2' SKIPPED

Are you currently building a version of this patch on armhf? If not I'd
like to push it.


signature.asc
Description: PGP signature

[sr #109299] Creating a 'cuirass' Git repository for Guix

[Ludovic Courtès]

URL:
  

 Summary: Creating a 'cuirass' Git repository for Guix
 Project: Savannah Administration
Submitted by: civodul
Submitted on: Thu 20 Apr 2017 11:12:49 PM CEST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Assigned to: None
Originator Email: 
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hello!

Could you create a guix/cuirass.git repository?  This will host a copy of
Cuirass, a continuous integration tool for Guix initially developed as a
GSoC.

Thanks,
Ludo'.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: guix pull: cannot allocate memory

[ng0]

ng0 transcribed 3.0K bytes:
> Is this exactly what Guile is telling me, "get more RAM / SWAP whatever"?
> 
> ERROR: In procedure open-process:
> ERROR: In procedure open-process: Cannot allocate memory
> builder for `/gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv' 
> failed with exit code 1
> guix pull: error: build failed: build of 
> `/gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv' failed

Okay, I added a swap, and this time guix pull as unprivileged user succeded.
As root I had no problems before, same before the conversion to GuixSD.

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

guix pull: cannot allocate memory

[ng0]

Is this exactly what Guile is telling me, "get more RAM / SWAP whatever"?

ng0@sharknado9001:~$ guix pull; guix package -i rxvt-unicode

Starting download of /tmp/guix-file.O9FRJW
From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz   981KiB/s 00:14 | 13.0MiB transferred
unpacking '/gnu/store/lqpb6cppk3h65q5y29dxrj060idqj60b-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivation will be built:
   /gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv
building path(s) `/gnu/store/5x386gcp93f3ms33s60d7q1ijmnllbml-guix-latest'
copying and compiling to 
'/gnu/store/5x386gcp93f3ms33s60d7q1ijmnllbml-guix-latest'...
loading...   24.5% of 587 filesrandom seed for tests: 1492717246
loading...   98.8% of 587 filesBacktrace:
In unknown file:
   ?: 19 [primitive-load-path "gnu/tests/install" ...]
In ice-9/eval.scm:
 453: 18 [eval # ()]
 411: 17 [eval # #]
 387: 16 [eval # #]
 373: 15 [run-install # #]
 387: 14 [eval # #]
 387: 13 [eval # #]
 387: 12 [eval # #]
 411: 11 [eval # #]
In srfi/srfi-1.scm:
 573: 10 [map # (# # # # ...)]
In ice-9/eval.scm:
 387: 9 [eval # #]
 411: 8 [eval # #]
 411: 7 [eval # #]
 387: 6 [eval # #]
In unknown file:
   ?: 5 [force #>]
In ice-9/eval.scm:
 411: 4 [eval # #]
 411: 3 [eval # #]
In ice-9/r4rs.scm:
  90: 2 [dynamic-wind # ...]
In ice-9/popen.scm:
  64: 1 [open-pipe* "r" "git" "ls-files"]
In unknown file:
   ?: 0 [open-process "r" "git" "ls-files"]

ERROR: In procedure open-process:
ERROR: In procedure open-process: Cannot allocate memory
builder for `/gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv' 
failed with exit code 1
guix pull: error: build failed: build of 
`/gnu/store/pg93cl2f7pynqz3rxmvg77226y79lhhi-guix-latest.drv' failed
The following package will be installed:
   rxvt-unicode 9.22
/gnu/store/3475lgmchm6741k4qba2yjy7vzi3dvaj-rxvt-unicode-9.22

substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivations will be built:
   /gnu/store/n170839mwhhmafzybwfyvzvr2715v9i6-profile.drv
   /gnu/store/vsl5cawz5rnff8vnqiv6j6rpfg51fmn9-ca-certificate-bundle.drv
   /gnu/store/r6a0llypsadsdhjg1in0hdc2gkhy3ffd-info-dir.drv
   /gnu/store/jkdfspmg0zciy7wkwi8nhzf043nw6q5h-fonts-dir.drv
   /gnu/store/5iysifiijhbspq5rs0wfvq7x0b6gpfjp-manual-database.drv
creating manual page database for 1 packages...
1 package in profile
The following environment variable definitions may be needed:
   export 
TERMINFO_DIRS="/home/ng0/.guix-profile/share/terminfo${TERMINFO_DIRS:+:}$TERMINFO_DIRS"

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: [PATCH] DRAFT: gnu: icecat: Update to 52.0.2-gnu1; add fixes from ESR 52.1.

[ng0]

Maxim Cournoyer transcribed 1.8K bytes:
> Hi Mark!
> 
> Mark H Weaver  writes:
> 
> > Hello Guix,
> >
> > Here's a draft patch to update GNU IceCat to 52.0.2-gnu1, with
> > additional fixes cherry-picked from upstream ESR 52.1.  It seems to work
> > well on my system, except that my GNOME 3 session has locked up a couple
> > of times while testing it[*].  I'm not yet sure whether the problem is
> > caused by IceCat or something else.  I'd appreciate it if other people
> > could try it out.
> 
> [...]
> 
> > I've also attached a patch to add autoconf-2.13 (from 1999!), since it
> > appears to be a build requirement of IceCat 52.x.  I haven't tested it
> > for anything except building IceCat.
> 
> Thanks for working on this. I'd reckon you first tried using current
> autoconf before resorting to using this 1999 flavor? I'm having a hard
> time understanding why such old software could be made a hard
> requirement :)
> 
> Maxim

Sometimes logic doesn't apply to development. I packaged the very same version 
when
I was working on palemoon-browser because they somehow depended on it.

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: NSS test failure on armhf

[Marius Bakke]

Marius Bakke  writes:

> Mark H Weaver  writes:
>
>> Leo Famulari  writes:
>>
>>> On Mon, Apr 17, 2017 at 11:23:43PM +0200, Marius Bakke wrote:
 Hello!
 
 Since version 3.30.1, one test consistently fails on armhf. It is the
 same as in this bug report, although we don't see the exception:
 
 https://bugzilla.mozilla.org/show_bug.cgi?id=1351459
 
 I initially thought this was due to stalls in the build process as we've
 seen before and tried increasing the timeouts in a790f2620, but that
 should probably be reverted.
 
 What should we do? We can either patch out this test, or go back to
 3.30. Here are the release notes for 3.30.1:
 
 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.30.1_release_notes
 
 It fixes a non-public bug in the base64 implementation, but introduced a
 test failure on at least two arches.
 
 Any preference?
>>>
>>> Since there were no changes to the set of certificates between 3.30 and
>>> 3.30.1 [0], I would revert it for now.
>>
>> It turns out that the bug fix in 3.30.1 is critical: it fixes
>> CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
>> has since been released, so I'm currently testing it and will push an
>> update to it soon.  Any issues on armhf will need to be dealt with in
>> another way.
>
> Mark,
>
> I checked this. The upstream 3.30 branch[0] contains a fix, but it was
> not picked to the 3.30.2 release which only contains certificate
> changes[1].
>
> Squashing these two commits into one should fix the problem (the first
> fix was incomplete[2]):
>
> https://hg.mozilla.org/projects/nss/rev/802ec96a8dd1
> https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7

Here is a patch that updates to 3.30.1 and disables the b64 test.

I'm building it on x86_64 now, but think it should be safe to push.

What do you think?

From 7f1a8eda567edb851e0f2cd1f08c6ac07e8a45cd Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Thu, 20 Apr 2017 21:36:21 +0200
Subject: [PATCH] gnu: nss: Update to 3.30.1 and disable failing test [fixes
 CVE-2017-5461].

* gnu/packages/patches/nss-disable-b64_unittest.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/gnuzilla.scm (nss): Update to 3.30.1.
[source]: Use it.
---
 gnu/local.mk   |  1 +
 gnu/packages/gnuzilla.scm  |  5 +--
 .../patches/nss-disable-b64_unittest.patch | 40 ++
 3 files changed, 44 insertions(+), 2 deletions(-)
 create mode 100644 gnu/packages/patches/nss-disable-b64_unittest.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index f38126251..d17f139a5 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -803,6 +803,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/ngircd-handle-zombies.patch		\
   %D%/packages/patches/ninja-zero-mtime.patch			\
   %D%/packages/patches/node-9077.patch\
+  %D%/packages/patches/nss-disable-b64_unittest.patch		\
   %D%/packages/patches/nss-increase-test-timeout.patch		\
   %D%/packages/patches/nss-pkgconfig.patch			\
   %D%/packages/patches/ntfs-3g-CVE-2017-0358.patch		\
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index 87695329c..21902b427 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -194,7 +194,7 @@ in the Mozilla clients.")
 (define-public nss
   (package
 (name "nss")
-(version "3.30")
+(version "3.30.1")
 (source (origin
   (method url-fetch)
   (uri (let ((version-with-underscores
@@ -205,9 +205,10 @@ in the Mozilla clients.")
   "nss-" version ".tar.gz")))
   (sha256
(base32
-"1agkkwb51si4raw46p44vl3d0l7wzvdjcblpcdjjz6aymq6h1h58"))
+"1djypq081m22iw0wg0q7gnpndam5f8qjhqfd5v9by4c6l6lp78hz"))
   ;; Create nss.pc and nss-config.
   (patches (search-patches "nss-pkgconfig.patch"
+   "nss-disable-b64_unittest.patch"
"nss-increase-test-timeout.patch"
 (build-system gnu-build-system)
 (outputs '("out" "bin"))
diff --git a/gnu/packages/patches/nss-disable-b64_unittest.patch b/gnu/packages/patches/nss-disable-b64_unittest.patch
new file mode 100644
index 0..8d2f1deb7
--- /dev/null
+++ b/gnu/packages/patches/nss-disable-b64_unittest.patch
@@ -0,0 +1,40 @@
+This disables a test that fails on armhf and ppc32.
+
+Upstream bug URL:
+
+https://bugzilla.mozilla.org/show_bug.cgi?id=1351459
+
+Patch copied from upstream source repository:
+
+https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7
+
+diff --git a/nss/gtests/util_gtest/util_b64_unittest.cc b/nss/gtests/util_gtest/util_b64_unittest.cc
+--- a/nss/gtests/util_gtest/util_b64_unittest.cc
 b/nss/gtests/util_gtest/util_b64_unittest.cc
+@@ -63,17 +63,19 @@ 

Re: NSS test failure on armhf

[Marius Bakke]

Mark H Weaver  writes:

> Leo Famulari  writes:
>
>> On Mon, Apr 17, 2017 at 11:23:43PM +0200, Marius Bakke wrote:
>>> Hello!
>>> 
>>> Since version 3.30.1, one test consistently fails on armhf. It is the
>>> same as in this bug report, although we don't see the exception:
>>> 
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1351459
>>> 
>>> I initially thought this was due to stalls in the build process as we've
>>> seen before and tried increasing the timeouts in a790f2620, but that
>>> should probably be reverted.
>>> 
>>> What should we do? We can either patch out this test, or go back to
>>> 3.30. Here are the release notes for 3.30.1:
>>> 
>>> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.30.1_release_notes
>>> 
>>> It fixes a non-public bug in the base64 implementation, but introduced a
>>> test failure on at least two arches.
>>> 
>>> Any preference?
>>
>> Since there were no changes to the set of certificates between 3.30 and
>> 3.30.1 [0], I would revert it for now.
>
> It turns out that the bug fix in 3.30.1 is critical: it fixes
> CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
> has since been released, so I'm currently testing it and will push an
> update to it soon.  Any issues on armhf will need to be dealt with in
> another way.

Mark,

I checked this. The upstream 3.30 branch[0] contains a fix, but it was
not picked to the 3.30.2 release which only contains certificate
changes[1].

Squashing these two commits into one should fix the problem (the first
fix was incomplete[2]):

https://hg.mozilla.org/projects/nss/rev/802ec96a8dd1
https://hg.mozilla.org/projects/nss/rev/00b2cc2b33c7

[0] https://hg.mozilla.org/projects/nss/shortlog/NSS_3_30_BRANCH
[1] 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.30.2_release_notes
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1351459#c6


signature.asc
Description: PGP signature

Re: [PATCH] Makefile.am: add a target that lists patches no longer used

[Leo Famulari]

On Tue, May 19, 2015 at 01:34:10AM +0200, Cyril Roelandt wrote:
> * list-useless-patches.sh: New file.
> * Makefile.am (check-for-useless-patches): New target.

We should make use of this somehow!


signature.asc
Description: PGP signature

Re: NSS test failure on armhf

[Leo Famulari]

On Thu, Apr 20, 2017 at 02:39:17PM -0400, Mark H Weaver wrote:
> It turns out that the bug fix in 3.30.1 is critical: it fixes
> CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
> has since been released, so I'm currently testing it and will push an
> update to it soon.  Any issues on armhf will need to be dealt with in
> another way.

Yikes, good catch!


signature.asc
Description: PGP signature

Re: NSS test failure on armhf

[Mark H Weaver]

Leo Famulari  writes:

> On Mon, Apr 17, 2017 at 11:23:43PM +0200, Marius Bakke wrote:
>> Hello!
>> 
>> Since version 3.30.1, one test consistently fails on armhf. It is the
>> same as in this bug report, although we don't see the exception:
>> 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1351459
>> 
>> I initially thought this was due to stalls in the build process as we've
>> seen before and tried increasing the timeouts in a790f2620, but that
>> should probably be reverted.
>> 
>> What should we do? We can either patch out this test, or go back to
>> 3.30. Here are the release notes for 3.30.1:
>> 
>> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.30.1_release_notes
>> 
>> It fixes a non-public bug in the base64 implementation, but introduced a
>> test failure on at least two arches.
>> 
>> Any preference?
>
> Since there were no changes to the set of certificates between 3.30 and
> 3.30.1 [0], I would revert it for now.

It turns out that the bug fix in 3.30.1 is critical: it fixes
CVE-2017-5461, a potential remote code execution vulnerability.  3.30.2
has since been released, so I'm currently testing it and will push an
update to it soon.  Any issues on armhf will need to be dealt with in
another way.

  Mark

Re: [PATCH] DRAFT: gnu: icecat: Update to 52.0.2-gnu1; add fixes from ESR 52.1.

[Petter]

Hi Mark,

I've been running Icecat 52 for a couple of hours now on Xfce. No 
problems!


Memory and CPU usage is normal.

Well done, thanks!
Petter

Re: Continuing the work on the recipes related to GNU Ring

[Adonay Felipe Nogueira]

Thank you all for taking it. :)

Also, before I forget: For the recipes we made so far, I agree to
license the recipes made so far under the license that is used for most
package recipes in Guix, just add my copyright/attribution line. :)

Re: Continuing the work on the recipes related to GNU Ring

[Maxim Cournoyer]

Hi Adonay!

Adonay Felipe Nogueira  writes:

> Hi all! :)
>
> I bring you a request: We might need "real" developers working on this
> --- because I don't know how to make programs in the languages being
> used by upstreams. Also, I'm somewhat "up to my ears" on study paperwork
> now. :)
>
> I have attached an improved set of recipes (in one .scm file, still not
> a patch), that take suggestions from
> [[https://lists.gnu.org/archive/html/ring/2017-03/msg7.html]] ---
> the list archive item doesn't show it, but someone replied privately to
> me saying that msgpack must be made with "C++11" set.
>
> Here is the notes that I have made so far:
>
> - I did not test the changes I made yet, but I plan to once I can
>   upgrade my packages installed through Guix.
>
> - Updated commit of ring-project.tar.gz still has lots of patches that
>   are applied to their upstream. The attached set of recipes, however,
>   doesn't have the updated version yet (due to lack of my time).
>
>   - Also, I just tried contacting pjsip/pjproject on an old issue that
> relates to the "gnutls" patch:
> 
> [[http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2017-April/019937.html]].
>
> - For the detailed questions of which license the patched *result*
>   should have, I recommend you to talk to ssalenick and dkc in #ring
>   channel at chat.freenode.net, because I already talked with them
>   briefely. Also, if they don't remember, tell them that they were
>   discussing this with "adfeno".
>
> - Other notes are in the .scm file.

Interesting coincidence! I was looking into GNU Ring as of last weekend
and would be interested in getting it packaged. There's still 2 things I
want to finish being free to work on it, so I might get around it in a
week or so.

If no one else volunteers, I can take it!

Maxim


signature.asc
Description: PGP signature

Re: Ready for Guile 2.2!

[Maxim Cournoyer]

Andy Wingo  writes:

> On Thu 20 Apr 2017 14:35, l...@gnu.org (Ludovic Courtès) writes:
>
>> l...@gnu.org (Ludovic Courtès) skribis:
>>
>>> ;; 2.724686s real time, 3.117062s run time.  0.880827s spent in GC.
>>> scheme@(guile-user)> (version)
>>> $1 = "2.0.13"
>>>
>> scheme@(guile-user)> ,use(guix scripts build)
>> scheme@(guile-user)> ,time (guix-build "libreoffice" "certbot" "xmonad" "-n" 
>> "--no-substitutes" "--no-build-hook")
>>
>> [...]
>>
>> ;; 1.826528s real time, 1.994426s run time.  0.382750s spent in GC.
>> scheme@(guile-user)> (version)
>> $1 = "2.2.1"
>>
>> That’s a 33% speedup compared to 2.0.
>
> That is a 50% speedup compared to 2.0 :)  If we consider its speed as
> being how many times you could do this per second, then 2.0 speed is
> 1/2.72, and 2.2.1 speed is 1/1.82.  Speed ratio is then
> 2.72/1.82=1.4945.  So 2.2.1 is 1.5x the speed of 2.0, or 50% faster :)
>
> Andy, who is not looking for praise, but who likes perf numbers :)

Impressive :). Is there a blog post/article/information somewhere about
what went in Guile to make it that faster?

Thank you for your work!

Maxim


signature.asc
Description: PGP signature

Re: grub with qemu-kvm server fail

[Maxim Cournoyer]

Hi,

ng0  writes:

> ng0 transcribed 1.6K bytes:
>> Maxim Cournoyer transcribed 1.3K bytes:
>> > Hello ng0,
>> > 
>> > On April 19, 2017 5:14:13 PM PDT, ng0  wrote:
>> > >Hi,
>> > >
>> > >I already contacted the hoster support, but maybe someone has an idea.
>> > >
>> > >Upon initing GuixSD from a minimal Debian base, I get stuck at this
>> > >point
>> > >about GRUB. The server is aparently a qemu -> kvm one.
>> > >
>> > >guix system: warning: while talking to shepherd: No such file or
>> > >directory
>> > >Installing for i386-pc platform.
>> > >grub-install: warning: File system `ext2' doesn't support embedding.
>> > >grub-install: warning: Embedding is not possible.  GRUB can only be
>> > >installed in this setup by using blocklists.  However, blocklists are
>> > >UNRELIABLE and their use is discouraged..
>> > >grub-install: error: will not proceed with blocklists.
>> > >guix system: error: failed to install GRUB on device '/dev/vda'
>> > 
>> > What kind of device is /dev/vda?
>> 
>> If I knew, I would've succeeded. I asked if there were any special 
>> requirements to the server ;)
>
> And now I know:
>
> "If you chose an autoinstall then there is no GRUB being used, the bootloader 
> uses a kernel residing on the host."
>
> But I have options to proceed.
>

Interesting! Good luck setting it up :)

Maxim


signature.asc
Description: PGP signature

Re: [PATCH] DRAFT: gnu: icecat: Update to 52.0.2-gnu1; add fixes from ESR 52.1.

[Maxim Cournoyer]

Hi Mark!

Mark H Weaver  writes:

> Hello Guix,
>
> Here's a draft patch to update GNU IceCat to 52.0.2-gnu1, with
> additional fixes cherry-picked from upstream ESR 52.1.  It seems to work
> well on my system, except that my GNOME 3 session has locked up a couple
> of times while testing it[*].  I'm not yet sure whether the problem is
> caused by IceCat or something else.  I'd appreciate it if other people
> could try it out.

[...]

> I've also attached a patch to add autoconf-2.13 (from 1999!), since it
> appears to be a build requirement of IceCat 52.x.  I haven't tested it
> for anything except building IceCat.

Thanks for working on this. I'd reckon you first tried using current
autoconf before resorting to using this 1999 flavor? I'm having a hard
time understanding why such old software could be made a hard
requirement :)

Maxim


signature.asc
Description: PGP signature

Re: Continuing the work on the recipes related to GNU Ring

[Adonay Felipe Nogueira]

Hi all! :)

I bring you a request: We might need "real" developers working on this
--- because I don't know how to make programs in the languages being
used by upstreams. Also, I'm somewhat "up to my ears" on study paperwork
now. :)

I have attached an improved set of recipes (in one .scm file, still not
a patch), that take suggestions from
[[https://lists.gnu.org/archive/html/ring/2017-03/msg7.html]] ---
the list archive item doesn't show it, but someone replied privately to
me saying that msgpack must be made with "C++11" set.

Here is the notes that I have made so far:

- I did not test the changes I made yet, but I plan to once I can
  upgrade my packages installed through Guix.

- Updated commit of ring-project.tar.gz still has lots of patches that
  are applied to their upstream. The attached set of recipes, however,
  doesn't have the updated version yet (due to lack of my time).

  - Also, I just tried contacting pjsip/pjproject on an old issue that
relates to the "gnutls" patch:

[[http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2017-April/019937.html]].

- For the detailed questions of which license the patched *result*
  should have, I recommend you to talk to ssalenick and dkc in #ring
  channel at chat.freenode.net, because I already talked with them
  briefely. Also, if they don't remember, tell them that they were
  discussing this with "adfeno".

- Other notes are in the .scm file.


ring.scm
Description: Binary data

Re: [PATCH] DRAFT: gnu: icecat: Update to 52.0.2-gnu1; add fixes from ESR 52.1.

[Clément Lassieur]

Hi Mark,

Thanks for this patch, it works well :)

I still can't watch videos from http://onlinemoviescinema.com, but I
guess it's an upstream issue (or DRM issue?).  I can watch them with
Firefox/ffmpeg.

I didn't experience your unresponsive GUI issue (using ratpoison).

Clément

Re: Ready for Guile 2.2!

[Andy Wingo]

On Thu 20 Apr 2017 14:35, l...@gnu.org (Ludovic Courtès) writes:

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> ;; 2.724686s real time, 3.117062s run time.  0.880827s spent in GC.
>> scheme@(guile-user)> (version)
>> $1 = "2.0.13"
>>
> scheme@(guile-user)> ,use(guix scripts build)
> scheme@(guile-user)> ,time (guix-build "libreoffice" "certbot" "xmonad" "-n" 
> "--no-substitutes" "--no-build-hook")
>
> [...]
>
> ;; 1.826528s real time, 1.994426s run time.  0.382750s spent in GC.
> scheme@(guile-user)> (version)
> $1 = "2.2.1"
>
> That’s a 33% speedup compared to 2.0.

That is a 50% speedup compared to 2.0 :)  If we consider its speed as
being how many times you could do this per second, then 2.0 speed is
1/2.72, and 2.2.1 speed is 1/1.82.  Speed ratio is then
2.72/1.82=1.4945.  So 2.2.1 is 1.5x the speed of 2.0, or 50% faster :)

Andy, who is not looking for praise, but who likes perf numbers :)

Re: Ready for Guile 2.2!

[Ludovic Courtès]

Hello Guix!

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

> An unscientific illustration of this point:
>
> scheme@(guile-user)> ,use(guix scripts build)
> scheme@(guile-user)> ,time (guix-build "libreoffice" "certbot" "xmonad" "-n" 
> "--no-substitutes" "--no-build-hook")
> The following derivations would be built:
>
> [...]
>
> ;; 2.724686s real time, 3.117062s run time.  0.880827s spent in GC.
> scheme@(guile-user)> (version)
> $1 = "2.0.13"
>
>
> Compared to:
>
> scheme@(guile-user)> ,time (guix-build "libreoffice" "certbot" "xmonad" "-n" 
> "--no-substitutes" "--no-build-hook")
>
> [...]
>
> ;; 2.224821s real time, 2.347463s run time.  0.374545s spent in GC.
>
> Roughly an 18% speedup here.

In Guile 2.2.1 Andy fixed an optimization of ‘thunk?’, which is called a
lot when we load packages (via ‘make-promise’, for record fields marked
as ‘delayed’).  Now we get… drum roll…

--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix scripts build)
scheme@(guile-user)> ,time (guix-build "libreoffice" "certbot" "xmonad" "-n" 
"--no-substitutes" "--no-build-hook")

[...]

;; 1.826528s real time, 1.994426s run time.  0.382750s spent in GC.
scheme@(guile-user)> (version)
$1 = "2.2.1"
--8<---cut here---end--->8---

That’s a 33% speedup compared to 2.0.

Andy super-hero!

Ludo’.

Re: Idea: setting up a company [formerly 'ethical hosting' [formerly mailman service (free for FOSS projects)]]

[Pjotr Prins]

> Yeah, that was exactly my impression when I've started looking into
> what I'm doing, although not with the very same motivation or goal.
> 
> Like I told you offlist, we could use the gnunet.org mumble server
> to shape the idea(s) and solve questions like funding etc.

Sure. What I'll do first is write my ideas up in a BLOG and we open
for discussion. There is no rush, I am taking the long view.

Pj.

Re: Services can now have a default value

[Carlo Zancanaro]

Hey Ludo,

On Thu, Apr 20 2017, Ludovic Courtès wrote:
> There must be some sort of a mapping between service types and
> configuration types, indeed, but I’m not sure how to achieve it.
>
> One solution would be to have all the  records
> inherit (in the OO sense) from , or something along these
> lines.

This was my first thought. I couldn't see how to do OO-style inheritance
with the SRFI-9 API, though. I'm not very experienced with Guile (or
scheme generally), so I might do some more reading about that.

One nice thing about this approach is that now a "service type" is a
scheme record-type, and a "service" is a particular instance of that
record-type, which feels slightly simpler/cleaner to me.

> Or we could make  “struct vtables” and then make
>  instances of those vtables (info "(guile) Vtables").
> I’d rather avoid using those interfaces, though (currently the only
> record API we use is SRFI-9.)

I don't know what this means. I had a quick scan of the documentation,
but I'll have to read it in more detail later.

> Or we could have a ‘define-service’ macro that defines both the
>  and the , and defines a ‘foo-service’
> macro equivalent to (service foo-service-type (foo-configuration …)).
>
>   (define-service-type openssh-service-type
> openssh-service
> (extensions …)
> (configuration
>   (port openssh-service-port (default 22))
>   (use-pam? openssh-service-use-pam? (default #t
>
> and then:
>
>(operating-system
>  ;; …
>  (services (cons (openssh-service (port )) %base-services)))

I also thought about this, but I was concerned about things like
dovecot-service, where there are two configuration objects. I wouldn't
want to force us to duplicate code, and create two different service
types, if we wanted services like that in future.

Although, maybe we would actually rather enforce a "one configuration
type per service type" rule, for the sake of modifying services? It's
hard to modify a service if you can't be sure of what the type of the
configuration will be.

Do you have a preference for what approach to use? If we use a macro to
generate things then we retain the same flexibility as the current
approach which removing a bunch of boilerplate, but I'm not sure I have
the best view of the trade-offs involved.

> I’m not sure what you mean.  Is it something like what ‘simple-service’
> does?

I meant something more like what I did with exim-service-type, where I
extend a service just to ensure its presence, then I had to document
you have to have a mail-aliases-service-type in order to use exim. With
a default configuration the mail-aliases-service-type could be
automatically instantiated if it doesn't exist.

I don't think that's a good idea, though.

Carlo


signature.asc
Description: PGP signature

Re: grub with qemu-kvm server fail

[ng0]

ng0 transcribed 1.6K bytes:
> Maxim Cournoyer transcribed 1.3K bytes:
> > Hello ng0,
> > 
> > On April 19, 2017 5:14:13 PM PDT, ng0  wrote:
> > >Hi,
> > >
> > >I already contacted the hoster support, but maybe someone has an idea.
> > >
> > >Upon initing GuixSD from a minimal Debian base, I get stuck at this
> > >point
> > >about GRUB. The server is aparently a qemu -> kvm one.
> > >
> > >guix system: warning: while talking to shepherd: No such file or
> > >directory
> > >Installing for i386-pc platform.
> > >grub-install: warning: File system `ext2' doesn't support embedding.
> > >grub-install: warning: Embedding is not possible.  GRUB can only be
> > >installed in this setup by using blocklists.  However, blocklists are
> > >UNRELIABLE and their use is discouraged..
> > >grub-install: error: will not proceed with blocklists.
> > >guix system: error: failed to install GRUB on device '/dev/vda'
> > 
> > What kind of device is /dev/vda?
> 
> If I knew, I would've succeeded. I asked if there were any special 
> requirements to the server ;)

And now I know:

"If you chose an autoinstall then there is no GRUB being used, the bootloader 
uses a kernel residing on the host."

But I have options to proceed.

> There was just /dev/vda, no partitionsm, in a ready to be used system.
> 
> Of course in grub-configuration I wrote "/dev/vda" and in the file-systems 
> the same.
> 
> > It looks like grub is trying to install itself on an ext2 partition rather 
> > than on the device itself (for old school dos partitions that would be in 
> > the MBR), and apparently this is not supported. I think I had a similar 
> > problem when installing on my personal computer with ext4; I think it was 
> > because I had specified a numbered partition rather than the device itself 
> > (/dev/sda1 instead of /dev/sda for example).
> > 
> > Maxim
> 

Thanks!
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Performance of the man page database generation

[Ludovic Courtès]

Hello,

Maxim Cournoyer  skribis:

> myglc2  writes:

[...]

>> It is taking more like 50 seconds on my 3.4 Ghz server for 33 packages.
>>
>>> I wonder why the odd package count mismatch (23 vs 22) ?
>>
>> That's my fault. I cut and pasted from two different runs. SORRY! ;-)
>>
>
> OK! No problem; thanks for clarifying it!
>
>>> I don't recall observing this while testing (maybe it only happens
>>> when using the -m option) ?
>>
>> No, I get the same effect w/ 'guix package -r foo.
>
> 50 seconds for 33 packages on such a powerful machine seems abnormal,
> unless you have a specific package(s) which would install an unusually
> large amount of manual pages (which would take more time to be indexed).
>
> Ludovic had a way to time the generation of the manual-database
> derivation; he was using something like [0]:
>
> time guix build --check 
> /gnu/store/rkri628apz2a2i2jvav11ylv2736fvv3-manual-database.drv
>
> Notice that you need the derivation (.drv) of manual-database rather
> than the store item ending by manual-database. Unfortunately I'm not
> aware of how we can easily find the derivation of the corresponding
> manual-database store item used by the profile (as can be found by: guix
> gc -R $(realpath $HOME/.guix-profile) | grep manual-database).
>
> Maybe Ludovic can enlight us?

You can see those .drv names when building the profile.  So you just
need to copy/paste them and run “guix build --check” above.

If you have the profile but not its .drv, you can find out what the .drv
for that profile was but there’s no command-line interface for that (you
have to use ‘valid-derivers’ from (guix store).)

HTH,
Ludo’.

Re: Services can now have a default value

[ng0]

Ricardo Wurmus transcribed 0.6K bytes:
> 
> ng0  writes:
> 
> > Because I still don't think modify-services is documented well enough
> 
> What do you find under-documented about “modify-services”?  The manual
> includes an example and a syntax definition, both of which are pretty
> clear in my opinion.
> 
> Could you please take a look at “6.2.15.3 Service Reference” (especially
> where “modify-services” is documented) and “6.2.1 Using the
> Configuration System” (sub-heading “System Services”), and tell us what
> you consider to be unclear?
> 
> --
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 

It's probably well documented from a programmers point of view, I have
no open question in that regard, but from a users point of view there
is the question open how many modify-services can there be?
If I want to keep %base-services as is and just want to modify one
of the extra services (openssh for example), how does an example
look like?

Questions like these. You think it's clear because the programming
side is covered. Documentation includes the easy to understand
user (I don't like the separation of btw) side.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Extending the mysql configuration

[Andy Wingo]

On Wed 19 Apr 2017 19:45, Christopher Baines  writes:

> I also spotted the define-configuration syntax, which looks like it
> might work well, but I wanted to check if this was definitely a
> direction more services were heading before attempting to write out a
> large part of the supported configuration options.

MHO is this is the direction we should go in.  Having a configuration
defined in a data type that Guix can understand makes it easier to
operate on the system as a whole -- the system can see your mysql
configuration and introspect on it, it's easy to define extension
points, etc.  There are a few services that use this approach and I
expect the number to grow over time.  At the same time many of these
services have the option to fall back on an opaque configuration when
you have special needs or a different workflow -- see dovecot for a very
long example.

Andy

Re: grub with qemu-kvm server fail

[ng0]

Maxim Cournoyer transcribed 1.3K bytes:
> Hello ng0,
> 
> On April 19, 2017 5:14:13 PM PDT, ng0  wrote:
> >Hi,
> >
> >I already contacted the hoster support, but maybe someone has an idea.
> >
> >Upon initing GuixSD from a minimal Debian base, I get stuck at this
> >point
> >about GRUB. The server is aparently a qemu -> kvm one.
> >
> >guix system: warning: while talking to shepherd: No such file or
> >directory
> >Installing for i386-pc platform.
> >grub-install: warning: File system `ext2' doesn't support embedding.
> >grub-install: warning: Embedding is not possible.  GRUB can only be
> >installed in this setup by using blocklists.  However, blocklists are
> >UNRELIABLE and their use is discouraged..
> >grub-install: error: will not proceed with blocklists.
> >guix system: error: failed to install GRUB on device '/dev/vda'
> 
> What kind of device is /dev/vda?

If I knew, I would've succeeded. I asked if there were any special requirements 
to the server ;)

There was just /dev/vda, no partitionsm, in a ready to be used system.

Of course in grub-configuration I wrote "/dev/vda" and in the file-systems the 
same.

> It looks like grub is trying to install itself on an ext2 partition rather 
> than on the device itself (for old school dos partitions that would be in the 
> MBR), and apparently this is not supported. I think I had a similar problem 
> when installing on my personal computer with ext4; I think it was because I 
> had specified a numbered partition rather than the device itself (/dev/sda1 
> instead of /dev/sda for example).
> 
> Maxim

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Services can now have a default value

[Ricardo Wurmus]

ng0  writes:

> Because I still don't think modify-services is documented well enough

What do you find under-documented about “modify-services”?  The manual
includes an example and a syntax definition, both of which are pretty
clear in my opinion.

Could you please take a look at “6.2.15.3 Service Reference” (especially
where “modify-services” is documented) and “6.2.1 Using the
Configuration System” (sub-heading “System Services”), and tell us what
you consider to be unclear?

--
Ricardo

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

Re: Idea: setting up a company [formerly 'ethical hosting' [formerly mailman service (free for FOSS projects)]]

[ng0]

Pjotr Prins transcribed 1.3K bytes:
> > For the record, YunoHost develops such a Web interface that allows
> > people to select services to run on their machine:
> > 
> >   https://yunohost.org/
> > 
> > It’s designed to drive a Debian system, but I guess making something
> > similar for GuixSD would be easier.  We could have Exim, Mailman,
> > MediaGoblin, and all that!
> > 
> > > No consulting required unless something goes wrong. So we need to
> > > probably factor in monitoring and minimal support for paying clients.
> > 
> > Heh, sounds like a plan.  :-)
> > 
> > Thanks for the brainstorming session!
> 
> Now I have a crazy idea. I propose to set up a company that targets
> 'ethical hosting'. We'll design that company to be fair. Every step
> will happen online and anyone can participate. It will be both an
> experiment - as a company, an opportunity for people to earn and give
> back, and a guide for geeks to set up their own. This is an
> interesting age with people working from different countries on FOSS
> projects, funding schemes like crowd sourcing, and plenty ideas. What
> seems to be missing is is a guide for individuals to start up.

Yeah, that was exactly my impression when I've started looking into
what I'm doing, although not with the very same motivation or goal.

Like I told you offlist, we could use the gnunet.org mumble server
to shape the idea(s) and solve questions like funding etc.

> I have been much inspired by Pieter Hintjens, one of the FOSDEM
> organizers who sadly passed away last year. You can still read his
> BLOG online and see what I mean.
> 
> Do you think we can create a Guix-based business? I do. I am willing
> to take the lead.
> 
> Pj.
> -- 
> 

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Services can now have a default value

[Ludovic Courtès]

Hi Carlo,

Carlo Zancanaro  skribis:

>> There are two issues here:
>>
>>   1. The default values here are redundant with those we also specify in
>>  .
>>
>>   2. The ‘-service’ procedures are a bit opaque.  For things like
>>  ‘modify-services’, we want to expose the fact that we have service
>>  objects with an associated  value, rather than
>>  hide it inside a procedure.
>>
>> For these reasons, I’ve been progressively suggesting that we avoid
>> ‘-service’ procedures altogether, and deprecate the existing ones.
>> There are still many of them though, as you write; we should remove
>> them (patches welcome! easy task for a GuixSD newcomer! :-)).
>
> Could we create a mapping from configuration -> service-type? Or somehow
> embed the service-type inside the configuration record? (I prefer the
> former.) That way we could specify our service list as a list of
> configurations without having to doubly-specify the services.
>
> So then instead of
>
>   (service foo-service-type
>(foo-configuration (foo #f)
>   (number 42)))
>
> we could have:
>
>   (foo-configuration (foo #f)
>  (number 42))
>
> and have the foo-service-type implicitly looked up when instantiating
> the services.

There must be some sort of a mapping between service types and
configuration types, indeed, but I’m not sure how to achieve it.

One solution would be to have all the  records
inherit (in the OO sense) from , or something along these
lines.

Or we could make  “struct vtables” and then make
 instances of those vtables (info "(guile) Vtables").
I’d rather avoid using those interfaces, though (currently the only
record API we use is SRFI-9.)

Or we could have a ‘define-service’ macro that defines both the
 and the , and defines a ‘foo-service’
macro equivalent to (service foo-service-type (foo-configuration …)).

  (define-service-type openssh-service-type
openssh-service
(extensions …)
(configuration
  (port openssh-service-port (default 22))
  (use-pam? openssh-service-use-pam? (default #t

and then:

   (operating-system
 ;; …
 (services (cons (openssh-service (port )) %base-services)))

Thoughts?

>> The default value thing in this thread is about making the ‘service’
>> form less verbose and closer to what we had with ‘-service’
>> procedures.
>
> Yeah, okay. I guess I just saw the change and felt like it doesn't
> actually change much. Having a default value saves you a bit of typing,
> but only in the case where you don't want to change any configuration
> for the service.
>
> The other thing that it would buy you (which is more significant) is the
> ability to create services that are required for service extensions, but
> which aren't listed in the operating-system's services. I assume we
> don't want to do that, though, because that could be
> dangerous/surprising.

I’m not sure what you mean.  Is it something like what ‘simple-service’
does?

>> Does that clarify things?
>
> Yes, thanks! Are there discussions somewhere that I can read about how
> this came together? I don't think I've been on the list long enough to
> have seen it myself (or if I have, I can't find them).

It all started with the new service API, which introduced service types
and service objects:

  https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00608.html

The specific issue we’re discussing hasn’t received much attention
though, but it’s been discussed a few times as people were adding new
service definitions.

Thanks,
Ludo’.

Re: [PATCH] DRAFT: gnu: icecat: Update to 52.0.2-gnu1; add fixes from ESR 52.1.

[Mark H Weaver]

Mark H Weaver  writes:

> Here's a draft patch to update GNU IceCat to 52.0.2-gnu1, with
> additional fixes cherry-picked from upstream ESR 52.1.  It seems to work
> well on my system, except that my GNOME 3 session has locked up a couple
> of times while testing it[*].  I'm not yet sure whether the problem is
> caused by IceCat or something else.  I'd appreciate it if other people
> could try it out.
>
> [*] The mouse cursor still moves, and I can switch to text VTs, but
> otherwise the GUI is unresponsive.  Killing icecat is not sufficient
> to unfreeze the graphical session, but I'm able to restart the X
> server without rebooting.

Actually, it turns out that I can consistently recover from these
freezes by kill -9  from a text console.  gnome-session
restarts gnome-shell automatically, and IceCat is still functional.

  Mark

[PATCH] DRAFT: gnu: icecat: Update to 52.0.2-gnu1; add fixes from ESR 52.1.

[Mark H Weaver]

Hello Guix,

Here's a draft patch to update GNU IceCat to 52.0.2-gnu1, with
additional fixes cherry-picked from upstream ESR 52.1.  It seems to work
well on my system, except that my GNOME 3 session has locked up a couple
of times while testing it[*].  I'm not yet sure whether the problem is
caused by IceCat or something else.  I'd appreciate it if other people
could try it out.

[*] The mouse cursor still moves, and I can switch to text VTs, but
otherwise the GUI is unresponsive.  Killing icecat is not sufficient
to unfreeze the graphical session, but I'm able to restart the X
server without rebooting.

Note that upstream has apparently removed support for Gstreamer, so our
IceCat package now links directly to ffmpeg, as Mathieu OTHACEHE
suggested a few months ago.  It would be nice to find a way to make this
more modular.

I've also attached a patch to add autoconf-2.13 (from 1999!), since it
appears to be a build requirement of IceCat 52.x.  I haven't tested it
for anything except building IceCat.

  Mark


From 743060c66e9a74e196121d882048599f5eb5a953 Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Thu, 20 Apr 2017 00:42:15 -0400
Subject: [PATCH 1/2] gnu: Add autoconf@2.13.

* gnu/packages/autotools.scm (autoconf-2.13): New variable.
---
 gnu/packages/autotools.scm | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/autotools.scm b/gnu/packages/autotools.scm
index e8b087000..4dbe7b2a2 100644
--- a/gnu/packages/autotools.scm
+++ b/gnu/packages/autotools.scm
@@ -3,7 +3,7 @@
 ;;; Copyright © 2012, 2013, 2014, 2015, 2016 Ludovic Courtès 
 ;;; Copyright © 2015 Mathieu Lirzin 
 ;;; Copyright © 2014 Manolis Fragkiskos Ragkousis 
-;;; Copyright © 2015 Mark H Weaver 
+;;; Copyright © 2015, 2017 Mark H Weaver 
 ;;; Copyright © 2016 David Thompson 
 ;;; Copyright © 2017 ng0 
 ;;;
@@ -92,6 +92,35 @@ know anything about Autoconf or M4.")
(base32
 "0j3jdjpf5ly39dlp0bg70h72nzqr059k0x8iqxvaxf106chpgn9j"))
 
+(define-public autoconf-2.13
+  ;; GNU IceCat 52.x requires autoconf-2.13 to build!
+  (package (inherit autoconf)
+(version "2.13")
+(source
+ (origin
+  (method url-fetch)
+  (uri (string-append "mirror://gnu/autoconf/autoconf-"
+  version ".tar.gz"))
+  (sha256
+   (base32
+"07krzl4czczdsgzrrw9fiqx35xcf32naf751khg821g5pqv12qgh"
+(arguments
+ `(#:tests? #f
+   #:phases
+   ;; The 'configure' script in autoconf-2.13 can't cope with "SHELL=" and
+   ;; "CONFIG_SHELL=" arguments, so we set them as environment variables
+   ;; and pass a simplified set of arguments.
+   (modify-phases %standard-phases
+ (replace 'configure
+   (lambda* (#:key build inputs outputs #:allow-other-keys)
+ (let ((bash (which "bash"))
+   (out  (assoc-ref outputs "out")))
+   (setenv "CONFIG_SHELL" bash)
+   (setenv "SHELL" bash)
+   (zero? (system* bash "./configure"
+   (string-append "--prefix=" out)
+   (string-append "--build=" build)))
+
 
 (define* (autoconf-wrapper #:optional (autoconf autoconf))
   "Return an wrapper around AUTOCONF that generates `configure' scripts that
-- 
2.12.2

From 87f481b3376f7bbbf2b62307317e6386ac10ebfa Mon Sep 17 00:00:00 2001
From: Mark H Weaver 
Date: Thu, 20 Apr 2017 00:41:32 -0400
Subject: [PATCH 2/2] DRAFT: gnu: icecat: Update to 52.0.2-gnu1; add fixes from
 ESR 52.1.

* gnu/packages/gnuzilla.scm (icecat): Update to 52.0.2-gnu1.
[source]: Remove all patches except "icecat-avoid-bundled-libraries.patch".
Add selected fixes from the upstream mozilla-esr52 repository, up to 52.1.
Remove "dom/devicestorage" in the snippet.
[inputs]: Remove gstreamer and gst-plugins-base.  Add gtk+ version 3,
libnotify and ffmpeg.  Move yasm to native-inputs.
[native-inputs]: Add autoconf-2.13 and yasm.
[arguments]: In configure-flags, remove the following switches which are no
longer accepted: --enable-{pango,svg,canvas,mathml,gstreamer=1.0 and
--disable-gnomevfs.  Pass --enable-default-toolkit=cairo-gtk3 to use Gtk+3.
Remove the 'remove-h264parse-from-blacklist' phase.  Adapt the
'arrange-to-link-libxul-with-libraries-it-might-dlopen' phase as needed.
In the 'configure' phase, set the AUTOCONF environment variable.
(mozilla-patch): Update the URL pattern to fetch from the mozilla-esr52
repository.
* gnu/packages/patches/icecat-avoid-bundled-libraries.patch: Adapt to mozilla-esr52.
* gnu/packages/patches/icecat-binutils.patch: Remove file.
* gnu/packages/patches/icecat-bug-1299500-pt10.patch: New file.
* gnu/local.mk (dist_patch_DATA): Remove "icecat-binutils.patch".
Add "icecat-bug-1299500-pt10.patch".
---
 gnu/local.mk

Re: Idea: setting up a company [formerly 'ethical hosting' [formerly mailman service (free for FOSS projects)]]

[Pjotr Prins]

> For the record, YunoHost develops such a Web interface that allows
> people to select services to run on their machine:
> 
>   https://yunohost.org/
> 
> It’s designed to drive a Debian system, but I guess making something
> similar for GuixSD would be easier.  We could have Exim, Mailman,
> MediaGoblin, and all that!
> 
> > No consulting required unless something goes wrong. So we need to
> > probably factor in monitoring and minimal support for paying clients.
> 
> Heh, sounds like a plan.  :-)
> 
> Thanks for the brainstorming session!

Now I have a crazy idea. I propose to set up a company that targets
'ethical hosting'. We'll design that company to be fair. Every step
will happen online and anyone can participate. It will be both an
experiment - as a company, an opportunity for people to earn and give
back, and a guide for geeks to set up their own. This is an
interesting age with people working from different countries on FOSS
projects, funding schemes like crowd sourcing, and plenty ideas. What
seems to be missing is is a guide for individuals to start up.

I have been much inspired by Pieter Hintjens, one of the FOSDEM
organizers who sadly passed away last year. You can still read his
BLOG online and see what I mean.

Do you think we can create a Guix-based business? I do. I am willing
to take the lead.

Pj.
--