This is not a bug within pkg-kde-tools in general.
The rules line is bogus in that it should be checking for the .pot file's presence rather than assuming it to be there, which it will not with changed pkg-tools in envrionments other that official archive builds. i.e. it will fail for PPAs, local builds, you name it. So what should happen is that the rules file should wrap that cp in a nice
IF THE FILE EXISTS DO CP condition.
The problem I have with it though is that the rules line should not be there at all because this sort of stuff should be handled by pkg-kde-tools, to only have one central point of failure which makes it easy to debug and fix. Supposedly pkg-kde-tools does not provide functionallity for this currently, which made someone do this completely ugly hack, which obviously is a bad idea because now if one does a change to the build infrastructure that renders an assumption as made here false, one cannot right away influence conditional actions like the one at hand, but either knows that digikam does this completely horribly thing or wait for a bug to pop up.
So short term solution -> make the copy action if conditional, long term solution -> find a way to regulate this kind of functionallity from within pkg-kde-tools
This is not a bug within pkg-kde-tools in general.
The rules line is bogus in that it should be checking for the .pot file's presence rather than assuming it to be there, which it will not with changed pkg-tools in envrionments other that official archive builds. i.e. it will fail for PPAs, local builds, you name it. So what should happen is that the rules file should wrap that cp in a nice
IF THE FILE EXISTS DO CP condition.
The problem I have with it though is that the rules line should not be there at all because this sort of stuff should be handled by pkg-kde-tools, to only have one central point of failure which makes it easy to debug and fix. Supposedly pkg-kde-tools does not provide functionallity for this currently, which made someone do this completely ugly hack, which obviously is a bad idea because now if one does a change to the build infrastructure that renders an assumption as made here false, one cannot right away influence conditional actions like the one at hand, but either knows that digikam does this completely horribly thing or wait for a bug to pop up.
So short term solution -> make the copy action if conditional, long term solution -> find a way to regulate this kind of functionallity from within pkg-kde-tools