>--> Add code here to redirect to default English version instead
>of just displaying the awkward message.
Copy the same snippet just above? Or new code?
Darrell
>Until a localized version exists, we can use the English page in
>case of documentation not found.
>Better than the unprofessional blank background message.
>When a localized version becomes available, we simply replace the
>English file with the localized version.
Here is the way the newly patched code looks:
====================================
TQString HelpProtocol::lookupFile(const TQString &fname,
const TQString &query, bool
&redirect)
{
redirect = false;
TQString path, result;
path = fname;
result = langLookup(path);
if (result.isEmpty())
{
result = langLookup(path+"/index.html");
if (!result.isEmpty())
{
KURL red( "help:/" );
red.setPath( path + "/index.html" );
red.setQuery( query );
redirection(red);
kdDebug( 7119 ) << "redirect to " << red.url() << endl;
redirect = true;
}
else
{
const TQString helpNotFound =
"khelpcenter/helpnotfound/index.html";
if (!langLookup(helpNotFound).isEmpty())
{
KURL red;
red.setProtocol("help");
red.setPath(helpNotFound);
red.setQuery(query);
redirection(red);
kdDebug( 7119 ) << "redirect to " << red.url() <<
endl;
redirect = true;
}
else
{
unicodeError( i18n("There is no documentation
available for %1." ).arg(path) );
finished();
return TQString::null;
}
}
} else
kdDebug( 7119 ) << "result " << result << endl;
return result;
}
====================================
Does that mean all i18n users will not see the new English page or
a translated page?
Would be nice if i18n users saw the default English page. I really
hate the blank page and lame error message.
I have no experience tinkering with i18n. I probably should learn
how and at least install the en-GB i18n package.
Darrell
All,
In response to bug report 1839, I created a professional looking
page for the help handbook when no help documentation exists. View
the new page here:
http://bugs.trinitydesktop.org/attachment.cgi?id=1876
Here is the actual text:
===================================
Help Documentation Not Found
The requested help file was not found. &tde; looks for files in a
location that depends upon how &tde; was installed on your
computer. There are several possible reasons why no help file was
found. The document might not exist or might not have been
installed.
To resolve the problem, first contact the upstream packager.
If no help file exists, then please report this bug using the
<ulink url="http://bugs.trinitydesktop.org/">TDE Bug
Tracker</ulink>.
If no help file exists and you are interested in helping further,
please consider writing the help file. Submitting a basic text file
is acceptable.
If no help file exists for your native language, please consider
helping with a translation.
Thank you for helping and thank you for your patience.
===================================
&tde; is a docbook entity for TDE.
If a localized page is not found then users of that language will
still be greeted with the unprofessional "There is no documentation
available for %1." message with the blank background.
This is a small chunk of text. Please help translate for your
native language or forward this message to someone you know or to
the users mail list. Send translations to me and I'll update.
Thank you!
Darrell
>Hmmm.. That's what I was doing... Here is the build order I use:
Perform the following on my build script collection:
grep build_package TDE.SlackBuild
You find my build order and whether I use automake or cmake. If you
browse TDE.SlackBuild you'll find comments about building certain
packages before other packages.
Also perform the following in my unarchived build environment:
find . -maxdepth 3 -name "*.SlackBuild" -exec grep -l "AUTOTOOLS="
{} \;
This will reveal which packages can use either automake or cmake.
When the line AUTOTOOLS=true is commented out then the script uses
cmake. When not commented out then I still use automake.
There are some partical conversions to cmake. Those respective
build scripts I have configured to test either cmake or automake as
new cmake patches come forth. I use the AUTOTOOLS=true line to
determine which to use. When new patches come forth I uncomment the
line and test cmake.
BTW, as Slavek mentioned, in my TDE.SlackBuild you'll notice I have
the following comment:
# Build tdegames after tdemultimedia.
Darrell
>The build farm builds everything on 8-core machines with parallel
>jobs allowed, and I haven't seen any failures.
I would like to know how. I cannot build tdebindings with parallel
processing. Everything else, yes.
Are you compiling all components?
Darrell
>HOLY CRAP!!
>
> tdelibs built fine with the patch -- and in 7 minutes flat with
>'make -j4'!!!
>
>Script Execution Time: 7 minutes - that is down from 27 min with -
>j1 and this is on a 5 year old box.
7 minutes? Skeptical --- do you have a full package?
Takes 33 minutes on my 5 year old 2.3 GHz dual core.
Darrell
>I saw that. Thanks. Glad to know you have a list. After
>experiencing sever
>spurious failures a year or so ago, I have been gunshy about using
>it. The
>difference between -j1 and -j4 is phenomenal (haven't tried
>anything above
>actual cores)
I had forgotten about the three exceptions. Next build run I'm
going to test them again.
Darrell
Slavek, All
After fixing the option that strips static-libs from the final package in
arch, I went to rebuild tdelibs. Doing so, I enabled the following:
cmake ${srcdir}/tdelibs \
-DCMAKE_INSTALL_PREFIX=${TDEDIR} \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DWITH_ARTS=ON \
-DWITH_ALSA=ON \
-DWITH_LIBART=ON \
-DWITH_LIBIDN=ON \
-DWITH_SSL=ON \
-DWITH_CUPS=ON \
-DWITH_LUA=OFF \
-DWITH_TIFF=ON \
-DWITH_JASPER=ON \
-DWITH_OPENEXR=ON \
-DWITH_UTEMPTER=ON \
-DWITH_AVAHI=ON \
-DWITH_PAM=ON \
-DWITH_PCRE=ON \
-DWITH_TDEHWLIB_DAEMONS=ON \
-DWITH_UPOWER=ON \
-DWITH_UDISKS2=ON \
-DWITH_LZMA=ON \
-DWITH_XRANDR=ON \
-DWITH_XCOMPOSITE=ON \
-DWITH_ASPELL=ON \
-DWITH_HSPELL=ON
The build failed with the now-familiar error:
/usr/bin/ld: cannot find -ldbus-1-tqt
collect2: error: ld returned 1 exit status
tdecore/CMakeFiles/tdecore-shared.dir/build.make:3063: recipe for target
'tdecore/libtdecore.so.14.0.0' failed
make[2]: *** [tdecore/libtdecore.so.14.0.0] Error 1
make[2]: Leaving directory '/build/tde-tdelibs/src/build'
CMakeFiles/Makefile2:1087: recipe for target
'tdecore/CMakeFiles/tdecore-shared.dir/all' failed
However, note: This is now with '-ldbus-1-tqt' instead of '-ldbus-tqt-1'.
Basically, this is "same-song-second-verse". pkgconfig info is fine, but unless
the CMakeLists.txt files are patched to include either ${DBUS_TQT_LIBRARY_DIRS}
or somehow get ${TDEHW_CUSTOM_LIBRARY_DIRS} into the CMakeLists.txt, the build
fails. The current tdecore CMakeLists.txt includes only the following:
link_directories(
${TQT_LIBRARY_DIRS}
${LIBIDN_LIBRARY_DIRS}
${GAMIN_LIBDIR}
${LIBART_LIBRARY_DIRS}
)
This is insufficient if( WITH_TDEHWLIB_DAEMONS OR WITH_HAL OR WITH_DEVKITPOWER
OR WITH_UPOWER OR WITH_UDISKS OR WITH_UDISKS2 OR
WITH_NETWORK_MANAGER_BACKEND OR WITH_CONSOLEKIT ) are chosen as options.
See: tdecore/tdehw/CMakeLists.txt
There are probably other fixes needed, but my first thought was just to
include ${DBUS_TQT_LIBRARY_DIRS}:
link_directories(
${TQT_LIBRARY_DIRS}
${LIBIDN_LIBRARY_DIRS}
${GAMIN_LIBDIR}
${LIBART_LIBRARY_DIRS}
${DBUS_TQT_LIBRARY_DIRS}
)
But if ${TDEHW_CUSTOM_LIBRARY_DIRS} is visible in this scope, then :
link_directories(
${TQT_LIBRARY_DIRS}
${LIBIDN_LIBRARY_DIRS}
${GAMIN_LIBDIR}
${LIBART_LIBRARY_DIRS}
${TDEHW_CUSTOM_LIBRARY_DIRS}
)
is probably better.
You do NOT see this problem if you are including -L/opt/trinity/libs in
CXXFLAGS, but you should not have to put library search paths in CXXFLAGS to
avoid the FTBFS.
--
David C. Rankin, J.D.,P.E.