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. > Cheers, > > Miao Wang cu Adrian
