rev 5588 - kde-extras/digikam/branches/experimental/debian

Wed Feb 14 22:10:48 CET 2007

Author: ach-guest
Date: 2007-02-14 22:10:47 +0100 (Wed, 14 Feb 2007)
New Revision: 5588

Modified:
   kde-extras/digikam/branches/experimental/debian/TODO
Log:
digikam: remove old cruft from TODO

Modified: kde-extras/digikam/branches/experimental/debian/TODO
===================================================================

--- kde-extras/digikam/branches/experimental/debian/TODO	2007-02-14 21:01:47 UTC (rev 5587)
+++ kde-extras/digikam/branches/experimental/debian/TODO	2007-02-14 21:10:47 UTC (rev 5588)
@@ -1,10 +1,4 @@
-Important 
----------
 
-> 0.9-rc1
-
-  exiv2 digikam will probably need exiv2 0.12. (Release planed ~ 26 Nov)
-
 o lintian: rename to digikam.lintian to test if cdbs install it
 	on it's own.  On Dapper got a changed lintian complain:
 		digikam: package-name-doesnt-match-sonames libdigikam0
@@ -14,10 +8,6 @@
 o digikam.manpage:
 	o document new DCOP calls
 
-o media:
-	check if we depend on other pkgs now that a start of media:/
-	support is added
-
 o digikam uses kio_trash from kdebase-kio-plugins for <Delete>
   A xfce user got bitten by it. <shift>-<delete> should work.
 	+ can a non kde desktop use KDEs trash, and how?
@@ -26,22 +16,11 @@
 	+ Is abose worth  Depends or Recomends or Suggests
   	  for non KDE Desktop installations?
 
-  [toma]  
-  dato notes that it should be an absolute recommends, 
-  frob thinks that should be enough. A similar situation is setup
-  for kmail
+	[toma]  
+  	dato notes that it should be an absolute recommends, 
+  	frob thinks that should be enough. A similar situation is setup
+  	for kmail
 
-o patch/merge upstream (??) Makefile.am to use XDG by default
-  for digikam desktop and remove 'hack' in rules. Does upstream
-  support KDE < 3.2 ?? (showfoto uses XDG location and noone
-  complained about missing K-menu entry)
-
-o send my media service desktop files to digikam-* and ask to
-  test (especially SuSE, that should have correct HAL support
-  for libgphoto2 cameras): Removable camera versus Removable
-  disk
-
-
 Nice to have
 ------------
 
@@ -49,85 +28,6 @@
 	KIPI (loading): KIPI::whatever
   msg on startup in digikam source.
 
