On Thu, 2022-11-03 at 21:51 +0000, Richard Purdie wrote: > «Внимание! Данное письмо от внешнего адресата!» > > On Thu, 2022-11-03 at 18:53 +0000, Sergey Zhmylev wrote: > > Hi Richard, > > > > Thank you for the comment! > > Well, the environment described in reproducible guides currently > > does > > not provide binary reproducability due to extfs implementation. > > Agreed, there is an issue here. I just don't think the patch looks > quite right. > > > Moreover, building on some FS (for example mounted with noatime or > > not supporting crtime field at all like UFS) makes the extfs > > creation > > process totally not reproducible in spite of any modifications on > > the > > source files. > > You're arguing we need to set crtime, ctime and atime which I can > believe. The mtime however should be fine from the package manager so > I > don't think this patch should be changing it. > > There may be a case for just setting the others to mtime instead of > SDE > too?
Unfortunately, there is no other way to properly get mtime of the files in order to clone it into atime/ctime/crtime, than create a large listing of the files and ask debugfs to print stat information, and then parse the long output creating a debugfs script. This process can lead to additional bugs and will take a time. > > > I've checked the behaviour under multiple conditions, double > > checking > > that I've set as much reproducible stuff as possible, and it comes > > out that in certain circumstances rootfs files have incorrect > > timestamps -- they're set to the build process time. > > Which timestamps though? Isn't mtime ok? mtime "mostly" looks ok, while the others were definitely bad. There were several files, not only fstab before my previous patch, but also rpmdb.sqlite and some dnf-related stuff, and so on, on which mtime was set improperly anyways. According to https://reproducible-builds.org/docs/source-date-epoch/ if the user specified SDE, the "last modification of something" (aka mtime) must be set to this value. Taking all the above into account, there is nothing bad in changing all the inodes timestamps: mtime (SDE requirement) and atime/ctime/crtime (to overcome extfs building issues) to the same value -- specified by the user. > > > So I'm sure that if the user set SDE to a particular timestamp, we > > should also modify atime, ctime and crtime. > > > > P.S. overriding only the time later than SDE could have also been > > an > > option, but in reality we can not surely gather stat info for each > > file without debugfs or similar tools and this will tremendously > > degradate performance of already pretty slow image creation > > process. > > Due to this I suggest the patch I've sent. > > That stat information should already be present? Right, but as I said, it's pretty tricky to obtain it for later use. > > Cheers, > > Richard > Thank you, Richard -- With best wishes, Sergei Zhmylev Engineering consultant OS development department
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#172708): https://lists.openembedded.org/g/openembedded-core/message/172708 Mute This Topic: https://lists.openembedded.org/mt/94758789/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
