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
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
Hello,
I've started writing ebuilds for trinity, but failed at tqtinterface
(damn!). I've successfully built it before, but now it seems that the
build script do not compile libtqt.so.*, only symlinks to it. This
reminds me some old bugs with configure (sigh). I think this might be
problem with our eclasses, but the same happens with recommended steps
to build. Maybe buggy libtool? Using 2.2.10.
Attaching log.
Regards Ladislav Laska
S pozdravem Ladislav Laska
---
xmpp/jabber: ladislav.laska(a)jabber.cz
This is a popular non-core package. If many of these non-core package are unavailable to end-users, then I call that a show-stopper. Many people will lose interest in Trinity when such non-core packages remain unavailable. I would like to get this package to build as soon as possible.
I'm attaching a log. Same as a previous report, but attached here for quicker access.
This is a build from the source tarball.
Build errors:
============================================
checking cdda_interface.h usability... no
checking cdda_interface.h presence... no
checking for cdda_interface.h... no
-----------------------------------------
ERROR: Could not find cdparanoia headers.
-----------------------------------------
configure: error: could not find cdparanoia headers
make: *** No targets specified and no makefile found. Stop.
============================================
The cause is straightforward. In Slackware the cdda_paranoia.h file is found in /usr/include/cdda rather than /usr/include.
A short term fix is creating a sym link. I could revise the build script to create such a link on-the-fly, but that is not the default in Slackware. Generally, I dislike the idea of tampering with expected upstream defaults. Another solution is to patch the configure files to look in /usr/include/cdda as well as /usr/include.
Also conspicuous are these errors:
============================================
*** Creating configure
configure.in:92: warning: KDE_ENABLE_HIDDEN_VISIBILITY was called before AC_PATH_QT_1_3
acinclude.m4:3645: KDE_ENABLE_HIDDEN_VISIBILITY is expanded from...
configure.in:92: the top level
*** Creating config.h template
configure.in:92: warning: KDE_ENABLE_HIDDEN_VISIBILITY was called before AC_PATH_QT_1_3
acinclude.m4:3645: KDE_ENABLE_HIDDEN_VISIBILITY is expanded from...
configure.in:92: the top level
*** Creating Makefile templates
configure.in:92: warning: KDE_ENABLE_HIDDEN_VISIBILITY was called before AC_PATH_QT_1_3
acinclude.m4:3645: KDE_ENABLE_HIDDEN_VISIBILITY is expanded from...
============================================
Also these:
============================================
kaffeine/src/input/dvb/lib/libdvbapi/Makefile.am:11: `CFLAGS' is a user variable, you should not override it;
kaffeine/src/input/dvb/lib/libdvbapi/Makefile.am:11: use `AM_CFLAGS' instead.
kaffeine/src/input/dvb/lib/libdvben50221/Makefile.am:21: `CFLAGS' is a user variable, you should not override it;
kaffeine/src/input/dvb/lib/libdvben50221/Makefile.am:21: use `AM_CFLAGS' instead.
kaffeine/src/input/dvb/lib/libucsi/Makefile.am:17: `CFLAGS' is a user variable, you should not override it;
kaffeine/src/input/dvb/lib/libucsi/Makefile.am:17: use `AM_CFLAGS' instead.
kaffeine/src/input/dvb/lib/libucsi/dvb/Makefile.am:19: `CFLAGS' is a user variable, you should not override it;
kaffeine/src/input/dvb/lib/libucsi/dvb/Makefile.am:19: use `AM_CFLAGS' instead.
kaffeine/src/input/dvb/lib/libucsi/mpeg/Makefile.am:12: `CFLAGS' is a user variable, you should not override it;
kaffeine/src/input/dvb/lib/libucsi/mpeg/Makefile.am:12: use `AM_CFLAGS' instead.
============================================
Then there are the many "undefined reference" errors, of which the build finally fails. As seen in the build log, all expected component packages are installed.
Darrell
I ran into an interesting quirk with libkipi, libkdcraw, and libkexiv2.
I'm trying to build gwenview and digikam for Slackware 12.2. Two popular non-core apps.
Digikam has a required dependency on libkipi and libkipi is optional in gwenview. Unless explicitly declared otherwise in the configure options, gwenview will build with kipi support when those packages are installed.
As the libkipi, libkdcraw, and libkexiv2 library packages are available upstream as well in Trinity SVN and tarballs, and these packages are not dependent upon tqtinterface, non-core packages should build with either the upstream or Trinity version of these libraries.
As I am using these same packages in KDE 3.5.10 on Slackware, and I have yet to create and test build scripts for the Trinity library packages, I proceeded to build both digikam and gwenview using my previous upstream version of libkipi, libkdcraw, and libkexiv2.
Both digikam and gwenview failed to build with those versions of libkipi, libkdcraw, and libkexiv2. The build always failed with an error about libGL.la not being available.
=====================================
grep: /usr/lib//libGL.la: No such file or directory
/usr/bin/sed: can't read /usr/lib//libGL.la: No such file or directory
libtool: link: `/usr/lib//libGL.la' is not a valid libtool archive
=====================================
I traced that file to the proprietary nvidia package. The stock X11 OpenGL provides no such la file.
In the past I must have compiled libkipi, libkdcraw, and libkexiv2 with the proprietary nvidia package installed. The packages then build somehow linked to libGL.la.
In my chroot build environment I do not have the proprietary nvidia package installed. Only the stock X11. Thus the failure when using the previous versions of libkipi, libkdcraw, and libkexiv2.
In my chroot environment I built and installed a new libkipi, libkdcraw, and libkexiv2 packages from the same upstream sources.
Gwenview and digikam then built without errors regarding libGL.la.
Gwenview only needed the newer libkipi. Digikam needed all three.
I presume the same build error will occur when using the Trinity version of libkipi, libkdcraw, and libkexiv2. That is, when a person has the proprietary nvidia package installed, then libkipi, libkdcraw, and libkexiv2 will somehow link to the libGL.la file.
I have not yet tested this with the Trinity versions of the library files. A side comment: I submitted a bug report that perhaps Trinity should not maintain versions of these libraries because they are maintained and available upstream.
I checked the libkipi, libkdcraw, and libkexiv2 configure options and did not notice anything obvious or helpful. I'm not a developer and perhaps an option exists to ignore the proprietary OpenGL.
One solution seems to be to modify the build process to prevent that linking to libGL.la.
Another solution is to always build libkipi, libkdcraw, and libkexiv2 in an environment without the proprietary nvidia package installed.
Another option is to install the proprietary nvidia package in my chroot build environment. I'm guessing then the packages will not fail to build with that particular error, but then I am no longer creating generic packages for users not using nividia. Or perhaps the final binary will still work without the proprietary nvidia package installed. I haven't any idea.
This would seem to be an upstream problem. Therefore possibly only the generic build environment is the only tenable solution.
I can add commentation in my build scripts and documentation.
Comments and advice appreciated.
Darrell
