tde-devels April 2011

devels@trinitydesktop.org

14 participants
47 discussions

by Baho Utot

/trinity.source/amarok/amarok/src/threadmanager.h:401:8: warning: extra tokens at end of #endif directive Building CXX object amarok/src/CMakeFiles/amarok-shared.dir/playlistloader.cpp.o In file included from /trinity.source/amarok/amarok/src/collectiondb.h:17:0, from /trinity.source/amarok/amarok/src/playlistloader.cpp:18: /trinity.source/amarok/amarok/src/threadmanager.h:401:8: warning: extra tokens at end of #endif directive line number 401 should be I think #endif // Q_MOC_RUN /trinity.source/amarok/amarok/src/playlistitem.cpp: In member function 'virtual void PlaylistItem::paintCell(QPainter*, const QColorGroup&, int, int, int)': /trinity.source/amarok/amarok/src/playlistitem.cpp:616:83: error: 'TQ_ScaleMax' was not declared in this scope /trinity.source/amarok/amarok/src/playlistitem.cpp:628:84: error: 'TQ_ScaleMax' was not declared in this scope make[2]: *** [amarok/src/CMakeFiles/amarok-shared.dir/playlistitem.cpp.o] Error 1 TQ_ScaleMax looks like it is not declared any where/ any file that I can find I don't do c++ YMMV

13 years, 10 months

Re: [trinity-devel] libpng version conflicts

by alekow

"Darrell Anderson" <humanreadable(a)yahoo.com> pisze: > --- On Sat, 4/16/11, /dev/ammo42 wrote: > > > From: /dev/ammo42 > > Subject: Re: [trinity-devel] libpng version conflicts > > To: trinity-devel(a)lists.pearsoncomputing.net > > Date: Saturday, April 16, 2011, 2:48 AM > > Le Fri, 15 Apr 2011 17:55:53 -0700 > > (PDT), > > Darrell Anderson > > a écrit : > > > > > > I'll report back in an hour or so with the > > results. > > > > > > > > > > That was a wash. :( Same result. > > > > > > Next I tried changing the various links to point to > > libpng12. ldd > > > showed that kate built with libpng12 and libpng14, but > > once again, no > > > icons in the kate toolbars. > > > > > > Only kate is affected by this. No other app. > > > > > > I noticed every time I start kate that something > > deletes the user's > > > kateui.rc file, which would partially explain the lack > > of icons, > > > although kate should revert to the default kateui.rc > > file. > > > > > > I suppose next I'll try deleting all libpng14 files. > > > > > > Listening for ideas.... > > Did you try setting PNG_CFLAGS / PNG_LIBS or using sed, as > > the message > > I quoted suggests ? I think sed would definitely prevent > > kate from > > using libpng14 (or libpng12 if you want to force the use of > > libpng14). > > But I'm not sure the libpng versions are really the > > problem, since you > > said that without using kdesu there is no issue. Did you > > try running > > Kate both with commandline sudo, su and su - ? If the > > results are not > > the same, there are problems with environment variables. > > > > > > Darrell > > > > > > > > I don't see any such flags such as PNG_CFLAGS / PNG_LIBS. I also never have seen a separate build script for kate. The only place to set build flags is when building kdebase. > > I doubt the problem is related to kdesu ore nvironment variables. As I wrote previously, I see the problem only with kate and not with any other app started through kdesu. > > As I wrote previously, same problem with running from the command line. That is where I see the error messages about the two different libpng versions. > > I'm going to rebuild all packages with only one version of libpng installed. That will eliminate that variable as a cause. That is not a smooth solution because many distros install both versions of libpng. Trinity will have to address this problem sooner or later. > I have no problems with kate under kdesu. I've compiled kde3 on slackware-13.1 and -current using default slackware's libpng. Did you recompile qt-3 before building kde? What were your configure options? I used qt3 slackbuild from slackware12.2 and changed "-qt-libpng" to "-system-libpng". Take a look at "KDE 3.5.10 for slackware-13.1" thread on linuxquesions.org to check which patches i used. Regards, alekow ------------------------------------------------- Pobierz darmowy program PIT. Kliknij tutaj >> http://linkint.pl/f296d

13 years, 10 months

KNetworkManager 0.8 missing icon

by Tiago Marques

Hi all, I've been able to build knetworkmanager-0.8 but it's missing the icons on the system tray. Any ideia where should I look for a fix? Best regards, Tiago

13 years, 10 months

April Meeting

by Robert Xu

Hello all, Not many people responded to the Doodle poll, so... I have meeting dates for you all! http://www.timeanddate.com/worldclock/fixedtime.html?msg=Trinity+April+Meet… Check the link for the meeting date and time in your local time zone. Remember, meetings are held in #trinity-desktop-meeting. This meeting is expected to take one hour. -- later, Robert Xu

13 years, 10 months

libpng version conflicts

by Darrell Anderson

While the work with cmake continues I have been working with building 3.5.10 on newer Slackware systems. Some of the effort will help Trinity, which is part of my goal. Such as testing patches for libpng and KDE4 compatibility. I found some preliminary patches for KDE4 compatibility and have expanded those quite a bit. I will submit those patches to Trinity when I am confident the entire package set is working, which will require several days or more of actual usage. I've rebuilt the entire 3.5.10 package set except koffice. Everything works wonderfully except when I use kdesu to open kate. That is the only problem I have noticed so far. When I open kate through kdesu there are no icons in the toolbars. Usually that indicates a problem with libpng. I'm guessing that this problem might eventually hit Trinity too. Indeed, when I run that command from a terminal I see oodles of messages like this: kate: WARNING: Pixmap not found for mimetype text/plain libpng warning: Application was compiled with png.h from libpng-1.4.3 libpng warning: Application is running with png.c from libpng-1.2.44 libpng error: Incompatible libpng version in application and library So apparently kdebase (at least) linked to libpng 1.4.3 when compiling but oddly wants to run using libpng 1.2.44. Searching the web hasn't helped me nail the solution other than the obvious that there is a conflict between the two versions. I have two versions of libpng installed because that is the way Slackware is now bundled. /usr/include/libpng12/* /usr/include/libpng14/* /usr/lib/libpng* /usr/lib/pkgconfig/libpng12.pc /usr/lib/pkgconfig/libpng14.pc /usr/lib/pkgconfig/libpng.pc -> /usr/lib/pkgconfig/libpng14.pc I'm thinking I should change the libpng.pc sym link from 1.4 to 1.2. I am hoping that will force the packages to build with libpng 1.2. I'm going to try that but I thought I'd post and see whether there might be something else I'm missing. Oddly, I can open kate directly with my user account. I can log in to KDE as root and kate behaves. I can open other apps with kdesu and there are no toolbar icon problems. I can open konqueror with kdesu and then open a file from there with kate and the toolbar icons are fine. I temporarily deleted all of root's related kate config files and saw the same results. I don't really care which version the packages link against as long as they all use that same version after being installed. Any ideas how to avoid these libpng conflicts? Thanks. Darrell

13 years, 10 months

New Qt3 xsession crash on x86_64 - need collective wisdom :)

by David C. Rankin

Baho, All, I was working with the new Qt3 build on x86_64 and I ran into an xsession crash that I need help identifying the cause. I have put the .xsession-error, trinity-qt3 file list up at: http://www.3111skyline.com/dl/dt/trinity/err/newqt3/xsession-error-new-qt3.… http://www.3111skyline.com/dl/dt/trinity/err/newqt3/new-qt3-no-work-file-li… I have reinstalled an older build of Qt3 and it works fine, so there is something in the new build. The PKGBUILD is modeled after the one you are using, but I have enabled the doc and examples. I have put the PKGBUILD up here: http://www.3111skyline.com/dl/dt/trinity/err/newqt3/PKGBUILD-qt3-trinity Looking at the xsession-error file, the following jump out at: DCOP: register 'anonymous-1000' -> number of clients is now 4 DCOP: 'anonymous-1000' now known as 'kwin' kdeinit: Got EXEC_NEW 'kdesktop' from launcher. DCOP: register 'kdesktop' -> number of clients is now 5 DCOP: register 'anonymous-1001' -> number of clients is now 6 DCOP: register 'anonymous-1002' -> number of clients is now 7 DCOP: unregister 'anonymous-1002' *** glibc detected *** kdesktop [kdeinit]: free(): invalid next size (fast): 0x00000000008dda20 *** ======= Backtrace: ========= /lib/libc.so.6(+0x71b96)[0x7fed6bd43b96] /lib/libc.so.6(cfree+0x6c)[0x7fed6bd4896c] /usr/lib/libxcb.so.1(+0x9b64)[0x7fed68288b64] /usr/lib/libxcb.so.1(xcb_wait_for_reply+0x124)[0x7fed682891c4] /usr/lib/libX11.so.6(_XReply+0x10d)[0x7fed6c597b3d] /usr/lib/libX11.so.6(XInternAtom+0xa4)[0x7fed6c581744] /opt/trinity/lib/libkdeinit_kdesktop.so(_ZN18KBackgroundManagerC1EP7QWidgetP10KWinModule+0x4e6)[0x7fed661bd516] /opt/trinity/lib/libkdeinit_kdesktop.so(_ZN8KDesktop8initRootEv+0x430)[0x7fed661add80] /opt/trinity/lib/libkdeinit_kdesktop.so(_ZN8KDesktopC1Ebb+0x4b3)[0x7fed661b2d23] /opt/trinity/lib/libkdeinit_kdesktop.so(kdemain+0x6b4)[0x7fed661947f4] kdesktop [kdeinit][0x408728] kdesktop [kdeinit][0x409f75] kdesktop [kdeinit][0x40a866] kdesktop [kdeinit](main+0xa64)[0x40c1c1] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fed6bcf0dcd] kdesktop [kdeinit][0x4064b9] ======= Memory map: ======== <snip> DCOP aborting (delayed) call from 'anonymous-1001' to 'kdesktop' DCOP: unregister 'kdesktop' DCOP: unregister 'anonymous-1001' KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = kdesktop path = <unknown> pid = 1002 kdeinit: Got EXEC_NEW 'drkonqi' from socket. kdeinit: PID 1001 terminated. kdeinit: Got EXEC_NEW 'kicker' from launcher. Could not load library! Trying exec.... kdeinit: PID 1003 terminated. <snip> dcop: error while loading shared libraries: libqt-mt.so.3: cannot open shared object file: No such file or directory [startkde] Shutting down Trinity... kdeinit: terminate KDE. klauncher: Exiting on signal 1 DCOP: unregister 'anonymous-14951' DCOP: unregister 'khotkeys' DCOP: unregister 'kded' DCOP: unregister 'anonymous-14950' DCOP: unregister 'klauncher' DCOPServer : slotShutdown() -> waiting for clients to disconnect. DCOPServer : slotExit() -> exit. [startkde] Running Trinity shutdown scripts... [startkde] Trinity shutdown complete. I can't explain the first 2 error blocks, but the "dcop: error while loading shared libraries: libqt-mt.so.3: cannot open shared object file: No such file or directory" is self explanatory. However, if you check the file list link above, libqt-mt.so.3 is there: 07:36 alchemy:~/tmp> grep libqt-mt.so.3 new-qt3-no-work-file-list.txt /opt/qt/lib/libqt-mt.so.3 /opt/qt/lib/libqt-mt.so.3.3 /opt/qt/lib/libqt-mt.so.3.3.8 So, why is this file not being found? I don't know what is causing this, so I'm punting to the smart folks for help. I'll have a bit more time to dig into this this weekend, but if you have any thoughts, I would appreciate any help you can give to shorten the dig :) -- David C. Rankin, J.D.,P.E.

13 years, 10 months

kdepim cmake error?

by Baho Utot

Scanning dependencies of target ksieve_parser-static [ 12%] Building CXX object libksieve/parser/CMakeFiles/ksieve_parser-static.dir/utf8validator.cpp.o [ 12%] Building CXX object mimelib/CMakeFiles/mimelib-shared.dir/token.cpp.o [ 13%] Building CXX object libksieve/parser/CMakeFiles/ksieve_parser-static.dir/lexer.cpp.o [ 13%] Building CXX object mimelib/CMakeFiles/mimelib-shared.dir/uuencode.cpp.o [ 13%] Building CXX object mimelib/CMakeFiles/mimelib-shared.dir/binhex.cpp.o Linking CXX shared library libmimelib.so /usr/bin/ld: cannot find -lqt-mt collect2: ld returned 1 exit status make[2]: *** [mimelib/libmimelib.so.1.0.1] Error 1 make[1]: *** [mimelib/CMakeFiles/mimelib-shared.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... [ 13%] Building CXX object libksieve/parser/CMakeFiles/ksieve_parser-static.dir/parser.cpp.o Linking CXX static library libksieve_parser.a [ 13%] Built target ksieve_parser-static make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... Use to build before the svn updates of yesterday and today.

13 years, 10 months

April Meeting

by Robert Xu

Hi all, Next Meeting is currently set for 19 or 20 of April. If nobody reponds to available times here http://www.doodle.com/eivtcn5c3wndqt2u , I will assume 2PM EST. Deadline for submitting available times is Saturday. Meeting topic list also needs to be updated, see trinity.etherpad.trinitydesktop.org/19 or bring it up on #trinity-desktop by pinging Xu_R, samelian, kb9vqf, or MutantTurkey. If you have write permissions, please alter the etherpad. Trinity users are invited for input this meeting. *AS ALWAYS*, meetings are in #trinity-desktop-meeting and the channel is unlocked 24 hours before meetnig. -- later, Robert Xu

13 years, 10 months

Fwd: Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc]

by David C. Rankin

Tim, All, Below is a backtrace and links to the full backtrace I get in Trinity kdesktop. There may be more than 1 bug here, but it looks like at least part of it may be in the Trinity code. Let me know if there is something else you think may help isolate the issue. -------- Original Message -------- Subject: Re: [arch-general] [trinity-devel] x86_64 kdesktop.kcrash [SOLVED - it is glibc] Date: Thu, 24 Feb 2011 12:10:41 -0600 From: David C. Rankin <drankinatty(a)suddenlinkmail.com> Reply-To: General Discussion about Arch Linux <arch-general(a)archlinux.org> Organization: Rankin Law Firm, PLLC To: General Discussion about Arch Linux <arch-general(a)archlinux.org> On 02/23/2011 08:37 PM, David C. Rankin wrote: > On 02/23/2011 07:38 PM, Allan McRae wrote: >> On 24/02/11 10:15, David C. Rankin wrote: >>> On 02/23/2011 04:53 PM, David C. Rankin wrote: >>>> I have no idea what the error means, but it looks like malloc is complaining >>>> about corruption? >>>> >>>> #8 0x00007f3550d27b96 in malloc_printerr (action=3, str=0x7f3550dd6a2e >>>> "malloc(): memory corruption", ptr=<value optimized out>) at malloc.c:6283 >>>> #9 0x00007f3550d2a4ad in _int_malloc (av=0x7f3551012ea0, bytes=16) at >>>> malloc.c:4396 >>>> #10 0x00007f3550d2c460 in __libc_malloc (bytes=16) at malloc.c:3660 >>>> >>>> I'll also follow up with the Trinity folks because I have just tried downgrading >>>> to glibc 2.13-3 and I'm still getting the error on x86_64. No issues with i686 >>>> though?? >>>> >>> >>> Hmm.. This is looking like it is a memory corruption in VMs with glibc> ~ 2.11. >>> I'll dump building in Virtualbox and setup a new x86_64 box for the purpose. If >>> you have any other thoughts/ideas on the glibc/VM issue, I'd welcome them. >> >> Never heard of that. Do you have a link? I was thinking that this was a >> treading issue further up the stack... (libxcb??) > > No link. One of the guys on the Trinity list mentioned the problem, and googling > turned up a related glibc bug fixed 1/14/2011 > > http://www.virtualbox.org/ticket/7981 > > I don't know why the internals of a VM would cause the memory corruption entry > in the backtrace (but then again.. I don't know enough about it to know :) > >> >>> What this seems to indicate is that you can no longer rely on building in a >>> clean VirtualBox Arch VM. This problem is more acute for large projects with >>> multiple layers of dependencies where an archroot proves difficult for managing >>> dependencies for packages later in the build order. >> >> I use makechrootpkg -r /root/of/chroot -- -i. That tells makepkg to install >> after building and the lack of -c means the chroot cleaning does not occur so >> those packages stay installed. >> > > I had set up an archroot with an internal repository under > <archroot>/root/chrepo. On i686 it would load the packages as needed. On x86_64 > it wasn't behaving correctly at all. (same pacman.conf, etc..) I had used > makechrootpkg -r /root/of/chroot -- -i to manually install packages but ran into > problems so I switched to Virtualbox which was working *perfectly* until I ran > into this glibc/libxcb issue. > > (Virtualbox still works perfectly for building and running Trinity, it's just > this issues that has me questioning if vbox is causing problems) > > I'm about to dump kde4 and kdemod3 from an old laptop drive I've got and test > the issue on a native x86_64 outside of a VM. I'll let you know how it goes. > > If I can get you anything else from the install that has the glibc or libxcb > issue, let me know and I'm happy to do it. > > BTW: I've tested the kdemod3 update based on Trinity 3.5.12 on both i686 and > x86_64 and they seem to run fine. > >> >> If this is virtualbox specific, I'd try qemu-kvm. >> >> Allan >> > > Allan, There is something to this glibc/libxcb issue. I have just dumped a prior arch install on my X86_64 laptop and did a fresh net-install. Nothing but xorg (and dependencies) on the box. I loaded the latest Trinity binaries - no kdesktop crash, and it ran fine from startx. But the X resolution was 1024x768 due to xf86-video-fbdev being the only driver on the box at the time.. After going through all the kcontrol settings I normally use, I exited the desktop to install xf86-video-ati. On restart of the desktop, the resolution looked great, the desktop looked great, the kde useful tips window was fine -- then I cliced the 'Close' button on the useful tips window and my display ripped into little pixels wrapping the display around itself at least 10 times (the staggered checkerboard pixelation) Clicking in the blind, I was able to log off and was greeted by a backtrace on the console window. I started X again with the output redirected into a file to catch the error. The basic error is: <snip> COP: unregister 'kaccess' X Error: BadWindow (invalid Window parameter) 3 Major opcode: 7 Minor opcode: 0 Resource id: 0x2000006 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 6 Minor opcode: 0 Resource id: 0x2000006 *** glibc detected *** kdesktop [kdeinit]: double free or corruption (!prev): 0x00000000019b4020 *** ======= Backtrace: ========= /lib/libc.so.6(+0x71b96)[0x7fabc07e2b96] /lib/libc.so.6(cfree+0x6c)[0x7fabc07e796c] /opt/trinity/lib/libkdeinit_kdesktop.so(_ZN18KBackgroundManagerD0Ev+0x24)[0x7fabbac2fdfe] /opt/trinity/lib/libkdeinit_kdesktop.so(_ZN8KDesktopD1Ev+0xe8)[0x7fabbac23ba8] /opt/trinity/lib/libkdeinit_kdesktop.so(kdemain+0xc27)[0x7fabbac04dff] /opt/trinity/lib/kde3/kdesktop.so(kdeinitmain+0x20)[0x7fabbae9c77c] kdesktop [kdeinit][0x408728] kdesktop [kdeinit][0x409f75] kdesktop [kdeinit][0x40a866] kdesktop [kdeinit](main+0xa64)[0x40c1c1] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fabc078fdcd] kdesktop [kdeinit][0x4064b9] ======= Memory map: ======== 00400000-00411000 r-xp 00000000 08:06 904841 /opt/trinity/bin/kdeinit 00611000-00612000 rw-p 00011000 08:06 904841 /opt/trinity/bin/kdeinit 018a1000-0200f000 rw-p 00000000 00:00 0 [heap] 7fabb4000000-7fabb4021000 rw-p 00000000 00:00 0 7fabb4021000-7fabb8000000 ---p 00000000 00:00 0 7fabb9847000-7fabb98b3000 r-xp 00000000 08:06 813482 /usr/lib/libmng.so.1.0.0 7fabb98b3000-7fabb9ab2000 ---p 0006c000 08:06 813482 /usr/lib/libmng.so.1.0.0 <snip> The full error is: http://www.3111skyline.com/dl/dt/trinity/arch/err/X/startx-messages.txt The corresponding Xorg.0.log: http://www.3111skyline.com/dl/dt/trinity/arch/err/X/startx-messages.txt No (EE). I have no idea what this error is. Something is going wrong somewhere on x86_64 with either glibc or libxcb. I don't know if the output from the startx command and its backtrace will help narrow this down, but it seems to be a generic X/glibc/libxcb issue. When using the fbdev video driver, there was *no corruption* at all. Then when I loaded the ati driver all heck broke loose. I don't know what Virtualbox relies on to create its virtual display driver, but this glibc/libxcb issue is present on both nvidia and ati based host computers. When the current build in the x86_64 laptop is done, I'll load fluxbox and see what it does on top of the ati driver, but I suspect it will be exactly the same. I saw this same display pixelation a week ago on a suse 11.3 box after the xorg files were updated. I had to downgrade the xorg files there to recover. The pixelation/display wrapping was exactly the same there. I'll follow up with the fluxbox results (expect the same), but in the mean time, if you have any suggestions of what additional information could help, let me know and I'll go chase it down. Thanks -- David C. Rankin, J.D., P.E.

13 years, 10 months

[arch] Your Qt3 is not patched for compatibility with tqtinterface

by Calvin Morrison

Hmmmm, All of a sudden whenever building anything for trinity, I keep running into this problem " Your Qt3 is not patched for compatibility with tqtinterface " but I don't really know why. I have installed the patched versions and it was all working until last week. Am I missing something? Also, Baho and David, have you run into similar problems? Calvin Morrison

13 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels April 2011