Control: tags -1 moreinfo Hi Miao
On 2025-11-29 03:47:25 +0800, Miao Wang wrote: > 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. What is the input you are seeking from the release team? Cheers -- Sebastian Ramacher
