Tim, Serghei, Baho, All;
Here is a quick snapshot of the packages built and those with problems on
Arch since I got time to dive back into building. So far most all of the
packages that were building before the gcc46 update and reworked Qt3 are still
building with minimal tweaks to the PKGBUILD scripts. This is true for both i686
and x86_64. I did apply the gcc46.diff from suse to Qt3.
I haven't had time to fully test everything, but so far everything seems to
be running fantastically. The packages that I have rebuilt are:
19:01 supersff:~/tblds> pmq | grep trinity
trinity-app-d3lphin 1229360-1
trinity-arts 1228449-1
trinity-dbus-1-qt3 0.9-7.2
trinity-kdebase 1228451-1
trinity-kdegraphics 1229555-1
trinity-kdelibs 1228610-1
trinity-kdepim 1228885-1
trinity-pyqt3 3.18.1-9
trinity-qt3 3.3.8c-1
trinity-tqtinterface 1228485-1
The packages where I still experience build failures are:
trinity-kdevelop
trinity-kdewebdev
trinity-app-amarok
trinity-app-knetworkmanager
trinity-app-kpowersave
I will look into the build failures a bit closer and follow up. Baho has
kdevelop building, so I will compare notes there.
Let me know which of the problem packages above should build (no known CMake
issues) and which ones are still being updated. That way I don't drive myself
nuts trying to build a package that won't build to begin with.
Also, are there any new packages available to build (finished CMake files)
that I should be working on that have been completed in the past 30 days? If so,
let me know or drop me a link and I'll see if I can make progress. Thanks.
--
David C. Rankin, J.D.,P.E.
Hello,
When I compile tqtinterface under Slackware64 13.37 (KDE4 is installed,
no Qt3) with Qt4 support, it produces a wrong tqt.pc:
==========
$ cmake ../dependencies/tqtinterface/
-DCMAKE_INSTALL_PREFIX=/opt/trinity -DCMAKE_VERBOSE_MAKEFILE=ON
-DUSE_QT4=ON -DQTDIR=/opt/qt -DQT_LIBRARY_DIRS=/opt/qt/lib
-DBUILD_ALL=ON -DLIB_SUFFIX=64
==========
followed by make -j5 and standard installation (via Slackware packages)
produces the following /usr/lib64/pkgconfig/tqt.pc:
==========
prefix=/opt/trinity
exec_prefix=${prefix}
libdir=${prefix}/lib64
includedir=${prefix}/include/tqt
tmoc_executable=/opt/trinity/bin/tmoc
moc_executable=/usr/bin/moc
uic_executable=
Name: TQt
Description: Interface and abstraction library for Qt and Trinity
Version: 3.5.13
Libs: -L${libdir} -ltqt -L/usr/lib64 -lQtCore -lQtGui
Cflags: -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL
-DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT
-I/usr/include/qt4 -I${includedir} -include tqt.h
===========
The uic_executable is not defined, causing arts failing to build.
===========
$ which uic
/usr/bin/uic
===========
shows that uic is really installed on my system.
Tim,
I apologize for the delays, life seems to have caught up with me recently. This week and the following are finals for the semester so I am under a great stress and large workload. I also have not been able to successfully install Trinity either on Arch Linux. Baho and David haven't grasped the concept of portability so I don't have it working.
Again Sorry,
Calvin Morrison.
Timothy Pearson <kb9vqf(a)pearsoncomputing.net> wrote:
>Hi Serghei, Calvin,
>
>Can you two please update me on the CMake status of kdegraphics? I would
>like to keep things moving if possible; I know Calvin has on the Etherpad
>that he is waiting for some kind of macro from Serghei; if this could be
>coordinated and fixed I would appreciate it.
>
>Once kdegraphics is complete I will initate TQt4 conversion and autobuilds
>on this end.
>
>Thanks!
>
>Tim
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
>For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net
>Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/
>Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
>
Tim, Serghei, Robert:
What is the latest on restoring sftp://host:port/path/to/file/ capability
in TDE? It broke in KDE3 some time ago. Particularly where 'port' is a
non-standard port. In Trinity you still get the error:
Error encountered while talking to ssh
My understanding is there was a complete re-write of the code that handles
this taking place -- any word on how that is coming? fish:// continues to work
in Trinity, but sftp should be working before the 3.5.13 release.
What say the folks in the know?
--
David C. Rankin, J.D.,P.E.
What is the best way to troubleshoot run-time crashes?
Do the packages have to be built a certain way?
I've read about backtraces, core dumps, and using gdb. I'm no programmer, so what is the best way for me to troublesoot?
In particular, I am running KDE 3.5.10, recompiled for Slackware 13.1. KMail always now crashes whenever I try to do anything with the composer window (save as draft, send, etc.). Boom. Just disappears. Almost as if I had started KMail with the --compose option. The app disappears and I have to restart KMail. The funny thing is the message gets stored in the Outbox.
I want to troubleshoot in case this bug carries over to Trinity.
Thanks.
Darrell
Tim, Serghei, All:
I ran into an earlier build error with amarok that indicated a '-fpermissive'
problem, so I added the flags Baho had set in other files that let amarok build
further until I hit the undefined reference to `Amarok::aboutData' error.
Why the new need for:
CFLAGS=${CFLAGS}" -fpermissive"
CXXFLAGS=${CXXFLAGS}" -fpermissive"
in the build?
--
David C. Rankin, J.D.,P.E.
Guys,
There were 2 files installed owned by root:root in user ~/.kde3/share/config:
-rw------- 1 root root 221 Mar 5 09:34 kcmshellrc
-rw------- 1 root root 147 Mar 5 09:34 kfontinstuirc
The remaining files were all owned by the normal user. Does this need to be
fixed in svn? I can't think of any reason packaging would have caused this issue.
Also, kcontrol does not launch from the "kmenu -> Settings -> Control Center"
entry any more. Launching from the command line with 'kcontrol' works fine. This
is on x86_64. I haven't tried on i686 yet.
--
David C. Rankin, J.D.,P.E.