Hi tienhock, On Fri, May 27, 2022 at 01:22:35AM +0000, Tienhock Loh wrote:
-----Original Message----- From: Paul Wise <pabs@debian.org> Sent: Thursday, May 26, 2022 3:33 PM To: Tienhock Loh <tienhock.loh@starfivetech.com>; debian- riscv@lists.debian.org Subject: Re: debian riscv64 stable build question Apologies for the very long mail, hopefully just enough detail below.Thanks for taking the time to help me out. Some further questions inlined.On Thu, 2022-05-26 at 05:14 +0000, Tienhock Loh wrote: > How does the architecture (not ports) move from unofficial to > official? I don't see much information on this. There is a bit of info about this in the archive criteria document, and I haven't worked on any of this myself, but I think it goes like this: Once there is hardware that meets DSA's requirements: https://dsa.debian.org/ports/hardware-requirements/ and the port itself meets the ftp-master archive requirements; https://ftp-master.debian.org/archive-criteria.html The riscv64 port team will file a request against ftp.debian.org (with usertag arches) for inclusion of the port in the archive, linking to the arch qualification page, which should link to other RISC-V pages.[]Who is considered the team? Anyway I can get myself into the team?
There is no *real* port team in here. Anyone is free to join the team if you have interesting in porting RISC-V on Debian :)
https://wiki.debian.org/ArchiveQualification/riscv64 https://wiki.debian.org/RISC-V https://wiki.debian.org/Ports/riscv64 ;(doesn't exist yet) The archive admins will review this request and respond.[]I see.Enough of the packages from the unofficial port of Debian unstable to be able to create buildds will be imported to the official port.Are there any criteria that I can check?Hardware for the buildds will be delivered to Debian hosting locations. The buildds for the official port will be setup using those packages.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.The initially imported packages will be rebuilt, the rebuilds imported to the official port & the buildds will be updated to those packages. The rest of the archive will be rebuilt using the rebuilt packages.I see.The port team will resolve any circular builds using manual builds with build profiles, the manual builds will be rebuilt etc. There is some documentation about this bootstrapping work on the Ports wiki. https://wiki.debian.org/Ports Once the rebuild is complete, then the port can proceed to qualifying for inclusion in the bookworm release. https://release.debian.org/testing/arch_policy.html https://release.debian.org/testing/arch_qualify.html > From what I understand, there are buildd and porterbox machine > deployed and fulfilled the hardware requirements correct? As I understand it, some of the buildds for the unofficial port are based on qemu on amd64 instead of RISC-V hardware, I think that is not acceptable for an official port, so those would need replacing, I'm not sure if they have been replaced entirely or not. I'm also not sure where they are hosted, usually new ones are setup (or old ones moved) for the official port in existing Debian hosting locations. https://wiki.debian.org/RISC-V#buildd_.28build-daemon.29_information There are no porterboxes according to this: https://wiki.debian.org/RISC-V#PorterboxesOh, I must've mistaken arm64 for riscv64. Silly :(See this page for how to setup an unofficial porterbox: https://wiki.debian.org/PortsDocs/BuilddPorterboxSetupOk noted, let's see if we can get something up.> So the next step is to ensure that packages builds are passing. The "Unofficial port" section of the new port docs links these: https://udd.debian.org/cgi-bin/ftbfs.cgi?arch=riscv64 https://buildd.debian.org/status/architecture.php?a=riscv64&suite=sid > Would it be possible and make sense to start a wanna-build server in > our own company to start building stable or testing branch, deploy > into an archive (not main archive), and run test internally in our > company? Would this help to accelerate progress? The thought process > is that if we can build the current stable/testing (bookworm or > bullseye), we can see how many of the packages can be built using the > stable/testing branch, and start testing? I think if you followed the procedure Debian will use that I mention above, then this seems like a useful exercise, but I think the priority should be in solving build failures (links above) and checking that the port is ready to meet the hardware/archive/release criteria. Since the initial official port will be based on the unofficial port of Debian unstable, definitely use unstable rather than stable/testing.Noted, let me see if I need to do the exercise or should just jump into helping to fix build issues with packages. 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, 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. 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?
The url you mentioned is riscv64 ftbfs issues page, you can pick one tofix it with any packaging tool recommended by Debian. Personally I like to use sbuild to build Debian package[0].
Before this you need setup riscv64 chroot on amd64, refer to[1]. Once done, you need add sid(unstable) source into your host sources.list.
e.g: ``` apt source neochatcd neochat-xx
# fix and patchsbuild --arch=riscv64 -c sid-riscv64-sbuild # sid-riscv64-sbuild is the name you specified when you setup chroot
```This is *native* build with qemu maybe, in fact, I've been confusing him with the concept of cross-compilation in here.
If you build debian package on real riscv64 machines, it is the same way to setup riscv64 chroot and use sbuild without `--arch` switch. This is not pure method to setup riscv64 chroot above maye, but it works for me.In the process you will meet missing corresponding package, it is ok to install them according to hint. please look at the `quilt` tool and try to get
how to play with it. This will bring great convenience to manage patches for you. And: I am struggle to try fix ftbfs firefox[2] & libreoffice[3] if you have interesting in them, please try it:) This will This will enriches applications on riscv Debian. Any porting issues are welcome to post the list or join IRC #debian-riscv on OFTC. Bo[0] https://wiki.debian.org/sbuild [1] https://lists.debian.org/debian-riscv/2022/05/msg00028.html
[2] https://lists.debian.org/debian-riscv/2022/05/msg00065.html [3] https://lists.debian.org/debian-riscv/2022/05/msg00067.html
> From this page: https://release.debian.org/testing/arch_qualify.html, > it looks like we'll need buildd-dsa for riscv64 as well correct? Right, this will happen during the switch from unofficial to official port, I think that as part of the process, enough hardware to rebuild the port and keep up with builds of unstable will be delivered to Debian hosting locations and setup by DSA, the unofficial buildds shut down and the port rebuilt on the official buildds. > What would be the process on this? I looked up on > https://dsa.debian.org/ but not much information. I should be sending > a mail to debian-admin@lists.debian.org for more information? I'm not entirely sure, but I think that after the inclusion of riscv64 into the main archive is accepted, the riscv64 port team would file a ticket with DSA in the request-tracker to discuss hosting and hardware arrangements for the official riscv64 port.I see, notedhttps://wiki.debian.org/Teams/DSA/RTUsage https://wiki.debian.org/rt.debian.orgThank you very much Paul!-- bye, pabs https://wiki.debian.org/PaulWise
-- Best Regards,
Attachment:
signature.asc
Description: PGP signature