unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Marius Bakke <mbakke@fastmail.com>
Cc: guix-devel@gnu.org
Subject: Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.
Date: Tue, 03 Jul 2018 15:20:08 -0400	[thread overview]
Message-ID: <87efgknn2v.fsf@netris.org> (raw)
In-Reply-To: <877emdwm0f.fsf@fastmail.com> (Marius Bakke's message of "Mon, 02 Jul 2018 20:06:08 +0200")

Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> mbakke@fastmail.com (Marius Bakke) writes:
>>
>>> mbakke pushed a commit to branch staging
>>> in repository guix.
>>>
>>> commit cb4b508cd68df89bfbd5255a0c5569f8318ad50f
>>> Author: Marius Bakke <mbakke@fastmail.com>
>>> 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
> <https://bugs.gnu.org/31028> 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 <https://bugs.gnu.org/31719>.
>>
>> I don't see the connection between that bug and this commit.
>> How does this commit fix that bug?
>
> Whoops, typo.  It should be <https://bugs.gnu.org/31971>.

In my view, this commit does not fix that bug.

       Mark

  reply	other threads:[~2018-07-03 19:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180702101757.22792.51026@vcs0.savannah.gnu.org>
     [not found] ` <20180702101758.97A6020543@vcs0.savannah.gnu.org>
2018-07-02 17:29   ` 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf Mark H Weaver
2018-07-02 18:06     ` Marius Bakke
2018-07-03 19:20       ` Mark H Weaver [this message]
2018-07-04  7:21         ` Ludovic Courtès
2018-07-04 19:55           ` RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.) Mark H Weaver
2018-07-04 22:32             ` Kei Kebreau
2018-07-05  8:39               ` Ludovic Courtès
2018-07-05 14:15                 ` Kei Kebreau
2018-07-05  9:04               ` Jonathan Brielmaier
2018-07-05 19:40                 ` Andreas Enge
2018-07-05  6:38             ` Ricardo Wurmus
2018-07-05  8:46               ` Ludovic Courtès
2018-07-05  9:52               ` Andreas Enge
2018-07-05  8:50             ` Ludovic Courtès
2018-07-05  9:01             ` Ludovic Courtès
2018-07-02 18:28     ` 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf Marius Bakke
2018-07-03 19:24       ` Mark H Weaver
2018-07-04  7:27         ` Ludovic Courtès
2018-07-04 14:27           ` Marius Bakke
2018-07-03 21:28       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87efgknn2v.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=mbakke@fastmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).