Re: 01/01: gnu: python-setuptools: Update to 12.1.

Re: 01/01: gnu: python-setuptools: Update to 12.1.

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> commit d3d656c5fbd9345e7f9d62564a06d1672300625c
> Author: Andreas Enge <andreas@enge.fr>
> Date:   Sun Feb 15 23:10:58 2015 +0100
>
>     gnu: python-setuptools: Update to 12.1.

Strangely, this update broke python-urwid-1.3.0.x86_64-linux.  Three
tests involving newlines broke:

  http://hydra.gnu.org/build/255711/log/tail-reload

Interestingly, this only affects the Python 3 version of this package,
and only on x86_64.  The Python 2 versions on both Intel platforms
continue to work, and the Python 3 version for i686 still works.

  http://hydra.gnu.org/eval/102796?filter=urwid

Any theories of what's happening here?

      Mark

Re: 01/01: gnu: python-setuptools: Update to 12.1.

[Andreas Enge]

On Tue, Feb 17, 2015 at 10:46:11PM -0500, Mark H Weaver wrote:
> Strangely, this update broke python-urwid-1.3.0.x86_64-linux.  Three
> tests involving newlines broke:

Even more strangely, it builds without problems on my machine.

I wonder if something is wrong with the hydra build machine setup, or if
we still have some kind of impurity in the build system. There is a growing
number of packages that fail on hydra, but build locally: python-urwid, r,
elfutils, lightning (which I tried the other day).

Andreas

Re: 01/01: gnu: python-setuptools: Update to 12.1.

[Andreas Enge]

In the particular case of python-urwid, it succeeded after a restart.

Andreas

Re: 01/01: gnu: python-setuptools: Update to 12.1.

[Andreas Enge]

Concerning R, I confirm that it builds indeed on my local x86_64 machine.

Andreas

Re: 01/01: gnu: python-setuptools: Update to 12.1.

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> On Tue, Feb 17, 2015 at 10:46:11PM -0500, Mark H Weaver wrote:
>> Strangely, this update broke python-urwid-1.3.0.x86_64-linux.  Three
>> tests involving newlines broke:
>
> Even more strangely, it builds without problems on my machine.
>
> I wonder if something is wrong with the hydra build machine setup, or if
> we still have some kind of impurity in the build system.

The most notable impurity is the kernel.  Also, on several platforms,
including ARM, config.guess looks at 'uname -m' to find out the specific
processor type in the build machine to decide what triplet to use.
That's why I advocated passing --build= to configure by default for all
builds here:

  https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00037.html

However, there was pushback and the discussion stalled.

Even if we pass --build= to bypass config.guess, some packages probe the
details of the build machine and/or kernel and specialize the build for
those.

In theory, we could perform all builds within a VM and include the VM
build+configuration and kernel in the hash computation, but that would
obviously increase the resources needed to build things quite a lot.

       Mark