Summary: | CVS import from PayPal causes Crash when setting columns | ||
---|---|---|---|
Product: | [Applications] kmymoney | Reporter: | george |
Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | agander93, onet.cristian, ostroffjh |
Priority: | NOR | ||
Version: | git (master) | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
george
2014-09-30 21:46:28 UTC
As there is no longer such a class as CsvImporterDlg - "#6 0x00007f89b2c9cee8 in CsvImporterDlg::validateColumn", I assume that although the bug is entered against git master, the backtrace is from an earlier release. (Or, might the plugin be from an earlier release? If so, be sure to remove that version completely.) The earlier bug backtrace to which you refer looks almost identical. Also, the symbols here appear incomplete. As there has been a previous issue in this area, which was fixed, I really need a backtrace from master to get close enough to see how this relates to the earlier problem. How many hundred columns does your CSV file contain? <BG> I've just successfully imported a 47 column paypal file, with no problem. Could you also provide a sample CSV file which demonstrates the problem. Further, as a get-around if there is still a problem, perhaps you could try removing some unneeded columns? (In reply to allan from comment #1) > As there is no longer such a class as CsvImporterDlg - > "#6 0x00007f89b2c9cee8 in CsvImporterDlg::validateColumn", > I assume that although the bug is entered against git master, the backtrace > is from an earlier release. (Or, might the plugin be from an earlier > release? If so, be sure to remove that version completely.) The earlier > bug backtrace to which you refer looks almost identical. > Also, the symbols here appear incomplete. > > As there has been a previous issue in this area, which was fixed, I really > need a backtrace from master to get close enough to see how this relates to > the earlier problem. > > How many hundred columns does your CSV file contain? <BG> I've just > successfully imported a 47 column paypal file, with no problem. > > Could you also provide a sample CSV file which demonstrates the problem. > > Further, as a get-around if there is still a problem, perhaps you could try > removing some unneeded columns? Ok, I just don't understand... I removed the 4.6.6 rpms from Fedora and the CSV option is no longer in the File menu. Clearly there was shared code. Could you tell me how to buid with CSV included? The issue is less the building than the installing. All KDE applications (unless you are extremely careful in the build configuration) install in the same place (or set of places for user and system) so KDE always knows where to look for things like icons, help files, config files, ..... If you run KMM from the build directory, KDE still looks in the system location, so without doing "make install" it will find the system installed plugins and not the ones you just built. If you do "make install" without first uninstalling the distro installed version, you will end up with some mix of files. The CSVimport plugin is built by default when you build from source. However, unless you do "make install" after the "make" KDE will not find it. On 10/01/14 13:38, Jack wrote: > https://bugs.kde.org/show_bug.cgi?id=339544 > > Jack <ostroffjh@users.sourceforge.net> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |ostroffjh@users.sourceforge > | |.net > > --- Comment #3 from Jack <ostroffjh@users.sourceforge.net> --- > The issue is less the building than the installing. All KDE applications > (unless you are extremely careful in the build configuration) install in the > same place (or set of places for user and system) so KDE always knows where to > look for things like icons, help files, config files, ..... If you run KMM > from the build directory, KDE still looks in the system location, so without > doing "make install" it will find the system installed plugins and not the ones > you just built. If you do "make install" without first uninstalling the distro > installed version, you will end up with some mix of files. > > The CSVimport plugin is built by default when you build from source. However, > unless you do "make install" after the "make" KDE will not find it. The CVS files are in /opt/KMM/lib64, kmymoney in /opt/KMM/bin, still do not have the CVS import option in the File menu, only QIF and GNU Cash seems OFX has also gone missing. I have been doing the make install all along... Oh, by the way, tried kmymoney from the build directory, they are not there either. Your install dir has to match where KDE expects to find stuff. When you do the initial cmake, what install directory do you specify? It sounds like /opt/KMM. If your distro installed KDE is looking in /usr or /usr/local, then it will never find your plugins under /opt/KMM. You can still use /opt/KMM, but you will then need to alter KDEDIRS and run kbuildsyscoca4 so KDE knows about the new stuff. It's probably easier to just install into /usr/local and remember to "make uninstall" before trying a new version. Again, so you understand, when you run kmymoney from the build directory, the only thing you are getting from there is the single executable file. KDE will still look for all the other stuff: icons, plugins, ... in /usr/local (or wherever it is using.) I really wish it was otherwise, but I've been fighting this issue for a long time, and not very successfully. (In reply to Jack from comment #5) > Your install dir has to match where KDE expects to find stuff. When you do > the initial cmake, what install directory do you specify? It sounds like > /opt/KMM. If your distro installed KDE is looking in /usr or /usr/local, > then it will never find your plugins under /opt/KMM. You can still use > /opt/KMM, but you will then need to alter KDEDIRS and run kbuildsyscoca4 so > KDE knows about the new stuff. It's probably easier to just install into > /usr/local and remember to "make uninstall" before trying a new version. > > Again, so you understand, when you run kmymoney from the build directory, > the only thing you are getting from there is the single executable file. > KDE will still look for all the other stuff: icons, plugins, ... in > /usr/local (or wherever it is using.) I really wish it was otherwise, but > I've been fighting this issue for a long time, and not very successfully. I completely wiped the git and the rpm installs and then pulled a new git. CVS import now seems to "almost" work. The remaining problem is that when I "Finish" KMM acts as if nothing happened. The manual says it should ask which account, but it does not. Given all the above history of this issue, this could well be another cockpit error.... Any help would be welcome. As far as I know you need to press 'import' instead of 'finish'. Yes, that is correct. 'Finish' means exactly that. Perhaps I should rename it 'Exit'. 'Import ' first, though. You should then be there. Do I take it you didn't have the 'Paypal' problem? Yes - please change Finish to either Close or Exit, and maybe even add an "Are you sure" popup if there has been no import actually done. I've been caught by that myself a few times. (In reply to allan from comment #8) > Yes, that is correct. 'Finish' means exactly that. Perhaps I should rename > it 'Exit'. 'Import ' first, though. You should then be there. Do I take > it you didn't have the 'Paypal' problem? No problem with paypal. I will try the import later, no time now. On 02/10/14 19:01, Jack wrote: > https://bugs.kde.org/show_bug.cgi?id=339544 > > --- Comment #9 from Jack <ostroffjh@users.sourceforge.net> --- > Yes - please change Finish to either Close or Exit, and maybe even add an "Are > you sure" popup if there has been no import actually done. I've been caught by > that myself a few times. > Yes, I'll do that. But not now, as it's not as straight forward as I expected, and I don't want to sidetrack just now. The Finish button does actually do that. I can intercept and put up a message, but what happens then is not straight forward. Allan (In reply to george from comment #10) > (In reply to allan from comment #8) > > Yes, that is correct. 'Finish' means exactly that. Perhaps I should rename > > it 'Exit'. 'Import ' first, though. You should then be there. Do I take > > it you didn't have the 'Paypal' problem? > > No problem with paypal. I will try the import later, no time now. Except for a lot of column missmatch errors it seems to have worked. What are these errors about? Oh, and could you add a way to specify the transaction id? This would avoid dup issues and since PayPal provides them.... -- George On 03/10/14 23:14, george@wildturkeyranch.net wrote: > https://bugs.kde.org/show_bug.cgi?id=339544 > > --- Comment #12 from george@wildturkeyranch.net --- > (In reply to george from comment #10) >> (In reply to allan from comment #8) >>> Yes, that is correct. 'Finish' means exactly that. Perhaps I should rename >>> it 'Exit'. 'Import ' first, though. You should then be there. Do I take >>> it you didn't have the 'Paypal' problem? >> >> No problem with paypal. I will try the import later, no time now. > > Except for a lot of column missmatch errors > it seems to have worked. Good. > What are these errors about? Beats me, George. You'll need to be a bit more specific. > Oh, and could you add a way to specify the transaction id? This would avoid dup issues and since PayPal provides them.... > That looks like it needs to be a wish-list item, if you want to do that. The immediate snag I see is that the UI is already very busy. Allan Since the subject of the report is a crash and it's reported as working in comment #10 using the latest version I'm closing this. |