El mié., 11 de jul. de 2018 17:12, Vagrant Cascadian <vagr...@debian.org>
> 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
> > browse/QTBUG-62511) Non the less a workaround has been included in Qt
> > already in experimental. Setting QT_RCC_SOURCE_DATE_OVERRIDE should be
> > to solve this issue.
> The mentioned upstream bug report is simply marked as invalid without
The point is that stuff like CMake can change this value. See comments.
This is (currently) an empty search:
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