• Re: GTK-rs code regeneration issues -- help wanted

    From =?UTF-8?Q?Jeremy_B=C3=ADcha?=@21:1/5 to werdahias@riseup.net on Tue Apr 30 16:10:01 2024
    On Tue, Apr 30, 2024 at 9:34 AM Matthias Geiger <werdahias@riseup.net> wrote:
    The gir files mentioned previously are just taken at a specific point in
    time and (sometimes) do not match the ones we have in unstable at that
    time. This used to work fine (more or less) since I started regenerating every affected source package that way. However, the current stack of bindings does not match the ones we have generated (partially because of time_t; fixed by upstream in the latest release). This leads to
    buildfailures [3] and possible memory corruption.

    Maybe part of our problem is that the gtk-rs related packages in
    Experimental are not being built against glib 2.80 /
    gobject-introspection 1.80. We could bump Build-Depends for it.

    Thank you,
    Jeremy Bícha

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthias Geiger@21:1/5 to All on Tue Apr 30 15:40:01 2024
    Hi all,

    I would appreciate some guidance with the best way forward regarding the
    code regeneration of GTK-rs in Debian.

    Some background information:


    GTK-rs provides rust bindings for the base (glib) and high-level (GTK4)
    C GTK libraries. These bindings are somewhat autogenerated.

    The rough process upstream is like this:

    "Random" gir files imported [0] -> codegenerator at a specific version
    [1] reads Gir.toml files -> automatically generates high- and low-level
    crates (e.g. gtk4-sys and gtk4). [2] -> published on crates.io from
    where we take the source code

    The gstreamer-* and other (libadwaita, libshumate) bindings are
    generated the same way.

    The gir files mentioned previously are just taken at a specific point in
    time and (sometimes) do not match the ones we have in unstable at that
    time. This used to work fine (more or less) since I started regenerating
    every affected source package that way. However, the current stack of
    bindings does not match the ones we have generated (partially because of time_t; fixed by upstream in the latest release). This leads to
    buildfailures [3] and possible memory corruption.


    I would appreciate some help with as to how we can ensure this does not
    happen.

    My thoughts so far:

    1. Ship upstreams gir-files.

    Advantages: Should fix all issues

    Disadvantages: Would need to pass NEW; those are autogenerated from C themselves; code duplication

    2. Adjust the current process so that "our" gir files are adjusted to
    match upstreams

    Advantages: no need for an extra package

    Disadvantages: A lot of work, need to check every gir file against
    upstreams somewhat and adjust accordingly

    Would need some degree of automation and a significant amount of work

    3. Do not regenerate: Not really an option; this would violate DFSG §2,
    see https://wiki.debian.org/AutoGeneratedFiles


    Given the above difficulties I would appreciate some ideas as how to
    best resolve this problem. Upstream release cycle is ~twice a year (+
    minor bugfix releases).

    Let me know if you have any questions wrt the regeneration process.


    [0] https://github.com/gtk-rs/gir-files/

    [1] this is not an issue itself; the package in Debian is called gir-rust-code-generator

    [2] I re-implemented upstreams process in d/rules, see for instance https://sources.debian.org/src/rust-libadwaita-sys/0.5.3-1/debian/rules/

    [3] https://buildd.debian.org/status/fetch.php?pkg=gnome-snapshot&arch=amd64&ver=46.2-3&stamp=1713724614&raw=0


    As GNOME is increasingly using gtk-rs to build their applications this
    will need resolving.


    best,


    --
    Matthias Geiger <werdahias>
    Debian Maintainer

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)