Your message dated Mon, 15 Dec 2025 20:29:43 +0100
with message-id <[email protected]>
and subject line Re: Bug#1121569: Recursive FTBFS report regrading multiple
packages in trixie
has caused the Debian Bug report #1121569,
regarding Recursive FTBFS report regrading multiple packages in trixie
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1121569: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121569
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Hi Miao,
On 12/2/25 09:17, Miao Wang wrote:
2025年12月2日 05:46，Sebastian Ramacher <[email protected]> 写道：
What is the input you are seeking from the release team?
I'd like to draw the release team's attention on the mentioned packages which
may change their behavior or break if rebuilt or upgraded, and remind the
release
team about more udiscovered packages in the current stable repo which might also
have the same issue.
I'm still a bit surprised that you filed the bug against the
release.debian.org pseudo package and not against the packages that have
the issues. This bug report isn't very actionable for us as normally
we're not the ones fixing individual packages. While I think the issues
you uncovered are real issues, I'm also not sure how much effort it's
worth to fix these in stable. Personally I see more value in preventing
them from happening in the future. Do you have ideas on how to achieve
that (assuming it's work or a service that someone like you would need
to provide)?
If you want to pursue your endeavor with the issues in the current
stable, I think the best course of action is to file bug reports against
the individual packages (with the right version information, such that
it clear when the issue only affects stable), taking the advice from the
dev-ref about mass bug filing [1] into account if you have discovered
more cases. Whether their maintainers are interested to update their
package for these issues in a stable release is to be discussed with them.
Paul
[1]
https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#reporting-lots-of-bugs-at-once-mass-bug-filing
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
