Re: Let’s freeze and build ‘core-updates’!
Ricardo Wurmus writes: > Marius Bakke 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 signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Marius Bakke 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? :-) signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Marius Bakke 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’!
Ludovic Courtès 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. signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Leo Famulari 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’!
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. signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
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’!
From: Marius Bakke 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.”. (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’!
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’!
Marius Bakke 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’!
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 :) signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
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! signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Marius Bakke 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 :-) signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Leo Famulari 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! signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Thomas Danckaert writes: > From: Leo Famulari > 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’!
From: Leo Famulari 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’!
On Tue, Mar 21, 2017 at 10:19:02PM +0100, Julien Lepiller wrote: > On Mon, 20 Mar 2017 14:41:45 -0400 > Leo Famulari 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. signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Julien Lepiller 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’!
On Mon, 20 Mar 2017 14:41:45 -0400 Leo Famulari 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’!
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. signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
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’!
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 :) signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
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! signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Leo Famulari 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? :) signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
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’!
On Wed, Mar 08, 2017 at 09:44:26AM +0100, Ludovic Courtès wrote: > Leo Famulari 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 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 > 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 > 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’!
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
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:
+ ;;
+ (add-before 'configure 'bootstrap
+ (lambda _ (zero? (system* "autoreconf" "-vfi"
(add-before
'configure 'pre-configure
(lambda _
--
2.12.0
From 3601571063aa0317720d19d83f1cb42745abd5f8 Mon Sep 17 00:00:00 2001
From: Leo Famulari
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
signature.asc
Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Leo Famulari 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’!
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’!
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 signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
On Mon, Mar 06, 2017 at 07:49:42PM +0100, Marius Bakke wrote: > Leo Famulari 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? signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Marius Bakke writes: > Leo Famulari 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. signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Leo Famulari 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. signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
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 skribis: > Ludovic Courtès 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’!
Ludovic Courtès 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 signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
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’!
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’!
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. signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
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 signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Ludovic Courtès writes: > Hey Marius, > > Marius Bakke skribis: > >> Ludovic Courtès 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? signature.asc Description: PGP signature
Re: Let’s freeze and build ‘core-updates’!
Hey Marius, Marius Bakke skribis: > Ludovic Courtès 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’!
Ludovic Courtès 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? signature.asc Description: PGP signature
