Gnome-shell-extension-gsconnect: [SOLVED]: Nautilus (was) breaking nautilus-gsconnect.py in Fedora 29

[basilrabi]

In fedora 29, the extension runs fine with nautilus 3.30.2. However, the extension breaks nautilus 3.30.3. Nautilus crashes right after opening. The terminal command returns:

$ nautilus
sys:1: Warning: Two different plugins tried to register 'GSConnectShareExtension+NautilusPython'.
sys:1: Warning: g_type_add_interface_dynamic: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

[andyholmes]

Hey, good to see you're still around.

Could you please check if locate nautilus-gsconnect.py is listing extra installs of this, just to make sure? The original should be in the extension dir, with a soft-link to ~/.local/share/nautilus-python/extensions/nautilus-gsconnect.py.

If there aren't any extra soft-links or copies anywhere, I may have to as csoriano (Nautilus dev) what's up, or dig into the Nautilus source a bit because I don't know what might have changed to affect this.

EDIT if this is stopping you from using Nautilus, you should be able to replace that soft-link with an empty file or something to prevent GSConnect from automatically replacing it with a new one.

[basilrabi]

Only two files are returned: the original and the soft-link.

$ locate nautilus-gsconnect.py
/home/brabi/.local/share/gnome-shell/extensions/[email protected]/nautilus-gsconnect.py
/home/brabi/.local/share/nautilus-python/extensions/nautilus-gsconnect.py

Replacing the soft-link with an empty file fixes the crash. Thank you!

[andyholmes]

Hmm, I've had a look at the changes between 3.30.2-3.30.3 (loading will take awhile), but there don't seem to be any related changes. nautilus-python seems to be mostly done, which makes sense since I think they're planning on a new approach to extensions/plugins.

I've been reminded a couple times by Fedora users that they ship _python2_-nautilus as a dependency for this, while many others have a less explicit python-nautilus/nautilus-python package.

Python2-3 is not a big deal for these extensions, but it makes me wonder if there are now two packages being shipped with Fedora 29? Could you have a look and see if there are now two versions installed on your system that are both trying to load nautilus-gsconnect.py?

[basilrabi]

Fedora 29 has 2 versions, python2-nautilus and python3-nautilus but only python2-nautilus-1.2.1-4 is installed in my system. I tried downgrading to python2-nautilus-1.2.1-3 and the crash is also fixed. Maybe this change is related to the crash?

The crash is only reproducible if nautilus-3.30.3 is paired with python2-nautilus-1.2.1-4.

[andyholmes]

Hmm, after some digging there seems to be a related upstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1636626

Unfortunately, it seems like the package maintainer is not (yet) convinced this is a bug in Fedora, but I don't see how it could be a bug in our extension or Nautilus. My best advice in the short term is to lock the package at python2-nautilus-1.2.1-3 (since it doesn't seem to include any code changes) and maybe "me too" that bug report with a link back to here.

[ferdnyc]

Re: That bug, the good news is that they've caught up to the fact that F29's python2-nautlus packaging is broken (leigh scott yelling at them no doubt hastened that come-to-jesus moment), and are now merely mulling over what to do about it.

The most recent proposal from Franco is to just bite the bullet, dump Python 2 support for nautilus-python extensions, and require that they all be Python 3 compatible.

