Since version 3.0, nsis start to support unicode. However, Bionic still use 2.51. So, it might be a good reason to add nsis into dependency list to support unicode.
TODO:
- Gitian build should be deterministic
<!--e57a25ab6845829454e8d69fc972939a-->Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Since this is not a regression, I have assigned the 0.18.0 milestone for now.
13 | +endef 14 | + 15 | +define $(package)_stage_cmds 16 | + $(MAKE) install prefix=$($(package)_staging_prefix_dir) 17 | +endef 18 | +
Please use "linux encoding" for the "new line characters"
Crap, one of the reasons we upgraded to bionic in the first place is to upgrade NSIS, not really happy that we end up compiling it anyway now. But yes, let's put this for 0.18, this is not a new problem (and comes extremely last-minute for 0.17).
0 | @@ -0,0 +1,27 @@ 1 | +package=native_nsis 2 | +$(package)_version=3.03 3 | +$(package)_download_path=https://sourceforge.net/projects/nsis/files/NSIS%203/$($(package)_version) 4 | +$(package)_file_name=nsis-$($(package)_version)-src.tar.bz2 5 | +$(package)_sha256_hash=abae7f4488bc6de7a4dd760d5f0e7cd3aad7747d4d7cd85786697c8991695eaa 6 | +$(package)_dependencies=native_zlib 7 | + 8 | +define $(package)_set_vars 9 | +$(package)_build_opts = -j4
I'm not sure what the best number is here.
Can't you use the passed down number from make depends -j yy?
nsis is not built by make, so it is incompatible with make jobs.
Or there is a way to get job number?
Not that I am aware of. Other than that you might just set the number of jobs so that they use less than 1GB of RAM, since that is our minimum requirement to get built.
After testing a few times, there are some edge case fail to cd directories in multi-job. Will remove this.
@MarcoFalke This is not ready for gitian build since it is not deterministic.
I have no idea why the following things would happen? I already put scons into faketime wrapper, but the compiled stub files still contain timestamp in PE header. The alternative way is to hack the compiled PE file timestamp and set it to a constant.
@theuni Do you have any idea what would break the deterministic?
Maybe it helps if you include the diffoscope output between two consecutive builds?
Yes, I know it contains current timestamp and checksum, that is the only differnece. But I don't know why it would be there. I already pack scons into faketime wrapper.
The difference is here: https://0bin.net/paste/Z5FvTgDDCLs2El3y#fvLayra1H9pE-R0lc/QX026USa0ZYn5PgTWKDCFqkT5
Apparently it is timestamp.
Could you also upload both of the tar.gz results?
Close it for now. I can't solve the gitian build deterministic issue.
Oh, wait. Why is it required that the depends cache is deterministic? Shouldn't the only requirement be that the resulting bitcoind.exe (et al) is deterministic? At least that should be the goal when we want to support deterministic builds on any host by default.
If you reopen, I can run DrahtBot on this twice to see what the effective difference is for Gitian builds.
Why is it required that the depends cache is deterministic?
It has to compile installer and decompressor that runs on Windows.
If you reopen, I can run DrahtBot on this twice to see what the effective difference is for Gitian builds.
Thanks, but you have to clear nsis depends cache manually, otherwise it's deterministic.
<!--cf906140f33d8803c4a75a2196329ecb-->Needs rebase
Does this upstream patch fix this? https://sourceforge.net/p/nsis/bugs/1230/