tde-devels

devels@trinitydesktop.org

9 participants
3790 discussions

Warning: patch updates
by Darrell Anderson 06 Feb '14

06 Feb '14

All, For several days I have been working on several items with the help handbook system. I've been thorough and have been testing intensely with the hope of avoiding new bugs after the patches are pushed to git. Much of the work revolves around fixing tdeioslaves and protocol handbooks, but there are other patches such as fixing missing icons, fixing DocPath keys, updated handbooks, etc. The patches include tde-i18n fixes to match as much as possible the changes made in the parent packages. I ran a final full build set last night with all of the upcoming patches, including tde-i18n. There were no build failures and my usage tests today went as expected. As the patch set includes the tdelibs module, which include entity changes, your best approach is to run a full build set. Any time we update the entities in tdelibs that means help handbooks using the previous entities will fail to build. After many rounds of package rebuilding and usability testing I'm not expecting problems, but as always I'm only one person and don't conceive of or anticipate all use cases. Please report potentially related bugs to the list and I'll look into them. Please don't report bugs unless you performed a full package set rebuild because that will be my first reply. :) I plan to soon start pushing those patches. I plan to run another full build set tonight after I finish pushing all patches to ensure no new problems. Darrell

1 0

Re: [trinity-devel] python-tqt FTBFS - ImportError: No module named sip4_tqt
by Darrell Anderson 06 Feb '14

06 Feb '14

>> I've read through it until I'm blue in the face and I can't >figure out what it >> means to my build script. How are you building it? Obviously my >build for >> python-sip and python2-sip build but are now completely broken. >I'm building with: >> >> CFLAGS="${CFLAGS} -I/usr/include/tqt -I${TDEDIR}/include - >I${QTDIR}/include" Grab a copy of my build scripts. There are some nominal changes in the sip4-tqt and python-tqt scripts. Notice the changes in the configuration section. Rebuild both packages. Darrell

2 1

tdeutils FTBFS (cmake) - error: 'PyString_CheckExact' was not declared in this scope
by David C. Rankin 05 Feb '14

05 Feb '14

Darrell, Slavek, With a complete build (tqt3 -> tdeutils), tdeutils fails at 96% with the following: [ 96%] Building CXX object superkaramba/src/CMakeFiles/superkaramba.dir/meter_python.cpp.o cd /build/tde-tdeutils/src/build/superkaramba/src && /usr/bin/c++ -DHAVE_CONFIG_H -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/opt/tqt3/include -I/usr/include/tqt -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/build/tde-tdeutils/src/build -I/build/tde-tdeutils/src/build/superkaramba/src -I/build/tde-tdeutils/src/tdeutils/superkaramba/src -I/usr/include/python3.3m -I/opt/trinity/include -I/opt/tqt3/include -I/usr/include/tqt -o CMakeFiles/superkaramba.dir/meter_python.cpp.o -c /build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp In file included from /build/tde-tdeutils/src/tdeutils/superkaramba/src/karamba.h:73:0, from /build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:17: /build/tde-tdeutils/src/tdeutils/superkaramba/src/imagelabel.h:41:14: warning: declaration 'class TDEIO::CopyJob' does not declare anything [enabled by default] class TDEIO::CopyJob; ^ /build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp: In function 'TQString PyString2TQString(PyObject*)': /build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:96:33: error: 'PyString_CheckExact' was not declared in this scope if (PyString_CheckExact(text)) ^ /build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:98:41: error: 'PyString_AsString' was not declared in this scope char* t = PyString_AsString(text); ^ /build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp: In function 'PyObject* TQString2PyString(TQString)': /build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:151:38: error: 'PyString_FromString' was not declared in this scope pyString = PyString_FromString(""); ^ superkaramba/src/CMakeFiles/superkaramba.dir/build.make:973: recipe for target 'superkaramba/src/CMakeFiles/superkaramba.dir/meter_python.cpp.o' failed make[2]: *** [superkaramba/src/CMakeFiles/superkaramba.dir/meter_python.cpp.o] Error 1 make[2]: Leaving directory '/build/tde-tdeutils/src/build' CMakeFiles/Makefile2:5060: recipe for target 'superkaramba/src/CMakeFiles/superkaramba.dir/all' failed make[1]: *** [superkaramba/src/CMakeFiles/superkaramba.dir/all] Error 2 make[1]: Leaving directory '/build/tde-tdeutils/src/build' Makefile:119: recipe for target 'all' failed How to solve? -- David C. Rankin, J.D.,P.E.

1 0

Screen captures for i18n packages
by Darrell Anderson 05 Feb '14

05 Feb '14

All, As we continue to update the help handbooks, a significant challenge is updating not only the text but the screen captures. I would like to automate part of this process as much as possible. The basic screen capture process: * Save a new screen capture in English. * Note the image size properties. * Toggle to a different language. * Verify the respective tde-i18n module is using that same image. (Not all i18n modules support everything.) * Save a new screen capture in the respective language with the same image size properties. * Repeat through all i18n languages. I'm thinking we need a way to update all i18n po file references to the original source file and code lines, as well as update the po file English reference to what is now actually in the source code. We've made many changes the past few years and the po file English references are not current. Many code line references are incorrect. We lack the project size needed to keep all of the i18n files updated, but at least we can update the English references and source code lines as well as the screen captures. I am asking that you let this challenge fester for a while in your subconcious and hopefully a solution emerges. These are not R14.0.0 priorities, but as Slavek mentioned previously, probably marked for R14.0.2. As always, thank you. :) Darrell

1 0

Re: [trinity-devel] Default video player (Formerly UUGH! Desktop Icons open in DOLPHIN -- really?)
by Darrell Anderson 05 Feb '14

05 Feb '14

>maybe tmplayer? I don't think the name matters all that much. >there >already exists smplayer, gnome-mplayer, kplayer and kmplayer >according >to my debian package list. I meant a name change consistent with our previous name changes. Not a priority. Darrell

1 0

Re: [trinity-devel] Default video player (Formerly UUGH! Desktop Icons open in DOLPHIN -- really?)
by Darrell Anderson 05 Feb '14

05 Feb '14

>I think that, in the end, we have three options: > >1. Get kaboodle up to snuff. Yes, improving kaboodle to support all modern formats is a huge bite. Short term we only need to debug and patch why kaboodle is failing with even the older formats. That provides us some temproary breathing room. >2. Move kmplayer into tde-multimedia. If we do this then we might consider pulling kaboodle from the sources and abandon kaboodle. I'm not against the idea of pulling kmplayer into tdemultimedia, but another option is we promote kmplayer as part of the base package set. If we start promoting kmplayer, I'm in favor of a name change. >3. Move kaffeine into tde-multimedia. Same as kmplayer: we promote kaffeine as part of the standard package set. Darrell

2 1

Re: [trinity-devel] Commit 83f044c5 [tdebase]
by Darrell Anderson 05 Feb '14

05 Feb '14

>No, leave the patch in place - I'll make an update. >I hope soon :) Okay. I believe the path I used in the patch is the normal installation location as intended from upstream. Therefore other distro maintainers who use a different path are changing that location. Darrell

2 2

Re: [trinity-devel] Default video player (Formerly UUGH! Desktop Icons open in DOLPHIN -- really?)
by Greg Madden 05 Feb '14

05 Feb '14

On Tuesday 04 February 2014 16:08:45 you wrote: > >7) all distros support mplayer in one form or another > > I suppose this is a packager problem, but the original idea of a > default player is no external dependencies. > > MPlayer is well supported but is not part of a stock installation > on all distros. Other dependency presumptions exist in Trinity (for > example, xine for amarok), yet nominating kmplayer as a default > video player and moving into tdemultimedia means MPlayer needs to > be installed. > > Audio players are not the same challenge. We have kaboodle, noatun, > and juk, all installed by the base package tdemultimedia. > > Fixing kaboodle gets us half way home. The other half is update > kaboodle to support newer generations of avi/mpg and like or not, > probably should support flv. For a default player that will > suffice. People who want extensive video format coverage are going > to install something else anyway. > > For Trinity users those additional apps will be kaffiene and > kmplayer for video and amarok for audio. Not a problem for those > types of users. We are discussing a basic default video player for > the first-time out-of-the-box Trinity experience. > > Darrell Never could get kaboodle & kmplayer to 'just work' for random streaming media, checking the 'depends' for those two comes up with a signifcantly shorter list of codecs et al installed compared to mplayer and (my fav) vlc. this is on a Debian system. Problem with desktop environments, apps that no longer or never did work, not being able to go outside the box and use best of breed apps. TDE has some 'best' apps, mine=gwenview, digikam, k3b, kmail, can using other non-tde apps be considered ? Is this what the gtk-qt widget stuff is for? -- Peace, Greg

4 3

Re: [trinity-devel] tdeutils - installing irkick.png icons off / directory?
by Darrell Anderson 05 Feb '14

05 Feb '14

> Please confirm. Something in tdeutils 'make install' paths are >broken and it >is installing /hicolor/16x16/apps/irkick.png at that absolute path >as well as >the /locolor/16x16/apps/irkick.png. The same is true for the 22x22 >and 32x32 >icons for the same: > >/hicolor/16x16/apps/irkick.png >/hicolor/22x22/apps/irkick.png >/hicolor/32x32/apps/irkick.png >/locolor/16x16/apps/irkick.png >/locolor/32x32/apps/irkick.png > > > I'm building tdeutils without any strange patches: > > cd ${srcdir}/${pkgname#*-} > > # copy system libtool and ltmain scripts > cp /usr/share/aclocal/libtool.m4 ./admin/libtool.m4.in > cp /usr/share/libtool/config/ltmain.sh ./admin > > ## Generate config files and update with autoreconf > cd ${srcdir}/${pkgname#*-} > make -f admin/Makefile.common > > ## configure > ./configure \ > --prefix=${TDEDIR} \ > --with-qt-dir=${QTDIR} \ > --sysconfdir=${TDEDIR}/etc \ > --localstatedir=/var \ > --enable-debug=full \ > --enable-closure > > ## make $NUMJOBS > make $NUMJOBS > > cd ${srcdir}/${pkgname#*-} > make -j1 DESTDIR="$pkgdir" install > >What got broke and where? Something in the tdeutils (whereever the irkick.png icons are installed from) is not seeing your prefix configuration. BTW, I am using cmake for tdeutils. rm CMakeCache.txt 2>/dev/null mkdir -p ${TMP}/${PRGNAM}.build cd ${TMP}/${PRGNAM}.build cmake $SOURCES_ROOT \ -DCMAKE_C_FLAGS:STRING="$CPUOPT" \ -DCMAKE_CXX_FLAGS:STRING="$CPUOPT $DEBUG_CMAKE_OPT" \ -DCMAKE_INSTALL_PREFIX=${PREFIX} \ -DSYSCONF_INSTALL_DIR=${SYSCONFDIR} \ -DLIB_SUFFIX=${LIBDIRSUFFIX} \ -DMAN_INSTALL_DIR=${MANDIR} \ -DWITH_DPMS=ON \ -DWITH_XSCREENSAVER=ON \ -DWITH_SNMP=ON \ -DWITH_SENSORS=ON \ -DWITH_XMMS=ON \ -DWITH_KNEWSTUFF=ON \ -DWITH_ASUS=ON \ -DWITH_VAIO=ON \ -DWITH_THINKPAD=ON \ -DWITH_I8K=ON \ -DWITH_POWERBOOK=OFF \ -DWITH_POWERBOOK2=OFF \ -DBUILD_ALL=ON || exit 1 Darrell

3 3

Re: [trinity-devel] R14 RC1 ready?
by Darrell Anderson 05 Feb '14

05 Feb '14

>I would like to tag the current sources and binaries R14.0.0 RC1, >as it >appears that we have finally cleared the Blocker and Critical >reports from >the R14 Etherpad. > >Are we ready for this or are there any objections? The etherpad hasn't received updates in a while. We need some hacking. Blocker: ======== http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd =Blocker Critical: ========= http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd =Critical Michele is working on 1825, but could use help. That is an ugly bug from a public relations perspective. The comments provide a lot of details. 1853 needs attention. 1821 hasn't been touched. 1813 can be closed after the last comment is implemented. Regressions: ============ 1825 is bad (already mentioned in Critical). The others should receive attention but probably could survive the R14.0.0 cut. Patches Available: ================== Lots of patches sitting out there that have not been reviewed. Likely many could be pushed. Other: ====== * The new web site should be tested before moving toward a release date. * There is a laundry list of items in the R14 checklist etherpad that need attention. Darrell

6 15

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels