tde-devels

devels@trinitydesktop.org

5 participants
3856 discussions

Trinity 3.5.13
by Darrell Anderson 16 Oct '10

16 Oct '10

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

3 2

tqtinterface, arts and kdelibs - compilable with cmake
by Serghei Amelian 13 Oct '10

13 Oct '10

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

2 12

progress update
by Robert Xu 09 Oct '10

09 Oct '10

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

2 4

RPATH vs LD_LIBRARY_PATH
by Serghei Amelian 07 Oct '10

07 Oct '10

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

2 2

Building koffice
by Darrell Anderson 06 Oct '10

06 Oct '10

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

2 1

cmake build system - need advices/ideas
by Serghei Amelian 06 Oct '10

06 Oct '10

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.html http://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

2 3

r1182813
by Darrell Anderson 05 Oct '10

05 Oct '10

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

1 0

Re: [trinity-devel] Amarok, kipi-plugins sym links
by Darrell Anderson 05 Oct '10

05 Oct '10

> 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

2 2

Packager for Ark Linux
by Kristopher Gamrat 05 Oct '10

05 Oct '10

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

3 2

Amarok, kipi-plugins sym links
by Darrell Anderson 05 Oct '10

05 Oct '10

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. Thanks. Darrell

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels