tde-devels

devels@trinitydesktop.org

3 participants
3808 discussions

STRACE - kwrite crash i686
by David C. Rankin 30 Apr '12

30 Apr '12

Tim, Darrell, As /dev/ammo42 suggested, I captured a strace on the i686 crash. It is attached to bug 979. (current tdebase and tqt3, tdelibs from 4/16 -- same crash) http://bugs.trinitydesktop.org/attachment.cgi?id=568 Also, this bug occurs 100% of the time when pasting 'small' amounts of text (1-2 words at a time) until the line wraps. I can paste 10 lines of text into kwrite and keep editing - so it looks like something that effects the single line length computation. I'll keep incrementally downgrading and report when I narrow the time the bug was introduced. If anyone can read straces, then take a look. -- David C. Rankin, J.D.,P.E.

2 2

kwrite/kate - why is 3.5.12 not affected (help analyzing)
by David C. Rankin 30 Apr '12

30 Apr '12

Tim, All, As I work to downgrade my R14 test boxes to troubleshoot what caused the kate/kwrite crash, I ran into a question I would like to get your thoughts on. All my day-to-day boxes run fully updated Archlinux (with one openSuSE box), and TDE 3.5.12 as the desktop (3.5.10 on SuSE). QUESTION: If the crash is due to an Arch update -- "They why do kate/kwrite continue to function normally in 3.5.12?" It just strikes me that 3.5.12 would be much more susceptible to break due to Arch updates that R14. Would we not expect to see this same crash in 3.5.12 if this was due to an Arch update? What say the experts? If this was Arch, wouldn't 3.5.12 have broken too? -- David C. Rankin, J.D.,P.E.

4 19

kcmshell keys
by Jay 29 Apr '12

29 Apr '12

Tmenu/settings/regional & accessibility/keyboard shortcuts gives a segfault SIGSEGV. Running *kcmshell keys* opens the panel successfully. Can someone else confirm this? Jay

5 18

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

28 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 28 Apr '12

28 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 27 Apr '12

27 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 27 Apr '12

27 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels