Re: [OE-Core][PATCH v11][master-next 1/5] package_ipk.bbclass: add support for ACLs and xattr

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2023-07-31 at 14:25 -0600, Joshua Watt wrote:
> On Mon, Jul 31, 2023 at 1:10 PM Piotr Łobacz <p.lobacz@welotec.com> wrote:
> > 
> > I’m sorry for splitting this message but it has happend by accident…
> > 
> > Returning to the topic my assumption is that for some reason in reproducibleA, these miliseconds are cutted and in case of reproducibleB they are not.
> > 
> > This was obviously working for opkg-build in case of gnu format which is cutting it also but for posix format it stores and thus error occurs.
> > 
> > My question is where can I find the code responsible for moving/coping data into these packages-split directories?
> 
> I suspect this is because reproducibleA is allowed to restore from
> sstate where the milliseconds are not preserved, while reproducibleB
> doesn't restore from sstate.
> 
> I'm not sure how you would store the milliseconds in sstate and make
> sure it was consistent, but that is probably where you need to look.
> Start in sstate.bbclass

What is likely happening is that we have two cases:

a) do_package is run and do_package_write_ipk uses the files directly
from disk which has the millisecond data. do_package writes an sstate
tarball using tar in non-posix mode.

b) do_package_setscene runs instead of do_package. This restores the
tarball written into sstate in a). The millisecond data is therefore
lost. do_package_write_ipk would then be written without it.

I'd guess you need to make the sstate archives of do_package store the
acl and extended attribute data and when that is done, the millisecond
timestamp data will probably be saved too? I'm not sure this is going
to be a generally useful thing in the general case though and zeroing
the millisecond portion would really be easier in general if we could.
Certainly, SOURCE_DATE_EPOCH doesn't have millisecond precision.

Cheers,

Richard