Master Regression Tests Failing

Tom Kent

9 Oct 2017 9 Oct '17

3:26 p.m.

It appears that we haven't had any successful runs of the regression tests on master since last Friday afternoon. Looking at some logs, I'm seeing output like below. Any ideas? Tom notice: [lzma] Condition /var/boost/run/boost_bb/src/build/feature.jam:140: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "pthread" "win32" : "propagated" /var/boost/run/boost_root/libs/thread/build/Jamfile.v2:151: in modules.load from module Jamfile /var/boost/run/boost_bb/src/build/project.jam:325: in load-jamfile from module project /var/boost/run/boost_bb/src/build/project.jam:64: in load from module project /var/boost/run/boost_bb/src/build/project.jam:89: in load-used-projects from module project /var/boost/run/boost_bb/src/build/project.jam:75: in load from module project /var/boost/run/boost_bb/src/build/project.jam:89: in load-used-projects from module project /var/boost/run/boost_bb/src/build/project.jam:75: in load from module project /var/boost/run/boost_bb/src/build/project.jam:113: in load-parent from module project /var/boost/run/boost_bb/src/build/project.jam:464: in initialize from module project /var/boost/run/boost_bb/src/build/project.jam:306: in load-jamfile from module project /var/boost/run/boost_bb/src/build/project.jam:64: in load from module project /var/boost/run/boost_bb/src/build/project.jam:145: in project.find from module project /var/boost/run/boost_bb/src/build-system.jam:535: in load from module build-system /var/boost/run/boost_bb/src/kernel/modules.jam:295: in import from module modules /var/boost/run/boost_bb/src/kernel/bootstrap.jam:139: in boost-build from module /var/boost/run/boost_regression/boost-build.jam:57: in module scope from module # Searching for "process_jam_log" in "/var/boost/run/boost_regression/stage/bin"... Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "/var/boost/run/boost_regression_src/regression.py", line 287, in __init__ self.main() File "/var/boost/run/boost_regression_src/regression.py", line 624, in main getattr(self,action_m)() File "/var/boost/run/boost_regression_src/regression.py", line 581, in command_regression self.command_setup() File "/var/boost/run/boost_regression_src/regression.py", line 352, in command_setup self.build_if_needed(self.process_jam_log,self.pjl_toolset) File "/var/boost/run/boost_regression_src/regression.py", line 715, in build_if_needed tool[ 'build_path' ] = self.tool_path( tool ) File "/var/boost/run/boost_regression_src/regression.py", line 740, in tool_path , '\n'.join( [ name_or_spec[ 'path' ], build_dir ] ) Exception: Cannot find "process_jam_log" in any of the following locations: /var/boost/run/boost_regression/stage/bin/process_jam_log /var/boost/run/boost_regression/stage/bin

Show replies by date

Peter Dimov

9 Oct 9 Oct

3:45 p.m.

Tom Kent wrote:

...

It appears that we haven't had any successful runs of the regression tests on master since last Friday afternoon. Looking at some logs, I'm seeing output like below. Any ideas? ... notice: [lzma] Condition /var/boost/run/boost_bb/src/build/feature.jam:140: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "pthread" "win32" : "propagated"

Looks like you're using the develop Boost.Build. It contains a change that requires two other corresponding patches, to Thread and the superproject.

Tom Kent

10:20 p.m.

On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:

...

Tom Kent wrote:

...
It appears that we haven't had any successful runs of the regression tests on master since last Friday afternoon. Looking at some logs, I'm seeing output like below. Any ideas?

...

...
notice: [lzma] Condition /var/boost/run/boost_bb/src/build/feature.jam:140: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "pthread" "win32" : "propagated"

Looks like you're using the develop Boost.Build. It contains a change that requires two other corresponding patches, to Thread and the superproject.

Can we back out this change until we can figure out a way to do it where it doesn't break our regression suite? I don't believe there is a way to specify that the master tests use the master version of build, If I recall, a long time ago, we decided to use a separate version of build for the regression tests, instead of the one tied from the superproject? Is this just the head of develop? Does anyone remember the rationale for this? Tom

Peter Dimov

10:35 p.m.

Tom Kent wrote:

...

I don't believe there is a way to specify that the master tests use the master version of build, If I recall, a long time ago, we decided to use a separate version of build for the regression tests, instead of the one tied from the superproject? Is this just the head of develop?

Yes, regression.py seems to always use Boost.Build from develop. https://github.com/boostorg/regression/blob/develop/testing/src/regression.p... https://github.com/boostorg/regression/blob/develop/testing/src/regression.p... No idea why.

Steven Watanabe

11:57 p.m.

AMDG On 10/09/2017 04:35 PM, Peter Dimov via Boost wrote:

...

Tom Kent wrote:

...
I don't believe there is a way to specify that the master tests use the master version of build, If I recall, a long time ago, we decided to use a separate version of build for the regression tests, instead of the one tied from the superproject? Is this just the head of develop?

Yes, regression.py seems to always use Boost.Build from develop.

https://github.com/boostorg/regression/blob/develop/testing/src/regression.p...

https://github.com/boostorg/regression/blob/develop/testing/src/regression.p...

No idea why.

I think it was the result of a misunderstanding. Vladimir (?) argued that we should use develop Boost.Build for the develop regression tests and somehow this was interpreted as use Boost.Build from develop for all regression tests. In Christ, Steven Watanabe

Robert Ramey

11:09 p.m.

On 10/9/17 3:20 PM, Tom Kent via Boost wrote:

...

On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost < Can we back out this change until we can figure out a way to do it where it doesn't break our regression suite?

I don't believe there is a way to specify that the master tests use the master version of build, If I recall, a long time ago, we decided to use a separate version of build for the regression tests, instead of the one tied from the superproject? Is this just the head of develop? Does anyone remember the rationale for this?

Cant we just use the master version of boost build for ALL the testing - master and develop branch? Does it make sense to use an experimental version of the test tools to test anything? Robert Ramey

...

Tom

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Edward Diener

11:15 p.m.

On 10/9/2017 7:09 PM, Robert Ramey via Boost wrote:

...

On 10/9/17 3:20 PM, Tom Kent via Boost wrote:

...
On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost < Can we back out this change until we can figure out a way to do it where it doesn't break our regression suite?

I don't believe there is a way to specify that the master tests use the master version of build, If I recall, a long time ago, we decided to use a separate version of build for the regression tests, instead of the one tied from the superproject? Is this just the head of develop? Does anyone remember the rationale for this?

Cant we just use the master version of boost build for ALL the testing - master and develop branch? Does it make sense to use an experimental version of the test tools to test anything?

Am I the only one who thinks it logical that a regression test for 'master' should use the 'master' branch of everything and the regression test for 'develop' should use the 'develop' branch of everything ? Why is this even going to be debated ? I have no idea why the 'master' branch uses the 'devlop' branch of Boost Build, but that does not seem like it can ever be right.

...

Robert Ramey

...
Tom

Tom Kent

11:26 p.m.

On Mon, Oct 9, 2017 at 6:15 PM, Edward Diener via Boost < boost@lists.boost.org> wrote:

...

On 10/9/2017 7:09 PM, Robert Ramey via Boost wrote:

...
On 10/9/17 3:20 PM, Tom Kent via Boost wrote:

...
On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost < Can we back out this change until we can figure out a way to do it where it doesn't break our regression suite?

I don't believe there is a way to specify that the master tests use the master version of build, If I recall, a long time ago, we decided to use a separate version of build for the regression tests, instead of the one tied from the superproject? Is this just the head of develop? Does anyone remember the rationale for this?

Cant we just use the master version of boost build for ALL the testing - master and develop branch? Does it make sense to use an experimental version of the test tools to test anything?

Am I the only one who thinks it logical that a regression test for 'master' should use the 'master' branch of everything and the regression test for 'develop' should use the 'develop' branch of everything ? Why is this even going to be debated ? I have no idea why the 'master' branch uses the 'devlop' branch of Boost Build, but that does not seem like it can ever be right.

To be fair, I believe the failure wasn't in building boost but in building the jam log processor, so it does make sense to disconnect that from the boost->build relationship. I really feel like we've had this conversation before, and there was a good reason to set it up like this. Unfortunately I can't find the chain on that. Regardless, it seems like having the defaults in boost build be something that depends on a specific feature in boost is too aggressive. Would it be possible to put this feature on some kind of flag (default off) until the features it depends on have been in master for a while? Is this something that could hit other users of boost build who may be using it for non-boost builds? Tom

Peter Dimov

11:32 p.m.

Tom Kent wrote:

...

Would it be possible to put this feature on some kind of flag (default off) until the features it depends on have been in master for a while?

Not in this case. There are three interlocked changes (to Build, to Thread, to the superproject) that need to be applied at the same time. Applying any of these in isolation breaks everything. Using master for master testing seems just common sense, although there's probably a reason things are done the way they are.

Vicente J. Botet Escriba

10 Oct 10 Oct

2:28 a.m.

Le 10/10/2017 à 01:32, Peter Dimov via Boost a écrit :

...

Tom Kent wrote:

...
Would it be possible to put this feature on some kind of flag (default off) until the features it depends on have been in master for a while?

Not in this case. There are three interlocked changes (to Build, to Thread, to the superproject) that need to be applied at the same time. Applying any of these in isolation breaks everything.

Using master for master testing seems just common sense, although there's probably a reason things are done the way they are.

Peter, let me know when I should merge Boost.Thread to master. Best, Vicente

