Hi,

I'm working on some time_t side effects on the emboss package and by
doing so stumbled I upon the fact that i386 builds of packages with a Build-Dependency on clustalw are failing. You can see an example in
Salsa CI for libbio-tools-run-alignment-clustalw-perl[1] which contains

The following packages have unmet dependencies:
builddeps:. : Depends: clustalw but it is not installable
E: Unable to correct problems, you have held broken packages.

When checking the package pool[2] I can find
clustalw_2.1+lgpl-7_i386.deb
which is easily installable in some chroot I created using

sudo debootstrap --arch=i386 sid i386-chroot http://deb.debian.org/debian

Debci seems to be fine in testing clustalw on all architectures[3] and according to build logs[4] all should be fine. Unfortunately

wget -q -O - http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.xz | xzgrep "Package: *clustalw" Packages.xz

is empty and I wonder why. Is the Packages file for i386 just broken
or is it me?

Kind regards
Andreas.

[1] https://salsa.debian.org/perl-team/modules/packages/libbio-tools-run-alignment-clustalw-perl/-/jobs/5431253
[2] http://ftp.debian.org/debian/pool/main/c/clustalw/
[3] https://ci.debian.net/packages/c/clustalw/unstable/i386/
[4] https://buildd.debian.org/status/package.php?p=clustalw

--
http://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Mar 11, 2024 at 12:06:58PM +0100, Andreas Tille wrote:

Debci seems to be fine in testing clustalw on all architectures[3] and according to build logs[4] all should be fine. Unfortunately

wget -q -O - http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.xz | xzgrep "Package: *clustalw" Packages.xz

is empty and I wonder why. Is the Packages file for i386 just broken
or is it me?

Search for "clustalw" in https://ftp-master.debian.org/removals.txt:

[Date: Mon, 26 Feb 2024 18:19:39 -0000] [ftpmaster: Thorsten Alteholz]
Removed the following packages from unstable:

clustalw | 2.1+lgpl-7 | armel, armhf, i386
Closed bugs: 1063063

------------------- Reason -------------------
ROM; emboss-lib does not support of 32 bit architectures any more
----------------------------------------------

... and in fact https://bugs.debian.org/1063063 seems to have been filed
by you?

--
Colin Watson (he/him) [cjwatson@debian.org]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mon, Mar 11, 2024 at 11:41:42AM +0000 schrieb Colin Watson:

Search for "clustalw" in https://ftp-master.debian.org/removals.txt:

[Date: Mon, 26 Feb 2024 18:19:39 -0000] [ftpmaster: Thorsten Alteholz]
Removed the following packages from unstable:

clustalw | 2.1+lgpl-7 | armel, armhf, i386
Closed bugs: 1063063

------------------- Reason -------------------
ROM; emboss-lib does not support of 32 bit architectures any more
----------------------------------------------

... and in fact https://bugs.debian.org/1063063 seems to have been filed
by you?

Yes, I've filed this and this was perfectly intended (even if I forgot
that the bug is done meanwhile which I should have checked before asking
here - sorry about this). It was just that all signs that this package
exists are remaining and its just missing in the Packages file. So
removing a package just means droping it from Packages file and all
other things are cleaned up later on?

Kind regards
Andreas.

--
http://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Mar 11, 2024 at 01:06:49PM +0100, Andreas Tille wrote:

Yes, I've filed this and this was perfectly intended (even if I forgot
that the bug is done meanwhile which I should have checked before asking
here - sorry about this). It was just that all signs that this package exists are remaining and its just missing in the Packages file. So
removing a package just means droping it from Packages file and all
other things are cleaned up later on?

"rmadison clustalw" shows:

clustalw | 2.1+lgpl-6 | oldoldstable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
clustalw | 2.1+lgpl-7 | oldstable | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
clustalw | 2.1+lgpl-7 | stable | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
clustalw | 2.1+lgpl-7 | testing | source, amd64, arm64, mips64el, ppc64el, s390x
clustalw | 2.1+lgpl-7 | unstable | source, amd64, arm64, mips64el, ppc64el, s390x
clustalw | 2.1+lgpl-7 | unstable-debug | source
clustalw | 2.1+lgpl-7+b1 | unstable | riscv64

So since clustalw/2.1+lgpl-7/i386 is still in oldstable and stable, it
has to be kept in the pool; files are only expired from the pool once
they're no longer referenced anywhere. (And yes, I think there's a
delay between removing references from index files and removing the
actual pool files, to avoid mirroring race conditions.)

--
Colin Watson (he/him) [cjwatson@debian.org]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mon, Mar 11, 2024 at 12:12:45PM +0000 schrieb Colin Watson:

"rmadison clustalw" shows:

Shame on me I always forget about rmadison which explains things
perfectly.

So since clustalw/2.1+lgpl-7/i386 is still in oldstable and stable, it
has to be kept in the pool; files are only expired from the pool once
they're no longer referenced anywhere. (And yes, I think there's a
delay between removing references from index files and removing the
actual pool files, to avoid mirroring race conditions.)

This makes perfectly sense.

Thanks again for your patience
Andreas.

--
http://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)