tde-devels

devels@trinitydesktop.org

3753 discussions

by Darrell Anderson

Has anyone been building tqca and tqca-tls as 64-bit packages? They fail for not finding libtqt-mt.so. This is the snippet from the configure file: ============================================ if [ "$?" != "0" ]; then rm -rf .qconftemp echo fail echo echo "There was an error compiling 'conf'. Be sure you have a proper" echo "TQt 3.x Multithreaded (MT) build environment set up." if [ ! -f "$QTDIR/lib/libtqt-mt.so.3" ]; then echo echo "One possible reason is that you don't have" echo "libtqt-mt.so.3 installed in $QTDIR/lib/." fi echo exit 1; fi ============================================ I have $LIBDIR exported as /opt/trinity/lib64, but the tqca/tqca-tls configuration seems to be hard-coded to $PREFIX/lib. I'm probably missing something obvious because I see oodles of 64-bit RPM packages online, meaning the packages build on 64-bit. Currently I have all Trinity related 64-bit lib files installing to /opt/trinity/lib64. I'm just beginning to build everything for 64-bit, but other than these two packages, I seem to be proceeding okay. I'm presuming the two need to be patched or I have something misconfigured in my build scripts. Thanks. Darrell

12 years, 9 months

SOLVED: digikam libpng15 + gcc47 - But: 'color_type' -- Is This Correct??

by David C. Rankin

All, I have built digikam on libpng15. There were two simple fixes for: if (setjmp(png_jmpbuf(png_ptr))) The remaining errors involved: digikamthumbnail.cpp:416:17: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' In file included from digikamthumbnail.cpp:96:0: /usr/include/png.h:726:16: error: forward declaration of 'png_info {aka struct png_info_def}' digikamthumbnail.cpp:419:17: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' In file included from digikamthumbnail.cpp:96:0: /usr/include/png.h:726:16: error: forward declaration of 'png_info {aka struct png_info_def}' digikamthumbnail.cpp:425:17: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' In file included from digikamthumbnail.cpp:96:0: The above all involved references like: if (info_ptr->color_type == PNG_COLOR_TYPE_RGB_ALPHA) I know the 'info_ptr->color_type' is the problem. That's wrong due to no longer having direct access to the png struct. Looking at other patches, it looked like I could simply do: if (color_type == PNG_COLOR_TYPE_RGB_ALPHA) Since we have already made the call to: png_get_IHDR(png_ptr, info_ptr, (png_uint_32 *) (&w32), (png_uint_32 *) (&h32), &bit_depth, &color_type, &interlace_type, NULL, NULL); color_type should already hold the color type. So is just using 'color_type' correct? Digikam builds fine, but I need somebody to verify the patch. Darrell, we will need to add preprocessor checks for the libpng version. I haven't done that yet. The consolidated patch is attached for review. -- David C. Rankin, J.D.,P.E.

12 years, 9 months

Building for 64-bit

by Darrell Anderson

I'm updating my build scripts to support 64-bit packages. Should (T)Qt3 install the lib files to $PREFIX/lib or $PREFIX/lib64? Thanks. Darrell

12 years, 9 months

Building against Qt3 Fails

by Darrell Anderson

I decided to build against Qt3 rather than TQt3. First time in a long time. The patch we used recently to build avahi-tqt against TQt3 can't be used when building against Qt3. The patch is good only when building against TQt3. I presume the proper way to implement the patch is to add some preprocessor checks so packagers don't have to worry about the issue. For myself I added the following test in my avahi-tqt build script: if [ -r ${PREFIX}/lib/pkgconfig/tqt-mt.pc ] || [ -r /usr/lib/pkgconfig/tqt-mt.pc ]; then cat $CWD/avahi-tqt-fixes.diff | patch -p1 --verbose --no-backup-if-mismatch || exit 1 fi tdebase fails to build: /dev/shm/tdebase.build/kicker/kicker/core/kmenubase.ui.h:7: error: 't_xdisplay' was not declared in this scope As neither tqt_xdisplay nor qt_xdisplay is used in the source file, why does the file compile against TQt3 and not Qt3? Darrell

12 years, 9 months

tqqt_cast vs. tqt_cast

by Darrell Anderson

What is the differnce? Darrell

12 years, 9 months

tdepim - gcc47 - need help with "which redeclared 'it' is right 'it'?"

by David C. Rankin

Calvin, Slavek, Liddell, I'm trying to fix tdepim to build with gcc47, but I don't understand how to make sure I'm fixing the right 'it' iterator. Specifically, the multiple declaration issue is: /build/src/tdepim/kmail/kmsystemtray.cpp: In member function 'void KMSystemTray::updateNewMessages()': /build/src/tdepim/kmail/kmsystemtray.cpp:485:48: error: redeclaration of 'TQMap<TQGuardedPtr<KMFolder>, int>::Iterator it' /build/src/tdepim/kmail/kmsystemtray.cpp:475:55: error: 'TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator it' previously declared here The code beginning at line 473 is: void KMSystemTray::updateNewMessages() { for ( TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator it = mPendingUpdates.begin(); it != mPendingUpdates.end(); ++it) { KMFolder *fldr = it.key(); if ( !fldr ) // deleted folder continue; /** The number of unread messages in that folder */ int unread = fldr->countUnread(); TQMap<TQGuardedPtr<KMFolder>, int>::Iterator it = mFoldersWithUnread.find(fldr); bool unmapped = (it == mFoldersWithUnread.end()); /** If the folder is not mapped yet, increment count by numUnread in folder */ if(unmapped) mCount += unread; /* Otherwise, get the difference between the numUnread in the folder and * our last known version, and adjust mCount with that difference */ else { int diff = unread - it.data(); mCount += diff; } Looking through the comments and context, there seems to be two 'it' iterators involved: TQMap<.., bool>::...it TQMap<.., int>::...it with the 'bool' declaration being the loop index and the 'int' being used to determine if the folder with unread messages is unmapped. The 'bool' dec seems to be the one used to access the class data (i.e. it.key(), it.data()) If I'm reading that correctly, then we can correct the 'int' iterator by renaming it something like 'unread_it' TQMap<TQGuardedPtr<KMFolder>, int>::Iterator unread_it = mFoldersWithUnread.find(fldr); bool unmapped = (unread_it == mFoldersWithUnread.end()); What say the experts. Is my reading of which 'it' can be renamed correct? -- David C. Rankin, J.D.,P.E.

12 years, 9 months

TDE spring fundraiser status

by Timothy Pearson

I am cross-posting this as I know some of you are not signed up for the trinity-announce mailing list: http://trinity-announce.pearsoncomputing.net/?0::21 Tim

12 years, 9 months

Calvin: Thanks!

by Darrell Anderson

I have so much enjoyed being able to disable the cycling feature with the task bar and pager applet (bug reports 251 and 908). Both patches have reduced my irritability/anxiety levels. :) 'Tis the little things that often affect us most. :) Darrell

12 years, 9 months

k3b -bug ('K3bAudioEditorWidget::Range* r' previously declared here)

by David C. Rankin

Darrell, all I'm making an attempt at fixing k3b for gcc47. If anyone else has already done this please stop me. It is part of bug 958. -- David C. Rankin, J.D.,P.E.

12 years, 9 months

Tim: Collation of TSAK/TDM related issues

by Darrell Anderson

Collation of TSAK/TDM related issues (there are overlaps in descriptions but that does not mean the same exact problem): Bug reports involved: 928, kdm starts too early 925, [kdesktop] SAK driven secure dialog is not available for use 906, SAK realization is mostly buggy for KDM 898, tsak process taking 90-100% of CPU 894, TDM: Log file is never purged 884, tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket' 667, kdm spawns kwin as root, keeps running after login 625, KDM is hard-coded to use /tmp rather than $TMP or $TMPDIR ================================================== Direct TSAK issues: * TSAK demands 90-100% CPU. * High CPU consumption on wait SAK. * TSAK/TDM performs no housekeeping to remove pipe/socket files: 1) During a reboot/halt (when TDM terminates) 2) X server restart (which TDM allows) 3) When a user disables TSAK in KControl (tdmrc:UseSAK=false) * Restarting X server or TSAK ignores the tdmrc:UseSAK=false, using the existing pipe/socket files instead and keeps running even when explicitly disabled in tdmrc. * When building tdebase without TSAK support (-DBUILD_TSAK=OFF), and tdmrc:UseSAK=false, TDM starts with the dialog to press Ctrl-Alt-Del. That should not happen. * Disabling TSAK in tdmrc (UseSAK=false) does not work. * Exit from wait dialog by Ctrl+Alt+Del does not work. * Some people cannot obtain access to the TDM login dialog when pressing Ctrl-Alt-Del. * TSAK ownership of /tmp/tdesocket-global is assigned to the system's primary login account. Ownership of that directory is determined by the account UID listed in the tdmrc MinShowUID key and then that account number is grabbed from /etc/passwd. * xsession message of "[kdesktop] SAK driven secure dialog is not available for use (retcode %d)" appears although TDM is not running when using startx. ================================================== Related to TDM and TSAK: * When starting X from startx (TDM is not running) the message "tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket'" appears. There should be no tdmctl/TSAK related messages when using startx. * Both calls to tdmctl in tdmtsak use the format "tdmctl list" yet there is no "list" option in tdmctl --help. What is the "list" parameter supposed to do? * TDM creates nominal profile directories in /tmp. All such directories use a numeric name string. TDM runs as non-user, but should not be creating any profile directories. Not needed and the profile directories are never purged. Never happened in KDE3. ================================================== TDM specific: * TDM starts too early * TDM log files never purged. * TDM spawns twin as root, keeps running after login I hope this helps. :) Darrell

12 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels