tde-devels

devels@trinitydesktop.org

8 participants
3849 discussions

Building kdeartwork
by Darrell Anderson 15 Sep '10

15 Sep '10

Okay, I'm a little slow. I added the --enable-closure option to the kdeartwork build script and the package built. Thus, at this point, all core trinity kde packages build on Slackware 12.2! Darrell

2 1

Startup Management
by Darrell Anderson 15 Sep '10

15 Sep '10

There is some nominal support in kcontrol to support startup management. I don't know what all is available in this area for KDE 3.5.x, but I'd like to see more. As Slackers tend to be rather anal about such GUI apps <roll eyes>, very little in that way ever apeared in Slackware. There is some kind of Lilo manager hook in kcontrol. There is something called qgrubeditor that supports GRUB 1. That tool now only supports QT4 (what's new). I don't see qgrubeditor in svn so here is a vote to support that. Then there are the startup services and daemons. I don't know if any KDE GUI tool exists for that. If there I would appreciate a link so I can consider how that tool might be adapted to Slackware. I think the Ubuntu folks have something like that, but of course, GTK. This all would be something for 3.5.13 of course. Darrell

3 6

Building kdeartwork
by Darrell Anderson 15 Sep '10

15 Sep '10

All core packages, as well as amarok, ktorrent, k3b, and knemo built without error! kdeartwork is the lone holdout in tonight's effort. :( Log attached. Darrell

1 0

Helpful Packages But Not Prerequisties
by Darrell Anderson 14 Sep '10

14 Sep '10

I'm thinking ahead with you offering binary packages for Slackware. There are several packages that do not have to be installed to build the core KDE packages. I have created this list from watching the build messages and logs. There might be additional packages to add to this list: libcarddav (part of the Trinity Project, kdepim) libcaldav (part of the Trinity Project, kdepim) avahi (dns-sd, DNS service discovery/zeroconf, kdelibs/kdebase) lua hspell (Hebrew spell checking) krb5 (kerberos) OpenEXR Libraries (EXR image format support, several KDE packages) GraphicsMagick (various image filters; e.g. koffice/krita, kdebase) JRE-Java Runtime Engine (kdebindings) JDK-Java Development Kit (kdebindings) SIP PyQT3 PyKDE (Trinity KDE Python bindings; require SIP and PyQT) PostgreSQL (koffice/kexi) Transcode, ffmpeg (k3b ripping) libdvdread, libdvdnav (k3b video ripping) If the binaries are built without these packages installed, then the build process will not create any related support, even if the end-user installs those packages after installing the KDE packages. If the binaries are built with these packages installed, then the end-user should be able to make use of those hooks as soon as the additional packages are added. What happens when the packages are built to provide that support but the end-user does not have the support packages installed? I'm presuming nothing happens and the built-in support is a dead-end stub. Hopefully the xsession errors log is not filled with useless messages. I always thought the KDE developers were horribly sloppy about controlling stdout/stderr messages captured in the xsession errors log. Have you done any testing in this area or offer any observations from daily use of Trinity? As you liked the idea about two sets of packages, one embracing full third-party support and one set stripped to the essentials, seems some testing in this area will be needed if we travel that road. For my first full build set I am going to build mostly without the third-party support. I likely will install most of the third-party packages listed previously and then build another set of packages. I'm curious what the differences will be in package sizes and performance. I have both a Pentium I and II box that provide some hard-core performance testing of any distro. :) If you decide to support two sets of packages I foresee a handful of exceptions. For example, people using K3B will presume and want full ripping support out of the box. I think that package has to be built the same for either set of packages. The K3B package in Slackware never was built that way because of concerns about digital restrictions. I always thought the package should be built with full support but then just don't include the other packages with the distro. At least then when users add the necessary support packages K3B would work immediately as advertised. Darrell

1 0

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels