diff mbox

gnu: boost: Update to 1.61.0.

Message ID 8737kw2tp8.fsf@gnu.org
State New
Headers show

Commit Message

Roel Janssen Sept. 19, 2016, 8:13 a.m. UTC 
Dear Guix,

I don't know what the impact of the following upgrade is, but I think it
would be good to update Boost to the latest stable version that was
released on May 13th, 2016.

What do you think?

Kind regards,
Roel Janssen

>From a6409b0648352cac86a3ceb205ee183c034085f5 Mon Sep 17 00:00:00 2001
From: Roel Janssen <roel@gnu.org>
Date: Mon, 19 Sep 2016 10:08:52 +0200
Subject: [PATCH] gnu: boost: Update to 1.61.0.

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

Comments

Roel Janssen Sept. 19, 2016, 10:11 a.m. UTC | #1 
Roel Janssen writes:

> Dear Guix,
>
> I don't know what the impact of the following upgrade is, but I think it
> would be good to update Boost to the latest stable version that was
> released on May 13th, 2016.
>
> What do you think?
>
> Kind regards,
> Roel Janssen
>
>>From a6409b0648352cac86a3ceb205ee183c034085f5 Mon Sep 17 00:00:00 2001
> From: Roel Janssen <roel@gnu.org>
> Date: Mon, 19 Sep 2016 10:08:52 +0200
> Subject: [PATCH] gnu: boost: Update to 1.61.0.
>
> * gnu/packages/boost.scm (boost): Update to 1.61.0.
> ---
>  gnu/packages/boost.scm | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
> index 8fe8c8e..ccc1f06 100644
> --- a/gnu/packages/boost.scm
> +++ b/gnu/packages/boost.scm
> @@ -34,7 +34,7 @@
>  (define-public boost
>    (package
>      (name "boost")
> -    (version "1.60.0")
> +    (version "1.61.0")
>      (source (origin
>                (method url-fetch)
>                (uri (string-append
> @@ -43,7 +43,7 @@
>                      ".tar.bz2"))
>                (sha256
>                 (base32
> -                "0fzx6dwqbrkd4bcd8pjv0fpapwmrxxwr8yx9g67lihlsk3zzysk8"))))
> +                "0h5nk7pgxf7xsvvshj9qfpsfp9wx6gq9r78n3nx736pxq83bsix5"))))
>      (build-system gnu-build-system)
>      (inputs `(("zlib" ,zlib)))
>      (native-inputs

It looks like an upgrade to 1.61.0 causes a build failure for MySQL:

-------------------------- BUILD OUTPUT LOG FOR MYSQL --------------------------
-- BOOST_VERSION_NUMBER is #define BOOST_VERSION 106100
CMake Warning at cmake/boost.cmake:266 (MESSAGE):
  Boost minor version found is 61 we need 60
Call Stack (most recent call first):
  CMakeLists.txt:455 (INCLUDE)


-- BOOST_INCLUDE_DIR /gnu/store/...fzzl-boost-1.61.0/include
-- LOCAL_BOOST_DIR 
-- LOCAL_BOOST_ZIP 
-- Could not find (the correct version of) boost.
-- MySQL currently requires boost_1_60_0

CMake Error at cmake/boost.cmake:81 (MESSAGE):
  You can download it with -DDOWNLOAD_BOOST=1 -DWITH_BOOST=<directory>
------------------------ END BUILD OUTPUT LOG FOR MYSQL ------------------------

So I guess the impact is too large to just go for it.

Do we have a Guix command to find out which packages are dependent on
a package (in this case Boost)?

Kind regards,
Roel Janssen
Ricardo Wurmus Sept. 19, 2016, 12:26 p.m. UTC | #2 
Roel Janssen <roel@gnu.org> writes:

> Roel Janssen writes:
>
>> Dear Guix,
>>
>> I don't know what the impact of the following upgrade is, but I think it
>> would be good to update Boost to the latest stable version that was
>> released on May 13th, 2016.
>>
>> What do you think?
>>
>> Kind regards,
>> Roel Janssen
>>
>>>From a6409b0648352cac86a3ceb205ee183c034085f5 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen <roel@gnu.org>
>> Date: Mon, 19 Sep 2016 10:08:52 +0200
>> Subject: [PATCH] gnu: boost: Update to 1.61.0.
>>
>> * gnu/packages/boost.scm (boost): Update to 1.61.0.
>> ---
>>  gnu/packages/boost.scm | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
>> index 8fe8c8e..ccc1f06 100644
>> --- a/gnu/packages/boost.scm
>> +++ b/gnu/packages/boost.scm
>> @@ -34,7 +34,7 @@
>>  (define-public boost
>>    (package
>>      (name "boost")
>> -    (version "1.60.0")
>> +    (version "1.61.0")
>>      (source (origin
>>                (method url-fetch)
>>                (uri (string-append
>> @@ -43,7 +43,7 @@
>>                      ".tar.bz2"))
>>                (sha256
>>                 (base32
>> -                "0fzx6dwqbrkd4bcd8pjv0fpapwmrxxwr8yx9g67lihlsk3zzysk8"))))
>> +                "0h5nk7pgxf7xsvvshj9qfpsfp9wx6gq9r78n3nx736pxq83bsix5"))))
>>      (build-system gnu-build-system)
>>      (inputs `(("zlib" ,zlib)))
>>      (native-inputs
>
> It looks like an upgrade to 1.61.0 causes a build failure for MySQL:
>
> -------------------------- BUILD OUTPUT LOG FOR MYSQL --------------------------
> -- BOOST_VERSION_NUMBER is #define BOOST_VERSION 106100
> CMake Warning at cmake/boost.cmake:266 (MESSAGE):
>   Boost minor version found is 61 we need 60
> Call Stack (most recent call first):
>   CMakeLists.txt:455 (INCLUDE)
>
>
> -- BOOST_INCLUDE_DIR /gnu/store/...fzzl-boost-1.61.0/include
> -- LOCAL_BOOST_DIR 
> -- LOCAL_BOOST_ZIP 
> -- Could not find (the correct version of) boost.
> -- MySQL currently requires boost_1_60_0
>
> CMake Error at cmake/boost.cmake:81 (MESSAGE):
>   You can download it with -DDOWNLOAD_BOOST=1 -DWITH_BOOST=<directory>
> ------------------------ END BUILD OUTPUT LOG FOR MYSQL ------------------------
>
> So I guess the impact is too large to just go for it.
>
> Do we have a Guix command to find out which packages are dependent on
> a package (in this case Boost)?

You could use “guix refresh -l boost”.  This gives 190 packages with 395
dependent packages that would need to be rebuilt additionally.

~~ Ricardo
Efraim Flashner Sept. 19, 2016, 8:31 p.m. UTC | #3 
On Mon, Sep 19, 2016 at 12:11:57PM +0200, Roel Janssen wrote:
> Roel Janssen writes:
> 
> > Dear Guix,
> >
> > I don't know what the impact of the following upgrade is, but I think it
> > would be good to update Boost to the latest stable version that was
> > released on May 13th, 2016.
> >
> > What do you think?
> >
> > Kind regards,
> > Roel Janssen
> >
> >>From a6409b0648352cac86a3ceb205ee183c034085f5 Mon Sep 17 00:00:00 2001
> > From: Roel Janssen <roel@gnu.org>
> > Date: Mon, 19 Sep 2016 10:08:52 +0200
> > Subject: [PATCH] gnu: boost: Update to 1.61.0.
> >
> > * gnu/packages/boost.scm (boost): Update to 1.61.0.
> > ---
> >  gnu/packages/boost.scm | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
> > index 8fe8c8e..ccc1f06 100644
> > --- a/gnu/packages/boost.scm
> > +++ b/gnu/packages/boost.scm
> > @@ -34,7 +34,7 @@
> >  (define-public boost
> >    (package
> >      (name "boost")
> > -    (version "1.60.0")
> > +    (version "1.61.0")
> >      (source (origin
> >                (method url-fetch)
> >                (uri (string-append
> > @@ -43,7 +43,7 @@
> >                      ".tar.bz2"))
> >                (sha256
> >                 (base32
> > -                "0fzx6dwqbrkd4bcd8pjv0fpapwmrxxwr8yx9g67lihlsk3zzysk8"))))
> > +                "0h5nk7pgxf7xsvvshj9qfpsfp9wx6gq9r78n3nx736pxq83bsix5"))))
> >      (build-system gnu-build-system)
> >      (inputs `(("zlib" ,zlib)))
> >      (native-inputs
> 
> It looks like an upgrade to 1.61.0 causes a build failure for MySQL:
> 
> -------------------------- BUILD OUTPUT LOG FOR MYSQL --------------------------
> -- BOOST_VERSION_NUMBER is #define BOOST_VERSION 106100
> CMake Warning at cmake/boost.cmake:266 (MESSAGE):
>   Boost minor version found is 61 we need 60
> Call Stack (most recent call first):
>   CMakeLists.txt:455 (INCLUDE)
> 
> 
> -- BOOST_INCLUDE_DIR /gnu/store/...fzzl-boost-1.61.0/include
> -- LOCAL_BOOST_DIR 
> -- LOCAL_BOOST_ZIP 
> -- Could not find (the correct version of) boost.
> -- MySQL currently requires boost_1_60_0
> 
> CMake Error at cmake/boost.cmake:81 (MESSAGE):
>   You can download it with -DDOWNLOAD_BOOST=1 -DWITH_BOOST=<directory>
> ------------------------ END BUILD OUTPUT LOG FOR MYSQL ------------------------

I've already hacked mysql to require 1.60.0 instead of 1.59.0, its worth
checking out if changing it to require 1.61.0 works also. Unfortunately
my current machine only has 2 GB of ram and a spinning hard drive so I
can't realiably build mysql.

> 
> So I guess the impact is too large to just go for it.
> 
> Do we have a Guix command to find out which packages are dependent on
> a package (in this case Boost)?
> 
> Kind regards,
> Roel Janssen
>
Andreas Enge Sept. 21, 2016, 4:11 p.m. UTC | #4 
Hello,

On Mon, Sep 19, 2016 at 12:11:57PM +0200, Roel Janssen wrote:
> I don't know what the impact of the following upgrade is, but I think it
> would be good to update Boost to the latest stable version that was
> released on May 13th, 2016.

boost has quite a few dependencies, as Ricardo already pointed out, and in my
experience tends to be a bit fragile. So maybe the best option would be to
create a boost-update branch and have it built on hydra to see whether there
are problems. It not, one could then cherry-pick the commit to master.

Andreas
Andreas Enge Sept. 21, 2016, 5:27 p.m. UTC | #5 
On Wed, Sep 21, 2016 at 06:11:31PM +0200, Andreas Enge wrote:
> boost has quite a few dependencies, as Ricardo already pointed out, and in my
> experience tends to be a bit fragile. So maybe the best option would be to
> create a boost-update branch and have it built on hydra to see whether there
> are problems. It not, one could then cherry-pick the commit to master.

I replied before reading all the messages in that thread. Of course if Eric
has tried the commit locally and tested that nothing breaks, this could be
pushed to master directly.

Andreas
Marius Bakke Sept. 22, 2016, 9:16 p.m. UTC | #6 
Andreas Enge <andreas@enge.fr> writes:

> On Wed, Sep 21, 2016 at 06:11:31PM +0200, Andreas Enge wrote:
>> boost has quite a few dependencies, as Ricardo already pointed out, and in my
>> experience tends to be a bit fragile. So maybe the best option would be to
>> create a boost-update branch and have it built on hydra to see whether there
>> are problems. It not, one could then cherry-pick the commit to master.
>
> I replied before reading all the messages in that thread. Of course if Eric
> has tried the commit locally and tested that nothing breaks, this could be
> pushed to master directly.

Should this not be pushed to core-updates? `guix refresh -l` reports:

Building the following 190 packages would ensure 395 dependent packages
are rebuilt: [...]

That will take a while on Hydra, and in the mean time anyone trying to
install any dependent (or sub-dependent) package will have to compile
them locally.

Unless there is a security issue, isn't this exactly what core-updates
is for? Is `guix refresh recursive`? Many of the sub-depentents seem
like they have other dependents, affecting more than 10% of the tree.

~marius
Eric Bavier Sept. 23, 2016, 5:05 p.m. UTC | #7 
On 2016-09-22 16:16, Marius Bakke wrote:
> Andreas Enge <andreas@enge.fr> writes:
> 
>> On Wed, Sep 21, 2016 at 06:11:31PM +0200, Andreas Enge wrote:
>>> boost has quite a few dependencies, as Ricardo already pointed out, 
>>> and in my
>>> experience tends to be a bit fragile. So maybe the best option would 
>>> be to
>>> create a boost-update branch and have it built on hydra to see 
>>> whether there
>>> are problems. It not, one could then cherry-pick the commit to 
>>> master.
>> 
>> I replied before reading all the messages in that thread. Of course if 
>> Eric
>> has tried the commit locally and tested that nothing breaks, this 
>> could be
>> pushed to master directly.
> 
> Should this not be pushed to core-updates? `guix refresh -l` reports:
> 
> Building the following 190 packages would ensure 395 dependent packages
> are rebuilt: [...]

That's kind of on the edge of what's acceptable for master, as long as 
hydra isn't already overloaded, which it wasn't in this case.

> That will take a while on Hydra, and in the mean time anyone trying to
> install any dependent (or sub-dependent) package will have to compile
> them locally.

It's already finished rebuilding those dependents.

> Unless there is a security issue, isn't this exactly what core-updates
> is for?

Indeed, but for security updates grafts are preferable.

> Is `guix refresh recursive`?

Yes.
Andreas Enge Sept. 27, 2016, 7:13 p.m. UTC | #8 
On Thu, Sep 22, 2016 at 10:16:54PM +0100, Marius Bakke wrote:
> Should this not be pushed to core-updates? `guix refresh -l` reports:
> 
> Building the following 190 packages would ensure 395 dependent packages
> are rebuilt: [...]
> 
> That will take a while on Hydra, and in the mean time anyone trying to
> install any dependent (or sub-dependent) package will have to compile
> them locally.
> 
> Unless there is a security issue, isn't this exactly what core-updates
> is for?

Not quite. Initially, core-updates was for updates of the core packages,
that is, those that you can currently see being built on the core-updates
branch of hydra. With the lack of performance of hydra, we ended up putting
more and more packages requiring large rebuilds into that branch.

Often, we also just add a feature branch (something-update) and have it
built on hydra, especially also in cases where it is unclear how much we
break by the update, to make sure that master remains in a workable state.

After the hydra machine crashed, the FSF sysadmins switched to a more powerful
set-up, and right now, we can tolerate a larger package churn. In case of
doubt when updating a package requiring larger rebuilds, we can also have it
depend on the current load on hydra towards which branch we push.

Andreas
diff mbox

Patch

diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
index 8fe8c8e..ccc1f06 100644
--- a/gnu/packages/boost.scm
+++ b/gnu/packages/boost.scm
@@ -34,7 +34,7 @@ 
 (define-public boost
   (package
     (name "boost")
-    (version "1.60.0")
+    (version "1.61.0")
     (source (origin
               (method url-fetch)
               (uri (string-append
@@ -43,7 +43,7 @@ 
                     ".tar.bz2"))
               (sha256
                (base32
-                "0fzx6dwqbrkd4bcd8pjv0fpapwmrxxwr8yx9g67lihlsk3zzysk8"))))
+                "0h5nk7pgxf7xsvvshj9qfpsfp9wx6gq9r78n3nx736pxq83bsix5"))))
     (build-system gnu-build-system)
     (inputs `(("zlib" ,zlib)))
     (native-inputs