Slavek,
There are a couple of useful CMake commits that need to be cherrypicked for
3.5.13-sru. The first is in tdebase:
tdebase/kioslave/media/mediamanager/CMakeLists.txt
include_directories(
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/kioslave/media/libmediacommon
${CMAKE_SOURCE_DIR}/kioslave/media/libmediacommon
${CMAKE_BINARY_DIR}
${TDE_INCLUDE_DIR}
${TQT_INCLUDE_DIRS}
${HAL_INCLUDE_DIRS}
+ ${DBUS_TQT_INCLUDE_DIRS}
)
There is a commit that adds ${DBUS_TQT_INCLUDE_DIRS} to the
include_directories list. I'll keep a list in this thread and we can look up the
commit numbers when we are done.
--
David C. Rankin, J.D.,P.E.
All, Slavek,
With only slight changes to the build scripts for Arch, I was able to perform
a fairly successful automated end-to-end build of 3.5.13-sru using the same
build system I use for R14. tdebase required adjusting the config location name
from tdm to kdm and tdebase/kioslave/media/mediamanager/CMakeLists.txt was
patched to include the 'include directories' ${DBUS_TQT_INCLUDE_DIRS}. (there is
already a commit for this that can be cherry-picked to sru. The list of what
build on the 'first-run' is provided below along with the list of what failed.
I'll tweak the failures and provide needed changes, as time permits, under
(enhancement) Bug 1130 - Branch v3.5.13-sru -- Additional commits/fixes.
The packages that built (on the Arch build system with gcc 4.7.1, glibc 2.16,
ffmpeg 0.11-1, libpng 1.5) from the GIT tree with all modules available switched
to v3.5.13-sru were:
tde-arts
tde-basket
tde-dbus-1-tqt
tde-dbus-tqt
tde-digikam
tde-dolphin
tde-filelight
tde-gtk-qt-engine
tde-gwenview
tde-k3b
tde-kaffeine
tde-katapult
tde-kdiff3
tde-kima
tde-kio-locate
tde-kipi-plugins
tde-kmplayer
tde-knemo
tde-knutclient
tde-koffice
tde-konversation
tde-kpowersave
tde-krusader
tde-libart-lgpl
tde-libcaldav
tde-libcarddav
tde-libkdcraw
tde-libkexiv2
tde-libkipi
tde-libksquirrel
tde-mlt++
tde-mlt
tde-qca-tls
tde-qt3-3.8.8.d
tde-sip
tde-sip4-tqt
tde-tde-style-qtcurve
tde-tdeaccessibility
tde-tdeaddons
tde-tdeadmin
tde-tdeartwork
tde-tdebase
tde-tdeedu
tde-tdegames
tde-tdegraphics
tde-tdelibs
tde-tdenetwork
tde-tdepim
tde-tdetoys
tde-tdeutils
tde-tqtinterface
tde-twin-style-crystal
tde-wlassistant
The packages that failed and will need to be checked were:
tdebindings v3.5.13-sru
tdemultimedia v3.5.13-sru
tdevelop v3.5.13-sru
tdewebdev v3.5.13-sru
abakus
amarok v3.5.13-sru
kgtk-qt3
rosegarden v3.5.13-sru
tdesvn v3.5.13-sru
yakuake
soundkonverter
ksplash-engine-moodin
krename
k9copy v3.5.13-sru
kchmviewer v3.5.13-sru
kdirstat
tdmtheme
kbarcode
kbfx v3.5.13-sru (failure expected)
kbookreader
knetstats
knetload
kstreamripper
tdesdk v3.5.13-sru
I'll look through the logs, to find out what went wrong with the v3.5.13-sru
packages. It is likely a build script tweak or quick CMakeList patch is all that
will be required. (those packages with no branch listed above were attempted
from 'master')
--
David C. Rankin, J.D.,P.E.
Tim, Darrell, All,
Quick update. I removed 3.5.12 and replaced it with R 14.0.0 on one of my
boxes. (configured with tmd as the DM) Everything launched fine. (though the
default tdm theme had the ugly XDG login instead of the normal tde gradient one)
All has worked really well.
However, I did hit a bug right off the bat. After configuring panels (menu
checkbox to show settings submenu in kmenu) I tried to launch kcontrol from
kmenu->Settings->Control Center -- Nothing happened. I ended up having to launch
it with Alt+F2 -> kcontrol.
Has this been seen before? If not, I'll file it, but it seems I remember this
supposedly being 'fixed' already. This is from last nights build.
--
David C. Rankin, J.D.,P.E.
All, Slavek,
I like the idea of having 3.5.13 as a primary desktop to work from while R14
settles down. I have created tarballs from 3.5.13-sry, but I have run into
several build problems. Currently I have successfully built:
tde-arts-3.5.13_sru-1-i686.pkg.tar.xz
tde-dbus-1-tqt-3.5.13_sru-1-i686.pkg.tar.xz
tde-dbus-tqt-3.5.13_sru-1-i686.pkg.tar.xz
tde-libart-lgpl-3.5.13_sru-1-i686.pkg.tar.xz
tde-libcaldav-3.5.13_sru-1-i686.pkg.tar.xz
tde-libcarddav-3.5.13_sru-1-i686.pkg.tar.xz
tde-qca-tls-3.5.13_sru-1-i686.pkg.tar.xz
tde-qt3-3.8.8.d_git-1-i686.pkg.tar.xz
tde-sip-3.5.13_sru-1-i686.pkg.tar.xz
tde-sip4-tqt-3.5.13_sru-1-i686.pkg.tar.xz
tde-tqtinterface-3.5.13_sru-1-i686.pkg.tar.xz
The packages I'm struggling with are:
avahi-tqt: The issue is the same as Nix brought up in:
http://comments.gmane.org/gmane.comp.desktop.trinity.devel/6373
The build fails with:
make[2]: Entering directory `/build/src/avahi-tqt/avahi-tqt'
GEN qt-watch.moc3
Qt meta object compiler
moc: Too many input files specified
Usage: moc [options] <header-file>
-o file Write output to file rather than stdout
-f[file] Force #include, optional file name
-p path Path prefix for included file
-i Do not generate an #include statement
-k Do not stop on errors
-nw Do not display warnings
-v Display version of moc
make[2]: *** [qt-watch.moc3] Error 1
The problem is the build cannot find moc-tqt in /usr/bin/moc-tqt. I thought
this was resolved, but I can't recall how. The issue was created by installing
tqtinterface in /usr while the rest of Qt and TDE went in /opt. I'll play with
it. Any ideas, let me know :)
python-tqt:
Build fails due to:
Error: The TQt version number could not be determined by parsing
/opt/qt3/include/qglobal.h.
The problem is caused by configure.py looking for TQt and TQT_VERSION instead
of QT_VERSION even though the configure.py script correctly determined that
/opt/qt3/include/qglobal.h was the correct file. I will try patching this, but
shouldn't configure.py be smart enough to know to look for Qt/QT_VERSION when
the include is /opt/qt3/include/qglobal.h?
--
David C. Rankin, J.D.,P.E.
We don't have a mechanism to update existing Trinity profiles when updating to R14.
For the most part Trinity 3.5.11->3.5.13 profiles essentially are KDE3 profiles. Although the r14-xdg-update script will run automatically for users the first time they run the R14 starttde script, some profile breakage is likely to remain with older config files because the r14-xdg-update script is limited in scope to XDG changes.
I suspect more than a few Trinity users are using 3.5.12 and we should ensure their R14 updating experience "just works."
1. How should we detect older profiles? Possibly by looking for the existence of $TDEHOME/share/config twin_update, twinrc, or tdeprintrc? Any other reliable methods?
2. How should we help users update their profiles? Doing so transparently often is best. Possibly the migratekde3 script can accommodate post 3.5.10 profiles although originally I never considered anything other than 3.5.10.
Do any users have experience migrating existing profiles from 3.5.x to R14? What were those experiences like?
Ideas? Thoughts?
Darrell
Slavek,
I know there isn't a 3.5.13-sru branch for tqca-tls. I'll look at creating
a patch. Currently there is an error where it is looking for libtqt-mt.so.3
instead of libqt-mt.so.3
When there is NO 3.5.13-sru branch for a module (like tqca-tls), does this
mean you are still using the 3.5.13 tarball for the module and not the current
GIT tree?
For those that know cmake, what would I have to change to fix this? Can it
be done as a conditional to look for either Qt3 or TQt3 libs like we were
doing in the Jan.-Feb. timeframe when TDE could still build on QT3?? The error is:
==> Starting configure...
Configuring qca-tls ...
Verifying TQt 3.x Multithreaded (MT) build environment ... fail
There was an error compiling 'conf'. Be sure you have a proper
TQt 3.x Multithreaded (MT) build environment set up.
One possible reason is that you don't have
libtqt-mt.so.3 installed in /opt/qt3/lib/
or /opt/qt3/lib64/.
==> ERROR: A failure occurred in build().
Aborting...
--
David C. Rankin, J.D.,P.E.
All,
When checking the screenshots before posting, I'm normally in firefox.
However, I was testing konqueror. When I go to e.g.:
http://www.3111skyline.com/dl/bugs/Archlinux/gtk-gimp28.jpg
I cannot view the image in konqueror, but instead I'm faced with this
dialog:
http://www.3111skyline.com/dl/dt/trinity/ss/konqueror-jpg.jpg
What is preventing konqueror from viewing the jpg? I can rt-click and
choose to view in e.g. kview, but in the web browser, I should be able
to just open the image in the browser. Anybody else see this? How to fix?
All,
In R14, when you right-click an image and choose External Tools, any
association you make (i.e. gimp) does not get added to the list and is
not preserved between gwenview sessions. In the change from gimp 2.6 to
2.8, the executable changed names so I need to update the 'External
Tools' reference. If I go though the process of rt-click, External Tools
-> Other... and choose the new gimp from the menu, "[x] Remember
application association for this type of file", then the image is
launched in gimp, but when I rt-click the next image, there is nothing
in the External Tools for the new gimp. It goes through the normal
"Updating System..." dialog as normal, so I would expect to see the new
association in qwenview. (maybe not)
This problem seems limited to gwenview as I have updated other file
types in the file manager and I believe that worked.
I can use External Tools -> Configure External Tools and create/edit
the associations. So that part works. It's just strange that there seems
to be a disconnect with this setting in qwenview. Anybody else try this?
