[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


> 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.


> 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.


> 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.




Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: