Tracker for packages failing with dev-util/scons and Python 3.
Usually the error message is "SyntaxError: invalid syntax".
In affected packages SConstruct file should be ported to Python 3.
Reassigning to Matthew since he committed that skipping maintainer completely, and how cleaning up the resulting mess is his responsibility.
We may want to mask this version of scons until a solution is implemented.
One possible workaround would be to utilize python-any-r1 in affected ebuilds to force python2.
I wouldn't call that a workaround but a proper solution. As long as SConstruct files are totally random freeform Python scripts, we're dealing with running Python code that can be compatible with some specific set of implementations.
First, yes I messed up by bumping this package (a major version at that).
That being said, I think the proper workaround would be to add a cap on the scons version pulled in. The actual error seems to be that these consumers can't handle the new scons version.
Now THAT being said, this would have been better added unkeyworded at least, or possibly even masked, given what upstream said about it's readiness for production use.
At the moment I'm traveling so can't (and probably shouldn't) run around adding caps everywhere, but I would like feedback as to the options presented. The 'quickest', and possibly correct one would be to p.mask it for now.
The bug has been referenced in the following commit(s):
Author: Mike Gilbert <email@example.com>
AuthorDate: 2017-11-05 15:12:56 +0000
Commit: Mike Gilbert <firstname.lastname@example.org>
CommitDate: 2017-11-05 15:12:56 +0000
profiles: mask >=dev-util/scons-3.0.0
profiles/package.mask | 5 +++++
1 file changed, 5 insertions(+)}
> The actual error seems to be that these consumers can't handle the new scons version.
I had assumed that invoking scons with python2.7 would resolve the errors, but after testing a couple of packages that does not seem to be the case.
it seems we have now the latest ebuild using scons+python3, should all the bugs be reassigned to their relevant maintainers then? Currently they are all assigned to prometheanfire, then, I am not sure if they will get any attention from their maintainers (I noticed it just now when seeing new bug 661748).
If, on the other hand, that bugs are obsolete, I would simply close then (also this tracker) and probably open a new fresh tracker bug for issues with current scons ebuilds
Feel free to close the bugs. However, QA still needs to deliver a proper lecture to prometheanfire why you don't skip maintainers and testing, and break stuff in the process.
pretty sure I had that lecture
(In reply to Matthew Thode ( prometheanfire ) from comment #9)
> pretty sure I had that lecture
I'm sorry, I must have missed the part where you put any effort into fixing the resulting bugs, or bothered to reply or admit that you've made a mistake.
sorry you missed the show
I suppose it's time to reuse the tracker to start preparing for py2 removal in scons.
Let's link the porting guide: