From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf. Date: Tue, 03 Jul 2018 15:20:08 -0400 Message-ID: <87efgknn2v.fsf@netris.org> References: <20180702101757.22792.51026@vcs0.savannah.gnu.org> <20180702101758.97A6020543@vcs0.savannah.gnu.org> <8736x1r1g0.fsf@netris.org> <877emdwm0f.fsf@fastmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faQrg-00035Y-RX for guix-devel@gnu.org; Tue, 03 Jul 2018 15:21:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1faQrd-0003w2-Le for guix-devel@gnu.org; Tue, 03 Jul 2018 15:21:28 -0400 Received: from world.peace.net ([64.112.178.59]:36086) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1faQrd-0003vw-HZ for guix-devel@gnu.org; Tue, 03 Jul 2018 15:21:25 -0400 In-Reply-To: <877emdwm0f.fsf@fastmail.com> (Marius Bakke's message of "Mon, 02 Jul 2018 20:06:08 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Marius Bakke Cc: guix-devel@gnu.org Hi Marius, Marius Bakke writes: > Mark H Weaver writes: > >> mbakke@fastmail.com (Marius Bakke) writes: >> >>> mbakke pushed a commit to branch staging >>> in repository guix. >>> >>> commit cb4b508cd68df89bfbd5255a0c5569f8318ad50f >>> Author: Marius Bakke >>> Date: Mon Jul 2 12:07:58 2018 +0200 >>> >>> build-system/meson: Really skip the 'fix-runpath' phase on armhf. >>> >>> This follows up commit d5b5a15a4046362377f1a45d466b43bb6e93d4f which doesn't >>> work because %current-system etc expands before the actual build. >> >> I'm disappointed by this workaround that simply removes the >> 'fix-runpath' phase on armhf. Is that phase needed, or is it truly >> optional? What does the phase accomplish, and how will armhf users be >> disadvantaged by the removal of that phase? >> >> This feels like "sweeping the problem under the rug" to me. > > It *is* sweeping the problem under the rug, no doubt. The only > alternatives I can see is fixing patchelf on armhf, which is difficult > for me without access to hardware; fixing Meson itself, which may be > easier, but then we may not be able to merge staging in a long time; or > implement patchelf functionality in Guix as Ludovic started with > and is currently in 'core-updates'. > > Do you have other suggestions? None that I expect to be taken seriously by this community. I'd just like to point out that given the way things are going, I could only recommend Guix to x86_64 users. Almost all of our users are on x86_64, and they are impatient to always have the latest software. In practice, when upgrades would break *any* other system, we move ahead anyway, just like we did with the last 'core-updates' merge, and just like you wish to do now with the 'staging' branch. The end result is that the wishes of the x86_64-using majority are the only ones that seem to matter in this community, and other users are frequently left in a bad spot. This makes it increasingly unlikely that we'll ever gain a significant number of non-x86_64 users. I'm very troubled by this, because I intend to move away from x86_64. Unless there is a significant change in the priorities of the Guix project, I don't think I will be able to continue using Guix. >>> Fixes . >> >> I don't see the connection between that bug and this commit. >> How does this commit fix that bug? > > Whoops, typo. It should be . In my view, this commit does not fix that bug. Mark