After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

What's the reason for the decision not to fix a broken package?
If a broken package isn't worth fixing then, surely it isn't worth maintaining and should be removed?
I notice Honza has suggested this is an easy fix.
I also notice that the fix has been released to fedora since at least fc32

python3-scons-3.1.2-2.fc32.noarch : An Open Source software construction tool
Repo        : fedora32
Matched from:
Provide    : python3-scons = 3.1.2-2.fc32

Thanks

Sorry for closing this, it seems to have been done by mistake -- without making any promise at this point, let's re-open it and try to get it fixed.

Thanks, M

*** Bug 2012212 has been marked as a duplicate of this bug. ***

Hi Morgan,

If we will provide some testing repository with the requested version of scons package, is it possible for you to provide us with some simple test, how to test if this version fixes your issue?

We can't afford to push this change to RHEL without proper testing, hope you understand.

Please let me know at your earliest convenience.

Yay!
Hmm...
Thanks Lukas for your help with this.

When I was reporting this I was building ffado for my somewhat esoteric music server and reproduction system - since then I've moved house and have that particular kit locked up waiting for my next new home...  So, my use case is not operational atm.  However, I do know that I will be coming back to that particular project before too long.

So, I wonder if Jeff Olivier from Bug 2012212 with a more acute and industrial use case might be able to offer a better test bed?  I notice he's on the CC list for this bug.

If Jeff Olivier is unable to help, I could of course just run the build to see if it throws any errors.  Perhaps I should do that anyway, where's the test repo?

(PS hope I've got the Needinfo flags correct.)

We've worked around it in our project with this patch which switches from installing scons with yum to installing it with pip.

https://github.com/daos-stack/daos/pull/7825

All I can say is that it was unstable and it would periodically fail our CentOS 8 builds.   An occasional build would fail with that error but we no longer see it after upgrading to a later version of SCons.   It's not easy to reproduce the issue but it requires building something with SCons (in our case, DAOS) with parallel build.   It occasionally fails with this issue.   The error in question happens during SCons shutdown and after the build is already complete but since it causes SCons to return a non-zero error, it caused problems for our build stability.

I don't really have the cycles to pull out a reproducer.  Since we have a workaround, this is no longer a priority for us.

The repo can be downloaded here: http://brew-task-repos.usersys.redhat.com/repos/scratch/ljavorsk/scons/3.1.2/1.el8/scons-3.1.2-1.el8-scratch.repo

Just add it to the /etc/yum.repos.d/ folder, enable it, and install the scons package.

Please let me know if you can test it, and if so, then in what time frame, because the deadlines are quite close, and if we want to have this version in RHEL-8.6.0, we need to hurry.

I would be able to do this now, but:
$ curl http://brew-task-repos.usersys.redhat.com/repos/scratch/ljavorsk/scons/3.1.2/1.el8/scons-3.1.2-1.el8-scratch.repo
curl: (6) Could not resolve host: brew-task-repos.usersys.redhat.com

So, I'm not sure there's anything at the URL?
Thx

Hi Morgan,

Sorry, I haven't realized you need to be in our domain.

Please download the rpms here: https://ljavorsk.fedorapeople.org/scons/

I've verified that with the updated package scons-3.1.2-1.el8, 3 randomly chosen packages from epel that require scons for building, still build fine:


$> mock -r scons-centos-stream+epel-8-x86_64 --rebuild compat-tolua++-1.0.93-16.fc35.src.rpm | grep -e 'Installing.*python3-scons' -e '^Wrote'
Wrote: /builddir/build/SRPMS/compat-tolua++-1.0.93-16.el8.src.rpm
  Installing       : python3-scons-3.1.2-1.el8.noarch                       3/3 
Wrote: /builddir/build/RPMS/compat-tolua++-1.0.93-16.el8.x86_64.rpm
Wrote: /builddir/build/RPMS/compat-tolua++-devel-1.0.93-16.el8.x86_64.rpm
Wrote: /builddir/build/RPMS/compat-tolua++-debugsource-1.0.93-16.el8.x86_64.rpm
Wrote: /builddir/build/RPMS/compat-tolua++-debuginfo-1.0.93-16.el8.x86_64.rpm
Wrote: /builddir/build/RPMS/compat-tolua++-devel-debuginfo-1.0.93-16.el8.x86_64.rpm


$> mock -r scons-centos-stream+epel-8-x86_64 --rebuild libffado-2.4.4-5.fc35.src.rpm | grep -e 'Installing.*python3-scons' -e '^Wrote'
Wrote: /builddir/build/SRPMS/libffado-2.4.4-5.el8.src.rpm
  Installing       : python3-scons-3.1.2-1.el8.noarch                   280/281 
Wrote: /builddir/build/RPMS/libffado-2.4.4-5.el8.x86_64.rpm
Wrote: /builddir/build/RPMS/libffado-devel-2.4.4-5.el8.x86_64.rpm
Wrote: /builddir/build/RPMS/ffado-2.4.4-5.el8.x86_64.rpm
Wrote: /builddir/build/RPMS/libffado-debugsource-2.4.4-5.el8.x86_64.rpm


$> mock -r scons-centos-stream+epel-8-x86_64 --rebuild libserf-1.3.9-19.fc35.src.rpm | grep -e 'Installing.*python3-scons' -e '^Wrote'
Wrote: /builddir/build/SRPMS/libserf-1.3.9-19.el8.src.rpm
  Installing       : python3-scons-3.1.2-1.el8.noarch                     36/36 
Wrote: /builddir/build/RPMS/libserf-1.3.9-19.el8.x86_64.rpm
Wrote: /builddir/build/RPMS/libserf-devel-1.3.9-19.el8.x86_64.rpm
Wrote: /builddir/build/RPMS/libserf-debugsource-1.3.9-19.el8.x86_64.rpm
Wrote: /builddir/build/RPMS/libserf-debuginfo-1.3.9-19.el8.x86_64.rpm


Marking as pre-verified and also Verified: Devel.

Jakub, feel free to move to VERIFIED if you're ok with this level of verification.

Thanks Honza for stepping in to the breach - my circs have changed since I first reported and it's not easy for me to test at the moment.

Can we please make some progress on this?  We continue to see builds fail with:

scons: *** Found dependency cycle(s):
  Internal Error: no cycle found for node build/dev/gcc/src (<SCons.Node.FS.Dir object at 0x558e97a61908>) in state pending
File "/usr/lib/python3.6/site-packages/SCons/Taskmaster.py", line 1065, in cleanup

This ticket is in the VERIFIED state.  Surely finally getting this landed is not a significant effort still, yes?

Can anyone comment on the viability of moving this forward?  We seem to be hitting this issue more frequently.

@dbayly 
Don can you update us on next steps for this? Thx

Can anyone provide an update here please?  This issue is impacting our builds more and more frequently and therefore impacting productivity and not to mention driving up developer frustration.

The fix for this issue is part of the RHEL-8.6 update. If you need to have the build earlier, there is RHEL-8.6 Beta already available, so while it's not fully supported (scons is part of the unsupported Code-Ready Builder anyway), you might be able to take the builds from there.

This is an OK solution for ad-hoc use by individuals.  It's more difficult to implement in CI systems that build RPMs with mock and so forth as we don't really want to be building them with all of 8.6 Beta.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (scons bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2131

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days