On Sat, 03 Jun 2023 at 23:39:29 +0200, Abou Al Montacir wrote: > I've added support for on the fly converting .typelib files using > g-ir-generate.
The normal workflow for GObject-Introspection is: C source code } } ---> GIR XML ---> binary typelib compiled binaries } | | | | v v static bindings dynamic bindings (Rust, C++, etc.) (Python, JavaScript, etc.) Decompiling the binary typelib to re-create the GIR XML is not something that is conventionally done, and until today I wasn't aware that gobject-introspection even had a tool that could do this - I had assumed that compiling the GIR XML into a binary typelib was a lossy transformation, similar to the way compiling C or Pascal code into object files is a lossy transformation. If you are writing a binding for Pascal (a compiled language analogous to C or Java), then I would expect it to read the GIR XML from the -dev package, for example libharfbuzz-dev, and generate Pascal source code from that. That's how bindings for other statically-compiled languages like Rust, C++, Java and Vala tend to work. The binary typelibs in gir1.2-* are usually only used by bindings into dynamic languages like Python (PyGI), JavaScript (gjs, seed) and Perl (Glib::Object::Introspection), as a faster and more disk-space-efficient way to generate bindings on-demand on end-user systems, without the space consumption of installing the XML and the -dev package, and the computational overhead of parsing it. > However, when starting the conversion, g-ir-generate crashes with an error on > HarfBuzz-0.0. > I've raised a ticket [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug= > 1035669 to that package, but I'm not sure it is an issue in HarfBuzz itself, > and maybe it is in g-ir-generate itself. I don't know whether this is a bug in harfbuzz or GObject-Introspection. >From the patch proposed, it looks like either: - a bug in g-ir-scanner (which is the component that parses C source code) for mis-parsing harfbuzz's header file; or - a bug in harfbuzz, for having GObject-Introspection bindings that include a header file, but then having content in that header file that a current version of g-ir-scanner will mis-parse Either way I don't think it's release-critical for either harfbuzz or gobject-introspection. > The reason I'm write to debian-devel is to know if we want to enforce the fact > that typelib files shall be able to regenerate gir files for Bookworm. > If this is the case, shall I raise severity to be release critical? No, this is not a release-critical bug. This looks to me like a bug of normal severity: the definition of normal severity used to mention "a problem with a particular option", and this looks like a problem with a particular constant in a particular header, which is conceptually similar. In particular, this is not a DFSG violation, because the compiled typelibs aren't source code, so there is certainly no particular requirement that we can reproduce other files from them. If we can load the compiled typelib into PyGI, gjs, etc., and the majority of it works as intended, then the gir1.2-* package is usable. smcv