tde-devels

devels@trinitydesktop.org

2 participants
3805 discussions

GIT change
by Timothy Pearson 09 Dec '12

09 Dec '12

All, I have recently blown away the history of the main TDE GIT supermodule (which does NOT contain any files, only submodule references) in order to speed up processing and downloading of that supermodule. The aforementioned history was not useful, consisting primarily of automated updates to the submodule hashes. I have, however, left the 3.5.13-sru branch and associated tags intact as there is no good way to shrink/squash them. Developers, please delete and re-download the top-level GIT supermodule. I have temporarily locked out commit access to that top level supermodule to prevent accidental merges of the old history. All other GIT modules continue to have normal read/write permissions for the TDE development team, so the impact of this should be minimal. One of the most developer-visible benefits of this change is that the TDE commits web page will now update every 6 hours instead of every 12 hours. Tim

2 2

Re: [trinity-devel] Commit 786e248c 2012-12-01 breaks tdebase in GIT
by Darrell Anderson 09 Dec '12

09 Dec '12

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

1 0

Re: [trinity-devel] Gentoo issues.
by Darrell Anderson 09 Dec '12

09 Dec '12

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

1 0

Commit 786e248c 2012-12-01 breaks tdebase in GIT
by zlists＠ns.sympatico.ca 09 Dec '12

09 Dec '12

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

4 3

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels