Version: 2.1.0 OS: Linux When trying to start digikam 2.1 first time, it told me that the database were broken, but it would try to reconnect, then went into eternal doing nothing. I killed the process and downgraded to 2.0 which runs fine. Is there a secret migration tool like in kmail? Or something I can do to make it work? My database contains years of tagged files, so I really do not want to risk it! Reproducible: Didn't try Steps to Reproduce: bko is broken Actual Results: bko is broken Expected Results: bko is broken OS: Linux (i686) release 3.0-ARCH Compiler: gcc
> When trying to start digikam 2.1 first time, it told me that the database were > broken, but it would try to reconnect, then went into eternal doing nothing. I > killed the process and downgraded to 2.0 which runs fine. Sounds like MySQL, but you may want to tell us explicitly which database system you are using > Steps to Reproduce: > bko is broken > > Actual Results: > bko is broken > > Expected Results: > bko is broken ??
Same seen in Gentoo after the upgrade, at some point I gave up and "fixed" it by wiping my database and entire digikam settings. I know this is not particularly informative... :|
same happened to me but after reinstalling dk and reboot ubuntu and after clicking cancel in the automatic reconnection proces it started, with rereading the whole database. This tread maybe related http://mail.kde.org/pipermail/digikam-users/2011-September/014211.html Rinus
@Marcel: I do not know what database system I am using. I thought digikam used sqlite? @Rinus: Sounds good, but the message I got after pressing cancel was that it would start with not database at all, leading me to back out immediately. I wonder if there is an organized way to do a backup in digikam?
The relevant section of digikamrc looks like this: [Database Settings] Database Connectoptions= Database Hostname= Database Name=/home/anders/Pictures/ Database Name Thumbnails=/home/anders/Pictures/ Database Password= Database Port=-1 Database Type=QSQLITE Database Username= Internal Database Server=false
Anders: Yes you are using SQLite (if someone doesn't know what he's using, it's SQlite ;-) ) Database (SQLite) was broken starting from 37f5f5 (Sep 6th), sharply after the 2.1 tag, until 0ef128 (Sep 10th). Current git works again, I am using SQLite myself. I hope the 2.1 tag is precise and the broken commit is not included in the tarball.
Nicolas, Can you confirm that commit #37f5f5 has not been included in your 2.1.0 tarball ? Gilles Caulier
If it's any help. I attached a diff between current git and the 2.1 tar-ball source code of core/libs/database/. Not sure what the #37f5f5 commit is. /Philip On Sun, Sep 11, 2011 at 3:56 PM, Gilles Caulier <caulier.gilles@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=281767 > > > Gilles Caulier <caulier.gilles@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |neoclust.kde@free.fr > Component|general |Database > > > > > --- Comment #7 from Gilles Caulier <caulier gilles gmail com> 2011-09-11 13:56:07 --- > Nicolas, > > Can you confirm that commit #37f5f5 has not been included in your 2.1.0 tarball > ? > > Gilles Caulier > > -- > 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 > Digikam-devel@kde.org > https://mail.kde.org/mailman/listinfo/digikam-devel >
Created attachment 63560 [details] Diff Digikam 2.1 tarball and current git
(In reply to comment #7) > Nicolas, > > Can you confirm that commit #37f5f5 has not been included in your 2.1.0 tarball > ? > > Gilles Caulier 37f5f5d5 is definitely included in the tarball that I downloaded from sourceforge and that went into the Gentoo mirror system. :(
(In reply to comment #10) > (In reply to comment #7) > > Nicolas, > > > > Can you confirm that commit #37f5f5 has not been included in your 2.1.0 tarball > > ? > > > > Gilles Caulier > > 37f5f5d5 is definitely included in the tarball that I downloaded from > sourceforge and that went into the Gentoo mirror system. :( PS. Just as a personal remark, it might be useful if you guys would be hanging out at #digikam for a while after making a release tarball... the packager chatter there is quite constructive...
Created attachment 63562 [details] Diff between git tag v2.1.0 and digikam-2.1.0 tarball, core subdirectory
(In reply to comment #12) > Created an attachment (id=63562) [details] > Diff between git tag v2.1.0 and digikam-2.1.0 tarball, core subdirectory It's getting worse. I patched the code back to the exact state of the 2.1.0 tag, and re-installed digikam on my local box. With the database that was touched by the 2.1.0-tarball version, the 2.1.0-tag version immediately crashes with a segfault. So whoever managed to update to 2.1.0-tarball cannot go back to 2.1.0-tag. Thread 1 (Thread 0x7f97466af800 (LWP 28924)): [KCrash Handler] #6 Digikam::DatabaseCoreBackend::setDatabaseErrorHandler (this=0x0, handler=0x2184820) at /var/tmp/portage/media-gfx/digikam-2.1.0-r2/work/digikam-2.1.0/core/libs/database/databasecorebackend.cpp:1624 #7 0x0000000000589bc9 in Digikam::AlbumManager::setDatabase (this=0x208c930, params=..., priority=<value optimized out>, suggestedAlbumRoot=...) at /var/tmp/portage/media-gfx/digikam-2.1.0-r2/work/digikam-2.1.0/core/digikam/album/albummanager.cpp:726 #8 0x000000000067f423 in main (argc=33553984, argv=0x7fff0000001d) at /var/tmp/portage/media-gfx/digikam-2.1.0-r2/work/digikam-2.1.0/core/digikam/main/main.cpp:185
that's because only a little part of 37f5f5d5 is part of 2.1.0 tarball, the patch was already sligtly broken, but having only a little part of it make stuff definitly broken. What happened here? should have waited one day more to commit? too near to the tagging? Or the tarball has not been created from the tag? Damn, I've waited two week to commit only to have one full month for testing :( Anyway, seem solved downstream in gentoo with media-gfx/digikam-2.1.0-r2
This is the story : When 2.1.0 have been tagged by Nicolas, the release have been delayed from few days, due to some problems to compile libkvkontakte with kipi-plugins. We have talk about by mail for a long time to find the right solution. We all have been fixed, I don't know if tarball have been rebuild from git master. Gilles Caulier
> Anyway, seem solved downstream in gentoo with media-gfx/digikam-2.1.0-r2 Yeah... In Gentoo -r2 is now exactly the tag, not the tarball, so who goes from 2.0.0 to 2.1.0-r2 should be fine. I just hope not too many people installed -r1 and used the database with it, luckily it was only one day. Right now -r1 does not upgrade to -r2 automatically (I set this because of above crashes), but we have to figure out what to do there... Then, of course, I see in the cc list someone from fedora and in the comments arch and ubuntu... :| Please please make a 2.1.1 ...
Gilles, then we should remove/deprecate the tarball on sourceforge ASAP, it's still downloadable and it's clearly broken, inside there is part of my patch plus other (random?) changes. I've checked this downloading it right 5 min. ago Gentoo work because it revert by patch. At a minimum we need the andreas patch: http://vserver.13thfloor.at/Experimental/patch-3.0.4-vs2.3.1-pre10.1.diff but some more check would not be too bad.
Nicolas, is in copy here. I waiting comments from him release 2.1.1 soon. Gilles Caulier
One more note: Since old database settings are not deleted, just copyed and splitted; users which didn't changed database settings in the meantime should be safe. Looking at the users messages and screenshots in digikam-users there are various degrees of tainting, seem that different distro used different commits for the 2.1.0 snapshot (at least one must have my full patch) those that cannot start the first time after upgrade but that can work after the second launch for example have the full patch. Anyway I'll definitely wait more time to commit after a tag the next releases. Nicolas, just to be sure, please none of my commits should slip into 2.1.1. If some of the files is positive to the 'tmb[A-Z]' pattern, then it's tainted.
Just to be clear : If 2.1.1 release must be done, it safe to use current git master to do it ? Gilles Caulier
(In reply to comment #20) > Just to be clear : > > If 2.1.1 release must be done, it safe to use current git master to do it ? > > Gilles Caulier No, we should revert, see also bug 281838, there are only two commit for splitted DB, one is mine, the other is from Marcel.
Francesco, So, what's the last commit ID to include in 2.1.1 tarball ? Gilles
git clone -l ../digikam-sc/core/ git checkout v2.1.0 which give the exact tagged 2.1.0 version is fine for me, there are other changes in released tarballs, I cannot speak for those. P.S. the link at c#17 is obviously a cut&paste error, it should be http://dev.gentoo.org/~dilfridge/distfiles/digikam-2.1.0-tag.patch.bz2
Thanks Francesco, I sent a private mail in French to Nicolas (at Mandriva) about this entry. I hope that he will take a look soon... Gilles
(In reply to comment #23) > git checkout v2.1.0 (...) > http://dev.gentoo.org/~dilfridge/distfiles/digikam-2.1.0-tag.patch.bz2 ^ that's more or less just what I did to make the patch, yes. (I checked out the tag v2.1.0 of digikam.git, replaced the core directory in the tarball with the checkout, and then diffed against the original tarball.)
I just recieve a response from Nicolas. He will rebuild tarball using 2.1.0 tag. Gilles Caulier
Hi, I'm a Gentoo-user that has digikam-2.1.0-r1 installed right now. I use a MySQL-database and I remember that I ran the version once and did not have any problems. Nevertheless I do not want to try again just for the sake of knowing it exactly. What shall I do now? Unmerge and emerge the new version? Will my database work with 2.1.0-r2? Is there a Gentoo bug# for this problem?
(In reply to comment #27) > Hi, I'm a Gentoo-user that has digikam-2.1.0-r1 installed right now. I use a > MySQL-database and I remember that I ran the version once and did not have any > problems. Nevertheless I do not want to try again just for the sake of knowing > it exactly. > What shall I do now? Unmerge and emerge the new version? Will my database work > with 2.1.0-r2? Is there a Gentoo bug# for this problem? Hi, 1st) to be on the safe side, please dump your databases with mysqldump 2nd) edit ~/.kde4/share/config/digikamrc, the section [Database Settings] should contain only the following: [Database Settings] Database Connectoptions= Database Hostname= Database Name=digikam Database Name Thumbnails=digikam Database Password=digikam Database Port=0 Database Type=QMYSQL Database Username=digikam no Image* or Thumbnails*, if these are present remove them also check that values in there are correct. 3rd) additionally if using different databases for "Database Name" and "Database Name Thumbnails" please consider merging the two in only one. There are know bugs that will be fixed in 2.2.0 when using mysql and differrent databases. 4th) emerge -C =digikam-2.1.0-r1 && emerge -a =digikam-2.1.0-r2 I'm installing digikam-2.1.0-r1 right now for an in depth look, will report here if other steps are required
Thanks for the information. Database has been dumped while writing #27 here. Since I have the thumbnails and the other infos all in one database I'm confident there won't be much trouble. However, I won't do anything until tomorrow when the situation has been cleared up further. Thanks for all you work :D
Steps in Comment #28 are confirmed and sufficient and - no data loss is involved - small addition to 2rd): "Internal Database Server=false" should be kept (it's re-created but to be safe keep it) and explanation: those settings will be used in future versions of digikam, if they are unset then DK will read the old settings and migrate to new config. If instead the settings are present it will simply plain using it, then if the "old" settings have been changed by an "old" version of DK the changes will be lost, not inside the database, but DK will start a different database than the most recent one. "old" digikam mean version < 2.2.0 with exclusion of 2.1.0-r1 (or whatever 2.1.0 your distro provided) explanation for 3rd) is @ bug #277242 P.S. Possibly there is a thumbnails db tainting your image db but should do no harm if not on the database size.
Hello, Please test this tarball ( http://kenobi.mandriva.com/~neoclust/digikam-2.1.1.tar.bz2 ) and tell me if it works OK. If OK i will upload it on sourceforge.
Message read, I report back within 48 hours at max. Op 14-09-11 09:59, Nicolas L. schreef: > https://bugs.kde.org/show_bug.cgi?id=281767 > > > > > > --- Comment #31 from Nicolas L.<neoclust kde free fr> 2011-09-14 07:59:42 --- > Hello, > > Please test this tarball ( > http://kenobi.mandriva.com/~neoclust/digikam-2.1.1.tar.bz2 ) and tell me if > it works OK. > > If OK i will upload it on sourceforge. >
Is the tarball mentioned in comment 31 still current?
work for me on gentoo diff digikam-2.1.0-r1.ebuild digikam-2.1.1.ebuild 26c26 < KEYWORDS="" --- > KEYWORDS="~amd64 ~x86" 41,42c41,42 < >=media-libs/libkface-${PV} < >=media-libs/libkgeomap-${PV} --- > >=media-libs/libkface-2.1.0 > >=media-libs/libkgeomap-2.1.0 cosmetical, for the next time, we should ignore the following files: find . -name "*~" ./.gitslave~ ./core/CMakeLists.txt~ ./extra/kipi-plugins/CMakeLists.txt~
@ Will #33 : it will become the new one, to fix older 2.1.0 Please compile, test, and report... Gilles Caulier
@Nicolas, #31 : tarball compile fine here... Gilles Caulier
Works here on Arch Linux. +1 for release.
Op 14-09-11 09:59, Nicolas L. schreef: > https://bugs.kde.org/show_bug.cgi?id=281767 > > > > > > --- Comment #31 from Nicolas L.<neoclust kde free fr> 2011-09-14 07:59:42 --- > Hello, > > Please test this tarball ( > http://kenobi.mandriva.com/~neoclust/digikam-2.1.1.tar.bz2 ) and tell me if > it works OK. > > If OK i will upload it on sourceforge. > Can anyone tell me hoe to get the thing to download. Access forbidden! You don't have permission to access the requested object. It is either read-protected or not readable by the server. If you think this is a server error, please contact the webmaster <mailto:root@localhost>. Error 403 kenobi.mandriva.com <http://kenobi.mandriva.com/> Apache/2.2.15 (Mandriva Linux/PREFORK-3.3mdv2010.2) Rinus
damn mandriva infrastructure, i put somewhere else now.
you can take the tarball here now : ryu.zarb.org/~neoclust/digikam-2.1.1.tar.bz2 ( this is the same tarball )
seems good feedbacks, i will upload within one hour except if i have a bad feedback until this .
I would have prefered a little more extinsive testing, but as I see there is a little pressure. My findings sofar. I have ran several test on different setups. Two on fysical 32 and 64 bit and two on virtual machines, all runnung Ubuntu 11.04 setups some with kde 4.6.2 and others Kde 4.7.0. In all variaties nothing unusual or any suspicious behaviour detected. All existing databases opened as expected. Done several database activities, followed by successful integrety check. Several main activities tested, such as opening several formats in image editor, doing some Image manipulations, opening in batch cue manager, slideshow, lighttable etc etc. from compilation to using all went well. Rinus Op 14-09-11 18:14, Nicolas L. schreef: > https://bugs.kde.org/show_bug.cgi?id=281767 > > > > > > --- Comment #41 from Nicolas L.<neoclust kde free fr> 2011-09-14 16:14:42 --- > seems good feedbacks, i will upload within one hour except if i have a bad > feedback until this . >
version 2.1.1 is now available on sourceforge. thanks all for your tests.
(In reply to comment #28) Hi Francesco, on the Gentoo [*] bug some users have been asking about the procedure as in comment #28 but for the sqlite backend- any clues? Best, Andreas [*] https://bugs.gentoo.org/show_bug.cgi?id=382617
> (In reply to comment #28) > > Hi Francesco, > > on the Gentoo [*] bug some users have been asking about the procedure as in > comment #28 but for the sqlite backend- any clues? > > Best, Andreas > > [*] https://bugs.gentoo.org/show_bug.cgi?id=382617 (In reply to comment #8) > The instructions in the link that is provided unfortunately only apply to mysql > databases. > Could you please also explain the procedure for SQlite databases? > Or is there no problem in this case? For sqlite the procedure could be this: 1st) to be on the safe side, copy the digikam4.db thumbnails-digikam.db files (thumbnails-digikam.db can easily be recreated but on a large collection it take some time) 2nd) edit ~/.kde4/share/config/digikamrc, the section [Database Settings] should contain only the following: [Database Settings] Database Connectoptions= Database Hostname= Database Name=/a/path/to/dir Database Name Thumbnails=/a/path/to/dir Database Password= Database Port=0 Database Type=QSQLITE Database Username= Internal Database Server=false no Image* or Thumbnails*, if these are present remove them also check that values in there are correct. 3rd) N/A 4th) emerge -C =digikam-2.1.0-r1 && emerge -a '>=digikam-2.1.1' Step 2) is not immediately needed but leaving the cruft there can create problems if and when we switch to this schema of config options. (In reply to comment #44)