Re: Can not recreate GIR information from gir1.2-harfbuzz-0.0.typelib

[Abou Al Montacir <abou.almontacir@sfr.fr>]

Hi Simon and All,

On Sun, 2023-06-04 at 15:24 +0100, Simon McVittie wrote:

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.

Yes makes sens.

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 reason I oriented myself to use .typelib files is that I was not sure how to get .gir files.

I could not find them and did not find packages that carry them.

If these are available, then I can make them build dependency of my bindings package and that is enough.

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.

Permit me to remark that it is strange that packages named gir* do not provide gir files.

This is really misleading for anyone who is not implicated in this logic.

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.

I was thinking that .typelib is lossless transformation and that Debian does not ship .gir files.

IF this logic is wrong, then I agree this is not RC, as long as interpreted languages can use it as intended.

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.

Just to note that on Bullseye, this issue does not exist.

But I agree with you on the above.

Thanks for taking the time to answer this question.

-- 

Cheers,
Abou Al Montacir

Attachment: signature.asc
Description: This is a digitally signed message part