Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #907315 > unrolled thread

Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH)

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH) Vagrant Cascadian <vagrant@debian.org> - 2018-07-11 22:20 +0200
    Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH) Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> - 2018-07-11 22:40 +0200
      Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH) "Bernhard M. Wiedemann" <bwiedemann@suse.de> - 2018-07-12 19:20 +0200
    Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH) Sune Vuorela <sune@vuorela.dk> - 2018-07-12 20:00 +0200
      Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH) Thomas Preud'homme <robotux@debian.org> - 2018-07-15 00:00 +0200

#907315 — Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH)

[Multipart message — attachments visible in raw view] — view raw

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.

This is (currently) an empty search:

  https://codesearch.debian.net/search?q=QT_RCC_SOURCE_DATE_OVERRIDE

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...


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*


live well,
  vagrant

[toc] | [next] | [standalone]

#907321

[Multipart message — attachments visible in raw view] — view raw

El mié., 11 de jul. de 2018 17:12, Vagrant Cascadian <vagrant@debian.org>
escribió:

> 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.


This is (currently) an empty search:
>
>   https://codesearch.debian.net/search?q=QT_RCC_SOURCE_DATE_OVERRIDE


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.

[toc] | [prev] | [next] | [standalone]

#907443

> 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.

I added a downstream patch to a test-version [1] in openSUSE with

+        static const quint64 sourceDate2 = 1000 *
qgetenv("SOURCE_DATE_EPOCH").toULongLong();
+        if (sourceDate2 != 0)
+            lastmod = sourceDate2;

but somehow this did not help (e.g. with bitcoin's
bitcoin-0.16.1/src/qt/qrc_bitcoin_locale.cpp going into the bitcoin-qt
binary).
So maybe the patch is not the correct solution... or there are more
similar issues somewhere else in rcc.



[1]
https://build.opensuse.org/package/view_file/home:bmwiedemann:reproducible:test/libqt5-qtbase/reproducibletime.patch

[toc] | [prev] | [next] | [standalone]

#907447

On Wednesday, July 11, 2018 10:08:23 PM CEST Vagrant Cascadian wrote:

> Ideally QT_RCC_SOURCE_DATE_OVERRIDE would get set based on
> SOURCE_DATE_EPOCH, otherwise build tools have an arbitrary growing

No. As explained, we need to look at each individual package to check if the 
timestamp is actually used for anything. It can be. It probably is. 

I think a better fix might be to specifically mark in the rcc file if the 
dates are important or not. But it requires involvement upstream. (Or maybe if 
the rcc file is autogenerated or not). I don't think it is a problem for non-
autogenerated rcc files.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

[toc] | [prev] | [next] | [standalone]

#907679

[Multipart message — attachments visible in raw view] — view raw

On jeudi 12 juillet 2018 18:28:21 BST Sune Vuorela wrote:
> On Wednesday, July 11, 2018 10:08:23 PM CEST Vagrant Cascadian wrote:
> > Ideally QT_RCC_SOURCE_DATE_OVERRIDE would get set based on
> > SOURCE_DATE_EPOCH, otherwise build tools have an arbitrary growing
> 
> No. As explained, we need to look at each individual package to check if the
> timestamp is actually used for anything. It can be. It probably is.
> 
> I think a better fix might be to specifically mark in the rcc file if the
> dates are important or not. But it requires involvement upstream. (Or maybe
> if the rcc file is autogenerated or not). I don't think it is a problem for
> non- autogenerated rcc files.

Agreed, it's only a problem for files autogenerated at build time. rcc on a 
file that's part of the source tarball is gonna give a reproducible result.

Best regards,

Thomas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web