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