On 2018-07-11, Lisandro Damián Nicanor Pérez Meyer wrote:
> Version: 5.11.1+dfsg-1
>
> The bug upstream has been closed as invalid (see https://bugreports.qt.io/
> browse/QTBUG-62511) Non the less a workaround has been included in Qt 5.11,
> already in experimental. Setting QT_RCC_SOURCE_DATE_OVERRIDE should be enough
> to solve this issue.
The mentioned upstream bug report is simply marked as invalid without
explanation.
The point is that stuff like CMake can change this value. See comments.
Because it did not scan experimental.
Do you have a link for QT_RCC_SOURCE_DATE_OVERRIDE present in Debian and
upstream? This bug doesn't really seem resolved if that variable isn't
actually getting set by anything or consumed by anything...
Right now, in experimental. We hope to get the transition going soon.
Ideally QT_RCC_SOURCE_DATE_OVERRIDE would get set based on
SOURCE_DATE_EPOCH, otherwise build tools have an arbitrary growing
number of variables to keep track of for each library, toolchain,
language, etc. that implements their own way of doing this sort of
thing, which kind of defeats the purpose of SOURCE_DATE_EPOCH. *sigh*
That's sadly something we can only "fix" by making packages have the right value set. As per Qt policy the environment variable needs to be prefixed with QT, so no chance of directly using SOURCE_DATE_EPOCH.
Feel free to jump in in the upstream bug report if you feel like this is not enough.
Cheers, Lisandro.