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 -- Slávek
Attachment:
signature.asc
Description: This is a digitally signed message part.
