Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
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
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
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?
Tim
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
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?
Tim
I am quite a new entry in the development team, but IMO we should aim to get R14 released as soon as we consider it ready to be released (i.e. as soon as we can fix the few remaining bugs listed in the Etherpad). If we try to fix every problem every time it comes up, we will never get R14 out of the door. So I think we should consider to: 1) get R14 out 2) this problem and any other problem that requires some time to fix or to test should be addressed in R14.1 Just my 2 cents
Michele
On Sunday 08 of December 2013 08:35:14 Timothy Pearson wrote:
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
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?
Tim
I'm afraid that if we wish an official release in early January, now is not enough time for heroics.
If we push the patch into common cmake module, it would result in rebuild almost all packages. For Debian and Ubuntu, this represents 11 supported distributions - all i386 and amd64, 3× armel and 1× armhf. I estimate about 18 days. In case of complications further delay.
With additional time is needed to count due to limited connectivity from master server. Here is complication compared to previous 3.5.13.2, because for 3.5.13.2 is already used package format quilt (source tarballs are common to all Debian / Ubuntu distributions), while the nightly builds still use format native => will significantly larger volume to synchronize the mirrors. Number of supported RPM distributions probably also increase.
Just to remind: git tag for 3.5.13.2 was from 2. June (a few fixes 8. June) and the official release date was 21. July!
Slavek
-
Darrell Anderson -
Michele Calgaro -
Slávek Banko -
Timothy Pearson