[digikam] [Bug 370744] Date viewer does return photos

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370744

--- Comment #1 from Jeff  ---
Found a workaround ...seems to do with new defaults in MYSQL 5.7 releases ...
see https://github.com/Piwigo/Piwigo/issues/376 

Now changed SQL mode for MYSQL to be blank and date view is now working :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 370744] New: Date viewer does return photos

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370744

Bug ID: 370744
   Summary: Date viewer does return photos
   Product: digikam
   Version: 5.2.0
  Platform: MacPorts Packages
OS: OS X
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Searches-Dates
  Assignee: digikam-de...@kde.org
  Reporter: jeffmarch...@hotmail.com

Browsing for photos using the date view control shows the tree structure for
years and months ok. When you select a month no photos are displayed or dates
highlighted in the calendar, even though there are photos for that date present
in the album. The timeline browser works ok.

If I look in the console output when selecting a month in date browser I see
that there is an SQL error raised.

" Prepare failed!
digikam.dbengine: Failure executing query:
 "SELECT DISTINCT Images.id, Images.name, Images.album,   
Albums.albumRoot,ImageInformation.rating, Images.category,   
ImageInformation.format, ImageInformation.creationDate,   
Images.modificationDate, Images.fileSize,ImageInformation.width,
ImageInformation.height  FROM ImagesLEFT JOIN ImageInformation ON
Images.id=ImageInformation.imageidINNER JOIN Albums ON
Albums.id=Images.album  WHERE Images.status=1AND
ImageInformation.creationDate < ?AND ImageInformation.creationDate >= ? 
ORDER BY Albums.id;" 
Error messages: "QMYSQL3: Unable to prepare statement" "Expression #1 of ORDER
BY clause is not in SELECT list, references column 'digikam.Albums.id' which is
not in SELECT list; this is incompatible with DISTINCT" 3065 2"

Reproducible: Always

Steps to Reproduce:
1.Select a month node from the tree in the date viewer
2.
3.

Actual Results:  
NO photo displayed in viewer window and no dates highlighted in calendar
control 

Expected Results:  
Photo displayed in viewer window for selected month.

This is a fresh  install using the 5,2,0 pkg with external MySQL database.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 366326] OFX direct download fails when OFX UID is expected by bank

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366326

--- Comment #5 from Jeff  ---
Created attachment 100482
  --> https://bugs.kde.org/attachment.cgi?id=100482=edit
libofx patch to support 

libofx patch to support . I did not rebuild my libofx with this
patch because backing out all my other changes is a lot of work. But this
should be sufficient to support .

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 366326] OFX direct download fails when OFX UID is expected by bank

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366326

--- Comment #4 from Jeff  ---
Created attachment 100481
  --> https://bugs.kde.org/attachment.cgi?id=100481=edit
KMM patch to support OFX 

"Client UID" field added to the online settings UI. I built KMM with this patch
and connected to my Chase account OK using an updated libofx. This patch
assumes libofx supports .

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 366326] OFX direct download fails when OFX UID is expected by bank

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366326

--- Comment #3 from Jeff  ---
Mike: Yes, since Quicken already had a CLIENTUID for my accounts, and I had
read elsewhere on the web that institutions tend to limit the number of UID's
they accept per account (sometimes to one?), I set my KMM UID to what Quicken
was using.  I'm still unclear on where the UID came from - I believe Quicken
just "made it up" through some hash of the account name or something (if I'm
remembering correctly what I tried to decode from their documentation). And I'm
not sure if there's some extra transaction required with the bank the first
time you use a CLIENTUID. If there was, Quicken did it for me and/or told me
how to do it. I seem to recall doing something - maybe it was just deleting the
online setup in Quicken and re-establishing it when Chase changed their policy.
But I vaguely recall going to the bank website and doing something too.  Maybe
it was just reauthorizing OFX access after the policy change.

With some effort, I could make patch files. I'd need to back out all my other
changes, but just the CLIENTUID changes are pretty simple. But my KMM patch
just assumes that libofx supports the CLIENTUID (thus why I call it a hack).
Not sure what is the best way for KMM to know or figure out if it's supported
before trying to use it. (Originally I thought it could eventually just require
a newer version of libofx before compiling that in.)

I'll look into making patch files.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 366326] OFX direct download fails when OFX UID is expected by bank

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366326

Jeff  changed:

   What|Removed |Added

 CC||jeffjl@outlook.com

--- Comment #1 from Jeff  ---
I don't recall a patch to KMM that fixed this. AqBanking implements the
 and that is the workaround I remember.

The problem is that libofx does not implement .

I have modified my copy of libofx to implement the  and hacked my
copy of KMM to use it, and that works with my Chase accounts.  But I also made
a lot of other libofx changes to better support investment accounts.  About a
couple of weeks ago, I sent an email to the sourceforge libofx mailing list
with my patch and got no response. Not sure what to do next.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 365820] New: cannot build due to duplicate definitions for payeeidentifierloader when linking

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365820

Bug ID: 365820
   Summary: cannot build due to duplicate definitions for
payeeidentifierloader when linking
   Product: kmymoney4
   Version: 4.8.0
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kmymoney-de...@kde.org
  Reporter: jeffjl@outlook.com

When building on Windows/mingw, the link for kmymoney.exe fails as shown below.
I can get a build if I edit the generated
kmymoney\CMakeFiles\kmymoney.dir\link.txt file and remove the
"..\bin\libkmm_payeeidentifier_loader.a" reference and rebuild without
reconfiguring. Have the same problem with the 4.7 and 4.8 branches. Also had
this problem in building some of the test programs, but I just stopped building
the test programs rather than edit the link.txt files.


Linking CXX executable ..\bin\kmymoney.exe
..\bin\libkmm_payeeidentifier_loader.a(payeeidentifierloader.cpp.obj): In
function `ZN21payeeIdentifierLoader22translatedDelegateNameERK7QString':
q:/kmymoney/kmymoney/mymoney/payeeidentifier/payeeidentifierloader.cpp:128:
multiple definition of `payeeIdentifierLoader::translatedDelegateName(QString
const&)'
..\bin\libkmm_mymoney.dll.a(d000889.o):(.text+0x0): first defined here
..\bin\libkmm_payeeidentifier_loader.a(payeeidentifierloader.cpp.obj): In
function `ZN21payeeIdentifierLoader21createPayeeIdentifierERK7QString':
q:/kmymoney/kmymoney/mymoney/payeeidentifier/payeeidentifierloader.cpp:53:
multiple definition of `payeeIdentifierLoader::createPayeeIdentifier(QString
const&)'
..\bin\libkmm_mymoney.dll.a(d000888.o):(.text+0x0): first defined here
..\bin\libkmm_payeeidentifier_loader.a(payeeidentifierloader.cpp.obj): In
function
`ZN21payeeIdentifierLoader36createPayeeIdentifierFromSqlDatabaseE12QSqlDatabaseRK7QStringS3_':
q:/kmymoney/kmymoney/mymoney/payeeidentifier/payeeidentifierloader.cpp:80:
multiple definition of
`payeeIdentifierLoader::createPayeeIdentifierFromSqlDatabase(QSqlDatabase,
QString const&, QString const&)'
..\bin\libkmm_mymoney.dll.a(d000891.o):(.text+0x0): first defined here
..\bin\libkmm_payeeidentifier_loader.a(payeeidentifierloader.cpp.obj): In
function `ZN21payeeIdentifierLoader18availableDelegatesEv':
q:/kmymoney/kmymoney/mymoney/payeeidentifier/payeeidentifierloader.cpp:118:
multiple definition of `payeeIdentifierLoader::availableDelegates()'
..\bin\libkmm_mymoney.dll.a(d000885.o):(.text+0x0): first defined here
..\bin\libkmm_payeeidentifier_loader.a(payeeidentifierloader.cpp.obj): In
function `ZN21payeeIdentifierLoader18createItemDelegateERK7QStringP7QObject':
q:/kmymoney/kmymoney/mymoney/payeeidentifier/payeeidentifierloader.cpp:95:
multiple definition of `payeeIdentifierLoader::createItemDelegate(QString
const&, QObject*)'
..\bin\libkmm_mymoney.dll.a(d000886.o):(.text+0x0): first defined here
..\bin\libkmm_payeeidentifier_loader.a(payeeidentifierloader.cpp.obj): In
function `ZN21payeeIdentifierLoader19hasItemEditDelegateERK7QString':
q:/kmymoney/kmymoney/mymoney/payeeidentifier/payeeidentifierloader.cpp:110:
multiple definition of `payeeIdentifierLoader::hasItemEditDelegate(QString
const&)'
..\bin\libkmm_mymoney.dll.a(d000887.o):(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
kmymoney\CMakeFiles\kmymoney.dir\build.make:291: recipe for target
'bin/kmymoney.exe' failed
mingw32-make[2]: *** [bin/kmymoney.exe] Error 1
CMakeFiles\Makefile2:554: recipe for target
'kmymoney/CMakeFiles/kmymoney.dir/all' failed
mingw32-make[1]: *** [kmymoney/CMakeFiles/kmymoney.dir/all] Error 2
Makefile:145: recipe for target 'all' failed
-

Reproducible: Always

Steps to Reproduce:
1. configure - so the link.txt file is rebuilt
2. make

Actual Results:  
make fails

Expected Results:  
make succeeds

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351874

--- Comment #15 from Jeff  ---
With my testing, the combination described in comment #14 seems to work.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 362139] CSV Importer asks the same question twice during profile deletion

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362139

Jeff  changed:

   What|Removed |Added

 CC||jeffjl@outlook.com

--- Comment #12 from Jeff  ---
> I cannot find any real life situation where stockholder would pay money to 
> corporation under term dividend

When you are short the stock and the dividend is due, it is paid out of your
account. (You don't pay it to the corporation, you pay it to the stockholder
from whom you borrowed the stock.)  I'm not sure how this would be tagged in
the CSV / OFX data, but it could well be a "cash dividend" with a negative
value (i.e. a payment = deducted from your account). You can google "short
stock dividend payment" for an explanation of the process.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351874

--- Comment #13 from Jeff  ---
>  With your suggested change, to remove the sign reversal, when the 
> transaction imports, the result shows as a deposit of $8.77 (positive).  

In order for that 8.77 to properly become a payment instead of a deposit, I
have to restore the statement reader to its 6/28/2015 version as well as remove
the negative sign on the line in the QIF reader (and to make it all work, place
a negative sign on the "buy" case in the QIF importer). It then imports with a
warning triangle, but simply hitting "Edit" followed by the "Enter" fixes the
math and the warning goes away.  To remove the warning and have the whole thing
work would probably take some different change to the statement reader that I
have not pursued. (I'm guessing the 6/28/2015 statement reader has some
extraneous .abs() when it sets up the split and the transaction editor does
not, which is why the editor fixes it.)  

As I recall from my quick look, the current master branch version of the
statement reader makes assumptions about buys and sells and basically ignores
the signs on the incoming data. So you could change all the signs in the QIF
importer and the ledger results would not change.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351874

--- Comment #11 from Jeff  ---
> I wonder how you test if OFX imports are correct? Is your test based only on 
> fact that KMM doesn't show you warning signs in ledger?

This wasn't addressed to me, but I will chime in. I know OFX imports work
because I have 2 investment accounts that I trade in quite frequently (daily to
weekly), 2 more that I trade in fairly often (monthly), and 4 more that get
updates every few months. I know the imports are working because my stock and
cash balances in KMM match the balances at the brokers.

> Summarizing it: It didn't work for you in general case and corner case. Now 
> it works for you in general case but still not in corner case :)

I believe that is correct. But I didn't do extensive testing before I backed
your change out of my copy.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351874

--- Comment #9 from Jeff  ---
That line:

tr.m_amount = -amount;

is the one I changed in my patch to fix my problem for "sells".  Need remove
the negative sign.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351874

--- Comment #6 from Jeff  ---
Hi Łukasz,

There is still a problem with the QIF import with your change.  My test file
also tested the case where the commission was greater than the proceeds from
the sale (which can happen when trading options.)  Your fix changed a "sell"
trade that actually cost money into one that brought in money. The example in
my test file was the "sell" of the "NFLX Aug 18 2012 110.0 Call". The price is
0.02, times 100 shares = 2.00. The commission is 10.77.  So income of 2.00,
outgo of 10.77 makes the total -8.77 (as shown in the U and T values in the QIF
file).  The cash account should decrease by 8.77. Your change turned that into
a positive 8.77, and increased the cash account.  This is admittedly a corner
case, and I think I am the only KMM user that trades options because I have
made a bunch of other changes to the KMM code to support that.

So, to support my particular needs, I am going to undo your change in my local
copy and restore my QIF importer change (which I submitted to the review board
on Aug 15, 2015 but was never accepted). And still claim that the master branch
does not fix my problem.  (Though I hardly use QIF import anymore. I was using
it to transfer my data from Quicken to KMM. I do have one investment account
that doesn't support OFX and I use QIF for that one.)

And I know that without your change, my OFX imports have been working. I don't
have a quick and easy test for OFX import. But my review board submittal for
the QIF importer change says I made the QIF importer data look just like the
OFX importer data. Thus my concern in comment #3 about OFX testing with your
change.  I suspect OFX will work except for the case I explained in my first
paragraph. Which probably nobody but me cares about :-)

Jeff.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351874

--- Comment #3 from Jeff  ---
Hi Łukasz,

The git master branch does import my test file without any warnings.

I had patched my copy of mymoneyqifreader.cpp to fix my problem. I undid that
patch to test your fix.

I'm a little concerned about the change to mymoneystatementreader.cpp. I didn't
change it to fix my problem because the statement reader also has to handle csv
and OFX imports. You have verified the csv import. Have you verified OFX
imports?

Jeff.

-- 
You are receiving this mail because:
You are watching all bug changes.

[phonon-backend-gstreamer] [Bug 356527] Plasma Crash

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356527

--- Comment #1 from Jeff  ---
There at the end, I was having a total break down of KDE in Fedora 22.  So, I
wiped the drives and did a clean install to Fedora 23.  I'm not sure what the
problem was.  I think it was some data corruption.  It seemed to stem from
Akonadi.  From Gnome I couldn't access anything dependant upon MYSQL via
Akonadi.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 356527] New: Plasma Crash

[Jeff via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=356527

Bug ID: 356527
   Summary: Plasma Crash
   Product: plasmashell
   Version: 5.4.3
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: k...@davidedmundson.co.uk
  Reporter: jeffspl...@live.com
CC: bhus...@gmail.com, plasma-b...@kde.org

Application: plasmashell (5.4.3)

Qt Version: 5.5.1
Operating System: Linux 4.2.6-201.fc22.x86_64 x86_64
Distribution: "Fedora release 22 (Twenty Two)"

-- Information about the crash:
- What I was doing when the application crashed: I pretty much now just have to
boot into Plasma and it crashes.  I have also been having Firefox Crashing, but
not sure if that is related.

So, whenever I boot into Plasma, Plasma crashes.

The crash can be reproduced every time.

-- Backtrace:
Application: Plasma (plasmashell), signal: Bus error
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f5fbcd88900 (LWP 2490))]

Thread 8 (Thread 0x7f5f9cd68700 (LWP 2492)):
#0  0x7f5fb47432fd in poll () at /lib64/libc.so.6
#1  0x7f5fbabdb182 in _xcb_conn_wait () at /lib64/libxcb.so.1
#2  0x7f5fbabdcc77 in xcb_wait_for_event () at /lib64/libxcb.so.1
#3  0x7f5f9eceada9 in QXcbEventReader::run() () at /lib64/libQt5XcbQpa.so.5
#4  0x7f5fb53503ce in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#5  0x7f5fb33ee555 in start_thread () at /lib64/libpthread.so.0
#6  0x7f5fb474eb9d in clone () at /lib64/libc.so.6

Thread 7 (Thread 0x7f5f961d8700 (LWP 2512)):
#0  0x7f5fb558775d in postEventSourceCheck(_GSource*) () at
/lib64/libQt5Core.so.5
#1  0x7f5faf8ef801 in g_main_context_check () at /lib64/libglib-2.0.so.0
#2  0x7f5faf8efd60 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#3  0x7f5faf8efecc in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#4  0x7f5fb5587f0b in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/libQt5Core.so.5
#5  0x7f5fb552ef0a in
QEventLoop::exec(QFlags) () at
/lib64/libQt5Core.so.5
#6  0x7f5fb534b424 in QThread::exec() () at /lib64/libQt5Core.so.5
#7  0x7f5fb9669b45 in QQmlThreadPrivate::run() () at /lib64/libQt5Qml.so.5
#8  0x7f5fb53503ce in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#9  0x7f5fb33ee555 in start_thread () at /lib64/libpthread.so.0
#10 0x7f5fb474eb9d in clone () at /lib64/libc.so.6

Thread 6 (Thread 0x7f5f8b12f700 (LWP 2513)):
#0  0x7f5fb47432fd in poll () at /lib64/libc.so.6
#1  0x7f5faf8efdbc in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#2  0x7f5faf8efecc in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#3  0x7f5fb5587f0b in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/libQt5Core.so.5
#4  0x7f5fb552ef0a in
QEventLoop::exec(QFlags) () at
/lib64/libQt5Core.so.5
#5  0x7f5fb534b424 in QThread::exec() () at /lib64/libQt5Core.so.5
#6  0x7f5fb9669b45 in QQmlThreadPrivate::run() () at /lib64/libQt5Qml.so.5
#7  0x7f5fb53503ce in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#8  0x7f5fb33ee555 in start_thread () at /lib64/libpthread.so.0
#9  0x7f5fb474eb9d in clone () at /lib64/libc.so.6

Thread 5 (Thread 0x7f5f8949e700 (LWP 2516)):
#0  0x7f5faf8ecdf3 in g_source_iter_next () at /lib64/libglib-2.0.so.0
#1  0x7f5faf8ef2fb in g_main_context_prepare () at /lib64/libglib-2.0.so.0
#2  0x7f5faf8efceb in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#3  0x7f5faf8efecc in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#4  0x7f5fb5587f0b in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/libQt5Core.so.5
#5  0x7f5fb552ef0a in
QEventLoop::exec(QFlags) () at
/lib64/libQt5Core.so.5
#6  0x7f5fb534b424 in QThread::exec() () at /lib64/libQt5Core.so.5
#7  0x7f5fb9669b45 in QQmlThreadPrivate::run() () at /lib64/libQt5Qml.so.5
#8  0x7f5fb53503ce in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#9  0x7f5fb33ee555 in start_thread () at /lib64/libpthread.so.0
#10 0x7f5fb474eb9d in clone () at /lib64/libc.so.6

Thread 4 (Thread 0x7f5f839c0700 (LWP 2517)):
#0  0x7f5fb33f3540 in pthread_cond_wait@@GLIBC_2.3.2 () at
/lib64/libpthread.so.0
#1  0x7f5fbc4ac514 in QTWTF::TCMalloc_PageHeap::scavengerThread() () at
/lib64/libQt5Script.so.5
#2  0x7f5fbc4ac559 in  () at /lib64/libQt5Script.so.5
#3  0x7f5fb33ee555 in start_thread () at /lib64/libpthread.so.0
#4  0x7f5fb474eb9d in clone () at /lib64/libc.so.6

Thread 3 (Thread 0x7f5f80f23700 (LWP 2518)):
#0  0x7f5faf934ee4 in g_mutex_unlock () at /lib64/libglib-2.0.so.0
#1  0x7f5faf8efdb1 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#2  0x7f5faf8efecc in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#3