Guys,
cmake-gui in Trinity broke within just the last day or so. I know, because I
was running it not 2 days ago. I went to start it tonight and got the following
error:
cmake-gui: error while loading shared libraries: libQtGui.so.4: cannot open
shared object file: No such file or directory. Huh?
It was just working one or two rebuilds ago. I have confirmed on both i686 and
x86_64. I haven't changed anything in the way I'm building it. So something is
amiss.
I've grepped the package lists for 'libQtG' and there is none to be found in
any of the packages. I'm guessing it is supposed to be provided by Qt3, but I've
looked at that package list and there is no libQtG anything.
I'm perplexed and where this problem lies -- or what I did to create it? Help?
Let me know if you want a bug report. Thanks.
--
David C. Rankin, J.D.,P.E.
Hi guys!
I've updated Chakra's kdemod3 packages to Trinity 3.5.12 and I would
like it to be added to the list of distributions with prebuilt
packages.
This is the thread in the Arch forums about the project:
https://bbs.archlinux.org/viewtopic.php?id=97612
Best regards,
Albert Vaca
Of course!
If it is a bug then it should be filed immediately. The point of the bug tracker is to keep things organized. This is a smaller issue so unless it is in the tracker it maybe overlooked. Definitely file that baby.
Calvin Morrison
Next time somebody is in the code near the default settings for Login Manager,
have a look at the font size and Greeting line.
The current fonts are 22 pt for the Greeting, 10 pt for Failures, and 10 pt for
General. I would propose 14, 10, 8.
The current greeting welcomes you to Ubuntu. I would propose Trinity?
I'll update the default proposals on the wiki as well
--
David C. Rankin, J.D.,P.E.
Whew,
I'm done for the weekend :) Attached is a chart showing the current state of
the applications/... cmake ports as well as the errors I encountered trying to
build the ones with the old CMakeLists.txt files. (these are just notes I took
working through the applications directory)
The chart should be self-explanatory. If there is an 'x' in the CMake Port
column, that just means a CMakeLists.txt file exists (not necessarily a Trinity
CMakeLists.txt file). If there is a date under the Date column, then I was able
to build it on Arch. The errors encountered in building are listed in the Error
Description column. Ignore the last column.
The openoffice calc file is here:
http://www.3111skyline.com/dl/dt/trinity/arch/doc/app-cmake-port.ods
It would be helpful to keep some type of running list on the status of the
port effort. (it may already exist - dunno)
Great job to all on Trinity. It's really looking good.
--
David C. Rankin, J.D.,P.E.
Guys,
I'm trying to learn how to solve these include errors. At first glance, it
looks like the build isn't accepting my:
export CMAKE_INCLUDE_PATH=/opt/qt/include:/opt/qt/include/tqt:/opt/trinity/include
The error I'm dealing with is:
[ 7%] Building CXX object kdialogd3/CMakeFiles/kdialogd3.dir/kdialogd.o
cd /home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3 && /usr/bin/c++
-march=x86-64 -mtune=generic -O2 -pipe -Wnon-virtual-dtor -Wno-long-long
-ansi -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W
-Wpointer-arith -Wwrite-strings -Wformat-security -fno-exceptions -fno-check-new
-fno-common -O2 -I/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3
-I/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3
-I/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/common
-I/opt/trinity/include -I/opt/qt/include -o
CMakeFiles/kdialogd3.dir/kdialogd.o -c
/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3/kdialogd.cpp
In file included from
/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3/kdialogd.h:4:0,
from
/home/david/tblds/trinity-app-kgtk-qt3/src/kgtk-qt3/kdialogd3/kdialogd.cpp:3:
/opt/trinity/include/kfile.h:21:19: fatal error: tqdir.h: No such file or directory
compilation terminated.
I think the short answer is the cmake files have not been tailored to Trinity,
but I'm trying to figure out how to do that. The chain of the error seems
simple, /opt/trinity/include/kfile.h includes:
#include <tqdir.h>
which is in /opt/trinity/include/tqt, so in order for it to be seen as a
standard <file.h> include instead of a "tqt/file.h" include, the Trinity cmake
setup must do something to tell the compiler to look in /opt/trinity/include/tqt
as a standard include directory. I thought that was what I was doing with
CMAKE_INCLUDE_PATH=.... What else do we need to do in the cmake files?
Thanks :)
--
David C. Rankin, J.D.,P.E.
Guys,
Just an update. I was able to get applications/kde-style-qtcurve to build with
the existing CMakeLists.txt, but as with gtk-qt-engine, it doesn't look like a
normal Trinity cmake file. This brings the current Trinity packages building on
Arch to:
trinity-app-amarok-1222475-1-x86_64.pkg.tar.xz
trinity-app-gtk-qt-engine-1222892-1.0-x86_64.pkg.tar.xz
trinity-app-style-qtcurve-1182805-1-x86_64.pkg.tar.xz
trinity-arts-1214641-1-x86_64.pkg.tar.xz
trinity-kdebase-1222475-1-x86_64.pkg.tar.xz
trinity-kdelibs-1222475-1-x86_64.pkg.tar.xz
trinity-kdevelop-1222477-1-x86_64.pkg.tar.xz
trinity-kdewebdev-1222551-1-x86_64.pkg.tar.xz
trinity-pyqt3-3.18.1-9-x86_64.pkg.tar.xz
trinity-qt3-3.3.8-20-x86_64.pkg.tar.xz
trinity-tqtinterface-1222551-1-x86_64.pkg.tar.xz
Let me know if there are additional modules that should build under cmake. I
have been watching svn update and browsing through the applications directory to
see what might build. We should keep a list of what is currently ported and
should be working. That way we can concentrate building on the new packages to
catch build errors.
If I can get my hands on a complete list, I'll add it to the HowToBuild wiki
page so we have a running list.
Also, if we should not expect the apps with the older generic looking
CMakeLists.txt to work properly, let me know and I'll hold off making the
development packages available to Arch. Thanks.
--
David C. Rankin, J.D.,P.E.
> Re: KDESU
> From: Darrell Anderson <humanreadable@...>
> Date: Sat, 11 Dec 2010 19:52:20 -0800 (PST)
> Some things I noticed when using kdesu to open Kate.
> 1. In the password dialog box there was no check box to remember the
> password.
> 2. For my root user I have Kate configured to use a pink background
> rather than white. That serves as a simple reminder I am working as
> root and not as a normal user. Yet in Trinity, after launching through
> kdesu, Kate did not display the background as pink but white.
> Superficially that seems to indicate Kate inherited the normal user's
> properties rather than root's.
> 3. After running kdesu to open Kate, I continually received DCOP
> error messages of the effect that KLauncher could not be reached via
> DCOP. Basically I had to restart my desktop session thereafter to
> launch apps.
> Comments? Confirmations?
Hi Darrell
It, doesn't look like you can respond to archive post that were not
delivered directly to your mail box. I hope this kludge I'm making
works and you get this post.
I am assuming you are using Ubuntu or Debian. For this problem I
think they are a lot alike. I am running Ubuntu.
When I was a webmaster I kept doing the same thing over and over and
got different results every time. <grin> This problem is sorta like
that. Slight differences in how you set your system up make this
problem give different results for different computers.
Yes this is confirmed. Here is what I think is going on from days,
weeks, months.... of experimenting and banging my head on the wall.
When you kdesu, kdesudo, etc to root you are not using roots copy of
Kate you are using yours. Sorta like you do when you use fish or sftp
to access a remote computer using xwindows. That means you don't
"really" have roots complete environment and if the settings are not
exactly right you have all kinds of problems like you mention. You
have the permissions to go anywhere and open and write to all files
but there are a lot of other "settings" you don't receive the benefits
of, like you would as a real root user. I noticed that it seemed like
half the configurations were stored in roots config files and half in
mine. Kate wasn't bad but Konqueror was a pain to try to use like
that.
I think the DCOP issue is a case where the DCOP server is seeing some
of the signals or request from the root xserver and when it queries
Klauncher it goes to root instead of your server--and roots Klauncher
is not installed. In fact as little of the Xwindows and KDE software
as possible is installed in roots xwindow system.
The Root Whackers "had" to leave a place for root to exist--since
Linux was basically built around the concept--but they did strip as
many of the root environment variables as they could (including all
KDE and DBus settings) and yet still have Linux run. For example both
KDEHOME AND KDEDIR are not in roots environmental variables. This has
caused some problems and caused issues like you had. I think that
they will sooner or later break Linux by all the contortions they go
through in the code to prevent users from playing with their root. I
hope I'm around to laugh at them. <grin>
I decided to find a way to run root's version of Kate, Konqueror and
kcontrol so I could have control of their environment and
configuration files. I did it and it works real well for the regular
work you need to do as root. There are still at few weird things here
and there that I have not fixed like not being able to run the
"Configure Konqueror" application "consistently" without actually
logging in as root in a real xwindow session. Sometimes it works
sometimes it doesn't. But I am working on it
It's nice to finally have my Root applications (run from my xwindow
session) that have their own colors, title bar, icons, etc.--which
helps keep me from thinking I am in one of my local
applications--which usually are also open at the same time. Like you,
I'm sure. Also it makes it easier to drop to root on my system then
ssh to one of my other computers and run the other computer's root
version of a Xwindow application.
I also finally figured out how to run an xwindow session as root and
that really helped to figure out how to make the local su to root apps
work correctly.
If you are not against working with the full power of root, (Though
not logged in to xwindows as root) I will tell you what I did to solve
the problem.
The basic idea is that you have to create a root password, fix and
export a bunch of environmental variables that were left out, install
some missing software, fix some permission issues and finally give
yourself permission to use everyone else's xwindow server on that
computer (su to root doesn't give you that).
After that there are various ways to run the root programs. I prefer
su. The icons I use run local scripts that let me setup a lot more
options than Klanucher would.
Here is the su part of my kate script.
su -l -c '/opt/kde3/bin/kate --caption ROOT' root
This starts up Kate a LOT faster than using "kdesu kate" from an icon.
The only draw back is that I have an extra terminal window open as
well as Kate.
Hope this helps.
Keith