* Re: 01/01: gnu: python-setuptools: Update to 12.1. [not found] ` <E1YN7Pm-00026R-OM@vcs.savannah.gnu.org> @ 2015-02-18 3:46 ` Mark H Weaver 2015-02-18 8:33 ` Andreas Enge 0 siblings, 1 reply; 5+ messages in thread From: Mark H Weaver @ 2015-02-18 3:46 UTC (permalink / raw) To: Andreas Enge; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 01/01: gnu: python-setuptools: Update to 12.1. 2015-02-18 3:46 ` 01/01: gnu: python-setuptools: Update to 12.1 Mark H Weaver @ 2015-02-18 8:33 ` Andreas Enge 2015-02-18 8:57 ` Andreas Enge ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Andreas Enge @ 2015-02-18 8:33 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 01/01: gnu: python-setuptools: Update to 12.1. 2015-02-18 8:33 ` Andreas Enge @ 2015-02-18 8:57 ` Andreas Enge 2015-02-18 9:17 ` Andreas Enge 2015-02-18 19:59 ` Mark H Weaver 2 siblings, 0 replies; 5+ messages in thread From: Andreas Enge @ 2015-02-18 8:57 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel In the particular case of python-urwid, it succeeded after a restart. Andreas ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 01/01: gnu: python-setuptools: Update to 12.1. 2015-02-18 8:33 ` Andreas Enge 2015-02-18 8:57 ` Andreas Enge @ 2015-02-18 9:17 ` Andreas Enge 2015-02-18 19:59 ` Mark H Weaver 2 siblings, 0 replies; 5+ messages in thread From: Andreas Enge @ 2015-02-18 9:17 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel Concerning R, I confirm that it builds indeed on my local x86_64 machine. Andreas ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 01/01: gnu: python-setuptools: Update to 12.1. 2015-02-18 8:33 ` Andreas Enge 2015-02-18 8:57 ` Andreas Enge 2015-02-18 9:17 ` Andreas Enge @ 2015-02-18 19:59 ` Mark H Weaver 2 siblings, 0 replies; 5+ messages in thread From: Mark H Weaver @ 2015-02-18 19:59 UTC (permalink / raw) To: Andreas Enge; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-02-18 19:59 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20150215221146.8024.17763@vcs.savannah.gnu.org> [not found] ` <E1YN7Pm-00026R-OM@vcs.savannah.gnu.org> 2015-02-18 3:46 ` 01/01: gnu: python-setuptools: Update to 12.1 Mark H Weaver 2015-02-18 8:33 ` Andreas Enge 2015-02-18 8:57 ` Andreas Enge 2015-02-18 9:17 ` Andreas Enge 2015-02-18 19:59 ` Mark H Weaver
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).