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.
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
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
--
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
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
I am unable to build kbugbuster in tdesdk. I realize kbugbuster is more or less broken but we should still be able to build.
I can build tdesdk in one of two ways:
* -DBUILD_KBUGBUSTER=OFF
* Reversing GIT patches b04ab117 and 629e2283, both from 03-27-2012.
The failure is being unable to find the libkcal headers installed by tdepim. Those headers are installed in $PREFIX/include/libkcal, as seen in tdepim/libkcal/CMakeLists.txt: DESTINATION ${INCLUDE_INSTALL_DIR}/libkcal.
Therefore reversing the two patches in GIT seems the correct way to fix this. Comments? Objections?
Darrell
Some of you may know of "smxi" which is a set of administration
scripts for Debian going back a number of years. Originating from the
sidux project, smxi is well-known and repected among Debian
(particularly testing/sid) users.
I recently requested on smxi forum
http://techpatterns.com/forums/about2131-10.html
for kdm-trinity to be added to the list of supported display managers.
The scripts autodetect the default DM so it can stop/start it when
nececcary.
The admin was happy to do so, however it did not work as expected
because of TDE naming inconsistencies and the DM executable being in
other than /usr/bin
$ which kdm
/opt/trinity/bin/kdm
$ ls /etc/init.d | grep kdm
kdm-trinity
$ cat /etc/X11/default-display-manager
/opt/trinity/bin/kdm
I would like to draw attention to this, as I am sure TDE would be more
widely accepted if more general standards were followed (however, I
know the team is already working in this area)
tdenetwork built without error on 6/14. Now fails to build.
[ 40%] Building CXX object kopete/protocols/groupwise/libgroupwise/CMakeFiles/groupwise-static.dir/gwclientstream.cpp.o
cd /dev/shm/tdenetwork.build/kopete/protocols/groupwise/libgroupwise && /usr/bin/c++ -DHAVE_CONFIG_H -O2 -march=i486 -mtune=i686 -ggdb -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/opt/trinity/include -I/usr/include/tqt -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/dev/shm/tdenetwork.build/kopete/protocols/groupwise/libgroupwise -I/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise -I/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/qca/src -I/dev/shm/tdenetwork/kopete/libkopete -I/opt/trinity/include -I/usr/include/tqt -fPIC -o CMakeFiles/groupwise-static.dir/gwclientstream.cpp.o -c /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp
In file included from /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:43:
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:43: error: 'QCA' has not been declared
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:43: error: expected ',' or '...' before '*' token
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:44: error: 'QCA' has not been declared
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:44: error: expected ',' or '...' before '*' token
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:45: error: 'QCA' has not been declared
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:45: error: expected ',' or '...' before '*' token
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:109: error: 'QCA' has not been declared
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:109: error: expected ')' before '*' token
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:110: error: 'QCA' has not been declared
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:110: error: expected ')' before '*' token
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: 'QCA' has not been declared
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: ISO C++ forbids declaration of 'TLS' with no type
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:122: error: expected ';' before '*' token
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: 'QCA' has not been declared
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: ISO C++ forbids declaration of 'SASL' with no type
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/securestream.h:123: error: expected ';' before '*' token
In file included from /dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:48:
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.h:38: warning: 'typedef' was ignored in this declaration
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: 'QCA' has not been declared
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: ISO C++ forbids declaration of 'TLS' with no type
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:119: error: expected ';' before '*' token
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp: In constructor 'ClientStream::Private::Private()':
/dev/shm/tdenetwork/kopete/protocols/groupwise/libgroupwise/gwclientstream.cpp:78: error: 'tls' was not declared in this scope
make[2]: *** [kopete/protocols/groupwise/libgroupwise/CMakeFiles/groupwise-static.dir/gwclientstream.cpp.o] Error 1
make[2]: Leaving directory `/dev/shm/tdenetwork.build'
make[1]: *** [kopete/protocols/groupwise/libgroupwise/CMakeFiles/groupwise-static.dir/all] Error 2
make[1]: Leaving directory `/dev/shm/tdenetwork.build'
make: *** [all] Error 2
This is a clean build from scratch, against TQt3, just like 6/14. Everything else builds. There are no tdenetwork patches in the last 18 hours.
tdenetwork will build with the following:
-DBUILD_KOPETE_PROTOCOL_GROUPWISE=OFF
-DBUILD_KOPETE_PROTOCOL_JABBER=OFF
Darrell
All,
After tweaking the go.svg file a couple of days ago Darrell mentioned that
when rendered in TDE, the svg file showed artifacts which I couldn't explain as
the original inkscape file looked fine. Long story short, I was using konqueror
file manager on a suse box (3.5.10 on opensuse 11.4) and I noticed black
artifacts in an svg file preview. Here is a screenshot of the actual svg file in
inkscape:
http://www.3111skyline.com/dl/dt/trinity/ss/svg-artifact-error-2.jpg
Here is the preview in konqueror (3.5.10)
http://www.3111skyline.com/dl/dt/trinity/ss/svg-artifact-error-1.jpg
The svg file had a black fill on the rectangle below the image, so I changed
it to white to see if that made any difference on the artifact -- it didn't.
Here is a link to the svg file itself:
http://www.3111skyline.com/dl/dt/trinity/ss/firstTest.svg
So, it looks like there is something that KDE did not handle correctly in svg
preview that now shows up in TDE as well. I have no clue where to go with this,
but I would like to start with asking "Has anyone else seen this type of
artifact with svg files?"
Then "does anybody have any experience working with svg file rendering in
KDE/TDE who would know what part of the code is responsible for generating the
svg previews?"
What say the graphic file format wizards on the list? What is going on in
these images? Is it a svg format change causing problems with old rendering code
or what? Obviously this isn't a blocker type issue, but right now, I don't know
enough about it to author an intelligent bug report...
--
David C. Rankin, J.D.,P.E.
