ODP: posix atime/ctime changes despite mtime being set

[Piotr Łobacz]

Paul, I haven't tested your recipe yet.

I'm currently running on my local machine this poky-contrib repo from yocto with my patches for tar paramas to this opkg-build script,

which Sergey suggested.

If you wish to test it as well than it is located here git://git.yoctoproject.org/poky-contrib.git branch abelloni/master-next

To run it you are typing:

. ./oe-init-build-env build

MACHINE="qemux86-64" oe-selftest -r reproducible

but be adviced that first you need to comment SANITY_TESTED_DISTROS variable from ./meta-poky/conf/distro/poky.conf

otherwise, it will fail due to this error:

2023-07-25 17:30:19,637 - oe-selftest - ERROR - Please unset SANITY_TESTED_DISTROS in order to run oe-selftest

Right now, I'm running it as well...

BR,

Piotr

---

Od: Paul Eggert <eggert@cs.ucla.edu>
Wysłane: wtorek, 25 lipca 2023 17:50
Do: Sergey Poznyakoff <gray@gnu.org.ua>; Piotr Łobacz <p.lobacz@welotec.com>
DW: bug-tar@gnu.org <bug-tar@gnu.org>
Temat: Re: posix atime/ctime changes despite mtime being set

 

On 2023-07-25 05:13, Sergey Poznyakoff wrote:
>
>> as you can see on this output the only
>> differences are between timestamps e.g.:
>>
>>                                                                      
>>   7  -rw-r--r--···0········0······· 7  -rw-r--r--···0········0·······
>>      ·0·····7339·2012-02-16·20:24:4    ·0·····7339·2012-02-16·20:24:4
>>      2.000000·./usr/src/debug/acpid    2.515701·./usr/src/debug/acpid
>>      /2.0.34-r0/acpi_ids.c             /2.0.34-r0/acpi_ids.c
>
> Then I'd suppose that first archive (the one shown on the left size) was
> created in ustar, gnu or similar format - the one that stores timestamps
> with a seconds precision.  In contrast, second archive (the one shown on
> the right side) is in POSIX.1-2001 format, which stores timestamps with
> a subsecond precision.
>
> Regards,
> Sergey

The recipe I suggested yesterday should generate tarballs with
timestamps that are all integer multiples of seconds. Either the recipe
wasn't followed, or it's buggy.

It's similar to the recipe I've been using to generate tzdb releases
since 2022a.