I just realized that in my latest flathub build by vorarbeiter the manifest.json embedded in the app differs from the manifest I provided.
It contains an additional field "source-date-epoch" , that evaluates to 11. November 2011 12:11:11. This seems to be used as the timestamp of a build when using cmake (and possibly other build systems too).
In fact, you can now find several app on flathub that seem to be released “more than 13 years ago”, presumably because of a release date set to 2011-11-11.
I cannot find any information on this in the documentation available to me. man flatpak-manifest does not mention a field source-date-epoche.
Is what I observe intentional? And has this change in behavior been communicated?
Any information on this would be greatly appreciated.
I think I figured it out. In the vorarbeiter piepline, flatpak-builder is called with argument --override-source-date-epoch 1321009871see github repo. This timestamp evaluates to 2011-11-11 11:11:11. I could not find documentation on this flatpak-builder option, but I assume that it sets the SOURCE_DATE_EPOCH env variable for the build process and also adds the source-date-epoch to the manifest.
I used to do that and some apps (e.g. QtCreator via string(TIMESTAMP timestamp "%Y-%m-%d") ) still do it. That’s a convenient way to ensure that the release date matches the date of the build of the released executable. If you look at these apps on flathub.org, they are said to be released “more than 13 years ago”, which of course is incorrect.
Perhaps we should be able to set SOURCE_DATE_EPOC in the manifest.
No, if app maintainers keep changing it, then the entire point of making builds reproducible is moot. That variable is specifically used for this purpose.
It’s a bug on the software’s end to use that as release date in appstream. You should fix that instead.
the manifest.json embedded in the app differs from the manifest I provided.
That manifest is autogenerated by Flatpak Builder, it always differs from the input manifest created by humans as that is meant to deterministically reproduce a build. It being different is not new news.
That’s a convenient way to ensure that the release date matches the date of the build of the released executable.
That’s wrong, the appstream tag is “release date” not “build date” you are introducing unreproducibility in appstream data by using the date of the build as release date. This will cause the same version to say different release dates depending on when it gets built which is horrible.
The release date should be the date when you make the release or tag it. It’s fixed in time that’s one of the points of making a release.
This is completely wrong. The release date in the appstream file should be set when releasing the package. It should be part of the release process. It is NEVER at build time. You complain about the release date being 13 years in the past, but what if the release was actually 13 years ago and the release info show today? It’s also misleading.
The build date is irrelevant. Even for proprietary binary only packages.