tde-devels

devels@trinitydesktop.org

3753 discussions

TQt3 FTBFS - Looks like build scripts need renaming as well

by David C. Rankin

Darrell, TQt3 fails to build with the following (during packaging). Looks like the build scripts :( ( [ -d styles ] && cd styles ; make -f Makefile install; ) || true make[3]: Entering directory `/build/src/tqt3/plugins/src/styles' make[3]: Nothing to be done for `install'. make[3]: Leaving directory `/build/src/tqt3/plugins/src/styles' make[2]: Leaving directory `/build/src/tqt3/plugins/src' make[1]: Leaving directory `/build/src/tqt3' install: cannot stat 'qmake/qmake': No such file or directory ==> ERROR: A failure occurred in package(). Aborting... I think this is on my end, but all other packagers will have to check their setup as well... -- David C. Rankin, J.D.,P.E.

12 years, 7 months

Ark Extraction Dialog Broken?

by Darrell Anderson

I think the Ark extraction dialog is broken. Ark refuses to retain a kdialog size. The dialog always opens too small for me to read the file text box. I have to manually resize every time. Rinse, repeat. Frustrating. Ark does not use a full kdialog. There is no toolbar, hence, no button with my bookmarks. Ark won't retain a dialog history. I have two working directories to which I routinely want to extract files. I want those locations retained in the drop-down history. Each time I open Ark the dialog defaults to $HOME/{$ARCHIVE_NAME} with no history. Sometimes Ark will default to extracting to $HOME/{$PREVIOUS_ARCHIVE_NAME}//{$ARCHIVE_NAME}, which to silly. (Also notice the double slash.) Just to be sure, I created a fresh profile and noticed the same behavior. I can somewhat cheat by manually editing arkrc with the following: [generic] extractionHistory[$e]=/some/directory1,/some/directory2 I don't know why Ark doesn't automatically create that config key. I seem to recall this working at one time in 3.5.10, but I can't get this to work there any more either. This is classic paper cut territory and I'm bleeding. :-) I would be grateful if somebody would confirm this wacky behavior before I write a bug report. Darrell

12 years, 7 months

Arch update - gcc 4.7.1 hists testing repo, kwrite crash?

by David C. Rankin

All, Just a quick update. gcc 4.7.1 has it the testing repository for Arch Linux. This will hopefully allow a resolution of what was causing the race condition in tdelibs/tdebase leading to the kwrite crash on line-wrap. However, as is the Arch tradition, the chroot build environment is going though growing pains resulting from the recent updates to the Arch package manager 'pacman'. We will hopefully work though this in the next couple of days and have a new set of packages build on 4.7.1 to test. Nothing like working on the leading (not bleeding) edge :) -- David C. Rankin, J.D.,P.E.

12 years, 7 months

FTBFS - python-tqt -- sip: TQ_LONG is undefined

by David C. Rankin

Tim, Darrell, All, python-tqt fails to build from source. It looks like it may be related to a sip problem (see 1st two lines below). I haven't changed my build scripts of either sip or python-tqt. What should I check? Full error follows: sip: TQ_LONG is undefined Error: Unable to create the C++ code. This is the GPL version of PyTQt 3.18.1 (licensed under the GNU General Public License) for Python 2.7.3 on linux2. Type 'L' to view the license. Type 'yes' to accept the terms of the license. Type 'no' to decline the terms of the license. Do you accept the terms of the license? qextscintillaglobal.h could not be found in /opt/tqt3/include and so the qtext module will not be built. If TQScintilla is installed then use the -n argument to explicitly specify the correct directory. Checking to see if the qtcanvas module should be built... Checking to see if the qtnetwork module should be built... Checking to see if the qttable module should be built... Checking to see if the qtxml module should be built... Checking to see if the qtgl module should be built... Checking to see if the qtui module should be built... Checking to see if the qtsql module should be built... Checking to see if the TQAssistantClient class is available... Creating features file... Checking to see if the TQCDEStyle class is built in... Checking to see if the TQCDEStyle class is built in... Checking to see if the TQInterlaceStyle class is built in... Checking to see if the TQInterlaceStyle class is built in... Checking to see if the TQMotifStyle class is built in... Checking to see if the TQMotifStyle class is built in... Checking to see if the TQMotifPlusStyle class is built in... Checking to see if the TQMotifPlusStyle class is built in... Checking to see if the TQPlatinumStyle class is built in... Checking to see if the TQPlatinumStyle class is built in... Checking to see if the TQSGIStyle class is built in... Checking to see if the TQSGIStyle class is built in... Checking to see if the TQWindowsXPStyle class is built in... Checking to see if the TQWindowsXPStyle class is built in... Checking to see if the TQWindowsStyle class is built in... Checking to see if the TQWindowsStyle class is built in... TQt v3.4.0 free edition is being used. SIP 4.10.5 is being used. These PyTQt modules will be built: qt qtcanvas qtnetwork qttable qtxml qtgl qtui qtsql. Support for these TQt classes has been disabled: TQInterlaceStyle TQWindowsXPStyle. The PyTQt modules will be installed in /usr/lib/python2.7/site-packages. The PyTQt .sip files will be installed in /usr/share/sip. The TQt header files are in /opt/tqt3/include. The tqt-mt TQt library is in /opt/tqt3/lib. pyuic will be installed in /usr/bin. pylupdate will be installed in /usr/bin. Generating the C++ source for the qt module... -- David C. Rankin, J.D.,P.E.

