Hi,
I have CentOS 7 with KDE on my workstation. I'm using the CR repo. I had to remove Digikam to be able to do the latest update (1 GB of updates... wow). Here's what happens when I try to reinstall it.
# yum install digikam ... --> Finished Dependency Resolution Error: Package: digikam-4.10.0-6.el7.x86_64 (epel) Requires: libgphoto2_port.so.10(LIBGPHOTO2_5_0)(64bit) Available: libgphoto2-2.5.2-5.el7.x86_64 (base) libgphoto2_port.so.10(LIBGPHOTO2_5_0)(64bit) Installed: libgphoto2-2.5.15-1.el7.x86_64 (@cr) ~libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit) Error: Package: digikam-4.10.0-6.el7.x86_64 (epel) Requires: libgphoto2_port.so.10()(64bit) Available: libgphoto2-2.5.2-5.el7.x86_64 (base) libgphoto2_port.so.10()(64bit) Installed: libgphoto2-2.5.15-1.el7.x86_64 (@cr) ~libgphoto2_port.so.12()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
Any suggestions? Just wait until the EPEL maintainers rebuild it against the latest stuff?
Cheers,
Niki
On 28/04/18 21:23, Nicolas Kovacs wrote:
Hi,
I have CentOS 7 with KDE on my workstation. I'm using the CR repo. I had to remove Digikam to be able to do the latest update (1 GB of updates... wow). Here's what happens when I try to reinstall it.
# yum install digikam ... --> Finished Dependency Resolution Error: Package: digikam-4.10.0-6.el7.x86_64 (epel) Requires: libgphoto2_port.so.10(LIBGPHOTO2_5_0)(64bit) Available: libgphoto2-2.5.2-5.el7.x86_64 (base) libgphoto2_port.so.10(LIBGPHOTO2_5_0)(64bit) Installed: libgphoto2-2.5.15-1.el7.x86_64 (@cr) ~libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit) Error: Package: digikam-4.10.0-6.el7.x86_64 (epel) Requires: libgphoto2_port.so.10()(64bit) Available: libgphoto2-2.5.2-5.el7.x86_64 (base) libgphoto2_port.so.10()(64bit) Installed: libgphoto2-2.5.15-1.el7.x86_64 (@cr) ~libgphoto2_port.so.12()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
Any suggestions? Just wait until the EPEL maintainers rebuild it against the latest stuff?
Cheers,
Niki
Yes, that's something we discovered during CR QA tests on our nodes : people relying on third-party repositories will get such kind of errors and so will have to contact upstream maintainers to rebuild against $current release. Same issue with libgphoto : wine has to be rebuilt too (unsigned pkgs available here : https://people.centos.org/arrfab/CentOS7/wine32bits/)
Le 29/04/2018 à 17:52, Fabian Arrotin a écrit :
Yes, that's something we discovered during CR QA tests on our nodes : people relying on third-party repositories will get such kind of errors and so will have to contact upstream maintainers to rebuild against $current release. Same issue with libgphoto : wine has to be rebuilt too (unsigned pkgs available here : https://people.centos.org/arrfab/CentOS7/wine32bits/)
OK, thanks for the heads-up.
Cheers,
Niki
Nicolas try installing Digikam as flatpak, I think it could be working since it should be independent of system packages.
On Sun, Apr 29, 2018 at 6:10 PM, Nicolas Kovacs info@microlinux.fr wrote:
Le 29/04/2018 à 17:52, Fabian Arrotin a écrit :
Yes, that's something we discovered during CR QA tests on our nodes : people relying on third-party repositories will get such kind of errors and so will have to contact upstream maintainers to rebuild against $current release. Same issue with libgphoto : wine has to be rebuilt too (unsigned pkgs available here : https://people.centos.org/arrfab/CentOS7/wine32bits/)
OK, thanks for the heads-up.
Cheers,
Niki
-- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Le 29/04/2018 à 17:52, Fabian Arrotin a écrit :
Yes, that's something we discovered during CR QA tests on our nodes : people relying on third-party repositories will get such kind of errors and so will have to contact upstream maintainers to rebuild against $current release.
There's a similar problem with gthumb and exiv2.
On Tue, May 1, 2018 at 8:25 AM, Nicolas Kovacs info@microlinux.fr wrote:
There's a similar problem with gthumb and exiv2.
This is a known issue and there is a workaround:
https://bugzilla.redhat.com/show_bug.cgi?id=1568618 https://access.redhat.com/discussions/3414821
Akemi
Akemi Yagi wrote:
There's a similar problem with gthumb and exiv2.
This is a known issue and there is a workaround:
https://bugzilla.redhat.com/show_bug.cgi?id=1568618 https://access.redhat.com/discussions/3414821
I've just hit this issue - to save me re-inventing the wheel, does a 'exiv2-libs-compat' (S)RPM exist somewhere that I could get hold of?
Thanks
James Pearson
Le 16/05/2018 à 17:26, James Pearson a écrit :
I've just hit this issue - to save me re-inventing the wheel, does a 'exiv2-libs-compat' (S)RPM exist somewhere that I could get hold of?
It looks like the problem is solved. I just installed Digikam, and it went fine, without any extra -compat packages.
Nicolas Kovacs wrote:
Le 16/05/2018 à 17:26, James Pearson a écrit :
I've just hit this issue - to save me re-inventing the wheel, does a 'exiv2-libs-compat' (S)RPM exist somewhere that I could get hold of?
It looks like the problem is solved. I just installed Digikam, and it went fine, without any extra -compat packages.
I'm not using Digikam - but I'm having a similar problem with another unconnected package
However, I've now created my own 'exiv2-libs-compat' RPM which fixes my problem
Thanks
James Pearson
-
Akemi Yagi -
Fabian Arrotin -
James Pearson -
Nicolas Kovacs -
vychytraly