Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Mark H Weaver]

Hi Marius,

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.

>     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?

      Thanks,
        Mark

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Hi Marius,
>
> 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?

>>     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>.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Hi Marius,
>
> 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?

I'm sorry, I forgot to address your actual concerns.  The (buggy)
workaround was put in place and discussed in
<https://bugs.gnu.org/30761>.  The meat of it can be found in (guix
build-system meson):

    ;; XXX PatchELF fails to build on armhf, so we skip
    ;; the 'fix-runpath' phase there for now.  It is used
    ;; to avoid superfluous entries in RUNPATH as described
    ;; in <https://bugs.gnu.org/28444#46>, so armhf may now
    ;; have different runtime dependencies from other arches.

Now, I'm not proud of this "workaround", but it's not exactly new, so I
don't see why we should rush to fix it now.  Given how late we are in
this staging cycle, I would prefer delaying any proper fix until the
next round.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Mark H Weaver]

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

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Mark H Weaver]

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?
>
> I'm sorry, I forgot to address your actual concerns.  The (buggy)
> workaround was put in place and discussed in
> <https://bugs.gnu.org/30761>.  The meat of it can be found in (guix
> build-system meson):
>
>     ;; XXX PatchELF fails to build on armhf, so we skip
>     ;; the 'fix-runpath' phase there for now.  It is used
>     ;; to avoid superfluous entries in RUNPATH as described
>     ;; in <https://bugs.gnu.org/28444#46>, so armhf may now
>     ;; have different runtime dependencies from other arches.

Thanks for this, but I'd still like to know the answer to my questions:
"What does the [fix-runpath] phase accomplish, and how will armhf users
be disadvantaged by the removal of that phase?"

If the 'fix-runpath' phase is not strictly needed, then I would prefer
to remove it on _all_ systems.  If it _is_ needed, then I don't see how
we can simply remove it on 'armhf' systems.

      Thanks,
        Mark

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> I'm sorry, I forgot to address your actual concerns.  The (buggy)
> workaround was put in place and discussed in
> <https://bugs.gnu.org/30761>.  The meat of it can be found in (guix
> build-system meson):
>
>     ;; XXX PatchELF fails to build on armhf, so we skip
>     ;; the 'fix-runpath' phase there for now.  It is used
>     ;; to avoid superfluous entries in RUNPATH as described
>     ;; in <https://bugs.gnu.org/28444#46>, so armhf may now
>     ;; have different runtime dependencies from other arches.
>
> Now, I'm not proud of this "workaround", but it's not exactly new, so I
> don't see why we should rush to fix it now.  Given how late we are in
> this staging cycle, I would prefer delaying any proper fix until the
> next round.

I agree.  It’s terrible, but the priority here is to get ‘staging’ in
shape for merging.

Thanks for taking care of ‘staging’!

Ludo’.

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Ludovic Courtès]

Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

> 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.

This kind of rant is really unhelpful.  You’re shouting at someone who
*is* doing the work of keeping things running.  And yes, when you do
that work, sometimes you have to choose between two suboptimal solutions
while waiting for a proper fix.

Generalizations about “this community” obviously make no sense.  You are
a part of “this community” so it cares just as much as you do.

Please let’s work in a friendly manner towards finding solutions to the
problems.

Thank you,
Ludo’.

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Ludovic Courtès]

Hello,

Mark H Weaver <mhw@netris.org> skribis:

> Marius Bakke <mbakke@fastmail.com> writes:

[...]

>> I'm sorry, I forgot to address your actual concerns.  The (buggy)
>> workaround was put in place and discussed in
>> <https://bugs.gnu.org/30761>.  The meat of it can be found in (guix
>> build-system meson):
>>
>>     ;; XXX PatchELF fails to build on armhf, so we skip
>>     ;; the 'fix-runpath' phase there for now.  It is used
>>     ;; to avoid superfluous entries in RUNPATH as described
>>     ;; in <https://bugs.gnu.org/28444#46>, so armhf may now
>>     ;; have different runtime dependencies from other arches.
>
> Thanks for this, but I'd still like to know the answer to my questions:
> "What does the [fix-runpath] phase accomplish, and how will armhf users
> be disadvantaged by the removal of that phase?"

As discussed in <https://bugs.gnu.org/31970> and
<https://bugs.gnu.org/31974>, Meson does not (or did not) adjust
RUNPATHs upon installation (contrary to what Libtool does, for
instance.)

Consequently, the RUNPATH is left with /tmp/guix-build-… entries, which
is not great but okay, but more importantly if usually lacks OUTPUT/lib
as well.

However, the commit Marius referred to¹ as well as what you reported for
Epiphany in #31974 suggest that things are improving in Meson proper,
and that we might be able to remove that ‘fix-runpath’ phase altogether
soon.

I think we should simply try building things without ‘fix-runpath’ and
see if ‘validate-runpath’ reports anything.

Thoughts?

Ludo’.

¹ https://github.com/mesonbuild/meson/commit/e3757e3d3cf24327c89dd3fc40f6cc933510f676

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
>> Marius Bakke <mbakke@fastmail.com> writes:
>
> [...]
>
>>> I'm sorry, I forgot to address your actual concerns.  The (buggy)
>>> workaround was put in place and discussed in
>>> <https://bugs.gnu.org/30761>.  The meat of it can be found in (guix
>>> build-system meson):
>>>
>>>     ;; XXX PatchELF fails to build on armhf, so we skip
>>>     ;; the 'fix-runpath' phase there for now.  It is used
>>>     ;; to avoid superfluous entries in RUNPATH as described
>>>     ;; in <https://bugs.gnu.org/28444#46>, so armhf may now
>>>     ;; have different runtime dependencies from other arches.
>>
>> Thanks for this, but I'd still like to know the answer to my questions:
>> "What does the [fix-runpath] phase accomplish, and how will armhf users
>> be disadvantaged by the removal of that phase?"
>
> As discussed in <https://bugs.gnu.org/31970> and
> <https://bugs.gnu.org/31974>, Meson does not (or did not) adjust
> RUNPATHs upon installation (contrary to what Libtool does, for
> instance.)
>
> Consequently, the RUNPATH is left with /tmp/guix-build-… entries, which
> is not great but okay, but more importantly if usually lacks OUTPUT/lib
> as well.

I haven't seen /tmp in RUNPATH during my testing, which would be a
*huge* security problem.  The only consequence I've noticed from
dropping 'fix-runpath' is that it sometimes contain entries that are not
in NEEDED (but often required for a "neighbour" library, so no big deal).

> However, the commit Marius referred to¹ as well as what you reported for
> Epiphany in #31974 suggest that things are improving in Meson proper,
> and that we might be able to remove that ‘fix-runpath’ phase altogether
> soon.
>
> I think we should simply try building things without ‘fix-runpath’ and
> see if ‘validate-runpath’ reports anything.
>
> Thoughts?

I'm in favor of removing it on all architectures and see how it fares.
I suspect the main reason for adding it was that <out>/lib was often
lacking, which is mitigated by 09a45ffb146fda75b87f89c729c31d1da5bf93da.

I'll prepare patches for this for the next staging round.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> 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.
>
> This kind of rant is really unhelpful.  You’re shouting at someone who
> *is* doing the work of keeping things running.

I wasn't actually shouting, but in retrospect I can see how it came off
that way.  I apologize for any hurt feelings that I caused.

This is not Marius' fault, and I didn't intend to target him
specifically.  I'm grateful for the large amount of important work that
he does on Guix.

However, I do feel frustrated by the fact that it's considered
acceptable in this community to leave non-x86_64 users with broken
systems in the name of "moving things forward" for x86_64 users.

Portability is important to the long-term health of the free software
movement.  Especially given that fact that Intel has long ago stopped
producing processors that can be used without large amounts of nonfree
software (including the Intel Management Engine), I think we should work
to ensure that Guix works well for users of non-x86_64 systems.

