I don't know when those errors started to appear, but I think they started after I updated GIT today.
The errors are in my build log and look like this:
cd /opt/trinity/bin && ./tdelfeditor -m /dev/shm/arts.build/soundserver/artswrapper "artswrapper" "" "" "" "" "Trinity Desktop Environment" "" "" "01/19/2012 19:33:11" "artswrapper" "" || true
/bin/sh: line 0: cd: /opt/trinity/bin: No such file or directory
The problem is /opt/trinity/bin does not yet exist. Hence the errors.
I built qt3 and tqtinterface to build to /usr. Everything else I am building to install to /opt/trinity.
The errors occurred while building arts, the third package in the core series of packages.
I can eliminate the messages with mkdir -p /opt/trinity/bin, but I think there should be a test that /opt/trinity/bin exists. Of course, /opt/trinity/bin gets created after I install the arts package. Thereafter the errors will not occur.
I suspect the errors are harmless, but I always search my build logs for "No such file or directory" errors. That is one way I catch problems. Not having those errors in the build logs helps reduce clutter. :)
Darrell
tdesdk comes with an app called kbugbuster. Everything I have read online indicates the app is broken.
* Is there any hope of getting kbugbuster updated to interface with the Trinity bugzilla? If yes, then I'll submit a bug report/enhancement request.
* If not then should kbugbuster be stripped from the package?
I would love to have a local desktop tool to query bug reports. Would save a lot of bandwidth on the Trinity servers as well as user's bandwidth too.
I am aware of deskzilla --- a java app and one that is guaranteed to work only with the Sun (now Oracle) version of Java. The free version handles up to 2000 bug reports. We're a long ways from that, but I am uncomfortable with the idea of acclimating to an app and when bug/enchancement report 2001 rolls around I no longer have a useful app (unless buying the professional version).
Would be nice to use a native qt3 app.
So --- what is the verdict with kbugbuster?
Darrell
So as pointed out its rather annoying to type your password in 50 times,
and most people won't bother creating a script to export the git password
variable.
A quick solution I found was this:
yes "password" | path/to/script
yes will repeatedly echo the same thing forever! thank god for loops.
Calvin
I don't know where to start but apparently cmake, or something related to cmake with respect to Trinity, or pkgconfig, is broken on my Slackware 13.1 build environment.
Tim helped me with some testing. We know that something is not right when trying to build Trinity on Slackware, but we have to find the root cause. Tim believes the built-in pkgconfig system in my build environment is not working correctly.
I have not experienced any build issues with many other cmake packages not related to Trinity. I have been building my own packages for many years. I would have noticed something awry with other packages and not just Trinity packages. Therefore I believe the problem is limited to my build environment for Trinity.
The problems are provided in bug report 581, but narrow to this:
1) cmake will not populate the internal TQT_INCLUDE_DIRS variable. Although the problematic package reported in bug report 581 is tdelibs, I have verified this to be true with arts and tdebase too. Oddly, both of those packages build without that internal variable being set. Regardless, the problem seems to be fundamental that TQT_INCLUDE_DIRS never gets populated. Because of this failure to populate that internal cmake variable, the tdelibs build fails almost immediately with this error:
cc1: error: tqt.h: No such file or directory
Of course, tqt.h does indeed exist in my build environment. Nobody else has reported this failure.
2) The second problem is tdelibs will not build unless a sym link exists:
cd /usr/include/tqt; ln -s ${QTDIR}/include/qglobal.h qglobal.h
At least one other Slackware user reported this same sym link requirement: http://trinity-devel.pearsoncomputing.net/?0::3307
According to Tim, the sym link is not required by anybody else.
Oddly, arts and tdebase will build without the TQT_INCLUDE_DIRS internal variable and the sym link. tdelibs and tdevelop both fail to build without these requirements being met.
In my tdelibs build script I wrote a small test that executes just after the cmake configure and before make. All I did in my snippet was look for a value in TQT_INCLUDE_DIRS and when empty, grab the value from TQT_INCLUDEDIR and populate TQT_INCLUDE_DIRS with that value.
That produced some nominal success. Instead of the usual cc1 message about tqt.h not existing, I received an error message about not finding qglobal.h. I inserted a aforementioned sym link and then the tdelib package built.
So even if I discover how to get the TQT_INCLUDE_DIRS internal variable to populate automatically, I still need to figure out why this sym link is needed when nobody else does.
I'm using cmake 2.8.4 on Slackware 13.1, although the stock Slackware 13.1 came with 2.8.1.
I have tested this with and without Qt4 being installed, so the problem is not crossing paths with Qt4.
I'm open to the idea that I'm not correctly setting environment variables, or that I am making a common mistake or presumption throughout my build scripts. I am not embarrassed if this turns out to be a PEBKAC issue. :)
I appreciate any help. There is an interest in Trinity in the Slackware community and my web site gets quite a few hits every day at my KDE3 and Trinity pages. I'd like to get these problems resolved because others in the Slackware community look to me as a pivot point to build and use KDE3 and Trinity.
I know next to nothing about cmake or pkgconfig. I just use them. :) So please start with the basics when trying to help. Don't assume I know better --- I probably don't, although I learn quickly. :)
Thanks much!
Darrell
Darrell
Re: For example, after configuring Kate with the --use parameter
Exactly where and how (any quotes, etc) did you set the --use
parameter for Kate.
Tell me that and I will experiment and see if I have the same problem.
Keith
When Kate is already open, and in Firefox I press Ctrl-U to open the web page in the assigned external text editor (Kate), the web content opens in a second Kate session.
I want to use the current session only. I'm an MDI kind of person. :)
Editing the Firefox preferences to "kate --use" then causes Firefox to open the web page content in the Firefox viewer rather than Kate.
All of my kate related *.desktop files are set to kate --use.
Any ideas how to fix this?
Darrell
Has anybody tried this GIT Qt GUI front-end? Looks like the older version is Qt3.
Does somebody with a decent grasp of GIT want to give this app a try? I know next to nothing about GIT and am wondering whether something like this might help.
Darrell
Since I'm trying to come up with an idea for new [a little more
modern, and not looking like it was made in 2003 (no offense to
creator intended)] Trinity website I'd like some help. What I need is
a logo, a symbol for Trinity. And one that is not religious (since the
name was understood as a religious one once). The current logo is a
no-no IMO since it's a too big reference to the KDE logo (gears) and
it just kde3.5 logo with a "T" instead of "K". It should be something
simple and easy to remember.
I know I might be demanding too much, but I think it's a good idea to
come up with something together.
Hi,
attached is a patch (tested in KDE 3 in Kubuntu Hardy, untested
in Trinity) which resolves the problem with non-ASCII filenames
on WebDAV servers. I’ve designed it using the Qt3/KDE3 APIS af‐
ter how it was fixed in KDE 4.
I’m not a C++ developer, and this is a one-shot. Criticism – of
course – welcome. Please Cc me in replies.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Elmar Geese
GIT 2678
tdesdk was built with automake, but now in GIT is built with cmake. In my previous automake build script I had these two build options:
--with-apr-config=/usr/bin/apr-1-config
--with-apu-config=/usr/bin/apu-1-config
Are these build options necessary in the cmake version or are they automatically detected? I don't see anything obvious in the cmake files.
Darrell
