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