12 years, 7 months

tqca/tqca-tls FTBFS: Proposed patches

by Darrell Anderson

qmake has been renamed to tqmake. Proposed patch for tqca: ============================================ diff -urN tqca/configure tqca.new/configure --- tqca/configure 2012-06-12 12:34:36.000000000 -0500 +++ tqca.new/configure 2012-06-19 21:14:05.000000000 -0500 @@ -71,15 +71,15 @@ fi fi -if [ ! -x "$QTDIR/bin/qmake" ]; then +if [ ! -x "$QTDIR/bin/tqmake" ]; then if [ "$QC_DEBUG" = "Y" ]; then - echo Warning: qmake not in \$QTDIR/bin/qmake + echo Warning: tqmake not in \$QTDIR/bin/tqmake echo trying to find it in \$PATH fi - qm=`type -p qmake` + qm=`type -p tqmake` if [ -x "$qm" ]; then if [ "$QC_DEBUG" = "Y" ]; then - echo qmake found in $qm + echo tqmake found in $qm fi else echo fail @@ -88,12 +88,12 @@ echo or I missdetected \$QTDIR=$QTDIR echo echo Please set \$QTDIR manually and make sure that - echo \$QTDIR/bin/qmake exists. + echo \$QTDIR/bin/tqmake exists. echo exit 1; fi else - qm=$QTDIR/bin/qmake + qm=$QTDIR/bin/tqmake fi gen_files() { @@ -480,7 +480,7 @@ if [ -x "./qcextra" ]; then ./qcextra fi -# run qmake +# run tqmake $qm qca.pro if [ "$?" != "0" ]; then echo diff -urN tqca/qca.pro tqca.new/qca.pro --- tqca/qca.pro 2012-05-27 17:58:16.000000000 -0500 +++ tqca.new/qca.pro 2012-06-19 21:14:13.000000000 -0500 @@ -1,4 +1,4 @@ -# qca qmake profile +# qca tqmake profile TEMPLATE = lib CONFIG += qt thread release ============================================ Proposed patch for tqca-tls: diff -urN tqca-tls/configure tqca-tls.new/configure --- tqca-tls/configure 2012-06-12 12:34:50.000000000 -0500 +++ tqca-tls.new/configure 2012-06-19 21:17:33.000000000 -0500 @@ -79,15 +79,15 @@ fi fi -if [ ! -x "$QTDIR/bin/qmake" ]; then +if [ ! -x "$QTDIR/bin/tqmake" ]; then if [ "$QC_DEBUG" = "Y" ]; then - echo Warning: qmake not in \$QTDIR/bin/qmake + echo Warning: tqmake not in \$QTDIR/bin/tqmake echo trying to find it in \$PATH fi - qm=`type -p qmake` + qm=`type -p tqmake` if [ -x "$qm" ]; then if [ "$QC_DEBUG" = "Y" ]; then - echo qmake found in $qm + echo tqmake found in $qm fi else echo fail @@ -96,12 +96,12 @@ echo or I missdetected \$QTDIR=$QTDIR echo echo Please set \$QTDIR manually and make sure that - echo \$QTDIR/bin/qmake exists. + echo \$QTDIR/bin/tqmake exists. echo exit 1; fi else - qm=$QTDIR/bin/qmake + qm=$QTDIR/bin/tqmake fi gen_files() { @@ -575,7 +575,7 @@ if [ -x "./qcextra" ]; then ./qcextra fi -# run qmake +# run tqmake if expr match "$DEB_BUILD_OPTIONS" ".*nostrip"; then $qm QMAKE_STRIP=true qca-tls.pro else diff -urN tqca-tls/qca-tls.pro tqca-tls.new/qca-tls.pro --- tqca-tls/qca-tls.pro 2012-05-27 17:58:17.000000000 -0500 +++ tqca-tls.new/qca-tls.pro 2012-06-19 21:17:22.000000000 -0500 @@ -1,4 +1,4 @@ -# qca-tls qmake profile +# qca-tls tqmake profile TEMPLATE = lib CONFIG += qt thread release plugin ============================================ Darrell

12 years, 7 months

FTBFS - avahi-tqt - looks like qt-watch.moc3 or sed issue

by David C. Rankin

Tim, Darrell, I have also run into an avahi-tqt build failure. Again, nothing has changed on my end. However, when attempting to build avahi-tqt, it fails. I have included the context leading to the failure, because I'm not entirely sure what crashed. It looks like it is complaining about a sed option. What does it look like to you? config.status: executing libtool commands ---{ avahi 0.6.30 }--- prefix: /opt/trinity sysconfdir: /etc localstatedir: /var avahi socket: /var/run/avahi-daemon/socket dbus-1 system.d dir: /etc/dbus-1/system.d dbus-1 version: 1.4.20 dbus-1 system socket: unix:path=/var/run/dbus/system_bus_socket C Compiler: gcc -std=gnu99 CFLAGS: -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fstack-protector -std=c99 -Wall -W -Wextra -pedantic -pipe -Wformat -Wold-style-definition -Wdeclaration-after-statement -Wfloat-equal -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn -Wshadow -Wendif-labels -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -fdiagnostics-show-option -Wno-cast-qual -fno-strict-aliasing Enable GLIB: yes Enable GLIB GObject: yes Enable GObject Introspection: no Enable GTK 2.0: Enable GTK 3.0: Enable D-Bus: yes With XML: expat Enable GDBM: Enable DBM: Enable Python: Enable pygtk: Enable python-dbus: Enable QT3: yes Enable QT4: Enable Mono: Enable Monodoc: Distribution/OS: archlinux User for avahi-daemon: avahi Group for avahi-daemon: avahi Priviliged access group for Avahi clients: netdev User for avahi-autoipd: avahi-autoipd Group for avahi-autoipd: avahi-autoipd Enable chroot(): yes Enable Linux inotify: yes Enable stack-smashing protection: yes systemd unit directory: Building libavahi-tqt: yes + make clean Making clean in avahi-tqt make[1]: Entering directory `/build/src/avahi-tqt/avahi-tqt' test -z "qt-watch.moc3" || rm -f qt-watch.moc3 test -z "libavahi-tqt.la" || rm -f libavahi-tqt.la rm -f ./so_locations rm -rf .libs _libs rm -f *.o rm -f *.lo make[1]: Leaving directory `/build/src/avahi-tqt/avahi-tqt' Making clean in . make[1]: Entering directory `/build/src/avahi-tqt' test -z "avahi-tqt.pc" || rm -f avahi-tqt.pc rm -rf .libs _libs rm -f *.lo make[1]: Leaving directory `/build/src/avahi-tqt' ==> Building - tde-avahi-tqt... make all-recursive make[1]: Entering directory `/build/src/avahi-tqt' Making all in avahi-tqt make[2]: Entering directory `/build/src/avahi-tqt/avahi-tqt' GEN qt-watch.moc3 cp: invalid option -- 'o' Try 'cp --help' for more information. sed: invalid option -- 'o' Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]... -n, --quiet, --silent suppress automatic printing of pattern space -e script, --expression=script add the script to the commands to be executed -- David C. Rankin, J.D.,P.E.

12 years, 7 months

Proposed menu changes --- testing requested

by Darrell Anderson

Corner cases always present challenges. They need to be resolved with as little impact as possible to "mainstream" usage. When installing a full Trinity package set the Office and Utilities menus are huge. Huge menus are challenging to read and not user-friendly. Under the current structure, when KDE4 is installed on the same system, those menu items also appear in the TDE menus, as do all non TDE apps. The result is an overwhelming and frustrating menu, especially for laptop users, who have reduced desktop areas. I have been testing a menu layout that attempts to resolve this clutter and move all KDE4 menu items to a separate "KDE" submenu. Reducing clutter in the Utilities menu was straightforward: I restored the old "File" and "Peripherals" sub menus. Reducing clutter in the Office menu was a tad more challenging. On my 1650x1080 desktop, the menu is longer than the vertical height of my screen and requires scrolling to view the full menu. My solutions: * Moved Kivio and Karbon to the Graphics menu. * Removed KNotes, as KNotes is already in Utilities->Desktop. * Removed KAlarm, as KAlarm is already in Utilities->PIM. * Created an Office->PIM submenu. In all not a lot considering the benefits. Proposed TDE Menu Changes for KDE Apps: With the current menu layout, KDE4 apps appear alongside TDE apps in the Trinity menu. The KDE4 apps are distinguished with a "[KDE4]" appendage in the menu description. Some people don't mind this mixing of menu items and others find this structure confusing or cluttered. I developed a way to reduce this clutter when TDE and KDE are installed concurrently. All KDE items are placed in their own submenu. Although I'm content with the changes, I am asking for folks to test. The updated files are available as a tar.gz file at bug report 977. I am using that format rather than a series of patches because the latter means only those who build Trinity packages would be able to test. As a compressed file anybody can help test. Installing the updated files: * Unpack and install the directories files to $PREFIX/share/desktop-directories. These files are unique and do not overwrite anything. They are easy to identify because all but one have a "kde-" prefix rather than "tde-" prefix. * Unpack and install the desktop_files to $PREFIX/share/applications/tde. These files will overwrite any installed files. Please consider creating a backup of the directory of affected files. * Install the two applications.menu-* files to $SYSCONFDIR/xdg/menus. Testing: copy (overwrite) the desired applications.menu* to the same location as applications.menu. The *.desktop files won't work in 3.5.13 because they presume the latest XDG updates. These updated files probably could work with KDE3 because the updated menus reference "KDE" rather than "KDE4." Before skipping down that trail remember that trying to run KDE3 apps in Trinity or vice-versa is a library-loading nightmare that will result in crashes and freezes. KDE3 and Trinity may be installed concurrently, but unlike Trinity and KDE4, only one desktop can be used by a user at one time. Multiple users can use either desktop (KDE3 remains useful for comparative testing against Trinity, but most/all of us here want to use Trinity as a primary desktop. :-) ). Therefore populating the Trinity menu with KDE3 apps is somewhat self-defeating. I have a special menu: applications.menu-no-kde. This menu excludes all KDE3 or KDE4 apps from the Trinity menu. To help ensure KDE3 and TDE apps don't conflict with another by appearing in the menu, ensure the XDG_CONFIG_DIRS environment variable does not include XDG menu paths from the other desktop. These updated files do not remove the "[KDE4]" appendage from the KDE4 menu items. To do that requires a patch to tdelibs, which I have but am not making available at the moment. Retaining the "[KDE4]" identifier is an easy way to notice whether the menu items are in the correct location. Further, when using the modified application.menu-with-kde and the KDE4 items are moved to their own menu, the "[KDE4]" identifier helps as a redundant reminder. When using the modified menu, there will be no changes to the menu when KDE4 is not installed on the system. TDE populates a menu item only when there are items to populate. That is, the menu will look the same despite using the modified menu. The changes become effective only when KDE4 is installed. Such users will still see the other menu changes. Testing might should not require restarting the TDE session. Waiting several seconds and accessing the menu once or twice will refresh the entire menu. These menu changes are targeted for R14. :-) Thank you much for helping! Note: the changes are not set in stone. Please provide feedback! Darrell

12 years, 7 months

Preparing v3.5.13.1

by Slávek Banko

Hi, It's been a long time since I announced the current status of preparation 3.5.13.1. As you probably know, the process is not stopped. Not only was it incorporated many other patches, but it was set up branch in the GIT, in which patches were included. In the GIT so you can see some modules with branch v3.5.13-sru. Because packages in my PPA include not only commits cherry picked from GIT, but some patches "cherry picked" from Bugzilla, I would like to open discussion about these patches: + kdelibs -- Fix Konqueror file pane updates http://bugs.pearsoncomputing.net/bugzilla/bugzilla/show_bug.cgi?id=756 -- Fix mimetype detection is incorrect, some files appear as Unknown http://bugs.pearsoncomputing.net/bugzilla/bugzilla/show_bug.cgi?id=656 + kdepim -- [kmail] fixed composer crash http://bugs.pearsoncomputing.net/bugzilla/bugzilla/show_bug.cgi?id=953 + kdeutils -- [klaptodaemon] removes dpkg commands http://git.trinitydesktop.org/cgit/tde-packaging/tree/redhat/kdeutils/kdeut… All these patches are for some time already part of prepared v3.5.13.1, so are some time tested by users. I propose to push them into the GIT. What do you think? Slavek --

12 years, 7 months

Corrupt image files in gwenview sources

by Darrell Anderson

There are 6 png and 2 svg files in applications/gwenview/src/gvdirpart. All png files are unviewable. I can restore the 6 png images from the original 1.4.2 sources. The difference with the png images is one byte in file size, so probably some kind of CR/LF copy error. I have pushed those 6 fixes to GIT. One of the svg files won't open in gwenview, in Trinity GIT or 3.5.10. Gwenview crashes trying to open the file. Looking through past source archives of gwenview, this file never changed size and all of the past copies crash gwenview. I can open the suspect svg in karbon and resave but before I push that copy I'd be grateful if one of the artists here would look at the file: applications/gwenview/src/gvdirpart/crsc-app-gvdirpart.svg I can open the suspect svg in a text editor. Thanks again! Darrell

12 years, 7 months

Suspect debugging symbols

by Darrell Anderson

I notice in my kcrash backtrace captures that sometimes I see references to files in "dev/shm." That is the location for tmpfs/$TMP on my system, where I build packages. Are those "dev/shm" references normal or am I doing something wrong with creating my debugging symbol packages? Thanks much. Darrell

12 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels