Bug#350873: digikam - FTBFS: libtool: link: `/usr/lib/libXft.la' is not a valid libtool archive
On Wednesday 01 February 2006 10:25, Bastian Blank wrote: Package: digikam Version: 0.8.1-1 Severity: serious There was an error while trying to autobuild your package: Hi Bastian, this is not a digikam problem. libXt-dev contains no longer a libXt.la file. So every -dev pkgs that has a .la file refering to libXt.la makes every other pkg, that build-depend on it, FTBFS. AFAIU the disappearance of libXt.la is intentional. So all pkg with with references in libXt.la, need (just) a rebuild to get rid of the reference of libXt.la. I'll do some more checks later and reassing/merge as appropriate. Achim Automatic build of digikam_0.8.1-1 on debian-31 by sbuild/s390 85 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper ( 4.1), cdbs, kdelibs4-dev, libimlib2-dev, libexif-dev ( 0.6.9), libtiff4-dev, libgphoto2-2-dev, libkexif1-dev, libkipi0-dev, automake1.9, libsqlite3-dev [...] /bin/sh ../../../libtool --silent --tag=CXX --mode=link g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE-o libjpegutils.la -L/usr/lib -L/usr/share/qt3/lib -L/usr/X11R6/lib libjpegutils_la.all_cpp.lo -ljpeg -lkexif grep: /usr/lib/libXft.la: No such file or directory /bin/sed: can't read /usr/lib/libXft.la: No such file or directory libtool: link: `/usr/lib/libXft.la' is not a valid libtool archive make[5]: *** [libjpegutils.la] Error 1 make[5]: Leaving directory `/build/buildd/digikam-0.8.1/obj-s390-linux-gnu/digikam/libs/jpegutils' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/build/buildd/digikam-0.8.1/obj-s390-linux-gnu/digikam/libs' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/buildd/digikam-0.8.1/obj-s390-linux-gnu/digikam' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/digikam-0.8.1/obj-s390-linux-gnu' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/digikam-0.8.1/obj-s390-linux-gnu' make: *** [debian/stamp-makefile-build] Error 2 ** Build finished at 20060130-2209 FAILED [dpkg-buildpackage died] Bastian -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350873: digikam - FTBFS: libtool: link: `/usr/lib/libXft.la' is not a valid libtool archive
On Wednesday 01 February 2006 11:48, Achim Bohnet wrote: On Wednesday 01 February 2006 10:25, Bastian Blank wrote: Package: digikam Version: 0.8.1-1 Severity: serious There was an error while trying to autobuild your package: Hi Bastian, this is not a digikam problem. libXt-dev contains no longer a libXt.la file. So every -dev pkgs that has a .la file refering to libXt.la makes every other pkg, that build-depend on it, FTBFS. AFAIU the disappearance of libXt.la is intentional. So all pkg with with references in libXt.la, need (just) a rebuild to get rid of the reference of libXt.la. I'll do some more checks later and reassing/merge as appropriate. He,he. Rebuilding libkipi and libkexif, to get rid of their libXft.la references, is enough to get digikam build again. What a coincidence that the'KDE Extras Team' has relibtoolized version of both ready. So I'll ask my sponsor to upload. Saves RMs a bit of work. Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290111: digikamplugins: FTBFS: Cannot find headers
package digikamplugins tags 290111 + pending stop thx Hi Daniel, thx for the report. That's an incomptibility with digikam 0.7 (and 0.7 obsoletes digikamplugins). when KDE 3.3 went into sarge and in it's tail digikam 0.7. Therefore digikam 0.6.*, the only user of digikamplugins, 'vanished'. We did not request to remove or conflict with digikamplugins yet, because it's successor kipi-plugin is still hanging in NEW queue (unfortunate circumsances (my fault) prevented kipi-plugins to enter sid before digikam 0.7 was uploaded. When kipi-plugins enters sid, we'll upload a new dummy digikamplugins pkgs that depends on kipi-plugins (just to smooth updates). Short before sarge release we'll then request the removal of digikamplugins. So bug will be closed with next digikamplugins upload - tags pending. Hope that's okay with you to 'not fix' the bug until kipi-plugins enters sid. I think uploading a empty fake digikamplugins with prio high until kipi-plugins enters sarge is overkill. Achim From my build log, using pbuilder in an ia32 chroot: ... make[3]: Entering directory `/tmp/buildd/digikamplugins-0.6.2/acquireimages' if /bin/sh ../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/kde -I/usr/share/qt3/include -I. -DQT_THREAD_SUPPORT -D_REENTRANT -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -MT plugin_acquireimages.lo -MD -MP -MF .deps/plugin_acquireimages.Tpo \ -c -o plugin_acquireimages.lo `test -f 'plugin_acquireimages.cpp' || echo './'`plugin_acquireimages.cpp; \ then mv -f .deps/plugin_acquireimages.Tpo .deps/plugin_acquireimages.Plo; \ else rm -f .deps/plugin_acquireimages.Tpo; exit 1; \ fi In file included from plugin_acquireimages.cpp:46: plugin_acquireimages.h:28:34: digikam/albummanager.h: No such file or directory plugin_acquireimages.h:29:31: digikam/albuminfo.h: No such file or directory plugin_acquireimages.h:30:28: digikam/plugin.h: No such file or directory In file included from plugin_acquireimages.cpp:46: plugin_acquireimages.h:39: error: `Digikam' is not a class or namespace plugin_acquireimages.h:40: error: `Plugin' is not a class or namespace ... make[3]: *** [plugin_acquireimages.lo] Error 1 make[3]: Leaving directory `/tmp/buildd/digikamplugins-0.6.2/acquireimages' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/buildd/digikamplugins-0.6.2' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/digikamplugins-0.6.2' make: *** [build-stamp] Error 2 -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.9-9-amd64-k8 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- Daniel Schepler Please don't disillusion me. I [EMAIL PROTECTED]haven't had breakfast yet. -- Orson Scott Card -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290111: digikamplugins: FTBFS: Cannot find headers
On Tuesday 18 January 2005 12:55, Steve Langasek wrote: If this package is obsoleted by digikam 0.7, what reason is there to wait before asking for its removal? To me, obsoleted means doesn't work. Hi Steve, the plugins 'work' but no package use the plugins anymore. As I tried to explain in my last msg, I would like to upload a dummy digikamplugins pkg, that just depends on kipi-plugins as 'soon' as kipi-plugins enters sid (currently still pending in NEW queue). That's just to smooth upgrade. Some weeks before pkg freeze, my plan was ask for the digikamplugin removal. If you, as RM, think the timescales are too short let me know and I'll submit a bugreport for removal to ftp-masters now. Achim -- Steve Langasek postmodern programmer -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290111: digikamplugins: FTBFS: Cannot find headers
Update: I've ask the ftp master for removal of digikamplugins. See #295363. Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332827: digikam: Missing Depends on libsqlite3-dev
reassign 332827 digikam digikamimageplugins tags 332827 +pending thanks Hi Kurt, because libdigikam is only shared between digikam and digikamimageplugins (see #324592). I added a build-deps libsqlite3-dev to digikamimageplugins instead of a depends to digikam. This way the dependency kicks in only during build time when it's really needed. Fix in svn. Upstream will release rc1 real soon now (tm) Achim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299709: digikam: Fails to install
On Tuesday 15 March 2005 23:13, Benoît Deville wrote:
Package: digikam
Version: 0.7-3
this should be 0.7.2-1 *duck*
Severity: grave
Justification: renders package unusable
Says it depends on libkexif1 which seems not to be installable.
Yes. Sorry! It was a sad stupid accident that 0.7.2 was uploaded.
Sorry! libkexif1 is pending in debians NEW queue waiting for
approval.
Until libkexif1(and -dev) enters sid you can
o set digikam pkg to hold state to avoid error in
future apt-get (dist-)upgrade runs.
or
o add 'deb http://www.mpe.mpg.de/~ach/debian/experimental ./'
to get a set of digikam* kipi-plugins* and libkexif1 pkgs
that installs.
As 'soon' as libkexif1{,-dev} pkgs enters sid we'll upload
this set of pkgs. [1]
Sorry again for the trouble,
Achim
[1] showimg also needs to be rebuild against libkexif1. I've contact
the DD already. So everything will ready in time.
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- [EMAIL PROTECTED]
Bug#299709: Shall I upload libexif1 to unstable
On Tuesday 22 March 2005 22:53, Steve Langasek wrote:
On Tue, Mar 22, 2005 at 08:46:17PM +, Mark Purcell wrote:
Now that libikexif1 has hit experimental shall I upload the release
version to unstable?
Both libkexif1 libkexif0 can co-exist in unstable together and
libkexif0 won't be removed until all reverse dependancies are taken care
of.
That's not true; libkexif0 and libkexif1 are both built from the libkexif
source package, so if you upload the experimental version of libkexif to
unstable, the old libkexif0 binaries will be removed.
Another reason to coordinate the libkexif upload with a showimg update.
I contacted Jean-Michel (DD of showimg, cc'ed) Monday last week via mail
already. This Monday I've prepare a deb (#300813). No response yet.
When Jean-Michel is ready we should (re)upload libkexif to sid together
with showimg, rebuild kipi-plguins and digikamimageplugins 0.7.2.
If you change the source package name, it will have to go through NEW
processing, AFAIK (and probably be rejected for a gratuitous name change).
When libkexif1{,-dev} is in sid (and later maybe even testing)
there's no need to have libkexif0{,-dev} binary pkgs.
$ apt-cache rdpends libkexi0
libkexif0
Reverse Depends:
digikam
showimg
libkexif0-dev
kipi-plugins
Given how few packages depend on this library, and given that one of them is
already broken, there's probably no reason to hold off on uploading the new
libkexif to unstable.
Short story:
This implies: broken digikam versus maybe will be broken showimg on arch !=
i386.
I was of course tempted but I resisted because I'm not involved in showimg
pkging.
Long version:
digikam 0.7.2, links against libkexif1 and conflicts with kipi-plugins and
digikamplugins in sid (linked against libkexif1). Therefore the 'need'
to upload libkexif1, and rebuild kipi-plugins and digikamplugins (that link
against libkexif1) in one go. [Everything already prepared in
http://www.mpe.mpg.de/~ach/debian/experimental (with dist = sid)]
But in this case showimg links against libkexif0 and would use kipi-plugins
that use libkexif1 :( This combination does not crash gwenview on i386
because the dynamicly loaded kipi-plugins use only the part of libkexif
that has not changed between libkexif 0 and 1. No idea show other archs
act with such a libkexif0/1 combination.
I hope Jean-Michel find soon time for a new showimg deb as e.g. prepared in
#300813
Achim
--
Steve Langasek
postmodern programmer
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299709: Shall I upload libexif1 to unstable
On Thursday 24 March 2005 15:41, Mark Purcell wrote: [...] I intend to upload libkexif1 and rebuilt kipi-plugins and digkameplugins to unstable. They will all sit in unstable until showimg is uploaded to unstable at which time they can all migrate to testing together. I don't want to wait on this any longer. showimg can catch up when it is ready. Okay. I have some cosmetic changes on disk. I'll checkin tonight. Achim Mark -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305566: digikam: hangs when trying to display larger albums
Hi Markus, What is huge? How many pictures? Total size of pictures? If you used a digikam version before that did not show the problem, which version? Thx, Achim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305566: digikam: hangs when trying to display larger albums
On Wednesday 20 April 2005 23:32, Markus Schatzl wrote: Hi Achim, What is huge? How many pictures? Total size of pictures? Not that much, actually. About 10 pictures at ~1MB suffice to trigger the issue. Hmm, only 10 thumbnails only? All my albums have more (all 150). No problem here. But meanwhile (sorry for not checking this before) I found out that not the filesize raises the problem, it seems to be the displaying of them, i.e. the thumbnails. BTW, it's typical that some of the thumbnail-placeholders to remain empty before digikam starts to eat up all CPU-time. This sounds more like a 'broken' image triggering digikams memory consumption to go out of bounds. Is it always the '8th' pic that triggers it of only one of the 10 pictues? I exchanged the pictures from the said 10/1MB album with 10 4K gifs and got the freeze again. When I deleted 2 of them and started digikam again, everything was ok. Changing the thumbnail display size made it possible to scroll down a bit where otherwise the mere show()ing of the first few images triggered the bug. What happens when you looks at the folder with other tools like gwenview, showimg, konqueror? What other pkgs did you install together with and after the digikam 0.7.2 upgrade (ls -ltr | tail -50)? Can you tar the album with the 10/4k gifs and attach it to the bug report? Achim P.S. I've build a 0.7.3-beta1 deb with the patch applied but now digikam and kio_thumbnails use each 50% CPU on the first thumbnail creation of an little AVI movie :(:( If you used a digikam version before that did not show the problem, which version? I set up that box completely anew about 2 months ago. The version that ran on UNSTABLE on the old disk worked fine. Since 0.7.2 went to unstable not before Feb 16 it must have been 0.7-x or 0.7.1. So it was 0.7.0. But I doubt that the digikam upgrade triggered the problem. What other pkgs did you install together with and after the digikam 0.7.2 upgrade (ls -ltr | tail -50)? Can you tar the album with the 10/4k gifs and attach it to the bug report? If you need more infos, don't hesitate to ask. I did not ;) Achim P.S. I've build a 0.7.3-beta1 deb with the patch applied but now digikam and kio_thumbnails use each 50% CPU on the first thumbnail creation of an little AVI movie :( Thanks in advance, /Markus -- A: No. Q: Should I include quotations after my reply? -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305566: digikam: hangs when trying to display larger albums
package digikam
severity 305566 normal
stop
I've copied your gif-samples to a new digikam folder
and digikam 0.7.2-2 displayed all 10 thumbnails after
some seconds without problem. Copied 200 other pkgs
into the folder still no problems. So I can't reproduce
here. Considering that almost all user have albums
with 10 pic I set the severity of the bug to normal.
Can you try to mkdir a new digikam album, tar x your
tar ball to it and start digikam? Maybe your original
folder somehow corrupted?
What other pkgs did you install together with and after the
digikam 0.7.2 upgrade (ls -ltr | tail -50)?
You probably mean this:
No, but I missed the dir: ls -ltr /usr/share/doc | tail -50
Sorry. Increase 50 until you see the jump in time before
digikam was installed.
cd /var/cache/apt/archives
find . -anewer digikam_0.7.2-2_i386.deb -exec ls -l \{\} \;
the downloaded debs preserve their date so they are not related
to the installation/download time.
Achim
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324592: digikam: Libraries should be split in a lib and -dev package.
On Monday 22 August 2005 23:38, Kurt Roeckx wrote: [Sorry for my (too) late response. Just returned from holidays.] Package: digikam Version: 0.7.4-1 Severity: serious Hi, Your package has a shared library in it: /usr/lib/libdigikam.so Hi Kurt, technically it's a shared library, but it was never intented to be used as a library for others by upstream! It's just a container to share code as needed between digikam, showfoto (pkg digikam) and digikamplugins. And this code changes continuesly!! You need to split the package so that the symlink and headers and things like that are in a -dev package that depends on the package with the lib in it. Other package like digikamimageplugins will then need to build-depend on the -dev package. That makes no sense IMHO as upstream changes contents and breaks API and ABI as needed. This happened with every minor release in the 0.6.*, 0.7.* and upcoming 0.8 release (exception 0.7.4 which was an translation documentation update) Please see things like the debian policy (section 8, 10.2) and maybe the Debian Library Packaging guide. Before 0.7 pkging I spend quite some time reading them both (and FHS) with respect to this lib/-dev stuff. None of the advantages and needs for the split apply is this case. As I wrote, there's no API or ABI promise. It's just a container to share code between tighly coupled pkgs that are, if API, ABI changes, are always released together (that's the only promise from upstream!!). Also, you have a .la file in it. So the -dev package will need to make sure that all other .la files referenced in it get installed too by adding the correct Depends. They only 'benefit' from lib and -dev split is more pkg# bloat, with every minor release, more useless (IMHO) maintainer work and last but not least ftp-master is always pestered because of a NEW and obsolete lib pkg. And last but not least that everyone dare to use the lib and dev pkgs will be disappointed due to the continous API breakage. If I miss a/the point, please let me know. Otherwise I would like reopen/downgrade/won't fix this bug and revert the split until upstream decides to maintain libdigikam as a real shared library with a proper maintained API and version handling. PS: I recommend you upgrade the libtool version in the package to the version in debian. The one you're using is rather old. AFAIU KDEs build system uses it own forked version of libtool. No good idea to poke around there. Any change needed here should be done upstream because almost every KDE appl release uses the build code used in KDE svn. Achim Kurt -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401513: [Pkg-kde-extras] Bug#401513: libkexif: FTBFS: Tries to regenerate autofiles
I shall try and upload with a dependancy on autotools tonight. Mhmm, we still patch Makefile.am's. So adding updated 098_buildprep.diff will fix it as well (and is idempotent, i.e., the diff of a second build run is not cluttered with lots of e.g. Makefile.in changes.) AFAIU kde.mk has now only a buildprep target, so a buildprep rule in debian/rules is not necessary anymore. but buildprep.diff is still needed. I'll upload a new diff later. Feel free to remove it and add a dependency instead. Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366933: [Pkg-kde-extras] Bug#366933: libkipi - FTBFS: error: libkipi/interface.h: No such file or directory
On Friday 12 May 2006 09:58, Bastian Blank wrote: Package: libkipi Version: 0.1.3-1 Severity: serious There was an error while trying to autobuild your package: Hi Bastian, I had alreaday a look at the m68k failure yesterday, which fails for the same reason :( Automatic build of libkipi_0.1.3-1 on debian01 by sbuild/s390 85 [...] g++ -DHAVE_CONFIG_H -I. -I/build/buildd/libkipi-0.1.3/./libkipi/libkipi -I../.. -I. -I/usr/include/kde -I/usr/share/qt3/include -I. -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -Wall -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -c libkipi_la.all_cpp.cpp -fPIC -DPIC -o .libs/libkipi_la.all_cpp.o In file included from /build/buildd/libkipi-0.1.3/./libkipi/libkipi/interface.cpp:32, from libkipi_la.all_cpp.cpp:2: /build/buildd/libkipi-0.1.3/./libkipi/libkipi/pluginloader.h:25:31: error: libkipi/interface.h: No such file or directory [...] make: *** [debian/stamp-makefile-build] Error 2 ** Build finished at 20060510-2356 FAILED [dpkg-buildpackage died] Bug seems obvious. Includedirs miss -I.. and -I$(srcdir)/.. but when I build libkipi in an svn checkout there are additional -I../../libkipi -I../../../libkipi if /bin/sh ../../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../libkipi/libkipi -I../.. -I. -I../../libkipi -I../../../libkipi -I/usr/include/kde -I/usr/share/qt3/include -I. -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long ... At least in Kubuntu/Dapper when I delete libkipi*-dev and debuild 0.1.3 it fails too. Ditto for plain configure; make. Same on me. kde-imaging developers: does configure; make with libkipi-0.1.3 work for you when you remove _all other_ installations of libkipi from the system, so the only kipi header files are in the srcdir or libkipi? I'm a bit confused by the fact that an build from svn works. If other system break too. We should add something INCLUDES = -I.. -$(srcdir)/.. more here? $(all_includes) in libkipi/libkipi/Makefile.am I can only look into this later. No time right now. Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366933: Fixed Re: [Pkg-kde-extras] Bug#366933: libkipi - FTBFS: error: libkipi/interface.h: No such file or directory
tags 366933 +pending stop I've commited a fix upstream and to alioth. Pbuilds fine. --- libkipi/libkipi/Makefile.am (revision 540612) +++ libkipi/libkipi/Makefile.am (revision 540613) @@ -1,5 +1,5 @@ METASOURCES = AUTO -INCLUDES= $(LIBKIPI_CFLAGS) $(all_includes) +INCLUDES = -I.. -I$(srcdir)/.. $(LIBKIPI_CFLAGS) $(all_includes) KDE_ICON = kipi Mark please upload. Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396747: FTBFS (alpha): attempt to use output operater '' on va_list
Hi Falk, thx for the report. I've asked upstream for a fix. Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401416: [Pkg-kde-extras] Bug#401416: pending upload of digikam-0.8.2
[not cc'ed to debian-release and exiv2] On Thursday, 21. December 2006 16:46, Marc 'HE' Brockschmidt wrote: [...] From what I can see, this is fine. bugs.d.o doesn't report anything unusual, but I would love to know if #393505 and #396249 are fixed in 2:0.8.2-2. FWIW: a quick try of an alioth svn trunk build on kubuntu/Edgy (kde3.5.5), shows that both bugs are fixed. (I've seen the crash in kubuntu/dapper before) #396249 libgphoto2-2-dev needed I saw this problem on Kubuntu/Dapper too. On Edgy it's gone. Quick test and strace double check: as root: cd /usr/lib/libgphoto2/2.2.1 mkdir x mv *.la x/ as user: strace -o x.x digikam #open list of cameras that can be added grep /usr/lib/libgphoto2/2.2.1 x.x .. open(/usr/lib/libgphoto2/2.2.1/spca50x.la, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib/libgphoto2/2.2.1/spca50x.so, O_RDONLY) = 17 .. as root mv x/* . rmdir x #393505 digikam: Crashes on assigning icon to tag works here without crash too. I've tried RMB menu of Tags tab on the LHS and RMB menu of Filter Tags on the RHS using 'Add Tag ...' menu item add a tagname click on icon button choose an (application) icon via double click add the new tag via [ok] button = icon is added, no crash If you use another method to add icons to tag Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429466: gwenview crashed on menu entering
On June 18, 2007 05:39:48 Paul Romanchenko wrote: [...] Versions of packages gwenview recommends: ii kdegraphics-kfile-plugins 4:3.5.7-2 KDE metainfo plugins for graphic f ii kipi-plugins 0.1.3-4image manipulation/handling plugin kipi-plugins 0.1.3-4 is linked against libexiv2-0.12 with is incompatible to libexiv2-0 used by gwenview. Please upgrade kipi-plugins to 0.1.3-5. Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430863: digikam: Bus error on startup
On Wednesday, 27. June 2007, Marcus Better wrote: Package: digikam Version: 2:0.9.2~beta3-1 Severity: grave Digikam doesn't start anymore after upgrading to this version: can you try 0.9.2-2, that was uploaded yesterday to sid? Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
