On Tue, Mar 17, 2026 at 04:29:44PM +0800, Miao Wang wrote: > > > > 2026年3月17日 06:44，Adrian Bunk <[email protected]> 写道： > > > > On Tue, Mar 17, 2026 at 06:21:04AM +0800, Miao Wang wrote: > >> > >> > >>> 2026年3月17日 06:08，Adrian Bunk <[email protected]> 写道： > >>> > >>> On Tue, Mar 17, 2026 at 05:27:26AM +0800, Miao Wang wrote: > >>>> > >>>> > >>>>> 2026年3月17日 03:14，Adrian Bunk <[email protected]> 写道： > >>>>> > >>>>> On Mon, Mar 16, 2026 at 06:09:34PM +0800, Miao Wang wrote: > >>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I don't know why this should happen. The previous version ipxe-qemu was > >>>>>> actually in the archive before my upload. Actually it was available > >>>>>> when > >>>>>> building on amd64, so building on amd64 was successful. Why it became > >>>>>> unavailable when building on all? I don't quite understand the reason > >>>>>> and I don't know how to prevent this from happening. > >>>>> > >>>>> The binary-all buildds had some backlog yesterday, and didn't start > >>>>> building the package before the amd64 build was installed at > >>>>> incoming.debian.org. > >>>>> > >>>>> incoming.debian.org will stop providing the amd64 package in around > >>>>> 16 hours, the binary-all build might then happen if you just wait. > >>>>> > >>>> > >>>> Hi, thanks for your explanation. I have uploaded a newer version > >>>> of ipxe, which skips the tests and the dependency to workaround > >>>> the current situation. However, I wonder if there is any mechanism > >>>> to prevent this from happening in the future. I suggest that there > >>>> might be opportunity in wanna-build to schedule the build of amd64 > >>>> packages after the corresponding arch-all packages are built. > >>> > >>> Circular build dependencies are a pain for several reasons, > >>> and hacks like what you have in mind are fragile. > >>> > >>> Would running the unit tests as autopkgtest with build-needed > >>> restriction work? That might be less hassle here. > >> > >> It might work. However, when running unit tests during build, > >> not only the code is tested, but the binary object files forming > >> the final firmware/bootroms are also get tested. If doing this in > >> autopkgtest, the object files are recompiled and there is possibility > >> that they become different due to differences of building > >> environments. So the best place to execute the unit tests is in the > >> building process. > >> ... > > > > No disagreement on that. > > > > But the relevant question is whether moving it to an autopkgtest is less > > bad than the circular build dependency. > > mjt suggested that a dummy package could be added to satisfy the dependency > from qemu to qemu-ipxe, to break the dependency loop. I wonder if it is > acceptable.
The more relevant question is whether it is worth it, when you compare benefits and costs. Executing the unit tests in the building process is a benefit. Adding a dummy package is a cost, and users unintentionally installing the dummy package instead of the real package is also a cost. In general, I would try hard to avoid doing user-visible changes for build/test-only benefits. What you want to do (unit tests in the building process) is in general desirable, but you should also consider whether it is really the best option in this specific case. > Cheers, > > Miao Wang cu Adrian
