tde-devels

devels@trinitydesktop.org

3781 discussions

Re: [trinity-devel] Can not seem to get tqt to build.
by Darrell Anderson 08 Dec '12

08 Dec '12

>I am trying to build the git version of tqt but every time it fails >with a statement saying that tqmake was not found. Is this a bug or >do I not have a package installed that I should? There is tqt3 and tqtinterface but no tqt. To which are you referring? qt3 is maintained for historical purposes only. Don't build qt3. tqt3 must be built before tqtinterface. Those two must be built before building anything else. You mentioned using Arch. Be sure to use the build scripts provided by them. I don't know whether that helps. Darrell

2 1

Currently going through images...
by pauline martin 07 Dec '12

07 Dec '12

I am currently perusing ALL of the images that are in the git repo for the trinity DE. However, I have a few questions on what all is going to get renamed or changed to have a t in the front of it and I can not find a hard list of what is and is not. So far I am wondering about the following programs... note that I have never been a big desktop environment user before I switched to trinity so some of these may be obvious to you and others I may ave missed. Please, let me know if I missed anything. Okay So far I am wandering about: Kontact Konsole Kommander Are we forking qt into tqt or is it just a built-in KPPP KDCOP KnewtworkManager KNOTE KArm KAlarm Quanta Plus Kdevelop kdewallet ... I am sure there are more... and if there is a list anywhere please let me know about it. As I find specific images I plan to set up an etherpad page for the images. Pauline Martin

1 0

Can not seem to get tqt to build.
by pauline martin 07 Dec '12

07 Dec '12

I am trying to build the git version of tqt but every time it fails with a statement saying that tqmake was not found. Is this a bug or do I not have a package installed that I should? Pauline Martin

1 0

Re: [trinity-devel] Trying to fix bug #1170 (Kima FTBFS)
by Darrell Anderson 05 Dec '12

05 Dec '12

>I am trying to build it within a chroot, but unless I am doing that >wrong I do not know what I need to do. :( I am also not opposed to >uninstalling my current version of trinity and working from a >different environment, whatever is the best way to do it. I can use >qemu or virtualbox. It does not matter to me. if there is a specific >way that one would suggest building them please let me know what it >is, even if it a little unorthodox. I build for Slackware. I have only one computer. For comparison testing, I have the following virtual machines: Slackware 12.2 with KDE 3.5.10 Slackware 13.1 with Trinity 3.5.13 I use both virtual systems to compare how things used to run and to determine whether a bug or behavior is legacy from either system or new or a regression in R14. I still work primarily with Slackware 13.1 32-bit as my main production system, although I also have a newer Slackware 14.0 64- bit system. Within my 13.1 32-bit system I use a chroot in konsole to build R14 packages for 13.1 32-bit. As I have only one computer, I have separate partitions on my system for Slackware 13.1 64-bit, 13.37 32-bit and 64-bit, 14.0 32- bit and 64-bit, and Current 32-bit and 64-bit. Typically I don't build often in any of those systems. When I find a nice quiet spot in the R14 development, where everything builds without incident and usage remains stable, then I reboot my system and will run a full package build in one of the other systems. Most often I pick the Slackware 14.0 64-bit environment. My Slackware 14.0 64-bit production and build environments are on separate partitions. Almost always I run those non-13.1 builds at night while I sleep and I don't need the computer. On my to-do list is to create virtual machines for each build system and to use the existing build environment partitions as raw devices in the virtual machines. That will provide me flexibility to support the other systems without rebooting. A sane approach, when the budget allows, is to use a second machine that hosts all of these build environments. Most people have no need or desire to support multiple systems. Just focus on building against the current system. For that a chroot is fine. Virtual machines work too, but I find virtual machines too slow for long build runs. Although written for Slackware, here is a good tutorial about creating a chroot: http://slackworld.berlios.de/2007/chroot_howto.html In the past, in all of my build environments, I remove all KDE4 related packages. I do that create as pure a build environment as possible. I have been removing Qt4 as well, but I'll need to change that in order to build and test some of the newer packages Trinity provides. The cmake packages don't have a problem correctly finding (T)Qt3 rather than Qt4. The automake packages tend to get confused, but the work-around is to explicitly declare where to find the (T)Qt3 packages: --with-qt-dir=${QTDIR} --with-qt-includes=${QT_INCLUDE_DIR} --with-qt-libraries=${QT_LIB_DIR} In all of my build environments I don't use any desktop environment or window manager. I run my sole chroot from a terminal window and all other build environments from the console. A sane approach is to focus on just building one package at a time in the order suggested in the wiki. Get TQt3 to build. Then tqtinterface. Etc. The Trinity wiki and Arch web site should provide the gritty details. I'm guessing the Arch web site for Trinity provides all build scripts. I believe most of us use a parent/master script to build each package successively without user intervention. The 3.5.13.x branch is for back porting patches. Therefore the primary build environment uses the R14 development branch. Darrell

2 1

Distro build scripts
by Nick Leverton 04 Dec '12

04 Dec '12

I won't hijack Pauline's thread but I'm interested in distro build scripts, specifically in my case for Debian. May I enquire as advertised ? :-) I can't see much in git apart from the debianrules scripts but they seem to generate something almost but not quite entirely unlike[*] the debian/ directory in a sample nightly source package I just downloaded. It strikes me that it would be worth keeping the distro build scripts in git too, perhaps in a different part of the tree, if they aren't already ? All pointers welcome ! [*] I exaggerate for comic effect. It *is* entirely unlike debian/* Nick

2 2

Re: [trinity-devel] Trying to fix bug #1170 (Kima FTBFS)
by Darrell Anderson 04 Dec '12

04 Dec '12

>As Slávek said this package is still built with the autotools. >However when I run the configure script it runs through the script >until it stops when it tries to find tde-config. If I change it to >kde-config (in the configure script which I know should not be needed) >it tells me that it cannot find the qt-mt library. Starting with R14, kde-config is renamed to tde-config. All previous Trinity releases still use kde-config. The trick then is to ensure your build environment is correct. If you are building 3.5.13.x then you use the 3.5.13.x tarballs. If you are building R14, then use the GIT tree as sources rather than tarballs. R14 is expected to be built against TQt3, which will install a tqt- mt pkgconfig file. If you build with Qt3, as is the case prior to R14, then a qt-mt pkgconfig file is installed. If you are running 3.5.13.x as your production environment, you can still build R14. Use a second computer, use a virtual machine, use a chroot environment, reboot to a different partition set, etc. Slavek and Francois build and support both environments. They would be the best people to ask for advice how they manage both environments. Darrell

2 1

Re: [trinity-devel] Seeking to help in the development of Trinity
by Darrell Anderson 04 Dec '12

04 Dec '12

>> I was thinking of making the triquetra-type image (overlappingballs >> whatever) in place of the T in the gear (originally a K from KDE). As >> that is one location that needs to be obviously be rebranded if we are >> to trully become our own entity away from kde. Other imagery would of >> course need to go as well and I will work on creating a list of other >> apps and stuff that I think might be good to change their art for. >> Suck as Chalk, and in sme cases it might be good to know what the >> image for for the DE is before creating an entire set of icons and art >> that would go with it. I do need to however, either find a list of >> art that needs to go or to create one. Otherwise, it would almost be >> like chasing a bouncing ball in the dark. > >Just did a search through the contents of tde-tdeartwork and found a >few more images that I thought might be worth changing. These are (without the file type): > >about_kde >go_old >go >kfs_kde (might want a totally new mascot character /thing) I can make >a mascot/character if so desired) >kmenu >krec >krita_kra >krita > >However, I do realize that by changing a subset of icons and imagery I >would have to force myself to stay within their style and feel. Where >as a completely new set (yes more work) could be desired more. I also >realize that only some of the art that might be desired to be replaced >is within tde-tdeartwork. A list or a road map is a good first step. Don't spend time creating images or mockups at this point. :) We have an etherpad site where you can store and share the road map: http://trinity.etherpad.trinitydesktop.org I don't remember how to create an account. :( Contact Tim. One challenge with changing art work is changing the respective files for all theme and icon collections. These tend to be scattered about but mostly in tdelibs, tdebase, and tdeartwork. Rather than modify any of the existing icon themes, a same approach is just changing a handful of files while retaining consistency with the theme style. New art work helps promote a new project identity, yet we want to retain some roots to KDE 3. Trinity is a continuation of the KDE 3 model and we don't want to abandon those roots. We probably need some kind of list discussion about which specific images to change, but for myself I prefer to retain the "T in the gear" images. On the other hand, a new mascot is a great idea. I also like the idea of a complete rebranding of chalk images. Darrell

3 2

Re: [trinity-devel] Trying to fix bug #1170 (Kima FTBFS)
by Darrell Anderson 04 Dec '12

04 Dec '12

>Which packages do I need to install to build the package from the git >tree. My base installation of Trinity is: tde-tdebase 3.5.13_sru- 2. >I may need to install developmental builds of the dependencies, for my >distribution (Arch Linux, if it matters. There are several Archers subscribed to this list. Calvin and David come to mind. The Archers have a specific web page posted at the Arch web site for building Trinity. The first place to collect build information is the Trinity wiki: http://www.trinitydesktop.org/wiki/bin/view/Developers/HowToBuild As mentioned previously, the best approach is to build TQt3 and not Qt3 and then build the remaining package set against TQt3. Note that all packages can be built to /opt/trinity except one: tqtinterface. That package needs to be built to install to /usr. I don't know when that will be fixed and changed. Generally, most of us build to /opt/trinity rather than /usr to avoid conflicts with KDE4, which is provided in most distros. A primary reason is although we have renamed many files, many remain with the same name as those used in KDE4. Check the wiki for the suggested build order (section 7). There are two branches from which to build: 3.5.13.x and the development branch, targeted as R14. I build exclusively from the R14 branch and use those packages daily as my production system. Very stable. Yes, there are bugs, irritants, and build issues, but I have work-arounds for almost all problems. In other words, don't be afraid to build from and use the R14 branch. :) Darrell

1 0

Re: [trinity-devel] Trying to fix bug #1170 (Kima FTBFS)
by Darrell Anderson 04 Dec '12

04 Dec '12

>I am trying to fix the bug (#1170) where kima fails to build. >However, I can not seem to get cmake to build the kicker applet. Is >it possible to get the build scripts for it,, so that I can make my >adjustments and see if they work. As Slavek mentioned, kima has not yet been ported to cmake. Here are my basic configuration options: CFLAGS=$CPUOPT \ CXXFLAGS=$CPUOPT \ ./configure \ --prefix=${PREFIX} \ --sysconfdir=${SYSCONFDIR} \ --libdir=${LIBDIR} \ --mandir=${MANDIR} \ --with-qt-dir=${QTDIR} \ --with-qt-includes=${QT_INCLUDE_DIR} \ --with-qt-libraries=${QT_LIB_DIR} \ --enable-gcc-hidden-visibility \ $DEBUG_AUTOTOOL_OPT || exit 1 I seem to recall some list discussions about the problem. Possibly check the list archives: http://trinity-devel.pearsoncomputing.net/ Note that kima builds without incident on systems that have HAL. The challenge is building kima on newer systems that don't have HAL. Resolving the bug report requires using the new Trinity TDEHW libs. That means building tdebase appropriately: -DWITH_HAL=OFF -DWITH_TDEHWLIB=ON And of course ensuring that HAL is not installed on the build system. :) Darrell

1 0

Trying to fix bug #1170 (Kima FTBFS)
by pauline martin 04 Dec '12

04 Dec '12

I am trying to fix the bug (#1170) where kima fails to build. However, I can not seem to get cmake to build the kicker applet. Is it possible to get the build scripts for it,, so that I can make my adjustments and see if they work. Pauline Martin

3 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels