Tim,
you have a plan to rename packages kio-apt, kio-locate and
kio-umountwrapper? If so, will be also renamed GIT repositories?
By now kio-apt/debian/rules and kio-umountwrapper/debian/rules in
tde-packaging refer to tdeio-* names, but changelog files still contains
current kio-* names. That's probably wrong, but I do not know what
version is intended as a future right.
Slavek
--
On Tue, 29 Jan 2013 11:21:19 -0600 "Slávek Banko"
<slavek.banko(a)axis.cz> wrote:
>On Tuesday 29 of January 2013 18:04:12 Darrell Anderson wrote:
>> The commits web page has not updated in many days.
>>
>> Yet again.
>>
>> Darrell
>>
>
>And tbottu is not active on IRC :)
What is the status of the recent ABI/API breakage? Is everything
again stable to allow build runs?
Darrell
Hello all,
I would like to install TDE on Debian Squeeze but i want only the minimal
not games , educations , videos .
Thanks for your help.
Sincerely,
Jean
--
MILOT Jean
Tél. : 0659514624
milot.jean(a)gmail.com
Hi all,
I have a problem to discuss:
Before long time I prepared a patch, which is included in the commit 9e3f8a7f.
It was based on a completely broken patch for KDE4 - commit c24ea2b4. Our
patch works correctly, but contains one potential risk - is dependent on DNS
=> on the network delays.
First question is, how big is this risk, because we have a patch incorporated
nearly a year ago and no problems observed. The fact is that if the user will
have a problem with the network, probably will not even be able to open a
remote window. However, this risk actually exists.
In my proposal for the integration of our patch into KDE4 was a risk discussed
by KDE4 team and Martin prepared a solution where the DNS queries is executed
in a separate thread - commit cbb7f575. In comparison with our patch it is
quite big patch. Backport of Martin's patch is hampered by the fact that he
was used QtConcurrent which is included in QT4.7 and higher.
Therefore, I have a question: What next? Martin designed a simple revert our
patch seems to me inappropriate. The second option is to leave our patch
unchanged and also a risk. Third, that someone remakes patch to not use
QtConcurrent (it is beyond my abilities).
Your suggestions?
Thanks for your comments and help
Mentioned commits:
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=c24ea2b4aac214ce29a…http://git.trinitydesktop.org/cgit/tdebase/commit/?id=9e3f8a7f0c9f2ed1125c7…http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=cbb7f5750fe2a3b4916…
Slavek
--
======================================================================
I have forwarded this message to the list at the request of Mikhail T.
======================================================================
Hello!
As you may have heard, FreeBSD stopped maintaining KDE3 ports ("frozen" at
3.5.10) several years ago. Though they are still available (and the binary
packages are still being built for new OS-releases), the maintainers
switched to
KDE4.
I don't need to explain to you, why I do not think, KDE4 is a good
replacement
for KDE3 (my own primary objection was having to redo all customizations in
~/.kde/), so I'd like to explore creating KDE-Trinity ports alongside with
(and
eventually replacing) KDE-3 ones.
Obviously, the effort will be gradual and I'd like to take advantage of as
much
existing stuff as possible. For example, can TQt3 simply replace the Qt3 --
without breaking the existing ports? For that, TQt3 needs to provide the same
q-symbols alongside the new tq-ones...
How about sub-pieces? For example, FreeBSD has for years maintained the
port of
qmake separately from that of the Qt-library -- to avoid having to rebuild
the
tool completely for every minor update to the latter. Other optional
pieces of
Qt3 (such as, for example, database back-ends) also live as separate ports.
If I were to switch (upgrade?) the main library to TQt3, will these
sub-pieces
continue to build and work, or do I have to ensure, ALL Qt3-users (and that's
hundreds of ports today) are switchedat once?
Beyond the (T)Qt3 foundation, can I switch kdelibs3 to Trinity without
/simultaneously/ switching kdebase3, kdenetworks3, and kdegraphics3?
Obviously,
I'd want to eventually switch them all, but it'd be much easier, if I
could do
it piecemeal, rather than all at once...
I'd also like to ask about the "roadmap" -- there is a Trinity-14 project,
which
warns about "breaking backwards compatibility". Does this simply mean
ABI-changes (if API is preserved, this is easy to deal with)? Or will the
dreaded changes to configuration format (stuff already under user's ~/.kde/)
come and bite me again?
Thanks a lot for suggestions. Yours,
-mi
P.S. I see people have reported running Trinity on their FreeBSD machines
already. Please, let me know of any patches or other tricks still (in
3.5.13.1)
necessary to build on the OS. Collaborators and testers would also be
welcome.
[Not sure of the protocol here: should I have posted to Bug 690? or
sent this email?]
3.5.13 kdm_greet eats lots of CPU.
I see this was marked as fixed (Bug 690) and looking at the source of
Slavek's kdm-trinity, I'm using his ppa on wheezy so the version of
kdm-trinity installed is 4:3.5.13-2debian0~pre26+7~wheezy, the patches
for kgreeter.cpp and sakdlg.cc are in place... but the bug's still
there.
It seems worse when a remote display connects but also happens with just
a display on the machine's console.
This is happening on my little laptop test mule (Intel Core 2) and a
larger 16 core server (AMD Opteron).
A few observations:
/tmp/ksocket-global exists and is mode 0644. Curiously it's owned by
what appears to be a random user-id. If I stop kdm, remove the
/tmp/ksocket-global directory and restart kdm it recreates
ksocket-global mode 0644 but owned by user id 1000... as that's the uid
for the kdm_greet process (eh? why is kdm_greet changing its process
uid? kdm is running as root. can't even see setuid being used in the
kfrontend code).
/tmp/ksocket-global is an empty directory.
An strace on kdm_greet shows the following loop:
read(-1, 0xbfcdd300, 2048) = -1 EBADF (Bad file descriptor)
recv(4, 0x993e5f0, 4096, 0) = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 500000}, NULL) = 0
gettimeofday({1358766636, 578738}, NULL) = 0
recv(4, 0x993e5f0, 4096, 0) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1358766636, 578825}, NULL) = 0
select(9, [4 5 8], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1358766636, 578940}, NULL) = 0
read(-1, 0xbfcdd300, 2048) = -1 EBADF (Bad file descriptor)
The read from -1 is obviously wrong.
/var/log/kdm.log contains errors as follows:
>Jan 21 11:17:52 kdm_config[30569] info: Cannot open master configuration file /etc/trinity/kdm/kdmdistrc
<fair enough: it doesn't exist>
>
>X.Org X Server 1.12.4
>Release Date: 2012-08-27
>X Protocol Version 11, Revision 0
>Build Operating System: Linux 2.6.32-5-amd64 i686 Debian
>Current Operating System: Linux lapcat 3.2.32lls-rt48 #2 SMP Wed Dec 12
>10:32:35 GMT 2012 i686
>Kernel command line: BOOT_IMAGE=Linux ro
>root=UUID=7b9e9723-c08f-426c-96a6-4ad9aeee1e5d
>Build Date: 29 November 2012 08:52:43PM
>xorg-server 2:1.12.4-4 (Julien Cristau <jcristau(a)debian.org>)
>Current version of pixman: 0.26.0
> Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
>Markers: (--) probed, (**) from config file, (==) default setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>(==) Log file: "/var/log/Xorg.0.log", Time: Mon Jan 21 11:17:52 2013
>(==) Using system config directory "/usr/share/X11/xorg.conf.d"
>(II) [KMS] Kernel modesetting enabled.
>QWidget::setMinimumSize: The smallest allowed size is (0,0)
>QWidget::setMaximumSize: (unnamed/QDialog) Negative sizes (-1,-1) are not possible
>sh: warning: setlocale: LC_ALL: cannot change locale (en_GB)
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
This file does exist mode 0644 uid root, gid root.
/etc/qt3 is mode 0755, root.root
/etc is 0711, root.root
>QSettings: error creating /tmp/1468675921/.qt
/tmp/1468675921/.qt does exist. Mode 0775, root.root. Nothing in
there though.
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
>QSettings: error creating /tmp/1468675921/.qt
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
>QSettings: error creating /tmp/1468675921/.qt
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
>QSettings: error creating /tmp/1468675921/.qt
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
>QSettings: error creating /tmp/1468675921/.qt
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
>QSettings: error creating /tmp/1468675921/.qt
>QSettings::sync: failed to open '/etc/qt3/qt_plugins_3.3rc.tmp' for writing
I'm very happy to test/debug/try code.
Original Bug Ref: http://bugs.trinitydesktop.org/bugzilla/show_bug.cgi?id=690
--
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 |
--------------------------------------------------------------------
