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.
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
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
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
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
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
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
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
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
