SUMMARY Skrooge is available at Flathub, but you can't test fixes before a new version is released. Many KDE applications have nightly and debug versions available in the https://distribute.kde.org/kdeapps.flatpakrepo , but not Skrooge. Skrooge devs have indicated they don't work on Flatpak packaging, but I don't know where else to make this request. There's a Phabricator project for Flatpak at https://phabricator.kde.org/project/profile/124/ and I think the master for the kdeapps repo is in Diffusion at https://phabricator.kde.org/source/flatpak-kde-applications/repository/master/ The developer of the flatpak recipe at Flathub is happy to share his code, see https://github.com/flathub/org.kde.skrooge/issues/3
Git commit 63da3451b02438e8438595367428a3419c507486 by Stephane MANKOWSKI. Committed on 10/04/2019 at 13:23. Pushed by smankowski into branch 'master'. build a nightly debug Skrooge flatpak See: https://git.reviewboard.kde.org/r/130252/ M +1 -0 CHANGELOG M +4 -2 README M +76 -23 org.kde.skrooge.json https://commits.kde.org/skrooge/63da3451b02438e8438595367428a3419c507486
Git commit 675cb834c0f051893f6afeee5d4142abfc4070c1 by Aleix Pol, on behalf of Stephane Mankowski. Committed on 10/04/2019 at 14:04. Pushed by apol into branch 'master'. Addition of Skrooge REVIEW: 130252 A +128 -0 org.kde.skrooge.json https://commits.kde.org/flatpak-kde-applications/675cb834c0f051893f6afeee5d4142abfc4070c1
Thanks for doing this. How long should it take for skrooge to show up on http://distribute.kde.org/flatpak-apps-testing ? `flatpak remote-ls --all kdeapps | grep -i skrooge` finds nothing. I apologize for reopening this bug if it just takes a while. Also, I'm a n00b, but why does the flatpak json for Skrooge mention tcl and give its archive, only to disable-tcl for package sqlcipher? Is this an oversight?
(In reply to skierpage from comment #3) > Thanks for doing this. How long should it take for skrooge to show up on > http://distribute.kde.org/flatpak-apps-testing ? `flatpak remote-ls --all > kdeapps | grep -i skrooge` finds nothing. I apologize for reopening this bug > if it just takes a while. I opened a request to KDE sysadmin to build and distribute Skrooge as a flatpack package as all other application. I will close this incident when it's done. > Also, I'm a n00b, but why does the flatpak json for Skrooge mention tcl and > give its archive, only to disable-tcl for package sqlcipher? Is this an > oversight? I don't know, I just copy/pasted and adapted an existing json file (https://github.com/flathub/org.kde.skrooge/blob/master/org.kde.skrooge.yml).
(In reply to Stephane MANKOWSKI from comment #4) > I opened a request to KDE sysadmin to build and distribute Skrooge as a > flatpack package as all other application. It's there, yay! $ flatpak install skrooge Looking for matches… Remotes found with refs similar to ‘skrooge’: 1) ‘flathub’ (system) 2) ‘kdeapps’ (system) Which do you want to use (0 to abort)? [0-2]: 2 Found ref ‘app/org.kde.skrooge/x86_64/master’ in remote ‘kdeapps’ (system). Use this ref? [Y/n]: y > I will close this incident when it's done. It is missing OFX import, the same problem as on flathub, https://github.com/flathub/org.kde.skrooge/issues/5
(In reply to skierpage from comment #5) > (In reply to Stephane MANKOWSKI from comment #4) > > > I opened a request to KDE sysadmin to build and distribute Skrooge as a > > flatpack package as all other application. > It's there, yay! > $ flatpak install skrooge > Looking for matches… > Remotes found with refs similar to ‘skrooge’: > > 1) ‘flathub’ (system) > 2) ‘kdeapps’ (system) > > Which do you want to use (0 to abort)? [0-2]: 2 > Found ref ‘app/org.kde.skrooge/x86_64/master’ in remote ‘kdeapps’ (system). > Use this ref? [Y/n]: y kdeapps is the good one. > > > I will close this incident when it's done. > It is missing OFX import, the same problem as on flathub, > https://github.com/flathub/org.kde.skrooge/issues/5 I did the commit to add libofx: https://cgit.kde.org/flatpak-kde-applications.git/commit/?id=41fa37b6bf3a2ddbb62080bfdbcc2f00824047ea The skrooge plugin for ofx import is well built and installed but I don't know why not detected at runtime. I'm still investigating. Regards.
This is working now. Regards
(In reply to Stephane MANKOWSKI from comment #7) >> The skrooge plugin for ofx import is well built and installed but I don't >> know why not detected at runtime. I'm still investigating. > This is working now. Not for me. I just did `flatpak update` and the master 2.20.0BETA org.kde.skrooge flatpak still can't import OFX/QFX files. I think its plugins directory is /var/lib/flatpak/app/org.kde.skrooge/x86_64/master/466f514d7a096b0dc06e81f14c24423c6a1027175a0af28e7351a3de6bee1e83/files/lib/plugins/ , and it contains lots of plugins like skrooge_import_qif.so, but not skrooge_import_ofx.so. But, https://binary-factory.kde.org/job/Skrooge_flatpak/lastSuccessfulBuild/execution/node/22/log/ indicates that it's building this plugin like all the others, e.g.: 09:32:56 processing: /home/flatpakdev/jenkins/.flatpak-builder/rofiles/rofiles-N9ZUkX/files/lib/plugins/skrooge_import_ofx.so Hmmm. Naybe this is a newer build. I'll try again in 24 hours before reopening.
(In reply to skierpage from comment #8) > I just did `flatpak update` and the master 2.20.0BETA > org.kde.skrooge flatpak still can't import OFX/QFX files. This is still the case with the skrooge flatpak from the kdeapps flatpakrepo Built on Sat May 4 09:34:35 UTC 2019. The flatpak directory /var/lib/flatpak/app/org.kde.skrooge/x86_64/master/blahblah/ does have files/lib/lifofx.so and files/lib/plugins/skrooge_import_ofx.so. I ran `strace -o /tmp/skrooge -ff flatpak run org.kde.skrooge` and it makes no attempts to open either file. I can't see what's different between skrooge_import_ofx.so and, e.g. skrooge_import_qif.so, and the flatpak does open the latter library and offer QIF as an import format. So I'm not sure what OFX import is broken.
Hi, When I execute strace -ff flatpak run org.kde.skrooge 2>&1 | grep ofx I can see that and I can import an ofx file: [pid 14165] statx(AT_FDCWD, "./skrooge_import_ofx", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe05f48560) = -1 ENOENT (No such file or directory) [pid 14165] statx(AT_FDCWD, "./skrooge_import_ofx.so", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe05f48560) = -1 ENOENT (No such file or directory) [pid 14165] statx(AT_FDCWD, "./libskrooge_import_ofx", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe05f48560) = -1 ENOENT (No such file or directory) [pid 14165] statx(AT_FDCWD, "./libskrooge_import_ofx.so", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe05f48560) = -1 ENOENT (No such file or directory) [pid 14165] statx(AT_FDCWD, "/app/lib/plugins/skrooge_import_ofx", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe05f48560) = -1 ENOENT (No such file or directory) [pid 14165] statx(AT_FDCWD, "/app/lib/plugins/skrooge_import_ofx.so", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0755, stx_size=106032, ...}) = 0 [pid 14165] openat(AT_FDCWD, "/app/lib/plugins/skrooge_import_ofx.so", O_RDONLY|O_CLOEXEC) = 16 [pid 14165] openat(AT_FDCWD, "/app/lib/plugins/skrooge_import_ofx.so", O_RDONLY|O_CLOEXEC) = 16 [pid 14165] openat(AT_FDCWD, "/app/lib/libofx.so.7", O_RDONLY|O_CLOEXEC) = 16 Could you try this? flatpak uninstall org.kde.skrooge flatpak install skrooge org.kde.skrooge
(In reply to Stephane MANKOWSKI from comment #10) > Hi, > > When I execute strace -ff flatpak run org.kde.skrooge 2>&1 | grep ofx > I can see that and I can import an ofx file: > ... > Could you try this? > flatpak uninstall org.kde.skrooge > flatpak install skrooge org.kde.skrooge I didn't try that. But I did figure out that the app's flatpak directory, ~/.var/app/org.kde.skrooge/ , contains a cache/ksycoca5_en_blahblah= file. Despite multiple `flatpak update`s, that file remained last modified back in December 2018. When I deleted it and ran the flatpak, OFX import appears! So it works for me now, but this feels like a bug in the way KDE Flatpak operates. It's unclear what should trigger a ksycoca5 rebuild, but a new version of a program with new functionality ought to do it. FWIW my normal Fedora ~/.cache/ksycoca5_en_blah= file was last modified yesterday, and I didn't issue the kbuildsycoca5 command. (There is a /var/lib/flatpak/runtime/org.kde.Platform/x86_64/5.12/blahblah/files/bin/kbuildsycoca5 binary in the KDE platform runtime, but I don't know how I would run it "within" a flatpak.)
I close this issue.
(In reply to skierpage from comment #11) > this feels like a bug in the way KDE Flatpak > operates. It's unclear what should trigger a ksycoca5 rebuild I filed bug 408010 - kbuildsycoca5 doesn't ever rebuild in Flatpak, and mentioned the workaround flatpak run --command=kbuildsycoca5 org.kde.skrooge in https://userbase.kde.org/KDE_System_Administration/Caches#Caches_and_Rebuilding_KSycoca_in_a_flatpak