Let’s freeze and build ‘core-updates’!

Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Hello Guix!

Since I’m about to leave keyboard for a couple of weeks, here’s a to-do
list for those of you who’ll be around.  :-)

The last things I wanted to push for ‘core-updates’ were a reproducible
Guile (done in b5efd14a9add1bcb4a44fa5b9c1b47706f3df9da), and a subset
or all of the aarch64 patches, depending on their status (should not be
a blocker IMO).

So, here’s a plan:

  • Once Efraim has pushed some of the aarch64 patches, do another
    evaluation of the “core” package set for that branch, and check for
    anything wrong.  From there on, forbid full-rebuild changes.

  • Once the “core” subset builds correctly on all the supported
    platforms (those that Hydra supports), merge ‘master’.  Maybe update
    a couple of things like GnuTLS while we’re at it.  From there on
    forbid non-trivial changes.

  • Build all the packages.  (To do that, someone with access to Hydra
    must change the “subset” argument to “all” in the config of the
    ‘core-updates’ jobset.)

  • Fix things.

  • Once most regressions have been addressed and most binaries are
    available, merge ‘core-updates’ into ‘master’.

How does that sound?

Thanks,
Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

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

> Hello Guix!
>
> Since I’m about to leave keyboard for a couple of weeks, here’s a to-do
> list for those of you who’ll be around.  :-)
>
> The last things I wanted to push for ‘core-updates’ were a reproducible
> Guile (done in b5efd14a9add1bcb4a44fa5b9c1b47706f3df9da), and a subset
> or all of the aarch64 patches, depending on their status (should not be
> a blocker IMO).
>
> So, here’s a plan:
>
>   • Once Efraim has pushed some of the aarch64 patches, do another
>     evaluation of the “core” package set for that branch, and check for
>     anything wrong.  From there on, forbid full-rebuild changes.
>
>   • Once the “core” subset builds correctly on all the supported
>     platforms (those that Hydra supports), merge ‘master’.  Maybe update
>     a couple of things like GnuTLS while we’re at it.  From there on
>     forbid non-trivial changes.
>
>   • Build all the packages.  (To do that, someone with access to Hydra
>     must change the “subset” argument to “all” in the config of the
>     ‘core-updates’ jobset.)
>
>   • Fix things.
>
>   • Once most regressions have been addressed and most binaries are
>     available, merge ‘core-updates’ into ‘master’.
>
> How does that sound?

This sounds great. I have a question:

The 'staging' branch contains a number of minor updates and it's been
more than a month since the last merge. Should we do a staging
evaluation first (i.e. next few days), or just merge it to core-updates?

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

Re: Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Hey Marius,

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello Guix!
>>
>> Since I’m about to leave keyboard for a couple of weeks, here’s a to-do
>> list for those of you who’ll be around.  :-)
>>
>> The last things I wanted to push for ‘core-updates’ were a reproducible
>> Guile (done in b5efd14a9add1bcb4a44fa5b9c1b47706f3df9da), and a subset
>> or all of the aarch64 patches, depending on their status (should not be
>> a blocker IMO).
>>
>> So, here’s a plan:
>>
>>   • Once Efraim has pushed some of the aarch64 patches, do another
>>     evaluation of the “core” package set for that branch, and check for
>>     anything wrong.  From there on, forbid full-rebuild changes.
>>
>>   • Once the “core” subset builds correctly on all the supported
>>     platforms (those that Hydra supports), merge ‘master’.  Maybe update
>>     a couple of things like GnuTLS while we’re at it.  From there on
>>     forbid non-trivial changes.
>>
>>   • Build all the packages.  (To do that, someone with access to Hydra
>>     must change the “subset” argument to “all” in the config of the
>>     ‘core-updates’ jobset.)
>>
>>   • Fix things.
>>
>>   • Once most regressions have been addressed and most binaries are
>>     available, merge ‘core-updates’ into ‘master’.
>>
>> How does that sound?
>
> This sounds great. I have a question:
>
> The 'staging' branch contains a number of minor updates and it's been
> more than a month since the last merge. Should we do a staging
> evaluation first (i.e. next few days), or just merge it to core-updates?

Good point.  I’d just merge it into ‘core-updates’ at this point.

Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

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

> Hey Marius,
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hello Guix!
>>>
>>> Since I’m about to leave keyboard for a couple of weeks, here’s a to-do
>>> list for those of you who’ll be around.  :-)
>>>
>>> The last things I wanted to push for ‘core-updates’ were a reproducible
>>> Guile (done in b5efd14a9add1bcb4a44fa5b9c1b47706f3df9da), and a subset
>>> or all of the aarch64 patches, depending on their status (should not be
>>> a blocker IMO).
>>>
>>> So, here’s a plan:
>>>
>>>   • Once Efraim has pushed some of the aarch64 patches, do another
>>>     evaluation of the “core” package set for that branch, and check for
>>>     anything wrong.  From there on, forbid full-rebuild changes.
>>>
>>>   • Once the “core” subset builds correctly on all the supported
>>>     platforms (those that Hydra supports), merge ‘master’.  Maybe update
>>>     a couple of things like GnuTLS while we’re at it.  From there on
>>>     forbid non-trivial changes.
>>>
>>>   • Build all the packages.  (To do that, someone with access to Hydra
>>>     must change the “subset” argument to “all” in the config of the
>>>     ‘core-updates’ jobset.)
>>>
>>>   • Fix things.
>>>
>>>   • Once most regressions have been addressed and most binaries are
>>>     available, merge ‘core-updates’ into ‘master’.
>>>
>>> How does that sound?
>>
>> This sounds great. I have a question:
>>
>> The 'staging' branch contains a number of minor updates and it's been
>> more than a month since the last merge. Should we do a staging
>> evaluation first (i.e. next few days), or just merge it to core-updates?
>
> Good point.  I’d just merge it into ‘core-updates’ at this point.

I believe Efraim has pushed the remaining aarch64 patches, and I just
merged in the updates from staging, as well as an xorg and cmake update.

I think we're ready to build the "core" package set now. Mark, Leo?

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

Re: Let’s freeze and build ‘core-updates’!

[Andreas Enge]

Hello,

On Tue, Feb 21, 2017 at 03:03:52PM +0100, Marius Bakke wrote:
> I believe Efraim has pushed the remaining aarch64 patches, and I just
> merged in the updates from staging, as well as an xorg and cmake update.
> 
> I think we're ready to build the "core" package set now.

thanks to all who helped advance core-updates! I just started a new
evaluation.

However, it looks as if all our mips build machines are currently offline.
Mark, could you have a look, please? Or should we simply disregard mips
for this cycle?

Andreas

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Tue, Feb 21, 2017 at 03:03:52PM +0100, Marius Bakke wrote:
> I believe Efraim has pushed the remaining aarch64 patches, and I just
> merged in the updates from staging, as well as an xorg and cmake update.
> 
> I think we're ready to build the "core" package set now. Mark, Leo?

I think we should start, too.

One last question: do you think we should take the rest of the changes
from my xorg branch?

https://github.com/lfam/guix/commits/contrib-xorg-server

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

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Tue, Feb 21, 2017 at 12:32:01PM -0500, Leo Famulari wrote:
> On Tue, Feb 21, 2017 at 03:03:52PM +0100, Marius Bakke wrote:
> > I believe Efraim has pushed the remaining aarch64 patches, and I just
> > merged in the updates from staging, as well as an xorg and cmake update.
> > 
> > I think we're ready to build the "core" package set now. Mark, Leo?
> 
> I think we should start, too.
> 
> One last question: do you think we should take the rest of the changes
> from my xorg branch?
> 
> https://github.com/lfam/guix/commits/contrib-xorg-server

I didn't realize that you already got most of the changes. I pushed the
last two from my branch.

I'll give python-tests more time before starting the core-updates
evaluation.

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

Re: Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Hello Guix!

Looks like there’s been a disk space issue a few days ago that’s now
solved, so I’ve restarted an evaluation of the “core” subset.

Is there any blocker left or should we move forward after that?

Thanks,
Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

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

> Hello Guix!
>
> Looks like there’s been a disk space issue a few days ago that’s now
> solved, so I’ve restarted an evaluation of the “core” subset.
>
> Is there any blocker left or should we move forward after that?

We were waiting for the xorg-server 1.19.3 hotfix that was announced a
few days ago [0], but it hasn't been released yet.

I suggest we either run "autoreconf" in the build process of 1.19.2, or
graft 1.19.3 when available. Any preference?

[0] https://lists.x.org/archives/xorg-announce/2017-March/002780.html

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

Re: Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello Guix!
>>
>> Looks like there’s been a disk space issue a few days ago that’s now
>> solved, so I’ve restarted an evaluation of the “core” subset.
>>
>> Is there any blocker left or should we move forward after that?
>
> We were waiting for the xorg-server 1.19.3 hotfix that was announced a
> few days ago [0], but it hasn't been released yet.
>
> I suggest we either run "autoreconf" in the build process of 1.19.2, or
> graft 1.19.3 when available. Any preference?
>
> [0] https://lists.x.org/archives/xorg-announce/2017-March/002780.html

It’s been 3 days since their message and it hasn’t happened yet, so
perhaps we should simply run autoreconf.

Thoughts?

BTW, xorg-server is a build-time dependency of gtk+@3 (for test
purposes), which is the main reason why it has so many dependents.
Perhaps it would be fine to keep using 1.9.12 for GTK+.  That way, we
can update xorg-server without rebuilding the world.

Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

On Mon, Mar 06, 2017 at 04:39:56PM +0100, Ludovic Courtès wrote:
> It’s been 3 days since their message and it hasn’t happened yet, so
> perhaps we should simply run autoreconf.
> 
> Thoughts?

Okay.

> BTW, xorg-server is a build-time dependency of gtk+@3 (for test
> purposes), which is the main reason why it has so many dependents.
> Perhaps it would be fine to keep using 1.9.12 for GTK+.  That way, we
> can update xorg-server without rebuilding the world.

Good idea. Should xorg-server-for-gtk inherit from xorg-server or be a
completely separate package? Or something else?

Re: Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Mon, Mar 06, 2017 at 04:39:56PM +0100, Ludovic Courtès wrote:
>> It’s been 3 days since their message and it hasn’t happened yet, so
>> perhaps we should simply run autoreconf.
>> 
>> Thoughts?
>
> Okay.
>
>> BTW, xorg-server is a build-time dependency of gtk+@3 (for test
>> purposes), which is the main reason why it has so many dependents.
>> Perhaps it would be fine to keep using 1.9.12 for GTK+.  That way, we
>> can update xorg-server without rebuilding the world.
>
> Good idea. Should xorg-server-for-gtk inherit from xorg-server or be a
> completely separate package? Or something else?

I guess it could be called ‘xorg-server-1.9.12’ and technically inherit
from ‘xorg-server’ but override the version and source.

Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Tue, Mar 07, 2017 at 02:59:39PM +0100, Ludovic Courtès wrote:
> I guess it could be called ‘xorg-server-1.9.12’ and technically inherit
> from ‘xorg-server’ but override the version and source.

I've attached patches updating xorg-server and creating a special
package to be used for building GTK+.

[-- Attachment #1.2: 0001-gnu-xorg-server-Update-to-1.19.2-fixes-CVE-2017-2624.patch --]
[-- Type: text/plain, Size: 2226 bytes --]

From 5e6cc8caaf7de4d8863f8f4ab64d8c9e7cbbfcaf Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Fri, 3 Mar 2017 13:44:48 -0500
Subject: [PATCH 1/2] gnu: xorg-server: Update to 1.19.2 [fixes CVE-2017-2624].

* gnu/packages/xorg.scm (xorg-server): Update to 1.19.2.
[native-inputs]: Add font-util, libtool, autoconf, and automake.
[arguments]: Add 'bootstrap' phase.
---
 gnu/packages/xorg.scm | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm
index 31ea296d4..5c9300e20 100644
--- a/gnu/packages/xorg.scm
+++ b/gnu/packages/xorg.scm
@@ -4982,7 +4982,7 @@ over Xlib, including:
 (define-public xorg-server
   (package
     (name "xorg-server")
-    (version "1.19.1")
+    (version "1.19.2")
     (source
       (origin
         (method url-fetch)
@@ -4991,7 +4991,7 @@ over Xlib, including:
               name "-" version ".tar.bz2"))
         (sha256
          (base32
-          "1yx7cnlhl14hsdq5lg0740s4nxqxkmaav38x428llv1zkprjrbkr"))))
+          "1fw4b2lf75nsqkiyhn95b1c2if1l3cw5a188a1szx1d8l7sbk2jg"))))
     (build-system gnu-build-system)
     (propagated-inputs
       `(("dri2proto" ,dri2proto)
@@ -5050,7 +5050,12 @@ over Xlib, including:
         ("xcb-util-wm" ,xcb-util-wm)))
     (native-inputs
        `(("python" ,python-minimal-wrapper)
-         ("pkg-config" ,pkg-config)))
+         ("pkg-config" ,pkg-config)
+         ;; XXX Bootstrapping inputs for 1.19.2. Remove for > 1.19.2.
+         ("font-util" ,font-util)
+         ("libtool" ,libtool)
+         ("autoconf" ,autoconf)
+         ("automake" ,automake)))
     (arguments
      `(#:parallel-tests? #f
        #:configure-flags
@@ -5077,6 +5082,10 @@ over Xlib, including:
 
        #:phases
        (modify-phases %standard-phases
+         ;; XXX The 1.19.2 release of xorg-server was not bootstrapped:
+         ;; <https://lists.x.org/archives/xorg-announce/2017-March/002780.html>
+         (add-before 'configure 'bootstrap
+           (lambda _ (zero? (system* "autoreconf" "-vfi"))))
          (add-before
           'configure 'pre-configure
           (lambda _
-- 
2.12.0


[-- Attachment #1.3: 0002-gnu-gtk-Build-GTK-with-its-own-xorg-server-package.patch --]
[-- Type: text/plain, Size: 2520 bytes --]

From 3601571063aa0317720d19d83f1cb42745abd5f8 Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Wed, 8 Mar 2017 00:40:37 -0500
Subject: [PATCH 2/2] gnu: gtk+: Build GTK+ with its own xorg-server package.

This will allow us to update xorg-server directly on the master branch.

* gnu/packages/xorg.scm (xorg-server-1.19.2): New variable.
* gnu/packages/gtk.scm (gtk+) [native-inputs]: Use xorg-server-1.19.2 instead of
xorg-server.
(arguments): Add xorg-server-1.19.2 to #:disallowed-references.
---
 gnu/packages/gtk.scm  |  7 +++++--
 gnu/packages/xorg.scm | 16 ++++++++++++++++
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index 92f399ecb..057c80859 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -689,9 +689,12 @@ application suites.")
       ("pkg-config" ,pkg-config)
       ("gobject-introspection" ,gobject-introspection)
       ("python-wrapper" ,python-wrapper)
-      ("xorg-server" ,xorg-server)))
+      ;; By using a special xorg-server for GTK+'s tests, we reduce the impact
+      ;; of updating xorg-server directly on the master branch.
+      ("xorg-server" ,xorg-server-1.19.2)))
    (arguments
-    `(;; 47 MiB goes to "out" (24 of which is locale data!), and 26 MiB goes
+    `(#:disallowed-references (,xorg-server-1.19.2)
+      ;; 47 MiB goes to "out" (24 of which is locale data!), and 26 MiB goes
       ;; to "doc".
       #:configure-flags (list (string-append "--with-html-dir="
                                              (assoc-ref %outputs "doc")
diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm
index 5c9300e20..bd8f38c39 100644
--- a/gnu/packages/xorg.scm
+++ b/gnu/packages/xorg.scm
@@ -5111,6 +5111,22 @@ communicates with the user via graphical controls such as buttons and
 draggable titlebars and borders.")
     (license license:x11)))
 
+;;; This package is intended to be used when building GTK+.
+(define-public xorg-server-1.19.2
+  (package
+    (inherit xorg-server)
+    (name "xorg-server")
+    (version "1.19.2")
+    (source
+      (origin
+        (method url-fetch)
+        (uri (string-append
+              "mirror://xorg/individual/xserver/"
+              name "-" version ".tar.bz2"))
+        (sha256
+         (base32
+          "1fw4b2lf75nsqkiyhn95b1c2if1l3cw5a188a1szx1d8l7sbk2jg"))))))
+
 (define-public xorg-server-xwayland
   (package
     (inherit xorg-server)
-- 
2.12.0


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

Re: Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Tue, Mar 07, 2017 at 02:59:39PM +0100, Ludovic Courtès wrote:
>> I guess it could be called ‘xorg-server-1.9.12’ and technically inherit
>> from ‘xorg-server’ but override the version and source.
>
> I've attached patches updating xorg-server and creating a special
> package to be used for building GTK+.
>
> From 5e6cc8caaf7de4d8863f8f4ab64d8c9e7cbbfcaf Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo@famulari.name>
> Date: Fri, 3 Mar 2017 13:44:48 -0500
> Subject: [PATCH 1/2] gnu: xorg-server: Update to 1.19.2 [fixes CVE-2017-2624].
>
> * gnu/packages/xorg.scm (xorg-server): Update to 1.19.2.
> [native-inputs]: Add font-util, libtool, autoconf, and automake.
> [arguments]: Add 'bootstrap' phase.

[...]

> From 3601571063aa0317720d19d83f1cb42745abd5f8 Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo@famulari.name>
> Date: Wed, 8 Mar 2017 00:40:37 -0500
> Subject: [PATCH 2/2] gnu: gtk+: Build GTK+ with its own xorg-server package.
>
> This will allow us to update xorg-server directly on the master branch.
>
> * gnu/packages/xorg.scm (xorg-server-1.19.2): New variable.
> * gnu/packages/gtk.scm (gtk+) [native-inputs]: Use xorg-server-1.19.2 instead of
> xorg-server.
> (arguments): Add xorg-server-1.19.2 to #:disallowed-references.
  ^ square brackets  :-)

Both LGTM.

After that I think we can start building all the packages on Hydra,
right?

Thank you!

Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

On Wed, Mar 08, 2017 at 09:44:26AM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > Subject: [PATCH 1/2] gnu: xorg-server: Update to 1.19.2 [fixes CVE-2017-2624].
> > Subject: [PATCH 2/2] gnu: gtk+: Build GTK+ with its own xorg-server package.

Pushed!

> After that I think we can start building all the packages on Hydra,
> right?

There are still many failures like this, which I'm not sure how to
interpret:

https://hydra.gnu.org/build/1863401

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

On Mon, Mar 06, 2017 at 10:19:34AM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> Looks like there’s been a disk space issue a few days ago that’s now
> solved, so I’ve restarted an evaluation of the “core” subset.
> 
> Is there any blocker left or should we move forward after that?

Let's also decide what to do about GRUB. I updated it originally because
something (I forgot what) failed to build without a newer GRUB.

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> On Mon, Mar 06, 2017 at 10:19:34AM +0100, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> Looks like there’s been a disk space issue a few days ago that’s now
>> solved, so I’ve restarted an evaluation of the “core” subset.
>> 
>> Is there any blocker left or should we move forward after that?
>
> Let's also decide what to do about GRUB. I updated it originally because
> something (I forgot what) failed to build without a newer GRUB.

I think you meant "flex" here.

According to https://github.com/westes/flex/issues/162 , this commit
should fix the grub issue:

https://github.com/westes/flex/commit/f5d87f1a26f4a5c3402497008ae10e9a1345d327

Seeing as wireshark is apparently also affected according to the
upstream bug, I would suggest applying this fix on our flex package.

Alternatively package a "flex-for-grub" variant, but that's not very
re-usable.

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

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

Marius Bakke <mbakke@fastmail.com> writes:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Mon, Mar 06, 2017 at 10:19:34AM +0100, Ludovic Courtès wrote:
>>> Hello Guix!
>>> 
>>> Looks like there’s been a disk space issue a few days ago that’s now
>>> solved, so I’ve restarted an evaluation of the “core” subset.
>>> 
>>> Is there any blocker left or should we move forward after that?
>>
>> Let's also decide what to do about GRUB. I updated it originally because
>> something (I forgot what) failed to build without a newer GRUB.
>
> I think you meant "flex" here.
>
> According to https://github.com/westes/flex/issues/162 , this commit
> should fix the grub issue:
>
> https://github.com/westes/flex/commit/f5d87f1a26f4a5c3402497008ae10e9a1345d327
>
> Seeing as wireshark is apparently also affected according to the
> upstream bug, I would suggest applying this fix on our flex package.

Another option is to keep version 2.6.2 around, which is better than a
specialized "flex-for-grub". If the previous version works for both grub
and wireshark, I prefer this alternative.

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

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Mon, Mar 06, 2017 at 07:54:06PM +0100, Marius Bakke wrote:
> Another option is to keep version 2.6.2 around, which is better than a
> specialized "flex-for-grub". If the previous version works for both grub
> and wireshark, I prefer this alternative.

The choices are a bit overwhelming; there are problems with 2.6.2 as
well:

https://github.com/westes/flex/issues/134 (kservice broken)
https://github.com/westes/flex/issues/113 (doxygen broken)
https://github.com/westes/flex/issues/98 (flex tests fail)

2.6.4 is "due" today, although I'm not sure what changes could be
included:

https://github.com/westes/flex/milestones

We should not go back to anything before 2.6.1, due to CVE-2016-6354:

https://security-tracker.debian.org/tracker/CVE-2016-6354

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

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Mon, Mar 06, 2017 at 07:49:42PM +0100, Marius Bakke wrote:
> Leo Famulari <leo@famulari.name> writes:
> > Let's also decide what to do about GRUB. I updated it originally because
> > something (I forgot what) failed to build without a newer GRUB.
> 
> I think you meant "flex" here.

Yup! :p

> According to https://github.com/westes/flex/issues/162 , this commit
> should fix the grub issue:
> 
> https://github.com/westes/flex/commit/f5d87f1a26f4a5c3402497008ae10e9a1345d327

I was wary of cherry-picking this due to the flex maintainer's comment:

"f5d87f1

should bwhat you want, but there are a couple others that are
related/relevant."

https://github.com/westes/flex/issues/162#issuecomment-274608469

But we can try it out on core-updates and see how it goes. Will you try
making the patch?

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

core-updates frozen!

[Leo Famulari]

On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
> So, here’s a plan:
> 
>   • Once Efraim has pushed some of the aarch64 patches, do another
>     evaluation of the “core” package set for that branch, and check for
>     anything wrong.  From there on, forbid full-rebuild changes.

Let's freeze core-updates and try to build it. No more rebuild the world
changes except to fix breakage.

>   • Once the “core” subset builds correctly on all the supported
>     platforms (those that Hydra supports), merge ‘master’.  Maybe update
>     a couple of things like GnuTLS while we’re at it.  From there on
>     forbid non-trivial changes.
> 
>   • Build all the packages.  (To do that, someone with access to Hydra
>     must change the “subset” argument to “all” in the config of the
>     ‘core-updates’ jobset.)
> 
>   • Fix things.
> 
>   • Once most regressions have been addressed and most binaries are
>     available, merge ‘core-updates’ into ‘master’.
> 
> How does that sound?
> 
> Thanks,
> Ludo’.
> 

Re: core-updates frozen!

[Leo Famulari]

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

On Mon, Feb 27, 2017 at 03:30:59PM -0500, Leo Famulari wrote:
> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
> > So, here’s a plan:
> > 
> >   • Once Efraim has pushed some of the aarch64 patches, do another
> >     evaluation of the “core” package set for that branch, and check for
> >     anything wrong.  From there on, forbid full-rebuild changes.
> 
> Let's freeze core-updates and try to build it. No more rebuild the world
> changes except to fix breakage.

Once these changes are pushed, I'll start a new evaluation:

http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html

Please, no more rebuild the world changes except to fix breakage in the
core packages.

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

Re: core-updates frozen!

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> On Mon, Feb 27, 2017 at 03:30:59PM -0500, Leo Famulari wrote:
>> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
>> > So, here’s a plan:
>> > 
>> >   • Once Efraim has pushed some of the aarch64 patches, do another
>> >     evaluation of the “core” package set for that branch, and check for
>> >     anything wrong.  From there on, forbid full-rebuild changes.
>> 
>> Let's freeze core-updates and try to build it. No more rebuild the world
>> changes except to fix breakage.
>
> Once these changes are pushed, I'll start a new evaluation:
>
> http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html
>
> Please, no more rebuild the world changes except to fix breakage in the
> core packages.

xorg-server@1.19.2 was *just* released[0] and contains some important
bug fixes (notably CVE-2017-2624).

[0] https://lists.x.org/archives/xorg-announce/2017-March/002779.html

AFAICT it has not been built yet on Hydra since it's not part of the
"core" package set. Is it okay to push?

Unfortunately I have not been able to backport the fix to 1.18.4.

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

Re: core-updates frozen!

[Leo Famulari]

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

On Fri, Mar 03, 2017 at 01:02:04AM +0100, Marius Bakke wrote:
> Leo Famulari <leo@famulari.name> writes:
> > Once these changes are pushed, I'll start a new evaluation:
> >
> > http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html
> >
> > Please, no more rebuild the world changes except to fix breakage in the
> > core packages.
> 
> xorg-server@1.19.2 was *just* released[0] and contains some important
> bug fixes (notably CVE-2017-2624).
> 
> [0] https://lists.x.org/archives/xorg-announce/2017-March/002779.html

It looks like a relatively small set of changes.

> AFAICT it has not been built yet on Hydra since it's not part of the
> "core" package set. Is it okay to push?

xorg-server is not a core package, so I guess it's fine. I'll do the
update when pushing the libgd changes from the thread linked above.

I've been reconfiguring my GuixSD system on core-updates, so I've fixed
and then suffered breakage in a few non-core packages so far :)

At some arbitrary point we have to stop changing the branch and just
build it. Newer important updates will have to be grafted.

> Unfortunately I have not been able to backport the fix to 1.18.4.

Okay, hopefully we can figure it out or copy from another distro.

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

Re: core-updates frozen!

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> On Fri, Mar 03, 2017 at 01:02:04AM +0100, Marius Bakke wrote:
>> Leo Famulari <leo@famulari.name> writes:
>> > Once these changes are pushed, I'll start a new evaluation:
>> >
>> > http://lists.gnu.org/archive/html/guix-devel/2017-03/msg00063.html
>> >
>> > Please, no more rebuild the world changes except to fix breakage in the
>> > core packages.
>> 
>> xorg-server@1.19.2 was *just* released[0] and contains some important
>> bug fixes (notably CVE-2017-2624).
>> 
>> [0] https://lists.x.org/archives/xorg-announce/2017-March/002779.html
>
> It looks like a relatively small set of changes.
>
>> AFAICT it has not been built yet on Hydra since it's not part of the
>> "core" package set. Is it okay to push?
>
> xorg-server is not a core package, so I guess it's fine. I'll do the
> update when pushing the libgd changes from the thread linked above.

Note that 1.19.3 will be released shortly since 1.19.2 had a release bug
that requires running `autoreconf`. See:

https://lists.x.org/archives/xorg-announce/2017-March/002780.html

> I've been reconfiguring my GuixSD system on core-updates, so I've fixed
> and then suffered breakage in a few non-core packages so far :)

Wow, nice :)

> At some arbitrary point we have to stop changing the branch and just
> build it. Newer important updates will have to be grafted.

Agreed. Let's do a full evaluation once Hydra settles down and then
*really* freeze it ;)

>> Unfortunately I have not been able to backport the fix to 1.18.4.
>
> Okay, hopefully we can figure it out or copy from another distro.

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

Re: core-updates frozen!

[Leo Famulari]

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

On Fri, Mar 03, 2017 at 07:33:52PM +0100, Marius Bakke wrote:
> Note that 1.19.3 will be released shortly since 1.19.2 had a release bug
> that requires running `autoreconf`. See:
> 
> https://lists.x.org/archives/xorg-announce/2017-March/002780.html

Ooookay :)

> > I've been reconfiguring my GuixSD system on core-updates, so I've fixed
> > and then suffered breakage in a few non-core packages so far :)
> 
> Wow, nice :)

Note that I haven't succeeded yet. But I did reach the build of GRUB,
which failed to build.

> > At some arbitrary point we have to stop changing the branch and just
> > build it. Newer important updates will have to be grafted.
> 
> Agreed. Let's do a full evaluation once Hydra settles down and then
> *really* freeze it ;)

Okay, but Hydra may never settle down!

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

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
>   • Build all the packages.  (To do that, someone with access to Hydra
>     must change the “subset” argument to “all” in the config of the
>     ‘core-updates’ jobset.)

I've just started an evaluation of "all" the packages :)

>   • Fix things.

Next step!

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
>>   • Build all the packages.  (To do that, someone with access to Hydra
>>     must change the “subset” argument to “all” in the config of the
>>     ‘core-updates’ jobset.)
>
> I've just started an evaluation of "all" the packages :)

Yay! Only two months behind schedule! :-P

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
/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/sh: line 3: 10187 Aborted                 ./Programs/_freeze_importlib ./Lib/importlib/_bootstrap.py Python/importlib.h
Fatal Python error: getentropy() failed
/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/sh: line 3: 10188 Aborted                 ./Programs/_freeze_importlib ./Lib/importlib/_bootstrap_external.py Python/importlib_external.h
make: *** [Makefile:742: Python/importlib.h] Error 134
make: *** Waiting for unfinished jobs....
make: *** [Makefile:736: Python/importlib_external.h] Error 134
phase `build' failed after 27.4 seconds

Will you restart it? :)

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

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

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.

> Will you restart it? :)

Done!

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

core-updates: Python build failures

[Leo Famulari]

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

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 :)

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

Re: core-updates: Python build failures

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> 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.

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

Re: core-updates: Python build failures

[Leo Famulari]

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

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.

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

Re: core-updates: Python build failures

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> 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.

Oh, I missed that 3.5.3 is out. After updating, the patch applied.

I've pushed the Python update and the getentropy() fix as
343cee8af and e4d34cd0 respectively.

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

Re: core-updates: Python build failures

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Leo Famulari <leo@famulari.name> writes:
>
>> 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.

In general, our packages should work with kernels as old as 2.6.32,
since that’s what we build glibc against (via ‘--enable-kernel’).
(We should probably bump to something a bit newer though.)

> Oh, I missed that 3.5.3 is out. After updating, the patch applied.
>
> I've pushed the Python update and the getentropy() fix as
> 343cee8af and e4d34cd0 respectively.

Awesome, thanks!

I started an evaluation of core-updates, we’ll see how it goes:

  https://hydra.gnu.org/jobset/gnu/core-updates#tabs-evaluations

Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
> So, here’s a plan:
> 
>   • Once Efraim has pushed some of the aarch64 patches, do another
>     evaluation of the “core” package set for that branch, and check for
>     anything wrong.  From there on, forbid full-rebuild changes.
> 
>   • Once the “core” subset builds correctly on all the supported
>     platforms (those that Hydra supports), merge ‘master’.  Maybe update
>     a couple of things like GnuTLS while we’re at it.  From there on
>     forbid non-trivial changes.
> 
>   • Build all the packages.  (To do that, someone with access to Hydra
>     must change the “subset” argument to “all” in the config of the
>     ‘core-updates’ jobset.)
> 
>   • Fix things.

We are at this stage... please help :)

Here is a list of packages that are failing on core-updates but not on
the master branch:

https://hydra.gnu.org/eval/109549?compare=master&full=1#tabs-now-fail

It might take a while to load the web page; please have patience :)

Once you load it, take note of the brown and red icons.

The brown icon means, "we did not try to build this yet, because one of
the dependencies failed to build".

The red icon means, "we tried to build this and it failed." You should
probably focus on these failed builds.

I'm sorry if the color-coding is not sufficient for you; we know it's
not a good system for people who have impaired vision. My vision is
pretty good and I find it hard to pick out the red icons.

Once you have found an interesting build failure, read its log (the
"raw" log is most useful, in my opinion) and try to reproduce and fix it
on your machine. Then send a patch!

Sometimes there is a spurious build failure: The SSH connection used for
offloading fails, or the build machine is out of memory. Reply to this
thread with a link to the failing build and we will restart it.

Thanks in advance :)

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

Re: Let’s freeze and build ‘core-updates’!

[julien lepiller]

Le 2017-03-20 19:41, Leo Famulari a écrit :
> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
>> So, here’s a plan:
>> 
>>   • Once Efraim has pushed some of the aarch64 patches, do another
>>     evaluation of the “core” package set for that branch, and check 
>> for
>>     anything wrong.  From there on, forbid full-rebuild changes.
>> 
>>   • Once the “core” subset builds correctly on all the supported
>>     platforms (those that Hydra supports), merge ‘master’.  Maybe 
>> update
>>     a couple of things like GnuTLS while we’re at it.  From there on
>>     forbid non-trivial changes.
>> 
>>   • Build all the packages.  (To do that, someone with access to Hydra
>>     must change the “subset” argument to “all” in the config of the
>>     ‘core-updates’ jobset.)
>> 
>>   • Fix things.
> 
> We are at this stage... please help :)
> 
> Here is a list of packages that are failing on core-updates but not on
> the master branch:
> 
> https://hydra.gnu.org/eval/109549?compare=master&full=1#tabs-now-fail
> 
> It might take a while to load the web page; please have patience :)
> 
> Once you load it, take note of the brown and red icons.
> 
> The brown icon means, "we did not try to build this yet, because one of
> the dependencies failed to build".
> 
> The red icon means, "we tried to build this and it failed." You should
> probably focus on these failed builds.
> 
> I'm sorry if the color-coding is not sufficient for you; we know it's
> not a good system for people who have impaired vision. My vision is
> pretty good and I find it hard to pick out the red icons.
> 
> Once you have found an interesting build failure, read its log (the
> "raw" log is most useful, in my opinion) and try to reproduce and fix 
> it
> on your machine. Then send a patch!
> 
> Sometimes there is a spurious build failure: The SSH connection used 
> for
> offloading fails, or the build machine is out of memory. Reply to this
> thread with a link to the failing build and we will restart it.
> 
> Thanks in advance :)

Hi,

c-reduce seems to have failed because of a crash in g++. Maybe the 
server lacked memory? It builds fine here.

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Tue, Mar 21, 2017 at 12:16:20PM +0100, julien lepiller wrote:
> c-reduce seems to have failed because of a crash in g++. Maybe the server
> lacked memory? It builds fine here.

Thanks for checking on the log!

Indeed, errors like this one...

g++: internal compiler error: Killed (program cc1plus)

... typically indicate an out-of-memory condition. So, I restarted the
build.

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

Re: Let’s freeze and build ‘core-updates’!

[Julien Lepiller]

On Mon, 20 Mar 2017 14:41:45 -0400
Leo Famulari <leo@famulari.name> wrote:

> We are at this stage... please help :)
> 
> Here is a list of packages that are failing on core-updates but not on
> the master branch:
> 
> https://hydra.gnu.org/eval/109549?compare=master&full=1#tabs-now-fail
> 
> It might take a while to load the web page; please have patience :)

Hi,

zsh (https://hydra.gnu.org/build/1883646) failed but the last line is:

build-succeeded /gnu/store/8q928a90f08qc3nfsdf4h39lx8yyr8pm-zsh-5.2.drv

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Tue, Mar 21, 2017 at 10:19:02PM +0100, Julien Lepiller wrote:
> On Mon, 20 Mar 2017 14:41:45 -0400
> Leo Famulari <leo@famulari.name> wrote:
> 
> > We are at this stage... please help :)
> > 
> > Here is a list of packages that are failing on core-updates but not on
> > the master branch:
> > 
> > https://hydra.gnu.org/eval/109549?compare=master&full=1#tabs-now-fail
> > 
> > It might take a while to load the web page; please have patience :)
> 
> Hi,
> 
> zsh (https://hydra.gnu.org/build/1883646) failed but the last line is:
> 
> build-succeeded /gnu/store/8q928a90f08qc3nfsdf4h39lx8yyr8pm-zsh-5.2.drv

Thanks, I've restarted the build.

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

Re: Let’s freeze and build ‘core-updates’!

[Ricardo Wurmus]

Julien Lepiller <julien@lepiller.eu> writes:

> zsh (https://hydra.gnu.org/build/1883646) failed but the last line is:
>
> build-succeeded /gnu/store/8q928a90f08qc3nfsdf4h39lx8yyr8pm-zsh-5.2.drv

That was probably a transient failure.  It’s currently marked as
“Scheduled to be built”.

--
Ricardo

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

Re: Let’s freeze and build ‘core-updates’!

[Thomas Danckaert]

From: Leo Famulari <leo@famulari.name>
Subject: Re: Let’s freeze and build ‘core-updates’!
Date: Mon, 20 Mar 2017 14:41:45 -0400

> Sometimes there is a spurious build failure: The SSH connection 
> used for
> offloading fails, or the build machine is out of memory. Reply to 
> this
> thread with a link to the failing build and we will restart it.

The build of hdf5 on armhf has failed, but the build log ends in

@ build-succeeded 
/gnu/store/y1c7fw50l2lyy0f22nndqws2fsjhrfba-hdf5-1.8.18.drv -

https://hydra.gnu.org/build/1883211/nixlog/2/raw

Thomas

Re: Let’s freeze and build ‘core-updates’!

[Ricardo Wurmus]

Thomas Danckaert <post@thomasdanckaert.be> writes:

> From: Leo Famulari <leo@famulari.name>
> Subject: Re: Let’s freeze and build ‘core-updates’!
> Date: Mon, 20 Mar 2017 14:41:45 -0400
>
>> Sometimes there is a spurious build failure: The SSH connection 
>> used for
>> offloading fails, or the build machine is out of memory. Reply to 
>> this
>> thread with a link to the failing build and we will restart it.
>
> The build of hdf5 on armhf has failed, but the build log ends in
>
> @ build-succeeded 
> /gnu/store/y1c7fw50l2lyy0f22nndqws2fsjhrfba-hdf5-1.8.18.drv -
>
> https://hydra.gnu.org/build/1883211/nixlog/2/raw

Thanks, I just restarted the build.

-- 
Ricardo

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

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
>> So, here’s a plan:
>> 
>>   • Once Efraim has pushed some of the aarch64 patches, do another
>>     evaluation of the “core” package set for that branch, and check for
>>     anything wrong.  From there on, forbid full-rebuild changes.
>> 
>>   • Once the “core” subset builds correctly on all the supported
>>     platforms (those that Hydra supports), merge ‘master’.  Maybe update
>>     a couple of things like GnuTLS while we’re at it.  From there on
>>     forbid non-trivial changes.
>> 
>>   • Build all the packages.  (To do that, someone with access to Hydra
>>     must change the “subset” argument to “all” in the config of the
>>     ‘core-updates’ jobset.)
>> 
>>   • Fix things.
>
> We are at this stage... please help :)

Checking in for duty! o7

Here are the results of the latest evaluation:

https://hydra.gnu.org/eval/109570?full=1&compare=master#tabs-now-fail

I cannot reproduce these failures, please try restarting the jobs:

https://hydra.gnu.org/job/gnu/core-updates/c-graph-2.0.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/express-beta-diversity-1.0.7.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/gdm-3.22.1.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/gengetopt-2.22.6.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/libutf-0.0.0-1.ff4c606.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/mupdf-1.10a.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/ghc-mockery-0.3.2.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/gst-plugins-good-1.10.4.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/python-lit-0.5.0.x86_64-linux
https://hydra.gnu.org/job/gnu/core-updates/ruby-concurrent-1.0.2.i686-linux
https://hydra.gnu.org/job/gnu/core-updates/wcslib-5.16.i686-linux

With those out of the way, here are most remaining problems on x86_64:

* aegis
* discrover
* clang-3.5.2 (can this be removed?)
* elixir
* gcc-4.7.4 (likewise)
* glog
* a handful of guile libraries
* hugs (abondoned upstream, no users, remove?)
* khmer
* kodi
* ldc
* powertabeditor
* pspp
* scalapack
* stringtie
* swish-e
* vim-full

Once most of these are fixed, I think we're ready to merge!

Kodi is very interesting, most tests take <1s on 'master', but almost
every test take ~30s on 'core-updates' and invariably segfaults. Any
idea what might be going on?

Likewise, one "vim-full" test is failing on 'core-updates' for no good
reason. I would create an upstream issue if I had any idea what might be
causing it :)

Powertabeditor is likely fixed by an update, but I haven't tried it yet.
Any takers?

For the rest.. please share your findings!

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

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

Marius Bakke <mbakke@fastmail.com> writes:

> Here are the results of the latest evaluation:
>
> https://hydra.gnu.org/eval/109570?full=1&compare=master#tabs-now-fail

[...]

> With those out of the way, here are most remaining problems on x86_64:
>
> * aegis
> * discrover
> * clang-3.5.2 (can this be removed?)
> * elixir
> * gcc-4.7.4 (likewise)
> * glog
> * a handful of guile libraries
> * hugs (abondoned upstream, no users, remove?)
> * khmer
> * kodi
> * ldc
> * powertabeditor
> * pspp
> * scalapack
> * stringtie
> * swish-e
> * vim-full

There is at least one other important package failing: "greenisland". I
wonder why it's no longer listed on the Hydra page.

Anyway, halp wanted :-)

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

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Wed, Mar 29, 2017 at 03:41:56PM +0200, Marius Bakke wrote:
> Here are the results of the latest evaluation:
> 
> https://hydra.gnu.org/eval/109570?full=1&compare=master#tabs-now-fail
> 
> I cannot reproduce these failures, please try restarting the jobs:
> 
> https://hydra.gnu.org/job/gnu/core-updates/c-graph-2.0.x86_64-linux
> https://hydra.gnu.org/job/gnu/core-updates/express-beta-diversity-1.0.7.i686-linux
> https://hydra.gnu.org/job/gnu/core-updates/gdm-3.22.1.x86_64-linux
> https://hydra.gnu.org/job/gnu/core-updates/gengetopt-2.22.6.x86_64-linux
> https://hydra.gnu.org/job/gnu/core-updates/libutf-0.0.0-1.ff4c606.i686-linux
> https://hydra.gnu.org/job/gnu/core-updates/mupdf-1.10a.x86_64-linux
> https://hydra.gnu.org/job/gnu/core-updates/ghc-mockery-0.3.2.i686-linux
> https://hydra.gnu.org/job/gnu/core-updates/gst-plugins-good-1.10.4.i686-linux
> https://hydra.gnu.org/job/gnu/core-updates/python-lit-0.5.0.x86_64-linux
> https://hydra.gnu.org/job/gnu/core-updates/ruby-concurrent-1.0.2.i686-linux
> https://hydra.gnu.org/job/gnu/core-updates/wcslib-5.16.i686-linux

Done. Thank you for the convenient list of links!

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

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Wed, Mar 29, 2017 at 03:41:56PM +0200, Marius Bakke wrote:
> With those out of the way, here are most remaining problems on x86_64:
> 
> * aegis
> * discrover
> * clang-3.5.2 (can this be removed?)
> * elixir
> * gcc-4.7.4 (likewise)
> * glog
> * a handful of guile libraries
> * hugs (abondoned upstream, no users, remove?)
> * khmer
> * kodi
> * ldc
> * powertabeditor
> * pspp
> * scalapack
> * stringtie
> * swish-e
> * vim-full
> 
> Once most of these are fixed, I think we're ready to merge!

Personally, I think it would be ideal to wait until there are no new
failures before merging but, on the other hand, people may not be
willing to fix build failures until `guix pull && guix package -u`
breaks their favorite package.

Let's see what happens :)

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

Re: Let’s freeze and build ‘core-updates’!

[Ricardo Wurmus]

Marius Bakke <mbakke@fastmail.com> writes:

> * discrover

I’ll try to fix this.

> * a handful of guile libraries

Including guile-reader, which has problems with generated code.  Not
sure what to do here.

> * hugs (abondoned upstream, no users, remove?)

Hugs may eventually be needed for bootstrapping GHC.  I’ll try to fix it.

> * khmer
> * ldc
> * powertabeditor

I’ll take care of this one.  Looks like I’d just need to add -lpthread somewhere.

> * pspp

Maybe John can take a look here?

> * stringtie

I’ll try to fix this.

> For the rest.. please share your findings!

I’m still compiling things to update my profile — since more than two
days.

--
Ricardo

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

Re: Let’s freeze and build ‘core-updates’!

[Ricardo Wurmus]

The following packages are now fixed in core-updates:

* discrover
* hugs
* powertabeditor
* stringtie

-- 
Ricardo

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

Re: Let’s freeze and build ‘core-updates’!

[Thomas Danckaert]

From: Marius Bakke <mbakke@fastmail.com>
Subject: Re: Let’s freeze and build ‘core-updates’!
Date: Wed, 29 Mar 2017 15:41:56 +0200

> For the rest.. please share your findings!

Perhaps this is not a “finding”, but just a positive anecdote: I 
reconfigured on core-updates and it's working fine (after an 
afternoon of building nss and webkitgtk).

I'm also happy with jmd's util-linux patch d9804e501 which allows 
mount to find helper programs “mount.<xyz>”.  (I needed that to mount 
cifs/samba shares easily, don't know if anyone else has managed this 
on master?)

Thomas

Re: Let’s freeze and build ‘core-updates’!

[Ludovic Courtès]

Hi!

It looks like we’re doing okay now?  There are still a number of
armhf-linux builds pending, but if everything goes well, I think we
should merge tomorrow (Sunday).  WDYT?

Thanks,
Ludo’.

Re: Let’s freeze and build ‘core-updates’!

[Leo Famulari]

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

On Sun, Apr 02, 2017 at 12:30:28AM +0200, Ludovic Courtès wrote:
> Hi!
> 
> It looks like we’re doing okay now?  There are still a number of
> armhf-linux builds pending, but if everything goes well, I think we
> should merge tomorrow (Sunday).  WDYT?

Yes, I like this plan.

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

Re: Let’s freeze and build ‘core-updates’!

[Ricardo Wurmus]

Leo Famulari <leo@famulari.name> writes:

> On Sun, Apr 02, 2017 at 12:30:28AM +0200, Ludovic Courtès wrote:
>> Hi!
>> 
>> It looks like we’re doing okay now?  There are still a number of
>> armhf-linux builds pending, but if everything goes well, I think we
>> should merge tomorrow (Sunday).  WDYT?
>
> Yes, I like this plan.

Sounds good to me!

-- 
Ricardo

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

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

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

> Hi!
>
> It looks like we’re doing okay now?  There are still a number of
> armhf-linux builds pending, but if everything goes well, I think we
> should merge tomorrow (Sunday).  WDYT?

One "greenisland" test is segfaulting. This package is needed for the
"sddm" display manager, so I don't think we should merge until that is
sorted. I'm looking into it now, but struggling to produce useful
debugging information.

"vim-full" also has a failing test, but is arguably less important.
There are "relink" warnings during the test phase, like this:

Relink `/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28/lib/libpng16.so.16' with `/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0' for IFUNC symbol `longjmp'

...but I'm not sure if it's actually related.

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

Re: Let’s freeze and build ‘core-updates’!

[Ricardo Wurmus]

Marius Bakke <mbakke@fastmail.com> writes:

> "vim-full" also has a failing test, but is arguably less important.
> There are "relink" warnings during the test phase, like this:
>
> Relink `/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28/lib/libpng16.so.16' with `/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0' for IFUNC symbol `longjmp'
>
> ...but I'm not sure if it's actually related.

Hmm, I’ve also seen this when running Lilypond!  I thought it was my
fault.  I don’t know what this means.  Do we need to rebuild libpng?

--
Ricardo

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

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

Ricardo Wurmus <rekado@elephly.net> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> "vim-full" also has a failing test, but is arguably less important.
>> There are "relink" warnings during the test phase, like this:
>>
>> Relink `/gnu/store/vis7x2j2lsmwbl5m5w794c23ysqah8xh-libpng-1.6.28/lib/libpng16.so.16' with `/gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread.so.0' for IFUNC symbol `longjmp'
>>
>> ...but I'm not sure if it's actually related.
>
> Hmm, I’ve also seen this when running Lilypond!  I thought it was my
> fault.  I don’t know what this means.  Do we need to rebuild libpng?

I don't know either, but this topic was discussed recently at [0] and is
apparently a glibc regression [1].

We should probably open a bug for tracking it, since there is likely
more software affected in Guix.

[0] https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00626.html
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21041

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

Re: Let’s freeze and build ‘core-updates’!

[Marius Bakke]

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

Marius Bakke <mbakke@fastmail.com> writes:

> One "greenisland" test is segfaulting. This package is needed for the
> "sddm" display manager, so I don't think we should merge until that is
> sorted. I'm looking into it now, but struggling to produce useful
> debugging information.

Apparently "ctest" will invoke "gdb" for tests if available in PATH. The
stack trace was not very helpful to my untrained eye however..

Given that this software is abandoned upstream, I don't think it's worth
spending a lot of time on maintaining it (our Wayland is newer than the
latest Greenisland release). We'll eventually have to find another
Wayland compositor for SDDM, in the meantime I think it's okay to
disable this test. What do others think?

I've configured my system on 'core-updates' and can confirm that SDDM
works fine (after disabling greenisland tests).

Geronimo? :-)

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

‘core-updates’ merged!

[Ludovic Courtès]

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

Hello Guix!

With the last blocker out of the way, I’ve merged the branch!

The (not so new) news:

  • Updates: glibc 2.25, coreutils 8.26, grep 3.0, guile 2.0.14,
    sed 4.4, tzdata 2017a, etc.

  • Packages are built with GCC 5 (was 4.9).

  • Aarch64 is supported!

  • Reproducibility fixes: new ‘reset-gzip-timestamps’ build phase, use
    of Guile 2.0.14 which produces .go files deterministically,
    ‘perl-build-system’ no longer produces ‘perllocal.pod’ files (which
    were not reproducible).

  • No more broken store references in grafted stuff!
    <https://bugs.gnu.org/24703>

  • Only one entry in ‘GIT_EXEC_PATH’ & co.!
    <https://bugs.gnu.org/25422>

  • GNU/Hurd and powerpc-linux-gnu cross-compilation fixes.

… and probably lots of other things long forgotten.

Thanks to everyone who took the time to address the issues in this
branch!

Enjoy!

Ludo’.

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

Greenisland & SDDM

[Ludovic Courtès]

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

Hi!

Marius Bakke <mbakke@fastmail.com> skribis:

> One "greenisland" test is segfaulting. This package is needed for the
> "sddm" display manager, so I don't think we should merge until that is
> sorted. I'm looking into it now, but struggling to produce useful
> debugging information.

I’ve looked a bit and this seems to be a case of double-free:

--8<---------------cut here---------------start------------->8---
$ valgrind /tmp/guix-build-greenisland-0.9.0.1.drv-0/build/tests/auto/client/tst_client_registry 
==16114== Memcheck, a memory error detector
==16114== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==16114== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==16114== Command: /tmp/guix-build-greenisland-0.9.0.1.drv-0/build/tests/auto/client/tst_client_registry
==16114== 
QML debugging is enabled. Only use this in a safe environment.
********* Start testing of TestRegistry *********
Config: Using QtTest library 5.7.1, Qt 5.7.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 5.4.0)
PASS   : TestRegistry::initTestCase()
==16114== Invalid read of size 4
==16114==    at 0x9E71A94: pthread_mutex_lock (in /gnu/store/rmjlycdgiq8pfy5hfi42qhw3k7p6kdav-glibc-2.25/lib/libpthread-2.25.so)
==16114==    by 0x5556E9F: wl_proxy_destroy (in /gnu/store/syzisi3ib6q406nrxpb4723fhm2cmyml-wayland-1.13.0/lib/libwayland-client.so.0.3.0)
==16114==    by 0x509A42F: wl_registry_destroy (wayland-wayland-client-protocol.h:1065)
==16114==    by 0x509A42F: GreenIsland::Client::RegistryPrivate::~RegistryPrivate() (registry.cpp:121)
==16114==    by 0x509A488: GreenIsland::Client::RegistryPrivate::~RegistryPrivate() (registry.cpp:124)
==16114==    by 0x7C1336B: QObject::~QObject() (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x404D30: ~Registry (registry.h:54)
==16114==    by 0x404D30: testSetup (tst_registry.cpp:108)
==16114==    by 0x404D30: TestRegistry::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) [clone .part.23] (tst_registry.moc:96)
==16114==    by 0x7BED4F9: QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) const (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x4E4A213: ??? (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Test.so.5.7.1)
==16114==    by 0x4E4AB25: ??? (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Test.so.5.7.1)
==16114==    by 0x4E4B111: ??? (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Test.so.5.7.1)
==16114==    by 0x4E4B5E8: QTest::qExec(QObject*, int, char**) (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Test.so.5.7.1)
==16114==    by 0x403C60: main (tst_registry.cpp:306)
==16114==  Address 0x1274e4c0 is 240 bytes inside a block of size 320 free'd
==16114==    at 0x4C2BBD0: free (in /gnu/store/qr7xykwfxav3drx9c2fxazggpl8j9py9-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16114==    by 0x508F305: GreenIsland::Client::ClientConnectionPrivate::~ClientConnectionPrivate() (clientconnection.cpp:61)
==16114==    by 0x508F318: GreenIsland::Client::ClientConnectionPrivate::~ClientConnectionPrivate() (clientconnection.cpp:63)
==16114==    by 0x7C1336B: QObject::~QObject() (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x508FDA6: ~ClientConnection (clientconnection.h:43)
==16114==    by 0x508FDA6: GreenIsland::Client::ClientConnection::~ClientConnection() (clientconnection.h:43)
==16114==    by 0x7C0C887: QObject::event(QEvent*) (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x7BE2879: QCoreApplication::notify(QObject*, QEvent*) (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x7BE29D7: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x7BE4FCA: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x7C32EE2: ??? (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x8CF30D6: g_main_context_dispatch (in /gnu/store/0wps368gx0cn3ynrkbhzq5pxf75rng7y-glib-2.50.3/lib/libglib-2.0.so.0.5000.3)
==16114==    by 0x8CF3307: g_main_context_iterate.isra.29 (in /gnu/store/0wps368gx0cn3ynrkbhzq5pxf75rng7y-glib-2.50.3/lib/libglib-2.0.so.0.5000.3)
==16114==  Block was alloc'd at
==16114==    at 0x4C2C868: calloc (in /gnu/store/qr7xykwfxav3drx9c2fxazggpl8j9py9-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16114==    by 0x555755E: wl_display_connect_to_fd (in /gnu/store/syzisi3ib6q406nrxpb4723fhm2cmyml-wayland-1.13.0/lib/libwayland-client.so.0.3.0)
==16114==    by 0x5557741: wl_display_connect (in /gnu/store/syzisi3ib6q406nrxpb4723fhm2cmyml-wayland-1.13.0/lib/libwayland-client.so.0.3.0)
==16114==    by 0x508F6D3: GreenIsland::Client::ClientConnectionPrivate::_q_initConnection() (clientconnection.cpp:83)
==16114==    by 0x7C0C850: QObject::event(QEvent*) (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x7BE2879: QCoreApplication::notify(QObject*, QEvent*) (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x7BE29D7: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x7BE4FCA: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x7C32EE2: ??? (in /gnu/store/ihjf81is9xh4virnj9k5v87zv3z0idj8-qtbase-5.7.1/lib/libQt5Core.so.5.7.1)
==16114==    by 0x8CF30D6: g_main_context_dispatch (in /gnu/store/0wps368gx0cn3ynrkbhzq5pxf75rng7y-glib-2.50.3/lib/libglib-2.0.so.0.5000.3)
==16114==    by 0x8CF3307: g_main_context_iterate.isra.29 (in /gnu/store/0wps368gx0cn3ynrkbhzq5pxf75rng7y-glib-2.50.3/lib/libglib-2.0.so.0.5000.3)
==16114==    by 0x8CF33AB: g_main_context_iteration (in /gnu/store/0wps368gx0cn3ynrkbhzq5pxf75rng7y-glib-2.50.3/lib/libglib-2.0.so.0.5000.3)
--8<---------------cut here---------------end--------------->8---

However, <https://github.com/greenisland/greenisland> says that it’s
UNMAINTANED (sic), so I wonder what should be done.

Since, SDDM can be built without Greenisland (and thus without Wayland
support I suppose), what about doing just that?

Thanks,
Ludo’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 496 bytes --]

diff --git a/gnu/packages/display-managers.scm b/gnu/packages/display-managers.scm
index 307bc864e..d636fec8c 100644
--- a/gnu/packages/display-managers.scm
+++ b/gnu/packages/display-managers.scm
@@ -140,7 +140,7 @@ Qt-style API for Wayland clients.")
        ("qttools" ,qttools)))
     (inputs
      `(("glib" ,glib)
-       ("greenisland" ,greenisland)
+       ;; ("greenisland" ,greenisland)
        ("libxcb" ,libxcb)
        ("libxkbcommon" ,libxkbcommon)
        ("linux-pam" ,linux-pam)

Re: Greenisland & SDDM

[Marius Bakke]

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

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

> Since, SDDM can be built without Greenisland (and thus without Wayland
> support I suppose), what about doing just that?

I suggested this in [0] and see now that I completely missed Leos reply.

Let's do that. No blockers left from my side, at least.

[0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26200

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

Re: Greenisland & SDDM

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Since, SDDM can be built without Greenisland (and thus without Wayland
>> support I suppose), what about doing just that?
>
> I suggested this in [0] and see now that I completely missed Leos reply.
>
> Let's do that. No blockers left from my side, at least.
>
> [0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26200

Perfect, thanks!

Ludo’.

Let’s merge ‘core-updates’!

[Ludovic Courtès]

Hello Guix!

The ‘core-updates’ branch is in a good shape now, and I think we should
go ahead and merge in the coming days!

Please try to upgrade your system and your user profile to see if
anything’s wrong for you (I did that a few days ago and I’m happy!).

You can test, for example, with:

  guix pull --branch=core-updates -p /tmp/new
  /tmp/new/bin/guix upgrade

You can also check substitute availability:

  /tmp/new/bin/guix weather -c 10

Feedback welcome!

Ludo’.

Re: Let’s merge ‘core-updates’!

[Ludovic Courtès]

Hello Guix!

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

> The ‘core-updates’ branch is in a good shape now, and I think we should
> go ahead and merge in the coming days!

Friends have fixed quite a few things lately, so I’ll merge today.

Please shout now if you’re aware of a blocker!

Ludo’.

Re: Let’s merge ‘core-updates’!

[Marius Bakke]

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

Hallo Ludo,

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

> Hello Guix!
>
> Ludovic Courtès <ludo@gnu.org> skribis:
>
>> The ‘core-updates’ branch is in a good shape now, and I think we should
>> go ahead and merge in the coming days!
>
> Friends have fixed quite a few things lately, so I’ll merge today.
>
> Please shout now if you’re aware of a blocker!

I think <https://issues.guix.gnu.org/issue/37501> should block the
merge.  Otherwise many headless systems will occasionally fail to boot.

(attended systems too, but at least then you have a good meat-based
entropy source at hand)

John Soo reported that adding the urandom-seed-service-type did not
work.  Perhaps it starts after OpenSSH?  I haven't had time to look into
it yet.

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

Re: Let’s merge ‘core-updates’!

[Ludovic Courtès]

Hello Marius!

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello Guix!
>>
>> Ludovic Courtès <ludo@gnu.org> skribis:
>>
>>> The ‘core-updates’ branch is in a good shape now, and I think we should
>>> go ahead and merge in the coming days!
>>
>> Friends have fixed quite a few things lately, so I’ll merge today.
>>
>> Please shout now if you’re aware of a blocker!
>
> I think <https://issues.guix.gnu.org/issue/37501> should block the
> merge.  Otherwise many headless systems will occasionally fail to boot.
>
> (attended systems too, but at least then you have a good meat-based
> entropy source at hand)

I think we made good progress there; there are still unknowns, but at
least we have a workaround (Torvalds’ patch.)

Anything else that should be blocking the merge?

Thanks!

Ludo’.

‘core-updates’ merged!

[Ludovic Courtès]

Hello Guix!

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

>> I think <https://issues.guix.gnu.org/issue/37501> should block the
>> merge.  Otherwise many headless systems will occasionally fail to boot.
>>
>> (attended systems too, but at least then you have a good meat-based
>> entropy source at hand)
>
> I think we made good progress there; there are still unknowns, but at
> least we have a workaround (Torvalds’ patch.)
>
> Anything else that should be blocking the merge?

Apparently not, so I went ahead and merged!

Please email bug-guix@gnu.org if you notice anything wrong.

For the record, there are many novelties: glibc 2.29, the default
compiler is now GCC 7 (was 5.5), there’s the new “reduced binary seed
bootstrap”, and tons of other updates and improvements.

Thanks to everyone who’s been working on this!

Ludo’.

‘core-updates’ freeze approaching!

[Ludovic Courtès]

Hi there!

We’ve been pushing a number a fixes, improvements, and package upgrades
in the ‘core-updates’ branch.

I think it’s time to get ready to merge it, so let’s say we’ll get Hydra
building all of it within a day or two.  Any objections?

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

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

> I think it’s time to get ready to merge it, so let’s say we’ll get Hydra
> building all of it within a day or two.  Any objections?

I’ve just pushed a patch to skip the Coreutils test that was causing
intermittent failures (see <http://bugs.gnu.org/21460>) and Hydra will
soon start rebuilding the ‘core’ package subset.

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

Since we’ve sidestepped the GnuTLS/libtasn1 issue 宋文武 reported by
reverting the libtasn1 upgrade, Hydra is now building all of
‘core-updates’:

  http://hydra.gnu.org/jobset/gnu/core-updates

Please keep an eye on it so we can fix breakage as quickly as possible.

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

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

> Since we’ve sidestepped the GnuTLS/libtasn1 issue 宋文武 reported by
> reverting the libtasn1 upgrade, Hydra is now building all of
> ‘core-updates’:
>
>   http://hydra.gnu.org/jobset/gnu/core-updates
>
> Please keep an eye on it so we can fix breakage as quickly as possible.

The main (only?) remaining blocker now is pixman, where a test segfaults
on i686:

  https://bugs.freedesktop.org/show_bug.cgi?id=92027

I would not be comfortable just skipping tests since this seems to be a
genuine bug.

If someone else familiar with C could look into it, that’d be great.  To
reproduce it, run (on x86_64 or i686):

  ./pre-inst-env guix build pixman -s i686-linux

on a ‘core-updates’ checkout.

Ludo’.

Re: ‘core-updates’ freeze approaching!

[Andreas Enge]

On Thu, Sep 17, 2015 at 10:02:08PM +0200, Ludovic Courtès wrote:
>   https://bugs.freedesktop.org/show_bug.cgi?id=92027

The segfault and the valgrind issue happen in different files, so they
do not seem to be related.

The code before the line where gdb places the error:
Program received signal SIGSEGV, Segmentation fault.
fast_fetch_r5g6b5 (iter=0xffff5e68, mask=0x0) at pixman-fast-path.c:2191
2191		t0 = ((sr << 16) & 0x00FF0000) | ((sg << 8) & 0x0000FF00) |
(gdb) bt
#0  fast_fetch_r5g6b5 (iter=0xffff5e68, mask=0x0) at pixman-fast-path.c:2191

is the following:
    while ((w -= 2) >= 0)
    {
        uint32_t sr, sb, sg, t0, t1;
        uint32_t s = *(const uint32_t *)src;
        src += 2;
        sr = (s >> 8) & 0x00F800F8;
        sb = (s << 3) & 0x00F800F8;
        sg = (s >> 3) & 0x00FC00FC;
        sr |= sr >> 5;
        sb |= sb >> 5;
        sg |= sg >> 6;
        t0 = ((sr << 16) & 0x00FF0000) | ((sg << 8) & 0x0000FF00) |
             (sb & 0xFF) | 0xFF000000;

This looks perfectly safe; all treated variables are scalars, so the result
may be wrong, but cannot cause a segfault. A problem with optimisation in gcc?
Or gdb giving a wrong line number? Since pointers are dereferenced before and
after that line.

I also tried to cd into /tmp/nix-build-..., source the environment variables
and run "make check"; then all tests pass (but the build is for i686-linux
on an x86_64-machine, so maybe this does not mean much outside the guix build
container?).

Andreas

Re: ‘core-updates’ freeze approaching!

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Sep 17, 2015 at 10:02:08PM +0200, Ludovic Courtès wrote:
>>   https://bugs.freedesktop.org/show_bug.cgi?id=92027
>
> The segfault and the valgrind issue happen in different files, so they
> do not seem to be related.

[...]

> I also tried to cd into /tmp/nix-build-..., source the environment variables
> and run "make check"; then all tests pass (but the build is for i686-linux
> on an x86_64-machine, so maybe this does not mean much outside the guix build
> container?).

With the patch applied (the patch I attached to the above bug report),
the problem indeed vanishes when outside of the build container, like
you describe.

Without the patch the problem is 100% reproducible both inside and
outside of the build container.

Ludo’.

‘core-updates’ merged!

[Ludovic Courtès]

Hi!

At last ‘core-updates’ is merged!

This brings:

  • Security fixes in icu4c (CVE-2014-6585 and CVE-2015-1270.)

  • libc 2.22–make sure to read
    <https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00717.html>
    before you upgrade!

  • New ‘install-file’ procedure in (guix build utils); consider using
    it where appropriate.

  • Patched tarballs are produced in a deterministic fashion (file
    ordering and time stamps.)

  • The closure size of openssl, curl, libtiff, libx11, libxt has been
    reduced.

  • ‘glib-or-gtk-build-system’ no longer generates icon-theme.cache
    since this is handled during profile generation.  This avoids
    collisions.

  • ‘glibc’ no longer provides bin/bash.

  • Many upgrades.

Ludo’.