RE: debian riscv64 stable build question
Thank you very much for the information Paul. I'll see how our company can contribute to the port.
> -----Original Message-----
> From: Paul Wise <pabs@debian.org>
> Sent: Friday, May 27, 2022 3:33 PM
> To: Tienhock Loh <tienhock.loh@starfivetech.com>; debian-
> riscv@lists.debian.org
> Subject: Re: debian riscv64 stable build question
>
> Another hopefully not too long mail :)
>
> On Fri, 2022-05-27 at 01:22 +0000, Tienhock Loh wrote:
>
> > Who is considered the team?
>
> This is quite fuzzy. Anyone who regularly contributes to the port in some way
> (fixing build/test failures etc) should be considered part of the team. There is
> also the list of people who are registered on the port wiki page as part of the
> team. riscv64 doesn't yet have a wiki page based on the port template page,
> but the RISC-V port family wiki page has a credits section with the names of
> people who did early work.
> In addition, the people who responded to the most recent roll call for porters
> sent out by the Debian release team are considered part of the port team by
> the release team. Their names are listed in the title attribute of the porters
> item in the release arch qualification page and also in the underlying YAML
> data for all the arches.
>
> https://wiki.debian.org/Ports
> https://wiki.debian.org/PortTemplate
> https://wiki.debian.org/RISC-V#Credits
> https://lists.debian.org/debian-release/2021/10/msg00138.html
> https://release.debian.org/testing/arch_qualify.html
> https://release.debian.org/testing/arch_spec.yaml
>
> > Anyway I can get myself into the team?
>
> Start by regularly working on the RISC-V FTBFS bugs and then respond to the
> release team's porter roll call. Click the reply link in the mail archive link I
> posted above and most MUAs will reply to the thread properly, except you
> might have to cut/paste the mail to quote it.
>
> > Are there any criteria that I can check?
>
> The packages needed to create a buildd are all of build-essential plus
> anything basic needed to boot and administer the machine. So probably
> things like the Linux kernel, bootloaders and OpenSSH, not fully sure..
>
> > So the unofficial ports will be like a bootstrapping for official
> > ports. The unofficial ports will run on RISC-V board as buildd server.
> > Understood.
>
> Correct. Hopefully in future we will be able to do automated bootstrap via
> cross-builds instead of needing the unofficial port binaries and later breaking
> build cycles with manual builds, but Debian's buildd setup doesn't currently
> support this. There is work towards this with build profiles, rebootstrap and
> other efforts, but it is not complete yet and lots of Debian cannot be cross-
> built yet. Outside Debian there is also work going on to be able to build an
> entire Linux distro starting from only ~512 bytes of binary code plus all the
> source code, without any other binaries, but that is a much longer term
> project.
>
> https://wiki.debian.org/BuildProfileSpec
> https://wiki.debian.org/HelmutGrohne/rebootstrap
> https://wiki.debian.org/DebianBootstrap
> https://bootstrap.debian.net/
> https://wiki.debian.org/CrossCompiling
> https://crossqa.debian.net/
> https://bootstrappable.org/
>
> > Noted, let me see if I need to do the exercise or should just jump
> > into helping to fix build issues with packages.
>
> Probably a good idea to work on both in parallel.
>
> > I see, promotion from unstable -> stable will happen, and referring to
> > https://udd.debian.org/cgi-bin/ftbfs.cgi?arch=riscv64&release=bookworm
> > ,
> > the bookworm is the current unstable
>
> bookworm is the current "testing" suite, the "unstable" suite is sid, packages
> automatically flow from unstable to testing when they are acceptable
> according the rules (no RC bugs, tested etc) set by the release team, the
> process is managed by some software called "britney".
> Only official architectures that are release architectures get to migrate from
> unstable to testing and later be allowed in the release.
>
> https://release.debian.org/doc/britney/
>
> > and will promote to stable when time comes. If RISC-V builds managed
> > to pass the above-mentioned criteria, then it archives will be copied
> > into stable and can be used.
>
> These are the steps:
>
> 0) unofficial arch on ports.d.o, packages for unstable only,
> this is where riscv64 is now.
> 1) archive qualification
> 2) official arch on ftp.d.o, packages for unstable only
> 3) release qualification
> 4) britney migrates packages to testing, blocking things that stop
> building on all the release architectures they built on before.
> 5) official arch on ftp.d.o, packages for testing/unstable only
> 6) bookworm release of all release architectures
> 7) official arch on ftp.d.o, packages for stable/testing/unstable only
>
> This may change at some point to allow releases of unofficial architectures, in
> order to create an architecture tier system, but that requires lots of work on
> the infrastructure and is unlikely to happen for the bookworm release cycle.
>
> > I see some folks are already helping out to fix firefox, libreoffice,
> > etc. in the mailing list, I think my question here would be the
> > criteria to get it into stable, so that the community can start
> > focusing on the packages that is crucial I guess?
>
> Every package that is in testing when the bookworm release happens will get
> into stable. The release team policy for architectures is that 98% of the
> packages in Debian must be built in unstable before an official arch can
> become a release arch and then packages migrate to testing.
> It sounds like riscv64 meets that since it has 99% built. Prioritising particular
> packages for fixing is up to the people doing the fixing and depends on the
> use-cases that they want to enable for the release. Some folks want to use
> RISC-V as desktop-like systems, so they are working on desktop software like
> Firefox/LibreOffice. Others might want to work on other packages. Others
> might work on every broken package.
>
> https://release.debian.org/testing/arch_policy.html
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
Reply to: