tde-devels April 2012

devels@trinitydesktop.org

25 participants
142 discussions

New kwrite crashes with yesterdays builds of tdelibs/tdebase
by David C. Rankin 29 Apr '12

29 Apr '12

All, After rebuilds of tdelibs/tdebase yesterday evening (with fresh GIT update), I have experienced repeated crashes with kwrite becoming unresponsive. The kwrite window stays open, but no response from the menu, toolbar or context menu and the screen within the kwrite window does not repaint itself. (leading to a million copies of anything you move across it). Here are a couple of screenshots of the behavior after the crash (we've all seen it before...) http://nirvana.3111skyline.com/dl/dt/trinity/ss/kwrite-crash-select-buffer.… http://nirvana.3111skyline.com/dl/dt/trinity/ss/kwrite-crash-backspacing.jpg I repeated the crash twice. It seemed to occur when either inserting text with the select buffer (select, then middle-mouse paste) or when simply backspacing to join two lines of text in kwrite. It was bad enough that after the second crash, I had to give up and just use vim. For the second attempt working with kwrite, I started it from konsole so I could look at the kdDebug output. There was nothing out of the ordinary. These crashes have always been difficult for me to isolate. Can anyone suggest a test that would help identify the problem. Also, any reports confirming this behavior would be helpful. -- David C. Rankin, J.D.,P.E.

5 35

How to support ruby 1.9.x?
by Darrell Anderson 29 Apr '12

29 Apr '12

I have some patches that I apply for my builds when using ruby 1.9.x rather than 1.8.x. Amarok, tdebindings, and koffice, although the latter has additional problems with ruby 1.9.x. I want to push these patches to GIT but I can't change code one-way because the ruby 1.9 patches will cause build failures for those folks still building against ruby 1.8.x. I need to add preprocessor checks in the patches to test the ruby version, similar to what we have been doing for building against libpng 1.4/1.5. Normally there is an APP_MAJOR_VERSION and APP_MINOR_VERSION variable defined in an app header. The ruby people feel the need to be different and don't do this. At least not with the latest versions. There are two basic methods to extract the version: RUBY_MAJOR_VERSION="`ruby --version | awk '{print $2}' | awk -F '.' '{print $1}'`" RUBY_MINOR_VERSION="`ruby --version | awk '{print $2}' | awk -F '.' '{print $2}'`" Or: RUBY_MAJOR_VERSION=ruby -rrbconfig -e "puts Config.expand( Config::MAKEFILE_CONFIG['MAJOR'] )" RUBY_MINOR_VERSION=ruby -rrbconfig -e "puts Config.expand( Config::MAKEFILE_CONFIG['MINOR'] )" How do I get the cpp code to recognize those variables? Can I do this through the configure process? Thanks. Darrell

2 1

Tim: tdegraphics POPPLER_016
by Darrell Anderson 28 Apr '12

28 Apr '12

Tim, What is the significance of checking for version 0.16 of poppler and not earlier versions? Darrell

5 11

kmplayer patch
by Darrell Anderson 28 Apr '12

28 Apr '12

A while ago David posted a build failure with kmplayer: gstplayer.cpp:1009:5: error: C99 designator 'b' outside aggregate initializer I don't know what the error means. David proposed a patch but nobody responded as to whether his patch was legitimate. Yesterday I tried to build kmplayer with gcc 4.7. I saw the same failure. I forgot about David's query. I looked around the web for clues to resolve the problem. I ran into this: http://websvn.kde.org/?view=revision&revision=686006 The patch description is exactly what David and I saw with the build failure. The patch was to the xineplayer.cpp module. Other than the difference between "XINE" and "XVIDEO" I figured the patch is just what the doctor ordered. I massaged the patch for the gstplayer.cpp module and compiled. No failures and the package size is the same as non gcc 4.7 builds. I tested the patch with a non gcc 4.7 build too. I pushed the patch in GIT hash 5106117b. Odd that the "C99 designator" problem was addressed in the xineplayer.cpp module yet the same exact code in gstplayer.cpp was not. The patch does not include fixes for xine-libs. Because there remains a wide mix of xine-libs versions being used, at least for now, the original patch David proposed should have some preprocessor tests like we did with several other patches. That way the patch can be pushed to GIT and work for all versions of xine-libs. I will try to do that. I searched the list archives but could not determine the exact version when the problems start. Which version of xine-libs causes the problems? Darrell

1 2

tdegraphics FTBFS
by Darrell Anderson 28 Apr '12

28 Apr '12

What is the status of the patch in bug report 902? I tried the patch with the latest GIT and gcc 4.7. The build still fails with the same error: collect2: error: ld returned 1 exit status /usr/lib/gcc/i486-slackware-linux/4.7.0/../../../../i486-slackware-linux/bin/ld: CMakeFiles/ksnapshot.dir/windowgrabber.cpp.o: undefined reference to symbol 'XShapeQueryExtension' Darrell

2 6

gcc 4.7 support
by Darrell Anderson 28 Apr '12

28 Apr '12

I am now (finally) building Trinity in a gcc 4.7 environment. So far pretty good news. I can't build tdebindings with xparts and tdegraphics. Otherwise I seem to be moving forward. As I build each package I notice what fails and then head to the bug tracker looking for patches. Bug report 958 is a first start but there are a few other bug reports too. If you have not submitted any related gcc 4.7 patches, please do so. As an attachment here in the list is fine or a bug report. I have tested some of the patches and they work for me as well. Therefore I am going to start pushing those that I test successfully. (Working for two or more people using different distros is a reasonable litmus test.) I mention this here as a friendly warning. :-) That is, if you are building from GIT, please check all resources before posting to the list. That includes doing a git pull to discover whether I pushed a patch. I'm even learning. :-) I just created a tdepim patch that needed a this-> pointer. Thanks to all of you who have created similar patches, from which I learned what to do. I don't grasp the whole "this" pointer concept, but I can patch. :-) Darrell

2 2

kaffeine-mozilla
by Darrell Anderson 26 Apr '12

26 Apr '12

Anybody able to build this plugin? Seems some files are missing, notably the configure script. I can build the package after copying a couple of files from the original sources, but the package does not build correctly: usr/lib/mozilla/plugins/kaffeineplugin.so gets built as usr/lib/mozilla/plugins/kaffeineplugin Darrell

4 8

TDE spring fundraiser status
by Timothy Pearson 26 Apr '12

26 Apr '12

We are currently $145 short of our $2,000 goal, and the fundraiser has only 4 days remaining (termination date April 30, 2012). We're almost there, so keep the donations coming in! Tim

1 0

TDE spring fundraiser status
by Timothy Pearson 26 Apr '12

26 Apr '12

We are currently $145 short of our $2,000 goal, and the fundraiser has only 4 days remaining (termination date April 30, 2012). We're almost there, so keep the donations coming in! Tim

1 0

Slackware Trinity build status
by Darrell Anderson 26 Apr '12

26 Apr '12

Good news overall. I can build Trinity on Slackware 13.1 (gcc 4.4.4) and 13.37 (gcc 4.5.2), both 32-bit and 64-bit. I build everything but a few packages. There are nominal build issues I work around, but I can build full packages for most modules. Exceptions: * tqca, tqca-tls won't build with 64-bit (can't find $PREFIX/lib64) * python-tqt, python-trinity won't build with 64-bit (can't find $PREFIX/lib64) * tdeadmin (won't build knetworkconf) * kstreamripper FTBFS With that foundation I now can start testing against Slackware Current, which is the testing branch for the next official Slackware release. Slackware Current contains gcc 4.7. Darrell

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels April 2012