Fix CI: install libgirepository-2.0-dev required by newer PyGObject b…

[anhtumai]

…uilds

Please follow these steps before submitting a new Pull Request to Guake:

• rebase on latest HEAD:

  $ git pull --rebase upstream master

• hack your change

• to execute the code styling, checks and unit tests:

  $ make style check reno-lint test

• describe your change in a slug file for automatic release note
  generation, using:

  $ make reno SLUG=<short_name_of_my_feature>

  and edit the created file in releasenotes/notes/.
  You can see how reno works using pipenv run reno --help.

  Please use a generic slug (eg, for translation update,
  use translation, for bugfix use bugfix,...)

• create new commit message

  $ <hack the code>
  $ git commit --all

• If your change is related to a GitHub issue, you can add a reference
  using #123 where 123 is the ID of the issue.
  You can use closes #123 to have GitHub automatically close the issue
  when your contribution get merged

• Semantic commit is supported (and recommended). Add one of the following
  line in your commit messages:

  # For a bug fix, uses:
  sem-ver: bugfix
  
  # For a new feature, uses:
  sem-ver: feature
  
  # Please do not use the 'breaking change' syntax (`sem-ver: api-break`),
  # it is reserved for really big reworks
  

[anhtumai]

@Davidy22 this PR should unblock the CI pipeline: https://github.com/Guake/guake/actions/runs/28706200405/job/85132147751 , which fails with:

../meson.build:35:9: ERROR: Dependency 'girepository-2.0' is required but not found.

Can you run this pipeline to test: https://github.com/Guake/guake/actions/runs/30938832362

[Davidy22]

Man the code rot is real, immediately runs into another error, at least you made the libgi error disappear. Sorry about the slow response, been busy. Do you want to dig through all the CI rot and make that into one PR or leave the rest to someone else?

[anhtumai]

Since I cannot run the ci pipeline, I just throw out the fix and pray. I will find a way to simulate the CI environment and fix the next error

[anhtumai]

I want to fix it properly

[Davidy22]

You should just be able to enable it on your fork. Thanks for taking this on, been busy lately

[anhtumai]

Why these pins exist

setuptools_scm<9 (setup.cfg)
setup_requires still uses setuptools' legacy fetch_build_eggs mechanism to fetch build-time dependencies. That mechanism fetches a single egg but doesn't resolve that egg's own dependencies. Starting at setuptools_scm 9.0, the project split a chunk of its internals out into a separate package, vcs-versioning. An unpinned setuptools_scm resolves to the latest (10.x), pulls in the vcs-versioning requirement, fetch_build_eggs silently drops it, and the build crashes with ModuleNotFoundError: No module named 'vcs_versioning'. Pinning <9 keeps us on the last self-contained release.

pbr==7.0.3 (Pipfile)
pbr is a transitive dependency of reno (release-notes tooling), not something guake uses directly. pbr registers a global egg_info.writers setuptools entry point, so it gets loaded during any package's egg_info step in the environment — including guake's own sdist build, which has nothing to do with reno. pbr==6.1.0 still imports pkg_resources in pbr/git.py, but setuptools removed pkg_resources entirely as of ~80.x. So an unrelated dev dependency was silently breaking guake's own packaging step. pbr==7.0.3 dropped that import, fixing it.

pygobject<3.52 (.github/workflows/ci.yml, .github/workflows/release.yml)
pygobject 3.52 switched its introspection backend from girepository-1.0 to the new girepository-2.0 (part of GLib ≥2.80). The problem: gir1.2-keybinder-3.0 — the distro package for libkeybinder, guake's global-hotkey library — is unmaintained upstream (last release 2013) and its .typelib was built for the old girepository-1.0 loader. girepository-2.0 can't see it, so gi.require_version("Keybinder", "3.0") raises Namespace Keybinder not available. This only showed up on Python 3.9+ in CI because pip resolves pygobject to the newest version compatible with each interpreter, and 3.52+ requires Python ≥3.9 — the Python 3.8 CI job was accidentally protected because it's capped at 3.48.2. This is a stopgap, not a permanent fix: the real fix is dropping the Keybinder dependency, since it will never get a girepository-2.0-compatible typelib. That's follow-up work, not part of this PR.

libgirepository-2.0-dev / gobject-introspection / glib2-devel (bootstrap scripts)
Even pinned to <3.52, PyGObject's build probes for girepository-2.0.pc at compile time on some paths, so the dev headers need to be present to build the wheel at all — separate from the runtime typelib-loading issue above. Debian/Ubuntu ship this as its own package (libgirepository-2.0-dev, from the glib2.0 source); Fedora folds it into glib2-devel; Arch bundles both girepository versions into one gobject-introspection package (rolling release, no version-split packaging). Each bootstrap script needed the platform-appropriate equivalent.

[anhtumai]

@Davidy22 the action on my PR has succeeded with this pin: https://github.com/anhtumai/guake/actions/runs/31902412202/job/95055080045

Can you rerun the main job to check?

P/S: if possible, you can rerun pipenv lock on your machine to compare if my pipenv lock brings too different result

[Davidy22]

The run works again, so thank you for your contribution, I just noticed one thing that seems out of scope for this PR, and doesn't seem to be quite correct on its own merit.

On a side note I have been noticing an uptick in PRs lately, and the big hunk of text you dropped does look a bit like AI. Was there some article everyone read or something that I missed? I'm not gonna ban AI, but I'm still going to expect PRs to meet requirements and be correct

[Davidy22]

Why change this? Doesn't have anything to do with CI

[anhtumai]

this fails pylint test.

`no-else-return` check at terminal.py:366

So I need to change elif to if. Should be safe to do so.

[anhtumai]

about the big chunk of text above

Yes, I did rely on AI to search for information , and the right version of package to pin, but I still reviewed all the changes and regenerated lock file myself, so AI cannot halluciate incorrect hash.

I wanted to document why these pins fixed CI issues, but got a bit lazy to write it myself, so used AI to do so.

[anhtumai]

but yeah, I always reviewed the code , and mostly used AI for boring tasks like writing tests or documentation (but I also reviewed them afterward). I hope it is ok