RE: debian riscv64 stable build question
> -----Original Message-----
> From: Bo YU <tsu.yubo@gmail.com>
> Sent: Friday, May 27, 2022 10:32 AM
> To: Tienhock Loh <tienhock.loh@starfivetech.com>
> Cc: Paul Wise <pabs@debian.org>; debian-riscv@lists.debian.org
> Subject: 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-
> >> 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 :)
I see. Any idea who will determine if the port is "stable" enough for bookworm?
>
> >
> >>
> >> 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#Porterboxes
> >
> >Oh, I must've mistaken arm64 for riscv64. Silly :(
> >
> >>
> >> See this page for how to setup an unofficial porterbox:
> >>
> >> https://wiki.debian.org/PortsDocs/BuilddPorterboxSetup
> >>
> >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:
> >>
> >> 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 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.
I see, let me try this out and possibly start to fix some simpler packages.
>
> e.g:
> ```
> 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.
>
> 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, noted
> >
> >>
> >> https://wiki.debian.org/Teams/DSA/RTUsage
> >> https://wiki.debian.org/rt.debian.org
> >>
> >
> >Thank you very much Paul!
> >
> >> --
> >> bye,
> >> pabs
> >>
> >> https://wiki.debian.org/PaulWise
>
> --
> Best Regards,
Reply to: