Tim, Darrell,
Why does the common/cmake/modules/TDESetupPaths.cmake still include the
reference to 'kde' in the HTML path?
_tde_internal_setup_path( HTML_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/doc/kde/HTML"
I know Darrell has been working on patches to update this location. Couldn't
we just set it here in cmake and then just build all packages letting this
default set the proper location?
--
David C. Rankin, J.D.,P.E.
Would somebody who does not use a sudo based distro please test whether this happens on your system?
1. Start kate as normal user.
2. Start a separate kate session as root using 'tdesu kate'.
Two separate sessions should be open. In the second session you should be able to view the contents of /root.
If only one session is open then you are experiencing the same problem.
No other app seems affected by this behavior.
Thanks much.
Darrell
All,
I just hit a new build failure in tdebase. I don't know if this is related to
a prior patch, a parallel build failure -- or what. I haven't seen this before
with document generation:
Scanning dependencies of target kfind-en-handbook
[ 2%] Generating index.cache.bz2
[ 2%] Built target kmenuedit-en-handbook
Scanning dependencies of target khelpcenter-visualdict-en-handbook
[ 2%] Generating index.cache.bz2
index.docbook:22: parser error : Entity 'tde-release-date' not defined
<date>&tde-release-date;</date>
^
index.docbook:23: parser error : Entity 'tde-release-version' not defined
<releaseinfo>&tde-release-version;</releaseinfo>
^
index.docbook:30: parser error : Entity 'tde-copyright-date' not defined
<year>&tde-copyright-date;</year>
^
make[2]: *** [doc/visualdict/index.cache.bz2] Error 1
make[1]: ***
[doc/visualdict/CMakeFiles/khelpcenter-visualdict-en-handbook.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 2%] Built target kfind-en-handbook
What is wrong with the </year> ??
--
David C. Rankin, J.D.,P.E.
All,
There are 5 patches I continue to apply in arch that should be evaluated for
inclusion in the GIT tree and a decision made. I don't know if they are slated
for inclusion, have already been nixed or what. The patches are:
01-kicker-lockout-applet-button-order.patch
02-doc_location.patch
03-kcontrol_advbg_step.patch
06-nspluginscan-xdgcompliance.patch
08-kip_kdesktop_rounded_icon_text_corners.patch
The builds have performed great with the patches, so I've noticed no adverse
impact anywhere else. I've attached the patches. I think Calvin and Pawell
originally carried them over from a previous arch build, but I'm not certain
about that. Look them over, and let's decide whether they should be included in
the code.
--
David C. Rankin, J.D.,P.E.
Darrell,
I started a new build of tde tonight from scratch. I grabbed the output of the
build failure in tdelibs due to komp-pid.diff. (I know it is experimental -- I
was experimenting :) It is another "error: cannot convert 'TQString' to 'const
char*' in assignment" in tdelibs/tdecore/kapplication.cp:
[ 6%] Building CXX object tdecore/CMakeFiles/tdecore-shared.dir/kapplication.cpp.o
cd /build/src/build/tdecore && /usr/bin/c++ -Dtdecore_shared_EXPORTS
-DHAVE_CONFIG_H -march=i686 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -DQT_NO_ASCII_CAST
-DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION
-DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -fPIC -I/opt/tqt3/include
-I/usr/include/tqt -I/build/src/build/tdecore -I/build/src/build
-I/build/src/tdelibs/tdecore -I/build/src/tdelibs/tdecore/network
-I/build/src/tdelibs/dcop -I/build/src/tdelibs/libltdl
-I/build/src/tdelibs/tdefx -I/build/src/tdelibs/tdeui
-I/build/src/tdelibs/kio/kio -I/usr/include/libart-2.0 -o
CMakeFiles/tdecore-shared.dir/kapplication.cpp.o -c
/build/src/tdelibs/tdecore/kapplication.cpp
/build/src/tdelibs/tdecore/kapplication.cpp:2039:2: warning: #warning This
should be already in Qt, check. [-Wcpp]
/build/src/tdelibs/tdecore/kapplication.cpp: In static member function 'static
bool KApplication::isCompositionManagerAvailable()':
/build/src/tdelibs/tdecore/kapplication.cpp:1791:47: error: cannot convert
'TQString' to 'const char*' in assignment
/build/src/tdelibs/tdecore/kapplication.cpp: In member function 'TQt::HANDLE
KApplication::getX11RGBAVisual(Display*)':
/build/src/tdelibs/tdecore/kapplication.cpp:1911:10: warning: converting to
non-pointer type 'TQt::HANDLE {aka long unsigned int}' from NULL [-Wconversion-null]
/build/src/tdelibs/tdecore/kapplication.cpp: In member function 'TQt::HANDLE
KApplication::getX11RGBAColormap(Display*)':
/build/src/tdelibs/tdecore/kapplication.cpp:1921:10: warning: converting to
non-pointer type 'TQt::HANDLE {aka long unsigned int}' from NULL [-Wconversion-null]
/build/src/tdelibs/tdecore/kapplication.cpp: In static member function 'static
void KApplication::sigpipeHandler(int)':
/build/src/tdelibs/tdecore/kapplication.cpp:3595:31: warning: ignoring return
value of 'ssize_t write(int, const void*, size_t)', declared with attribute
warn_unused_result [-Wunused-result]
/build/src/tdelibs/tdecore/kapplication.cpp: In member function 'bool
KApplication::detectCompositionManagerAvailable(bool, bool)':
/build/src/tdelibs/tdecore/kapplication.cpp:1876:42: warning: ignoring return
value of 'size_t fwrite(const void*, size_t, size_t, FILE*)', declared with
attribute warn_unused_result [-Wunused-result]
make[2]: *** [tdecore/CMakeFiles/tdecore-shared.dir/kapplication.cpp.o] Error 1
make[2]: Leaving directory `/build/src/build'
make[1]: *** [tdecore/CMakeFiles/tdecore-shared.dir/all] Error 2
make[1]: Leaving directory `/build/src/build'
So far the build is progressing with all other patches:
patch -Np0 -i ${pkgname#*-}-XDG-KDE-TDE.diff
## patch kde help dir
patch -Np0 -i ${pkgname#*-}-helpdir.diff
## patch KDE4-detect
patch -Np0 -i ${pkgname#*-}-KDE4-detect.diff
## patch kdetcompmgr
patch -Np0 -i ${pkgname#*-}-kdetcompmgr.diff
## patch recentdocs
patch -Np0 -i ${pkgname#*-}-recentdocs.diff
## patch kdirwatch
patch -Np0 -i ${pkgname#*-}-kdirwatch.diff
I'll report back on the kdirwatch patch improvements once the build is done.
--
David C. Rankin, J.D.,P.E.
Good news!
I found a one-liner patch and now am no longer seeing problems with Konqueror updating file information.
I posted the complete story in the bug report:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=756
I attached the patch to the bug report.
Simply put: the patch works. What a joy to see the file pane update immediately!
The patch should back port to 3.5.13.
Please test!
:) :) :) :)
Darrell
All,
Beginning a complete rebuild last night was evidently a bad idea. 13 packages
that had previously built without any error now fail to build. The list of
failing packages include:
Beginning build of: libkarma - Apr 4 20:19:06
makepkg --> FAILED
Beginning build of: dependencies/python-tqt - Apr 4 20:12:56
makepkg --> FAILED
Beginning build of: libraries/kipi-plugins - Apr 4 22:43:59
makepkg --> FAILED
Beginning build of: tdegames - Apr 4 23:49:31
makepkg --> FAILED
Beginning build of: tdegraphics - Apr 5 00:21:04
makepkg --> FAILED
Beginning build of: tdepim - Apr 5 00:30:10
makepkg --> FAILED
Beginning build of: applications/rosegarden - Apr 5 00:34:51
makepkg --> FAILED
Beginning build of: applications/basket - Apr 5 00:38:14
makepkg --> FAILED
Beginning build of: applications/k3b - Apr 5 00:39:00
makepkg --> FAILED
Beginning build of: applications/gwenview - Apr 5 00:44:53
makepkg --> FAILED
Beginning build of: applications/kima - Apr 5 00:49:19
makepkg --> FAILED
Beginning build of: applications/krusader - Apr 5 00:54:10
makepkg --> FAILED
Beginning build of: tdesdk - Apr 5 00:57:28
makepkg --> FAILED
The only new packages installed that are related to the failures are:
binutils-2.22-5 boost-1.49.0-1.1 boost-libs-1.49.0-1.1 coreutils-8.16-2
expat-2.1.0-1 fftw-3.3.1-1 freetype2-2.4.9-2 gcc-4.7.0-3 gcc-libs-4.7.0-3
glibc-2.15-10 krb5-1.10.1-2 libarchive-3.0.4-1 libltdl-2.4.2-5
libtool-2.4.2-5 linux-api-headers-3.3-1 p11-kit-0.12-1 tzdata-2012b-3
xfig-3.2.5b-8 xorg-server-1.12.0.901-1 xorg-server-common-1.12.0.901-1
Of those - the obvious winners look like gcc-4.7, glibc-2.15 and xorg.
Frustrating, yes, but understanding the failures will probably disclose
weaknesses in the codebase. I'll put time into trying to narrow down what broke.
You guys that are build wizards, please let me know if you see, or know of, a
common thread that may have been pulled in with gcc 4.7 that may be the base of
the build problem.
--
David C. Rankin, J.D.,P.E.