tde-devels

devels@trinitydesktop.org

1 participants
3754 discussions

Re: [trinity-devel] gtk3-tqt-engine FTBFS (debian/testing) and patch

by Darrell Anderson

>gtk3-tqt-engine FTBFS on debian/testing, complaining that ld can't >find libtdeui. Attached proposed patch. Although I can push patches to git, one of the software gurus will have to review the patch before I can do so. :-) Both Tim and Slavek are Debian users. Darrell

11 years, 4 months

Re: [trinity-devel] My opinion on Trinity project quality

by Darrell Anderson

>Sure, all you mentioned about KDE4 are indeed drawbacks that hold >me >from using it. What I expect to be done for KDE4 is some 'Classic >mode' (like for Windows), that will rip those horrible kid visuals >and >needless daemons. Also merge of window manager features from 3 to >4 is >a must to decide KDE4 more or less serious shell. > >Sorry, I don't want to repeat in details why TDE is wrong. You can >find it in bugs (open and closed) and here on the list by >searching >for my name. > >Figuratively speaking, they try to move a mountain to build a >straight >way through when it is satisfactory to build a road over that >mountain. They will never have enough resources to move the >mountain, >the project will always be half-finished and half-working. In >fact, >all this tremendous work is needless. And moreover, it is even >worse >than this simple image. Moving a mountain is finite job and what >they >do is doom of endless support. They will never have time for real >features and bug-fixes. Moreover, I'm afraid that they will only >make >more bugs. > >Unfortunately, both of these projects KDE4 and TDE hadn't followed >real users expectations. Possibly you have some points of merit, but I don't think anybody here is going to spend time looking through the bug tracker and list archives to find what exactly you are referring. A bullet list of your concerns would be helpful. :-) Trinity is a small project. The people involved have lives. Everybody does their best to keep things moving but that is not always possible. I suspect with free/libre software that users tend to forget that project members are impacted by life. For example, recently I experienced a life-changing event that affects my time involved. I am aware of at least one other Trinity team member who is experiencing similar events. We don't share that information publicly because the events are very much private and personal. Yet family and life takes precedence over software projects. Tomorrow the same could well happen to you. The important point is to bring constructive criticisms to the mail list in a manner that allows for such events. A little sympathy and understanding goes a long way. :-) I use Trinity from Git and have been doing so for more than a year. Yes, bugs exist, I too have filed bug reports (probably more than any Trinity user). We peck away at the reports when we have time. Certianly with the bugs Trinity is not perfect or super polished, but none of the bugs that I have filed reports are show-stoppers. Almost all of the bugs are irritating to one degree or another, but none of the bugs come close to stopping me from using Trinity. I am aware that other people have different use cases and the bugs they report might be more critical. In short, despite the number of total bug reports filed by all people, I find Trinity (Git) remarkably stable. I have used KDE4, as recent as 4.10.2, and found that KDE4 is not without its own set of bugs and usability issues. Between the two desktops, I find Trinity more appealing to my computer usage and the related KDE4 bugs that affect me to be more irritating than those from Trinity. Not to mention I don't relish certain design aspects of KDE4. If I had no choice I could adapt to KDE4, but I'd rather use Trinity. I have tried Xfce as well and find that desktop much less configurable and tunable than either Trinity or KDE4. I have not tried GNOME since the 1.x days because I don't care for the developer culture there. Please help us improve Trinity and our response climate by listing exactly what is troubling you. Possibly some of the bug reports you filed can be bumped in priority for the R14.0.0 release. Darrell

11 years, 4 months

Re: [trinity-devel] qt3 API incompatiblity with qt3 programs

by Darrell Anderson

>What I need to do to run old qt3 programs on 3.5.13? >I need to make some kind of aufs chrooted environment. >Please, provide exact recipe of making it. In the Trinity source tree is a directory named experimental. There are some scripts there to convert KDE3 apps to TDE. Tim and Slavek are better qualified to explain how to use the scripts. We should have a wiki article. I don't know that pure Qt3 apps (rather than KDE3 apps) can be converted with those scripts. I presume the best approach is to install the original Qt3 in your chroot and build the app there. I haven't tinkered with that but as TQt3 normally is installed in /opt/trinity, there should be no conflicts installing the original Qt3 in /usr. I have no idea whether the original Qt3 will conflict with Qt4. Darrell

11 years, 4 months

qt3 API incompatiblity with qt3 programs

by Aleksey Midenkov

What I need to do to run old qt3 programs on 3.5.13? I need to make some kind of aufs chrooted environment. Please, provide exact recipe of making it.

11 years, 4 months

KOffice FTBFS on Jessie

by Slávek Banko

Hello all, Tim, I examined the problem FTBFS KOffice on Jessie. I have found the same problem also with other program from Jessie: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713270 Upon further searching, I found that the problem was caused by patch from reported bug #706181: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706181 When I tried to revert created symlinks, KOffice is built without problems. By the way, on Ubuntu 13.10 (Saucy) is KOffice built without any problems. -- Slavek

11 years, 4 months

Re: [trinity-devel] (More) Possible bugs introduced from latest k->tde patches

by Darrell Anderson

>>Those errors aren't supposed to be something new or related with >>renaming... >>Before patch git hash 5354555 all messages passed to >>kd{Error,Warning} have >>gone nowhere but now they go to stderr by default. >>So, these is old errors, but previously masked. > >Okay, thanks, that explains why I now see the messages when >previously I did not. Commit 5354555 was pushed to git >sufficiently >close to the k->tde renaming patches. I would not have noticed >because I was not updating my local source tree during the period >I helped test the renaming patches with Slavek. I opened bug report 1655 to address any of the new, previously unseen error and warning messages. Darrell

11 years, 5 months

Re: [trinity-devel] (tdesu) Possible bugs introduced from latest k->tde patches

by Darrell Anderson

>It does not matter if you use su or sudo. In tdelibs >CMakeLists.txt >DEFAULT_SUPER_USER_COMMAND is not set to a short name "su" or >"sudo", but the >name with the full path - ie. "/bin/su". And this is then the >reason for this >warning. I rebuilt tdelibs and tdebase with the proposed patches. I did not modify my configure options. The error message no longer appears. Please push the patches to git. :-) Thank you and good work! Darrell

11 years, 5 months

Re: [trinity-devel] (More) Possible bugs introduced from latest k->tde patches

by Darrell Anderson

On Sat, 07 Sep 2013 07:37:23 -0500 "Slávek Banko" <slavek.banko(a)axis.cz> wrote: >On Saturday 07 of September 2013 08:20:12 Darrell Anderson wrote: >> * tdesu: WARNING: unknown super user command > >Test the super user command is a one tdelibs/tdesu/su.cpp a second >time in >tdebase/tdesu/sudlg.spp. Valid is considered "sudo" or "su". > >For tdebase is in tdebase/tdesu/CMakeLists.txt defined: > >if( WITH_SUDO_TDESU_BACKEND ) > set( DEFAULT_SUPER_USER_COMMAND sudo CACHE INTERNAL "" FORCE ) >else() > set( DEFAULT_SUPER_USER_COMMAND su CACHE INTERNAL "" FORCE ) >endif() > >For tdelibs is in tdelibs/CMakeLists.txt defined: > ># FIXME for unknown reason cmake cannot find su >#find_program( __PATH_SU su ) >set( __PATH_SU "/bin/su" ) > >if( __PATH_SU ) > set( DEFAULT_SUPER_USER_COMMAND ${__PATH_SU} ) >else( __PATH_SU ) > message( STATUS "WARNING: su was not found" ) >endif( __PATH_SU ) > ># FIXME for unknown reason cmake cannot find sudo ># find_program( __PATH_SUDO "sudo" ) >set( __PATH_SUDO "/usr/bin/sudo" ) >if( WITH_SUDO_TDESU_BACKEND ) > if( __PATH_SUDO ) > set( DEFAULT_SUPER_USER_COMMAND ${__PATH_SUDO} ) > else( __PATH_SUDO ) > message( FATAL_ERROR "sudo was chosen as tdesu backend, but >was not found >in path." ) > endif( __PATH_SUDO ) >endif( WITH_SUDO_TDESU_BACKEND ) > >In neither case does not test for the presence sudo. And in >tdelibs instead of >setting DEFAULT_SUPER_USER_COMMAND to su or sudo is used full path >to binary, >which is incorrect. > >Proposed patches attached. I build tdelibs and tdebase with WITH_SUDO_TDESU_BACKEND=OFF. The description for that option: "Use sudo as backend for tdesu (default is su)". I always presumed that option was for support for Ubuntu because that distro is hard-wired for sudo. sudo is well supported in Slackware, but the default is for users to use su. Hence my build option decisions. Seems I can trigger the "tdesu: WARNING: unknown super user command" message simply by running tdesu. A snippet from my xsession-error log: [tdeinit] Got EXT_EXEC 'tdesu' from launcher. [tdeinit] tdesu is executable. Launching with exec. [tdeinit] Got EXEC_NEW '/opt/trinity/bin/tdesud' from launcher. [tdeinit] /opt/trinity/bin/tdesud is executable. Launching with exec. tdesu: WARNING: unknown super user command tdesu: WARNING: unknown super user command Will the patches resolve the xsession-error messages with WITH_SUDO_TDESU_BACKEND=OFF? Darrell

11 years, 5 months

Re: [trinity-devel] (More) Possible bugs introduced from latest k->tde patches

by Darrell Anderson

On Sat, 07 Sep 2013 02:47:38 -0500 "Fat-Zer" <fatzer2(a)gmail.com> wrote: >2013/9/7 Darrell Anderson <darrella(a)hushmail.com> > >> Additional xsession-error log messages that might be related to >the >> recent renaming (or they might be isolated bugs): >> >> * tdeio (KIOConnection): ERROR: Header read failed, errno=104 >> >> * tdeio (KIOConnection): ERROR: Header has invalid size (-1) >> >> * tdeio (KIOConnection): ERROR: Could not write data >> >> * tdeio (TDELauncher): ERROR: SlavePool: No communication with >> slave. >> >> * tdecore (TDEProcess): WARNING: _attachPty() 17 >> >> * tdecore (TDEProcess): WARNING: _attachPty() 13 >> >> * tdesu: WARNING: unknown super user command >> >> For consistency, should KIOConnection be renamed to >> TDEIOConnection? Looks like tdelibs is the only affected module, >> although there are some remaining remnant "KIO" usages in >tdelibs, >> tdepim, tdenetwork, tdebase, tdevelop, tdesdk, tde-i18n, >kshowmail, >> krusader, kdirstat, tdeio-apt, tork, digikam. >> >> Darrell >> > >Those errors aren't supposed to be something new or related with >renaming... >Before patch git hash 5354555 all messages passed to >kd{Error,Warning} have >gone nowhere but now they go to stderr by default. >So, these is old errors, but previously masked. Okay, thanks, that explains why I now see the messages when previously I did not. Commit 5354555 was pushed to git sufficiently close to the k->tde renaming patches. I would not have noticed because I was not updating my local source tree during the period I helped test the renaming patches with Slavek. That said, for consistency KIOConnection should be renamed to TDEIOConnection. Whether a WARNING or ERROR, the messages are caused by something not functioning correctly, especially the ERROR messages. I understand that commit 5354555 fixed a long standing problem of certain messages not being exposed but now that we have that fixed we must focus on why the messages are generated. As you shared, the messages were always being generated, which means a problem somewhere, despite the messages never being seen by anyone. At this point I now don't know whether the original three messages I posted are a result of the renaming or a result of commit 5354555 now making those messages available and the bugs actually have existed for a long time and nobody had any way to know. Darrell

11 years, 5 months

opensync FTBFS on debian/testing and patch

by Michele Calgaro

opensync FTBFS on debian/testing. This is another dh_python -> dh_python2 bug. Proposed patch attached. Cheers Michele

11 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels