[digikam] [Bug 371530] Database query fails when adding face rectangle resulting in full freeze

[Simon via KDE Bugzilla]

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

--- Comment #1 from Simon  ---
Created attachment 101725
  --> https://bugs.kde.org/attachment.cgi?id=101725=edit
Relevant command line output.

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

[digikam] [Bug 371530] New: Database query fails when adding face rectangle resulting in full freeze

[Simon via KDE Bugzilla]

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

Bug ID: 371530
   Summary: Database query fails when adding face rectangle
resulting in full freeze
   Product: digikam
   Version: 5.2.0
  Platform: Debian testing
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Database-Mysql
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

I use digikam with an internal mysql database. I tried to manually add a face
tag in preview mode. I can select the add face tag button and draw a rectangle,
but upon releasing the cursor digikam freezes but the process does not crash. I
will attach the relevant output on the command line.

Reproducible: Always

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

[digikam] [Bug 357944] wrong encoded collection paths after upgrade from digikam v4.x

[Simon via KDE Bugzilla]

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

--- Comment #10 from Simon  ---
Hi Antonio

Thanks for working on this.
I do not see how this addresses the issue of encoded paths ("%2F" instead of
"/") in the database, are you sure this is fixed with your changes?

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

[digikam] [Bug 369345] In tagging apply to all versions fails

[Simon via KDE Bugzilla]

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

--- Comment #4 from Simon  ---
Hi Maik,

Thanks for fixing this.
So there is currently no way to tag, flag, ... grouped images?
This is kind of a big deal, as grouping camera jpgs and raw images is an
essential feature for me, but tags only applying to the first image in
the stack makes it almost useless, as you cannot filter images "in the
background" (they have no tags). Intuitively I would have expected that
tags/... are applied to all grouped images when they are grouped or
collapsed in tree view and only to the single selected image when
"ungrouped". Is this behaviour or an additional button like "apply to
entire group" a possibility?

On 11/10/16 22:59, Maik Qualmann via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=369345
>
> Maik Qualmann  changed:
>
>What|Removed |Added
> 
>  CC||metzping...@gmail.com
>
> --- Comment #3 from Maik Qualmann  ---
> Note: "Apply to all versions" is not for grouped images, only for versioned
> images.
>
> Maik
>

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

[digikam] [Bug 369345] In tagging apply to all versions fails

[Simon via KDE Bugzilla]

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

--- Comment #1 from Simon  ---
I can still reproduce this with the current master (afebcb2).
Can anyone else reproduce this error?

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

[digikam] [Bug 369345] In tagging apply to all versions fails

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

Version|5.1.0   |5.2.0

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

[digikam] [Bug 369345] New: In tagging apply to all versions fails

[Simon via KDE Bugzilla]

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

Bug ID: 369345
   Summary: In tagging apply to all versions fails
   Product: digikam
   Version: 5.1.0
  Platform: Debian testing
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Tags
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

The title says it all: Clicking on the button "Apply to all versions" after
changing tags does not do anything. In the console the following error shows
up:

QObject::connect: Cannot connect (null)::progressItemCompleted(ProgressItem*)
to Digikam::FileActionProgressItemContainer::signalWrittingDone()

This is the same whether the marked item is a grouped item or a single picture.

Reproducible: Always

Steps to Reproduce:
1. Change tags.
2. Clich "Apply to all versions"

Actual Results:  
Nothing happens (except console output).

Expected Results:  
Tags are applied to the marked item and if appropriate to all other items in
the group.

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

[kmail2] [Bug 364967] Kmail message list does not remember rightmost column width

[Kay Simon via KDE Bugzilla]

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

Kay Simon  changed:

   What|Removed |Added

 CC||kayingosi...@gmail.com

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

[gwenview] [Bug 362474] Copy To/Move To does not remember path any more

[Simon via KDE Bugzilla]

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

--- Comment #7 from Simon  ---
The issue was introduced when porting to QFileDialog:

https://github.com/KDE/gwenview/commit/6cd4688f7b17ede3e2c01e9b97207e0c1400325a

Re-using the pseudo URL "kfiledialog:///" apparently not
supported in QFileDialog.

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

[gwenview] [Bug 362474] Copy To/Move To does not remember path any more

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||simon.th...@gmx.de

--- Comment #6 from Simon  ---
If anyone cares, here is a workaround/hack that stores the path in a static
variable.
https://github.com/thielsn/gwenview/commit/2ae15844267de360c210ed15a41d7b315448b49b

For a real fix the path should probably be stored in QSettings.

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

[digikam] [Bug 357944] wrong encoded collection paths after upgrade from digikam v4.x

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||freisi...@gmail.com

--- Comment #7 from Simon  ---
This is is still a problem in 5.1.0. See following bug report to debian:

Package: digikam
Version: 4:5.1.0-2
Severity: important
Tags: patch

--- Please enter the report below this line. ---
Just upgraded from latest Debian Digikam version 4 (with database version 6). 
I set the path of my old database on first start and when Digikam opened there 
where no more albums in the interface.

After restoration of my old database and various tests, I discover that my 
album root path where "urlencoded" in previous version with all '/' replace by 
'%2F'. Whit such path, Digikam 5.1 does not recognize album root and remove 
all metadata from the database on albums refreshing.

To correct this, I had to edit with sqlitebrowser the file digikam4.db and in 
the table AlbumRoots, replace all occurence of '%2F' bay '/' in the field 
identifier. Then Digikam recognize the path an show all my albums, photo and 
associated metadata.

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.6.0-1-amd64

Debian Release: stretch/sid
  500 unstablehttp.debian.net 
  500 testing http.debian.net 
  500 syncthing   apt.syncthing.net 
  500 stable  security.debian.org 
  500 stable  http.debian.net 
  101 experimentalhttp.debian.net 

--- Package information. ---
Depends(Version) | Installed
-+-
digikam-private-libs   (= 4:5.1.0-2) | 4:5.1.0-2
libc6  (>= 2.14) | 
libgcc1   (>= 1:3.0) | 
libkf5configcore5(>= 4.97.0) | 
libkf5coreaddons5   (>= 4.100.0) | 
libkf5filemetadata3 (>= 5.1.0.1) | 
libkf5i18n5  (>= 4.97.0) | 
libkf5xmlgui5(>= 4.96.0) | 
libqt5core5a (>= 5.6.0~beta) | 
libqt5gui5(>= 5.4.0) | 
libqt5sql5(>= 5.4.0) | 
libqt5widgets5(>= 5.4.0) | 
libstdc++6  (>= 4.9) | 
perl:any | 
libqt5sql5-sqlite| 
digikam-data   (= 4:5.1.0-2) | 


Recommends (Version) | Installed
-+-===
www-browser  | 
ffmpegthumbs | 4:16.04.2-1
 OR mplayerthumbs| 4:15.08.3-2


Suggests(Version) | Installed
=-+-===
digikam-doc   | 4:5.1.0-2
systemsettings| 4:5.7.0-1

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

[digikam] [Bug 366740] New: Remove dependency on libkexiv

[Simon via KDE Bugzilla]

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

Bug ID: 366740
   Summary: Remove dependency on libkexiv
   Product: digikam
   Version: 5.1.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: libkipi
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

This is the last component of digikam, that still depends on libkexiv instead
of libexiv. At least according to README and debian packages pull it as
dependency. If this is just an error in the README, then great, otherwise are
there plans to remove this dependency?

Reproducible: Always

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

[digikam] [Bug 366567] New: Allow choosing several duplicates

[Simon via KDE Bugzilla]

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

Bug ID: 366567
   Summary: Allow choosing several duplicates
   Product: digikam
   Version: 5.1.0
  Platform: Debian testing
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: Searches-Fuzzy
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

Currently in the duplicate part of fuzzy search I can only select one group of
duplicates at a time. This is ok if you have just a few duplicates. However I
have lots of duplicates and want to sort/remove them. For this case the current
state is useless, I would have to go through hundreds of duplicates one by one.
If I could choose all/several of them I could then apply tags and use filters
on all of the duplicates. Thus I could choose a subset of all picture that have
a duplicate and remove them.

Reproducible: Always

Steps to Reproduce:
1. Search for duplicates
2. Try to select multiple items

Actual Results:  
Only one selection possible.

Expected Results:  
Select as many duplicate groups as you want.

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

[digikam] [Bug 267131] SETUP : digiKam config and data cannot be moved, absolute paths embedded in database and digikamrc

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||freisi...@gmail.com

--- Comment #16 from Simon  ---
Yes this is still the same. There is no way to move a collection. The location
of a collection is stored in the database, so it has to be manually adjusted in
the database. Currently digikam sees that all files vanished, so deletes them
in database and the only thing you can do is creating a new collection at the
new location, obviously losing all information stored in the database. A
solution within the current framework would be a function within digikam to
move a collection.
In my opinion much better would be to take a different approach at storing
collection locations: Keep them separate from the database either in the
existing or a new configuration file. That means all the paths in the database
should be relative to root and the path to root is stored in this configuration
file. This allows for easily changing the location of a collection and even for
two digikam instances to share a database (not simultaneously, of course, but
if that is a worry, that should be solved by locking). A use case would be if
data and database were shared over a network and both could be accessed on
different computers.

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

[digikam] [Bug 364258] Upgrade to 5.0 (beta6) :KDE4 application configuration rc files ignored [patch]

[Simon via KDE Bugzilla]

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

--- Comment #20 from Simon  ---
Hi Gilles,

Do you plan to include this or something similar before the 5.1.0 release?
This is a major reason why digikam 5 is still in the experimental 
repository on debian. The "compatibility break" without any notice is 
considered a major issue for the user.

Cheers,
Simon

On 04/08/16 12:01, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=364258
>
> caulier.gil...@gmail.com changed:
>
> What|Removed |Added
> 
>  Summary|Upgrade to 5.0  (beta6) |Upgrade to 5.0  (beta6)
> |:KDE4 application   |:KDE4 application
> |configuration rc files  |configuration rc files
> |ignored |ignored [patch]
>
> --- Comment #19 from caulier.gil...@gmail.com ---
> Thanks Simon for your patch.
>
> Gilles Caulier
>

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

[digikam] [Bug 364258] Upgrade to 5.0 (beta6) :KDE4 application configuration rc files ignored

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||freisi...@gmail.com

--- Comment #18 from Simon  ---
Created attachment 100439
  --> https://bugs.kde.org/attachment.cgi?id=100439=edit
Add information about configuration transition to welcome screen.

I agree that this is a very important point for the user. Of course ideally the
transition problems would be removed, but as always: This is open-source, if
you want it done, do it.
I attached a patch that adds information about the (non-)migration of the
configuration to the welcome screen.

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

[digikam] [Bug 366219] Setting up internal mysql database fails [patch]

[Simon via KDE Bugzilla]

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

--- Comment #9 from Simon  ---
Created attachment 100382
  --> https://bugs.kde.org/attachment.cgi?id=100382=edit
minor patch on top of maiks commits

Thanks Maik for going over it and improve it. I have some minor points to add
(additional.patch):
 - Aren't the i18n calls in the arguments to processErrorLog redundant as this
argument is later on passed to i18n again?
- One minor improvement over my own patch: In createMysqlFiles only create
initCmdArgs if really necessary.

The following questions are purely out of curiosity/my education, so feel free
to ignore it, but I would appreciate a short answer:
- You removed my struct workaround to make the private variables const.
Obviously this is because my workaround was ugly and cumbersome. Is there a
better way to make them const or is this in any case a useless thing to do?
- Why is the msg argument to processErrorLog declared as a reference?

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

[digikam] [Bug 366219] Setting up internal mysql database fails

[Simon via KDE Bugzilla]

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

--- Comment #2 from Simon  ---
Created attachment 100359
  --> https://bugs.kde.org/attachment.cgi?id=100359=edit
Patch of cpp file after refactor

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

[digikam] [Bug 366219] Setting up internal mysql database fails

[Simon via KDE Bugzilla]

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

--- Comment #1 from Simon  ---
Created attachment 100358
  --> https://bugs.kde.org/attachment.cgi?id=100358=edit
Patch of header file after refactor

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

[digikam] [Bug 366219] New: Setting up internal mysql database fails

[Simon via KDE Bugzilla]

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

Bug ID: 366219
   Summary: Setting up internal mysql database fails
   Product: digikam
   Version: 5.0.0
  Platform: Other
OS: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Database-Setup
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

Details

While trying to setup digiKam with internal mysql database from scratch (no
migration), I got the following error:
digikam.databaseserver: Database initializer:  "mysql_install_db"
("--datadir=/home/simon/Programme/AppDaten/digikam5/.mysql.digikam/db_data")
digikam.databaseserver: "WARNING: Could not write to config file
/usr/my.cnf: Permission denied\n\nFATAL ERROR: Could not chown directory
/home/simon/Programme/AppDaten/digikam5/.mysql.digikam/db_data\n"
digikam.databaseserver: "Could not start database initializer.\nExecutable:
mysql_install_db\nArguments:
--datadir=/home/simon/Programme/AppDaten/digikam5/.mysql.digikam/db_data\nProcess
error: Unknown error"
digikam.databaseserver: Cannot start internal database server

I investigated the error in databaseserver.cpp/h. I found the error in the
arguments to mysql_install_db which missed a "--defaults-file" argument.
However new error turned up after. The error/debug messages were not conclusive
and the consistet more or less of one very long function riddled with return
statements. So I refactored databaseserver.cpp.

I am no c++ dev, so I did quite a bit of learning while writing the code.
Therefore the result is certainly not perfect. But it runs without error, gives
more information on errors and is in my opinion generally cleaner and more
readable.

I will attach patches, but the one for the cpp file is more or less useless, as
almost everything is marked as change due to the restructuring.

More detailed information can be derived from my github repository, i.e. the
commit messages in the tree intdb_init-redone
(https://github.com/imsodin/digiKam/commits/intdb_init-redone). Most of the
changes happened in "Split startMYSQLDatabaseProcess into smaller functions".
The branch is still compatible with master (at the time of writing), I will try
to keep an up-to-date version with master in the branch
"intdb_init-redone-current".
Please test it and I hope you have time to look over the code as well. Any
feedback is appreciated.


Reproducible: Always

Steps to Reproduce:
1. Start digiKam from scratch (no digikamrc, no database, no configs)
2. choose internal mysql database

Actual Results:  
fails to initialise database (see error in Details)

Expected Results:  
Initialise new database (which works with the patch)

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

[digikam] [Bug 366202] New: Bootstrap script does not test for QT5 mysql library

[Simon via KDE Bugzilla]

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

Bug ID: 366202
   Summary: Bootstrap script does not test for QT5 mysql library
   Product: digikam
   Version: 5.1.0
  Platform: Debian testing
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: setup
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

I am trying to setup digiKam with internal Mysql database. I am running into
several bugs and am currently fixing them (more on this later). The following
error occured during initialisation:
QSqlDatabase: QMYSQL driver not loaded
QSqlDatabase: available drivers: QSQLITE
digikam.databaseserver: Invalid database object during database server
startup
I checked and I was missing the file libqsqlmysql.so. On debian this file is
included in package "libqt5sql5-mysql" and located in:
/usr/lib/x86_64-linux-gnu/qt5/plugins/sqldrivers/
The bootstrap script did not report an error or warning (internal mysql was
obviously enabled). but it should.

Reproducible: Always

Steps to Reproduce:
1. Run bootstrap.linux without having libqsqlmysql.so installed


Actual Results:  
Script reports success.

Expected Results:  
Script should report failure and state that it did not find the necessary
libraries.

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

[digikam] [Bug 297922] THUMBDB : different database locations for thumbnails

[Simon via KDE Bugzilla]

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

--- Comment #7 from Simon  ---
The workaround mentioned in Comment 3 to set this manually in the config file
does not work in current digiKam version (5.1.0 devel). See duplicate bug:
https://bugs.kde.org/show_bug.cgi?id=366092
Digikam automatically resets a different thumbnail database location to main
database location.

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

[digikam] [Bug 366124] [Patch] Corrected spelling in first run widgets

[Simon via KDE Bugzilla]

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

--- Comment #1 from Simon  ---
Created attachment 100310
  --> https://bugs.kde.org/attachment.cgi?id=100310=edit
This patch corrects spelling/formatting in the first run widgets.

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

[digikam] [Bug 366124] New: [Patch] Corrected spelling in first run widgets

[Simon via KDE Bugzilla]

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

Bug ID: 366124
   Summary: [Patch] Corrected spelling in first run widgets
   Product: digikam
   Version: 5.1.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: Usability
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

I corrected some spelling/formatting in the UI text of the first run widgets.
The patch is attached.

Reproducible: Always

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

[digikam] [Bug 366122] New: Next button not activatable via Alt+N in widget

[Simon via KDE Bugzilla]

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

Bug ID: 366122
   Summary: Next button not activatable via Alt+N in widget
   Product: digikam
   Version: 5.1.0
  Platform: Debian testing
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: Usability
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

In the first run widget all buttons on the bottom except "Next" are activatable
by pressing Alt+Key, where key is the underlined letter.

Reproducible: Always

Steps to Reproduce:
1. Start digikam from scratch (no database, no digikamrc)
2. Press Alt+N

Actual Results:  
Nothing happens

Expected Results:  
Next button is pressed and next menu window appears.

digikam commit hash: 19446b5
Qt version: 5.6.1

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

[digikam] [Bug 366036] Sidecar file is not written when image is symlink to write-protected directory

[Simon via KDE Bugzilla]

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

--- Comment #13 from Simon  ---
The only "rescan metadata" option I find is "read metadata from file", 
but I do not currently write any metadata to file with digiKam, I store 
tags only internally.
So the behavior is that digiKam reads and writes metadata from/to just 
one file (the original) but keeps separate database entries? If this is 
the case, that would be very inconsistent. Either Thomas' approach:
 Keep separate metadata for every file, thus using sidecar file 
along symlink
or
 Only read/write to the original and one database entry for a file 
and all symlinks pointing to it
need to be used.

On 26/07/16 07:50, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=366036
>
> --- Comment #12 from caulier.gil...@gmail.com ---
> You must to force digiKam to rescan metadata to resync database contents.
>
> Try buttons on the bottom of Captions/Tags sidebar tab.
>
> Other way is to use Maintenance tool.
>
> Gilles Caulier
>

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

[digikam] [Bug 366036] Sidecar file is not written when image is symlink to write-protected directory

[Simon via KDE Bugzilla]

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

--- Comment #11 from Simon  ---
So I just opened digikam for the first time after compiling it with 
Maik's commit. It looks like digikam now detects the symlinks as 
duplicates. This output was printed repeatedly while scanning for new items:

 digikam.database: Recognized "*somefile*" as identical to item 56019

For testing I looked up which file has ID 56019 and changed a tag on it. 
This change is then not visible in *somefile*. The same is true the 
other way round. So digikam seems to recognize that these are the same 
items but it does not do anything about it.

On 25/07/16 20:18, Thomas Reifenberger via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=366036
>
> --- Comment #10 from Thomas Reifenberger  ---
> Just FYI: At least on my machine (up-to-date ArchLinux), the darktable 
> versions
> 1.6.7 up to 2.0.5 handle the scenario described above as expected (respect
> symlinks, create/update sidecar file next to symlink).
>
> (In reply to Maik Qualmann from comment #8)
>> Also Darktable created not a sidecar file and prints a exiv2 exception.
>>
>> Maik

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

[digikam] [Bug 366036] Sidecar file is not written when image is symlink to write-protected directory

[Simon via KDE Bugzilla]

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

--- Comment #9 from Simon  ---
Maik: So what is the behaviour after your commit: Does digikam handle 
symlinked images like unique images (so unique database entry, e.g. 
tags) or just as pointers to the real image (so all symlinks pointing to 
the same file have the same database information)? Thanks for clarification.


On 24/07/16 22:05, Maik Qualmann via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=366036
>
> --- Comment #8 from Maik Qualmann  ---
> Also Darktable created not a sidecar file and prints a exiv2 exception.
>
> Maik
>

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

[digikam] [Bug 366036] Sidecar file is not written when image is symlink to write-protected directory

[Simon via KDE Bugzilla]

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

--- Comment #3 from Simon  ---
Regarding the behaviour: Digikam does treat symlinks like "real files", 
e.g. every symlink has its own set of tags in the database. In my 
opinion it would make more sense to treat them as links internally too. 
So any operation on the link in the database is actually done on the 
original (operations on the image itself are anyway always on the original).


On 24/07/16 20:44, Maik Qualmann via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=366036
>
> Maik Qualmann  changed:
>
> What|Removed |Added
> 
>   CC||metzping...@gmail.com
>
> --- Comment #1 from Maik Qualmann  ---
> I think the sidecar should be stored in the image folder. In this case, the
> "subdir" folder. And the "subdir" must be writable. I think the behavior of
> digikam4.x was wrong. Gilles, what do you think?
>
> Maik
>

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

[digikam] [Bug 364793] wrong icon useage

[Simon via KDE Bugzilla]

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

--- Comment #7 from Simon <freisi...@gmail.com> ---
Sorry about the multiple mails, but while I am at it there are also some 
colored icons in the menus, some of which may also be intentianally colored:
  - Browse/Quit
  - Album
- Rename
- Delete Album
  - Item/Open With Default Application
  - Import
- Cameras
- Import from Scanner...
- Import from Google Photos/Picasaweb
  - Export/ almost all of them
  - Settings/Configure Notifications
  - Help
- Supported RAW Cameras
- Kipi Plugins Handbook
- About digiKam

On 20/07/16 11:12, Simon via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=364793
>
> --- Comment #6 from Simon <freisi...@gmail.com> ---
> Hi Andreas,
> There are other icons that stand out as not monochrome, however less
> present and much less intrusive. Still making them monochrome too would
> only be consistent. Are there already monochrome pendants to the
> following icons?
> In the right sidebar:
>- in Filters: MIME Type Filtering
>- in Captions/Tags: rider Information: Rights
>- in Properties: Item Properties and Photograph Properties
> In the left sidebar:
>- in Dates: icons of subentries of years
>
> On 20/07/16 11:03, andreas via KDE Bugzilla wrote:
>> https://bugs.kde.org/show_bug.cgi?id=364793
>>
>> --- Comment #5 from andreas <kain...@gmail.com> ---
>> Hi, yes global would be the best joice cause you use the icon for actions.
>> action icons are needed in 22px by default and 16px if the user like. I also
>> play around with 32px size but nobody care about 32px action icons. so change
>> to global
>>
>> thanks
>> Andreas
>>

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

[digikam] [Bug 364793] wrong icon useage

[Simon via KDE Bugzilla]

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

--- Comment #6 from Simon  ---
Hi Andreas,
There are other icons that stand out as not monochrome, however less 
present and much less intrusive. Still making them monochrome too would 
only be consistent. Are there already monochrome pendants to the 
following icons?
In the right sidebar:
  - in Filters: MIME Type Filtering
  - in Captions/Tags: rider Information: Rights
  - in Properties: Item Properties and Photograph Properties
In the left sidebar:
  - in Dates: icons of subentries of years

On 20/07/16 11:03, andreas via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=364793
>
> --- Comment #5 from andreas  ---
> Hi, yes global would be the best joice cause you use the icon for actions.
> action icons are needed in 22px by default and 16px if the user like. I also
> play around with 32px size but nobody care about 32px action icons. so change
> to global
>
> thanks
> Andreas
>

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

[digikam] [Bug 364793] wrong icon useage

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||freisi...@gmail.com

--- Comment #4 from Simon  ---
I noticed that the map icon still is the only icon not in monochrome and really
stands out. I guess the right icon instead of "internet-web-browser" is
"globe". It is essentially the same item as is in use currently, but in
monochrome. There is also "map-globe", but in my opinion it is ugly. "globe"
only exists in sizes 16 and 22, but as it is just a symlink to "folder-html" 
which exists in all sizes this should be easily added if necessary.

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

[zanshin] [Bug 365826] New: Some tasks from caldav calendar not shown

[Simon via KDE Bugzilla]

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

Bug ID: 365826
   Summary: Some tasks from caldav calendar not shown
   Product: zanshin
   Version: unspecified
  Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: general
  Assignee: er...@kde.org
  Reporter: b...@700c.org
CC: mbe...@ipsquad.net

I keep my tasks in a owncloud 9 caldav calendar. I currently have 39 tasks but
only 22 are shown in Zanshin

Reproducible: Always

Steps to Reproduce:
1. Connect Zanshin to a Caldav calendar
2. Use it for some months, using multiple machines to edit tasks
3. Notice that some tasks aren't

Actual Results:  
Tasks missing

Expected Results:  
All tasks shown

I see all tasks on my phone with the android tasks app.

Marked major as I have to trust zanshin to show me all the tasks. I don't enter
all the tasks, so I might not realise that something important is not being
shown.

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

[plasmashell] [Bug 337079] sddm theme doesn't focus password field

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||simon.th...@gmx.de

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

[plasmashell] [Bug 364234] New: plasma crashes and then reloads

[Simon via KDE Bugzilla]

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

Bug ID: 364234
   Summary: plasma crashes and then reloads
   Product: plasmashell
   Version: 5.6.4
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: k...@davidedmundson.co.uk
  Reporter: si...@beartech.co.uk
CC: bhus...@gmail.com, plasma-b...@kde.org

Application: plasmashell (5.6.4)

Qt Version: 5.6.0
Frameworks Version: 5.22.0
Operating System: Linux 4.5.6-200.fc23.x86_64 x86_64
Distribution (Platform): Fedora RPMs

-- Information about the crash:
Boot-up, login, bar shows notification & packages to be updated icons. clicked
on latter, then crash

-- Backtrace:
Application: Plasma (plasmashell), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f0642628940 (LWP 2026))]

Thread 9 (Thread 0x7f0638f40700 (LWP 2034)):
#0  0x7f06510eeb1d in poll () at /lib64/libc.so.6
#1  0x7f0656296272 in _xcb_conn_wait () at /lib64/libxcb.so.1
#2  0x7f0656297ee7 in xcb_wait_for_event () at /lib64/libxcb.so.1
#3  0x7f063b193349 in QXcbEventReader::run() () at /lib64/libQt5XcbQpa.so.5
#4  0x7f0651d00d48 in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#5  0x7f065042b61a in start_thread () at /lib64/libpthread.so.0
#6  0x7f06510fa59d in clone () at /lib64/libc.so.6

Thread 8 (Thread 0x7f0633913700 (LWP 2035)):
#0  0x7f064c9f4794 in g_mutex_unlock () at /lib64/libglib-2.0.so.0
#1  0x7f064c9af720 in g_main_context_prepare () at /lib64/libglib-2.0.so.0
#2  0x7f064c9b00bb in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#3  0x7f064c9b029c in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#4  0x7f0651f29a4b in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/libQt5Core.so.5
#5  0x7f0651ed24ca in
QEventLoop::exec(QFlags) () at
/lib64/libQt5Core.so.5
#6  0x7f0651cfbf34 in QThread::exec() () at /lib64/libQt5Core.so.5
#7  0x7f06526c14b5 in QDBusConnectionManager::run() () at
/lib64/libQt5DBus.so.5
#8  0x7f0651d00d48 in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#9  0x7f065042b61a in start_thread () at /lib64/libpthread.so.0
#10 0x7f06510fa59d in clone () at /lib64/libc.so.6

Thread 7 (Thread 0x7f06320d3700 (LWP 2048)):
#0  0x7f064c9b010a in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#1  0x7f064c9b029c in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#2  0x7f0651f29a4b in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/libQt5Core.so.5
#3  0x7f0651ed24ca in
QEventLoop::exec(QFlags) () at
/lib64/libQt5Core.so.5
#4  0x7f0651cfbf34 in QThread::exec() () at /lib64/libQt5Core.so.5
#5  0x7f0655116985 in QQmlThreadPrivate::run() () at /lib64/libQt5Qml.so.5
#6  0x7f0651d00d48 in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#7  0x7f065042b61a in start_thread () at /lib64/libpthread.so.0
#8  0x7f06510fa59d in clone () at /lib64/libc.so.6

Thread 6 (Thread 0x7f0623fff700 (LWP 2066)):
#0  0x7f0650430b20 in pthread_cond_wait@@GLIBC_2.3.2 () at
/lib64/libpthread.so.0
#1  0x7f062b9a2fc3 in radeon_drm_cs_emit_ioctl () at
/usr/lib64/dri/r300_dri.so
#2  0x7f062b9a2717 in impl_thrd_routine () at /usr/lib64/dri/r300_dri.so
#3  0x7f065042b61a in start_thread () at /lib64/libpthread.so.0
#4  0x7f06510fa59d in clone () at /lib64/libc.so.6

Thread 5 (Thread 0x7f062258c700 (LWP 2071)):
#0  0x7f064c9f4794 in g_mutex_unlock () at /lib64/libglib-2.0.so.0
#1  0x7f064c9afb5a in g_main_context_check () at /lib64/libglib-2.0.so.0
#2  0x7f064c9b0130 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#3  0x7f064c9b029c in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#4  0x7f0651f29a4b in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/libQt5Core.so.5
#5  0x7f0651ed24ca in
QEventLoop::exec(QFlags) () at
/lib64/libQt5Core.so.5
#6  0x7f0651cfbf34 in QThread::exec() () at /lib64/libQt5Core.so.5
#7  0x7f0655116985 in QQmlThreadPrivate::run() () at /lib64/libQt5Qml.so.5
#8  0x7f0651d00d48 in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#9  0x7f065042b61a in start_thread () at /lib64/libpthread.so.0
#10 0x7f06510fa59d in clone () at /lib64/libc.so.6

Thread 4 (Thread 0x7f0620b92700 (LWP 2084)):
#0  0x7f0651cffd1e in QThreadData::current(bool) () at
/lib64/libQt5Core.so.5
#1  0x7f0651f290aa in postEventSourcePrepare(_GSource*, int*) () at
/lib64/libQt5Core.so.5
#2  0x7f064c9af72d in g_main_context_prepare () at /lib64/libglib-2.0.so.0
#3  0x7f064c9b00bb in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#4  0x7f064c9b029c in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#5  0x7f0651f29a4b in

[kamoso] [Bug 356133] crash when starting - segmentation fault

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||s.sueu...@gmail.com

--- Comment #16 from Simon  ---
On Archlinux:
$sudo pacman -S gst-plugins-bad

On Ubuntu (in Mint and Debian the package name+ installation should be pretty
much the same/similar):
$sudo apt-get install gstreamer0.10-plugins-bad 

On Fedora (not sure which one of these or maybe both):
$dnf install gstreamer-plugins-bad-free 
$dnf install gstreamer1-plugins-bad-free 

That should fix the not working kamoso.

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

[digikam] [Bug 363638] bootstrap does not detect libgphoto2

[Simon via KDE Bugzilla]

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

--- Comment #14 from Simon  ---
Just for my own education, so only answer if you have time:
I have seen that you removed the return() calls in the else parts. My 
reason to use them was, that any further evaluation becomes useless (it 
already failed to find an essential part). It would be great if you 
could tell me the reason for not using return calls there.

On 03/06/16 06:32, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=363638
>
> --- Comment #13 from caulier.gil...@gmail.com ---
> Git commit 401f077455ff1b4537262880b63458cac200c9c9 by Gilles Caulier.
> Committed on 03/06/2016 at 04:30.
> Pushed by cgilles into branch 'master'.
>
> apply patch #99332 to polish gphoto2 detection
>
> M  +30   -9cmake/modules/FindGphoto2.cmake
>
> http://commits.kde.org/digikam/401f077455ff1b4537262880b63458cac200c9c9
>

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

[digikam] [Bug 363638] bootstrap does not detect libgphoto2

[Simon via KDE Bugzilla]

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

--- Comment #12 from Simon  ---
Created attachment 99332
  --> https://bugs.kde.org/attachment.cgi?id=99332=edit
remove typos from FIndGphoto2.cmake and make it more verbose

I finally resolved this. The actual problem is that the debian package has the
gphoto2-config executable in a dir outside of PATH. While searching for this
cause I made updates to FIndGphoto2.cmake. There were variable names like
"GHOTO..." and if it did not find the executables or the libraries there was no
warning and the value FALSE was not assigned to GPHOTO2_FOUND.  So I added
warnings plus this assignment. I had no idea about cmake before, so this might
be not the way one does usually do this, but I hope its fine and can help.

Bug report is filed against the debian package regarding the mentioned problem.
Thanks for the assistance.

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

[digikam] [Bug 363638] bootstrap does not detect libgphoto2

[Simon via KDE Bugzilla]

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

--- Comment #10 from Simon  ---
Now there is this additional part about libgphoto:
-- Found Lqr-1: 
/usr/include/lqr-1;/usr/include/glib-2.0;/usr/lib/x86_64-linux-gnu/glib-2.0/include
 

-- libgphoto2 found:
-- Checking for module 'lensfun'
--   Found lensfun, version 0.3.2.0
-- Found LensFun: /usr/include/lensfun (found version "0.3.2.0")
-- liblensfun: Found version 0.3.2.0 (required: 0.2.6.0)
The whole output is on http://pastebin.com/2QnNDJjr

On 02/06/16 16:15, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=363638
>
> --- Comment #9 from caulier.gil...@gmail.com ---
> there is no configuration option to set .
>
> With last commit i print more debug statement about Gphoto2 detection.
>
> Gilles Caulier
>

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

[digikam] [Bug 363638] bootstrap does not detect libgphoto2

[Simon via KDE Bugzilla]

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

--- Comment #7 from Simon  ---
I always remove the build dir before rerunning the boostrap script and I 
know have made sure to run it on an entirely clean git clone. I removed 
the translation checkout from my custom bootstrap script, so know the 
only difference (certified by diff) to "bootstrap.linux" is
 >   -DDIGIKAMSC_COMPILE_LIBKIPI=ON \
 >   -DDIGIKAMSC_COMPILE_LIBKSANE=ON \
Do I need to set anything else such that these statements are visible?


On 02/06/16 15:36, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=363638
>
> --- Comment #6 from caulier.gil...@gmail.com ---
> You have no libgphoto2 detection in cmake statements. This want mean that 
> camek
> cache is not cleaned.
>
> remove build sub dir and restart bootstrap.
>
> Note : your bootstrap script is an older one (few hours i think), because it
> checkout translations. This must be disabled.
>
> Gilles Caulier
>

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

[digikam] [Bug 363638] bootstrap does not detect libgphoto2

[Simon via KDE Bugzilla]

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

--- Comment #5 from Simon  ---
I do not see anything related to libusb and still the same for 
libgphoto. I am running the boostrap script on softwarecomp commit 
"d30542149650693a58b355aab944fea4e7be6e09" and core commit 
"e74ea61a3177d964474a04dc1460c1500811bec6". The full output of the 
bootstrap can be found on http://pastebin.com/RtgXyHsC

On 02/06/16 09:01, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=363638
>
> caulier.gil...@gmail.com changed:
>
> What|Removed |Added
> 
>   Resolution|--- |FIXED
>   Status|UNCONFIRMED |RESOLVED
>
> --- Comment #4 from caulier.gil...@gmail.com ---
> It must miss libusb1. This is required to prevent conflict with opencv. See 
> bug
> #268267 for details.
>
> In your configuration trace you must see something like that :
> ...
> -- Found gphoto2: -L/usr/lib64 -lgphoto2_port;-L/usr/lib64 -lgphoto2
> -lgphoto2_port -lm
> -- Found LibUSB1: /usr/lib64/libusb-1.0.so
> -- LibUSB1_FOUND= TRUE
> -- LibUSB1_INCLUDE_DIRS = /usr/include/libusb-1.0
> -- LibUSB1_LIBRARIES= /usr/lib64/libusb-1.0.so
> CMake Warning at core/CMakeLists.txt:351 (message):
>libgphoto2 is found but libusb1 cannot be found on your system.
>libgphoto2 support will be disabled.
> ...
>
> Gilles Caulier
>

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

[digikam] [Bug 363638] bootstrap does not detect libgphoto2

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #2 from Simon  ---
With commit f1f247f1cc71e948c377ec7d1daa1389728fe88c I still get the following
output:

--  libgphoto2 found. NO  (optional)
--  digiKam will be compiled without GPhoto2 camera drivers support.
--  Please install the libgphoto2 (version >= 2.4.0) development package.
-- 

I do and did have libusb 1.0.20 and libgphoto 2.5.10 both with -dev packages
installed.

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

[muon] [Bug 363695] Segmentation fault after startup of muon updater

[Laurent Simon via KDE Bugzilla]

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

--- Comment #2 from Laurent Simon  ---
Reported on Kubuntu Trusty (14.04) but the problem is identical on Kubuntu
Willy (15.10)

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

[muon] [Bug 363695] Segmentation fault after startup of muon updater

[Laurent Simon via KDE Bugzilla]

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

--- Comment #1 from Laurent Simon  ---
Possible duplicate of: bug 363679

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

[muon] [Bug 363695] Segmentation fault after startup of muon updater

[Laurent Simon via KDE Bugzilla]

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

Laurent Simon  changed:

   What|Removed |Added

 CC||k...@contact.stratic.fr

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

[muon] [Bug 363695] New: Segmentation fault after startup of muon updater

[Laurent Simon via KDE Bugzilla]

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

Bug ID: 363695
   Summary: Segmentation fault after startup of muon updater
   Product: muon
   Version: 2.2.0
  Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: muon
  Assignee: echidna...@kubuntu.org
  Reporter: k...@contact.stratic.fr
CC: aleix...@kde.org, sit...@kde.org

Unable to launch muon updater. It always ends with a segmentation fault.

Reproducible: Always

Steps to Reproduce:
1. Launch muon updater (from launcher or command line)


Actual Results:  
The window shows up. It displays the waiting animation during update process
and then it disappears (due to segmentation fault)

Expected Results:  
The window should display available updates

Application: muon-updater (2.2.0)
KDE Platform Version: 4.13.3
Qt Version: 4.8.6
Operating System: Linux 3.19.0-59-generic x86_64
Distribution: Ubuntu 14.04.4 LTS

-- Information about the crash:
- What I was doing when the application crashed:

When launching muon updater it crashes at startup (from menu or command line).
The window shows up, displays the waiting animation and then disapears.

The crash can be reproduced every time.

-- Backtrace:
Application: Muon Update Manager (muon-updater), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fcb3521d7c0 (LWP 7831))]

Thread 3 (Thread 0x7fcb217b4700 (LWP 7832)):
#0  0x7fcb3287ffdd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fcb2f74cfe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fcb2f74d0ec in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fcb330067be in QEventDispatcherGlib::processEvents
(this=0x7fcb1c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436
#4  0x7fcb32fd80af in QEventLoop::processEvents
(this=this@entry=0x7fcb217b3de0, flags=...) at kernel/qeventloop.cpp:149
#5  0x7fcb32fd83a5 in QEventLoop::exec (this=this@entry=0x7fcb217b3de0,
flags=...) at kernel/qeventloop.cpp:204
#6  0x7fcb32ed4c5f in QThread::exec (this=this@entry=0x22b25e0) at
thread/qthread.cpp:537
#7  0x7fcb32fb9823 in QInotifyFileSystemWatcherEngine::run (this=0x22b25e0)
at io/qfilesystemwatcher_inotify.cpp:265
#8  0x7fcb32ed732f in QThreadPrivate::start (arg=0x22b25e0) at
thread/qthread_unix.cpp:349
#9  0x7fcb2fc2c184 in start_thread (arg=0x7fcb217b4700) at
pthread_create.c:312
#10 0x7fcb3288d37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7fcb10c21700 (LWP 7891)):
#0  0x7fcb3287ffdd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fcb2f74cfe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fcb2f74d0ec in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fcb330067be in QEventDispatcherGlib::processEvents
(this=0x7fcb040008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436
#4  0x7fcb32fd80af in QEventLoop::processEvents
(this=this@entry=0x7fcb10c20de0, flags=...) at kernel/qeventloop.cpp:149
#5  0x7fcb32fd83a5 in QEventLoop::exec (this=this@entry=0x7fcb10c20de0,
flags=...) at kernel/qeventloop.cpp:204
#6  0x7fcb32ed4c5f in QThread::exec (this=this@entry=0x6cc6930) at
thread/qthread.cpp:537
#7  0x7fcb32fb9823 in QInotifyFileSystemWatcherEngine::run (this=0x6cc6930)
at io/qfilesystemwatcher_inotify.cpp:265
#8  0x7fcb32ed732f in QThreadPrivate::start (arg=0x6cc6930) at
thread/qthread_unix.cpp:349
#9  0x7fcb2fc2c184 in start_thread (arg=0x7fcb10c21700) at
pthread_create.c:312
#10 0x7fcb3288d37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7fcb3521d7c0 (LWP 7831)):
[KCrash Handler]
#6  KNSResource::setStatus (this=this@entry=0x0,
status=KNS3::Entry::Downloadable) at
/build/buildd/muon-2.2.0/libmuon/backends/KNSBackend/KNSResource.cpp:60
#7  0x7fcb20b43efc in KNSResource::setEntry (this=this@entry=0x0,
entry=...) at
/build/buildd/muon-2.2.0/libmuon/backends/KNSBackend/KNSResource.cpp:127
#8  0x7fcb20b40b7c in KNSBackend::receivedEntries (this=0x263cf10,
entries=...) at
/build/buildd/muon-2.2.0/libmuon/backends/KNSBackend/KNSBackend.cpp:194
#9  0x7fcb32fed87a in QMetaObject::activate (sender=0x20d3530,
m=m@entry=0x7fcb20b0c2c0 ,
local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffd5ffae7a0)
at kernel/qobject.cpp:3539
#10 0x7fcb208bffd2 in KNS3::DownloadManager::searchResult (this=, _t1=...) at ./downloadmanager.moc:112
#11 0x7fcb208c014a in KNS3::DownloadManager::Private::_k_slotEntriesLoaded
(this=0x262f6e0, entries=...) at
../../../knewstuff/knewstuff3/downloadmanager.cpp:117
#12 0x7fcb32fed87a in QMetaObject::activate (sender=sender@entry=0x2219470,
m=m@entry=0x7fcb20b0c740 ,

[digikam] [Bug 363638] New: bootstrap does not detect libgphoto2

[Simon via KDE Bugzilla]

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

Bug ID: 363638
   Summary: bootstrap does not detect libgphoto2
   Product: digikam
   Version: 5.0.0
  Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

When I run the bootstrap script it always tells me that it does not find
libgphoto2 (above version 2.4.0). However I do have the package libgphoto2-dev
from debian repos installed, which are version 2.5.10-2 (-2 is debian specific,
rest major version).

Reproducible: Always

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

[digikam] [Bug 350098] Sort images on photograph specific metadata

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

Version|4.11.0  |5.0.0

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

[digikam] [Bug 362023] Extremely slow metadata writing via maintenance

[Simon via KDE Bugzilla]

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

--- Comment #14 from Simon  ---
Indeed, my setup is far from optimal for disk io. I have both the 
database and the images on a ntfs pratition of a hard disk on my laptop 
(at least not system hd). I thought that the database would be 
automatically cached in ram. I will look at it again some time.
Thanks again for your help.

On 02/05/16 21:14, Maik Qualmann via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=362023
>
> --- Comment #13 from Maik Qualmann  ---
> This is are long waiting times, up to 5 seconds until a scan is completed for
> one image. Disabling the scanning does not help, he would be rescheduled in 
> any
> case. Modification date or file size have changed and need to be updated in 
> the
> DB. Writing to the SQLite DB is the time problem. The SQLite DB to put on an
> SSD drive is strongly recommended. Here are a few measured values, writing of
> one image information in the DB this include read new information from image
> (images on HDD - EXT4):
>
> HDD:
> SQLite: 180-270ms
> internal MySQL: 40-70ms
>
> SSD:
> SQLite: 30-60ms
>
> Are the images on an NTFS partition? Is also here the SQLite DB?
>
> Maik
>

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

[digikam] [Bug 362023] Extremely slow metadata writing via maintenance

[Simon via KDE Bugzilla]

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

--- Comment #12 from Simon  ---
Created attachment 98665
  --> https://bugs.kde.org/attachment.cgi?id=98665=edit
Command line output in the middle of writing metadat to files with
scancontroller2.patch

I applied the patch and added the command line output in the same fashion as
before.

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

[digikam] [Bug 362023] Extremely slow metadata writing via maintenance

[Simon via KDE Bugzilla]

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

--- Comment #11 from Simon  ---
Created attachment 98664
  --> https://bugs.kde.org/attachment.cgi?id=98664=edit
Startup of digikam and start of writing metadata with scancontroller2.patch

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

[digikam] [Bug 362411] New: Selecting grouped files and renaming only acts on one file of every group

[Simon via KDE Bugzilla]

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

Bug ID: 362411
   Summary: Selecting grouped files and renaming only acts on one
file of every group
   Product: digikam
   Version: 5.0.0
  Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

I want to rename all pictures in a album. These pictures are grouped by file
type. To select all of them, I set the view to "ignore grouping" in the right
click menu under "Group". Then I select rename but only one file per group is
shown in the rename window. This is clearly due to grouping and not file type,
as when I ungroup these files all files appear in the renaming window. It is
also not the case, that one image per group is shown but the renaming is
applied to all images in the group. Adding these images to the batch queue
manager works as expected

Reproducible: Always

Steps to Reproduce:
1. Group some images
2. Select ignore grouping to select all images
3. Press F2 or select Item/Rename...

Actual Results:  
Only one image per group is shown in the renaming window and is actually
altered.

Expected Results:  
All selected images appear in the renaming window (as it is already happening
when adding to batch queue manager).

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

[digikam] [Bug 362407] New: Shortcut to either (un-)collapse grouping tree or change to "ignore grouping"

[Simon via KDE Bugzilla]

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

Bug ID: 362407
   Summary: Shortcut to either (un-)collapse grouping tree or
change to "ignore grouping"
   Product: digikam
   Version: 5.0.0
  Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: general
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

I really like the option to group images by file type, as I usually shoot
jpg However if I want to do an operation on all images and for that I want
to select all images, I currently need to right click one, go to "Group" and
click "Ignore grouping" first or in tree mode expand all trees by hand. This is
very cumbersome. It would be great to have a shortcut to switch between the
hide, tree and ignore options for grouping or have a shortcut to collapse or
uncollapse all groups in the current album.

Reproducible: Always

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

[digikam] [Bug 362406] New: On import renaming by date from file should use exif date and time not modification time as standard

[Simon via KDE Bugzilla]

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

Bug ID: 362406
   Summary: On import renaming by date from file should use exif
date and time not modification time as standard
   Product: digikam
   Version: 5.0.0
  Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Import
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

