tde-devels December 2012

devels@trinitydesktop.org

19 participants
36 discussions

Re: [trinity-devel] Commit 786e248c 2012-12-01 breaks tdebase in GIT

by Darrell Anderson

>> It should come with binutils. Google shows a lot of bug reports for >> several distros saying that this file should be installed. > >thanks for that info. I copied in demangle.h from Slackware's >binutils source package and all seems to be good. (tdebase >compiled successfully, anyway.) This is not a palatable solution. As mentioned, searching the web reveals that including demangle.h in binutils is not something that can be presumed. Although some distros have been patched, not all have been patched. Trinity has to build against stock distros and not kludges. I've emailed the Slackware maintainer but there is no guarantee a patched binutils is forthcoming. Can the original commit be rewritten to not use demangle.h? Otherwise the only solution is reversing the original commit. I believe that code was committed primarily as a troubleshooting aid against bug report 1288. Therefore reversing the patch should not cause any problems, but do we want to keep that code in GIT permanently, even after bug report 1288 is resolved? Darrell

11 years, 11 months

Re: [trinity-devel] Gentoo issues.

by Darrell Anderson

>> The $DESKTOP_SESSION shell variable is set in 'startkde' script. I think the >> current value in 3.5.13.1 is "trinity". thanks for info, that was helpful > >Seems I found a reason of all this: trinity runs autostart files from >/usr/share as well as from it's own autorun subdirectory. >The nice workaround will be to remove /usr/share/autostart from an >autorun path. I haven't found yet there those paths are come from >but it should work. Anyway it's not a solution... > >IMHO the solution will be to stop using files contaning >OnlyShowIn=KDE (it will require small fixes in tdelibs and tdebase) and change >all such entries in our desktop files to TDE. I remember this bug hitting me a long time ago. The problem varied for everybody, but was path and environment variable related. For path issues we did a lot of work on fortifying the startkde/starttde script. For example, when the Trinity version of startkde/starttde is run, $TDEDIR/bin is in the search path before /usr/bin. For the environment variables the problem was KDE4 startup scripts in /etc/profile.d being sourced during login as well as the Trinity profile.d scripts. Because the underlying system has to support whichever desktop the user wants to run, one solution is to modify the system's startup scripts to only source the correct profile.d scripts rather than source every profile.d script tagged executable. My work-around was to tag all Trinity and KDE4 profile.d scripts not executable. I created a new profile.d script named zlocal.sh and in that script I sourced the appropriate profile.d scripts based upon whether starttde or startkde is being used. As 3.5.13.x and KDE4 uses the same named startkde, this still works because the Trinity version of startkde is installed to /opt/trinity/bin and not /usr/bin. To complete the circle, I use the full path in my Trinity xinitrc script such as /opt/trinity/bin//startkde rather than just startkde. Another problem is KDE4 only uses KDEDIRS and not KDEDIR. One solution then is not to use KDEDIRS in Trinity. The R14 branch should not have this problem because of the many XDG related changes (e.g., OnlyShowIn=TDE). Environment variables all have been renamed in R14 too (KDEDIR->TDEDIR, etc.). Also, a fringe wild shot, but try running the migratekde3 script against your profile directory. The script is not part of 3.5.13.1 but probably will be part of 3.5.13.2. The script is in GIT tdebase: http://git.trinitydesktop.org/cgit/tdebase/tree/migratekde3 Darrell

11 years, 11 months

Commit 786e248c 2012-12-01 breaks tdebase in GIT

by zlists＠ns.sympatico.ca

Hi I cloned myself a copy of tde yesterday and tried to compile it on Slackware64 14.0. (I use the Slackware build scripts available at http://humanreadable.nfshost.com/sdeg/trinity_desktop.htm.) All went well until I was compiling tdebase, when it crashed and burned with: Generating tdmadmindialog.moc cd /tmp/tdebase.build/tdm/kfrontend && /usr/bin/tmoc /tmp/tdebase/tdm/kfrontend/ tdmadmindialog.h -o /tmp/tdebase.build/tdm/kfrontend/tdmadmindialog.moc /tmp/tdebase/kdesktop/lock/backtrace_symbols.c:57:22: fatal error: demangle.h: No such file or directory compilation terminated. Slackware does not have demangle.h (nor does an Ubuntu 12.04 that I have lying around). Is there some other package which has been added as a pre-requisite with that commit? Or is there some way to change that patch so that we don't actually need that file? Thanks. Jim

11 years, 11 months

Re: [trinity-devel] Can not seem to get tqt to build.

by Darrell Anderson

>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

11 years, 11 months

Currently going through images...

by pauline martin

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

11 years, 11 months

Can not seem to get tqt to build.

by pauline martin

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

11 years, 11 months

Re: [trinity-devel] Trying to fix bug #1170 (Kima FTBFS)

by Darrell Anderson

>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

11 years, 11 months

Distro build scripts

by Nick Leverton

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

11 years, 11 months

Re: [trinity-devel] Trying to fix bug #1170 (Kima FTBFS)

by Darrell Anderson

>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

11 years, 11 months

Re: [trinity-devel] Seeking to help in the development of Trinity

by Darrell Anderson

>> 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

11 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels December 2012