Cant install on arch

[gavr123456789]

Full log: https://pastebin.com/r3ARC82Z

It just stops on the line (process:10775): GLib-CRITICAL **: 14:59:28.012: g_once_init_leave: assertion 'result != 0' failed

[gavr123456789]

Also trace stack after pressing ctrl c

(process:10775): GLib-GObject-CRITICAL **: 14:59:28.011: g_type_register_static: assertion 'parent_type > 0' failed

(process:10775): GLib-GObject-WARNING **: 14:59:28.011: cannot add private field to invalid (non-instantiatable) type '<invalid>'

(process:10775): GLib-CRITICAL **: 14:59:28.012: g_once_init_leave: assertion 'result != 0' failed

^CTraceback (most recent call last)
/tmp/gintrosalewski/gen.nim(4452) gen
/tmp/gintrosalewski/gen.nim(4406) launch
/tmp/gintrosalewski/gen.nim(3940) main
SIGINT: Interrupted by Ctrl-C.
stack trace: (most recent call last)
/tmp/nimblecache-4098377420/nimscriptapi_2282383482.nim(199, 29)
/tmp/nimble_10620/githubcom_stefansalewskigintro/gintro.nimble(77, 7) installBefore
/tmp/nimble_10620/githubcom_stefansalewskigintro/gintro.nimble(64, 7) prep
/usr/lib/nim/system/nimscript.nim(260, 7) exec
/usr/lib/nim/system/nimscript.nim(260, 7) Error: unhandled exception: FAILED: /tmp/gintrosalewski/gen 1 [OSError]
       Tip: 4 messages have been suppressed, use --verbose to show them.
     Error: Exception raised during nimble script execution
gavr@arch ~/P/Elm [1]> 

[gavr123456789]

I see here version 5, but there 4.0 in package manager

For package webkit2gtk 2.32.4-1. Maybe that's the point

[StefanSalewski]

Cant install on arch

Is this ARM 64 bit system (called aarch64)?

Please note that generally only fools posts images when a plain textual error message is sufficient. Real morons even posts full videos.

I will investigate this issue, but it has currently not a very high priority.

[gavr123456789]

@StefanSalewski No, its my usual arch linux distro.
Davide sent me this error in telegram chat, then I tried reinstalling gintro and now I get the same error.
So now I cant use gintro too.

[StefanSalewski]

So it is a new error on your own computer? It was my feeling that you tried to install on a device like Raspberry Pi!

Is this a v0.9.5 issue? Can you still install older gintro? I think command should be

nimble uninstall gintro
nimble install gintro@#v0.9.4

Well I am not sure, never tried to install old versions.

Have you recently updated your GTK install? Or updated Nim or nimble? So what has changed?

Have to watch "Auslandsreport" on German NTV now, may come back later. Bye.

[gavr123456789]

Is this a v0.9.5 issue? Can you still install older gintro?

arr, same with all older gintro versions, so it might be GTK, I updated my packages recently. Looks like something with SoupAuth, maybe

[gavr123456789]

Now I have 3 GIR files with name Soup in it in /usr/share/gir-1.0:
Soup-2.4.gir, Soup-3.0.gir, SoupGNOME-2.4.gir
Maybe one of them was added after the update and therefore it gives an error:
GLib-GObject-WARNING **: 19:36:40.219: cannot register existing type 'SoupAuth'

[StefanSalewski]

Yes, that may be the problem. I have only Soup-2.4.gir currently, and 3.0 seems not yet available as gentoo package, see https://packages.gentoo.org/packages/net-libs/libsoup

I will try to install libsoup from git sources in the next days and see if I can reproduce the issue. I guess it is not a real gintro problem but gobject-introspection related. GTK has not many GIR users, so unfortunately often we few gintro users are the first who discover such bugs.

[StefanSalewski]

But well, I may have an idea: libsoup 3.0 may be related to GTK4 only, in that case we may have to specify a version, 2.0 maybe, for GTK3 install. WE do that already for a few modules. Will investigate that soon.

[StefanSalewski]

You may have seen this thread in the GTK forum:

https://discourse.gnome.org/t/some-libsoup-3-issue/7807/3

So all that is not easy.

Yesterday I failed installing libsoup 3 from git sources on my Gentoo box, I will try again later.

Maybe you have already some basic Nim and Nimble knowledge, so you may be able to split the gintro install phase into a download and a run phase? In that case you could try to modify the gen.nim script to fix it.

I am doing such experiments not with nimble, but have prepared a special directory on my box, where I manually added some needed files from the oldgtk3 package, which are temporary needed to compile gen.nim. So I modify, compile and run gen.nim in that directory, and copy the generated files to ~/.nimble/pkgs/gintro-#v0.9.5/gintro

That is how I do it for many years now, but maybe at some time in future I will try to learn more about nimble.

Another person does some gintro development recently by temporary forking gintro. Then he modified the gen.nim script in his fork, and tries to install his fork. That way he was able to find a fix for his very old Debian Buster install. We then included that fix in recent version v0.9.5

[gavr123456789]

@StefanSalewski Fixed with change versions of WebKit2 JavaScriptCore and WebKit2WebExtension to correct ones.
Apparently, there are no versions 5.0 of this gir packages: https://valadoc.org/index.htm and also the second screen in my third message.
Now gintro builds successfully, yay:

...
We continue with the remaining packages...
  Verifying dependencies for gintro@0.9.5
 Installing gintro@0.9.5
   Success: gintro installed successfully.

[StefanSalewski]

Fine that you get it working for you, but that is not a general fix, as most people want to use the versions 5.0 of course.

I still are not able to install libsoup 3, see https://discourse.gnome.org/t/can-not-compile-libsoup-3-from-git-sources/7809/4

so I can not test it. Maybe we should remove webkit and libsoup fully? I have the feeling that no one really needs that.

[gavr123456789]

as most people want to use the versions 5.0 of course

As I understand WebKit for GTK 4 is not released yet. The only way to do that is manually build it with -DUSE_GTK4=ON flag, only then gir version 5.0 will appears.
I think we can disable webkit 5 build for gtk 4 until it officially released.
Also Im thinking about generate nim bindings for all gir files after scan gir directory.
Of course, there must be a mechanism that will allow the generation not to fall entirely if the generation of only one GIR file has fallen (as happened now). It can be generated one binding per process(per unit test?), so that if it fails, then the next one will start.

[StefanSalewski]

I was finally able to install libsoup3 from git sources and can now reproduce your issue.

I think fully disabling webkitgtk support for GTK4 is not a very good solution. I got webkitgtk with GTK4 to work in late 2020 already, and some Rust people seem to use this combination as well. Linux distributions may not yet ship it, as there are some NVidia issues. But later they will. I will investigate the issue in the next days.

[StefanSalewski]

Have you followed the discussion on the GTK forum? The real issue seems to be that libnice internally uses libsoup2.4 still, and so gobject-introspection uses that libsoup somehow. Then later, when gobject-introspection shall process libsoup3 we get the crash. We can fix that for now, but what when later libnice switches to libsoup3?

[gavr123456789]

when gobject-introspection shall process libsoup3 we get the crash

I don't quite understand why crush happens, because there is no linking during the process of creating bindings. The solution may be to divide the generation into 2 unit tests, 1 for GTK3 and the second for GTK 4, then they will run in different processes and this conflict will not arise, if I understand right what problem is.

[StefanSalewski]

We have currently already 2 separate processes, one for the GTK3 related libs, and one for the GTK4 libs. Currently all seems to be fine when we generate libsoup2.4 and libnice together in the GTK3 process. What worries me a bit is what will happen when libnice switch to libsoup3. As noted in the forum thread, a really clean solution would be to start a new process for each single lib creation. For current libnice it works also, when we just process libsoup before libnice, then libsoup version seems not to matter.

[gavr123456789]

really clean solution would be to start a new process for each single lib creation

Yes, I totally agree, this is also what I proposed in this thread 2 days ago.

allow the generation not to fall entirely if the generation of only one GIR file has fallen (as happened now). It can be generated one binding per process(per unit test?), so that if it fails, then the next one will start.

It will also be safer if only the generation of one of the GIR files fails, the user will still get bindings for the rest, unlike the current situation when I and DavideGalillei(who investigate this bug) can't get GTK bindings at all because of one fails.

[StefanSalewski]

You may try the fix with

nimble uninstall gintro nimble install gintro@#head

Fix is

$ diff ~/gintrotest/tests/gen.nim gen.nim 
3c3
< # v 0.9.6 2021-OCT-20
---
> # v 0.9.5 2021-OCT-01
403,404d402
<   if not ISGTK3 and (s == "libsoup"):
<     result &= "3"
4293,4298d4290
<   if namespace == "Soup":
<     if version == "2.4":
<       suff = ""
<     if version == "3.0":
<       suff = "3"
< 
4356d4347
<     main("Soup", "2.4") # process Soup before Nice, preventing the load of not matching libsoup version
4361c4352
<     #main("Soup", "2.4")
---
>     main("Soup")
4411,4412c4402
<     main("Soup", "3.0") # process Soup before Nice, preventing the load of not matching libsoup version
<     main("Nice") # https://discourse.gnome.org/t/some-libsoup-3-issue/7807/14 
---
>     main("Nice")
4416c4406
<     #main("Soup", "3.0")
---
>     main("Soup")
4477c4467
< # 4477 lines
---
> # 4467 lines

The trick is, that we process libsoup before libnice. And we create an additional module libsoup3 now. Indeed we have to process libnice in the GTK3 process as well as in the GTK4 process, as we do for all the other common modules. We need that to populate the gisup files, I initially forgot about that.

I was also able to install webkitgtk for GTK4, and to test gintro generating the bindings. But even a plain C test program does not work currently for GTK4 with webkit, we get a message of an internal webkit issue. But that is no gintro problem.

[StefanSalewski]

Fix is shipped as v0.9.6 now!

[gavr123456789]

Fix working, thanks!