Created attachment 148147 [details] logs SUMMARY Importing OFX files fails completely on any file I tried, due to a low-level parse error (logs attached). This includes known-good files that I have successfully imported in the past with previous releases of skrooge. STEPS TO REPRODUCE 1. Attempt to import an OFX file OBSERVED RESULT The import fails completely. EXPECTED RESULT The import succeeds, at least for files that used to work. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: n/a KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION I cannot select the correct version in the dropdown, looks like the options are 2 versions behind :)
Hi, Could you provide me an anonymized ofx sample file to reproduce the issue ? This is just to identify if the issue is coming from the format of the OFX file or from your installation. For information, the error is not raised by Skrooge but by libofx. This could be due to an issue in installation of libofx.
Created attachment 148271 [details] minimal reproducing example I did some more digging because my minimal anonymous file didn't trigger the issue. After playing with 'xmllint' and not finding anything, I tried importing a pretty-printed file and the cause became obvious: The offenders where all non-ascii characters. I attached a minimal example that I was able to reproduce this with. The funny thing is that nothing major changed about my system. Every software handles unicode just fine, and this file used to be correctly imported in previous versions (of skrooge and probably it's dependencies). This is the output of 'locale': LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=
Created attachment 148340 [details] Import Hi, No issue for me with this file. The import seems to be correct.
I will contact my libofx maintainer then, thank you! Do you have any other hints or ideas?
You can play with ofxdump to check if the issue is coming from libofx.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
I tracked this down to the source and got a workaround implemented in libofx! The cause of this issue is in OpenSP, which libofx uses to parse SGML and XML. That library's quality is suboptimal, and the last release is 20 years ago - obviously predating UTF. So there are a ton of workarounds in libofx around multi-byte encodings... Libofx has accepted the bug [0] and merged a workaround [1] for the case described in this ticket, which amounts to treating this "error" as a warning and ignoring it in the return status. I was able to locally build and LD_PRELOAD that branch and could successfully import previously-failing OFX files into Skrooge. So I think we can treat this as fixed upstream, as soon as they release a new version with the fix! I can handle asking for a new release of libofx in arch, but since the Skrooge project releases an AppImage that also didn't work for me, I would suggest that you release a new build with the latest libofx as soon as that is released :) PS: The "RESOLVED UPSTREAM" status is not described in https://bugs.kde.org/page.cgi?id=fields.html#bug_status. I hope this is the correct state for this ticket. [0] https://github.com/libofx/libofx/issues/60 [1] https://github.com/libofx/libofx/pull/64