Bug 1853469

Summary: Tar fails to build due to `make check` errors on i686
Product: [Fedora] Fedora Reporter: Stephen Gallagher <sgallagh>
Component: tarAssignee: Pavel Raiskup <praiskup>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: rawhideCC: kdudka, mmathesi, odubaj, ovasik, pkubat, praiskup
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: tar-1.32-5.fc32 tar-1.32-3.fc31 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-16 01:14:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Stephen Gallagher 2020-07-02 18:37:44 UTC
Description of problem:
Attempting to build `tar` on Rawhide fails on i686 with a test error.

Version-Release number of selected component (if applicable):
tar-1.32-4.fc33


How reproducible:
Every time


Steps to Reproduce:
1. `fedpkg clone tar`
2. `fedpkg scratch-build --arch=i686`

Actual results:
The build fails with an error on sptrdiff01.at. The comparison fails, returning the error "Contents differ" rather than the expected "Size differs".


Expected results:
The tests should pass.

Additional info:
We discovered this while trying to build for ELN and then determined it's a problem for Rawhide as well.

Comment 1 Ondrej Dubaj 2020-07-03 05:38:11 UTC
Investigating the problem

Comment 2 Ondrej Dubaj 2020-07-03 06:44:43 UTC
I have problem reproducing the problem outside koji (neither copr nor mock work), investigating other options

Comment 3 Pavel Raiskup 2020-07-03 07:12:12 UTC
Is this 100% reproducible?  Sounds like:
https://src.fedoraproject.org/rpms/tar/pull-request/6

Comment 4 Ondrej Dubaj 2020-07-03 07:31:21 UTC
(In reply to Pavel Raiskup from comment #3)
> Is this 100% reproducible?  Sounds like:
> https://src.fedoraproject.org/rpms/tar/pull-request/6

That patch seems to be already applied

https://src.fedoraproject.org/rpms/tar/c/4d2c3f08a9598a3251d54615feda9730952a2ff0?branch=master

Comment 5 Pavel Raiskup 2020-07-03 08:05:20 UTC
As I wrote in the pull-request, the commit is probably wrong, despite
the fact it was applied.

Comment 6 Merlin Mathesius 2020-07-08 18:38:35 UTC
Is there any progress towards a resolution for this? 'tar' is used rather extensively...

Comment 7 Pavel Raiskup 2020-07-08 19:04:06 UTC
(In reply to Merlin Mathesius from comment #6)
> Is there any progress towards a resolution for this? 'tar' is used rather
> extensively...

Do you mean it is "built" rather extensively?  This just looks like a wrongly
written test case.

Comment 8 Stephen Gallagher 2020-07-08 19:44:02 UTC
The build is broken on Rawhide and Fedora ELN, the latter of which we are trying to bootstrap right now.

I don't think it's a race condition, as I've been able to hit it 100% of the time.

Comment 9 Pavel Raiskup 2020-07-08 21:28:28 UTC
I tested now on my F32 with `mock -r fedora-rawhide-i386`, and the test passed.
Can we get more info about how to reproduce this?  It's good to hear that this is
finally reproducible.

Comment 10 Stephen Gallagher 2020-07-09 14:17:40 UTC
(In reply to Pavel Raiskup from comment #9)
> I tested now on my F32 with `mock -r fedora-rawhide-i386`, and the test
> passed.
> Can we get more info about how to reproduce this?  It's good to hear that
> this is
> finally reproducible.

I can reproduce it 100% of the time on my bare-metal F32 x86_64 system doing `fedpkg mockbuild --mock-config fedora-rawhide-i386`. However, when I try to run it in an F32 VM, I have a 0% reproduction rate.

That lends support to it being a race of some sort; the virtualization overhead appears to be enough to avoid the issue.

Comment 11 Pavel Raiskup 2020-07-09 14:35:24 UTC
Do you think we could get access to the affected machine?

Comment 12 Pavel Raiskup 2020-07-09 19:35:50 UTC
Indeed, a bug.  Thank you Stephen for pigning to me, I previously did
something wrong when I tried to reproduce this.  Upstream proposal:
https://www.mail-archive.com/bug-tar@gnu.org/msg05865.html

Comment 13 Fedora Update System 2020-07-13 07:41:14 UTC
FEDORA-2020-4567712788 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-4567712788

Comment 14 Fedora Update System 2020-07-13 07:41:14 UTC
FEDORA-2020-5065730d4d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5065730d4d

Comment 15 Fedora Update System 2020-07-14 01:07:08 UTC
FEDORA-2020-5065730d4d has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-5065730d4d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5065730d4d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 16 Fedora Update System 2020-07-14 01:09:02 UTC
FEDORA-2020-4567712788 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-4567712788`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4567712788

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 17 Fedora Update System 2020-07-16 01:14:33 UTC
FEDORA-2020-5065730d4d has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 18 Fedora Update System 2020-07-28 15:01:19 UTC
FEDORA-2020-4567712788 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.