I import images with "Add images" (as my sd-card is not recognised as an
sd-card, just standard storage) and use the file renaming options to prefix
every file with the create date/time. This results in images being renamed to
the modification time of the file. This is not consistent with the renaming
utility (invoked by F2), where the exif date/time is used. In any case exif
date/time is what one would expect (I cannot think of any reason to use the
modification time).
The renaming behaves as expected (using exif) when you check the box "use file
metadata (makes connection slower) in the "Behavior" rider of the Cameras part
of the settings. In my opinion this is not even justified for import from
camera, but is certainly not expected for import from any storage media. And
the setting is not intuitive to find, as I never use a camera in the process
(in an "Import" submenu, one might find it).
Please change the standard to read date from exif instead of file modification
time.

Reproducible: Always

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

[digikam] [Bug 362023] Extremely slow metadata writing via maintenance

[Simon via KDE Bugzilla]

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

--- Comment #10 from Simon  ---
Do I apply this patch on top of the current HEAD or on top of your 
previous patch? I guess the first, but just to be sure.

On 27/04/16 21:14, Maik Qualmann via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=362023
>
> --- Comment #9 from Maik Qualmann  ---
> Created attachment 98651
>--> https://bugs.kde.org/attachment.cgi?id=98651=edit
> scancontroller2.patch
>
> That it is now slowly working because now images are processed with symbolic
> links.
> Please try this patch. He also adds a time measurement.
>
> Maik
>

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

[dolphin] [Bug 357479] crash if I close the splitscreen while focused on it and then change the view

[Kay Simon via KDE Bugzilla]

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

--- Comment #15 from Kay Simon  ---
Still on 16.04

KDE Frameworks 5.21.0
Qt 5.6.0

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

[digikam] [Bug 362023] Extremely slow metadata writing via maintenance

[Simon via KDE Bugzilla]

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

--- Comment #8 from Simon  ---
And the scan is now going clearly slower than before the patch. I am now 
running it almost two days and its at 3% only.

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

[plasmashell] [Bug 336079] plasmashell desktop crash with kactivitymanager segfault message libQtCore

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||simon.t...@tngtech.com

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

[digikam] [Bug 362023] Extremely slow metadata writing via maintenance

[Simon via KDE Bugzilla]

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

--- Comment #7 from Simon  ---
Created attachment 98528
  --> https://bugs.kde.org/attachment.cgi?id=98528=edit
Command line output in the middle of writing metadat to files with
scancontroller.patch

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

[digikam] [Bug 362023] Extremely slow metadata writing via maintenance

[Simon via KDE Bugzilla]

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

--- Comment #6 from Simon  ---
Created attachment 98527
  --> https://bugs.kde.org/attachment.cgi?id=98527=edit
Startup of digikam and start of writing metadata with  scancontroller.patch

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

[digikam] [Bug 362023] Extremely slow metadata writing via maintenance

[Simon via KDE Bugzilla]

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

--- Comment #5 from Simon  ---
Thanks for looking into this. I applied your patch. The results seems to be the
same (maybe somewhat less frequent rescans). I attached the initial part of the
log after startup, where redundant stuff is excluded (marked by [...]). The
actual scanning starts at line 400. A second command line output is from later
on during the scan.

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

[digikam] [Bug 362023] Extremely slow metadata writing via maintenance

[Simon via KDE Bugzilla]

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

--- Comment #1 from Simon  ---
Created attachment 98490
  --> https://bugs.kde.org/attachment.cgi?id=98490=edit
Command line output of writing metadata to files.

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

[digikam] [Bug 362023] New: Extremely slow metadata writing via maintenance

[Simon via KDE Bugzilla]

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

Bug ID: 362023
   Summary: Extremely slow metadata writing via maintenance
   Product: digikam
   Version: 5.0.0
  Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Metadata
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

I am writing tags that previously only existed in (sqlite) database to image
metadata via the maintenance tool. This takes an enormous amount of time, I am
currently at 10% after 3 days continuously running. The bottleneck is
(obviously) disk io. Still this should take much less time (exiftool took about
3h to delete old tags of the same collection). The collection contains 100'000
items and probably about half of them are to be tagged.
What looks odd to me is, that throughout the process digikam.general reports
that QFileSystemWatcher detected change in the folder that is currently written
to by the metadata write. The occurrence of this is also not regular and at a
fixed position within the log entries from writing metadata to tags, which
suggest to me that the two things are separate.

As it is digikam that is writing to these folders and not an external programs,
are these scans really necessary?
And if they are, can they be delayed till the maintenance tool finished writing
to a directory.

I do not see an option to attach something. I will get a partial log into this
bug report as soon as I found out how (or use a pastebin).

Reproducible: Always

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

[digikam] [Bug 361848] New: When writing metadata to files is disabled, digikam still displays "Writing metadata to files"

[Simon via KDE Bugzilla]

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

Bug ID: 361848
   Summary: When writing metadata to files is disabled, digikam
still displays "Writing metadata to files"
   Product: digikam
   Version: 5.0.0
  Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Metadata
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

I have writing of all types of metadata disabled in the settings. When I change
tags of images, there are two progress boxes displayed at the bottom right:
"Applying metadata"
and
"Writing metadata to files"
The second one suggest that digikam is writing metadata to the files, while it
does not (I have checked that). So the behavior of digikam is correct, but the
progress bar suggest otherwise and thus creates confusion. This progress bar
should not be displayed when writing to metadata is disabled.

Reproducible: Always

Steps to Reproduce:
1. Select some images and change tags, then apply.


Actual Results:  
Two progress bars appear, one saying "Writing metadata to files".

Expected Results:  
Only the progress bar "Applying metadata" or even more accurate something like
"Updating metadata in database" should be displayed.

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

[digikam] [Bug 361686] New: When returning from full screen to preview mode the same image should be selected/shown.

[Simon via KDE Bugzilla]

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

Bug ID: 361686
   Summary: When returning from full screen to preview mode the
same image should be selected/shown.
   Product: digikam
   Version: 5.0.0
  Platform: Debian testing
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Preview
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

When I look at images in preview mode, then change to full screen mode, switch
through some images and end up with another than I started with, then end full
screen mode, the initial image is presented. The expected and useful behavior
would be, that the last viewed image in full screen is selected when returning
to preview mode.

Reproducible: Always

Steps to Reproduce:
1. Go to preview mode and from there switch to full screen.
2. Change the image.
3. Return to preview mode.

Actual Results:  
The image from step 1 is selected/shown.

Expected Results:  
The last viewed image in full screen mode should be selected/shown.

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

[dolphin] [Bug 357479] crash if I close the splitscreen while focused on it and then change the view

[Kay Simon via KDE Bugzilla]

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

Kay Simon  changed:

   What|Removed |Added

 CC||kayingosi...@gmail.com

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

[digikam] [Bug 359108] 5 beta 3: interface problem, icons not showing up

[Simon via KDE Bugzilla]

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

--- Comment #14 from Simon  ---
Strangely with digikam 4.14 from debian repo I get all icons and they do 
not look like breeze. And I use tango icon theme, but changing it to 
something different (e.g. gnome) does not change the icons within 
digikam 4.14. Maybe there is some icon magic in the debian package :)

On 24/03/16 20:15, Maik Qualmann via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=359108
>
> --- Comment #13 from Maik Qualmann  ---
> Yes, the icons for Light Table and Editor is still missing in Breeze icon
> theme. I'll report to the Breeze team. The Breeze icon theme is the standard
> for KF5. Only the Breeze icon theme has all the icons needed for digiKam. I 
> see
> the icon theme option in the miscellaneous section at the moment as a
> workaround for not KF5 desktops.
> Which Icon theme use you on the desktop?
>
> Maik
>

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

[digikam] [Bug 359108] 5 beta 3: interface problem, icons not showing up

[Simon via KDE Bugzilla]

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

--- Comment #12 from Simon  ---
I have the same problem. While it is now possible with gilles commit to 
choose Breeze icons, they are not complete (e.g. Light Table and Editor 
Window icons in settings are missing) and the icons are very different 
from digikam 4.14 (packaged version of debian repos in xfce): 
http://i.imgur.com/AcxniJ5.png while digikam 5 (from source in debian 
chroot without any DE): http://i.imgur.com/m9zMHdy.png. Any idea what 
the icons in the 4.14 version are?
Also if I wasn't aware of this bug report, I would never have found this 
option in the miscellaneous section of the settings. This should work 
out of the box.

On 14/02/16 21:48, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=359108
>
> --- Comment #11 from caulier.gil...@gmail.com ---
> Philippe,
>
> If Breeze icon collection is not suitable due to lack of visual contrast,
> please report this problem to Breeze team into KDE bugzilla.
>
> digiKam team is not in charge of icons set...
>
> Gilles Caulier
>

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

[plasmashell] [Bug 359508] Plasma crash after opening Audio Volume Settings via Tray

[Simon via KDE Bugzilla]

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

--- Comment #2 from Simon  ---
Another duplicate
https://bugs.kde.org/show_bug.cgi?id=358339

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

[frameworks-kconfigwidgets] [Bug 357467] plasmashell crash

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||simon.th...@gmx.de

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

[plasma-pa] [Bug 358339] Plasma crash after changing default audio output

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||simon.th...@gmx.de

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

[plasma4] [Bug 315557] system tray crashed

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||simon.th...@gmx.de

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

[plasmashell] [Bug 359508] Plasma crash after opening Audio Volume Settings via Tray

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||simon.th...@gmx.de

--- Comment #1 from Simon  ---
Hi, 

I've also experienced crashing Audio Volume Settings several times:
Arch Linux
4.4.5-1-ARCH
plasma-meta 5.5-1
qt5-base 5.5.1-10

Potentially, this is a duplicate of 
https://bugs.kde.org/show_bug.cgi?id=357467

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

[digikam] [Bug 360528] Digikam looks for digikamimageplugins in different directory than they were installed to

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

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

[digikam] [Bug 360528] Digikam looks for digikamimageplugins in different directory than they were installed to

[Simon via KDE Bugzilla]

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

--- Comment #8 from Simon  ---
This is embarrassing, sorry for wasting your time and thanks for your 
patience:
I used git://anongit.kde.org/digikam instead of using the 
software-compilation repo. Using the software-repo this problem 
disappears (and would have never come up in the first place).
This "bug" can be closed.

On 14/03/16 22:42, Maik Qualmann via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=360528
>
> --- Comment #7 from Maik Qualmann  ---
> Please look here:
> https://www.digikam.org/download?q=download/GIT
>
> Maik
>

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

[digikam] [Bug 360528] Digikam looks for digikamimageplugins in different directory than they were installed to

[Simon via KDE Bugzilla]

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

--- Comment #4 from Simon  ---
That gave the same result. You are right about the Qt installation. I 
only installed the packages that were necessary for cmake to run without 
errors. Therefore I was missing the qtpaths binary file for qt5, I only 
had a wrapper binary by qtchooser. Installing qttools5-dev-tools 
provides the necessary file and now the output is correct:

(stretch-digikam5)simon@simon-x220-deb:/usr$ qtpaths --plugin-dir
/usr/lib/x86_64-linux-gnu/qt5/plugins

I uninstalled, recompiled and installed digikam but the plugin files are 
stilled installed in lib/x86_64-linux-gnu/plugins/.

On 14/03/16 20:36, Maik Qualmann via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=360528
>
> --- Comment #3 from Maik Qualmann  ---
> Then should "qtpaths --writable-path HomeLocation" also do not work? DigiKam
> uses QStandardPaths to find folders and datas. This has to work, otherwise
> digiKam will not work properly. I think something is wrong with your Qt
> installation.
>
> Maik
>

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

[digikam] [Bug 360528] Digikam looks for digikamimageplugins in different directory than they were installed to

[Simon via KDE Bugzilla]

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

--- Comment #2 from Simon  ---
This results in
qtpaths: could not find a Qt installation of ''

On 14/03/16 19:48, Maik Qualmann via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=360528
>
> Maik Qualmann  changed:
>
> What|Removed |Added
> 
>   CC||metzping...@gmail.com
>
> --- Comment #1 from Maik Qualmann  ---
> Digikam uses "qtpaths --plugin-dir" to find the plugin directory. Which
> directory is displayed with "qtpaths --plugin-dir"?
>
> Maik
>

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

[digikam] [Bug 360528] New: Digikam looks for digikamimageplugins in different directory than they were installed to

[Simon via KDE Bugzilla]

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

Bug ID: 360528
   Summary: Digikam looks for digikamimageplugins in different
directory than they were installed to
   Product: digikam
   Version: 5.0.0
  Platform: Debian testing
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: setup
  Assignee: digikam-de...@kde.org
  Reporter: freisi...@gmail.com

I compiled digikam5 from git commit 1b9a889. Digikam shows errors on startup
indicating that it did not find the digikamimageplugins
(digikamimageplugin_transform, ...). These files are installed into
lib/x86_64-linux-gnu/plugins/ while digikam searches for these files per
default (no QT_PLUGIN_PATH set) in lib/x86_64-linux-gnu/qt5/plugins/. Adding
the first path to the env variable QT_PLUGIN_PATH fixes this. Digikam should
install these files into lib/x86_64-linux-gnu/qt5/plugins/.


Reproducible: Always

Steps to Reproduce:
1. compile and install digikam (debug)
2. run digikam, look at stdout/stderr

Actual Results:  
Imageplugins are not found:

Error loading plugin "digikamimageplugin_color" "The shared library was not
found." 
Plugin search paths are ("/usr/lib/x86_64-linux-gnu/qt5/plugins", "/usr/bin") 
The environment variable QT_PLUGIN_PATH might be not correctly set
digikam.general: ImagePluginLoader: createInstance returned 0 for 
"ImagePlugin_Colour"  ( "digikamimageplugin_color" )  with error:  "The shared
library was not found."
Error loading plugin "digikamimageplugin_decorate" "The shared library was not
found." 
Plugin search paths are ("/usr/lib/x86_64-linux-gnu/qt5/plugins", "/usr/bin") 
The environment variable QT_PLUGIN_PATH might be not correctly set
digikam.general: ImagePluginLoader: createInstance returned 0 for 
"ImagePlugin_Decorate"  ( "digikamimageplugin_decorate" )  with error:  "The
shared library was not found."
Error loading plugin "digikamimageplugin_enhance" "The shared library was not
found." 
Plugin search paths are ("/usr/lib/x86_64-linux-gnu/qt5/plugins", "/usr/bin") 
The environment variable QT_PLUGIN_PATH might be not correctly set
digikam.general: ImagePluginLoader: createInstance returned 0 for 
"ImagePlugin_Enhance"  ( "digikamimageplugin_enhance" )  with error:  "The
shared library was not found."
Error loading plugin "digikamimageplugin_fxfilters" "The shared library was not
found." 
Plugin search paths are ("/usr/lib/x86_64-linux-gnu/qt5/plugins", "/usr/bin") 
The environment variable QT_PLUGIN_PATH might be not correctly set
digikam.general: ImagePluginLoader: createInstance returned 0 for 
"ImagePlugin_FxFilters"  ( "digikamimageplugin_fxfilters" )  with error:  "The
shared library was not found."
Error loading plugin "digikamimageplugin_transform" "The shared library was not
found." 
Plugin search paths are ("/usr/lib/x86_64-linux-gnu/qt5/plugins", "/usr/bin") 
The environment variable QT_PLUGIN_PATH might be not correctly set
digikam.general: ImagePluginLoader: createInstance returned 0 for 
"ImagePlugin_Transform"  ( "digikamimageplugin_transform" )  with error:  "The
shared library was not found."


Expected Results:  
Imageplugins found and loaded.

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

[digikam] [Bug 359897] Compilation failure - conflicting return type decodeRawImage()

[Simon via KDE Bugzilla]

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

Simon  changed:

   What|Removed |Added

 CC||freisi...@gmail.com

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

[krita] [Bug 357480] Krita Crash after Fullscreen switch

[simon via KDE Bugzilla]

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

--- Comment #2 from simon  ---
thank you for the response.
I tried but couldn't reproduce the bug either. It also didn't reappear during
normal usage of the program. I keep my eyes open and report if it reappears.

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