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
I probably posted too late in the bugzilla, bug 343.
Version 0.8.8 compiles without error, but I cannot get any DVB functions to work in 0.8.8. Could be a local build issue, I don't know. I remember trying to build 0.8.8 soon after release and had the same problem then.
The DVB functions all work as expected in 0.8.7. Recommend updating SVN to 0.8.7 and not 0.8.8.
Darrell
> To those of you who have amarok and
> kipi-plugins installed. I want to know whether this problem
> is a build problem or a downstream packaging problem.
>
> Please check the HTML links for the non-English
> directories. For example,
>
> /usr/share/doc/HTML/pl/amarok
>
> There will be a sym link to common. Is the link good or
> broken?
>
> On my system the link points to:
>
> /usr/share/doc/HTML/pl/common
>
> I believe the link should point to:
>
> /usr/share/doc/HTML/en/amarok/common.
The problem is in the make files and is a remnant from KDE. In KDE I long ago noticed this problem with several apps: amarok, kipi-plugins, k3b, kpowersave, and kmplayer.
I created a diff patch to the make files. I don't pretend to understand automake, but after I apply the patch all is well until the build script runs make to build the files. Something in the make process overwrites the patches or restores the original make files. I never have seen that before.
Any ideas why the patch won't hold when running make?
At this point the only solution I have is to apply a post-make patch.
If anybody is interested I'm attaching the patch to the make files.
I'll watch other apps as I create Trinity build scripts.
Definitely a paper cut bug.
Darrell
Hello, all!
As you can see from my signature below, I am the Ark Linux Webmaster and
have a desire to also be a packager for Ark Linux. Ark is meant to be easy
enough for new Linux users (and even people who are new to computers in
general), simple enough for the "normal" user (e.g. the home or office user,
rather than geeks, hobbyists, and admins), and powerful enough for our
veteran Linux users.
It has been quite some time since Ark made a release (since 2008) because
our main developer and project leader has been extremely busy with his day
job and has not had much time to actually develop. We are still very much
alive, though, and have tied ourselves into using KDE4 for our next release
by making an official announcement stating as such. This was before we
discovered Trinity's KDE3. We would now like to include Trinity in our next
release.
We'll still be using KDE4, but we are undecided on whether to include both
on the main ISO, or to create two separate ISOs. Whichever we decide, we
want to make both available. I have volunteered to package it. I am a novice
packager (RPM), though, and would like to know if it would be a good idea to
use the old RPM Spec files from the packages of the official KDE 3.5.10
release, or if I should go down the route of making my own Specs. I know
that Trinity switched to cmake, which would require a bit of modifications
to the Specs, but would it be worth it?
--
Kris
"Piki"
Ark Linux Webmaster
Wannabe Ark Linux packager
