guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 01/01: gnu: boost: Update to 1.58.0.


From: Mark H Weaver
Subject: Re: 01/01: gnu: boost: Update to 1.58.0.
Date: Fri, 10 Jul 2015 16:03:50 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Andreas Enge <address@hidden> writes:

> On Fri, Jul 10, 2015 at 12:52:24PM -0400, Mark H Weaver wrote:
>> I'm not 100% sure what's happening either, but more packages are
>> becoming broken over time.  I think it has to do with the fact that
>> 'git' is one of the broken packages, and other packages that fetch their
>> source code using 'git' are becoming broken whenever Guix decides it's
>> time to try re-downloading the source, e.g.:
>
> Okay, that is an interesting explanation!
>
>> I've reverted the patch.  After we have a solution to this problem, we
>> can build it in a separate branch.  I think we should have done this
>> anyway, since updating Boost entails a lot of rebuilds, and has a
>> history of being problematic on non-Intel platforms.
>
> With only 69 dependent packages, it did not look like a big risk!

It's definitely more than that.  As I recall, Hydra had to do on the
order of 600 rebuilds after your boost update.  This is a case where
"guix refresh -l" is way off.

> It just built with the patch on my mips machine:
>    Performing configuration checks
>
>     - 32-bit                   : yes
>     - arm                      : no
>     - mips1                    : no
>     - power                    : no
>     - sparc                    : no
>     - x86                      : no
>     - combined                 : no
> I still find it suspicious that it is not recognised as "mips1"; it may
> have to do with the different ABIs, since when I build it on debian,
> it says "mips1 : yes".

Yes, it might have to do with that.  Debian uses the O32 ABI.

> I will push this to a wip-boost branch, and try to build a dependent package
> locally. I wonder if I should base wip-boost on openssl-update; but with
> only 69 dependent packages (if the count is true), it probably does not
> matter.

Can we do this on core-updates instead?  I'm currently working on a
core-updates branch.  I will push it soon, after I've done some basic
testing on it.

Hydra is already overloaded trying to rebuild the openssl-update jobset,
and now it will have more to do since I reverted boost on master and
rebased openssl-update on that.  I want to get openssl-update built
ASAP.

What do you think?

      Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]