-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Aug 04, 2017 at 07:40:22PM -0700, Andrew Morgan wrote: > On 08/04/2017 05:36 PM, Andrew Morgan wrote: > > On 08/04/2017 05:17 AM, Marek Marczykowski-Górecki wrote: > >> On Fri, Aug 04, 2017 at 03:51:32AM -0700, Andrew Morgan wrote: > >>> On 08/02/2017 07:59 AM, Marek Marczykowski-Górecki wrote: > >>>> On Wed, Aug 02, 2017 at 04:33:51AM -0700, Andrew Morgan wrote: > >>>>> On 08/01/2017 02:54 AM, Andrew Morgan wrote: > >>>>>> On 08/01/2017 02:53 AM, Marek Marczykowski-Górecki wrote: > >>>>>>> On Tue, Aug 01, 2017 at 12:59:16AM -0700, Andrew Morgan wrote: > >>>>>>>> On 07/31/2017 03:17 AM, Marek Marczykowski-Górecki wrote: > >>>>>>>>> On Sun, Jul 30, 2017 at 11:48:48PM -0700, Andrew Morgan wrote: > >>>>>>>>>> Quick update for tonight. > >>>>>>>>> > >>>>>>>>>> I've found where the most likely choke point for opening files is. > >>>>>>>>>> [1] > >>>>>>>>>> Ideally one would just make a call to extensions through > >>>>>>>>>> libnautilus-extension through there, wait for responses, then > >>>>>>>>>> return if > >>>>>>>>>> any extension returns a False. I'm unsure if anything in Nautilus > >>>>>>>>>> on the > >>>>>>>>>> UX side needs to happen after that (such as showing a loading icon > >>>>>>>>>> or > >>>>>>>>>> something...) but that's currently outside the scope of this > >>>>>>>>>> patchset. > >>>>>>>>> > >>>>>>>>>> I've been talking to and getting help from people on > >>>>>>>>>> GIMPnet/#nautilus. > >>>>>>>>>> After explaining the whole idea to a few people, I've been > >>>>>>>>>> prompted to > >>>>>>>>>> post on the mailing list. I have now done so with a RFC of sorts > >>>>>>>>>> on the > >>>>>>>>>> idea and whether or not they'd be prone to accepting it upstream > >>>>>>>>>> once > >>>>>>>>>> it's ready. > >>>>>>>>> > >>>>>>>>>> The post is currently awaiting moderation approval, but I'll link > >>>>>>>>>> it > >>>>>>>>>> once it goes up so people can keep up with the discussion. > >>>>>>>>> > >>>>>>>>> Great, thanks for the update! > >>>>>>>>> > >>>>>>>>>> Andrew Morgan > >>>>>>>>> > >>>>>>>>>> [1]: > >>>>>>>>>> https://github.com/GNOME/nautilus/blob/master/src/nautilus-mime-actions.c#L2421 > >>>>>>> > >>>>>>>> Another update, > >>>>>>> > >>>>>>>> The mailing list post still hasn't been approved. I messaged on > >>>>>>>> GIMPnet > >>>>>>>> about it not too long ago so hopefully the appropriate people will > >>>>>>>> get > >>>>>>>> pinged eventually. The team is currently busy with GUADEC so it's > >>>>>>>> understandable they may be running behind on moderating posts on a > >>>>>>>> not > >>>>>>>> too traffic heavy mailing list[1] :) > >>>>>>> > >>>>>>> Does subscribing to the list workaround the issue? Some times > >>>>>>> moderator > >>>>>>> is set to just one, busy, person... > >>>>>> > >>>>>> I presume that's probably the case, yeah. I subscribed before I posted, > >>>>>> didn't seem to make a difference :) > >>>>>> > >>>>>>> > >>>>>>>> In terms of the patch, I've inserted the necessary code into all the > >>>>>>>> accompanying files and Nautilus builds successfully. During my > >>>>>>>> testing I > >>>>>>>> threw a return statement in there and confirmed it blocked all file > >>>>>>>> open > >>>>>>>> attempts silently, which is intended behavior. > >>>>>>> > >>>>>>>> I've stuck the WIP code up on Github, currently it segfaults but the > >>>>>>>> cause is known. I'll be modifying the qvm_trust.py NautilusPython > >>>>>>>> extension to make use of this method soon, and once it all works out > >>>>>>>> I'll provide some pre-made .RPMs for testing. > >>>>>>> > >>>>>>> Ok :) > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>> > >>>>> Another status update for today. > >>>> > >>>>> As I said mostly everything's in place, however I'm currently stuck on > >>>>> trying to provide the correct arguments to a function that calls the > >>>>> subclassed methods in nautilus extensions. > >>>> > >>>>> Here is an example of calling a function subclassed by extensions: > >>>>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-directory-async.c#L4647 > >>>> > >>>>> The update_complete and &handle arguments are not necessary for our > >>>>> purposes, but the provider and file args are. > >>>> > >>>>> Here I am calling our new method, that asks extensions whether we should > >>>>> open a particular file or not: > >>>>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-mime-actions.c#L2500 > >>>> > >>>>> However the provider object is NULL. That > >>>>> nautilus_module_get_extensions_for_type method is defined here: > >>>>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-module.c#L268 > >>>> > >>>>> That G_TYPE_CHECK_INSTANCE_TYPE always fails, so we never get any data > >>>>> prepended. G_TYPE_CHECK_INSTANCE_TYPE doesn't seem to be defined in this > >>>>> codebase either, which makes it a bit tricky to figure out why we're > >>>>> getting a negative value back from it. > >>>> > >>>>> Talking to people about it on IRC has brought mixed results, it seems > >>>>> the extension interface hasn't been changed in a while, so most don't > >>>>> remember too much about it. I'll keep asking though, hoping someone in > >>>>> the know pops in. > >>>> > >>>>> That's where I'm at currently, any help or clues are appreciated. > >>>> > >>>> See this search results: > >>>> https://github.com/search?q=org%3AGNOME+NAUTILUS_TYPE_INFO_PROVIDER&type=Code > >>>> > >>>> Especially this one: > >>>> https://github.com/GNOME/gnome-system-tools/blob/50f92695648a1d6340416c8db6eff7c38a7b3bbd/src/shares/nautilus/nautilus-shares.c#L349-L352 > >>>> > >>>> > >>>> > >> > >>> Alright well I've been at this for a bit again with varying success. > >> > >>> The issue is that this if statement here fails: > >>> https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-module.c#L290 > >> > >>> This is due to none of the modules in module_objects being of type > >>> NAUTILUS_TYPE_INFO_PROVIDER. I tried the method suggested > >>> (g_type_module_add_interface) but am unsure of how to get access to the > >>> correct module to add our NAUTILUS_TYPE_INFO_PROVIDER type to. > >> > >>> Looking at nautilus-sendto-module.c (part of the included sendto > >>> extension) it gets a module from Nautilus, then calls a method that > >>> registers the NAUTILUS_TYPE_MENU_PROVIDER with that module: > >> > >>> https://github.com/anoadragon453/nautilus/blob/master/nautilus-sendto-extension/nautilus-sendto-module.c#L33 > >> > >>> https://github.com/anoadragon453/nautilus/blob/master/nautilus-sendto-extension/nautilus-nste.c#L190 > >> > >>> So, nautilus-python is flexible and will do this for you given that your > >>> extensions asks for one of the variable provider types: > >> > >>> https://github.com/anoadragon453/nautilus-python/blob/master/src/nautilus-python-object.c#L651 > >> > >>> So while writing this it seems that unless the new method (or any > >>> extension) is integrated into nautilus-python, it won't work to call it > >>> from nautilus. That wouldn't be such a big deal... if nautilus-python > >>> would work when I build and installed it. For that I'm having the > >>> following issue: > >> > >>> [user@dev-fedora nautilus-python]$ nautilus > >>> /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:40: Warning: > >>> specified class size for type 'PyGtkGenericCellRenderer' is smaller than > >>> the parent type's 'GtkCellRenderer' class size > >>> from gtk import _gtk > >>> /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:40: Warning: > >>> g_type_get_qdata: assertion 'node != NULL' failed > >>> from gtk import _gtk > >>> ^CSegmentation fault (core dumped) > >>> [user@dev-fedora nautilus-python]$ > >> > >>> This happens with both my patched nautilus-python and the version > >>> directly from source. Some research online says that it has to do with > >>> importing both PyGObject and PyGTK libraries at the same time[1], which > >>> is interesting as both libraries are a requirement to build > >>> NautilusPython. This crash occurs with patched nautilus and nautilus > >>> from the repos, so it's definitely an issue with building NautilusPython > >>> in some form or another, even though the build completes successfully. > >> > >>> The process of building it is as follows, simply: > >> > >>> ./autogen > >>> make > >> > >>> Then one copies the produced src/.libs/libnautilus-python.so to > >>> /usr/lib64/nautilus/extensions-3.0/ and nautilus will load it on startup. > >> > >>> You can grab the source code from here: git clone > >>> git://git.gnome.org/nautilus-python > >> > >>> And all the dependencies on Fedora: sudo dnf install gnome-common > >>> gtk-doc python-devel gnome-python2-devel > >> > >>> And getting an error related to get_toolbar_items is normal, I just > >>> comment out that line. I don't believe it to be related to the segfault. > >> > >> I get identical behavior. > >> Then switched to nautilus-3.0 branch and this one do not crash. > >> > >> I get this at startup: > >> > >> Traceback (most recent call last): > >> File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 39, > >> in <module> > >> raise ImportError(_static_binding_error) > >> ImportError: When using gi.repository you must not import static > >> modules like "gobject". Please change all occurrences of "import gobject" > >> to "from gi.repository import GObject". See: > >> https://bugzilla.gnome.org/show_bug.cgi?id=709183 > >> > >> (nautilus:1168): Nautilus-Python-WARNING **: > >> nautilus_python_init_python failed > >> > >> Not sure if failing nautilus_python_init_python prevent the SEGV, or > >> previously it didn't got that far. > >> > >> BTW that SEGV was infinite recursion like this: > >> > >> #39684 0x00007fffcb7d42d2 in pyg_type_get_bases () at > >> /usr/lib64/python2.7/site-packages/gobject/_gobject.so > >> #39685 0x00007fffcb7d4672 in pygobject_new_with_interfaces () at > >> /usr/lib64/python2.7/site-packages/gobject/_gobject.so > >> #39686 0x00007fffcb7d4285 in pygobject_lookup_class () at > >> /usr/lib64/python2.7/site-packages/gobject/_gobject.so > >> #39687 0x00007fffcb7d42d2 in pyg_type_get_bases () at > >> /usr/lib64/python2.7/site-packages/gobject/_gobject.so > >> #39688 0x00007fffcb7d4672 in pygobject_new_with_interfaces () at > >> /usr/lib64/python2.7/site-packages/gobject/_gobject.so > >> > >> > >> > > > > Wow, did not notice that branch. Yes that seems to be compatible with > > the latest Nautilus code. > > > > I can't explain it, but for some reason I do not get that error on my > > fedora-25-minimal VM (where I'm doing my testing), however I do get it > > on my fedora-25 VM. Instead, I get the following: > > > > [user@fedora-25-minimal np3]$ nautilus > > sys:1: PyGIWarning: Nautilus was imported without specifying a version > > first. Use gi.require_version('Nautilus', '3.0') before import to ensure > > that the right version gets loaded. > > > > ** (nautilus:11881): WARNING **: Unable to get contents of the bookmarks > > file: Error opening file /home/user/.gtk-bookmarks: No such file or > > directory > > update_file_info_full > > Traceback (most recent call last): > > File > > "/usr/share/nautilus-python/extensions/update-file-info-async.py", line > > 9, in update_file_info_full > > gobject.timeout_add_seconds(3, self.update_cb, provider, handle, > > closure) > > NameError: global name 'gobject' is not defined > > update_file_info_full > > > > However python extensions still seem to work fine, so I'll just continue > > on with this VM for now. > > > > Andrew Morgan > > > > Alright, I've managed to narrow down the issue to a single line which is > baffling me and probably has something to do with 32-bit vs. 64-bit > system (I'm on 64-bit of course). > > https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-mime-actions.c#L2489 > > So providers here (a GList *) is ending up as a different pointer than > what is being returned (another GList *), but instead of something > completely different, it's the same pointer but truncated 4 hex values > at the front. > > Here we can see that without the truncation, we get a valid pointer > destination. > > (gdb) print providers > $7 = 0x55f65ac0 = {Cannot access memory at address 0x55f65ac0 > (gdb) print 0x555555f65ac0 > $8 = 93825002789568 > (gdb) Quit > (gdb) > > So we're getting a 32-bit pointer instead of a 64-bit pointer, but I > can't see why as they're both GList *'s. As far as I know getting data > from this method works fine in other parts of the program, i.e. here: > > https://github.com/anoadragon453/nautilus/blob/master/src/nautilus-files-view.c#L4577
Try: print (GList*)0x555555f65ac0 Have you tried make clean after switching branch? I've got some problems without that (like still old version reporting). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZhXrOAAoJENuP0xzK19csGh8H/RJ1qY8ILecqBcjDZtY7WVcC sDJi0Eh3flWNAu3rPtIyZKYTNoYeP2pqLLLtmwOpbTNvAEfgY/kuKHVWblyHhqRo n+Vvc5BlZSC92AbFUMXwce8/6cYn1CwNmKq5s3pUisFZlTAL5DIat8dfbQHTlgRn cMJYxlJ61z1zJ/qF7ZWsPInbATsvx9ivfib7FkPILf71enNTDGfrY4MzOA+ta/v7 jBAO6BCQxYTKrCbsu2U+DQ4NsOGaU/VbAbXJszEv51ldciT43WyDHbtYRPOVwPA6 7wwbMAzRpRx3vRKYQeTXPRGG8No3hwzdY1VFznA3oPdYgA6xQ6OjsLzHfDwkUrs= =weJ0 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170805075909.GL1095%40mail-itl. For more options, visit https://groups.google.com/d/optout.