tde-devels

devels@trinitydesktop.org

1 participants
3754 discussions

Re: [trinity-devel] Help! fatal: destination path 'main/applications/ktorrent' already exists and is not an empty directory.

by Darrell Anderson

>With git >= 1.7.8 are submodules cloned into .git/modules and in >submodule folder is only .git file. I'm using git-1.7.12.1, which is what I have been using since I updated to Slackware 14.0 way back in February. I don't understand why all of the sudden everything is exploding. Darrell

11 years, 1 month

Re: [trinity-devel] Help! fatal: destination path 'main/applications/ktorrent' already exists and is not an empty directory.

by Darrell Anderson

>From a certain version of the GIT are ".git" folders of submodules >placed into folder ".git/modules" in the "master" module. Okay, I think I now see what you described. When did this change occur? I have not updated my git package. Why is this now happening only in the past several days? Why am I now receiving all of these fatal messages? How do I stop the messages? The latest fatal is tde-i18n, the biggest pig module of them all. Darrell

11 years, 1 month

Re: [trinity-devel] Help! fatal: destination path 'main/applications/ktorrent' already exists and is not an empty directory.

by Darrell Anderson

>There may be a better and quicker way, but in a case like this I >would do a clean checkout. It takes a few hours, but at least you >can be sure everything is as it should be. How do I do that? My fear is as my local tree continually self-explodes, I am going to end up cloninge the entire tree, which at 4 or 5 GBs will take all damn day. There must be some kind of repair procedure? Darrell

11 years, 1 month

Re: [trinity-devel] Help! fatal: destination path 'main/applications/ktorrent' already exists and is not an empty directory.

by Darrell Anderson

>From a certain version of the GIT are ".git" folders of submodules >placed into folder ".git/modules" in the "master" module. I no longer have any .git folders in any of the affected modules. One by one they are disappearing. Every time I resync a new module is affected. Something got corrupted and the proverbial hell is breaking loose here. :-) I hate git! Darrell

11 years, 1 month

Help! fatal: destination path 'main/applications/ktorrent' already exists and is not an empty directory.

by Darrell Anderson

All, Within the past couple of days I now am getting a lot of these types of messages when I attempt to sync my local tree: fatal: destination path 'main/applications/ktorrent' already exists and is not an empty directory. Thus far the only fix I have found is to delete the entire module and resync. The problem is there is no .git directory in the affected modules. I have no idea how to fix and searching the web is not helping. There seems to be no end to the madness. With each resync a new module is affected. Please help! Darrell

11 years, 1 month

Re: [trinity-devel] Compiling TQt3 with -debug/-release --- reversed?

by Darrell Anderson

>I am noticing a peculiarity when I compile TQt3.... > >Am I doing something wrong or are the -debug/-release configure >options reversed? Never mind. PEBKAC. I was using an environment variable $DEBUG twice in two different places. The two different uses confused the build script --- and confused me too. :-) Darrell

11 years, 1 month

dcop monitor tool

by Fat-Zer

Is there a such tool for DCOP like dbus-monitor for dbus? I'm currently messing with bug 1768 and I wanna find out who (if anybody) calls the logout method of ksmserver. NOTE: I'm a total noob in DCOP as well as in tde initialization system.

11 years, 1 month

Compiling TQt3 with -debug/-release --- reversed?

by Darrell Anderson

All, I am noticing a peculiarity when I compile TQt3. When I compile with the -release option, my final package size is about 35MB (txz). When I compile with the -debug option the final package size is about 13.6 MB. I expected the opposite. When I use -debug the build log is filled with -DQT_NO_DEBUG. When I use -release I do not see -DQT_NO_DEBUG at all in the build log. I expected the opposite. I am presuming -debug means compiling with debugging symbols and - release means do not compile debugging symbols. Here are my build script configure options, where $DEBUG is either - debug or -release: echo "yes" | \ CFLAGS=$CPUOPT \ CXXFLAGS=$CPUOPT \ ./configure \ -v \ -prefix $INSTALL_PREFIX \ -libdir $LIBDIR \ $DEBUG \ -I/usr/include/mysql \ -I/usr/include/freetype2/freetype \ -L/usr/lib${LIBDIRSUFFIX} \ -qt-imgfmt-png \ -qt-imgfmt-mng \ -qt-imgfmt-jpeg \ -qt-gif \ -qt-style-motif \ -system-zlib \ -system-libpng \ -system-libmng \ -system-libjpeg \ -shared \ -no-pch \ -thread \ -stl \ -no-exceptions \ -platform ${PLATFORM} \ -cups \ -ipv6 \ -nis \ -sm \ -largefile \ -xshape \ -xinerama \ -xcursor \ -xrandr \ -xrender \ -tablet \ -xkb \ -xft \ -plugin-imgfmt-mng \ -plugin-sql-mysql \ -plugin-sql-sqlite \ -plugin-style-cde \ -plugin-style-compact \ -plugin-style-motifplus \ -plugin-style-platinum \ -plugin-style-sgi \ -plugin-style-windows \ -lfontconfig \ -inputmethod \ -enable-opengl \ -dlopen-opengl \ $GLIBMAINLOOP \ || exit 1 Am I doing something wrong or are the -debug/-release configure options reversed? Darrell

11 years, 1 month

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES

by Darrell Anderson

>IMO, the better fix would be something like next snip (not tested >yet): >cmake_policy(PUSH) >cmake_policy(SET CMP0022 OLD) >target_link_libraries( ${_target} LINK_INTERFACE_LIBRARIES >${_shared_libs} ) >cmake_policy(POP) I tried this proposed solution with tdelibs. I still saw the CMP0022 output spew. Regardless, this bug needs attention, even if the final patch is not pushed immediately to git for R14. Digging deeper in why tdelibs now FTBFS on my system with cmake 2.8.12, I found this message in the build log: CMake Error: Error evaluating generator expression: $<LINK_ONLY:-Wl,-whole-archive> $<LINK_ONLY> expression requires exactly one parameter. This is the closest related online conversation I found: http://cmake.3232098.n2.nabble.com/cmake-2-8-12-generator- expression-error-when-linker-flags-have-comma-td7585816.html Darrell

11 years, 1 month

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES

by Darrell Anderson

>Part of me says push now, as there are several serious reports >still open >regarding removable disk mounting and handling. On the other hand >are >already starting to lose people to XFCE because the current stable >TDE >version requires HAL and does not work with the latest network- >manager versions. > >Thoughts? Regarding cmake 2.8.12, that is and should be a Blocker bug report - -- but not a blocker for R14. We add a note in the release README (refer to etherpad) that we are aware of the issue and offer packagers a temporary work-around similar to that suggested by Fat- Zer. At least two people should test a formal patch, then we attach the patch to the bug report and reference the bug report in the README. Regarding the delays with rebuilding Debian/Ubuntu packages. The presumption seems open to debate whether all of these package sets have to be built on the Trinity servers. At a pace of 18 days the realization is the servers lack the capacity. Likewise the presumption that all of these package sets must be built --- and mirrored --- before announcing the release. We have so few people participating in development and packaging. I don't know why package sets need to be built on the Trinity servers. Why not by individual participants and then uploaded? Moreso, rather than one bulk release, why not offer package sets progressively as they are built and mirrored? Issue press releases as each package set becomes available --- a simple public relations strategy that keeps Trinity in the news, let alone relieves serious tension and pressure to have all package sets built at one time. The initial press release merely states that additional package sets are forthcoming. If build scripts and tarballs are available in the official release announcement, then others can get involved. Until then serious triage is needed of what to support. Unlike previous releases, the sticky part of R14 is the significant number of renaming and branding changes. As the old adage goes, we only get one chance to create a first impression. We never developed any kind of release test plan. We hobbled along only through feedback by the few of us participating. We've done okay, but for example, we have not performed largescale testing of the r14-xdg-update script. Slavek and I tested but we are only two people with two different usage perspectives. That one script has the potential to destroy first impressions. My personal usage of R14 indicates no serious problems. Yet I don't use every single package nor do I use all apps every day. I'm sure there are hidden bugs as a result of the massive renaming and branding changes. I'm not worried about these types of bugs. My primary concern is not bug reports like cmake 2.8.12, but fundamental desktop usability. The desktop is the sole location where users and reviewers form their first impressions. While long- term Trinity users will tolerate bugs, reviewers and new users will not. Of those types of reports listed in the etherpad, I see the following that should be resolved immediately: 1761 tdevelop FTBFS with recent (t)qassistantclient patches 1759 R14 FTBFS with cmake 2.8.12 --- only test a formal patch providing a temporary work-around 1733 Launcher menu (T-Menu) takes a long time to appear the first time using Alt+F1 1729 KOffice: Applications crash on logout Get those reports resolved and release R14. Long term, as noted, we will never resolve all bug reports in a timely manner. That kind of focus is part of maintenance releases. We establish an etherpad wish list for each maintenance release period. The bugzilla supports voting. Nothing fancy needed here. Short term we focus on triage and develop a reasonable release pace for various distro packages. I believe that after we release R14.0.0, and users migrate from 3.5.x to R14, the bulk of the effort is behind us. We then focus on a maintenance release schedule where we no longer are distracted by the pressure of big announcements and big pushes. With maintenance releases we are able to move along at a steady pace. We just need to get past the big hump now known as R14.0.0. :-) Darrell

11 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels