tde-devels

devels@trinitydesktop.org

2 participants
3855 discussions

Wiki Page
by Darrell Anderson 14 Sep '10

14 Sep '10

> Also, on a different note, a Web page now exists that > details most of the > major changes from stock 3.5.11 to Trinity 3.5.11. > The address is > http://trinity.pearsoncomputing.net/wiki/bin/view/Documentation/Releases_3_… Looks nice! Some thoughts: Image sizes might be too large for folks on slower connections. I have a nominal broadband connection and some of the images took several seconds to download. How about a note that Ark was patched to support lzma/xz? Oh wait, never mind --- that is an improvement to 3.5.12. Seems we will need a 3.5.12 page too! What was the date of the official 3.5.11 release? I'll try to learn how to parse the svn logs since that date to create a punch list of improvements since then.

2 3

Re: [trinity-devel] Building kdebindings
by Darrell Anderson 14 Sep '10

14 Sep '10

> I did some poking around the Trinity source tree, and it > appears the > reason for the build failures is outdated code. Eons > ago Debian split out > the three components contained in kdebindings into > different source > packages. > > The components are: > SIP > PyQt > PyKDE > > I agree with this decision for the following reasons: > 1. SIP and PyQt are both maintained upstream and function > perfectly with > Trinity as-is; it makes no sense to maintain a > Trinity-specific copy of > these software projects. > 2. PyKDE needs to be patched for Trinity, and has already > been moved to > <svnroot>/libraries/python-kde3 > 3. This decision seems to fit with the general > user-configurability model > of Trinity; some users may want to install the Java/Ruby > bindings, but not > the Python bindings. > > With this in mind, I believe the correct course of action > is to remove the > <svnroot>/kdebindings/python folder completely. I don't know whether these decisions are correct. I'll trust you. As long as kdebindings works as expected in non-Debian systems _and_ various python bindings work in KDE. Slackware always uses stock KDE sources from upstream. Thus, if the KDE devs were including sip and python support in kdebindings, Patrick would not monkey with that. NOt saying who is right or wrong, just sharing facts. :) SIP was not included with the stock Slackware but available as an extra package. PyQt3 was not included with the stock Slackware but available as an extra package. PyKDE is unknown to Slackware. By your description, sounds as though this Debian package is the python-specific portion originally packaged with kdebindings. Sounds as though the first two packages are not strict build prerequisites, but recommended build prerequisites and should be built/installed by people who want those bindings when building pyKDE. Is that correct? Or do users merely install SIP and PyQT after installing KDE and those bindings work thereafter with KDE? There has to be some way when building kdebindings to provide the foundations hooks so python will work with KDE. How does all of this affect building the core KDE packages? Do I need to modify my kdebindings build script? With that said, I have progressed further with kdebindings. I mentioned my scheme to copy on-the-fly in my build script the python/sip/sipgen files from 3.5.10. That gets me past the original build failure. Of course, your information sounds as though all of that will disappear now anyway. Sounds good. With that said, my builds go for a while before failing. I have patched some /usr/include files from kdelibs. All of the patches are one-liners adding a specific tqt interface include statement. You can review the patches and decide whether they are necessary. Maybe they are, maybe they are not with the changes you propose. The process is slow because I get to see only one failure when the build fails. I add an appropriate include statement and then build again. I don't know the QT/TQT interface like you and I have to learn which include statement to add. Takes time. Regardless, the three patches I am including eliminate the build failures related to those files. Good thing this stuff can run in the background. :) I just compiled again and received an error I don't know how to fix. Log attached. I don't now how this is all affected by what just shared, but I suspect we are getting closer to building kdebindings. :)

2 5

Building kdebindings
by Darrell Anderson 14 Sep '10

14 Sep '10

FTBFS. Build log and build script attached. Darrell

2 6

Re: [trinity-devel] Building kdemultimedia
by Darrell Anderson 14 Sep '10

14 Sep '10

You da man! Got the package to build --- with one additional patch. Patch attached. Two down, two to go! kdebindings koffice I'd like to get kdebindings fixed first on simple idea that building and installing koffice presumes a full core package install. Regarding kdebindings, I posted a possible fix in a previous message. I suspect some of the python/sipgen files need some tqt interface include statements. I have been fiddling with koffice and have noticed some things that might help troubleshoot.

1 0

Re: [trinity-devel] Building kdemultimedia
by Darrell Anderson 14 Sep '10

14 Sep '10

> OK, try again with the latest SVN. Updated svn. FTBFS. Log attached.

2 1

Building kdemultimedia
by Darrell Anderson 13 Sep '10

13 Sep '10

I discovered I did not have gstreamer, gst-pugins, or lame installed in my chroot. I have them installed on my main system. I installed all of those packages in my chroot and tried again to build kdemultimedia. FTBFS. Log attached. Searching the web reveals that the failure seems rather common. I just don't know how to solve. Darrell

2 1

List server search function
by Darrell Anderson 13 Sep '10

13 Sep '10

Looks like the list server search function is broken again. Darrell

2 1

Headers Present But Cannot Be Compiled
by Darrell Anderson 13 Sep '10

13 Sep '10

"Headers Present But Cannot Be Compiled" I have seen that configure message several times. The most recent was with building kdepim. That particular error was about bluetooth/bluetooth.h and is described exactly here: http://flameeyes.eu/autotools-mythbuster/autoconf/finding.html#autoconf.hea… The specific problem file is: kdepim/configure.in.in The other times I have seen that error was with respect to linux/cdrom.h. The problematic files are: kdebase/kioslave/media/configure.in.in kdemultimedia/configure.in.in kdemultimedia/kscd/libwm/configure.in.in I grepped the source tree and did not find any other files. Hopefully you can use that information to fix the problem! :) Darrell

1 0

Re: [trinity-devel] Building kdepim
by Darrell Anderson 13 Sep '10

13 Sep '10

> The new feature should be present in SVN revision 1174561 > or higher. It > will detect when libcarddav or libcaldav are not present > and automatically > deactivate the affected resource(s). Not sure whether I understand correctly. I removed the libcaldav package and rebuilt kdepim. I have libical installed because I understood that the package is a requirement. FTBFS. Log attached.

2 3

Re: [trinity-devel] Configuration installation directory locations
by Timothy Pearson 13 Sep '10

13 Sep '10

> What configuration directory installation locations (--prefix, --libdir, > --sysconfdir, etc.) are you using for all of your trinity builds? > > Are the locations the same for Lenny (KDE4/QT4 not installed) as the > others where KDE4/QT4 are installed? Yes, they are identical whether or not KDE4/Qt4 is installed. > > Thanks. > > Darrell > What I use for the Debian builds is: --prefix=/opt/trinity --includedir=/opt/trinity/include/kde --mandir=/opt/trinity/share/man --infodir=/opt/trinity/share/info --with-extra-libs=/opt/trinity/lib --sysconfdir=/etc --localstatedir=/var --libexecdir="\${prefix}/lib/kdebase-kde3" --disable-rpath --with-xinerama --enable-closure (when needed, which is most of the time) There may be one or two that are module specific that I did not mention here, but this should permit close compatibility with the Debian builds. Tim

2 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels