Of all the applications I have written ebuilds for that depend on fuse-python, only flickrfs shows any semblance of working, and it has degraded functionality. This leads me to believe that fuse-python is not working at all. I am going to relate all the broken fuse-python stuff and then kick this bug out to the Tokyo Linux Users Group list, in hopes that one of the Pythonistas there-subscribed will have time and motivation to help me hack this out. I don't know Python from a hole in the ground. :(
Created attachment 123448 [details] fuse-python-0.2.ebuild Ebuild for the full 0.2 version; only 0.2_pre2 is in Portage. This changes nothing by itself, though. :(
Created attachment 123576 [details] fuse-python-0.1.ebuild Maybe everyone wants version 0.1
Created attachment 123577 [details, diff] Fixes compile errors Taken from http://bugs.gentoo.org/attachment.cgi?id=52578
*** Bug 185944 has been marked as a duplicate of this bug. ***
The new gmailfs-0.8.0 works (and requires) fuse-python-0.2. I haven't noticed any reduced functionality.
Hi, I'm the new lead maintainer for the flickrfs package. I'm also a long time Gentoo user, though I haven't tried to make any contributions before this. I can confirm that (1) flickrfs works with fuse-python 0.1 (currently avaialble as the python-fuse ebuild, but not what the flickrfs ebuild depends on) and that (2) it does not work correctly with fuse-python 0.2. The 0.2 problem involves threading. Specifically, threads started in the main flickrfs.py application freeze once fuse-python is called. From the data I have gathered so far (which only consists of four data points, unfortunately), this appears to be a gentoo specific problem with fuse-python. I and the one other gentoo user I have heard from have the problem. The one non-gentoo user (someone on Debian sid) does not have the problem. I contacted the fuse-python developer, and he cannot reproduce the threading bug, even though he is using the exact same fuse version, python version, and kernel version that I am. Unfortunately, while I am an experienced python programmer, I am not experienced with coding python extensions in C, and thus am not in much of a position to debug this. However, the fact that it is threading related may lead to someone being able to suggest some experiments I could try to try to isolate the problem. For example, is there a way for me to recompile some things (eg: Fuse and Python) with a different threading package? I can also supply a fuse-python test program that demonstrates the threading problem. It is a slight modification of the xmp.py demo program that comes with fuse-python. I will attach it. If you run it, it will print out 'ticking' four or five times, when it should, if threading were working correctly, print it out ticking nine times and then throw a NotImplementedError. Let me know what I can do to help resolve this.
Created attachment 142372 [details] Example demonstrating threading problem with fuse-python 0.2 To run: xmp.py --version /tmp somemountpoint In failure mode it prints out 'ticking' four or five times and then stops (but continues to do the normal functions of xmp.py, which is to mirror /tmp to your chosen mount point in this case). If threading were working correctly it would print out ticking ten times and then throw NotImplementedError in the thread.
Reassigning since jmglov has retired from Gentoo.
If you use import threading print "starting thread" threading.Thread(target=self.mythread).start() instead of import thread print "starting thread" thread.start_new_thread(self.mythread, ()) it works for me. So perhaps it is really an "error" in the underlying python thread implementation - which gets fixed in the threading module. But afaik there is no use in using thread instead of threading anyway.
Created attachment 146405 [details] small threading showcase I think, I found the reason it behaves like it behaves :) Threads created with the "thread" module run in daemon mode - i.e. they are stopped as soon as the main program quits. I guess this is even true if the main program forks (I guess this is what fuse does). Threads created with "threading" run in non-daemon (if not set to daemon mode explictly) - so they even run when the main program has stopped. Thus I created the attached showcase. Run it w/o any arguments to get the "thread" module, with one argument to get "threading" and with two to get "threading as daemon". - And watch the output. This really seems like what we are seeing in the bug :)
Just found this while reading the fuse-dev m-l ... http://www.nabble.com/Re:-thread-in-python-fuse-when-running-on-background--p15289550.html
Ok - I really found the issue: It's an error in the compat mode of fuse-python. In getattr_compat_0_1 an instance of os.stat_result is returned, whereas (for what ever reasons) a fuse.Struct instance is wanted. Perhaps it is because of the additional members in os.stat_result. However: I'll forward this upstream.
Created attachment 147413 [details, diff] patch to make flickrfs work And here is a patch, which makes the CVS version of flickrfs working with fuse-python-0.2 (note: no -pre :)) (And: This still uses the old API)
Just as a note - works with fuse-python-0.2_pre2 (the version in portage) too.
Created attachment 149060 [details, diff] fuse_python_accept_none.patch And here is now a patch which should resolve the issue - patching fuse-python itself. It no longer needs patches to the applications (like flickrfs). If upstream responds in a positive way, we are near to a solution. If upstream does not respond, I'll provide the ebuild _and_ the patch.
Are there any further comments from the flickrfs site? - If not: WORKSFORME
fuse-python in shape again now