(Which would be fine for us, right? Are we good with Python 3, on the Nautilus extension end... or, do we even know? There's no shebang at all in src/nautilus-gsconnect.py..., which makes sense of course, but leaves me wondering.)

Assuming we're Python 3 compatible (or can be), I'm kind of hoping the Franco plan prevails, and we can just escape this Python 2 insanity.

So, that being said, it _sounds_ like removing python2-nautilus and installing only python3-nautilus is the path to solving this on F29, even as things currently stands. (And if Franco's proposal wins out, is probably what the official solution will look like _anyway_.)

I know (or, I've now read) that you tried that before and hit a crash, but leigh has since replied to note that there's a missing Requires: python3-gobject-base in python3-nautilus, which is the source of the problem — so installing python3-gobject-base should fix that crash.

(The fact that python3-nautilus is probably needed to solve this also means that, on _our_ end, things gets a bit fraught. Changing the PackageKit requirement from python2-nautilus to python3-nautilus would break support for F28 and earlier. So there again, I'm hoping Franco's plan wins out: if F29 drops python2-nautilus, then we can just add it to the list alongside python2-nautilus, and whichever one is appropriate (i.e.: the only one available) for any given Fedora release will be installed.)

[andyholmes]

Which would be fine for us, right? Are we good with Python 3, on the Nautilus extension end... or, do we even know?

Yep, we're totally fine. In many cases Python2->3 is not relevant at all, and I think I avoided any syntax changes between the two (since I didn't actually know which was being used). KDE Connect uses a slightly modified version of ours and should also be okay.

Changing the PackageKit requirement from python2-nautilus to python3-nautilus would break support for F28 and earlier.

This I'm not sure about, especially not being a Fedora user, but with some more digging into PackageKit docs there may be an additional "conflicts" or "prefer latest" bitmasks we could use here.

Generally when I write this stuff (like the Shell tooltip code for example), I try and keep it modular in case some other extension author can re-use it, but that probably won't work in this case anyways. So another option is to do some OS/version detection if it's necessary and we can do it reliably.

[ferdnyc]

This I'm not sure about, especially not being a Fedora user, but with some more digging into PackageKit docs there may be an additional "conflicts" or "prefer latest" bitmasks we could use here.

Unfortunately not, due to the broken packaging state of python{2,3}-nautilus in F29 right now. The two packages are currently built to be installable side-by-side, as Python 2 and 3 versions of the same module normally would be. (I've pointed out in the upstream bug that these are _not_ python modules, and their inaccurate naming may have accidentally helped to create this problem.)

dnf (and therefore PackageKit) considers them two _completely_ different, unrelated packages, so there is no versioning relationship between them whatsoever (in fact their version numbers are identical), and there were no Conflicts:, Obsoletes:, or even Provides: defined on them that would help to correctly manage their installation. So until the packaging is fixed, we're vulnerable to their error and have to take a bit of care not to screw users up.

• Right now with only python2-nautilus listed in the dependencies for Nautilus integration, on F29 PackageKit will install that package even though it's broken.
• If I were to add python3-nautilus, PackageKit on F29 would install _both_ versions, because they're both available in its repos. Installing both is pretty much guaranteed to break things — assuming there's even a state they can be in that _isn't_ broken, right now.
• If I were to _remove_ python2-nautilus, on Fedora 28 and lower PackageKit would no longer be able to satisfy the nautilus-python part of our dependencies for Nautilus integration.

[ferdnyc]

(Yes, one option would be to filter the available package list returned by PackageKit, and remove python2-nautilus iff python3-nautilus is also found. That already feels _really_ hackish, but it's... a possibility to consider. As an absolute last resort.)

[rugk]

Likely the same issue in https://github.com/atenart/copr-build-mat2/issues/4 and https://bugzilla.redhat.com/show_bug.cgi?id=1647091…

So as I got lost in the (un)install python2/3 recommendations is there any recommendation that currently works.

And any recommendation for developers? Should they switch to python3-nautilus?

[ferdnyc]

Until they fix the packaging, the only option that _might_ work (from what leigh scott indicated at the bugzilla bug) is to force the switch to python3-nautilus manually. You'd have to break the dependencies and uninstall python2-nautilus or it's probably not gonna work.

$ sudo rpm -e --nodeps python2-nautilus
$ sudo dnf install python3-nautilus python3-gobject-base # (a missing python3-nautilus dependency)

Then restart the session and cross your fingers that whatever nautilus-python extension you want to use is Python 3 compatible.

[andyholmes]

That already feels really hackish, but it's... a possibility to consider. As an absolute last resort.

Yeah, I think it's best to just let upstream take responsibility for this. It's obviously happening for other Nautilus extensions anyways, and I've gathered that the current package maintainer doesn't really use them himself, since he misunderstands "building them" as though they're compiled.

He just happened to be the person who did the work of packaging and maintaining it, which is nothing to complain about really.

[basilrabi]

The Files integration works in fedora 29 again using the new nautilus-python package. Yay! This can be installed via the command:
bash dnf install nautilus-python --enablerepo=updates-testing
So starting from fedora 29, the new dependency for Files integration will be nautilus-python which will replace python2-nautilus.

[ferdnyc]

\o/ Yeah, my package-renaming argument surprisingly met with exactly zero resistance, just lots of head-nodding, so now that's sorted out as well. Which means we're all set w/PackageKit, too, since nautilus-python is already on the dependencies list for various other distros. That'll just also cover Fedora as well, starting with Fedora 29.

[ferdnyc]

(Oh, I should note FTR that the decision was ultimately made to keep F29's nautilus-python package at Python 2, same as F28's python2-nautilus package. The switch to Python 3 will occur in Fedora 30. Doesn't directly affect GSConnect, of course, since the extension code is already compatible.)

[ferdnyc]

I'm going to close this, since nautilus-python has now been available in Fedora 29 updates for more than a day. We've done all we can to address this issue on our end (which was basically nothing), and if anyone is still having problems using the GSConnect Nautilus extension under F29, the fix is almost certainly as simple as "Update your system".

(And if that doesn't fix the problem, please file a new issue.)