Log attached.
sip, pyqt and pykde are not installed.
Last time I tried and successfully built kdebindings was svn 1175370.
Is there a way I can diff SVNs that I might help troubleshoot?
Darrell
How are messages forwarded to the list? Many times I have sent messages/replies that don't arrive in my mail box for a long, long time and other times the messages appear within seconds.
Currently I have two replies not yet in my mail box, but I already received a reply I sent after those two.
Strange or normal behavior?
Darrell
I was browsing through KControl and selected the Wireless Network module. I later saw the following messages in the xsession-errors log:
QComboBox::setCurrentItem: (protocolCombo) Index 5 out of range
QComboBox::setCurrentItem: (aclCompatibilityCombo) Index 3 out of range
QComboBox::setCurrentItem: (maxProtocolCombo) Index 5 out of range
QComboBox::setCurrentItem: (serverSigningCombo) Index 3 out of range
lo no wireless extensions.
eth0 no wireless extensions.
I don't have wireless configured in any manner. Just a wired connection.
When I selected that module, I received a warning message box four times:
[Sorry - Control Center]
Unable to detect wireless interface.
(OK button)
Four warnings match the number of tabs in the module.
I think that after the user responds to the first message box the remaining three warnings should be quashed.
Unchecking the Autodetect check box does not disable the warning messages.
I don't believe the message warnings add usability value. Possibly a better method would be to provide a message (in each tab of the module) that no connection was detected.
Further, there should be no warning messages if nothing is yet configured.
Second, the QComboBox messages should not appear in the xsession-error messages. The content of those messages indicate some kind of code error, which translates to noise and clutter in the log. Some kind of error trap is needed to quash the messages.
Third, the messages about lo and etho should be prefixed with something like [kcontrol] so users know the source of the messages. Logs are meant to help users, so let's help them. :)
I hope this helps!
Darrell
> Yes. Try reversing the kdelibs patch created by SVN
> revision r1178028
> (you can download the patchfile from the Trinity project
> website per
> usual), rebuilding and reinstalling kdelibs, then attempt
> the kdebindings
> build again.
Okay. Tried the reverse patch. Same failure.
Log attached.
In the short term I can live without python bindings because I can't get pykde to compile, but I should be able to compile kdebindings.
When compiling tqtinterface I see many warning messages like this:
tqimageformatplugin.h:43:35: warning: no newline at end of file
The messages all seem non-fatal, but adding a newline at the end of all those tqt*.h files would clean the build process. :)
Similarly, as previously mentioned a few days ago:
configure: WARNING: You are attempting to compile Trinity without the
Trinity Qt Interface installed. Please install libtqtinterface-dev
and try again!
Seems there should be some kind of simple self-check so that one message does not appear when building tqtinterface. :)
Darrell
I see these types of messages in the xsession log:
Launched ok, pid = 5906
Launched ok, pid = 5930
Launched ok, pid = 5972
Launched ok, pid = 6014
The process IDs are momentary. They are not in the ps list.
At one point I traced the messages to the KControl/Appearances/Style dialog box. I was testing the toolbar grabber handles when I first noticed the messages. Every time I selected the Apply button, one of these messages appeared in the .xsession-errors log.
However, I see the messages without accessing KControl too. The messages seem harmless, but most people do not like mystery messages in their xsession logs. Would be nice if, like we did with the startkde script, the messages provided a prefix or other clue as to exactly what launched a process.
Darrell
Similar to the panel icons, the desktop icons flash and grow momentarily when selected. I don't find any disable option. If the option exists then grab your 2x4 and show me. :)
An option to disable the same behavior was added for panel icons --- and much appreciated!
Probably the same fix as with the panel icons?
Darrell
> Try these items in this order, doing a rebuilding test
> (including
> autogen.sh) after each item:
> 1. Remove all Makefile.in files from all folders in the
> libcarddav-0.6.2
> directory
> 2. Copy over your system's autoconf files:
> cp -Rp <path to your system's libool.m4 file>
> admin/libtool.m4.in
> cp -Rp <path to your system's ltmain.sh file>
> admin/ltmain.sh
> 3. I don't know?
There is no admin directory when I unpack the sources.
I created an admin directory and then copied the libtool files.
The make process failed with the following:
make: admin/Makefile.common: No such file or directory
make: *** No rule to make target `admin/Makefile.common'. Stop.
As there is no admin directory, there is no Makefile.common file.
Unsure, and not knowing exactly what is different with each package, I downloaded libcarddav_0.6.2-0debian3.tar.gz and libcarddav_0.6.2-0debian4.tar.gz.
Same results.
Log attached.
I discovered an annoying bug with /usr/bin/kde-config.
Because I am maintaining multiple KDE desktops in my testing, I am running a simple test to ensure I have the correct startkde script installed.
When I run the test in interactive mode (logged in) the test functions as expected. When I run the test in non-interactive mode, such as in an rc.local or rc.shutdown script, then kde-config misbehaves.
The annoying behavior is creating a .kde* home directory in the top level root directory. The bug is a carry-over from KDE because the same behavior occurs in 3.5.10. The only difference is that the 3.5.10 kde-config creates a /.kde directory while Trinity create /.kde3.
The directory gets get created there because in non-interactive mode the current working directory of a script usually is the top level.
To verify run this little snippet in an rc.local or rc.shutdown script:
/bin/ls -la /
sleep 2
/usr/bin/kde-config --help
/bin/ls -la /
sleep 2
Change the kde-config parameter to --version. Same results. You should see a /.kde3 directory get created.
Temporarily changing directories to /root in the test snippet does not help. Probably because kde-config sees no login name or ID. My only workaround at this point is to run my test snippet and then test for the existence of the new root directory.
The bug will affect anybody who runs kde-config in a script in non-interactive mode.
I believe kde-config is supposed to be informational and not pro-active. Hence, the tool should not presumptively be creating directories.
Darrell
