Should we restrict libtread-pool to 64bit only (Was: Bug#1063800: src:pinfish: fails to migrate to testing for too long: not installable on armel, armhf and i386)

Hi,

the chain of dependencies for pinfish which creates the problem is

   pinfish depends racon which in turn can't install its
   Build-Depends libthread-pool 4.0.0 which does not build
   for 32bit architectures[1]

My suggestion to solve the issue is to explicitly set

   Architecture: any-amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64 loong64 ppc64 sparc64 x32

and ask ftpmaster for removing 32bit architectures for libthread-pool,
racon and pinfish.  Does anybody think we should ask libthread-pool
upstream to support 32bit or do we just want to go on to remove 32bit
(which also solves time_t bug easily).

Kind regards
    Andreas.

[1] https://buildd.debian.org/status/package.php?p=libthread-pool

Am Mon, Feb 12, 2024 at 09:35:34PM +0100 schrieb Paul Gevers:
> Source: pinfish
> Version: 0.1.0+ds-3
> Severity: serious
> Control: close -1 0.1.0+ds-4
> Tags: sid trixie
> User: [email protected]
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:pinfish has been trying to migrate for 31 days [2].
> Hence, I am filing this bug. It seem the version in unstable isn't
> installable on our 32 bit architectures. It seems like the version in
> testing doesn't have binaries on these architectures, while the buildd
> history shows they were built for the previous version, so you probably had
> them removed. You probably need to do this again, but I suggest to add a
> Build-Depends on racon to prevent accidental builds on architectures where
> racon isn't available (and thus the package becomes not installable).
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on other
> packages, which makes preparing for the release more difficult. Finally, it
> often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that hamper
> the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new bugs,
> there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if that
> version or a later version migrates, this bug will no longer affect testing.
> I have also tagged this bug to only affect sid and trixie, so it doesn't
> affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2023/06/msg00001.html
> [2] https://qa.debian.org/excuses.php?package=pinfish
> 




> _______________________________________________
> Debian-med-packaging mailing list
> [email protected]
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging