On Wed, 21 May 2025 18:15, Fabian Grünbichler
<debian@fabian.gruenbichler.email> wrote:
On Wed, May 21, 2025, at 5:43 PM, Andrey Feofilaktov wrote:
Hey Matthias,
I tried to reproduce it, and it is true that on a raw trixie it is not
reproducible as is.
However, it would be if librust-gobject-sys-dev would have been built
from source that is uploaded. That does not seem to be the case.
If I build it from source manually, the resulting package would contain
a different src/lib.rs file (with the expected feature guards present):
if I do
apt source rust-gobject-sys/testing
apt source rust-glib/testing
and build both (injecting librust-gobject-sys-dev into the rust-glib build)
for testing, the built librust-gobject-sys-dev package differs from the one
in the archive. I guess src/lib.rs is rebuilt as part of the build of the
package, but not as part of just building a reverse-dep, since that rebuilding
is not part of build.rs, but in d/rules..
and sure enough, there have been uploads of glib2.0 (where the gir binaries
responsible for generating are from) since the last upload of
librust-gobject-sys-dev, including an update from .83 to .84 that would
match the diff below (which is identical to the one I see).
iirc autopkgtests for the -sys packages get triggered already for new
glib uploads (or gtk4, for that matter).
FWIW, rust-glib still builds for me, with a small diff compared to the
archive
as well though:
[...]
with or without nocheck ;) did you maybe rebuild other packages
as well that sit inbetween, and only that combination would then
expose the problem?
(CC'd glib uploaders) Do we some mechanism in place that could rebuild
the rust-gtk stack for such things ? It only gets rebuilt by binNMUs now
for outdated built-using and new revisions, of course.
I agree that it'd be good to catch minor changes like this.
Unfortunately it's caused issues in the past when the upstream source
didn't match the re-generated one, leading to breakage.
best,
werdahias
