The diff I've shown before is a result of the build on a clean trixie machine.
You show the diff in rust-glib, that is not the problem I pointed out.
To be completely clear:
1) Package rust-gobject-sys/testing when built with `dpkg-buildpackage
-us -uc` produces a diff
for an old feature in an autogenerated file
/usr/share/cargo/registry/gobject-sys-0.20.9/src/lib.rs.
2) Package rust-glib/testing has its own gobject bindings that are
supposed to be autogenerated, but aren't.
This leads to an incompatibility when
`librust-gobject-sys-dev_0.20.9-1_amd64.deb` built in 1) is installed
and
`dpkg-buildpackage -us -uc` is run for rust-glib/testing.
The packages' purpose is to provide those autogenerated bindings.
The files in question can be regenerated by debian/rules when the
package is built, but in 1) that is configured
but didn't happen, and in 2) it is not fully configured, hence my
original patch.
On Wed, May 21, 2025 at 6:16 PM 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..
Yes, they are regenerated by that `gir` command in debian/rules.
I don't know what is the expected state of packages here, or
how did the feature guard not appear despite the version referenced (v2_68)
being pretty old. I would expect a rebuild.
> 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).
The diff you show below is in the other package. librust-gobject-sys-dev
shows v2_68 as a guard for G_SIGNAL_ACCUMULATOR_FIRST_RUN.
> I suspect uploads of glib2.0 should include pro-active test-rebuilds of those
> language specific bindings? or maybe a custom autopkgtest triggered
> accordingly? or build.rs patched to regenerate at rust-build time?
>
> FWIW, rust-glib still builds for me, with a small diff compared to the archive
> as well though:
With librust-gobject-sys-dev that you've just built installed?
> --- librust-glib-dev_0.20.9-1_amd64.deb
> +++ stock/librust-glib-dev_0.20.9-1_amd64.deb
> ├── file list
> │ @@ -1,3 +1,3 @@
> │ -rw-r--r-- 0 0 0 4 2025-02-16 21:36:29.000000
> debian-binary
> │ --rw-r--r-- 0 0 0 4932 2025-02-16 21:36:29.000000
> control.tar.xz
> │ --rw-r--r-- 0 0 0 210092 2025-02-16 21:36:29.000000
> data.tar.xz
> │ +-rw-r--r-- 0 0 0 4936 2025-02-16 21:36:29.000000
> control.tar.xz
> │ +-rw-r--r-- 0 0 0 210060 2025-02-16 21:36:29.000000
> data.tar.xz
> ├── control.tar.xz
> │ ├── control.tar
> │ │ ├── ./md5sums
> │ │ │ ├── ./md5sums
> │ │ │ │┄ Files differ
> ├── data.tar.xz
> │ ├── data.tar
> │ │ ├── file list
> │ │ │ @@ -23,15 +23,15 @@
> │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/
> │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/
> │ │ │ -rw-r--r-- 0 root (0) root (0) 285 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/alias.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 1364 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/checksum.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 6503 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/constants.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 16265 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/date_time.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 91249 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/enums.rs
> │ │ │ --rw-r--r-- 0 root (0) root (0) 22859 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/flags.rs
> │ │ │ +-rw-r--r-- 0 root (0) root (0) 22654 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/flags.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 25453 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/functions.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 12304 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/key_file.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 5676 2025-02-16
> 21:36:29.000000
> ./usr/share/cargo/registry/glib-0.20.9/src/auto/main_context.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 1506 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/main_loop.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 3279 2025-02-16
> 21:36:29.000000
> ./usr/share/cargo/registry/glib-0.20.9/src/auto/markup_parse_context.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 4575 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/mod.rs
> │ │ │ -rw-r--r-- 0 root (0) root (0) 2974 2025-02-16
> 21:36:29.000000 ./usr/share/cargo/registry/glib-0.20.9/src/auto/regex.rs
> │ │ ├── ./usr/share/cargo/registry/glib-0.20.9/src/auto/flags.rs
> │ │ │ @@ -335,18 +335,14 @@
> │ │ │ const NO_ARG = ffi::G_OPTION_FLAG_NO_ARG as _;
> │ │ │ #[doc(alias = "G_OPTION_FLAG_FILENAME")]
> │ │ │ const FILENAME = ffi::G_OPTION_FLAG_FILENAME as _;
> │ │ │ #[doc(alias = "G_OPTION_FLAG_OPTIONAL_ARG")]
> │ │ │ const OPTIONAL_ARG = ffi::G_OPTION_FLAG_OPTIONAL_ARG as _;
> │ │ │ #[doc(alias = "G_OPTION_FLAG_NOALIAS")]
> │ │ │ const NOALIAS = ffi::G_OPTION_FLAG_NOALIAS as _;
> │ │ │ - #[cfg(feature = "v2_84")]
> │ │ │ - #[cfg_attr(docsrs, doc(cfg(feature = "v2_84")))]
> │ │ │ - #[doc(alias = "G_OPTION_FLAG_DEPRECATED")]
> │ │ │ - const DEPRECATED = ffi::G_OPTION_FLAG_DEPRECATED as _;
> │ │ │ }
> │ │ │ }
> │ │ │
> │ │ │ #[doc(hidden)]
> │ │ │ impl IntoGlib for OptionFlags {
> │ │ │ type GlibType = ffi::GOptionFlags;
>
> with or without nocheck ;) did you maybe rebuild other packages
> as well that sit inbetween, and only that combination would then
> expose the problem?
This is a clean installation. I do not possess a pristine trixie, so I
took a Debian 12 image
and upgraded it to Trixie. For this excercise that should be enough.
After the upgrade I
1) Installed build deps: sudo apt build-dep rust-glib/testing
rust-gobject-sys/testing
2) Downloaded the sources: apt source rust-glib/testing rust-gobject-sys/testing
3) Ran the most bare bones package build of rust-gobject-sys:
dpkg-buildpackage rust-gobject-sys-0.20.9
4) Installed the package I've just built: sudo dpkg -i
librust-gobject-sys-dev_0.20.9-1_amd64.deb
5) Ran the most bare bones package build of rust-glib:
dpkg-buildpackage rust-glib-0.20
The last build failed with at the same step as in my original message.
The reason it fails is that librust-gobject-sys-dev has
G_SIGNAL_ACCUMULATOR_FIRST_RUN
hidden behind v2_68, and rust-glib uses that flag without the guard.
That guard would have been present there
if we'd regenerated the bindings from Gir_GObject.toml in rust-glib
the same way we already
regenerate them from GLib-2.0.gir in debian/rules.
I *think* the problem may have appeared because the generator got updated
(https://salsa.debian.org/gnome-team/gir-rust-code-generator/-/blob/debian/latest/src/version.rs?ref_type=heads).
Regardless of the long-term solution for these packages to be
rebuildable, I think
a rebuild of rust-gobject-sys and my patch to rust-glib (and similar patches to
everything using gir-rust-code-generator) are warranted.
> > $ diff
> > /tmp/gobject/usr/share/cargo/registry/gobject-sys-0.20.9/src/lib.rs
> > /usr/share/cargo/registry/gobject-sys-0.20.9/src/lib.rs
> > 111,112d110
> > < #[cfg(feature = "v2_68")]
> > < #[cfg_attr(docsrs, doc(cfg(feature = "v2_68")))]
> > 1504,1506d1501
> > < #[cfg(feature = "v2_84")]
> > < #[cfg_attr(docsrs, doc(cfg(feature = "v2_84")))]
> > < pub fn g_type_class_get(type_: GType) -> gpointer;
> > 1942,1944d1936
> > < #[cfg(feature = "v2_84")]
> > < #[cfg_attr(docsrs, doc(cfg(feature = "v2_84")))]
> > < pub fn g_type_default_interface_get(g_type: GType) -> gpointer;
> >
> > So to reproduce the failure I am talking about you'd have to get a
> > machine on trixie, build rust-gobject-sys, and then build rust-glib
> > forcing it to use the just built librust-gobject-sys-dev.
> >
> > On Sat, May 10, 2025 at 3:19 PM Matthias Geiger <werdah...@riseup.net>
> > wrote:
> >> Control: tags -1 moreinfo
> >>
> >> On Fri, 9 May 2025 14:10:36 +0200 Andrey Feofilaktov
> >> <andarpo...@gmail.com> wrote:
> >> > Package: rust-glib
> >> > Version: 0.20.9-1
> >> >
> >> > rust-glib seems to have outdated/malformed gobject bindings and fails to
> >> > build:
> >> >
> >> > error[E0425]: cannot find value `G_SIGNAL_ACCUMULATOR_FIRST_RUN` in crate
> >> > `crate::gobject_ffi`
> >> > --> src/gobject/auto/flags.rs:119:59
> >> > |
> >> > 119 | const ACCUMULATOR_FIRST_RUN =
> >> > crate::gobject_ffi::G_SIGNAL_ACCUMULATOR_FIRST_RUN as _;
> >> > |
> >> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `crate::gobject_ffi`
> >> > |
> >> > note: found an item that was configured out
> >> > --> /usr/share/cargo/registry/gobject-sys-0.20.9/src/lib.rs:113:11
> >> > |
> >> > 113 | pub const G_SIGNAL_ACCUMULATOR_FIRST_RUN: GSignalFlags = 131072;
> >> > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> > note: the item is gated behind the `v2_68` feature
> >> > --> /usr/share/cargo/registry/gobject-sys-0.20.9/src/lib.rs:111:7
> >> > |
> >> > 111 | #[cfg(feature = "v2_68")]
> >> > | ^^^^^^^^^^^^^^^^^
> >> >
> >> > I can fix this by updating debian/rules to also run gir for
> >> > Gir_GObject.toml (the same way it does for the sys bindings in
> >> > rust-gobject-sys):
> >> >
> >> > Index: rust-glib-0.20.9-1/debian/rules
> >> > ===================================================================
> >> > --- rust-glib-0.20.9-1.orig/debian/rules
> >> > +++ rust-glib-0.20.9-1/debian/rules
> >> > @@ -6,6 +6,7 @@
> >> > # regenerating the source code
> >> > # the xmlstarlet fixes are taken from upstream here:
> >> > https://github.com/gtk-rs/gir-files/blob/master/fix.sh
> >> > execute_before_dh_auto_build:
> >> > + cp /usr/share/gir-1.0/GObject-2.0.gir $(CURDIR)
> >> > cp /usr/share/gir-1.0/GLib-2.0.gir $(CURDIR)
> >> > xmlstarlet ed -L \
> >> > -u
> >> > '//*[@glib:error-domain="g-option-context-error-quark"]/@glib:error-domain'
> >> > -v g-option-error-quark \
> >> > @@ -15,9 +16,20 @@ execute_before_dh_auto_build:
> >> > -u
> >> > '//_:record[@name="KeyFile"]/_:method[@name="set_locale_string_list"]//_:parameter[@name="list"]/_:array/@c:type'
> >> > -v "const gchar* const*" \
> >> > -u
> >> > '//_:record[@name="KeyFile"]/_:method[@name="set_string_list"]//_:parameter[@name="list"]/_:array/@c:type'
> >> > -v "const gchar* const*" \
> >> > GLib-2.0.gir
> >> > - sed -i
> >> > 's/girs_directories\s=\s\[\"\.\.\/gir-files\"\]/girs_directories=\[\".\"\]/'
> >> > $(CURDIR)/Gir.toml
> >> > + xmlstarlet ed -L \
> >> > + -u
> >> > '//_:class[@name="Object"]/_:method[@name="getv"]//_:parameter[@name="names"]/_:array/@c:type'
> >> > -v "const gchar**" \
> >> >
> >> Hi Andrey,
> >>
> >> thanks for the bug report and the patch. For me simply building
> >> rust-glib works (with both !nocheck and without) (though I skipped
> >> autopkgtest). Can you mabe share a full buildlog so we can compare notes
> >> ?
> >>
> >> best,
> >>
> >> werdahias
> >
> >
> > --
> > Regards,
> > Andrey
> > _______________________________________________
> > Pkg-rust-maintainers mailing list
> > pkg-rust-maintain...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
--
Regards,
Andrey
