MIME-Version: 1.0
References: <CAMmSBy-3=MYWhjSVJ1aiMy01mNZxNkERxfvFUpAs6Uwf0sdFgw@mail.gmail.com>
 <2TM9JLZJSHZ31.2Q8Y9DMYGMSGV@8pit.net>
In-Reply-To: <2TM9JLZJSHZ31.2Q8Y9DMYGMSGV@8pit.net>
From: Roman Shaposhnik <roman@zededa.com>
Date: Mon, 17 May 2021 13:38:19 -0700
Message-ID: <CAMmSBy-JDGHEsWBrbK+42JBy7m9YHaKPsZ6HxeMbQd2iu97SHg@mail.gmail.com>
Subject: Re: Proposal for next steps in support of riscv64 in Alpine
To: =?UTF-8?Q?S=C3=B6ren_Tempel?= <soeren@soeren-tempel.net>
Cc: ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 17, 2021 at 1:22 PM S=C3=B6ren Tempel <soeren@soeren-tempel.net=
> wrote:
>
> Roman Shaposhnik <roman@zededa.com> wrote:
> > Hi!
>
> Hi!
>
> >      2. bundled config.sub not being recent enough to recognize riscv64=
.
> >      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 int=
o patches
> >                    against bundled config.sub. This, however will incre=
ase
> >                    the maintenance cost and is effectively equivalent t=
o the
> >                    above cp statement anyway.
>
> Just use the update_config_sub() function provided by abuild:
>
>         https://gitlab.alpinelinux.org/alpine/abuild/-/blob/ac3ee42458ebb=
6204c75135cbeb30201777e4116/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 fundam=
ental
> >       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 there
> is currently not a single aport in aports.git which disables postchecks.

It is funny you should mention that -- because right after sending the emai
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 aarch6=
4
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 dependen=
cy
tree and holding up publishing riscv64 seems like a worse outcome than disa=
bling
it selectively like the above statement does.

Will this work?

> >         7. Finally, for whatever reason sha512 sums have changed for do=
wnloaded
> >         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.

Well, FWIW: there's a set of things I fixed in that commit -- and there's a=
lso
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.

Also, speaking of 3.14 -- that's my other question -- seeing if it would
be feasible to include riscv64 support in that.

Thanks,
Roman.