--- Log opened Thu Dec 23 00:00:09 2021 00:21 < hebasto> fanquake: consider the following scenario 00:22 < hebasto> (1) make -C depends clean 00:23 < hebasto> (2) guix build for any commit (eg top master) 00:24 < hebasto> (3) checkout any other commit that touch nothing in depends 00:24 < hebasto> (4) guix buid 00:25 < hebasto> (5) make -C depends clean 00:25 < hebasto> (6) guix build 00:26 < hebasto> Hashes in steps 4 and 6 are expected to differ 00:31 < hebasto> Internally, qt.mk calls 00:31 < hebasto> https://www.irccloud.com/pastebin/eQNFsifk/ 00:32 < hebasto> in step 6 those calls uses SOURCE_DATE_EPOCH which is set in the same step according to the recent commit 00:33 < hebasto> in step 4 those calls use SOURCE_DATE_EPOCH set in the previous step 2 00:34 < hebasto> also https://github.com/qt/qtbase/commit/1ffcca4cc208c48ddb06b6a23abf1756f9724351 00:38 < hebasto> 23:22:37 If we had to rebuild qt prior to every build something is broken -- if we consider the new qt rcc behavior "broken" we can just revert the commit above in our patch and re-add `QT_RCC_SOURCE_DATE_OVERRIDE` into guix script 00:42 < hebasto> but it seems hacky, no? also https://reproducible-builds.org/docs/deterministic-build-systems/ 01:36 < fanquake> I thought we'd taken care of this already, using --format-version 1, although that's only for our own rcc usage. If this is qt making internal calls to rcc, during it's build, and setting the modified time to SOURCE_DATE_EPOCH that is annoying. We can't leave it as is, if we are setting SOURCE_DATE_EPOCH and qt is using that. 01:38 < fanquake> I don't think that's too hacky. We certainly aren't going to move forward with the expectation that qt need to be rebuilt at every commit. 01:40 < hebasto> ok 01:41 < hebasto> let me suggest a pr 02:04 < hebasto> fanquake: if we are going to patch src/tools/rcc/rcc.cpp there are also more opportunities, eg (1) drop `if (lib.formatVersion() >= 2)` branch altogether, (2) or set `lastmod = 0` unconditionally. What do you think? 02:05 < hebasto> I mean, `qtbase/src/tools/rcc/rcc.cpp` 02:09 < fanquake> Setting lastmod to 0 is probably the easiest/smallest patch. Atleast that way, no more qt crap leaks out into depends / guix either. 02:09 < hebasto> qt resource system is the only one 02:17 < hebasto> 10:09:06 Setting lastmod to 0 is probably the easiest/smallest patch. -- not sure if it is the smallest one :) 02:27 < fanquake> ? isn't it 1 line 02:27 < hebasto> plus other lines to drop 02:28 < hebasto> however oneliner still possible 02:28 < fanquake> why do you need to drop other lines? Can't you just set lastmod to 0 last 02:29 < hebasto> it could be useful for #21995 02:29 < gribble> https://github.com/bitcoin/bitcoin/issues/21995 | build: Make built dependency packages reproducible by hebasto · Pull Request #21995 · bitcoin/bitcoin · GitHub 06:45 < laanwj> hebasto: rebuilding qt from scratch every time sounds horrible 06:45 < laanwj> hebasto: it's one of the longest steps in the build process 06:46 < laanwj> i'd rather downgrade qt if there's no other option (but patching rcc suonds fine) 07:29 < hebasto> yes, going to suggest patching 07:30 < hebasto> at least we know the reason of mismatched hash we observer recently 07:30 < hebasto> * hashes 07:30 < hebasto> * observe 07:34 < laanwj> yes, glad to hear that 07:51 -!- tla2k21 [~tla2k21@gateway/tor-sasl/tla2k21] has quit [Ping timeout: 276 seconds] 07:52 -!- tla2k21 [~tla2k21@gateway/tor-sasl/tla2k21] has joined #bitcoin-core-builds 08:13 < jarolrod> fanquake: messaging here because I don't want to add noise on #23838. Of course it's weird that i got mismatched hashes. I built again and I got my same hashes which mismatch yours 08:13 < gribble> https://github.com/bitcoin/bitcoin/issues/23838 | scripts: make security checks architecture independent by fanquake · Pull Request #23838 · bitcoin/bitcoin · GitHub 08:13 < jarolrod> I should note that I finished a build of a different PR before rebuilding your PR and did not get mismatched hashes 08:14 < laanwj> that sounds like the same problem as hebasto 08:14 < jarolrod> laanwj: ah ok, weird because it's only been happening recently. 13:34 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-builds 13:36 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 268 seconds] 13:37 -!- lukedashjr is now known as luke-jr 13:39 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-builds 13:41 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 240 seconds] 13:41 -!- lukedashjr is now known as luke-jr 14:02 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 240 seconds] 14:30 -!- tla2k21 [~tla2k21@gateway/tor-sasl/tla2k21] has quit [Remote host closed the connection] 14:30 -!- tla2k21 [~tla2k21@gateway/tor-sasl/tla2k21] has joined #bitcoin-core-builds 14:44 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-builds 15:14 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 260 seconds] 16:14 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-builds 16:28 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-builds 16:29 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 256 seconds] 16:30 -!- lukedashjr is now known as luke-jr 20:33 -!- Guest13 [~Guest13@2405:4802:90b5:9cd0:5558:f336:4261:c2ce] has joined #bitcoin-core-builds 22:52 -!- Guest13 [~Guest13@2405:4802:90b5:9cd0:5558:f336:4261:c2ce] has quit [Ping timeout: 256 seconds] --- Log closed Fri Dec 24 00:00:10 2021