[Bug 215486] New: collection not found in location on disk with uuid (lvm volume)

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

           Summary: collection not found in location on disk with uuid
                    (lvm volume)
           Product: digikam
           Version: 1.0.0-beta5
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]


Version:           1.0.0-beta5 (using KDE 4.3.3)
OS:                Linux
Installed from:    Ubuntu Packages

After upgrading to karmic koala (digikam 1.0.0-beta5)
I lost access to my image database.

I message I got was:

the collection


was

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #1 from  <simon margo student utwente nl>  2009-11-20 22:22:00 ---
sorry, mousing error....
continuing here

-------

the collection


(Folder /home/simon/Photos on the volume with the id:<uuid>)

is currently not found on your system
please choose the most appropriate action
A) database is located on temp storage
B) take no action
-----------------

This is wrong on a lot of levels:
- I don't _know_ about my collections, as I have only one
- I've been using this collection for a long time and had several updates (with
similar problems, but never resulting in a total loss of all database
information)
- the actual database is still there, and contains data
- neither action proposed is or could be appropriate
- the reference to the setup dialog is misleading, since the actual path to the
configuration in digikam is elsewhere.
- the actual database is still there _and_ is the cause of the problem, because
it contains bad information about paths and volume-ids that earlier versions of
digikam have put there themselves.
- I get two of these dialogs, for both entries in the database concerning my
rootpaths or whatever.


I managed to fix it partially, or completely (I'm not sure yet) thanks to some
hints on the ubuntu forum:
http://ubuntuforums.org/showthread.php?t=1192655
(The fix was to remove the rootpaths records in the database using
sqlitebrowser, and letting digikam create a new entry. Then checking what this
looks like and putting that in the old databasefile on each of my rootpath
entries got me a single dialog like above and a working "collection" with my
tags available again (I hope)

and the bug looks somewhat like this one:
https://bugs.kde.org/show_bug.cgi?id=193522

but my situation is different.

In general, I think a lot more care should be taken to deal with this database
around upgrades and in general. I have growing reluctance to trust my photos
and especially the metadata to digikam because of such an upgrade experience. I
have 10s of thousands of images, (I know, way too much, but it takes time to
weed them out). If I put in time to tag them, I want to know my data is safe!

How hard can it be to write a database recovery tool (inside digikam) to handle
this kind of situation. If a used has backups, the data in it should be
recoverable with a small bit of assistance from the user. It should recover
from any "collection" with any version of digikam's database formats. The main
thing is that images retain the links to their tags and ratings and comments,
those things cannot be generated by the machine.

Cheers

Simon

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #2 from  <simon margo student utwente nl>  2009-11-20 22:25:36 ---
The path I had was of the form:
6034d5dd-65c5-40a6-a231-d20f1e4e02a7
(though probably volumeid:?uuid=6034d5dd-65c5-40a6-a231-d20f1e4e02a7)

And it should be:
volumeid:?path=%2Fhome%2Fsimon%2FPhotos
And a / in the next field, instead of /home/simon/Photos

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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


Marcel Wiesweg <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #3 from Marcel Wiesweg <marcel wiesweg gmx de>  2009-11-21 17:16:22 ---

> - I don't _know_ about my collections, as I have only one
> - I've been using this collection for a long time and had several updates (with
> similar problems, but never resulting in a total loss of all database
> information)
> - the actual database is still there, and contains data

Nothing is said about loss of database information.
Please report upgrade problems

> - neither action proposed is or could be appropriate
> - the reference to the setup dialog is misleading, since the actual path to the
> configuration in digikam is elsewhere.

??

> - the actual database is still there _and_ is the cause of the problem, because
> it contains bad information about paths and volume-ids that earlier versions of
> digikam have put there themselves.

The database did not change. Probably your partitions and or filesystems
changed.
Please post the output of "solid-hardware list details"


> The path I had was of the form:
> 6034d5dd-65c5-40a6-a231-d20f1e4e02a7
> (though probably volumeid:?uuid=6034d5dd-65c5-40a6-a231-d20f1e4e02a7)

That is how it should be.

>
> And it should be:
> volumeid:?path=%2Fhome%2Fsimon%2FPhotos
> And a / in the next field, instead of /home/simon/Photos

No it should not be like this. It works like this, it can be like this if you
have reason.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #4 from  <simon margo student utwente nl>  2009-11-21 20:52:30 ---
> Nothing is said about loss of database information.
> Please report upgrade problems

Technically, the database lost no information, because the file digikam4.db was
still there, containing the information (AFAICT).

The upgrade problem is that I was confronted with a newer version of digikam
and I "lost" my entire "collection" due to some error regarding the uuid of the
disk on which my collection is stored.

The volume is an lvm2 one, though it matters not a bit, because I could have
copied all my data to a new and bigger disk, then my uuid would also be
different.

When I removed all the entries for AlbumRoots from the database, digikam told
me it was unable to determine the uuid and if it was ok to use the pathname
(which is perfectly fine with me).


>
> > - neither action proposed is or could be appropriate
> > - the reference to the setup dialogue is misleading, since the actual path to the
> > configuration in digikam is elsewhere.
>
> ??

The error refers to the "setup dialogue", the actual path is menu -> Settings
-> Configure Digikam -> Collections, if I understand correctly.


> > - the actual database is still there _and_ is the cause of the problem, because
> > it contains bad information about paths and volume-ids that earlier versions of
> > digikam have put there themselves.
>
> The database did not change. Probably your partitions and or filesystems
> changed.
> Please post the output of "solid-hardware list details"

I usually work remotely (ssh X tunnelling) I get this output:
 virtual QStringList Solid::Backends::Hal::HalManager::allDevices()  error:
"org.freedesktop.DBus.Error.ServiceUnknown"

>
> > The path I had was of the form:
> > 6034d5dd-65c5-40a6-a231-d20f1e4e02a7
> > (though probably volumeid:?uuid=6034d5dd-65c5-40a6-a231-d20f1e4e02a7)
>
> That is how it should be.
>
> >
> > And it should be:
> > volumeid:?path=%2Fhome%2Fsimon%2FPhotos
> > And a / in the next field, instead of /home/simon/Photos
>
> No it should not be like this. It works like this, it can be like this if you
> have reason.

Well, whether or not this is right or wrong according to the current
implementation or intention, I would like to argue that this way of referring
to "collections" is error prone, due to uncaught assumptions (as far as I
understand the intention, of course).

To me it seems that in order to handle collections on temporary storage, the
concept of uuid was added as a required authentication of a collection.
However, there are lots of situations that can occur with perfectly
non-temporary storage of collections that make the uuid change or unavailable
(as in my case, probably).

If my assumption is correct, I would suggest to change the behaviour of digikam
to take the uuid as a hint and rely mostly on the pathname. If a mismatch is
found in the uuid, or the stored collection on disk (the actual image files),
then it might be that you're dealing with a (different) temporary storage
device, rather than a permanently collected storage device. The latter being
the common use-case, I presume.

In modern Linux systems, the pathname is usually /media/<volume-label> anyway,
so it might very well be that the problem is commonly solved that way, without
needing something as arbitrary as a uuid. (It's not like you can see from the
uuid what kind of disk you're dealing with)

And furthermore, even if something seems to be wrong, it would definitely be
helpful if digikam was able to "import" the old database for the meta-data of
the files.

If the database contains filename and exif-date linked with the unique database
key used to store the tags and comments, I'd expect to get a 100% recovery in
most cases.

I hope I've cleared up the situation!

/Simon

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #5 from  <simon margo student utwente nl>  2009-11-21 21:11:27 ---
Probably the most important reason not to care about which disk the collection
is on is that unix is designed to not care about where the physical files are
stored, as long as the pathname is the same, the same file is intended.

Obviously, this breaks when partitions are added/removed willy nilly, like with
usb storage. But it makes no sense to break the basic design assumption of unix
(and Linux). To determine whether a different collection is meant by the
user(!), some sort of identifier should be kept with the collection, in the
form of a file, or the identification should be based on the image files
themselves.

/Simon

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Database




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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





--- Comment #6 from Marcel Wiesweg <marcel wiesweg gmx de>  2009-11-22 11:42:52 ---

> The volume is an lvm2 one, though it matters not a bit, because I could have
> copied all my data to a new and bigger disk, then my uuid would also be
> different.
>
> When I removed all the entries for AlbumRoots from the database, digikam told
> me it was unable to determine the uuid and if it was ok to use the pathname
> (which is perfectly fine with me).
>
> I usually work remotely (ssh X tunnelling) I get this output:
>  virtual QStringList Solid::Backends::Hal::HalManager::allDevices()  error:
> "org.freedesktop.DBus.Error.ServiceUnknown"

It seems that HAL is broken on your installation. That explains why digikam
could not find the UUID of newly added collections and why it did not suggest
the new place of your collection in the first place.

(and no, we do not add extra handling when HAL is broken - for one we cannot
find out because Solid is cross-platform, and secondly it's a system service,
so it's the problem of distributions)


> To me it seems that in order to handle collections on temporary storage, the
> concept of uuid was added as a required authentication of a collection.
> However, there are lots of situations that can occur with perfectly
> non-temporary storage of collections that make the uuid change or unavailable
> (as in my case, probably).

The intention is to support storage on hard-disks, optical disks, all kinds of
pluggable USB storage devices, and - this is a different conceptual level -
network drives. For all of the former, the UUID is by far the best means of
identification, followed by volume label (can easily be the same for different
media) and mount path (maybe based on volume label on Linux, arbitrary on
Windows).

The UUID has a weakness when you repartition your harddisk and change the
filesystem type, but do not change the mountpoint. In this case digikam will
see that the old collection from hard-wired storage is missing, and there is a
new candidate with the same relative paths (under the mountpoint), and offer
you that as a candidate. Provided your HAL system services are not broken.


> If the database contains filename and exif-date linked with the unique database
> key used to store the tags and comments, I'd expect to get a 100% recovery in
> most cases.

Me too. Otherwise it's a bug ;-)

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #7 from  <simon margo student utwente nl>  2009-11-22 17:22:47 ---
Regarding HAL, I'm running ubuntu karmic koala and in the release notes it says
HAL is deprecated:

> hal deprecation
>
> Ubuntu 9.10 Beta's underlying technology for power management, laptop
> hotkeys, and handling of storage devices and cameras maps has moved from
> "hal" (which is in the process of being deprecated) to "DeviceKit-power",
> "DeviceKit-disks" and "udev". When testing Ubuntu 9.10 Beta, please be alert
> for regressions in those areas and report any bugs you find.

So I suppose I should report this as a regression to ubuntu?

But the larger picture is still the one from my last comment, it's just not the
unix way to depend on meta-information about the storage device for this kind
of problems. If now HAL is deprecated and devicekit is used, in 5 years time
perhaps some other solution will be used, but the underlying philosophy is the
same old unix-way, so that's what you need to get things to work over longer
periods (and photo collections tend to be LONG periods).

So the problem is that some albumroots contain a different collection at
different times and digikam needs to differentiate between them?

The collection contains the actual photo-files and nothing else?

And the database is stored (theoretically) in a separate location (found by
digikamrc configuration?)

(In my case the digikam4.db is in the same toplevel directory as my collection)

Doesn't it make sense to add a collection identifying file to each collection's
root directory? That way you'll always know which is which. And even if you
want to solve the problem using some arbitrary other route (like uuid), there's
always a backup way to retain a working system.

Cheers

Simon

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #8 from  <simon margo student utwente nl>  2009-11-22 17:37:35 ---
https://wiki.ubuntu.com/Halsectomy has an overview of regressions for ubuntu's
decision to deprecate HAL

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Milan Knizek]

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


Milan Knizek <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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





--- Comment #9 from Marcel Wiesweg <marcel wiesweg gmx de>  2009-11-23 19:28:02 ---
What we use is KDE's Solid API, which is a cross-platform API in kdelibs
proper, on Linux usually traditionally on HAL. I don't know of the status of
post-HAL support for Solid, but that is out of our scope. If a distribution
decides to remove a piece of system software it should make sure KDE is not
broken. (I guess at least Kubuntu will sooner or later be forced to fix that)

And yes, you can put your database wherever you want and can add as many
collections to it (= photos on a storage somewhere) as you want.

It would be possible to add support for identifying collections by a file of
defined filename and known contents (could contain a random seed, a name or a
uuid)

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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


Marcel Wiesweg <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DOWNSTREAM




--- Comment #10 from Marcel Wiesweg <marcel wiesweg gmx de>  2009-12-20 15:50:41 ---
Seed identification may be done in the future for network collections, I'm not
sure.
The main problem here is clearly a DOWNSTREAM and/or UPSTREAM issue, we only
rely on platform-independent kdelibs API

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #11 from  <simon margo student utwente nl>  2009-12-21 08:23:00 ---
Hi Marcel,

I disagree with the closing of this bug. Please read again my comments (the
prose at the end of)  https://bugs.kde.org/show_bug.cgi?id=215486#c4

This "feature" assumes too much about the OS, nothing guarantees that the uuid
will remain the same during the timeperiod of any collection's life. The uuid
is simply not able to uniquely identify the collection.

Relying on the kdelibs (solid I presume?) is also not robust, especially
regarding low level stuff like uuid's.

It's like you're identifying cars by the composition of the metal used for the
wheel-hubs, where you should be using the number-plates (they're stuck on as
well!)

Cheers

Simon

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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





--- Comment #12 from Marcel Wiesweg <marcel wiesweg gmx de>  2009-12-21 20:09:58 ---
There are quite a few pros and cons to consider, and certainly one size doesn't
fit it all. For good support of network shares we can't UUID either of course.
Maybe there'll be an option to load a collection by path only, if the user
really wants. But if you check the Solid API, there is mostly label and uuid to
be used.
http://api.kde.org/4.x-api/kdelibs-apidocs/solid/html/classSolid_1_1StorageVolume.html

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #13 from  <simon margo student utwente nl>  2009-12-22 08:44:09 ---
To me it seems like you're desperately set on using an API intended to get
details about hardware when you really want to put a label on a directory-tree.

How do you handle:
- more than one collection on the same disk?
- moving a collection from one disk to another?
- moving a collection to another linux install?
- sub-collections?
- fixing a collection from a broken disk?

Say you put a file: .digikamcollection containing some information about the
collection like: owner, date of last access/additions, key for the digikamdb,
etc.

This would solve a lot of problems and it is doesn't get in the way.

Additionally, I think it would be a good idea to more pro-actively try to match
a physical collection to a collection in the database when a quick match (based
on uuid or the file I propose) isn't possible.

I hope you can see that the bug (as I intended it) isn't resolved at all!

/Simon

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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


[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DOWNSTREAM                  |




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|1.0.0-beta5                 |1.0.0




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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





--- Comment #14 from Orestes Mas <orestes tsc upc edu>  2009-12-25 23:12:10 ---
Created an attachment (id=39340)
 --> (http://bugs.kde.org/attachment.cgi?id=39340)
Hardware list provided by Solid

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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


Orestes Mas <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #15 from Orestes Mas <orestes tsc upc edu>  2009-12-25 23:13:47 ---
Please don't close this issue yet. I'm in a similar situation, and I tink this
is a real problem.

I've experienced recently a disk failure. The disk contained my photo
collections, but fortunately I had backup copy of all photos + the digikam
database.

Now I've decided to build a RAID system on my desktop computer, to be even more
protected against another eventual disk failure. So I bought 2 identical disks,
set up a RAID array and created some LVM2 logical partitions over it. Finally,
I restored my backup copy (in fact, a backup of whole /home containing
/home/photos) and triedopened Digikam to check my collection, but digikam
complained with similar message as the one of the fisrst reporter (Simon).

The 2 options offered were to do nothing and to consider the collection being
in a removable storage. But this dialog should also offer the option to fix the
drive's UUID stored in the database, as in my opinion the situation I face is
not uncommon.

I'm also on kubuntu karmic, but I don't thing my HAL is broken, although I'm
not an expert in this field and I can be wrong.

I attach the output of "solid-hardware", and explain a bit my setup, for the
sake of clarity:

I've 2 identical, 1TB drives: /dev/sda and /dev/sdb. The two are formatted
identically:

GPT partition table
  1 small "BIOS" partition (sda1, sdb1) to make room for GRUB2
  1 big partition (sda2, sdb2) to serve as a RAID volume

The created RAID (/dev/md1) is used as a LVM2 physical volume, and this volume
is assigned to a "gv1" volume group. Finally, this volume group is divided into
3 logical partitions: root ("arrel" in my language), home and swap, mounted and
used the obvious way.

The backup copy, previously stored in a LVM2 logical partition with
UUID=5f5cb5e1-091b-4f05-a564-9bd29ab9c664 in the failed drive, now is restored
in the new /home partition, with UUID=16013925-4625-4763-9246-22f1b80a65f2, and
Digikam is complaining about that.

I think I'll be able to fix it editing the database (with some suitable tool)
and change the old UUID with the new one, but obviously the average user won't,
and so thisshould be considered a (data loss) bug.

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel