[1.46.1] Release candidates available
Release candidate files for 1.46.1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers
Hello! I've downloaded http://boost.cowic.de/rc/boost_1_46_1.7z. Unpack it, but command: ./bootstrap.sh --help don't works: ./bootstrap.sh: 210: ./tools/build/v2/engine/src/build.sh: Permission denied Building Boost.Jam with toolset ... Failed to build Boost.Jam After that I've downloaded http://boost.cowic.de/rc/boost_1_46_1.tar.bz2. Unpack - works fine. Compile just now... - Denis
Hello again! Build Boost from http://boost.cowic.de/rc/boost_1_46_1.tar.bz2: # ./bootstrap.sh --prefix=/home/denis/boost_test # ./bjam # ./bjam install Ok. System: Debian Linux x86_64, g++ 4.4.5. - Denis
On Mar 9, 2011, at 8:56 AM, Beman Dawes wrote:
Release candidate files for 1.46.1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
Downloaded, extracted and built successfully (using pre-built bjam) on both darwin (gcc 4.2.1) and clang TOT. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Wed, Mar 9, 2011 at 5:56 PM, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.46.1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
The .tar.bz2 bootstraps and builds (without MPI) successfully on Debian 64bit with g++ 4.5.2. x86_64-linux. Output of ./bjam -j3 --without-mpi is attached. Matus
On Wed, Mar 9, 2011 at 5:56 PM, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.46.1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
The .zip bootstraps and builds OK on Vista 32-bit, with msvc-9.0 The output of .\bjam.exe -j4 is attached Matus
On Wed, Mar 9, 2011 at 5:56 PM, Beman Dawes <bdawes@acm.org> wrote:
Release candidate files for 1.46.1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge. .. and the .tar.gz also bootstraps+builds without errors on Ubuntu 32-bit, with gcc 4.5.1, both with and without --std=c++0x
Matus
On 9 March 2011 16:56, Beman Dawes <bdawes@acm.org> wrote:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
Exception is broken: http://lists.boost.org/boost-testing/2011/03/6821.php I've checked and the tests fail for me as well. It looks like a build file was missed when it was merged. The changes don't look appropriate for a point release, so it might be best to revert it. Daniel
On Wed, Mar 9, 2011 at 6:40 PM, Daniel James <dnljms@gmail.com> wrote:
On 9 March 2011 16:56, Beman Dawes <bdawes@acm.org> wrote:
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
Exception is broken:
http://lists.boost.org/boost-testing/2011/03/6821.php
I've checked and the tests fail for me as well. It looks like a build file was missed when it was merged. The changes don't look appropriate for a point release, so it might be best to revert it.
Daniel, Thanks for catching this! Please go ahead and revert any revisions that you don't think are appropriate. Is it revision 69620 that is causing the problem? --Beman
On 10 March 2011 01:07, Beman Dawes <bdawes@acm.org> wrote:
Please go ahead and revert any revisions that you don't think are appropriate.
It's reverted now. I suspect that Emil wasn't aware that we're in bug fix mode - understandable since there is a lot of noise on this list. I'm reworking the way releases are presented on the site, so I think I'll add something about the current development status as well. That way developers can easily check before merging. Daniel
On 3/10/2011 3:39 PM, Daniel James wrote:
On 10 March 2011 01:07, Beman Dawes <bdawes@acm.org> wrote:
Please go ahead and revert any revisions that you don't think are appropriate.
It's reverted now. I suspect that Emil wasn't aware that we're in bug fix mode - understandable since there is a lot of noise on this list. I'm reworking the way releases are presented on the site, so I think I'll add something about the current development status as well. That way developers can easily check before merging.
I'll use this as another opportunity to advocate for physically locking the release branch when we're gearing up for a release. How many more times do we need to get burned? This was a lucky catch. Next time we might not be so lucky. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Thu, Mar 10, 2011 at 5:30 AM, Eric Niebler <eric@boostpro.com> wrote:
On 3/10/2011 3:39 PM, Daniel James wrote:
On 10 March 2011 01:07, Beman Dawes <bdawes@acm.org> wrote:
Please go ahead and revert any revisions that you don't think are appropriate.
It's reverted now. I suspect that Emil wasn't aware that we're in bug fix mode - understandable since there is a lot of noise on this list. I'm reworking the way releases are presented on the site, so I think I'll add something about the current development status as well. That way developers can easily check before merging.
I'll use this as another opportunity to advocate for physically locking the release branch when we're gearing up for a release. How many more times do we need to get burned? This was a lucky catch. Next time we might not be so lucky.
I'm interested. How would do you see that working? --Beman
On 3/10/2011 8:19 PM, Beman Dawes wrote:
On Thu, Mar 10, 2011 at 5:30 AM, Eric Niebler <eric@boostpro.com> wrote:
I'll use this as another opportunity to advocate for physically locking the release branch when we're gearing up for a release. How many more times do we need to get burned? This was a lucky catch. Next time we might not be so lucky.
I'm interested. How would do you see that working?
How about this: when we're really close to release, the branch is locked so all commits are rejected. When someone wants to merge a fix, they ask permission. The release manager gives that one user commit access for 48 hrs or whatever. The access automatically expires. I don't know if svn allows this kind of work flow. If not, then the branch can be locked and patches given to the release manager, who applies them himself. This is more work for the release manager, though. We'd need an svn expert to chime in. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Thu, Mar 10, 2011 at 7:00 PM, Eric Niebler <eric@boostpro.com> wrote:
On 3/10/2011 8:19 PM, Beman Dawes wrote:
On Thu, Mar 10, 2011 at 5:30 AM, Eric Niebler <eric@boostpro.com> wrote:
I'll use this as another opportunity to advocate for physically locking the release branch when we're gearing up for a release. How many more times do we need to get burned? This was a lucky catch. Next time we might not be so lucky.
I'm interested. How would do you see that working?
How about this: when we're really close to release, the branch is locked so all commits are rejected. When someone wants to merge a fix, they ask permission. The release manager gives that one user commit access for 48 hrs or whatever. The access automatically expires.
I don't know if svn allows this kind of work flow. If not, then the branch can be locked and patches given to the release manager, who applies them himself. This is more work for the release manager, though.
We'd need an svn expert to chime in.
I've proposed this earlier: Add a precommit check, when the release branch is locked, that checks that any commit in the release path has a commit comment that is prefixed with e.g. "Authorized: ". If not, return error and write a description of how to proceed to stderr. The result is that no one commits by mistake, and that everyone can understand what has happened and how to proceed. /$
On 3/10/2011 1:14 PM, Henrik Sundberg wrote:
On Thu, Mar 10, 2011 at 7:00 PM, Eric Niebler<eric@boostpro.com> wrote:
On 3/10/2011 8:19 PM, Beman Dawes wrote:
On Thu, Mar 10, 2011 at 5:30 AM, Eric Niebler<eric@boostpro.com> wrote:
I'll use this as another opportunity to advocate for physically locking the release branch when we're gearing up for a release. How many more times do we need to get burned? This was a lucky catch. Next time we might not be so lucky.
I'm interested. How would do you see that working?
How about this: when we're really close to release, the branch is locked so all commits are rejected. When someone wants to merge a fix, they ask permission. The release manager gives that one user commit access for 48 hrs or whatever. The access automatically expires.
I don't know if svn allows this kind of work flow. If not, then the branch can be locked and patches given to the release manager, who applies them himself. This is more work for the release manager, though.
We'd need an svn expert to chime in.
I've proposed this earlier: Add a precommit check, when the release branch is locked, that checks that any commit in the release path has a commit comment that is prefixed with e.g. "Authorized: ". If not, return error and write a description of how to proceed to stderr.
The result is that no one commits by mistake, and that everyone can understand what has happened and how to proceed.
Seems easy and reasonable. I'd likely make the comment more specific, like the trac comments. Something like: (authorized by beman). That way there's an audit trail. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 3/11/2011 3:39 AM, Rene Rivera wrote:
On 3/10/2011 1:14 PM, Henrik Sundberg wrote:
I've proposed this earlier: Add a precommit check, when the release branch is locked, that checks that any commit in the release path has a commit comment that is prefixed with e.g. "Authorized: ". If not, return error and write a description of how to proceed to stderr.
The result is that no one commits by mistake, and that everyone can understand what has happened and how to proceed.
I like it.
Seems easy and reasonable. I'd likely make the comment more specific, like the trac comments. Something like: (authorized by beman). That way there's an audit trail.
Great. Rene, can I convince you to implement this hook? Beman, once it's impemented, can you add it to your release procedures? -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Thu, Mar 10, 2011 at 11:00 PM, Eric Niebler <eric@boostpro.com> wrote:
On 3/11/2011 3:39 AM, Rene Rivera wrote:
On 3/10/2011 1:14 PM, Henrik Sundberg wrote:
I've proposed this earlier: Add a precommit check, when the release branch is locked, that checks that any commit in the release path has a commit comment that is prefixed with e.g. "Authorized: ". If not, return error and write a description of how to proceed to stderr.
The result is that no one commits by mistake, and that everyone can understand what has happened and how to proceed.
I like it.
Seems easy and reasonable. I'd likely make the comment more specific, like the trac comments. Something like: (authorized by beman). That way there's an audit trail.
Great. Rene, can I convince you to implement this hook? Beman, once it's impemented, can you add it to your release procedures?
Sounds good to me! --Beman
On 3/10/2011 10:00 AM, Eric Niebler wrote:
On 3/10/2011 8:19 PM, Beman Dawes wrote:
I'm interested. How would do you see that working?
How about this: when we're really close to release, the branch is locked so all commits are rejected. When someone wants to merge a fix, they ask permission. The release manager gives that one user commit access for 48 hrs or whatever. The access automatically expires.
I don't know if svn allows this kind of work flow. If not, then the branch can be locked and patches given to the release manager, who applies them himself. This is more work for the release manager, though.
We'd need an svn expert to chime in.
I suspect the simplest would be to set up a pre-commit hook script which calls SVNLOOK and checks the "changed" and the "author" of the commit and only allow those who are authorized to do so. Someone will need to tweak it to add the allowed authors... There are lots of scripts like this around, for example the following is very similar (although it discusses preventing writing to the tags folders): http://stackoverflow.com/questions/464384/svn-pre-commit-hook-for-avoiding-c...
On Thu, Mar 10, 2011 at 3:39 AM, Daniel James <dnljms@gmail.com> wrote:
On 10 March 2011 01:07, Beman Dawes <bdawes@acm.org> wrote:
Please go ahead and revert any revisions that you don't think are appropriate.
It's reverted now.
Thanks! I'm assuming you tested to see that cleared the problem? Starting the build process. It will take two or three hours. --Beman
On 09/03/2011 16:56, Beman Dawes wrote:
Release candidate files for 1.46.1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
Apart from the fact that tools/ still does not build cleanly, it's fine. *sigh* KTC
participants (10)
-
Beman Dawes -
Daniel James -
Denis Shevchenko -
eg -
Eric Niebler -
Henrik Sundberg -
KTC -
Marshall Clow -
Matus Chochlik -
Rene Rivera