-o convert manpages to xml, so hopefully rosetta pick them up
-  and translates them.  Mhmm, manybe enhance text before a bit.
-
-o check menu-xdg if menu file is still needed when desktop file
-  is converted
-
-o check what can be done to make setup of hotplug easier.
-	a) gphoto2 cameras -> Joergs (?) digikam-hotplug script
-	b) mass storage cameras
-
-o relibtoolize digikam & co:
-
-	[20:58] <dato> allee: ping was to suggest you relibtoolizing digikam and related packages, in order to loose some dependencies.
-	[20:58] <dato> not that it matters _much_, but it may save you being removed from testing next time there is a big transition ongoing, as has happened now. :)
-	[20:59] <allee> heh heh ;)
-	[21:00] <allee> what do you mean with relibtoolizing excactly.  More than updating auto* and rebuilding?
-	[21:00] <dato> what do you mean with "updating auto*"?
-	[21:00] <allee> I mean the usual make -f Makefile.cvs
-	[21:01] <allee> use latest version of auto* tools for run make -f Makefile.cvs
-	[21:01] <dato> then, relibtoolizing is like that, but using the latest version of libtool (and a small patch)
-	[21:02] <dato>         cp -f /usr/share/libtool/libtool.m4 $(DEB_SRCDIR)/admin/libtool.m4.in
-	[21:02] <dato>         cp -f /usr/share/libtool/ltmain.sh  $(DEB_SRCDIR)/admin/ltmain.sh
-	[21:03] <dato> and the patch can be found in branches/3.4/common-patches/something_undefined_bla.diff
-	[21:03] <dato> 07_disable_no_undefined.diff
-	[21:04] <allee> Ah, I also remember that someone of the team 'complained' about noone using 'qt-kde' infrastruction.  E.g. common-patches, etc ...
-	[21:04] [Notify] Thucydides is online (irc.de.freenode.net).
-	[21:05] <allee> is amarok or gwenview a good example how to use the infrastruckture (I like learning by example ;)
-	[21:06] <dato> allee: well, amarok runs make -f Makefile.cvs (or similar) at build-time; not everybody likes that.
-	[21:06] <dato> allee: as for common-patches, there's no warrantly they'd apply to your admin/ dir, they're for the admin version of the latest KDE (and your upstream may use an older one).
-
-o check pkg-qt-kde build infrastructure (common-patches and more?)
-
-	[21:04] <allee> Ah, I also remember that someone of the team 'complained' about noone using 'qt-kde' infrastruction.  E.g. common-patches, etc ...
-	[21:04] [Notify] Thucydides is online (irc.de.freenode.net).
-	[21:05] <allee> is amarok or gwenview a good example how to use the infrastruckture (I like learning by example ;)
-	[21:06] <dato> allee: well, amarok runs make -f Makefile.cvs (or similar) at build-time; not everybody likes that.
-	[21:06] <dato> allee: as for common-patches, there's no warrantly they'd apply to your admin/ dir, they're for the admin version of the latest KDE (and your upstream may use an older one).
-	[...]
-	[21:11] <dato> Thucydides: btw, when you have a minute, I'd like to comment on a weird problem I'm having
-	[21:11] <Thucydides> allee: gwenview is a good example. I use all the common-patches except the visibility one, since I don't need it and it doesn't apply.
-
-Digikam > 0.8-beta version notes:
-	o apidox is supposed to work in svn (but API is not
-	  meant for public)
-
-Low priority stuff
-------------------
-
-o split into digikam and libdigikam0-dev.  (lintian complains)
-	--> no need as long as digikamimageplugin is the only external
-	user and upstream release digikam{,imageplugins} always together.
-o check sqlite mods of in tree source against sqlite in Debian
-	(ask Renchi if the last sqlite DSA are incorporated)
-
-	[18:57] <allee> pahli_bar: duplicate included code, possible future security fixes ...
-	[18:57] <pahli_bar> allee: the problem is default sqlite included with most distros doesn't have a) thread support b) utf8 support compiled in
-	[18:58] <allee> pahli_bar: well and not seeing this frighting warings during compile is a bonus too ;)
-	[18:58] <pahli_bar> also, the db format has changed from 2.x to 3.x series. by including in the code, we can ensure the longetivity the format we support
-	[19:02] <allee> pahli_bar: Okay.    Did your changes/optimizations found their way 2.8* upstream?
-	[19:02] <pahli_bar> allee: they are not changes. they are configure time flag includes
-	[19:03] <allee> pahli_bar: oh, my memory has bit flips already :(
-	[19:04] <jokele> pahli_bar: pong
-	[19:04] <pahli_bar> jokele: i got your patch for album history. will look at it carefully later
-	[19:04] <jokele> yep
-	[19:04] <pahli_bar> now, i want to check the exif changes
-	[19:07] <allee> pahli_bar: FWIW: debian 2.8.15-2 rules file has: ./configure ... -DTHREADSAFE=1 --enable-utf8
-	[19:08] <pahli_bar> allee: yes. but you can't trust every distro to do the same
-	[19:08] <pahli_bar> allee: btw, suse applied a patch to use the distro sqlite
-	[19:09] <pahli_bar> which i strongly disagree with. any bugreports related to the db in those situations will be bounced back to the distro maintainer
-	[19:09] <allee> pahli_bar: a nice if debian pkg is 'rock' solid. I'll return to this issue >> debian/TODO
-	[19:09] <allee> pahli_bar: well I'll trust the debian pkg maintainer ;)
-
-	Update 15-Feb: submitted wishlist http://bugs.kde.org/show_bug.cgi?id=99474
-
-	[22:45] <allee> he, he. and add it to debian/patches/ ;)
-	[22:49] <pahli_bar> allee: <a href="http://bugs.kde.org/show_bug.cgi?id=99474">99474</a> will be no-fix
-	[22:50] <allee> pahli_bar: Grmbl.  I suspected this somehow 
-	[22:51] <pahli_bar> allee: the problem is that its difficult to ensure utf-8 compatibility and thread-safety in distribution specific sqlite
-	[22:51] <pahli_bar> allee: otoh, you can copy suse's patch to make use of external sqlite
-	[22:52] <pahli_bar> though i don't recommend it. but its your call
-	[22:52] <allee> no I stick with upstream ;)  Following another source is not easier that stick with what you do
-
+o convert manpages to xml, so hopefully kde-i18n/rosetta pick them up
+  and translates them.  Mhmm, manybe after enhancinging the
+  content a bit.


