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

Re: debian riscv64 stable build question

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


and the port itself meets the ftp-master archive requirements;


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


Once the rebuild is complete, then the port can proceed to qualifying for
inclusion in the bookworm release.


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


There are no porterboxes according to this:


Oh, I must've mistaken arm64 for riscv64. Silly :(

See this page for how to setup an unofficial porterbox:


Ok 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:



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

apt source neochat

cd neochat-xx
# fix and patch

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


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.


[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, noted


Thank you very much Paul!



Best Regards,

Attachment: signature.asc
Description: PGP signature

Reply to: