Date: Tue, 18 May 2021 20:56:51 -0500 (CDT)
From: Ariadne Conill <ariadne@dereferenced.org>
To: Natanael Copa <ncopa@alpinelinux.org>
cc: Roman Shaposhnik <roman@zededa.com>, 
    =?ISO-8859-15?Q?S=F6ren_Tempel?= <soeren@soeren-tempel.net>, 
    ~alpine/devel@lists.alpinelinux.org
Subject: Re: Proposal for next steps in support of riscv64 in Alpine
In-Reply-To: <20210518101244.09ec8386@ncopa-desktop.lan>
Message-ID: <d9abfbc-f882-3c86-18b5-b3dcb6d1a96a@dereferenced.org>
References: <CAMmSBy-3=MYWhjSVJ1aiMy01mNZxNkERxfvFUpAs6Uwf0sdFgw@mail.gmail.com> <2TM9JLZJSHZ31.2Q8Y9DMYGMSGV@8pit.net> <CAMmSBy-JDGHEsWBrbK+42JBy7m9YHaKPsZ6HxeMbQd2iu97SHg@mail.gmail.com> <20210518101244.09ec8386@ncopa-desktop.lan>
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="0-1738029951-1621389402=:28236"
Content-ID: <68df4d13-79ff-ec83-bea9-7b40e51589a@dereferenced.org>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1738029951-1621389402=:28236
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-ID: <b5345086-ddba-42dc-89f0-5bfc204f2d88@dereferenced.org>

Hello,

On Tue, 18 May 2021, Natanael Copa wrote:

> On Mon, 17 May 2021 13:38:19 -0700
> Roman Shaposhnik <roman@zededa.com> wrote:
>
>> On Mon, May 17, 2021 at 1:22 PM S=F6ren Tempel <soeren@soeren-tempel.net=
> wrote:
>>>
>>> Roman Shaposhnik <roman@zededa.com> wrote:
>>>> Hi!
>>>
>>> Hi!
>
> Hi! Great job you have done so far with the riscv64!
>
>>>>      2. bundled config.sub not being recent enough to recognize riscv6=
4.
>>>>      The workaround I used for now is:
>>>>                cp /usr/share/abuild/config.sub .
>>>>       in the build() function. On top of that:
>>>>             2.1. I can make it conditional based on riscv64
>>>>             2.2. I can, possibly (if there's a lot desire), turn it in=
to patches
>>>>                    against bundled config.sub. This, however will incr=
ease
>>>>                    the maintenance cost and is effectively equivalent =
to the
>>>>                    above cp statement anyway.
>>>
>>> Just use the update_config_sub() function provided by abuild:
>>>
>>>         https://gitlab.alpinelinux.org/alpine/abuild/-/blob/ac3ee42458e=
bb6204c75135cbeb30201777e4116/abuild.in#L644
>>
>> That's a great suggestion -- will change to use that!
>>
>>>>       3. There's a few packages that come out with TEXTRELs and thus
>>>>       fail the postcheck() by default. They seem to be fully functional
>>>>       otherwise. For now, I'm proposing to disable the postcheck based
>>>>       on riscv64 case statement. Please let me know if there's a funda=
mental
>>>>       disagreement with this approach.
>>>
>>> It's generally preferable to investigate why sanity checks fails and fix
>>> the underlying failure reason instead of disabling a check. I think the=
re
>>> is currently not a single aport in aports.git which disables postchecks.
>>
>> It is funny you should mention that -- because right after sending the e=
mai
>> I've discovered:
>>
>> if [ "$CARCH" =3D x86 ]; then
>>         # Bug upstream that needs to be fixed
>>         options=3D"$options textrels"
>> fi
>>
>> in mesa/APKBUILD
>>
>> Which is definitely a much more precise approach and if it works for aar=
ch64
>> I'd love to use that unless there's a strong objection.
>>
>> Now, just to be clear -- at this point I only need it for roughly a
>> dozen packages
>> on main, but the problem is that they are close to the root of the depen=
dency
>> tree and holding up publishing riscv64 seems like a worse outcome than d=
isabling
>> it selectively like the above statement does.
>>
>> Will this work?
>
> Yes. I think so. Do something like:
>
> case "$CARCH" in
> 	x86|riscv64) options=3D"$options textrels";;
> esac
>
> Textrels often happens if there are some assembly or missing -fPIC, at
> least in the x86 case.
>
>>>>         7. Finally, for whatever reason sha512 sums have changed for d=
ownloaded
>>>>         artifacts (a good cluster is around acf-* packages). Not sure
>>>> what's up with
>>>>         that, but it surely doesn't seem riscv64 related (and btw, all
>>>> of them built fine
>>>>         when I manually updated the checksums).
>>>
>>> Happens, these general download issues will also be fixed anyhow as we
>>> are currently rebuilding all packages for the upcoming 3.14 release.
>
> It is super annoying that it happens. I think in most cases it happens
> because the tarballs are generated on the fly from gitlab or similar,
> and the way the tarballs are generated is changed. I think recent
> gitlab changed the compression level for gzip.
>
> I think tarballs generated on the fly is a general bad idea. In any
> case, it is not really related the riscv64 port.

This is one of the reasons why I want to make it possible for abuild to=20
fetch git tags instead.  Lots of people are just doing git tags for=20
releases now without uploading actually stable tarballs, so every time=20
something changes, the tarball content also changes.  If we had git=20
support in abuild, we could just use git for these projects and not have=20
to deal with this anymore.

>
>> Well, FWIW: there's a set of things I fixed in that commit -- and there'=
s also
>> ones (like procps) that fail to download completely:
>>
>> https://download.savannah.gnu.org/releases/quagga/quagga-1.2.4.tar.gz
>> https://dianne.skoll.ca/projects/rp-pppoe/download/rp-pppoe-3.14.tar.gz
>> http://ftp.debian.org/debian/pool/main/l/logcheck/logcheck_1.3.22.tar.xz
>> http://members.home.nl/p.a.rombouts/pdnsd/releases/pdnsd-1.2.9a-par.tar.=
gz
>>
>> Hope this helps.
>
> You can set
>
>  DISTFILES_MIRROR=3Dhttps://distfiles.alpinelinux.org/distfiles
>
> in/etc/abuild.conf to make abuild try our cached copy before downloading
> from upstream. Will work around most of those issues.
>
> That said, someone should see if upstream has moved the download to new
> location or report to upstream that the download URL is broken.
>
> (the ftp.debian.org/debian/pool thing should probably just be upgraded
> to newer version. I don't think debian keeps older versions)
>
>>
>> Also, speaking of 3.14 -- that's my other question -- seeing if it would
>> be feasible to include riscv64 support in that.
>
> I think I would prefer to not rush it and delay the 3.14 release even
> more. I'd like to add it right after the 3.14 release to alpine edge
> (development/rolling release) and aim for 3.15.

+1 lets focus on getting 3.14 out the door first.  We're not in any=20
particular rush for this (after all, EVE can use the interim repo for the=20
port for a couple of weeks until 3.14 is out and we have time to integrate =

the qemu riscv64 builder into the build infrastructure).

Ariadne
--0-1738029951-1621389402=:28236--