Staging freeze

Staging freeze

[Leo Famulari]

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

The last staging branch was merged into the master branch on December
11.

According to the 3 week staging cycle we are trying to adhere to [0],
this would mean we freeze the current branch on December 25 and try to
merge it on January 1.

These dates are inconvenient for many people. I propose we freeze the
branch and start building on December 27, and try to merge on January 3.

[0]
http://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html

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

Re: Staging freeze

[John Darrington]

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

On Fri, Dec 23, 2016 at 12:23:39AM -0500, Leo Famulari wrote:
     The last staging branch was merged into the master branch on December
     11.
     
     According to the 3 week staging cycle we are trying to adhere to [0],
     this would mean we freeze the current branch on December 25 and try to
     merge it on January 1.
     
     These dates are inconvenient for many people. I propose we freeze the
     branch and start building on December 27, and try to merge on January 3.
     
     [0]
     http://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html


Sounds good to me.

J'



-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Staging freeze

[Leo Famulari]

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

On Fri, Dec 23, 2016 at 07:00:38AM +0100, John Darrington wrote:
> On Fri, Dec 23, 2016 at 12:23:39AM -0500, Leo Famulari wrote:
>      The last staging branch was merged into the master branch on December
>      11.
>      
>      According to the 3 week staging cycle we are trying to adhere to [0],
>      this would mean we freeze the current branch on December 25 and try to
>      merge it on January 1.
>      
>      These dates are inconvenient for many people. I propose we freeze the
>      branch and start building on December 27, and try to merge on January 3.
>      
>      [0]
>      http://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html
> 
> 
> Sounds good to me.

I'll start the evaluation of the staging branch in ~12 hours.

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

Re: Staging freeze

[Leo Famulari]

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

On Fri, Dec 23, 2016 at 12:23:39AM -0500, Leo Famulari wrote:
> The last staging branch was merged into the master branch on December
> 11.
> 
> According to the 3 week staging cycle we are trying to adhere to [0],
> this would mean we freeze the current branch on December 25 and try to
> merge it on January 1.
> 
> These dates are inconvenient for many people. I propose we freeze the
> branch and start building on December 27, and try to merge on January 3.

And the build failures are rolling in :)

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

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

Re: Staging freeze

[Leo Famulari]

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

On Tue, Dec 27, 2016 at 06:56:44PM -0500, Leo Famulari wrote:
> On Fri, Dec 23, 2016 at 12:23:39AM -0500, Leo Famulari wrote:
> > The last staging branch was merged into the master branch on December
> > 11.
> > 
> > According to the 3 week staging cycle we are trying to adhere to [0],
> > this would mean we freeze the current branch on December 25 and try to
> > merge it on January 1.
> > 
> > These dates are inconvenient for many people. I propose we freeze the
> > branch and start building on December 27, and try to merge on January 3.
> 
> And the build failures are rolling in :)
> 
> https://hydra.gnu.org/eval/109410?full=1&compare=master#tabs-now-fail

The 'qemu-image' build failed due to a lack of disk space, presumably on
the VM image file:

------
registering closures...
error: setting journal mode: database or disk is full
ERROR: In procedure scm-error:
ERROR: failed to register store items "/xchg/system"
------
https://hydra.gnu.org/build/1741220

Any advice? I'm not sure where to start looking in the code.

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

Re: Staging freeze

[John Darrington]

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

On Tue, Dec 27, 2016 at 11:13:05PM -0500, Leo Famulari wrote:
     On Tue, Dec 27, 2016 at 06:56:44PM -0500, Leo Famulari wrote:
     > On Fri, Dec 23, 2016 at 12:23:39AM -0500, Leo Famulari wrote:
     > > The last staging branch was merged into the master branch on December
     > > 11.
     > > 
     > > According to the 3 week staging cycle we are trying to adhere to [0],
     > > this would mean we freeze the current branch on December 25 and try to
     > > merge it on January 1.
     > > 
     > > These dates are inconvenient for many people. I propose we freeze the
     > > branch and start building on December 27, and try to merge on January 3.
     > 
     > And the build failures are rolling in :)
     > 
     > https://hydra.gnu.org/eval/109410?full=1&compare=master#tabs-now-fail
     
     The 'qemu-image' build failed due to a lack of disk space, presumably on
     the VM image file:
     
     ------
     registering closures...
     error: setting journal mode: database or disk is full
     ERROR: In procedure scm-error:
     ERROR: failed to register store items "/xchg/system"
     ------
     https://hydra.gnu.org/build/1741220
     
     Any advice? I'm not sure where to start looking in the code.

For what it's worth, I find that building *anything* related to qemu fails
for different reasons in about 2/3 attempts. So I think there is a 
fundamental, yet to be diagnosed problem.

Would it be worth restarting the build and crossing fingers?

J'



-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Staging freeze

[Leo Famulari]

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

On Wed, Dec 28, 2016 at 10:17:31AM +0100, John Darrington wrote:
> On Tue, Dec 27, 2016 at 11:13:05PM -0500, Leo Famulari wrote:
>      On Tue, Dec 27, 2016 at 06:56:44PM -0500, Leo Famulari wrote:
>      > On Fri, Dec 23, 2016 at 12:23:39AM -0500, Leo Famulari wrote:
>      > > The last staging branch was merged into the master branch on December
>      > > 11.
>      > > 
>      > > According to the 3 week staging cycle we are trying to adhere to [0],
>      > > this would mean we freeze the current branch on December 25 and try to
>      > > merge it on January 1.
>      > > 
>      > > These dates are inconvenient for many people. I propose we freeze the
>      > > branch and start building on December 27, and try to merge on January 3.
>      > 
>      > And the build failures are rolling in :)
>      > 
>      > https://hydra.gnu.org/eval/109410?full=1&compare=master#tabs-now-fail
>      
>      The 'qemu-image' build failed due to a lack of disk space, presumably on
>      the VM image file:
>      
>      ------
>      registering closures...
>      error: setting journal mode: database or disk is full
>      ERROR: In procedure scm-error:
>      ERROR: failed to register store items "/xchg/system"
>      ------
>      https://hydra.gnu.org/build/1741220
>      
>      Any advice? I'm not sure where to start looking in the code.
> 
> For what it's worth, I find that building *anything* related to qemu fails
> for different reasons in about 2/3 attempts. So I think there is a 
> fundamental, yet to be diagnosed problem.

I've seen this error before when I fail to create a large enough blank
QEMU image. I think that's the problem here, but I'm not sure where this
qemu-image derivation comes from in the Guix code base, so I'm not sure
what to try adjusting or even how to replicate the failure.

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

Re: Staging freeze

[Ludovic Courtès]

Hi!

John Darrington <john@darrington.wattle.id.au> skribis:

> For what it's worth, I find that building *anything* related to qemu fails
> for different reasons in about 2/3 attempts. So I think there is a 
> fundamental, yet to be diagnosed problem.

Yet to be diagnosed… and yet to be reported?  :-)

This ‘qemu-image’ job has been failing since Dec. 11, apparently because
the closure of the OS in build-aux/hydra/demo-os.scm has become more
than 1.4G (the size specified in build-aux/hydra/gnu-system.scm):

  https://hydra.gnu.org/job/gnu/master/qemu-image.x86_64-linux

I’m tempted to simply remove this job because it doesn’t buy us anything
compared to the system tests.

Objections?

Ludo’.

Re: Staging freeze

[Leo Famulari]

On Thu, Dec 29, 2016 at 06:51:46PM +0100, Ludovic Courtès wrote:
> Hi!
> 
> John Darrington <john@darrington.wattle.id.au> skribis:
> 
> > For what it's worth, I find that building *anything* related to qemu fails
> > for different reasons in about 2/3 attempts. So I think there is a 
> > fundamental, yet to be diagnosed problem.
> 
> Yet to be diagnosed… and yet to be reported?  :-)
> 
> This ‘qemu-image’ job has been failing since Dec. 11, apparently because
> the closure of the OS in build-aux/hydra/demo-os.scm has become more
> than 1.4G (the size specified in build-aux/hydra/gnu-system.scm):
> 
>   https://hydra.gnu.org/job/gnu/master/qemu-image.x86_64-linux
> 
> I’m tempted to simply remove this job because it doesn’t buy us anything
> compared to the system tests.

Okay!

> Objections?

None here :)

Re: Staging freeze

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Dec 29, 2016 at 06:51:46PM +0100, Ludovic Courtès wrote:
>> Hi!
>> 
>> John Darrington <john@darrington.wattle.id.au> skribis:
>> 
>> > For what it's worth, I find that building *anything* related to qemu fails
>> > for different reasons in about 2/3 attempts. So I think there is a 
>> > fundamental, yet to be diagnosed problem.
>> 
>> Yet to be diagnosed… and yet to be reported?  :-)
>> 
>> This ‘qemu-image’ job has been failing since Dec. 11, apparently because
>> the closure of the OS in build-aux/hydra/demo-os.scm has become more
>> than 1.4G (the size specified in build-aux/hydra/gnu-system.scm):
>> 
>>   https://hydra.gnu.org/job/gnu/master/qemu-image.x86_64-linux
>> 
>> I’m tempted to simply remove this job because it doesn’t buy us anything
>> compared to the system tests.
>
> Okay!
>
>> Objections?
>
> None here :)

Done in a3a27745013f3e5a287de3bf0187b2f72beb6965.

Ludo’.

Re: Staging freeze

[Leo Famulari]

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

On Fri, Dec 23, 2016 at 12:23:39AM -0500, Leo Famulari wrote:
> The last staging branch was merged into the master branch on December
> 11.
> 
> According to the 3 week staging cycle we are trying to adhere to [0],
> this would mean we freeze the current branch on December 25 and try to
> merge it on January 1.
> 
> These dates are inconvenient for many people. I propose we freeze the
> branch and start building on December 27, and try to merge on January 3.

