Package: release.debian.org Severity: important X-Debbugs-Cc: [email protected], [email protected]
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
