macOS 14.4.1 problem with 'gi.repository.Gio' object has no attribute 'content_type_get_icon'

[vonProteus]

i have installed deluge (2.1.1) via pip long time ago
after updating macOS from 14.4.0 to 14.4.1 it stops working (i'm on apple silicon m2)
before update i run it from terminal via

Code: Select all

deluge

and got gui app
now i when i launch it i get

Code: Select all

$ deluge
11:50:50 [ERROR   ][deluge.ui.gtk3                    :52  ] 'gi.repository.Gio' object has no attribute 'content_type_get_icon'
Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/ui/gtk3/__init__.py", line 49, in run
    gtkui = GtkUI(options)
            ^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/ui/gtk3/gtkui.py", line 200, in __init__
    self.torrentdetails = TorrentDetails()
                          ^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/ui/gtk3/torrentdetails.py", line 124, in __init__
    from .files_tab import FilesTab
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/ui/gtk3/files_tab.py", line 47, in <module>
    G_ICON_DIRECTORY = Gio.content_type_get_icon('inode/directory')
                       ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/gi/overrides/__init__.py", line 32, in __getattr__
    return getattr(self._introspection_module, name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/gi/module.py", line 126, in __getattr__
    raise AttributeError("%r object has no attribute %r" % (
AttributeError: 'gi.repository.Gio' object has no attribute 'content_type_get_icon'
Traceback (most recent call last):
  File "/opt/homebrew/bin/deluge", line 8, in <module>
    sys.exit(start_ui())
             ^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/ui/ui_entry.py", line 140, in start_ui
    ui.start()
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/ui/gtk3/__init__.py", line 55, in start
    deluge.common.run_profiled(
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/common.py", line 1355, in run_profiled
    return func(*args)
           ^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/ui/gtk3/__init__.py", line 49, in run
    gtkui = GtkUI(options)
            ^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/ui/gtk3/gtkui.py", line 200, in __init__
    self.torrentdetails = TorrentDetails()
                          ^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/ui/gtk3/torrentdetails.py", line 124, in __init__
    from .files_tab import FilesTab
  File "/opt/homebrew/lib/python3.11/site-packages/deluge/ui/gtk3/files_tab.py", line 47, in <module>
    G_ICON_DIRECTORY = Gio.content_type_get_icon('inode/directory')
                       ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/gi/overrides/__init__.py", line 32, in __getattr__
    return getattr(self._introspection_module, name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/lib/python3.11/site-packages/gi/module.py", line 126, in __getattr__
    raise AttributeError("%r object has no attribute %r" % (
AttributeError: 'gi.repository.Gio' object has no attribute 'content_type_get_icon'

i tried to install it in venv but the error is the same (other paths but the same)

any help would be greatly appreciated

[ilikepeaches]

I have the exact same issue & error on Ventura 13.6.6 (22G630), but Deluge ran fine for me for a couple of days after the most recent 13.6.6 update. I think the issue instead may have been triggered by a Homebrew update that I did on Friday, March 29.

These instructions (through "Install Deluge") should work. They have in the past!
viewtopic.php?t=56287

I''m now on Python 3.12.2 and once before had to do a dance of re-building Deluge under 3.10 to get it working again after a Homebrew update ... but that 3.10 dance, virtual environments, and everything else I've tried today all got me nowhere this time.

[ilikepeaches]

Ok. I fixed my Deluge 2.1.1 command line by rolling back to an APFS snapshot from twenty minutes before I ran Homebrew updates yesterday.

I'll follow up once I investigate further, but I suspect the gobject-introspection update from 1.78.1 to 1.80 caused the issue.

-------

Update: yep, that's the cause of the issue.

Code: Select all

brew outdated

will tell you what packages Homebrew plans to update when you run it fully.

If you have gobject-introspection 1.78.1 do

Code: Select all

brew pin gobject-introspection

immediately to stop it from updating to 1.80.

Unfortunately, pinning gobject-introspection will prevent Homebrew from applying updates to other packages which require the most updated version of their dependencies. e.g. harfbuzz and ffmpeg now don't want to update for me.

If you're already in the situation I was in and can roll back your entire system to where it was before the relevant Homebrew update, like I did, I recommend you do that. I tried at length to manually undo the 1.78.1 → 1.80 update but did not succeed. Homebrew and Python seem too intertwined to respond to the kinds of interventions I thought to attempt. Maybe others would have better luck?

Probably this is the change in gobject-introspection that's breaking our Deluge:

1.80.0 - 2024-03-09
• Only allow loading GIRepository-2.0

https://gi.readthedocs.io/en/latest/changelog.html

I wonder whether the Deluge devs might be able to adjust the Deluge code to play nice with that change, or perhaps they could share feedback about its consequences with the maintainers of gobject-introspection?

[amar1729]

I run a brew tap for deluge where we just ran into the same problem. https://github.com/Amar1729/homebrew-de ... /issues/23

I'm not sure if this is because of that GiRepository change, or because of an issue where the gobject-introspection metadata isn't used as of 1.80 (see this issue comment in homebrew/homebrew-core https://github.com/Homebrew/homebrew-co ... 2027718285).

Note that in the meantime, if you don't have an easy way to rollback (like me) it's very difficult to resolve by extracting+building 1.78 formula yourself, since due to a different issue you might not be able to build gobject-introspection from source https://github.com/Homebrew/homebrew-core/issues/165388

[ambipro]

@ilikepeaches and I were troubleshooting this and trying to manually revert version 1.80 to 1.78.1 before they posted their update and had many problems doing so.

Reverting the entire time machine before updating seemed to possibly fix it, however, I'm not sure if this is a sustainable solution, or what a remedy would be for anyone without backups.

I was told downgrading with brew is next to impossible otherwise.

I've got a few PM's out but I'm not particularly optimistic that this is something that will be easily solved and caution everyone to always maintain backups for situations like this.

[amar1729]

In the past, i've gone into the homebrew/homebrew-core tap within brew --prefix, manually (with git) checked out a previous commit, and installed from there ... however, that's really only feasible for leaf formulae. Anything really interconnected, like gobject-introspection/glib, is horrific because this approach would cause rebuilds/reinstalls of every rdep :/

[ambipro]

One idea I had that was just a thought was to use pipdeptree, but this is a rabbit hole and who knows what it would break if you reverted the entire deptree.

[vonProteus]

thanks for your help

i reverted and pined gobject-introspection to 1.78.1 from this commit
i had only one dependent formula which was pygobject3 so i uninstalled it and reinstalled it after downgrade

so basically this

i've gone into the homebrew/homebrew-core tap within brew --prefix, manually (with git) checked out a previous commit, and installed from there ...

everything seems to be fine now and working

do you think I will have problems in the future because of this?

and when can i unpin this gobject-introspection ?

thanks again for your help

[amar1729]

Nice, good to hear it works. The only problems you'll have in the future are that brew will raise a warning whenever anything that depends on gobject-introspection can't be updated because you have it pinned (which shouldn't be much, because you only had one dependent). You'll be able to unpin whenever the upstream issue is fixed, not really sure how long that'll take unfortunately.

[ambipro]

This seems like something that would require a github issue on brew's end. @amar1729 - you seem rather familiar with the project is this something you think you could do?

I'm not sure what other projects depend on this or would be affected, but given that there is no intuitive way to do this for many users, at the very least maybe some documentation or notes about pinning packages could be done on brew's site?