aLinux http://alinux.tv/ , a KDE3-centric distro indicates that they use KDE
3.5.12 as the main desktop. This unambiguously hints that they use Trnity.
Since aLinux is an RPM-based distro, this fact may make porting to other
RPM-based distributions easier as they provide SRPMs for each package.
Hi all,
I'm very new here and to Trinity so please be gentle, this is my first
attempt :-)
I'm attempting a build for Mandriva 2010.1 and by a long winded-process of
'hit and miss' I've managed to get .configure to run to completion except
for the following warning message regarding 'libtqtinterface-dev' needing
to be installed:
==== Caution wrapped ====
checking if TQt is available... no
configure: WARNING: You are attempting to compile Trinity without the
Trinity Qt Interface installed. Please install libtqtinterface-dev and
try again!
====
Ignoring this message and calling 'make' appears to complete
correctly, however 'make install' returns the following:
failure as follows:
=====Caution may wrap ====
[root@john tqtinterface]# make install
Making install in libltdl
make[1]: Entering directory `/spare/kde-3.5.12/dependencies/tqtinterface/libltdl'
make[2]: Entering directory `/spare/kde-3.5.12/dependencies/tqtinterface/libltdl'
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/spare/kde-3.5.12/dependencies/tqtinterface/libltdl'
make[1]: Leaving directory `/spare/kde-3.5.12/dependencies/tqtinterface/libltdl'
Making install in qtinterface
make[1]: Entering directory `/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface'
Making install in .
make[2]: Entering directory `/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface'
make[3]: Entering directory `/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface'
test -z "/usr/local/kde/lib" || /bin/mkdir -p "/usr/local/kde/lib"
/bin/sh ../libtool --mode=install /usr/bin/install -c -p libtqt.la '/usr/local/kde/lib'
libtool: install: /usr/bin/install -c -p .libs/libtqt.so.4.2.0 /usr/local/kde/lib/libtqt.so.4.2.0
/usr/bin/install: cannot stat `.libs/libtqt.so.4.2.0': No such file or directory
make[3]: *** [install-libLTLIBRARIES] Error 1
make[3]: Leaving directory `/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface'
make: *** [install-recursive] Error 1
[root@john tqtinterface]#
I'm somewhat confused by the missing(?) `.libs/libtqt.so.4.2.0' message which is
correct when one looks in the referenced directory. Where does the ".2.0" come
from? What do I do to fix this?
==================
[root@john john]# locate libtqt
/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface/libtqt.la
/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface/.libs/libtqt.la
/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface/.libs/libtqt.lai
/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface/.libs/libtqt.so
/spare/kde-3.5.12/dependencies/tqtinterface/qtinterface/.libs/libtqt.so.4
[root@john john]#
Cheers
John NZ
Hi! I just found that KDE3 does not support IPv6.
knemo shows an interface as not connected if it has only IPv6 protocol.
Kconnections shows only IPv4 connections.
Although SVN provides a direct route to testing patches for the next 3.5.13 release, I want to propose making tarballs available too.
Many people are motivated to test newer versions but do not have the bandwidth, computer horsepower, or inclination to support SVN.
I propose providing directories just like those for downloading the 3.5.12 tarballs. The directories would be explicitly named 3.5.13-testing or something similar.
When 3.5.13 goes live and official, all we should need do is just change the name of the directory.
Darrell
Hello,
In this moment, cmake support for tqtinterface, arts and kdelibs are ready for
building tests.
Some info about cmake build system:
1) preffered mode for building are "out-of-source", which prevent sources to
be "polluted" with generated files and compiled objects (in kde4
out-of-source mode are mandatory).
For example, tqtinterfaces will be configured in this way:
mkdir /tmp/tqtinterface
cd /tmp/tqtinterface
svn co
svn://anonsvn.kde.org/home/kde/branches/trinity/dependencies/tqtinterface
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr ../tqtinterface
make -j 3
make install DESTDIR=/tmp/tqtinterface/install
2) There are some standard rules to activate/deactivate features:
For example, kdelibs have: WITH_LIBART, WITH_ARTS, WITH_TIFF, etc (for rest of
options check kdelibs/CMakeLists.txt)
For compile kdelibs with arts and tiff and without aspell, we will run:
cmake -DWITH_ARTS=ON -DWITH_TIFF=ON -DWITH_ASPELL=OFF <path_to_sources>
3) If we need to alter standard install directories we have variables like
BIN_INSTALL_DIR, SYSCONFDIR, XDG_MENUDIR.
Example:
cmake cmake -DCMAKE_INSTALL_PREFIX=/opt/kde3 -DSYSCONFDIR=/etc <sources>
4) Enabling RPATH:
cmake -DCMAKE_INSTALL_RPATH=/usr/kde/3.5/lib
###################################
(almost) complete example, kdelibs for ubuntu:
cmake -DCMAKE_INSTALL_PREFIX=/opt/kde3 \
-DINCLUDE_INSTALL_DIR=/opt/kde3/include/kde \
-DSYSCONFDIR=/etc \
-DWITH_LIBIDN=ON -DWITH_SSL=ON -DWITH_LIBART=ON \
-DWITH_ALSA=ON -DWITH_ARTS=ON -DWITH_CUPS=ON \
-DWITH_JASPER=ON -DWITH_OPENEXR=ON -DWITH_ASPELL=ON \
-DWITH_TIFF=ON -DWITH_LUA=OFF \
<path to kdelibs sources>
LUA support are disabled because is not done yet.
If you won't using RPATH, ensure that LD_LIBRARY_PATH is correcty set,
otherwise kdelibs will fail when will try to use mcopidl.
For testing, are preferable to use big number of concurrent compile processes
(-j 10, for example), to check if all dependencies are compiled in proper
order.
--
Serghei
Hi,
I've started to create/update spec files for Trinity KDE. You'll see some stuff
appearing in home:bravoall1552:trinity on build.o.o by the weekend.
I'll start out with SuSE and Fedora. I've got someone from the Unity Linux
project that can help Mandrivanize these :)
--
later, Robert Xu
Hello,
I wonder if is not good ideea to set RPATH into Trinity binaries, to
${prefix}/lib. In this case Trinity will still working even LD_LIBRARY_PATH
is not set at all.
Pros? Cons?
--
Serghei
I won't pretend to understand the challenges involved, but is there any chance Koffice can be split into component apps?
I think many end-users would appreciate that but so would anybody who builds the packages. Koffice is huge. A single failure in one component kills the entire build. Building Koffice on my dual core requires almost two hours. I can only imagine people trying to build on older hardware.
If the idea is doable I'll submit an enhancement request.
Darrell
Hello,
CMake support for kdelibs is almost done, but i still need some ideeas:
1) I'm not sure if is good ideea to commit cmake file into svn as is. But
otherwise we can't test/fix it, I think.
2) I need some advices about which options must be ON/OFF by default. Also, we
must to define very clear and in consistent way the names of variable which
enable/disable various options.
3) We need to define in consistent way variable names for standard directories
(for example now the "bin" directory is defined as "BIN_INSTALL_DIR";
but "etc" directory is defined as "SYSCONFDIR" - inconsistent naming,
inherited from kde4 and autotools).
4) I think we must drop support for some (very) obsolete thing, like libalsa <
0.9, hspell (now hebrew spelling support is incorporated in aspell too),
old/unused styles (like riscos). Also, anybody really using "fast malloc"
support?
5) KDE using plenty compiler flags. We really need to use all of them? Maybe
is better ideea to pass cflags options to distro packagers and to keep only
strictly necessary cflags.
6) We need to cleanup a little the code. I found code which are not
compiled/installed at all (for example: [kate/plugins/autobookmarker],
[kdeprint/foomatic], [kdeprint/lpd], [khtml/java], etc).
7) I need help for creating an external svn directory like [admin] for common
cmake macros. As a beginner svn user, I have no ideea how to do it.
8) Must be completed/reviewed tests for cmake configure stage. configure.h is
very large piece of code and is very dificult to made it by just one person.
9) Some dependencies must be required, not optional. For example, bzip2, jpeg
and openssl support, which in these days are available by default on most
current distros.
10) We need to decide how various pieces of trinity will be detect each
another (for building). I'm for extensive using of pkgconfig mechanism, which
seems standard for all modern distros. I succesfully used it for tqtinterface
and arts.
And many more little things... :)
Just for remember, there are my work:
http://www.thel.ro/trinity/kdelibs.htmlhttp://github.com/serghei/kde-trinity-cmake
PS Sorry for my english, I will try to explain better if anybody do not
understand what I want to say :)
--
Serghei
