Looks great @FeralChild64 , and I really like the naming harmonization - now very can directly mentally match the concepts between source files 👍

Added a commit to main to print the log on setup failure, when you have a chance to rebase.

The log revealed the issue:

2023-01-31T19:53:34.1755880Z Initialized empty Git repository in /home/runner/work/dosbox-staging/dosbox-staging/subprojects/gvdb/.git/
2023-01-31T19:53:34.9622053Z fatal: unable to access 'https://gitlab.gnome.org/GNOME/gvdb.git/': The requested URL returned error: 503

Literally every time we've had dependency fetch failures, it's because Gnome's gitlab server is failing and the guy who maintains it needs to reboot it.

(Reflecting on using GitHub: It's sure nice having this stress off our shoulders, knowing that paid staff are taking care of our infrastructure!)

@kcgen There is still some dependency error:

WARNING: Variable '-libpcre2_8' in the subproject 'subprojects/pcre2-10.40' is not found
Dependency libpcre2-8 from subproject subprojects/pcre2-10.40 found: NO
Dependency libpcre2-8 from subproject subprojects/pcre2-10.40 found: YES 10.40
Using subprojects/glib-2.74.1/subprojects/gvdb.wrap
Message: You can disable this dependency with: -Duse_slirp=false

subprojects/glib-2.74.1/meson.build:2089:0: ERROR: Git command failed: ['/usr/bin/git', 'fetch', '--depth', '1', 'origin', '0854af0fdb6d527a8d1999835ac2c5059976c210']
Error: Process completed with exit code 1.

@kcgen There is still some dependency error:

WARNING: Variable '-libpcre2_8' in the subproject 'subprojects/pcre2-10.40' is not found
Dependency libpcre2-8 from subproject subprojects/pcre2-10.40 found: NO
Dependency libpcre2-8 from subproject subprojects/pcre2-10.40 found: YES 10.40
Using subprojects/glib-2.74.1/subprojects/gvdb.wrap
Message: You can disable this dependency with: -Duse_slirp=false

subprojects/glib-2.74.1/meson.build:2089:0: ERROR: Git command failed: ['/usr/bin/git', 'fetch', '--depth', '1', 'origin', '0854af0fdb6d527a8d1999835ac2c5059976c210']
Error: Process completed with exit code 1.

Yes, it's stemming from gvdb.

In the failing Linux release workflow, click the gear icon and select 'view raw log', which is the full stdout and stderr.

Search it for 'gvdb', and you'll see git getting a 503 failure fetching it from gitlab's repo.

Then if you go back to the last successful main Linux release workflow, gvdb is fetched and compiled without issue.

Slirp depends on glib which depends on gvdb. For the Linux release, we build all of these statistically and optimized from sources (compared to non-release workflows where shared libs are used from the Linux distro).

I'll go poke around in gnome's gitlab and see if I can learn more.

https://gitlab.gnome.org/GNOME/gvdb

I can't even connect to the web front 😢

Edit: their whole site is kaputnik.

https://gitlab.gnome.org/

@kcgen, @johnnovak: I have found a regression: with seamless mouse enabled, the internal mouse cursor does not move any more if DOSBox window loses focus. This is not a desirable behavior, I need to fix it.

PR converted to draft for now.

Gnome's server is back online.

Added a ticket here: https://gitlab.gnome.org/GNOME/glib/-/issues/2906

@kcgen, @johnnovak: Regression fixed - ready for review again.