severity -1 important thanks Chris Hofstaedtler <z...@debian.org> writes:
> On Mon, Sep 23, 2024 at 02:32:20PM +0200, Simon Josefsson wrote: >> I am in the process of uploading a new upstream version into unstable >> that disables armel+armhf builds. > > You don't need to explicitly disable the architecutres, if your > package won't successfully build on them. > Just have the existing binaries removed from unstable and you should > be good. And downgrade this bug's severity, of course. Thanks. I'm trying to work out what the best way to proceed is. I believe downgrading this bug report is now okay, since after the recent 1.4.3-1 upload armel/armhf is simply no longer supported, so build failures on those archs shouldn't happen any more. I chose to keep the bug report open as a reminder to patch upstream's code to support armel+armhf. I used the 'Build-Depends: not-supported-on [armel armhf]' approach to disable builds on armel and armhf for 1.4.3-1. What would you recommend doing now? Is one or more of the following ideas relevant? Thanks for guidance. 1) Drop the B-D hack so that instead builds on armel+armhf will just fail forever? Won't that stall migration or lead to other problems? 2) Is requesting removal of libsocket-wrapper from unstable on armel+armhf necessary? Or will it happen automatically, since the version in unstable on those archs are now not the latest? I don't know the unstable cleanup policy. 3) Should I open bug reports on the packages that Build-Depends on libsocket-wrapper armel/armhf? What should the recommendation be? I suspect most usages of this package is optional and not required for building, so maybe a 'Build-Depends: libsocket-wrapper [!armel !armhf]' would work? 4) Are any removal requests of reverse dependencies necessary or relevant? Will libsocket-wrapper migrate to testing without that? /Simon
signature.asc
Description: PGP signature
