Re: RFS: hipfft/5.5.1-1 [ITP] -- portable interface for Fast Fourier Transforms on the GPU
On 2023-06-18 08:26, Cordell Bloor wrote:
> On 2023-06-17 06:11, Christian Kastner wrote:
> I'll put learning sbuild on my todo list, so I can use a proper
> chroot.
There are various package builders out there [1] that can build in
pristine environments (including docker), but yeah, sbuild has the
advantage of being the official build tool.
It's a personal preference, but I dislike the schroot backend. I tend to
use either --chroot-mode=unshare or --chroot-mode=autopkgtest, the
latter of which enables use of all autopkgtest backends [2].
I wrote a couple of helper scripts for the autopkgtest QEMU backend,
available in package 'sbuild-qemu' (from bookworm):
$ sudo sbuild-qemu-create -o <path>/unstable-autopkgtest-amd64.img unstable http://deb.debian.org/debian
$ sudo chown <user>: <path>/unstable-autopkgtest-amd64.img
$ cd <git-repo>
$ gbp buildpackage --git-builder=sbuild-qemu --image <path>/unstable-autopkgtest-amd64.img <other-sbuild-options>
[ For ROCm packages, you'll want to increase --ram-size and --cpus ]
This was because some of the packages I maintain truly needed full
system emulation [3].
By the way, a frequent recommendation for packages with arch:all and
arch:any binary packages is to do an arch:all-only build. That's how one
can catch FTBFS like the one you found recently with that -doc package.
> You also reminded me to review the dev package dependencies and verify
> them by building the examples. I've updated the package with the
> necessary changes.
sbuild can only detect build-time dependency issues, but the images can
of course be used for running the autopkgtests, so you could put the
example building in an autopkgtest [4], and thus have this step
repeatable by the CI infra. This is helpful not just to detect missing
dependencies, but to detect future breakages caused by dependencies.
$ cd <build-output>
$ autopkgtest -B *.deb *.dsc -- qemu <path>/unstable-autopkgtest-amd64.img
> The rocm-cmake package provides a library of cmake scripts. I'm not sure
> what the right answer is. Similar packages, such as cmake-extras or
> extra-cmake-modules don't seem to be consistent about this. That said, I
> can't think of any way to use rocm-cmake without cmake.
Yeah, so I guess a Depends would be warranted, then. But that would
mean that reverse B-D would need a versioned dependency on rocm-cmake,
so not much gained.
Let's just keep this in mind for now.
Best,
Christian
[1] https://wiki.debian.org/SystemBuildTools
[2] Unfortunately, the autopkgtest docker/podman backend doesn't seem to
work currently, see #1033352. And I know too little Perl to fix it.
[3] The ROCm stack is a good candidate because of its connection to the
kernel driver. But the sbuild and autopkgtest invocation is a bit
trickier, and unfortunately, something broke in unstable after the
bookworm release... My card now hangs after each test.
[4] I put this up for debate:
https://salsa.debian.org/rocm-team/community/team-project/-/wikis/autopkgtest-policy#build-tests
Reply to: