Closed kontura closed 2 years ago
Nice. Given that it is RHEL bug, do we need a test for it?
It seems there is some test that discovered this problem mentioned here: https://bugzilla.redhat.com/show_bug.cgi?id=2077864#c3
But I am not sure if that is deterministic and for this behavior specifically, I could create a dedicated CI test that loads the cached mtime
and then changes the file mtime manually with something like: touch --date '(cached mtime + 1nanosec)' bash.rpm
?
Yes, something like this should work. The current test is definitely not deterministic.
Why is the PR blocked? Is it because of missing / failing tests?
Why is the PR blocked? Is it because of missing / failing tests?
While creating the CI tests (https://github.com/rpm-software-management/ci-dnf-stack/pull/1096 which are also failing but I guess that is unrelated?) I noticed there is a failing unittest. It can be fixed but I am confused how come the build for the PR succeed. I want to look into it.
I was also considering whether it would be better to store the nanoseconds part of the timestamp separately under a different key, for example: user.Librepo.checksum.mtime_nsec
but I am not sure.
Nanoseconds epoch is a very big number.
Why is the PR blocked? Is it because of missing / failing tests?
While creating the CI tests (rpm-software-management/ci-dnf-stack#1096 which are also failing but I guess that is unrelated?) I noticed there is a failing unittest. It can be fixed but I am confused how come the build for the PR succeed. I want to look into it.
Oh I see, it is the problem with support of extended attributes. The test wasn't running (failing) because the build environment doesn't support them.
= changelog = msg: Use nanosec precision for timestamp of checksum cache type: bugfix resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2077864
librepo already uses
#define _POSIX_C_SOURCE 200809L
inlibrepo/handle.c
andlibrepo/util.c
so I think it should be fine from compatibility point of view.