Why do we still support Rosegarden?
Reasons not to support it.
1. It is not a kde project. Right now, Rosegarden is an independent project.
2. The current Rosegarden does not depend on KDE4, instead it depends
on Qt4 and other libraries (not unreasonable)
3. It has a large codebase that is aging, and is a highly specific
application, used for music creators, who will be using the latest
versions of it (for integration with things like jack and dbus), not
the ancient kde3 version.
4. we don't know anything about how it works code wise, sure we can
fix some problems here and there, but we obviously will not be
developing it.
Reasons to support it.
1. someone somewhere somehow may be philosophically against using Qt4.
Calvin
Tim, Slavek,
Attached is a patch that fixes a gcc47 issues with rosegarden CMakeLists.txt.
It just adds libfontconfig to the target libraries for rosegardenextended. The
error is:
[ 95%] Building CXX object RGbuild/CMakeFiles/rosegarden.dir/gui/application/main.o
Linking CXX executable rosegarden
/usr/bin/ld: /opt/qt3/lib/libqt-mt.so: undefined reference to symbol
'FcPatternAddInteger'
/usr/bin/ld: note: 'FcPatternAddInteger' is defined in DSO
/usr/lib/libfontconfig.so.1 so try adding it to the linker command line
/usr/lib/libfontconfig.so.1: could not read symbols: Invalid operation
The patch is attached. (signoff and push if OK)
--
David C. Rankin, J.D.,P.E.
All,
Aside from the obvious (no tde-config), what is being checked for that causes
this type of initial build failure. I am seeing it in several applications
(abakus, amarok, etc..). This is with the 3.5.13-sru branch files. Obviously
tde-config is present as tdelibs, tdebase, etc.. have built without issue. So
anybody familiar with some check that will need to be adjusted to fix these?
I'll dig into them, but if you have and idea -- let me know :)
--
David C. Rankin, J.D.,P.E.
Slavek,
As I work with code from master to build with v3.5.13-sru, if I find
solutions, I'll pass them along to you. The first couple I've done are
applications/abakus and kgtk-qt3. Simple changes. Here are the recipes:
pkgname=tde-abakus
## Port TDE 14.0.0 GIT -> v3.5.13-sru (name change of tde -> kde)
sed -i 's/tde-config/kde-config/g' ${pkgname#*-}/admin/acinclude.m4.in
sed -i 's/tde-config/kde-config/g' ${pkgname#*-}/admin/cvs.sh
sed -i 's/tde-config/kde-config/g' ${pkgname#*-}/cmake/modules/FindTDE.cmake
sed -i 's/tdelibs.cmake/kdelibs.cmake/' ${pkgname#*-}/cmake/modules/FindTDE.cmake
sed -i 's/tde\([a-z]\)/kde\1/g' ${pkgname#*-}/src/CMakeLists.txt
pkgname=tde-kgtk-qt3
## Port TDE 14.0.0 GIT -> v3.5.13-sru (name change of tde -> kde)
sed -i 's/tde-config/kde-config/g' ${pkgname#*-}/admin/acinclude.m4.in
sed -i 's/tde-config/kde-config/g' ${pkgname#*-}/admin/cvs.sh
sed -i 's/tde-config/kde-config/g' ${pkgname#*-}/cmake/modules/FindTDE.cmake
sed -i 's/tdelibs.cmake/kdelibs.cmake/' ${pkgname#*-}/cmake/modules/FindTDE.cmake
I run them from my build script against the current R14 code to build with
v3.5.13-sru. I guess we could apply them and create a patch, but is seems easy
enough to just do it at build time for those modules that just have simple changes.
--
David C. Rankin, J.D.,P.E.
Hello,
As a Mageia 2 user, I found annoying not to have any usable TDE version.
So, I built myself some TDE packages for Mageia 2.
These are based on the Redhat packages, which were slightly updated to
work on Mageia.
For end-user, it means that TDE is already very usable, since it has all
updates that Fedora/RHEL already has.
For maintainer (me, I guess), it's now possible to build TDE for all
RHEL/Fedora/Mageia distributions with an unique procedure.
I guess that adding support for Mandriva 2011 will be easy too, since
these distributions are very close.
For now, I've built tdebase only.
To install it on Mageia 2 (x86_64 only, no i386):
First, add the repositories:
urpmi.addmedia tde-3.5.13-x86_64
http://trinity.mangafrance.com/mga2/trinity-3.5.13/RPMS/x86_64/
urpmi.addmedia tde-3.5.13-noarch
http://trinity.mangafrance.com/mga2/trinity-3.5.13/RPMS/noarch/
urpmi.addmedia tde-extras-x86_64
http://trinity.mangafrance.com/mga2/trinity-extras/RPMS/x86_64/
Then, install the tdebase package:
urpmi trinity-tdebase
And there you go. You should be able to choose a new "TDE" se
ssssion in your favorite DM (GDM, KDM, or anything else).
Francois
Slavek, Darrell,
I am having fits with a handful of packages in 3.5.13 with the configure error:
configure: error: Qt (>= Qt 3.3 and < 4.0) (library tqt-mt) not found
Of course it isn't found, the file is qt-mt (/opt/qt3/lib/libqt-mt.so). The
configure.log discloses the actual error:
configure: 22827: /opt/qt3/include/qstyle.h
taking that
configure:23062: rm -rf SunWS_cache; g++ -o conftest -Wno-long-long -Wundef
-ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W
-Wpointer-arith -fno-builtin -g3 -fno-inline -march=i686 -mtune=generic -O2
-pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2
-Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -I/opt/qt3/include
-I. -DQT_THREAD_SUPPORT -D_REENTRANT
-Wl,-O1,--sort-common,--as-needed,-z,relro -L/opt/qt3/lib conftest.cpp
-ltqt-mt -lpng -lz -lm -ljpeg -ldl -lXext -lX11 -lSM -lICE -lpthread 1>&5
/usr/bin/ld: cannot find -ltqt-mt
The problem is that nowhere in the code that I can find is there anything that
would generate -ltqt-mt instead of -lqt-mt?? Meaning -- All of the pkgconfig
files are correct. The pkgconfig files at issue are:
/opt/qt3/lib/pkgconfig/qt-mt.pc
/usr/lib/pkgconfig/tqt.pc
BOTH CORRECTLY list -lqt-mt and NOT -ltqt-mt...
cat /opt/qt3/lib/pkgconfig/qt-mt.pc
prefix=/opt/qt3
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
qt_config=qt warn_on release incremental link_prl thread nocrosscompiler
dlopen_opengl minimal-config small-config medium-config large-config full-config
styles tools kernel widgets dialogs iconview workspace inputmethod network
canvas table xml opengl sql release dll thread largefile stl system-mng
system-jpeg system-png gif system-zlib nis cups bigcodecs x11sm xshape xinerama
xcursor xrandr xrender xftfreetype xkb inputmethod dylib create_prl link_prl qt
warn_on depend_includepath qmake_cache x11 x11inc create_libtool create_pc moc
x11lib
Name: Qt
Description: Libqt-mt.so.3.3.8 Library
Version: 3.3.8
Libs: -L${libdir} -lqt-mt -L/usr/lib/mysql -L/usr/X11R6/lib -lpq -lmysqlclient
-lz -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig -lXext
-lX11 -lm -lSM -lICE -ldl -lpthread
Cflags: -DQT_SHARED -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -D_REENTRANT -I${includedir}
cat /usr/lib/pkgconfig/tqt.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include/tqt
tmoc_executable=/usr/bin/tmoc
moc_executable=/opt/qt3/bin/moc
uic_executable=/opt/qt3/bin/uic
Name: TQt
Description: Interface and abstraction library for Qt and Trinity
Version: 3.5.13
Libs: -L${libdir} -ltqt -L/opt/qt3/lib -lqt-mt
Cflags: -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -I/opt/qt3/include
-I${includedir} -include tqt.h
So my question is "How in the heck can the build generate a config that looks
for -ltqt-mt when the only thing the pkgconfig files point to is -lqt-mt?"
--
David C. Rankin, J.D.,P.E.
Hi all,
While building TQt3 today, I noticed that I was receiving numerous
errors that said that an object was not declared in scope.
The log file: http://pastie.org/4350270
Does anyone have any idea? Patches I use don't seem to point to any
such solution at the moment (including qt-transparency.patch).
--
later daze. :: Robert Xu :: protocol.by/rxu
Hi,
I built tqt3->tdebase on a Debian Unstable box (GCC-4.7.1, cmake-2.8.9~rc1)
and the only show stopper was bug #1116 (kconfig_compiler should be
renamed)--and that only cropped up because I have KDE-4 dev packages
installed. I then started looking at the build logs for tqt3 and came across
a few simple to fix packaging issues...
$ diff -ru tde/tde-packaging/debian/squeeze/dependencies/tqt3/debian
tde/build/main/dependencies/tqt3/debian
Only in tde/tde-packaging/debian/squeeze/dependencies/tqt3/debian/patches:
09_amd64_lib64.diff
diff -ru
tde/tde-packaging/debian/squeeze/dependencies/tqt3/debian/patches/series
tde/build/main/dependencies/tqt3/debian/patches/series
--- tde/tde-packaging/debian/squeeze/dependencies/tqt3/debian/patches/series
2012-07-13 00:27:09.000000000 -0600
+++ tde/build/main/dependencies/tqt3/debian/patches/series 2012-07-20
15:25:19.000000000 -0600
@@ -1,4 +1,3 @@
06_disable_rpath.diff
-09_amd64_lib64.diff
72_dont_trust_uname-m_use_dpkg-arch_instead.diff
kubuntu_06_fglrx_0_size_screen.diff
... 09_amd64_lib64.diff patches to use obsolete /usr/X11R6 dirs ...
diff -ru tde/tde-packaging/debian/squeeze/dependencies/tqt3/debian/rules
tde/build/main/dependencies/tqt3/debian/rules
--- tde/tde-packaging/debian/squeeze/dependencies/tqt3/debian/rules
2012-07-13 00:27:09.000000000 -0600
+++ tde/build/main/dependencies/tqt3/debian/rules 2012-07-23
19:08:09.000000000 -0600
@@ -25,7 +25,11 @@
ifeq ($(DEB_HOST_ARCH),sparc)
PLATFORM_ARG = linux-g++-sparc
else #sparc
+ifeq ($(DEB_HOST_ARCH),amd64)
+ PLATFORM_ARG = linux-g++-64
+else #amd64
PLATFORM_ARG = linux-g++
+endif #amd64
endif #sparc
endif #hurd
... the platform wasn't being set properly, mkspecs/linux-g++ was being used
instead of the expected mkspecs/linux-g++-64. This patches over the problem
but (AFAICT) shouldn't be necessary (i.e., something deeper needs fixing)...
@@ -230,8 +234,6 @@
# copy all docs there first
install -d $(P_DOC)/usr/share/tqt3/doc/html/
for a in `cd $(TMP_INSTALL)/usr/share/tqt3/doc/html/ && find`; do cp
$(TMP_INSTALL)/usr/share/tqt3/doc/html/"$$a"
$(P_DOC)/usr/share/tqt3/doc/html/; done
- #typo bugfix
- sed -i -e 's/reveives/receives/'
$(P_DOC)/usr/share/tqt3/doc/html/ntqwidget.html
## build designer package documentation
# tqt3-designer
... fixing a typo via sed in the packaging is ugly, best to fix the typo in
the source itself and be done with it for everyone, eh.
Generally, it looks like the Debian packaging of everything required to get
tdebase up and running needs more updating than is reasonable to do via
tweaking what exists if the packages are to conform to current Debian Policy
and best practice--it may be best to backport the packaging currently being
used by Debian into Trinity where possible.
While looking through the build.log for tqt3 I kept getting distracted by the
piles of "suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]"
warnings--so I went through the source and added in all the missing
parentheses g++ was complaining about (plus fixed a few more warnings where
the fix was just as obvious). The build log is much easier to read now, and
potentially problematic warnings (such as [-Wdelete-non-virtual-dtor][1]) are
no longer buried among the noise.
What is the best way for me to get the tqt3 source changes to you?
- Bruce
[1] -Wdelete-non-virtual-dtor comes in two flavours, one which may result in a
memory leak and another which will result in undefined behaviour.