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