The origin of this problem is not in the Guix project.  Ultimately, it's
due to the fact that x86_64 has far too much market share among
GNU/Linux developers, and therefore the upstream projects upon which
Guix depends are not being sufficiently tested on other platforms.

However, there is one aspect of Guix that is greatly exacerbating this
problem: our impatience to always have the latest software, even if it
breaks other systems, is a serious problem in my view.

It means that if I want to ensure that Guix works well for i686 or armhf
users, then I would need to start trying to use Guix on those systems
for real work, which at the present time would entail almost
single-handedly fixing all of the portability bugs in all of the
software that I use, at the full pace of upstream development.  I would
need to keep this up for long enough to make Guix appear to be a safe
choice for i686 or armhf users, so that some of them might help work on
these portability issues in the future.

Another problem is that Guile 2.2's compiler has become so heavy that
it's nearly unbearable to use on slower hardware.  Simply running "make"
in my Guix git checkout after updating on my mips-based Yeeloong is so
slow that I'm in the habit of letting it run overnight.

So again, and I'm saying this calmly but with great concern: given the
current priorities of the project, I could not recommend Guix to users
of non-x86_64 architectures, and I don't see how we can fix that without
attracting more developers who use those architectures.  However, I
don't see how we could attract those developers if we continue to
prioritize "moving forward" at full speed for x86_64 users, even when it
breaks other systems.

> Generalizations about “this community” obviously make no sense.  You are
> a part of “this community” so it cares just as much as you do.

By that reasoning, since I'm part of the community of humans on planet
Earth, the community of humans on planet Earth therefore cares as much
about free software as I do.

When I suggest that the community would not take certain suggestions
seriously, e.g. the suggestion to block upgrades or merges that would
break non-x86_64 systems, that statement has some meaning.  I means that
I expect that most people here would disagree, and that the maintainers
would rule in favor of "moving forward" at full speed, and that it will
be the responsibility of the tiny number of non-x86_64 Guix users to fix
portability bugs as quickly as needed so that the x86_64-using majority
need not suffer any delays.  The problem is, we would need a *lot* more
non-x86_64 developers in our community to make that work, and we cannot
attract those developers given the current policies.

> Please let’s work in a friendly manner towards finding solutions to the
> problems.

I'm open to suggestions.  Do you see any solution to the problem of how
to attract more non-x86_64 users, given our current policies?

     Thanks,
       Mark

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 5023 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Hi Ludovic,
>
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> 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.
>>
>> This kind of rant is really unhelpful.  You’re shouting at someone who
>> *is* doing the work of keeping things running.
>
> I wasn't actually shouting, but in retrospect I can see how it came off
> that way.  I apologize for any hurt feelings that I caused.
>
> This is not Marius' fault, and I didn't intend to target him
> specifically.  I'm grateful for the large amount of important work that
> he does on Guix.
>
> However, I do feel frustrated by the fact that it's considered
> acceptable in this community to leave non-x86_64 users with broken
> systems in the name of "moving things forward" for x86_64 users.
>
> Portability is important to the long-term health of the free software
> movement.  Especially given that fact that Intel has long ago stopped
> producing processors that can be used without large amounts of nonfree
> software (including the Intel Management Engine), I think we should work
> to ensure that Guix works well for users of non-x86_64 systems.
>
> The origin of this problem is not in the Guix project.  Ultimately, it's
> due to the fact that x86_64 has far too much market share among
> GNU/Linux developers, and therefore the upstream projects upon which
> Guix depends are not being sufficiently tested on other platforms.
>
> However, there is one aspect of Guix that is greatly exacerbating this
> problem: our impatience to always have the latest software, even if it
> breaks other systems, is a serious problem in my view.
>
> It means that if I want to ensure that Guix works well for i686 or armhf
> users, then I would need to start trying to use Guix on those systems
> for real work, which at the present time would entail almost
> single-handedly fixing all of the portability bugs in all of the
> software that I use, at the full pace of upstream development.  I would
> need to keep this up for long enough to make Guix appear to be a safe
> choice for i686 or armhf users, so that some of them might help work on
> these portability issues in the future.
>
> Another problem is that Guile 2.2's compiler has become so heavy that
> it's nearly unbearable to use on slower hardware.  Simply running "make"
> in my Guix git checkout after updating on my mips-based Yeeloong is so
> slow that I'm in the habit of letting it run overnight.
>
> So again, and I'm saying this calmly but with great concern: given the
> current priorities of the project, I could not recommend Guix to users
> of non-x86_64 architectures, and I don't see how we can fix that without
> attracting more developers who use those architectures.  However, I
> don't see how we could attract those developers if we continue to
> prioritize "moving forward" at full speed for x86_64 users, even when it
> breaks other systems.
>
>> Generalizations about “this community” obviously make no sense.  You are
>> a part of “this community” so it cares just as much as you do.
>
> By that reasoning, since I'm part of the community of humans on planet
> Earth, the community of humans on planet Earth therefore cares as much
> about free software as I do.
>
> When I suggest that the community would not take certain suggestions
> seriously, e.g. the suggestion to block upgrades or merges that would
> break non-x86_64 systems, that statement has some meaning.  I means that
> I expect that most people here would disagree, and that the maintainers
> would rule in favor of "moving forward" at full speed, and that it will
> be the responsibility of the tiny number of non-x86_64 Guix users to fix
> portability bugs as quickly as needed so that the x86_64-using majority
> need not suffer any delays.  The problem is, we would need a *lot* more
> non-x86_64 developers in our community to make that work, and we cannot
> attract those developers given the current policies.
>
>> Please let’s work in a friendly manner towards finding solutions to the
>> problems.
>
> I'm open to suggestions.  Do you see any solution to the problem of how
> to attract more non-x86_64 users, given our current policies?
>
>      Thanks,
>        Mark

I am interested in helping with non-x86_64 issues. Particularly, helping
with i686-related changes should be just a change in workflow, but I'm
interested in obtaining freedom-respecting non-x86 hardware (or at least
using a virtual machine as close as possible to real hardware
configurations). Any recommendation or links for where I can get a
Yeeloong laptop or what freedom-respecting armhf computers are
available?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Ricardo Wurmus]

Hi Mark,

> However, I do feel frustrated by the fact that it's considered
> acceptable in this community to leave non-x86_64 users with broken
> systems in the name of "moving things forward" for x86_64 users.

I don’t think this is true.

> When I suggest that the community would not take certain suggestions
> seriously, e.g. the suggestion to block upgrades or merges that would
> break non-x86_64 systems, that statement has some meaning.  I means that
> I expect that most people here would disagree, and that the maintainers
> would rule in favor of "moving forward" at full speed, and that it will
> be the responsibility of the tiny number of non-x86_64 Guix users to fix
> portability bugs as quickly as needed so that the x86_64-using majority
> need not suffer any delays.

It’s neither about “moving forward” at all costs nor about “full speed”;
while we are generally moving forward, it’s hardly at full speed.  The
last core-updates merge was blocked for months, but it contained
critical fixes that had to be worked around in other branches, which was
an untenable position given the number of developers.

FWIW, I’m using a i686 machine with 2GB RAM myself, and I did test the
core-updates things on that machine (as far as the software is concerned
that I’m using).  I was rather surprised by the GRUB bug, to be honest.

I do agree with your laments about a lack of popularity of non-x86_64
systems and thus developers, but I do think this has been getting better
with the work this community has done to support Guix for the aarch64
and armhf architectures, and by adding aarch64/armhf build servers to
the build farm.  We can and should do more of this, but it won’t happen
by decree.

One thing that would help, in my opinion, is to purchase hardware and
make it available to interested developers and/or join these new
machines to the build farm.  We would need to come to an agreement about
at least these things:

  * what exact system configurations do we want?
  * where would these systems be hosted?
  * how many do we need / can we afford to buy and pay hosting fees for?

The last time this has come up the discussion kinda tapered out.  It
would be good if someone or a group of people would volunteer to take
this on and drive this project to its conclusion.

--
Ricardo

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Ludovic Courtès]

Hello Kei,

Kei Kebreau <kkebreau@posteo.net> skribis:

> I am interested in helping with non-x86_64 issues. Particularly, helping
> with i686-related changes should be just a change in workflow, but I'm
> interested in obtaining freedom-respecting non-x86 hardware (or at least
> using a virtual machine as close as possible to real hardware
> configurations). Any recommendation or links for where I can get a
> Yeeloong laptop or what freedom-respecting armhf computers are
> available?

Without having actual hardware, you can use the qemu-binfmt service on
your machine (info "(guix) Virtualization Services").  It’s slow, but it
allows you to reproduce and debug issues for other architectures.

Thanks,
Ludo’.

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Ludovic Courtès]

Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

>> However, I do feel frustrated by the fact that it's considered
>> acceptable in this community to leave non-x86_64 users with broken
>> systems in the name of "moving things forward" for x86_64 users.
>
> I don’t think this is true.

What is true is that most Guix users use x86_64 primarily.  But there’s
also a lot of interest in ARM.

Guix doesn’t exist in a vacuum, and I think the situation of non-x86_64
support in Guix is just as good or bad as in other free software
projects.  We have fewer packages available on non-x86_64 architectures,
but that’s in large part due to upstream packages not supporting those
architectures in the first place.

I agree this is sad, but repeating it doesn’t help address it.

> I do agree with your laments about a lack of popularity of non-x86_64
> systems and thus developers, but I do think this has been getting better
> with the work this community has done to support Guix for the aarch64
> and armhf architectures, and by adding aarch64/armhf build servers to
> the build farm.  We can and should do more of this, but it won’t happen
> by decree.

Agreed.

> One thing that would help, in my opinion, is to purchase hardware and
> make it available to interested developers and/or join these new
> machines to the build farm.  We would need to come to an agreement about
> at least these things:
>
>   * what exact system configurations do we want?
>   * where would these systems be hosted?
>   * how many do we need / can we afford to buy and pay hosting fees for?
>
> The last time this has come up the discussion kinda tapered out.  It
> would be good if someone or a group of people would volunteer to take
> this on and drive this project to its conclusion.

I agree!  If someone cares about ARM, for instance, now’s the time to
tell us what we should buy and to offer to help out with
hosting/sysadmin.  That would be immensely helpful in maintaining
non-x86_64 up to speed.

Thanks,
Ludo’.

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Another problem is that Guile 2.2's compiler has become so heavy that
> it's nearly unbearable to use on slower hardware.  Simply running "make"
> in my Guix git checkout after updating on my mips-based Yeeloong is so
> slow that I'm in the habit of letting it run overnight.

This is a topic on its own, and I really think we can and should do
better.  I posted observations on where the compiler is spending its
time and memory earlier; Andy pushed improvements, but I believe there’s
much more than can be done:

  https://lists.gnu.org/archive/html/guile-devel/2017-10/msg00035.html
  https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00033.html

Ludo’.

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Ludovic Courtès]

Hi again Mark,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> 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.
>>
>> This kind of rant is really unhelpful.  You’re shouting at someone who
>> *is* doing the work of keeping things running.
>
> I wasn't actually shouting, but in retrospect I can see how it came off
> that way.  I apologize for any hurt feelings that I caused.

I think the error is to suggest that people genuinely don’t care about
the issues.

Often they’re unaware, and sometimes they make suboptimal tradeoffs, as
in the PatchELF case, simply because the status quo is worse than the
suboptimal tradeoff.

> However, I do feel frustrated by the fact that it's considered
> acceptable in this community to leave non-x86_64 users with broken
> systems in the name of "moving things forward" for x86_64 users.

Like I write, it’s not “considered acceptable.”  That’s just not the way
it works.

There’s an implicit rule that we should not break any architecture
badly, but just like sometimes packages fail to build, sometimes there
are architecture-specific issues; and just like an unpopular package
that fails to build is likely to remain that way, an unpopular
architecture is more likely to have issues.

We don’t have to take it as a fact of life, though.  We can work
proactively to mitigate that, and support for those architectures in the
build farm, along with heads-up from overseers (like you’ve been doing
to great effect!) can greatly help.  It won’t bring, say, MIPS to the
level of support of x86_64, but it can reduce damage.

> I'm open to suggestions.  Do you see any solution to the problem of how
> to attract more non-x86_64 users, given our current policies?

Efraim, Danny, Vagrant, Julien, Mathieu, etc. have done a lot of work
fiddling with ARMv7 and AArch64.  We should encourage that, and
providing timely substitutes for the arches is one way to do it, and
ultimately to attract more users and contributors.

Thanks,
Ludo’.

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Jonathan Brielmaier]

On 7/5/18 12:32 AM, Kei Kebreau wrote:
>> I'm open to suggestions.  Do you see any solution to the problem of how
>> to attract more non-x86_64 users, given our current policies?
>>
>>      Thanks,
>>        Mark
> 
> I am interested in helping with non-x86_64 issues. Particularly, helping
> with i686-related changes should be just a change in workflow, but I'm
> interested in obtaining freedom-respecting non-x86 hardware (or at least
> using a virtual machine as close as possible to real hardware
> configurations). Any recommendation or links for where I can get a
> Yeeloong laptop or what freedom-respecting armhf computers are
> available?

I just want to bring POWER up as a freedom-respecting architecture.
Especially the TalosII from RaptorCS[0]. I know that guix does not work
on ppc64le yet, but I'm working for it :) They tend to be quite
expensive, but you get a decent performance on compiling and packing[1].

Regarding ARM hardware: I have access to a bunch of performant ARM
machines (Cavium Thunder, AMD ARM stuff etc.) at work. So feel free to
drop me a mail or set me to CC, if you need something to be tested on ARM :)

[0] https://raptorcs.com/
[1] https://www.phoronix.com/scan.php?page=article&item=power9-talos-2&num=3

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Andreas Enge]

Hello all,

of course I can all but agree that support for "exotic" hardware is very
desirable, especially since, as Mark pointed out, we would like it to become
more mainstream!

On Thu, Jul 05, 2018 at 08:38:19AM +0200, Ricardo Wurmus wrote:
> One thing that would help, in my opinion, is to purchase hardware and
> make it available to interested developers and/or join these new
> machines to the build farm.

If people want to look at armhf, one of the donated Novena boards is currently
running in my living room, under the name of redhill.guixsd.org. I could
of course create accounts for Guix developers who want to have access to
debug the architecture.

Andreas

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello Kei,
>
> Kei Kebreau <kkebreau@posteo.net> skribis:
>
>> I am interested in helping with non-x86_64 issues. Particularly, helping
>> with i686-related changes should be just a change in workflow, but I'm
>> interested in obtaining freedom-respecting non-x86 hardware (or at least
>> using a virtual machine as close as possible to real hardware
>> configurations). Any recommendation or links for where I can get a
>> Yeeloong laptop or what freedom-respecting armhf computers are
>> available?
>
> Without having actual hardware, you can use the qemu-binfmt service on
> your machine (info "(guix) Virtualization Services").  It’s slow, but it
> allows you to reproduce and debug issues for other architectures.
>
> Thanks,
> Ludo’.

Wow, this is excellent! Thanks for the tip.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)

[Andreas Enge]

Hello,

On Thu, Jul 05, 2018 at 11:04:31AM +0200, Jonathan Brielmaier wrote:
> I just want to bring POWER up as a freedom-respecting architecture.
> Especially the TalosII from RaptorCS[0]. I know that guix does not work
> on ppc64le yet, but I'm working for it :) They tend to be quite
> expensive, but you get a decent performance on compiling and packing[1].

this is indeed an exciting architecture. Vikings had a machine on display
at their FOSDEM table earlier this year. But the price is still quite
steep, if you know anybody who would sponsor a machine...

Andreas