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
Attachment:
signature.asc
Description: This is a digitally signed message part