tde-devels December 2013

devels@trinitydesktop.org

18 participants
106 discussions

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 09 Dec '13

09 Dec '13

>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

1 0

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 09 Dec '13

09 Dec '13

>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

3 3

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 09 Dec '13

09 Dec '13

>Incidentally, proposed patch from Darrell seems to me as a better >solution >than workaroung from Fat-Zer. Darrell's patch looks like the right >response >to change in CMake. My proposed patch was only a conceptual patch. I have not been able to get anything like that proposal to work. One of you cmake experts will have to dazzle us all. :-) Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 09 Dec '13

09 Dec '13

>However, yes, publication time should be shortened - during the building >arm packages >may be published packages for other distributions, that not depend >on arm >packages (for example all Ubuntu versions). Then let's do that? >Sending one announcement after tagging the sources in GIT and then >after every >publishing binary package to me does not seem like a good idea. >Immediately >after announcement users will ask just for binary packages. Please let me clarify. Announcing availability in a press release would be by full package sets, not individual packages. For example, the initial press release would include all of the supported Debian/Ubuntu package sets and any other distro package sets that have been made available, such as those from Francois. The site web page contains the links for those full package sets. After that initial batch of package sets are uploaded and mirrored, and announced, then begin building ARM package sets. When the ARM packages are ready then issue another press release. Likewise with all package sets for other distros. Something like this: 1st press release: ...full package sets are available now for Debian XX, XX, XX; Ubuntu XX, XX, XX; Fedora XX, XX. Build scripts are available for Slackware 14.0. Package sets for ARM are forthcoming. 2nd press release (whenever needed): ...full package sets are now available for ARM; OpenSuse XX, XX, Mageia XX. Build scripts are available for Slackware 13.1, 13.37, and 14.1. 3rd press release (whenever needed): ... The picture I'm trying to paint is we don't wait 18 or more days to start the release cycle. If the Debian and Ubuntu packages build quickly on the build farm, get those prepared first. Then focus on the next wave of package sets. Something like an 80/20 principle: Have 80% of the most needed package sets ready, then with those out of the way, prepare 80% of the remaining 20%. Etc. Darrell

2 1

Re: [trinity-devel] tqt FTBFS: something about TQAssistantClient
by Darrell Anderson 08 Dec '13

08 Dec '13

>4) tdevelop doesn't build and interestingly it is something >related to tqassistantclient. I haven't got the time to look at >that properly yet, but the obvious patch or remaning - >lqassistantclient to -ltqassistantclient is not enough. I will >work on this as soon as I have enough time > >The problems with TQAssistantClient seems to come after commit >5445c25f on Dec 02. I filed bug report 1761 for tdevelop and attached a proposed patch that works for me. Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 08 Dec '13

08 Dec '13

>Just as a word of warning, this would push R14 to January 2014 at >the earliest due to the time required to rebuild the entire package >set for Debian/Ubuntu. I had already filed bug report 1759: http://bugs.trinitydesktop.org/show_bug.cgi?id=1759 cmake_policy(SET CMP0022 OLD) seems like a temporary work-around --- cmake 2.8.12 is here to stay and we might as well adapt sooner rather than later. :-) I just love how upstream changes keep breaking things for everybody downstream.... C'est la vie. Darrell

4 3

Re: [trinity-devel] tqt FTBFS: something about TQAssistantClient
by Darrell Anderson 07 Dec '13

07 Dec '13

>tqt FTBFS with next message: > >x86_64-pc-linux-gnu-g++ -luuid -fno-exceptions -Wl,-O1 -Wl,--as- >needed -o >../../../bin/tqdesigner .obj/release-shared-mt/main.o -L/usr/lib64 >-L/var/tmp/portage/dev-qt/tqt-3.9999/work/tqt-3.9999/lib - >L/usr/X11R6/lib64 >-L/var/tmp/portage/dev-qt/tqt-3.9999/work/tqt-3.9999/lib - >L/usr/lib64 >-ltqtdesignercore -ltqui -ltqassistantclient -luuid -ltqt-mt -lmng >-ljpeg >-lpng -lz -lXi -lXrender -lXrandr -lXcursor -lXinerama -lXft - >lfreetype >-lfontconfig -lXext -lX11 -lm -lSM -lICE -ldl -lpthread >/var/tmp/portage/dev-qt/tqt-3.9999/work/tqt- >3.9999/lib/libtqtdesignercore.a(mainwindow.o): >In function `MainWindow::MainWindow(bool, bool, TQString const&)': >mainwindow.cpp:(.text+0x15bd5): undefined reference to >`TQAssistantClient::TQAssistantClient(TQString const&, TQObject*, >char >const*)' > > >Full Build log is in the attach. There was a bug report the past couple of days and related patch committed. Probably need to update your local source tree? Darrell

2 1

Amarok (x86) fails scanning files whose inode value exceeds "uint32 max value" (XFS/inode64)
by Nicolas Bercher 06 Dec '13

06 Dec '13

Hi, I just submitted a bug report regarding this issue: http://bugs.pearsoncomputing.net/show_bug.cgi?id=1758 Any clue on this? I'm not yet involved in TDE development, but I'd be willing to try to fix this if some people could give me few advices and directions. And basically, I don't want to dig in it if it's a well known fact that such inode64 issues on x86 platforms are not not fixable (in the context of TDE code only). I think I have to start analyzing the scanning code of course and check C types used to handle inode values, if such things occur within Amarok code. Another option might be that the bug lives in an external library that open the files for Amarok. (People might ask me "Why I don't you swich to amd64 distro?" But that is not the question here.) Nicolas

1 0

Re: [trinity-devel] Trinity on older hardware
by Darrell Anderson 05 Dec '13

05 Dec '13

>as further thing to consider, have 3.5.10 and R14 been compiled in >the same configuration (either release-release or debug-debug)? On >some intensive programs I noticed a speed difference ratio or 3-to- >1 between the two. 3-to-1 ratio --- which one was faster? Speaking of debugging, does including the debugging symbols affect run-time operation? I would not think so but on old hardware might that be true? I wonder because now in hindsight I remember I never built or installed the debugging symbols for the 3.5.10 or TDE 3.5.x packages. (I'm still not letting newer versions of X and the kernel off the hook. Just wondering out loud.) Darrell

3 2

Re: [trinity-devel] Trinity on older hardware
by Darrell Anderson 05 Dec '13

05 Dec '13

>Well, you are very much correct on the watts/performance issue, I >look at >it this way. Your average PII/PIII is about as powerful as some >of the >ultra-efficient Arm-based SBC devices now available for Linux >users. If >TDE can run well on PII/PIII hardware, then it will likely run >well on >those very efficient Arm-based systems as well. I don't run the PI and PII all day. I use them because they provide a nice way for corner case testing. For example, a while back I noted problems with the logout status dialog because only the PI or PII would show them. Darrell

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels December 2013