James E. King, III

4:05 a.m.

On Mon, Oct 9, 2017 at 7:15 PM, Edward Diener via Boost < boost@lists.boost.org> wrote:

...

On 10/9/2017 7:09 PM, Robert Ramey via Boost wrote:

...
On 10/9/17 3:20 PM, Tom Kent via Boost wrote:

...
On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost < Can we back out this change until we can figure out a way to do it where it doesn't break our regression suite?

I don't believe there is a way to specify that the master tests use the master version of build, If I recall, a long time ago, we decided to use a separate version of build for the regression tests, instead of the one tied from the superproject? Is this just the head of develop? Does anyone remember the rationale for this?

Cant we just use the master version of boost build for ALL the testing - master and develop branch? Does it make sense to use an experimental version of the test tools to test anything?

Am I the only one who thinks it logical that a regression test for 'master' should use the 'master' branch of everything and the regression test for 'develop' should use the 'develop' branch of everything ? Why is this even going to be debated ? I have no idea why the 'master' branch uses the 'devlop' branch of Boost Build, but that does not seem like it can ever be right.

I agree with Edward on this one. That is how I would set it up. - Jim

Stefan Seefeld

4:47 a.m.

On 09.10.2017 19:15, Edward Diener via Boost wrote:

...

On 10/9/2017 7:09 PM, Robert Ramey via Boost wrote:

...
On 10/9/17 3:20 PM, Tom Kent via Boost wrote:

...
On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost < Can we back out this change until we can figure out a way to do it where it doesn't break our regression suite?

I don't believe there is a way to specify that the master tests use the master version of build, If I recall, a long time ago, we decided to use a separate version of build for the regression tests, instead of the one tied from the superproject? Is this just the head of develop? Does anyone remember the rationale for this?

Cant we just use the master version of boost build for ALL the testing - master and develop branch? Does it make sense to use an experimental version of the test tools to test anything?

Am I the only one who thinks it logical that a regression test for 'master' should use the 'master' branch of everything and the regression test for 'develop' should use the 'develop' branch of everything ? Why is this even going to be debated ? I have no idea why the 'master' branch uses the 'devlop' branch of Boost Build, but that does not seem like it can ever be right.

Indeed. Though, I agree with Robert and would go one step further: Given that the things under development are the boost libraries, not the tools used to build and test them, I would prefer to use a stable Boost.Build release, even when building and testing Boost's "develop" branch. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Robert Ramey

4:59 a.m.

On 10/9/17 9:47 PM, Stefan Seefeld via Boost wrote:

...

Indeed. Though, I agree with Robert and would go one step further: Given that the things under development are the boost libraries, not the tools used to build and test them, I would prefer to use a stable Boost.Build release, even when building and testing Boost's "develop" branch.

LOL - I go even further. On my local system I a) clone the boost master branch b) build boost tools, etc .... c) pull the boost serialization library or any library I'm working on d) switch the library under test (ie the serialization library in this case to the develop branch e) move the serialization/test directory f) run b2 with all the switches Now I'm testing my local develop version against everything else on the master. Now I know that a) any errors are my own and not some artifact from someone elses work on the develop branch. b) When I merge my develop branch to the master, I am almost sure to not have any errors when the master branch tests are run. Makes my life much, much simpler. And best of all, I don't have to convince anyone else to go along. I can just do it in the privacy of my own home and no one is the wiser. Robert Ramey

Peter Dimov

9 Oct 9 Oct

11:19 p.m.

Robert Ramey wrote:

...

Cant we just use the master version of boost build for ALL the testing - master and develop branch?

This will break in the opposite way, when the develop library Jamfiles use develop build features that aren't present on master.

Robert Ramey

10 Oct 10 Oct

1:34 a.m.

On 10/9/17 4:19 PM, Peter Dimov via Boost wrote:

...

Robert Ramey wrote:

...
Cant we just use the master version of boost build for ALL the testing - master and develop branch?

This will break in the opposite way, when the develop library Jamfiles use develop build features that aren't present on master.

Hmmm - you mean the develop branch has more features than the master branch?

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Rene Rivera

2:48 p.m.

On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:

...

Tom Kent wrote:

...
It appears that we haven't had any successful runs of the regression tests on master since last Friday afternoon. Looking at some logs, I'm seeing output like below. Any ideas?

...

...
notice: [lzma] Condition /var/boost/run/boost_bb/src/build/feature.jam:140: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "pthread" "win32" : "propagated"

Looks like you're using the develop Boost.Build. It contains a change that requires two other corresponding patches, to Thread and the superproject.

I change B2 so that it avoids the error. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Vicente J. Botet Escriba

6 p.m.

Le 10/10/2017 à 16:48, Rene Rivera via Boost a écrit :

...

On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:

...
Tom Kent wrote:

...
It appears that we haven't had any successful runs of the regression tests on master since last Friday afternoon. Looking at some logs, I'm seeing output like below. Any ideas?

...

...
notice: [lzma] Condition /var/boost/run/boost_bb/src/build/feature.jam:140: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "pthread" "win32" : "propagated"

Looks like you're using the develop Boost.Build. It contains a change that requires two other corresponding patches, to Thread and the superproject.

I change B2 so that it avoids the error.

Did you mean Rene that we don't need to merge the 3 changes on Build, Boost and Thread? Vicente

Rene Rivera

6:23 p.m.

On Tue, Oct 10, 2017 at 1:00 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:

...

Le 10/10/2017 à 16:48, Rene Rivera via Boost a écrit :

On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost wrote:

Tom Kent wrote:

It appears that we haven't had any successful runs of the regression tests on master since last Friday afternoon. Looking at some logs, I'm seeing output like below. Any ideas?

...

notice: [lzma] Condition /var/boost/run/boost_bb/src/build/feature.jam:140: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "pthread" "win32" : "propagated"

Looks like you're using the develop Boost.Build. It contains a change that requires two other corresponding patches, to Thread and the superproject.

I change B2 so that it avoids the error.

Did you mean Rene that we don't need to merge the 3 changes on Build, Boost and Thread?

Correct. The master testing can use the current develop B2. But obviously merging those others will need to be coordinated. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Vicente J. Botet Escriba

11 Oct 11 Oct

6:26 a.m.

Le 10/10/2017 à 20:23, Rene Rivera via Boost a écrit :

...

On Tue, Oct 10, 2017 at 1:00 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:

...
Le 10/10/2017 à 16:48, Rene Rivera via Boost a écrit :

On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost wrote:

Tom Kent wrote:

It appears that we haven't had any successful runs of the regression tests on master since last Friday afternoon. Looking at some logs, I'm seeing output like below. Any ideas?

...

notice: [lzma] Condition /var/boost/run/boost_bb/src/build/feature.jam:140: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "pthread" "win32" : "propagated"

Looks like you're using the develop Boost.Build. It contains a change that requires two other corresponding patches, to Thread and the superproject.

I change B2 so that it avoids the error.

Did you mean Rene that we don't need to merge the 3 changes on Build, Boost and Thread?

Correct. The master testing can use the current develop B2. But obviously merging those others will need to be coordinated.

Rene, it seems the develop branch is broken now. https://s3.amazonaws.com/archive.travis-ci.org/jobs/286174190/log.txt?X-Amz-Expires=29&X-Amz-Date=20171011T062304Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20171011/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=b583d978a3467ef38a48039024e554307f9f77af0cde554315902129fbdc94b7 https://ci.appveyor.com/project/viboes/thread/build/1.0.141-feature/timespec... Have you changed something in develop? Best, Vicente

Vicente J. Botet Escriba

7:15 a.m.

Le 11/10/2017 à 08:26, Vicente J. Botet Escriba a écrit :

...

Le 10/10/2017 à 20:23, Rene Rivera via Boost a écrit :

...
On Tue, Oct 10, 2017 at 1:00 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:

...
Le 10/10/2017 à 16:48, Rene Rivera via Boost a écrit :

On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost wrote:

Tom Kent wrote:

It appears that we haven't had any successful runs of the regression tests on master since last Friday afternoon. Looking at some logs, I'm seeing output like below. Any ideas?

...

notice: [lzma] Condition /var/boost/run/boost_bb/src/build/feature.jam:140: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "threadapi" : "pthread" "win32" : "propagated"

Looks like you're using the develop Boost.Build. It contains a change that requires two other corresponding patches, to Thread and the superproject.

I change B2 so that it avoids the error.

Did you mean Rene that we don't need to merge the 3 changes on Build, Boost and Thread?

Correct. The master testing can use the current develop B2. But obviously merging those others will need to be coordinated.

Rene, it seems the develop branch is broken now.

https://s3.amazonaws.com/archive.travis-ci.org/jobs/286174190/log.txt?X-Amz-Expires=29&X-Amz-Date=20171011T062304Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20171011/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=b583d978a3467ef38a48039024e554307f9f77af0cde554315902129fbdc94b7

https://ci.appveyor.com/project/viboes/thread/build/1.0.141-feature/timespec...

Have you changed something in develop? Sorry, I believe this PR was related to develop, and it was for the branch timespec_clocks, which is not yet synchronized with develop :(

Best, Vicente

2603

Age (days ago)

2605

Last active (days ago)

List overview

Download

19 comments

9 participants

participants (9)

Edward Diener
James E. King, III
Peter Dimov
Rene Rivera
Robert Ramey
Stefan Seefeld
Steven Watanabe
Tom Kent
Vicente J. Botet Escriba