I have 14.0.3 installed freshly on Jessie on an AMD Cedar machine 18 months
old. When I try doing anything to access a CD in either of the two DVD
drives, http://fm.no-ip.com/Tmp/Linux/Sound/xsession-errors-jessie-easyst.txt
(includes dmesg tail) shows some sort of audio setup problem seems to be
repeatedly trying and failing. When KsCD triggers this, it gets hung by the
problem. Simply logging out of the session takes an excessive length of time,
and so does attempting to reboot. Holding down CAD produces a long string of
failed to store sound card state messages instead of rebooting, until well
over a minute passes. On reboot, journal recovery occurs. /etc/group seems to
have the required user permission assignments. Aplay works OK on a test .wav
file, and so does normal startup and shutdown system sounds. How can I tell
where the fault lies? Could there be a broken dependency? I don't see any
open bug that seems related.
Output from alsa-info.sh:
http://fm.no-ip.com/Tmp/Linux/Sound/alsa-info-jessie-easyst.txt
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Hi,
I'm looking for a way to test the vcardparser. It looks like there is a
small test utility in tdeabc and tdeac/vcardparser.
tdeabc/vcardparser$ more README.testing
For testing the vcardparser there are some test files and a small testsuite
automatically checking for regressions.
...
...
Now with cmake building in test dir
========
mkdir test && cd test && cmake ..
cd tdeabc/vcardparser
test/tdeabc/vcardparser$ make check
make: *** No rule to make target 'check'. Stop.
cd ..
test/tdeabc$ make check
make: *** No rule to make target 'check'. Stop.
========
but doing the old automake (it does not compile for various reasons)
produces a Makefile in vcardparser that (almost) works
========
cd tdelibs-trinity-14.0.3/tdeabc/vcardparser
make check
make testread testwrite testread2
make[1]: Entering
directory '/opt/software_x64/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/vcardparser'
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../dcop -I../../kjs -I../../tdecore -I../../tdeio/kssl -I../../tdeabc -I../../tdeabc -I../../dcop -I../../libltdl -I../../tdefx -I../../tdecore -I../../tdecore -I../../tdecore/network -I../../tdeui -I../../tdeio -I../../tdeio/tdeio -I../../tdeio/tdefile -I../.. -I/usr/share/tqt3/include -include
tqt.h -I. -I/opt/trinity/include -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/include/tqt -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT
testread.o -MD -MP -MF .deps/testread.Tpo -c -o testread.o testread.cpp
In file included from testread.cpp:33:0:
../../tdeabc/vcardconverter.h:26:23: fatal error: addressee.h: No such file
or directory
#include "addressee.h"
^
compilation terminated.
Makefile:710: recipe for target 'testread.o' failed
make[1]: *** [testread.o] Error 1
make[1]: Leaving
directory '/opt/software_x64/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/vcardparser'
Makefile:840: recipe for target 'check-am' failed
make: *** [check-am] Error 2
========
Furthermore cmake refuses to use the src dir and does not produce usable
Makefile for the test suite
========
tdelibs-trinity-14.0.3$ cmake .
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.28")
CMake Error at cmake/modules/TDEMacros.cmake:24 (message):
#################################################
Please use out-of-source building, like this:
rm /opt/software/KDE/TDE/tdelibs-trinity-14.0.3/CMakeCache.txt
mkdir /tmp/tdelibs.build
cd /tmp/tdelibs.build
cmake /opt/software/KDE/TDE/tdelibs-trinity-14.0.3 [arguments...]
#################################################
Call Stack (most recent call first):
cmake/modules/TDEMacros.cmake:1534 (tde_message_fatal)
CMakeLists.txt:39 (include)
-- Configuring incomplete, errors occurred!
See
also "/opt/software/KDE/TDE/tdelibs-trinity-14.0.3/CMakeFiles/CMakeOutput.log".
========
Let me know what you think about it and should we raise a bug to track and
fix it.
thanks in advance
Hi all,
I noticed one problem regarding the cmake build of libraries with versioning
and tdelfeditor. Tdelfeditor is used not only on file with the appropriate
version, but also on base 'so' file without a version number. However, this
is a symlink to the file with the appropriate version. Use tdelfeditor causes
that instead of this symlink is created a regular file. Results are then two
full 'so' files, which is incorrect. For example, in tdebase (current stable
R14.0.3 Wheezy@amd64):
libkonq.so - size 809232 (package libkonq4-trinity-dev)
libkonq.so.4.2.0 - size 809240 (package libkonq4-trinity)
Solutions should be simple: in the common cmake module run tdelfeditor only on
libraries with the appropriate version and on base files only if the library
is not versioned. In some cases tdelfeditor is used, although library is not
shared == tdelfeditor is started without valid arguments. See proposed patch.
I believe that there is no reason against to push the patch. There will be
only one consequence - the patch causes rebuild almost all packages.
--
Slávek
Hi everybody,
I was thinking about helping by testing TDE on the upcoming Ubuntu release
(16.04). Do you think is useful? Should I test git, the nightly snapshot or
14.0.3? Or all of them?
Cheers,
-- Diego.
I start new thread here to track this phenomenon.
I'm really p*ss*d off, because something is really wrong with that.
Luckily I make backup before playing around and based on my experience from
the past.
So here are my findings - no deeper code analyses yet.
When syncing 220 contacts to empty address book it ended up with only 72 in
the address book (vcf) configured.
This magic number 20 seem to be hardcoded undo steps. So what tdeabc was
doing, is saving couple of contacts and making backup and again and again.
Why the last copy of the vcf file had only 72 is still a mystery, but I
already had some headache with this phenomenon.
I think I'll have a closer look and play with it a bit. Perhaps I'll come up
with some improvement.
I hope I'll be able to reproduce this with the filesync or some test code.
Oh and BTW if one does copy-paste of contact from one address book into
another the encoding/conversion issue gets visible. I'll test the Fat-Zer
patch and get back reporting to the bug we opened.
I now understand what was wrong with opensync as well (haha - obviously
nothing) ... it took me just another 10y to come to the rootcause.
(to be continued)
regards
Hi all,
I now have one version that I would consider working and of preproduction
state.
Next steps
Is someone willing to test it, or how would you proceed in this case?
I do not have cal/carddav accounts or any of the other supported peers.
I have only two phones I could test with - Nokia 5530 and Nokia N9.
It would be interesting to test with other phones, devices, systems etc. -
at least the contacts and the calendar ( which I believe work fine now).
Contacts and Calendar
I tested address book (contacts) and calendar (events) extensively on both
phones.
Todos and Memos (journal)
The 5530 has some strange calendar type, so todo and memo worked only from
phone to TDE, but not v.v. for obvious reason. I am waiting now for some
hints on how to configure (perhaps virtual calendar or special settings).
On the N9 I did not test those extensively. I tested briefly todos and it
works fine. Memos in N9 are TDE/Knotes (see below).
Notes
I also did not implement the classical KDE/TDE notes - but I will soon do so
as this will be helpful for the N9 (and perhaps other phones/systems/peers
too). I have the basic structure and functions, but this goes into a
separate plugin and was not a prio.
Build
As SyncEvolution is using the automake system, the code is integrated into
it. (Not sure if this is of any interest)
Packaging
SyncEvolution is provided by debian main line.
Should the code be pushed there or we could provide a deb package with the
tdepim part from within trinity?
I am not sure if the debian main line will work with it. I had to explicitly
disable some configure options to have it working. What does one do in such
a case? Provide the full package? I would need some help here and
brainstorming as well.
Code availability
Where would you upload the code for testing in this case? What is
the "standard" procedure. I dislike google but have account @sourceforge
Is the latter good to go?
Optimization
There were some good advises from Fat-Zer regarding string encoding, but I
couldn't follow (as my time window is closing now), so I still convert the
TQString into std::string and then assign the content. (One could save some
memory here and there).
valgrind does not complain about the code - it looks clean.
Fun
I had some issue yesterday on the test env (2G mem) where it crashed,
because of memory exhausted. It turned out that opening the log file in
konqueror consumed 1,7G :D ... I was thinking for a moment - come one, you
were just syncing fine until last start of the virutal machine ... WTF
happened, but it was the konqueror and the log file :D
I also didn't follow up with the parseVCard - I'm not sure if it needs to be
handled as a bug - it seems to be left over from the babylonian times, but
someone has to retest and work it out properly and I do not think that I
could spend the time now and take the responsibility.
thanks in advance for your patience and support
regards
Hi all,
I need some help again.
Which is the preferred function to use when creating TQString from
std::string and how can I make sure that I end up with Utf-8.
The thing is that input in std::string can be either UTF-8 or not UTF-8.
What is the standard way of doing this in TDE (TQt)?
I am really confused, because I was looking in some KDE3/TDE code and I see
both used.
My problem is that some older phones would most likely lack UTF and newer
would do only UTF. So how can I make sure to "speak the right language"
with them?
A hint would be appreciated.
regards
Hi
I'm trying to migrate our systems to a 'pure' TDE 14 environment on
Debian Jessie (previously used Wheezy with a TDE and KDE3 mix) and
having real problems porting an old KDE3.5 application (it's a modified
version of kconsole that's needed to run some of our legacy stuff).
I freely admit I don't understand the build process/kde-tde changes and
flailing around with configure/make isn't getting me anywhere apart from
deeper into a hole :-(
Is there anyone on this list that would be willing to port it for me?
If someone can do this, as a form of thank-you, I'll donate $500 to TDE.
PS - I do hope this request/offer won't be regarded as inappropriate and
I will be making my annual-ish donation to TDE regardless of the above.
--
Regards,
Russell
--------------------------------------------------------------------
| Russell Brown | MAIL: russell(a)lls.com PHONE: 01780 471800 |
| Lady Lodge Systems | WWW Work: http://www.lls.com |
| Peterborough, England | WWW Play: http://www.ruffle.me.uk |
--------------------------------------------------------------------
