Date: Tue, 18 May 2021 10:12:44 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Roman Shaposhnik <roman@zededa.com>
Cc: =?ISO-8859-1?B?U/ZyZW4=?= Tempel <soeren@soeren-tempel.net>,
 ~alpine/devel@lists.alpinelinux.org
Subject: Re: Proposal for next steps in support of riscv64 in Alpine
Message-ID: <20210518101244.09ec8386@ncopa-desktop.lan>
In-Reply-To: <CAMmSBy-JDGHEsWBrbK+42JBy7m9YHaKPsZ6HxeMbQd2iu97SHg@mail.gmail.com>
References: <CAMmSBy-3=MYWhjSVJ1aiMy01mNZxNkERxfvFUpAs6Uwf0sdFgw@mail.gmail.com>
	<2TM9JLZJSHZ31.2Q8Y9DMYGMSGV@8pit.net>
	<CAMmSBy-JDGHEsWBrbK+42JBy7m9YHaKPsZ6HxeMbQd2iu97SHg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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: =20
> > > Hi! =20
> >
> > Hi!

Hi! Great job you have done so far with the riscv64!

> > >      2. bundled config.sub not being recent enough to recognize riscv=
64.
> > >      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 i=
nto patches
> > >                    against bundled config.sub. This, however will inc=
rease
> > >                    the maintenance cost and is effectively equivalent=
 to the
> > >                    above cp statement anyway. =20
> >
> > Just use the update_config_sub() function provided by abuild:
> >
> >         https://gitlab.alpinelinux.org/alpine/abuild/-/blob/ac3ee42458e=
bb6204c75135cbeb30201777e4116/abuild.in#L644 =20
>=20
> That's a great suggestion -- will change to use that!
>=20
> > >       3. There's a few packages that come out with TEXTRELs and thus
> > >       fail the postcheck() by default. They seem to be fully function=
al
> > >       otherwise. For now, I'm proposing to disable the postcheck based
> > >       on riscv64 case statement. Please let me know if there's a fund=
amental
> > >       disagreement with this approach. =20
> >
> > 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=
. =20
>=20
> It is funny you should mention that -- because right after sending the em=
ai
> I've discovered:
>=20
> if [ "$CARCH" =3D x86 ]; then
>         # Bug upstream that needs to be fixed
>         options=3D"$options textrels"
> fi
>=20
> in mesa/APKBUILD
>=20
> Which is definitely a much more precise approach and if it works for aarc=
h64
> I'd love to use that unless there's a strong objection.
>=20
> 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 depend=
ency
> tree and holding up publishing riscv64 seems like a worse outcome than di=
sabling
> it selectively like the above statement does.
>=20
> 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.
=20
> > >         7. Finally, for whatever reason sha512 sums have changed for =
downloaded
> > >         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). =20
> >
> > Happens, these general download issues will also be fixed anyhow as we
> > are currently rebuilding all packages for the upcoming 3.14 release. =20

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.

> 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:
>=20
> 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
>=20
> 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)

>=20
> 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.

Thanks!

-nc