Bug#1121569: Recursive FTBFS report regrading multiple packages in trixie
Package: release.debian.org
Severity: important
X-Debbugs-Cc: sanvila@debian.org, 1118744@bugs.debian.org
Hi,
I'm writing to report some FTBFS bugs relating to more than one package in
Debian trixie. I met the bugs during a full rebootstrap of the current stable
repo on a new arch. However, these bugs can also be reproduced on the official
supported arches. The common pattern of such bugs is that package Barz B-D on
package Bar and package Bar B-D on package Foo. If two of the three packages
are kept not touched, the third package can be built successfully. However, if
Bar is rebuilt, a different version of Bar from that one currently in the repo
will be generated, because the current stable Bar is built against an older
version of Foo. With the rebuilt version of Bar, Barz will fail to be built.
I'll provide the two actual cases I've met.
1. Opencv FTBFS with missing python3-numpy build dependency, which is reported
in [1], and related to opencv, imath and numpy. The root cause is a change of
behavior of dh_numpy3 script in numpy in numpy_1:2.2.3+ds-3. The imath
currently in the stable repo is built against an older version of numpy,
1:2.2.2+ds-2. If imath is rebuilt, the generated python3-imath will lack the
dependency to python3-numpy, because the rules file in imath invokes dh_numpy3
before dh_install, which is beyond the expectation of the author of the
dh_numpy3. With the rebuilt python3-imath, opencv cannot be built, due to the
missing indirect build dependency to python3-numpy. As a result, we have a
potential risk of missing a dependency of python3-imath if imath is rebuilt or
upgraded in stable.
2. geeqie_1:2.5-8 FTBFS with not passing the dh_autotest, which is related to
geeqie, grep and pcre2. There is a script from upstream in geeqie, which
checks if all the strings are surrounded my the gettext translator function
_() using grep[2]. The author expected the pattern "[[:lower:]]" would match
only the ascii characters a-z, which is indeed the case for grep_3.11-4
currently in the stable repo. However, grep_3.11-4 is built against an older
version of libpcre2-dev_10.42-4 while the current stable version of pcre2 is
10.46-1~deb13u1. grep will change its behavior during build time according the
availability of the macro PCRE2_EXTRA_ASCII_BSD in the pcre2 header[3] and will
not change the behavior during runtime even if the actual running version of
the pcre2 library upgrades. As a result, if grep is rebuilt, its behavior
will change to also matching characters like é with the pattern "[[:lower:]]",
and resulting a false positive during the checking of untranslated strings in
geeqie. Currently the upstream of geeqie has fixed this problem[4] and the
version in sid has already included this fix. However the version in stable is
still to be affected if grep in the stable is rebuilt or upgraded, and we have
potential risk of behavior change of grep in stable if it is rebuilt or
upgraded.
I've disussed this issue with Santiago Vila, who suggested me to report it
to release manager. I make the two issues in one bug report, considering they
share the same pattern and there might be more like this undiscovered.
Cheers,
Miao Wang
Reply to: