|
Description
Francois Andriot
2013-01-19 04:59:18 CST
tdebase 3.5.13.2 FTBFS because of missing "demangle.h" . This file is not provided by any package. [ 87%] /dev/shm/BUILD.el5.x86_64/trinity-tdebase-3.5.13.2/kdesktop/lock/backtrace_symbols.c:57:22: error: demangle.h: No such file or directory On Debian / Ubuntu (and some others) is demangle.h in binutils-dev. However, the ability to generate backtrace in kdesktop_lock integrated exception handler will be necessary to make optional. Created attachment 1078 [details]
kdelibs 3.5.13.2 : missing quotes in CMakelists.txt cause invalid syntax
> tdebase 3.5.13.2 FTBFS because of missing "demangle.h" . This file is not
> provided by any package.
Refer to bug report 1363. :)
My current work-around:
# This commit causes a build failure in some distros, including Slackware. The commit only
# adds troubleshooting code.
if [ ! -f /usr/include/demangle.h ]; then
cat $CWD/786e248c.diff | patch -p1 --reverse --verbose --no-backup-if-mismatch || exit 1
fi
Created attachment 1079 [details]
kdelibs 3.5.13.2 : fix openexr include flags
Under Fedora 18, the variable OPENEXR_INCLUDE_DIRS contains 2 directories, separated by ";" .
OPENEXR_INCLUDE_DIRS=/usr/include/OpenEXR;/usr/include/libdrm
It causes a syntax error in CMakeList.txt .
The patch fixes this.
Created attachment 1080 [details]
kdebase 3.5.13.2 : fix smbclient library detection
Under Fedora 18, samba V4 include are located under /usr/include/samba-4.0 . So we need to use the pkgconfig file to locate the include files.
kdepim installs an icon incorrectly: /opt/trinity/share/icons/hicolor/inityxinity/tdepim/3.5.13.2/akregator/src/pics/action-rss_tag.svg (it is akregator/src/pics/action-rss_tag.svg in source tree) Created attachment 1081 [details]
kdevelop 3.5.13.2 : missing LDFLAGS cause FTBFS
kdewebdev FTBFS under Fedora 18 because libxml2 does not provide the "docbParseFile" method anymore. /dev/shm/BUILD.fc18.x86_64/trinity-tdewebdev-3.5.13.2/kxsldbg/kxsldbgpart/libxsldbg/xsldbg.cpp:1030: undefined reference to `docbParseFile' kdegraphics (kamera) FTBFS on Fedora 18 because of gphoto2 (version too recent ?) /dev/shm/BUILD.fc18.x86_64/trinity-tdegraphics-3.5.13.2/kamera/kioslave/kamera.cpp: In member function 'void KameraProtocol::translateFileToUDS(KIO::UDSEntry&, const CameraFileInfo&, QString)': /dev/shm/BUILD.fc18.x86_64/trinity-tdegraphics-3.5.13.2/kamera/kioslave/kamera.cpp:860:25: error: 'GP_FILE_INFO_NAME' was not declared in this scope /dev/shm/BUILD.fc18.x86_64/trinity-tdegraphics-3.5.13.2/kamera/kioslave/kamera.cpp:861:49: error: 'const CameraFileInfoFile' has no member named 'name' Created attachment 1082 [details] DIgikam 3.5.13.2 : add support for gphoto 2.5 Digikam does not build against Gphoto 2.5 (used in Fedora 18). Based on the upstream patch: https://bugs.kde.org/attachment.cgi?id=73176&action=edit The attached patch applies to Digikam 3.5.13.2 and allows support for Gphoto 2.5, while retaining compatibility with <= 2.4 . Created attachment 1083 [details]
kmyfirewall 3.5.13.2 : fix locolor theme name
kmyfirewall installs 'locolor' icons under 'Locolor' directory. This patches fixes this.
I understand that changing condition in attachment 1080 [details]:
if( HAVE_LIBSMBCLIENT_H OR SMBCLIENT_FOUND )
is not necessary, due to previous:
if( SMBCLIENT_FOUND )
set( HAVE_LIBSMBCLIENT_H 1 )
Is that correct?
Created attachment 1084 [details]
kdebase 3.5.13.2: add cmake option WITH_KDESKTOP_LOCK_BACKTRACE
I tried to add CMake option WITH_KDESKTOP_LOCK_BACKTRACE for kdebase. Please test it.
Created attachment 1085 [details]
tdebase R14: add cmake option WITH_KDESKTOP_LOCK_BACKTRACE
Created attachment 1087 [details]
kdebase 3.5.13.2: add cmake option WITH_KDESKTOP_LOCK_BACKTRACE (2)
Added condition to link bfd library only if WITH_KDESKTOP_LOCK_BACKTRACE is enabled.
Created attachment 1088 [details]
tdebase R14: add cmake option WITH_KDESKTOP_LOCK_BACKTRACE (2)
Created attachment 1089 [details]
kdebase 3.5.13.2 : fix smbclient library detection (2)
Slavek, you're right about SMB detection patch. Here is a new one.
Attached file 1087 works for me. Comment on attachment 1079 [details]
kdelibs 3.5.13.2 : fix openexr include flags
Pushed in GIT in hash 9b523bbf and also into v3.5.13-sru branch.
Comment on attachment 1089 [details]
kdebase 3.5.13.2 : fix smbclient library detection (2)
Pushed to GIT in hash 56b3a6bc and also into v3.5.13-sru branch.
Comment on attachment 1087 [details]
kdebase 3.5.13.2: add cmake option WITH_KDESKTOP_LOCK_BACKTRACE (2)
After one additional modification pushed to GIT in hash 936d3cec and also into v3.5.13-sru branch.
Comment on attachment 1081 [details]
kdevelop 3.5.13.2 : missing LDFLAGS cause FTBFS
Pushed to GIT in hash 33d15e86 and also into v3.5.13-sru branch.
Created attachment 1091 [details] Fix icon name parsing in tde_install_icons This modification in common cmake module resolves a bug observed in kdepim - mentioned in the comment 7. Please test before I pushing it into the GIT. OK your patch works, no more kdepim icon problem. Comment on attachment 1091 [details]
Fix icon name parsing in tde_install_icons
Thanks, François.
Pushed to GIT in hash 274366fb and also into v3.5.13-sru branch.
Updating the common module in all other modules will follow.
(Odpověď na komentář #9)
> kdewebdev FTBFS under Fedora 18 because libxml2 does not provide the
> "docbParseFile" method anymore.
>
> /dev/shm/BUILD.fc18.x86_64/trinity-tdewebdev-3.5.13.2/kxsldbg/kxsldbgpart/libxsldbg/xsldbg.cpp:1030:
> undefined reference to `docbParseFile'
It's suspicious. In libxml/xmlversion.h should be defined LIBXML_DOCB_ENABLED, which tells if docb* functions are available or not. If LIBXML_DOCB_ENABLED is not set, then kdewebdev not using docbParseFile.
Please, can you check status LIBXML_DOCB_ENABLED in your libxml/xmlversion.h?
OK here is an extract from /usr/include/libxml2/libxml/xmlversion.h (in Fedora 18): /** * LIBXML_DOCB_ENABLED: * * Whether the SGML Docbook support is configured in */ #if 1 #define LIBXML_DOCB_ENABLED #endif It looks like is enabled in the header file. But I cannot find the symbol in 'libxml2.so'. So I still get the error log (extract): /bin/sh ../libtool --tag=CXX --mode=link g++ -DNDEBUG -DNO_DEBUG -O2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-exceptions -fno-check-new -fno-common -I/opt/trinity/include/tqt -DCOMPAT_KMDI -DENABLE_CVSSERVICE -L/opt/trinity/lib64 -L/usr/lib64/qt-3.3/lib -L/usr/lib64 -Wl,--as-needed -Wl,--enable-new-dtags -lqt-mt -lz -lpng -lz -lm -lXext -lX11 -lSM -lICE -ltqt -lpthread -lDCOP -lkdecore -lkdeui -lkdefx -lkio -lktexteditor -L/opt/trinity/lib64 -I/opt/trinity/include -o xsldbg xsldbgmain.o kxsldbgpart/libxsldbg/libxsldbg.la -lexslt -L/usr/lib64 -lxslt -lxml2 -lz -ldl -lm -lrt -lxml2 -lz -lm -ldl -lkdeui libtool: link: g++ -DNDEBUG -DNO_DEBUG -O2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-exceptions -fno-check-new -fno-common -I/opt/trinity/include/tqt -DCOMPAT_KMDI -DENABLE_CVSSERVICE -Wl,--as-needed -Wl,--enable-new-dtags -I/opt/trinity/include -o xsldbg xsldbgmain.o -L/opt/trinity/lib64 -L/usr/lib64/qt-3.3/lib -L/usr/lib64 -lqt-mt -lpng -lXext -lX11 -lSM -lICE /opt/trinity/lib64/libtqt.so -lpthread /opt/trinity/lib64/libDCOP.so /opt/trinity/lib64/libkdecore.so /opt/trinity/lib64/libkdefx.so /opt/trinity/lib64/libkio.so /opt/trinity/lib64/libktexteditor.so kxsldbgpart/libxsldbg/.libs/libxsldbg.a -lexslt -lxslt -lrt -lxml2 -lz -lm -ldl /opt/trinity/lib64/libkdeui.so kxsldbgpart/libxsldbg/.libs/libxsldbg.a(xsldbg.o): In function `xsldbgLoadXmlTemporary': /dev/shm/BUILD.fc18.x86_64/trinity-tdewebdev-3.5.13.2/kxsldbg/kxsldbgpart/libxsldbg/xsldbg.cpp:1030: undefined reference to `docbParseFile' kxsldbgpart/libxsldbg/.libs/libxsldbg.a(xsldbg.o): In function `xsldbgLoadXmlData': /dev/shm/BUILD.fc18.x86_64/trinity-tdewebdev-3.5.13.2/kxsldbg/kxsldbgpart/libxsldbg/xsldbg.cpp:980: undefined reference to `docbParseFile' collect2: error: ld returned 1 exit status make[3]: *** [xsldbg] Error 1 make[3]: Leaving directory `/dev/shm/BUILD.fc18.x86_64/trinity-tdewebdev-3.5.13.2/kxsldbg' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/dev/shm/BUILD.fc18.x86_64/trinity-tdewebdev-3.5.13.2/kxsldbg' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/dev/shm/BUILD.fc18.x86_64/trinity-tdewebdev-3.5.13.2' make: *** [all] Error 2 Running under Fedora 18: $ strings /usr/lib64/libxml2.so|grep docb initdocbDefaultSAXHandler __docbDefaultSAXHandler docbDefaultSAXHandlerInit Under another distribution $ strings /usr/lib64/libxml2.so|grep docb initdocbDefaultSAXHandler docbEncodeEntities docbParseDocument docbFreeParserCtxt docbParseChunk docbSAXParseDoc docbParseDoc docbCreateFileParserCtxt docbSAXParseFile docbParseFile docbCreatePushParserCtxt __docbDefaultSAXHandler docbDefaultSAXHandlerInit docbEncodeEntities() deprecated function reached docbParseDocument() deprecated function reached docbFreeParserCtxt() deprecated function reached docbParseChunk() deprecated function reached docbCreateFileParserCtxt() deprecated function reached docbSAXParseFile() deprecated function reached docbParseFile() deprecated function reached Created attachment 1092 [details]
DOCBparser.c , from Fedora 18 (libxml2 2.9.0)
Here is the DOCBparse.c file, from libxml2 2.9.0 source code.
As you can see, the code is totally deprecated and marked as so.
In order to properly build tdewebdev, we'll have to replace old functions (e.g: docbParseDocument) with newer ones (e.g: xmlParseDocument)
Created attachment 1093 [details]
kdewebdev 3.5.13.2 : fix compilation with libxml2 2.9.0
Created attachment 1094 [details]
kdewebdev : fix docbook support with libxml2 >= 2.6.x
Because functions docb* are marked as obsolete since version 2.6.0, I suggest to use this as a condition during build. May be?
Looks good, even if I doubt that any one will build againt libxml < 2.6, it's very very old ! Comment on attachment 1094 [details]
kdewebdev : fix docbook support with libxml2 >= 2.6.x
Pushed to GIT in hash c1c8adb7 and also into v3.5.13-sru branch.
Created attachment 1095 [details]
kdegraphics 3.5.13.2 : add support for gphoto 2.5
Patch based on KDE GIT commit cdcf4205.
François, please, can you test patch with gphoto 2.5?
In this time I do not have gphoto 2.5 in any Debian or Ubuntu.
Created attachment 1096 [details]
tdegraphics R14 : add support for gphoto 2.5
Created attachment 1099 [details]
kdegraphics 3.5.13.2 : add support for gphoto 2.5 (2)
Hello, I modified the kdegraphics gphoto patch a little so that it builds on Fedora 18.
Comment on attachment 1099 [details]
kdegraphics 3.5.13.2 : add support for gphoto 2.5 (2)
François, thank you for testing and supplementation.
Pushed to GIT in hash d4d1a580 and also into v3.5.13-sru branch.
Comment on attachment 1082 [details]
DIgikam 3.5.13.2 : add support for gphoto 2.5
Pushed to GIT in hash 00fa7147 and also into v3.5.13-sru branch.
Comment on attachment 1083 [details]
kmyfirewall 3.5.13.2 : fix locolor theme name
Pushed to GIT in hash d0fdb21a and also into v3.5.13-sru branch.
Good work. Does that mean that we are ready to release 3.5.13.2 ? (Odpověď na komentář #40) > Good work. > Does that mean that we are ready to release 3.5.13.2 ? I still have a small number of bugs that I would like to have in 3.5.13.2 fixed - especially bug 1288 and bug 1394. Possibly even bug 249, bug 1193 and bug 1290. See 3.5.13-sru page in Etherpad: http://trinity.etherpad.trinitydesktop.org/16 François, please, can you test patch in attachment 1100 [details] from bug 942 and in attachment 1101 [details] from bug 943? Done, both patches are OK for me. (Odpověď na komentář #43)
> Done, both patches are OK for me.
Thank you. I will wait for the result of testing by Darrell. However, I suppose that you both solve the same problem, so I hope that Darrell will also confirm both patches.
python-trinity FTBFS under PCLinuxOS 2013: sip/kdeui/keditlistbox.sip: In function ‘const char** PyQtListToArray(PyObject*)’: sip/kdeui/keditlistbox.sip:197:28: error: ‘ANY’ was not declared in this scope sip/kdeui/keditlistbox.sip:197:33: error: expected primary-expression before ‘)’ token sip/kdeui/qxembed.sip: In function ‘PyObject* meth_QXEmbed_processClientCmdline(PyObject*, PyObject*)’: sip/kdeui/qxembed.sip:75:29: error: ‘ANY’ was not declared in this scope sip/kdeui/qxembed.sip:75:34: error: expected primary-expression before ‘)’ token make[1]: *** [sipkdeuipart0.o] Error 1 I confirm that I cannot find "#define ANY" anywhere ... It should be "#define ANY void" The strange thing is that I don't have the FTBFS on other distros where there is no "#define any" ... Created attachment 1103 [details] python-trinity: fix "ANY" macro deprecation Cause of the problem: http://www.riverbankcomputing.co.uk/hg/sip/rev/40aeb5a8f98e Workaround: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=863104 A patch for python-trinity is attached. Comment on attachment 1103 [details]
python-trinity: fix "ANY" macro deprecation
Pushed to GIT in hash ab76f558 and also into v3.5.13-sru branch.
There is a new start(k)tde patch in bug report 675. I tested the version for R14 but not 3.5.13.2. Created attachment 1226 [details]
tdeutils : fix STRLCAT definition conflict
Under opensuse 12.3, tdeutils FTBFS in ksim because of "strlcat" already defined in /usr/include/net-snmp/library/system.h .
This file contains:
#ifndef HAVE_STRLCAT
NETSNMP_IMPORT
size_t strlcat(char *, const char *, size_t);
#endif
But in TDE we set variable HAVE_STRLCAT_PROTO .
The attached patch defines HAVE_STRLCAT if HAVE_STRLCAT_PROTO is defined too.
Comment on attachment 1226 [details]
tdeutils : fix STRLCAT definition conflict
Pushed to GIT in hash 3df06155 and also into v3.5.13-sru branch.
Created attachment 1294 [details]
libksquirrel : fix FTBFS with libgif >= 4.2.0
Using recent libgif ( >= 4.2.0 ) , libksquirrel FTBFS because function "PrintGifError" has been removed.
Attached patch redefines it inside libksquirrel code.
Created attachment 1295 [details]
libkipi : fix ftbfs because AM_CONFIG_HEADER is obsolete
libkipi FTBFS using automake >= 1.13 because AM_CONFIG_HEADER is deprecated. We must use AC_CONFIG_HEADER instead.
Created attachment 1296 [details]
bibletime : fix ftbfs with automake >= 1.13
François, that's not good news, because (although the tag is not yet visible in the git web interface) 3.5.13.2 was tagged as the final on Sunday :( No problem, build issues can stay in my packaging-specific directory tree . It won't affect the end user anyway. Created attachment 1297 [details]
kchmviewer : fix build with automake >= 1.13
Created attachment 1298 [details]
kvirc : fix FTBFS because undefined macro TDE_DIR, TDE_LIBDIR
Created attachment 1299 [details]
kaffeine-mozilla : fix build with automake >= 1.13
Comment on attachment 1295 [details]
libkipi : fix ftbfs because AM_CONFIG_HEADER is obsolete
Pushed to GIT in hash 7b2b1cac and also into v3.5.13-sru branch.
Comment on attachment 1294 [details]
libksquirrel : fix FTBFS with libgif >= 4.2.0
Pushed to GIT in hash 577f5c81 and also into v3.5.13-sru branch.
Comment on attachment 1296 [details]
bibletime : fix ftbfs with automake >= 1.13
Pushed to GIT in hash ee8b1e19 and also into v3.5.13-sru branch.
Comment on attachment 1299 [details]
kaffeine-mozilla : fix build with automake >= 1.13
Pushed to GIT in hash f4449a9b and also into v3.5.13-sru branch.
Comment on attachment 1297 [details]
kchmviewer : fix build with automake >= 1.13
Pushed to GIT in hash 08a0dfee and also into v3.5.13-sru branch.
Comment on attachment 1298 [details]
kvirc : fix FTBFS because undefined macro TDE_DIR, TDE_LIBDIR
Pushed to GIT in hash 2d7006ac and also into v3.5.13-sru branch.
Created attachment 1300 [details]
basket : fix compilation with gcc 4.7 (already present upstream)
Created attachment 1301 [details]
kstreamripper : fix ftbfs because missing include tqt.h
Created attachment 1302 [details]
gwenview : fix ftbfs with gcc >= 4.7 (already present upstream)
Created attachment 1303 [details]
kbfx : fix documentation installation directory
Francois, is a patch from attachment 1300 [details] still valid? The file unistd.h is included a few lines above - see: (R14) http://git.trinitydesktop.org/cgit/basket/commit/?id=d978009c (v3.5.13-sru) http://git.trinitydesktop.org/cgit/basket/commit/?h=origin/v3.5.13-sru&id=114d08b1 Francois, is a patch from attachment 1301 [details] still valid? The file tqt.h is set to include using CXXFLAGS - see: (R14) http://git.trinitydesktop.org/cgit/kstreamripper/commit/?id=a9b1841c (v3.5.13-sru) http://git.trinitydesktop.org/cgit/kstreamripper/commit/?h=origin/v3.5.13-sru&id=77909a22 Comment on attachment 1300 [details]
basket : fix compilation with gcc 4.7 (already present upstream)
Not needed anymore in 3.5.13.2
Comment on attachment 1301 [details]
kstreamripper : fix ftbfs because missing include tqt.h
Not needed anymore in 3.5.13.2
It looks like the gwenview patch is not needed anymore too in 3.5.13.2 but I do not understand what was its purpose. The kbfs patch is still useful in the case where "./configure --docdir" is specified under a different directory than "--datadir". Now, I have no more patches for 3.5.13.2. Comment on attachment 1302 [details]
gwenview : fix ftbfs with gcc >= 4.7 (already present upstream)
This patch is still valid.
As is mentioned in source code:
# QT_CLEAN_NAMESPACE is needed when building with automake, otherwise
# compilation fails in jpegcontent.cpp
Apparently it is also related to with libmng.
Without patch:
checking libmng.h usability... no
checking libmng.h presence... yes
configure: WARNING: libmng.h: present but cannot be compiled
configure: WARNING: libmng.h: check for missing prerequisite headers?
configure: WARNING: libmng.h: see the Autoconf documentation
configure: WARNING: libmng.h: section "Present But Cannot Be Compiled"
configure: WARNING: libmng.h: proceeding with the compiler's result
checking for libmng.h... no
With patch:
checking libmng.h usability... yes
checking libmng.h presence... yes
Patch cherry-picked into v3.5.13-sru branch.
Thank you for the information about it.
Comment on attachment 1303 [details]
kbfx : fix documentation installation directory
Pushed to GIT in hash e10a60ec and also into v3.5.13-sru branch.
Currently, I have not any other patches - except perhaps commits f29ac1d2 and 936f951e from tdebase... It seems that we can (second time) definitely freeze the source code and continue by building binary packages. Some reasons why to wait? No reason to wait more. I've just finished building all packages for 2 different distributions, and I do not have remaining patches that should go upstream. So go ahead and freeze the source code :) All right. As I found out, patch f29ac1d2 (kate) is not directly applicable to v3.5.13-sru branch. And patch 936f951e (lockprocess) is less significant. Neither will now backported. Source codes are hereby deemed frozen - no more patches will be accepted for 3.5.13.2. I'm going to prepare final source tarballs. And rebuild all Debian / Ubuntu binary packages... Thank you for your cooperation. Created attachment 1309 [details]
kvirc : fix build with automake >= 1.13
Sorry I forgot this patch for automake 1.13 ! Too late for 3.5.13.2 but still good for R14.
Comment on attachment 1309 [details]
kvirc : fix build with automake >= 1.13
Pushed to GIT in hash 3e8fea2e.
Release 3.5.13.2 is currently underway. Therefore I close this bug message. |