Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#30736 - wt, boost and gcc release cycles

Attached to Project: Community Packages
Opened by Andreas Baumann (andreas_baumann) - Wednesday, 18 July 2012, 06:38 GMT
Last edited by Allan McRae (Allan) - Wednesday, 18 July 2012, 07:28 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



I can't really agree with the release cycles in wt, boost and gcc.

a) wt releases a release candidate (wt-3.2.2rc2)

IMHO the release 3.2.1 should be the official package, wt-rc is something for AUR
(like wt-git). Or the release candidate should remain in testing till really released.

b) gcc 4.7 enables some C++-11 features

This causes a constant clash in '/usr/include/boost/thread/xtime.hpp', 'TIME_UTC'
(this is boost 1.49.0) with the one from the system in '/usr/include/time.h'.
The bug is fixed in boost 1.50.0 by using a different constant 'TIME_UTC_'.

IMHO boost should always be upgraded together with gcc and glibc, because it's
not so much a library but an extension to the C++ compiler. As wt depends on boost,
it should also upgrade together with boost.

Possible solutions: patch for 1.49.0 or releasing boost 1.45.0.

Problems are reproducable if compiling something using boost threads.

This task depends upon

Closed by  Allan McRae (Allan)
Wednesday, 18 July 2012, 07:28 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Not a bug... but two bugs. One bug report for one bug.
Comment by Allan McRae (Allan) - Wednesday, 18 July 2012, 07:28 GMT
One bug report for one bug.

Note boost-1.50 is in [testing] and will be moved soon.

Also, sometimes a RC is needed to fix a security or build issue that is too difficult to back port on its own. Would you prefer a patch be created between the RC and the stable release and applied without bumping there version in the package?