Bug 1759026
| Summary: | The primary distro-level SWID tag com.redhat.RHEL-8-x86_64.swidtag changed timestamp even if the content did not change | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Jan Pazdziora (Red Hat) <jpazdziora> |
| Component: | redhat-release | Assignee: | Rashmi <rnargund> |
| Status: | CLOSED WONTFIX | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.2 | CC: | jpazdziora, jwboyer, lisas, pkotvan, rnargund |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | 8.2 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-04-07 07:31:34 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
Jan Pazdziora (Red Hat)
2019-10-07 08:42:34 UTC
Thanks Jan for the ping. Moving to QA. To verify this on RHEL-8.2.0-Snapshot-3.0 -> RHEL-8.2.0-20200310.0:
$ find 8.* -type f -name 'com.redhat.RHEL-8-x86_64.swidtag' -exec stat {} \;
File: 8.0/com.redhat.RHEL-8-x86_64.swidtag
Size: 6796 Blocks: 16 IO Block: 4096 regular file
Device: fd03h/64771d Inode: 551976 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ pkotvan) Gid: ( 1000/ pkotvan)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2020-03-12 11:44:47.774294494 +0100
Modify: 2019-03-05 16:44:11.000000000 +0100
Change: 2020-03-09 12:59:44.052604094 +0100
Birth: 2020-03-09 12:59:44.051604083 +0100
File: 8.1/com.redhat.RHEL-8-x86_64.swidtag
Size: 6796 Blocks: 16 IO Block: 4096 regular file
Device: fd03h/64771d Inode: 551994 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ pkotvan) Gid: ( 1000/ pkotvan)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2020-03-12 11:44:52.112359122 +0100
Modify: 2019-09-25 20:17:47.000000000 +0200
Change: 2020-03-09 13:00:12.968922900 +0100
Birth: 2020-03-09 13:00:12.968922900 +0100
File: 8.2/com.redhat.RHEL-8-x86_64.swidtag
Size: 6796 Blocks: 16 IO Block: 4096 regular file
Device: fd03h/64771d Inode: 543568 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ pkotvan) Gid: ( 1000/ pkotvan)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2018-12-11 23:43:45.000000000 +0100
Modify: 2018-12-11 23:43:45.000000000 +0100
Change: 2020-03-12 11:44:43.292227720 +0100
Birth: 2020-03-12 11:44:43.292227720 +0100
As you can see "Modify" times are different every mino version of RHEL-8. Interestingly, RHEL-8.2.0-Snapshot-3.0 Modify time is even before the times for RHEL-8.1.0 and RHEL-8.0.0 (Modify: 2018-12-11 23:43:45.000000000 +0100).
The expected modify time on RHEL-8.2.0 is Modify: 2019-03-05 21:14:11.000000000 +0530, as specified in the bug description.
Moving back to ASSIGNED.
The Modify: 2018-12-11 23:43:45.000000000 +0100 is the correct value that we tried to achieve with this bugzilla. So the output of comment 5 seems like justification for VERIFIED (especially if also seen on installed system). Why aren't you happy with it? The old (2018-12-11) timestamp would be seen on RHEL 8.0 Beta, I believe. In the fix and tests we went with that timestamp, instead of the one in RHEL 8.0 GA -- that's why the date went backwards. So the intent of the Expected results is not to be read too literally, but rather "in the long run, the date should stay stable". (In reply to Jan Pazdziora from comment #7) > The old (2018-12-11) timestamp would be seen on RHEL 8.0 Beta, I believe. In > the fix and tests we went with that timestamp, instead of the one in RHEL > 8.0 GA -- that's why the date went backwards. So the intent of the Expected > results is not to be read too literally, but rather "in the long run, the > date should stay stable". I'm sorry I just checked the expected result in the bug description and it was different from what I actually saw. Thank you for the explanation. Moving to VERIFIED. 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. |