Update:

We are having some issues with the armhf and mips64el build machines
that are keeping us from building all the packages.

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

Re: Staging freeze

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Fri, Dec 23, 2016 at 12:23:39AM -0500, Leo Famulari wrote:
>> The last staging branch was merged into the master branch on December
>> 11.
>> 
>> According to the 3 week staging cycle we are trying to adhere to [0],
>> this would mean we freeze the current branch on December 25 and try to
>> merge it on January 1.
>> 
>> These dates are inconvenient for many people. I propose we freeze the
>> branch and start building on December 27, and try to merge on January 3.
>
> Update:
>
> We are having some issues with the armhf and mips64el build machines
> that are keeping us from building all the packages.

That should be more or less solved.

I’ve just merged ‘master’ into ‘staging’ and started a new evaluation.

Ludo’.

staging freeze

[Marius Bakke]

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

Hello Guix,

I've pushed a set of updates to the long-overdue "staging" branch.

Let's get it merged once Cuirass is done building for the various
architectures.  Not sure how long that takes now that we no longer use
transparent QEMU emulation for AArch64 and armhf.

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

Re: staging freeze

[Julien Lepiller]

Le 13 octobre 2020 17:54:16 GMT-04:00, Marius Bakke <marius@gnu.org> a écrit :
>Hello Guix,
>
>I've pushed a set of updates to the long-overdue "staging" branch.
>
>Let's get it merged once Cuirass is done building for the various
>architectures.  Not sure how long that takes now that we no longer use
>transparent QEMU emulation for AArch64 and armhf.

I have my groovy update ready to push to staging. Can I push it, or should I wait for next time staging is open?

Re: staging freeze

[Marius Bakke]

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

Julien Lepiller <julien@lepiller.eu> writes:

> Le 13 octobre 2020 17:54:16 GMT-04:00, Marius Bakke <marius@gnu.org> a écrit :
>>Hello Guix,
>>
>>I've pushed a set of updates to the long-overdue "staging" branch.
>>
>>Let's get it merged once Cuirass is done building for the various
>>architectures.  Not sure how long that takes now that we no longer use
>>transparent QEMU emulation for AArch64 and armhf.
>
> I have my groovy update ready to push to staging. Can I push it, or should I wait for next time staging is open?

Sure, go ahead!  I suppose we can give people a day or two to brush up
any almost-ready patches.

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

Re: staging freeze

[zimoun]

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

Hi Marius,

On Tue, 13 Oct 2020 at 23:54, Marius Bakke <marius@gnu.org> wrote:

> I've pushed a set of updates to the long-overdue "staging" branch.
>
> Let's get it merged once Cuirass is done building for the various
> architectures.  Not sure how long that takes now that we no longer use
> transparent QEMU emulation for AArch64 and armhf.

If it is possible –– not too late and not used with “guix refresh” ––,
could the attached patch go to “staging” and so all the Haskell packages
of v1.2 should be reproducible?  Otherwise, it should go to core-updates
and then wait the next round. :-)

Well, I could send the patch via guix-patches too. :-)
Let me know.


All the best,
simon

-- >8 --

[-- Attachment #2: haskell.patch --]
[-- Type: text/x-diff, Size: 1624 bytes --]

From 06eff8c02e22f583c252976f44db41554805293b Mon Sep 17 00:00:00 2001
From: zimoun <zimon.toutoune@gmail.com>
Date: Thu, 15 Oct 2020 14:02:09 +0200
Subject: [PATCH] build-system/haskell: Disable parallel builds.

Parallel builds introduced by commit 67cb9fa2357026ee42ec5bb0923ec4dc4a43abe2
leads to unreproducibility.  Instead of reverting, default is set to #false
which allows user to locally build with parallelism.

* guix/build-system/haskell.scm (haskell-build): Turn off PARALLEL-BUILD? by
default.
---
 guix/build-system/haskell.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/guix/build-system/haskell.scm b/guix/build-system/haskell.scm
index 8304e3b222..328d1139b0 100644
--- a/guix/build-system/haskell.scm
+++ b/guix/build-system/haskell.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015 Federico Beffa <beffa@fbengineering.ch>
 ;;; Copyright © 2020 Timothy Sample <samplet@ngyro.com>
+;;; Copyright © 2020 Simon Tournier <zimon.toutoune@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -121,7 +122,7 @@ version REVISION."
                         (haddock-flags ''())
                         (tests? #t)
                         (test-target "test")
-                        (parallel-build? #t)
+                        (parallel-build? #f)
                         (configure-flags ''())
                         (extra-directories ''())
                         (phases '(@ (guix build haskell-build-system)

base-commit: 7269a591361138ac6fc122d465e45e2b8c4944be
-- 
2.28.0