MIME-Version: 1.0
References: <CAMmSBy-3=MYWhjSVJ1aiMy01mNZxNkERxfvFUpAs6Uwf0sdFgw@mail.gmail.com>
 <2TM9JLZJSHZ31.2Q8Y9DMYGMSGV@8pit.net> <CAMmSBy-JDGHEsWBrbK+42JBy7m9YHaKPsZ6HxeMbQd2iu97SHg@mail.gmail.com>
 <20210518101244.09ec8386@ncopa-desktop.lan> <d9abfbc-f882-3c86-18b5-b3dcb6d1a96a@dereferenced.org>
In-Reply-To: <d9abfbc-f882-3c86-18b5-b3dcb6d1a96a@dereferenced.org>
From: Roman Shaposhnik <roman@zededa.com>
Date: Fri, 21 May 2021 21:01:43 -0700
Message-ID: <CAMmSBy8=ztzcyCNr_vV4QUyXraTxWapDs9WEGM_Db2pWYwun0g@mail.gmail.com>
Subject: Re: Proposal for next steps in support of riscv64 in Alpine
To: Ariadne Conill <ariadne@dereferenced.org>
Cc: Natanael Copa <ncopa@alpinelinux.org>, =?UTF-8?Q?S=C3=B6ren_Tempel?= <soeren@soeren-tempel.net>, 
	~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 18, 2021 at 6:56 PM Ariadne Conill <ariadne@dereferenced.org> w=
rote:
>
> 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=C3=B6ren Tempel <soeren@soeren-tempe=
l.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 risc=
v64.
> >>>>      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 =
into patches
> >>>>                    against bundled config.sub. This, however will in=
crease
> >>>>                    the maintenance cost and is effectively equivalen=
t to the
> >>>>                    above cp statement anyway.
> >>>
> >>> Just use the update_config_sub() function provided by abuild:
> >>>
> >>>         https://gitlab.alpinelinux.org/alpine/abuild/-/blob/ac3ee4245=
8ebb6204c75135cbeb30201777e4116/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 functio=
nal
> >>>>       otherwise. For now, I'm proposing to disable the postcheck bas=
ed
> >>>>       on riscv64 case statement. Please let me know if there's a fun=
damental
> >>>>       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 t=
here
> >>> is currently not a single aport in aports.git which disables postchec=
ks.
> >>
> >> 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 a=
arch64
> >> 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 dep=
endency
> >> tree and holding up publishing riscv64 seems like a worse outcome than=
 disabling
> >> 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=
 downloaded
> >>>>         artifacts (a good cluster is around acf-* packages). Not sur=
e
> >>>> what's up with
> >>>>         that, but it surely doesn't seem riscv64 related (and btw, a=
ll
> >>>> of them built fine
> >>>>         when I manually updated the checksums).
> >>>
> >>> Happens, these general download issues will also be fixed anyhow as w=
e
> >>> 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
> fetch git tags instead.  Lots of people are just doing git tags for
> releases now without uploading actually stable tarballs, so every time
> something changes, the tarball content also changes.  If we had git
> support in abuild, we could just use git for these projects and not have
> to deal with this anymore.
>
> >
> >> Well, FWIW: there's a set of things I fixed in that commit -- and ther=
e'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.g=
z
> >> 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.ta=
r.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 downloadin=
g
> > 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 wou=
ld
> >> 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
> particular rush for this (after all, EVE can use the interim repo for the
> port for a couple of weeks until 3.14 is out and we have time to integrat=
e
> the qemu riscv64 builder into the build infrastructure).

Sounds like a good plan! Let's target 3.15 then.

As you probably have seen, I started submitting all my patches as MRs
on GitLab. Since this is my first time contributing to Alpine -- please be
gentle ;-)

And I also have another favor to ask: would it be possible to add a runner
to the GitLab CI/CD that would be building all MRs on riscv64 starting
right now.
We can declare that runner's status to be unimportant for the state of
the overall
pipeline but it would help me tremendously to make sure that the
packages I already
fixed don't bitrot AND I get a chance to jump onto new packages that
may be flowing
through the pipeline.

Who do I need to work with to prepare that runner? FWIW, I already
have a similar
runner for EVE -- so it really is just a question of updating your
GitLab infra a tiny bit.

A little help, please?

Thanks,
Roman.