On Thursday 12 of March 2020 14:25:32 Slávek Banko wrote:
On Thursday 12 of March 2020 03:22:10 Michele Calgaro via trinity-devel
wrote:
On 2020/03/12 01:50 AM, Slávek Banko wrote:
Hi all,
as you probably know, if tdelibs are compiled with elf editor support (WITH_ELFICON), the application icon, TDE information and git repository information are embedded into libraries and binaries during CMake build.
This data, on the one hand, provides user convenience - better to see the application icon than the general binaries icon. On the other hand, they provide information to developers - for example, when reporting creashes.
It is possible that you have also heard about the activity Reproducible builds, which seems to us as a very good idea. See:
https://reproducible-builds.org/ https://wiki.debian.org/ReproducibleBuilds
Currently, the metadata that are embedded has a Compilation Date/Time entry. This is set to the current date and time at the time of building the binary package. And this is a problem because it makes it impossible to achieve reproducible builds.
My suggestion is that next to the ".tdescmmodule" and ".tdescmrevision" files we could have a ".tdescmdatetime" file containing the git commit date and/or a ".tdepackagedatetime" file containing the date the source package was created for distribution. For embedded metadata, this fixed time would be used instead of variable time.
What is your opinion?
Cheers
Hi Slavek, glad that you have brought up this issue, since it is something I have experienced several times when checking the "drop automake" PR in the last few months. I also feel it is good to have reproducible builds. We already have the ".tdescmmodule" and ".tdescmrevision" which contains the git commit hash the package was build from. Nevertheless we are missing the tde-packaging hash in those files. Rather than having too many .tdescmXXXXX files, I propose we use a single .tdegitinfo file which includes module name, repo git hash and packaging repo hash. I don't see any need for any date in the package once we have the git hash info.
Cheers Michele
Thank Michele, it is a good idea that instead of many files we can consolidate git repository information into one file. I will prepare patches / pull-requests in this sense.
Since the tde-packaging repository information and package information for each distribution are independent, a separate package information file will be required.
At the same time, git hash for tde-packaging is not enough for us, because there is also interesting information about the distribution. In addition, here can be forced rebuild without any changes in the git repositories - as an example here is the 'libr' with dependency on binutils. Therefore, it is still useful for us information about date+time and/or the version of the package for a specific distribution.
Cheers
The puzzle pieces are as follows:
1. The create_tarball script instead of individual .tdescmmodule and .tdescmrevision files creates a single .tdescminfo file that contains the SCM module name, revision, and date of the last commit:
https://mirror.git.trinitydesktop.org/gitea/TDE/scripts/pulls/2
2. DEB packaging ensure that a .tdepkginfo file with package metadata is generated during build:
https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/pulls/63
3. The CMake macro retrieves information from .tdescminfo as well as information from .tdepkginfo in source or binary directory. And then use TDE_PKG_DATETIME, or TDE_SCM_MODULE_DATETIME, or the current date:
https://mirror.git.trinitydesktop.org/gitea/TDE/tde-common-cmake/pulls/32
As a result of these pull requests, for deb packages, the date for embedded metadata will consistently contain information about the time the source package was created. So it looks like a good starting point.
So far my initial tests are giving strange results. When I made two independent chroots on the builder (both bullseye@amd64) and trying to build abakus package manually using dpkg-buildpackage, I repeatedly get identical binary packages - the only difference is the "buildinfo" file that contains the build date. When I use automated building with sbuild, I get different binary packages. For now I don't know the cause.
Cheers