Staging

Staging

[Leo Famulari]

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

On Mon, Apr 17, 2017 at 09:33:12PM +0200, Marius Bakke wrote:
> @Leo, others: I don't anticipate more staging updates in a while, should
> we try and get this merged?

Sure, I merged master into staging and started an evaluation of the
staging branch.

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

Re: Staging

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> On Mon, Apr 17, 2017 at 09:33:12PM +0200, Marius Bakke wrote:
>> @Leo, others: I don't anticipate more staging updates in a while, should
>> we try and get this merged?
>
> Sure, I merged master into staging and started an evaluation of the
> staging branch.

"mesa" failed the same test on both i686 and armhf:

https://hydra.gnu.org/job/gnu/staging/mesa-17.0.4.i686-linux
https://hydra.gnu.org/job/gnu/staging/mesa-17.0.4.armhf-linux

Oddly, I'm not able to reproduce it when compiling on x86_64:

$ ./pre-inst-env guix build --system=i686-linux mesa
[...]
/gnu/store/kkpq84ki2ipjcn9nhywgm2ww9c5ddlaq-mesa-17.0.4

Can someone with a native machine get the "test-suite.log" of the
failing test?

I pushed a patch that should hopefully fix the "libsndfile" 1.0.28 armhf
failure. We should probably pick it to the graft on 'master' if it
works and staging drags out.

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

[staging] Mesa FTBFS on 32-bit architectures

[Leo Famulari]

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

On Tue, Apr 18, 2017 at 07:00:37PM +0200, Marius Bakke wrote:
> "mesa" failed the same test on both i686 and armhf:
> 
> https://hydra.gnu.org/job/gnu/staging/mesa-17.0.4.i686-linux
> https://hydra.gnu.org/job/gnu/staging/mesa-17.0.4.armhf-linux
> 
> Oddly, I'm not able to reproduce it when compiling on x86_64:
> 
> $ ./pre-inst-env guix build --system=i686-linux mesa
> [...]
> /gnu/store/kkpq84ki2ipjcn9nhywgm2ww9c5ddlaq-mesa-17.0.4
> 
> Can someone with a native machine get the "test-suite.log" of the
> failing test?

The test, glsl/tests/cache-test, failed for me on x86_64 when building
for i686-linux.

I've attached '/mesa-17.0.4/src/compiler/test-suite.log'.

It's been discussed upstream here:

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

Apparently, this is the upstream fix:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=d7b3707c612027b354deea6bc5eae56a02d5f8d5

[-- Attachment #1.2: test-suite.log --]
[-- Type: text/plain, Size: 736 bytes --]

==============================================
   Mesa 17.0.4: src/compiler/test-suite.log
==============================================

# TOTAL: 10
# PASS:  9
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: glsl/tests/cache-test
===========================

Failed to create ./cache-test-tmp/xdg-cache-home for shader cache (No such file or directory)---disabling.
Failed to create ./cache-test-tmp/mesa-glsl-cache-dir for shader cache (No such file or directory)---disabling.
Error: Test 'no eviction before overflow with MAX_SIZE=1M' failed: Expected=3, Actual=2
Error: Test 'eviction after overflow with MAX_SIZE=1M' failed: Expected=2, Actual=1
FAIL glsl/tests/cache-test (exit status: 1)


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

Re: [staging] Mesa FTBFS on 32-bit architectures

[Leo Famulari]

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

On Tue, Apr 18, 2017 at 02:52:18PM -0400, Leo Famulari wrote:
> It's been discussed upstream here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=97967

Ah, this appears to be slightly different than our issue.

> Apparently, this is the upstream fix:
> 
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=d7b3707c612027b354deea6bc5eae56a02d5f8d5

And this commit was cherry-picked into 17.0.4 as
269266359967be69f39d9aa2cddbe1faeb2eaa36.

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

Re: [staging] Mesa FTBFS on 32-bit architectures

[Leo Famulari]

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

On Tue, Apr 18, 2017 at 02:52:18PM -0400, Leo Famulari wrote:
> FAIL: glsl/tests/cache-test
> ===========================
> 
> Failed to create ./cache-test-tmp/xdg-cache-home for shader cache (No such file or directory)---disabling.
> Failed to create ./cache-test-tmp/mesa-glsl-cache-dir for shader cache (No such file or directory)---disabling.
> Error: Test 'no eviction before overflow with MAX_SIZE=1M' failed: Expected=3, Actual=2
> Error: Test 'eviction after overflow with MAX_SIZE=1M' failed: Expected=2, Actual=1
> FAIL glsl/tests/cache-test (exit status: 1)
 
Gentoo's bug report for this issue (no resolution yet):

https://bugs.gentoo.org/show_bug.cgi?id=613644

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

Re: [staging] Mesa FTBFS on 32-bit architectures

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> On Tue, Apr 18, 2017 at 07:00:37PM +0200, Marius Bakke wrote:
>> "mesa" failed the same test on both i686 and armhf:
>> 
>> https://hydra.gnu.org/job/gnu/staging/mesa-17.0.4.i686-linux
>> https://hydra.gnu.org/job/gnu/staging/mesa-17.0.4.armhf-linux
>> 
>> Oddly, I'm not able to reproduce it when compiling on x86_64:
>> 
>> $ ./pre-inst-env guix build --system=i686-linux mesa
>> [...]
>> /gnu/store/kkpq84ki2ipjcn9nhywgm2ww9c5ddlaq-mesa-17.0.4
>> 
>> Can someone with a native machine get the "test-suite.log" of the
>> failing test?
>
> The test, glsl/tests/cache-test, failed for me on x86_64 when building
> for i686-linux.
>
> I've attached '/mesa-17.0.4/src/compiler/test-suite.log'.

[...]

> FAIL: glsl/tests/cache-test
> ===========================
>
> Failed to create ./cache-test-tmp/xdg-cache-home for shader cache (No such file or directory)---disabling.
> Failed to create ./cache-test-tmp/mesa-glsl-cache-dir for shader cache (No such file or directory)---disabling.
> Error: Test 'no eviction before overflow with MAX_SIZE=1M' failed: Expected=3, Actual=2
> Error: Test 'eviction after overflow with MAX_SIZE=1M' failed: Expected=2, Actual=1
> FAIL glsl/tests/cache-test (exit status: 1)

I am able reproduce this failure on a foreign distro (Jessie with
backported kernel), but not on GuixSD. I wonder what that's about, the
built libraries are indeed 32-bit.

Anyway, this commit seems to fix the issue:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=4026b45bbc4c2c067feeee181c54e2beaa1cc5e0

Patch attached. WDYT?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-gnu-mesa-Fix-build-on-32-bit-architectures.patch --]
[-- Type: text/x-patch, Size: 3661 bytes --]

From 3c5e9f124615501a081dc2c24d1e3e68c65c6ace Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Wed, 19 Apr 2017 01:35:45 +0200
Subject: [PATCH] gnu: mesa: Fix build on 32-bit architectures.

* gnu/packages/patches/mesa-fix-disk-cache-test-32bit.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/gl.scm (mesa)[source]: Use it.
---
 gnu/local.mk                                       |  1 +
 gnu/packages/gl.scm                                |  1 +
 .../patches/mesa-fix-disk-cache-test-32bit.patch   | 47 ++++++++++++++++++++++
 3 files changed, 49 insertions(+)
 create mode 100644 gnu/packages/patches/mesa-fix-disk-cache-test-32bit.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index e6dee5839..55fa4f970 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -776,6 +776,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/mcrypt-CVE-2012-4409.patch			\
   %D%/packages/patches/mcrypt-CVE-2012-4426.patch			\
   %D%/packages/patches/mcrypt-CVE-2012-4527.patch			\
+  %D%/packages/patches/mesa-fix-disk-cache-test-32bit.patch	\
   %D%/packages/patches/mesa-skip-disk-cache-test.patch		\
   %D%/packages/patches/mesa-wayland-egl-symbols-check-mips.patch	\
   %D%/packages/patches/metabat-remove-compilation-date.patch	\
diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index f43f46439..f19b59d2c 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -230,6 +230,7 @@ also known as DXTn or DXTC) for Mesa.")
           "0im3ca1vwwmkjf5w761vh7vabr4vrrdxpckr0wm974x18n2xqs8j"))
         (patches
          (search-patches "mesa-wayland-egl-symbols-check-mips.patch"
+                         "mesa-fix-disk-cache-test-32bit.patch"
                          "mesa-skip-disk-cache-test.patch"))))
     (build-system gnu-build-system)
     (propagated-inputs
diff --git a/gnu/packages/patches/mesa-fix-disk-cache-test-32bit.patch b/gnu/packages/patches/mesa-fix-disk-cache-test-32bit.patch
new file mode 100644
index 000000000..c5a60fdef
--- /dev/null
+++ b/gnu/packages/patches/mesa-fix-disk-cache-test-32bit.patch
@@ -0,0 +1,47 @@
+This fixes a test failure on 32bit architectures.
+
+Patch adapted from upstream source repository:
+
+https://cgit.freedesktop.org/mesa/mesa/commit/?id=61bbb25a080e48a8ca897ba7f6e73cc6a8e9b5b8
+
+From a2121a13b912c5c3cc2aa22009c978b69b3bbadc Mon Sep 17 00:00:00 2001
+From: Grazvydas Ignotas <notasas@gmail.com>
+Date: Thu, 9 Mar 2017 02:54:53 +0200
+Subject: [PATCH] util/disk_cache: fix size subtraction on 32bit
+
+Negating size_t on 32bit produces a 32bit result. This was effectively
+adding values close to UINT_MAX to the cache size (the files are usually
+small) instead of intended subtraction.
+Fixes 'make check' disk_cache failures on 32bit.
+
+Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
+Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
+---
+ src/util/disk_cache.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
+index d3e8b40123..ea7832d29e 100644
+--- a/src/util/disk_cache.c
++++ b/src/util/disk_cache.c
+@@ -521,7 +521,7 @@ evict_random_item(struct disk_cache *cache)
+    free(dir_path);
+ 
+    if (size) {
+-      p_atomic_add(cache->size, - size);
++      p_atomic_add(cache->size, - (uint64_t)size);
+       return;
+    }
+ 
+@@ -542,7 +542,7 @@ evict_random_item(struct disk_cache *cache)
+    free(dir_path);
+ 
+    if (size)
+-      p_atomic_add(cache->size, - size);
++      p_atomic_add(cache->size, - (uint64_t)size);
+ }
+ 
+ void
+-- 
+2.12.2
+
-- 
2.12.2


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

Re: [staging] Mesa FTBFS on 32-bit architectures

[Leo Famulari]

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

On Tue, Apr 18, 2017 at 02:52:18PM -0400, Leo Famulari wrote:
> ==============================================
>    Mesa 17.0.4: src/compiler/test-suite.log
> ==============================================
> 
> # TOTAL: 10
> # PASS:  9
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> .. contents:: :depth: 2
> 
> FAIL: glsl/tests/cache-test
> ===========================
> 
> Failed to create ./cache-test-tmp/xdg-cache-home for shader cache (No such file or directory)---disabling.
> Failed to create ./cache-test-tmp/mesa-glsl-cache-dir for shader cache (No such file or directory)---disabling.
> Error: Test 'no eviction before overflow with MAX_SIZE=1M' failed: Expected=3, Actual=2
> Error: Test 'eviction after overflow with MAX_SIZE=1M' failed: Expected=2, Actual=1
> FAIL glsl/tests/cache-test (exit status: 1)

I'm testing the build with this commit cherry-picked, minus the 3rd hunk
(does not apply to mesa 17.0.4):

https://cgit.freedesktop.org/mesa/mesa/commit/?id=61bbb25a080e48a8ca897ba7f6e73cc6a8e9b5b8



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

Re: [staging] Mesa FTBFS on 32-bit architectures

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> On Tue, Apr 18, 2017 at 02:52:18PM -0400, Leo Famulari wrote:
>> ==============================================
>>    Mesa 17.0.4: src/compiler/test-suite.log
>> ==============================================
>> 
>> # TOTAL: 10
>> # PASS:  9
>> # SKIP:  0
>> # XFAIL: 0
>> # FAIL:  1
>> # XPASS: 0
>> # ERROR: 0
>> 
>> .. contents:: :depth: 2
>> 
>> FAIL: glsl/tests/cache-test
>> ===========================
>> 
>> Failed to create ./cache-test-tmp/xdg-cache-home for shader cache (No such file or directory)---disabling.
>> Failed to create ./cache-test-tmp/mesa-glsl-cache-dir for shader cache (No such file or directory)---disabling.
>> Error: Test 'no eviction before overflow with MAX_SIZE=1M' failed: Expected=3, Actual=2
>> Error: Test 'eviction after overflow with MAX_SIZE=1M' failed: Expected=2, Actual=1
>> FAIL glsl/tests/cache-test (exit status: 1)
>
> I'm testing the build with this commit cherry-picked, minus the 3rd hunk
> (does not apply to mesa 17.0.4):
>
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=61bbb25a080e48a8ca897ba7f6e73cc6a8e9b5b8

Oops, that is indeed the commit in my patch earlier. Not sure what went
wrong with the copy-paste!

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

Re: [staging] Mesa FTBFS on 32-bit architectures

[Leo Famulari]

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

On Wed, Apr 19, 2017 at 02:17:20AM +0200, Marius Bakke wrote:
> Oops, that is indeed the commit in my patch earlier. Not sure what went
> wrong with the copy-paste!

Haha, oops! Looks like we both charged ahead trying to fix this :)

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

Re: [staging] Mesa FTBFS on 32-bit architectures

[Leo Famulari]

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

On Tue, Apr 18, 2017 at 08:13:58PM -0400, Leo Famulari wrote:
> On Tue, Apr 18, 2017 at 02:52:18PM -0400, Leo Famulari wrote:
> > ==============================================
> >    Mesa 17.0.4: src/compiler/test-suite.log
> > ==============================================
> > 
> > # TOTAL: 10
> > # PASS:  9
> > # SKIP:  0
> > # XFAIL: 0
> > # FAIL:  1
> > # XPASS: 0
> > # ERROR: 0
> > 
> > .. contents:: :depth: 2
> > 
> > FAIL: glsl/tests/cache-test
> > ===========================
> > 
> > Failed to create ./cache-test-tmp/xdg-cache-home for shader cache (No such file or directory)---disabling.
> > Failed to create ./cache-test-tmp/mesa-glsl-cache-dir for shader cache (No such file or directory)---disabling.
> > Error: Test 'no eviction before overflow with MAX_SIZE=1M' failed: Expected=3, Actual=2
> > Error: Test 'eviction after overflow with MAX_SIZE=1M' failed: Expected=2, Actual=1
> > FAIL glsl/tests/cache-test (exit status: 1)
> 
> I'm testing the build with this commit cherry-picked, minus the 3rd hunk
> (does not apply to mesa 17.0.4):
> 
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=61bbb25a080e48a8ca897ba7f6e73cc6a8e9b5b8

It worked for me, so I pushed the change as
165d45540a879c4b1d8b8aeb5a3c79bda91b7641 and started a new evaluation
of the staging branch.

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

Re: Staging

[Marius Bakke]

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

Looks like the queue was cancelled.

https://hydra.gnu.org/eval/109614?compare=master

Should we try to build out the remaining packages? There have been a few
large updates in 'master', might be useful to merge that first. Or just
go the other way around.. ;-)

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

Re: Staging

[Leo Famulari]

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

On Fri, Apr 21, 2017 at 03:57:41PM +0200, Marius Bakke wrote:
> Looks like the queue was cancelled.
> 
> https://hydra.gnu.org/eval/109614?compare=master
> 
> Should we try to build out the remaining packages? There have been a few
> large updates in 'master', might be useful to merge that first. Or just
> go the other way around.. ;-)

Most likely the queue was paused to make way for the security-updates
jobset:

https://hydra.gnu.org/jobset/gnu/security-updates

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

Re: Staging

[Mark H Weaver]

Leo Famulari <leo@famulari.name> writes:

> On Fri, Apr 21, 2017 at 03:57:41PM +0200, Marius Bakke wrote:
>> Looks like the queue was cancelled.
>> 
>> https://hydra.gnu.org/eval/109614?compare=master
>> 
>> Should we try to build out the remaining packages? There have been a few
>> large updates in 'master', might be useful to merge that first. Or just
>> go the other way around.. ;-)
>
> Most likely the queue was paused to make way for the security-updates
> jobset:
>
> https://hydra.gnu.org/jobset/gnu/security-updates

Yes, I cancelled the builds in 'staging' so that Hydra would focus on
rebuilding 'security-updates', whose patches have since been applied to
master.

Unfortunately, the recent 'imlib2' update rendered most of that
rebuilding obsolete, and now we need to rebuild the web browsers,
libreoffice, and Qt/KDE all over again.  Oh well.

Anyway, here's what I'd recommend: after the most important packages are
rebuilt on 'master', let's merge 'master' into 'staging' and start
another evaluation of 'staging'.

What do you think?

      Mark

Re: Staging

[Leo Famulari]

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

On Fri, Apr 21, 2017 at 02:59:23PM -0400, Mark H Weaver wrote:
> Yes, I cancelled the builds in 'staging' so that Hydra would focus on
> rebuilding 'security-updates', whose patches have since been applied to
> master.
> 
> Unfortunately, the recent 'imlib2' update rendered most of that
> rebuilding obsolete, and now we need to rebuild the web browsers,
> libreoffice, and Qt/KDE all over again.  Oh well.

Bah... libreoffice is especially annoying since it's very expensive to
build but also has a huge dependency graph.

> Anyway, here's what I'd recommend: after the most important packages are
> rebuilt on 'master', let's merge 'master' into 'staging' and start
> another evaluation of 'staging'.
> 
> What do you think?

Sure, hopefully it will be ready later today; I'll pay attention.

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

Re: Staging

[Marius Bakke]

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

The master queue has cleared, so let's get this started again :)

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

Re: Staging

[Marius Bakke]

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

Marius Bakke <mbakke@fastmail.com> writes:

> The master queue has cleared, so let's get this started again :)

Uh, never mind, I see there is a pending evaluation for some time.
Hopefully it won't time out (what's up with that, anyway).

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

Re: Staging

[Leo Famulari]

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

On Mon, Apr 17, 2017 at 04:09:01PM -0400, Leo Famulari wrote:
> On Mon, Apr 17, 2017 at 09:33:12PM +0200, Marius Bakke wrote:
> > @Leo, others: I don't anticipate more staging updates in a while, should
> > we try and get this merged?
> 
> Sure, I merged master into staging and started an evaluation of the
> staging branch.

I just merged master into staging and started a new evaluation. Barring
any new complications, I plan to merge staging into master later today.

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

Staging merged!

[Leo Famulari]

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

On Tue, Apr 25, 2017 at 02:33:13PM -0400, Leo Famulari wrote:
> I just merged master into staging and started a new evaluation. Barring
> any new complications, I plan to merge staging into master later today.

I merged the staging branch into the master branch as
2018eea07bb00663d2f0cec9d9085d51afa4513b and started a new evaluation.
Most of the substitutes should already be available.

Some notable changes are updates to mesa, xorg-server, gtk+, and tzdata.

Thanks to Marius for working on the branch!

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

Re: Staging merged!

[Ricardo Wurmus]

Leo Famulari <leo@famulari.name> writes:

> On Tue, Apr 25, 2017 at 02:33:13PM -0400, Leo Famulari wrote:
>> I just merged master into staging and started a new evaluation. Barring
>> any new complications, I plan to merge staging into master later today.
>
> I merged the staging branch into the master branch as
> 2018eea07bb00663d2f0cec9d9085d51afa4513b and started a new evaluation.
> Most of the substitutes should already be available.
>
> Some notable changes are updates to mesa, xorg-server, gtk+, and tzdata.
>
> Thanks to Marius for working on the branch!

Yay, thanks a lot for taking care of this!

-- 
Ricardo

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

Re: Staging merged!

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Tue, Apr 25, 2017 at 02:33:13PM -0400, Leo Famulari wrote:
>>> I just merged master into staging and started a new evaluation. Barring
>>> any new complications, I plan to merge staging into master later today.
>>
>> I merged the staging branch into the master branch as
>> 2018eea07bb00663d2f0cec9d9085d51afa4513b and started a new evaluation.
>> Most of the substitutes should already be available.
>>
>> Some notable changes are updates to mesa, xorg-server, gtk+, and tzdata.
>>
>> Thanks to Marius for working on the branch!
>
> Yay, thanks a lot for taking care of this!

Woohoo, thank you!

Ludo’.

Staging

[Leo Famulari]

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

There are some patches on the staging branch, including an update to the
time zone database.

What are the plans for the next week or so? Should we try merging the
staging branch in that timeframe?

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

Re: Staging

[Marius Bakke]

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

Leo Famulari <leo@famulari.name> writes:

> There are some patches on the staging branch, including an update to the
> time zone database.
>
> What are the plans for the next week or so? Should we try merging the
> staging branch in that timeframe?

Yes, let's start this in a few days, when Hydra calms down.  Perhaps we
can include the Java updates discussed in
<https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00383.html> as
well.  Ricardo, WDYT?

I have a handful more updates in my queue and will try to get them done
by tomorrow.

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

Re: Staging

[Efraim Flashner]

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

On Tue, Feb 20, 2018 at 04:54:36AM +0100, Marius Bakke wrote:
> Leo Famulari <leo@famulari.name> writes:
> 
> > There are some patches on the staging branch, including an update to the
> > time zone database.
> >
> > What are the plans for the next week or so? Should we try merging the
> > staging branch in that timeframe?
> 
> Yes, let's start this in a few days, when Hydra calms down.  Perhaps we
> can include the Java updates discussed in
> <https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00383.html> as
> well.  Ricardo, WDYT?
> 
> I have a handful more updates in my queue and will try to get them done
> by tomorrow.

Java currently only affects x86_64, so I'm not sure that it would need
to be staging specifically. In any case if we can get it merged within
the next week or so that'd be amazing. I know our cmake is in need of an
upgrade, maybe libva?


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: Staging

[Leo Famulari]

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

On Tue, Feb 20, 2018 at 11:45:58AM +0200, Efraim Flashner wrote:
> Java currently only affects x86_64, so I'm not sure that it would need
> to be staging specifically. In any case if we can get it merged within
> the next week or so that'd be amazing. I know our cmake is in need of an
> upgrade, maybe libva?

Are there any specific issues that would be fixed by a CMake update, or
is it just "too old"? I think that changes on the staging branch should
have a low probability of breaking things, so that we can finish the
branch quickly.

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

Re: Staging

[Andreas Enge]

On Tue, Feb 20, 2018 at 06:57:06AM -0500, Leo Famulari wrote:
> On Tue, Feb 20, 2018 at 11:45:58AM +0200, Efraim Flashner wrote:
> > Java currently only affects x86_64, so I'm not sure that it would need
> > to be staging specifically. In any case if we can get it merged within
> > the next week or so that'd be amazing. I know our cmake is in need of an
> > upgrade, maybe libva?
> 
> Are there any specific issues that would be fixed by a CMake update, or
> is it just "too old"? I think that changes on the staging branch should
> have a low probability of breaking things, so that we can finish the
> branch quickly.

Could we stage things on the staging branch? Do a few updates now, merge
quickly, and then try to update only cmake in the next run?

Andreas

Re: Staging

[Arun Isaac]

>> I know our cmake is in need of an upgrade

I submitted a patchset for updating cmake a couple of weeks ago.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30390

Re: Staging

[Efraim Flashner]

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

On Tue, Feb 20, 2018 at 01:07:11PM +0100, Andreas Enge wrote:
> On Tue, Feb 20, 2018 at 06:57:06AM -0500, Leo Famulari wrote:
> > On Tue, Feb 20, 2018 at 11:45:58AM +0200, Efraim Flashner wrote:
> > > Java currently only affects x86_64, so I'm not sure that it would need
> > > to be staging specifically. In any case if we can get it merged within
> > > the next week or so that'd be amazing. I know our cmake is in need of an
> > > upgrade, maybe libva?
> > 
> > Are there any specific issues that would be fixed by a CMake update, or
> > is it just "too old"? I think that changes on the staging branch should
> > have a low probability of breaking things, so that we can finish the
> > branch quickly.
> 
> Could we stage things on the staging branch? Do a few updates now, merge
> quickly, and then try to update only cmake in the next run?
> 

CMake is just old, not especially in need of updates. It would be nice
to ungraft stuff though.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: Staging

[Andreas Enge]

On Tue, Feb 20, 2018 at 03:14:39PM +0200, Efraim Flashner wrote:
> CMake is just old, not especially in need of updates. It would be nice
> to ungraft stuff though.

I just meant to not switch cmake versions together with other things:

$ ./pre-inst-env guix refresh -l cmake
Building the following 1007 packages would ensure 2499 dependent packages are rebuilt

A lot depends on cmake, so we can expect some breakage, and mixing this with
other potential sources of breakage would make it more difficult to diagnose.

Andreas

Re: Staging

[Efraim Flashner]

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

On Tue, Feb 20, 2018 at 02:17:59PM +0100, Andreas Enge wrote:
> On Tue, Feb 20, 2018 at 03:14:39PM +0200, Efraim Flashner wrote:
> > CMake is just old, not especially in need of updates. It would be nice
> > to ungraft stuff though.
> 
> I just meant to not switch cmake versions together with other things:
> 
> $ ./pre-inst-env guix refresh -l cmake
> Building the following 1007 packages would ensure 2499 dependent packages are rebuilt
> 
> A lot depends on cmake, so we can expect some breakage, and mixing this with
> other potential sources of breakage would make it more difficult to diagnose.
> 
> Andreas
> 

Works for me. Plus if we have a short staging cycle we can do it more
often¹.

¹hydra permitting

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: Staging

[Ludovic Courtès]

Efraim Flashner <efraim@flashner.co.il> skribis:

> On Tue, Feb 20, 2018 at 02:17:59PM +0100, Andreas Enge wrote:
>> On Tue, Feb 20, 2018 at 03:14:39PM +0200, Efraim Flashner wrote:
>> > CMake is just old, not especially in need of updates. It would be nice
>> > to ungraft stuff though.
>> 
>> I just meant to not switch cmake versions together with other things:
>> 
>> $ ./pre-inst-env guix refresh -l cmake
>> Building the following 1007 packages would ensure 2499 dependent packages are rebuilt
>> 
>> A lot depends on cmake, so we can expect some breakage, and mixing this with
>> other potential sources of breakage would make it more difficult to diagnose.
>> 
>> Andreas
>> 
>
> Works for me. Plus if we have a short staging cycle we can do it more
> often¹.
>
> ¹hydra permitting

Note that berlin is building master, core-updates (the ‘core’ subset of
packages), and staging right now.  The web interface isn’t very helpful
yet, but if it’s an option for you, you can use
‘M-x guix-hydra-latest-builds’ in Emacs, or just check the availability
of substitutes.

Ludo’.

Re: Staging

[Leo Famulari]

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

On Tue, Feb 20, 2018 at 04:54:36AM +0100, Marius Bakke wrote:
> Leo Famulari <leo@famulari.name> writes:
> 
> > There are some patches on the staging branch, including an update to the
> > time zone database.
> >
> > What are the plans for the next week or so? Should we try merging the
> > staging branch in that timeframe?
> 
> Yes, let's start this in a few days, when Hydra calms down.

Unless something comes up, I'll start an evaluation of the staging
branch tomorrow.

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

Re: Staging

[Leo Famulari]

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

On Wed, Feb 21, 2018 at 01:22:16PM -0500, Leo Famulari wrote:
> On Tue, Feb 20, 2018 at 04:54:36AM +0100, Marius Bakke wrote:
> > Leo Famulari <leo@famulari.name> writes:
> > 
> > > There are some patches on the staging branch, including an update to the
> > > time zone database.
> > >
> > > What are the plans for the next week or so? Should we try merging the
> > > staging branch in that timeframe?
> > 
> > Yes, let's start this in a few days, when Hydra calms down.
> 
> Unless something comes up, I'll start an evaluation of the staging
> branch tomorrow.

I've requested a new evaluation of the staging branch on Hydra.

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

Re: Staging

[Ricardo Wurmus]

Marius Bakke <mbakke@fastmail.com> writes:

> Yes, let's start this in a few days, when Hydra calms down.  Perhaps we
> can include the Java updates discussed in
> <https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00383.html> as
> well.  Ricardo, WDYT?

I didn’t have any time yet to check the Java updates, but they don’t
really affect many packages anyway (other than Java packages), so I
don’t think they’re all that critical.

-- 
Ricardo

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

Re: Staging

[Gábor Boskovits]

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

2018-02-22 18:09 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Marius Bakke <mbakke@fastmail.com> writes:
>
> > Yes, let's start this in a few days, when Hydra calms down.  Perhaps we
> > can include the Java updates discussed in
> > <https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00383.html> as
> > well.  Ricardo, WDYT?
>
> I didn’t have any time yet to check the Java updates, but they don’t
> really affect many packages anyway (other than Java packages), so I
> don’t think they’re all that critical.
>
>
I tend to agree. The whole jdk closure is about 200 packages.
Packages patched to work with java8 is on the order of 50, or so.

Even if 200 is too much, we can delay flipping the defaults. Then the
50 in need of individual patches can go in. WDYT?


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

[-- Attachment #2: Type: text/html, Size: 1841 bytes --]