Rapid Photo Downloader displays only “Others” when I connect my Fuji X-T2, so I cannot copy the files. For sure I have photos and videos on my cam. I can grab them on windows with Fuji software.
Is there something specific with Fuji X-T2 and RPD?
I am on Linux Mint 18.1 “Serena” Cinnamon
RAF, jpg and MOD files are recognized by Rapid Photo Downloader.
I cannot diagnose what is happening without seeing the log file. You can get the location of the log file from the “Report a Problem” dialog window, accessible from the main menu.
Please file a bug report here: https://bugs.launchpad.net/rapid/+filebug
In your bug report please include all the log files you have in the log files directory, and also describe if you see the expected directory structure and files when browsing the camera using the LinuxMint file manager.
Thanks.
Indeed I cannot browse the files with the file manager and it looks like a libgphoto2 issue. I have the version 2.5.9-3 and from the 2.5.14 changelog:
Fuji XT-2 capture support (firmware update needed, might work for other Fuji XT too)
Thanks for your time.
It sure would be good if Rapid Photo Downloader could be packaged as a snap, because then the very latest libgphoto2 could be included. However, it’s proving quite difficult for me to create the snap, as currently the snap technology is immature.
As an alternative to snap, you could create an AppImage packagge. @Carmelo_DrRaw has some experience in creating AppImage packages.
I’m definitely ready to help with a possible AppImage package for RPD, but most likely I’ll be only available for that starting from August… maybe @probono can also provide some help and guidance.
An AppImage might well be the best solution for now, given it has the ability to include newer (or older) versions of library code that provided by the distribution. I’ll definitely appreciate any help offered!
You should reach out to Alan Pope or Martin Wimpress, both Canonical employees, as they’ve been assisting projects by building snap packages. Both are on twitter or google plus.
After looking a little at AppImage, it seems one needs to build everything manually from source, starting with Python, step by step. Disconcertingly, the last stable release of the tool to build AppImages is 1.5 years old, with several development releases since then, most of whose purpose is not immediately obvious.
By contrast, with snaps, the snapcraft tool is supposed to take care of everything for you–which works well until it doesn’t, at which point you’re stuck.
The documentation for both projects is lacking. For example the snap documentation for building a Python snap doesn’t list snapcraft’s current limitations, which is unfortunate. I guess the snap developers are figuring them out as they go, and things are moving fast. Whereas for AppImages, there is very little documentation at all regarding Python programs. It’s unclear if the samples provided work, because they haven’t been updated for some time.
Not necessarily… one can build the AppImage on some not-so-new Ubuntu version (I am using 14.04) and get most of the dependencies from the .deb packages. Then one can build from source only those dependencies that need to be newer than what is available via .deb.
I am currently finalizing the python support for the GIMP AppImage, which the python interpreter being included in the bundle so that the AppImage can also run on systems where the native python package is not installed.
Let me have a look in the next days, so that we can have a clearer idea of how hard it would be to set-up an AppImage…
That could prove useful, because digging into this some more, just building python is quite a lot of work – because you first need to build openssl, bzip2, sqlite3, etc.
I’d need to use Ubuntu 16.04, however, because the packages in 14.04 are just too old to use recent versions of gobject introspection, PyQt5 etc.
We have to check this, as it is not necessarily true I think… for my AppImages I am extensively using jhbuild, a python-based build system that automatically handles package dependencies and allows to easily build several packages from sources.
You can find an example for GIMP here. It allows to build the latest GIMP with up-to-date dependencies on Ubuntu 14.04 or equivalently old distributions.
I propose to try a similar approach for RPD, and see how far we can go. One think that could be helpful would be a list of the required minimum versions for the major RPD dependencies, to prepare a first jhbuild configuration for the project.
What do you think?
If it means I don’t need to figure out how to build every single dependency from source then it’s definitely worth investigating! Doing everything by hand is rather painful. Does jhbuild already know how to build Python 3.5 / 3.6, including its dependencies? I’ve been unable to figure out that. Even if it doesn’t do that, building python gobject introspection automatically seems like a good idea.
For other Rapid Photo Downloader dependencies, not every package should be the oldest one can get away with. For example, one thing I’d like to achieve with a solution like AppImage or Snap is to use the latest gphoto2 (so users can use newer cameras) and the latest exiv2 (to read the metadata on files produced by recent cameras).
On the other hand, using the latest libraw (0.18) is not good, because the developers of the python bindings for it have not released a version that works with 0.18, despite @Wim_Verheij having already pitched in and submitting a patch.
So, to answer the question about the dependencies:
Additional required python packages (names straight from Pypi):
To build it: