digiKam 1.0 rc is out. http://www.digikam.org/drupal/node/488 Reproducible: Always
Ping...
As you can notice there is big patch applied to digikam 1.0.0-beta. If someone from you guys rebase it to apply for digikam 1.0.0-rc then it can go into main tree, otherwise it wont happen.
Created attachment 213289 [details, diff] digikam-1.0.0-rc.patch Rebased. The last hunk for /CMakeLists.txt was already applied in -rc, so I removed it. It applies cleanly in the -rc source. Feel free to test it.
It is nice but Your patch show differences for build/ folder we are not entirely interested. The patch i speak about is: http://dev.gentooexperimental.org/~scarabeus/digikam-1.0.0-beta6.patch.bz2
(In reply to comment #4) > It is nice but Your patch show differences for build/ folder we are not > entirely interested. > > The patch i speak about is: > http://dev.gentooexperimental.org/~scarabeus/digikam-1.0.0-beta6.patch.bz2 Yes, that's the patch I modified. It's not possible for me to know which differences are not needed inside the build/ folder... Anyway, I'll try to build -rc with this patch and see how it goes.
*** Bug 297771 has been marked as a duplicate of this bug. ***
1,0.0 final been released
I maid small changes on the ebuilds at portage and I could successfully emerge digikam-1.0.0 and kipi-plugins 1.0.0. I'll attach the ebuils for testing, but, please, I have never done this before, I'll just attach it for people who wants to install it now.
Created attachment 213778 [details] digikam-1.0.0 ebuild
Created attachment 213779 [details] kipi-plugins-1.0.0 ebuild
Thanks for the ebuilds Ronan. Testing right now. I didn't take a close look at the digikam ebuild, I suppose you don't include the patch Tomas was talking about in #c4, right?
Tested digikam 1.0.0 with kipi-plugins 1.0.0 with the attached ebuilds from Ronan and everything seems fine
Ebuild previously posted doesn't have the patch in at all. All bar 26 of the 2488 lines in the -beta6 patch are in the build/ subdirectory and are generated files from the cmake run. Therefore I can't see why they were needed in this patch in the first place. The remaining 26 lines are the change to CMakeLists.txt which as noted have been absorbed by upstream. Without it digikam itself builds fine (amd64 and x86 chroot), however the cleanup_digikamdb script included in the new release depends on kde-base/kreadconfig at runtime (it runs kreadconfig) - I guess that means that the ebuild for digikam needs to depend on kde-base/kreadconfig. With a USE-flag and if so what?
First, thanks for people who have tested the ebuild :) I have created another ebuild and a specific patch for digikam 1.0.0 to unbundled libpgf that was recently added to portage tree. I'll attach this when the bug http://bugs.gentoo.org/show_bug.cgi?id=298245 is resolved. With this, the following libraries will continue bundled: 1) SQLite2: needed to convert old database archive, so it doesn't need to be unbundled. 2) CLapack: unfortunately, I can't install the package that I suppose to provide clapack (sci-libs/lapack-atlas) because it depends on sci-libs/blas-atlas that cannot be installed on my system. So I can't unbundled it too. 3) lprof: the three available versions on portage cannot be installed on my system also. Richard, I'm not sure, but I think you are right about kreadconfig. It might affect people who want to install digikam and don't have KDE installed. So, when the bug that I mentioned was fixed, I'll attach the new ebuild with this runtime dependency. Thanks.
=sqlite-2.* is in main tree, so it should rather pull sqlite:0 as dep with some migration useflag. Rather than using insecure bundled version.
(In reply to comment #15) > =sqlite-2.* is in main tree, so it should rather pull sqlite:0 as dep with some > migration useflag. Rather than using insecure bundled version. > There isn't an option to avoid sqlite2 begin built. I don't think it can be done without code modification. What I suppose to be easy to do is to make sqlite:0 a dependency of digikam and unbundled it, but the ebuild mirrors doesn't have the distfile anymore, so it must be fixed. What do you think?
Since bug #298245 was closed (thanks to Samuli Suominen), now I can attach a new digikam ebuild and patch that unbundled libpgf that was recently added to portage. I have tested it here and it is working perfectly, please, give me the feedback if it is working well at others systems. I also add the runtime dependency kde-base/kreadconfig due to comment #13. Me and tampakrap are working to verify if it is feasible to add a newer lprof version to portage tree in order to unbundle it also from digikam.
Created attachment 214593 [details] Digikam ebuild with patch that unbundled libpgf.
Created attachment 214595 [details, diff] Patch to unbundled libpgf from digikam-1.0.0.
New ebuild with unbundled pibpgf fails here. libpgf gets installed fine (output of "equery f libpgf" is here: http://dpaste.com/139179/ ) and the patch is applied by the ebuild ( * Applying libpgf-unbundled-r0.patch ... [..] [ ok ]) but the compilation fails later: "/var/tmp/portage/media-gfx/digikam-1.0.0/work/digikam-1.0.0/libs/dimg/loaders/pgfloader.cpp:75:22: error: PGFimage.h: No such file or directory"
now try with 6.09.44-r1, which includes the fix to your problem. I'll add the digikam ebuild in kde overlay in a while, so we can keep development there (lprof and any other needed libs will be added there as well)
You're right, updating libpgf makes the compilation works and digicams can be used normally. However when trying to display PGF-files it crashes: (I didn't try to display PGF-images with the bundled libpgf) Thread 15 (Thread 0x7fe9c64f4710 (LWP 10550)): [KCrash Handler] #5 0x00007fe9d6ec51b5 in raise () from /lib/libc.so.6 #6 0x00007fe9d6ec65e0 in abort () from /lib/libc.so.6 #7 0x00007fe9d6effe77 in ?? () from /lib/libc.so.6 #8 0x00007fe9d6f05406 in ?? () from /lib/libc.so.6 #9 0x00007fe9d6f0a1ac in free () from /lib/libc.so.6 #10 0x00007fe9d3a342cd in CPGFImage::Close() () from /usr/lib64/libpgf.so.1 #11 0x00007fe9d3a353b0 in CPGFImage::Destroy() () from /usr/lib64/libpgf.so.1 #12 0x00007fe9db117026 in ?? () from /usr/lib64/libdigikamcore.so.1 #13 0x00007fe9db0ff93f in Digikam::ThumbnailCreator::createThumbnail(Digikam::ThumbnailInfo const&) () from /usr/lib64/libdigikamcore.so.1 #14 0x00007fe9db0fffaf in Digikam::ThumbnailCreator::load(QString const&) () from /usr/lib64/libdigikamcore.so.1 #15 0x00007fe9db10717b in ?? () from /usr/lib64/libdigikamcore.so.1 #16 0x00007fe9db0e22dc in Digikam::LoadSaveThread::run() () from /usr/lib64/libdigikamcore.so.1 #17 0x00007fe9d8d2a1d5 in ?? () from /usr/lib64/qt4/libQtCore.so.4 #18 0x00007fe9d8a9b894 in start_thread () from /lib/libpthread.so.0 #19 0x00007fe9d6f63f9d in clone () from /lib/libc.so.6 #20 0x0000000000000000 in ?? ()
Let me correct #22: some PGF-files make digikam crash, some do work. however, sometimes it says "image cannot be displayed" or the image is displayed incorrectly (only part of the image shown or white lines all over the image)
Jannis, I can't reproduce your bug with every pgf file that I have converted with digikam. I found a little bug, sometimes you have to zoom your picture to see it but I can always see my pgf files. But, I didn't found any pgf file on internet, everyone that I tried was converted by digikam, so, can you post this problematic file somewhere?
Since I didn't have any PGF-file on my computer, I searched the internet and found those: http://www.xeraina.ch/download/pgf_images.zip and used them to test PGF-support
Created attachment 214634 [details] Ebuild with correct dependency and additional patch Given the build fails without the fix to libpgf introduced in libpgf-6.09.44-r1, shouldn't the dep be >=media-libs/libpgf-6.09.44-r1 ? I assume so and have changed my copy of the ebuild to that. I also found an upstream bug in the under- and over-exposure indicators (they didn't work on 16-bit images, https://bugs.kde.org/show_bug.cgi?id=220454). Upstream have fixed this in their SVN for 1.1.0 version, but the patch applies to the 1.0.0 release as well, so I've added it to this ebuild to avoid other people hitting the same problem.
Created attachment 214635 [details, diff] patch to fix the over- and under-exposure indicators for 16-bit images patch from upstream for https://bugs.kde.org/show_bug.cgi?id=220454
(In reply to comment #25) > Since I didn't have any PGF-file on my computer, I searched the internet and > found those: http://www.xeraina.ch/download/pgf_images.zip and used them to > test PGF-support > I also found it but the link is down. I tested the ebuild posted by Richard and it is working.
jannis, Can you test these files with original digikam (with libpgf bundled)?
I rebuilt digikam with bundled pgf-support and it also crashes: Thread 16 (Thread 0x7fa5937fe710 (LWP 13254)): [KCrash Handler] #5 0x00007fa5ac69730b in ?? () from /usr/lib64/libdigikamcore.so.1 #6 0x00007fa5ac69de7e in ?? () from /usr/lib64/libdigikamcore.so.1 #7 0x00007fa5ac67b91f in Digikam::ThumbnailCreator::createThumbnail(Digikam::ThumbnailInfo const&) () from /usr/lib64/libdigikamcore.so.1 #8 0x00007fa5ac67bf8f in Digikam::ThumbnailCreator::load(QString const&) () from /usr/lib64/libdigikamcore.so.1 #9 0x00007fa5ac68315b in ?? () from /usr/lib64/libdigikamcore.so.1 #10 0x00007fa5ac65e2bc in Digikam::LoadSaveThread::run() () from /usr/lib64/libdigikamcore.so.1 #11 0x00007fa5aa2991d5 in ?? () from /usr/lib64/qt4/libQtCore.so.4 #12 0x00007fa5aa00a894 in start_thread () from /lib/libpthread.so.0 #13 0x00007fa5a84d2f9d in clone () from /lib/libc.so.6 #14 0x0000000000000000 in ?? () The link with the pgf-files I used for testing still works for me, so I mirrored them to my server: http://kripton.kripserver.net/dev/pgf_images.zip
Is anything going to happen here?
Joining my previous poster (Felix Büttner): I'm longing for digiKam 1.0 since the day it has been released. Especially the "AdvancedRename" feature is something, I would love to have available! I'm using gentoo for 6 years now, but I have no experience creating ebuilds. But can I help anyway in some way to bring this version into portage?
There is already an ebuild in kde-overlay. Maybe it isn't good enough for the main tree, but it works for me.
digiKam 1.1.0 released > http://www.digikam.org/drupal/node/497 Maybe thing run better with this version...
*** Bug 303163 has been marked as a duplicate of this bug. ***
I'm attaching the digikam-1.1.0 ebuild, the patch to unbundled libpgf and kipi-plugins 1.1.0 ebuild. I tested it here and everything seems fine. The support to pgf files seems to be better now. Jannis, can you test it too? We don't need overexposure-indicator patch anymore right? The only thing that worth to unbundled now is clapack and lprof. The first I couldn't build on my system and the second does not have any version on portage.
Created attachment 218407 [details] Ebuild of digikam-1.1.0 with patch that unbundled libpgf
Created attachment 218409 [details, diff] Patch to unbundled libpgf from digikam-1.1.0
Created attachment 218411 [details] Kipi-plugins-1.1.0 ebuild
*digikam-1.1.0 (05 Feb 2010) + + 05 Feb 2010; Samuli Suominen <ssuominen@gentoo.org> +digikam-1.1.0.ebuild, + +files/digikam-1.1.0-libpgf.patch: + Version bump wrt #295459, thanks to Ronan Arraes Jardim Chagas and others.
I sent a message to digikam mailing list to ask why they are shipping a version of libpgf and I'm pasting the answer: Email from Gilles Caulier sent to digikam mailing list: <START> It's planed to have a way to use an external version of libpgf. I have set an internal version to be sure that code run fine everywhere as Mac or windows, and we have found some internal problem Libpgf is use in production in digiKam and we want to be sure that we have a fine control on it, at least to polish implementation. It will be time to use an external version now, since last publish version work very well... Gilles Caulier <END> So, it seems that libpgf will be unbundled by upstream soon. Maybe they will do what they are doing with LQR, if it finds a version in the system, then the bundled LQR version isn't built and the installed one is used. Otherwise, it builds the shipped LQR version.
(In reply to comment #41) http://sourceforge.net/projects/libpgf/forums/forum/530086/topic/3292859
