tde-devels

devels@trinitydesktop.org

9 participants
3817 discussions

nightly builds for Wheezy
by Greg Madden 02 Feb '13

02 Feb '13

How can I find out when the nightly builds are ready for use ? I am testing these on Wheezy, not usable as of today, we were warned (thanks), just want to get back to testing when appropriate. Thank You -- Peace, Greg

1 0

Re: [trinity-devel] Commit page
by Darrell Anderson 29 Jan '13

29 Jan '13

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

2 1

Help about installation
by Jean Milot 29 Jan '13

29 Jan '13

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

2 1

Commit page
by Darrell Anderson 29 Jan '13

29 Jan '13

The commits web page has not updated in many days. Yet again. Darrell

2 1

broken nightlies?
by Calvin Morrison 27 Jan '13

27 Jan '13

Hey, just upgraded my box and tdm and starttde both failed. What gives? Calvin

2 2

Potential risk of delays due to DNS in twin
by Slávek Banko 26 Jan '13

26 Jan '13

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 --

4 4

Fwd: Porting Trinity to FreeBSD
by Timothy Pearson 26 Jan '13

26 Jan '13

====================================================================== 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.

2 2

kdm_greet using lots and lots of CPU
by russell＠lls.lls.com 25 Jan '13

25 Jan '13

[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 | --------------------------------------------------------------------

3 5

Decade Old KDE Bug Fixed
by Slávek Banko 21 Jan '13

21 Jan '13

Hi everyone, FYI - an interesting bug and one-line fix: http://paritynews.com/software/item/569-decade-old-kde-bug-fixed ...patch I have already backported into TDE. Slavek --

2 3

Re: Re: [trinity-devel] Standalone build of KWin
by Darrell Anderson 20 Jan '13

20 Jan '13

>I recently took some time to evaluate kwin on a TDE system. The >kwin developers have done excellent work; kwin itself operates well and >the configuration dialogs are relatively sane compared to most modern >offerings. At this point I agree with Martin that TDE should be >looking at using kwin as a default instead of our old twin fork as soon as >possible. > >I have put together an Etherpad >(http://trinity.etherpad.trinitydesktop.org/61) detailing the >changes that need to occur before this can be done. Both TDE and kwin will >need some modification to ensure that TDE doesn't lose features after the >migration is complete. Based on the etherpad notes, this sounds like a post R14 goal. As twin->kwin is a significant transition, I'm guessing R15? Darrell

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels