< bitcoin-git>
[bitcoin] fanquake closed pull request #16696: validation: static_assert to ensure width in unit class (master...fix-uintbase) https://github.com/bitcoin/bitcoin/pull/16696
< bitcoin-git>
bitcoin/master 2d23082 Micky Yun Chan: bump test timeouts so that functional tests run in valgrind
< bitcoin-git>
bitcoin/master c26b05c MarcoFalke: Merge #17770: test: bump test timeouts so that functional tests run in val...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #17770: test: bump test timeouts so that functional tests run in valgrind (master...bump) https://github.com/bitcoin/bitcoin/pull/17770
< wumpus>
fanquake: I'm really confused, so there is some difference in a third-party tool, not one of our own executables, and it's mostly just a difference in message?
< wumpus>
dmg is replaced by <elf>?
< wumpus>
I gues I'll delete the cache and retry...
< wumpus>
that didn't solve it either, I'm baffled
< wumpus>
I don't unnderstand why the text is different in that hexdump, but the hex digits seem the same?
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #18001: Updated appveyor job to checkout a specific vcpkg commit ID (master...vcpkg-specific-version) https://github.com/bitcoin/bitcoin/pull/18001
< wumpus>
they're supposed to be different representation of the same data, right?
< bitcoin-git>
[bitcoin] sipsorcery closed pull request #17995: Load vcpkg port files from a separate repository. (master...vcpkg-ports-separate) https://github.com/bitcoin/bitcoin/pull/17995
< sipa>
?d|iso|dmg] <in> <
< sipa>
is the hex ascii conversion
< wumpus>
exactly! so I don't see where the <elf> comes from; the dmg executable definitely differs from the ones generated by other's gitian, but I don't yet know in what way (besides the build id, but that's a kind of hash of some sections)
< wumpus>
deleted and regenerating the gitian base image, will delete the cache again, and try yet again if I get a different output
< wumpus>
can someone please put up their "correct" version of bitcoin-0.19.1rc1-osx-unsigned.tar.gz?
< fanquake>
wumpus sure
< fanquake>
I'm also confused by the supposed string substitution
< jeremyrubin>
(This came up in the context of taproot of not wanting to use optional in consensus to avoid a boost dep)
< gwillen>
wumpus: sipa: that hexdump is not a hexdump
< gwillen>
some tool has blindly performed an s/dmg/<elf>/ _after_ the hexdump was run, on whatever file contained the output
< gwillen>
there is a mistargeted glob somewhere or something in that toolchain
< fanquake>
gwillen I guess diffoscope must be broken then
< fanquake>
As that's what was used to generate those dumps.
< gwillen>
I am not familiar with diffoscope so I can't comment, but (1) the hex in the hexdump always controls, the displayed characters are just for convenience, and (2) you can see the the NUMBER of characters in the right column is wrong
< gwillen>
because dmg and <elf> are not the same length
< gwillen>
I suspect the same of the --symbols output, probably there is no <elf> in the binary, something is messing with the tool output
< jeremyrubin>
Another option would just be to fill in with boost::optional if c++17 isn't available, and std::optional otherwise (so libconsensus can build w/o boost on newer compilers)
< fanquake>
I think you might be right. Maybe the difference really is only the Build ID
< gwillen>
that build ID is allegedly supposed to be a hash of the binary contents to make it reproducible, I wonder what went wrong here
< gwillen>
I wonder if the way build ID is computed changed between versions of ld -- the original default is documented to have been md5, whereas the current default is allegedly sha1
< fanquake>
From what I understand, Build ID isn't necessarily a content hash, almost more like a UUID. However will continue looking tomorrow.
< * fanquake>
goes back to sleep
< gwillen>
there is apparently a --build-id flag you pass to ld, which you can set to values like "sha1" or "md5" or "uuid" or "0x..." (a constant)
< gwillen>
but given apparently identical inputs, and a difference in build ID on exactly one machine, I definitely wonder if the difference is the ld on that machine is doing something funny
< sipa>
you have an AI to wake you up when there are interesting IRC or github conversations and sleep in between
< fanquake>
sipa: yea something fancy like that
< bitcoin-git>
[bitcoin] sipa opened pull request #18002: Abstract out script execution out of VerifyWitnessProgram() (master...202001_execute_witness) https://github.com/bitcoin/bitcoin/pull/18002
< wumpus>
fanquake: after building with a newly generated base image I managed to get the same output as everyone else now, pushed new sigs
< wumpus>
fanquake: likely it's some ubuntu package difference that caused it; will still do a comparison just to be sure
< wumpus>
right: the only difference I get is the .note.gnu.build-id section -- well, okay, that's only a id and can't be an implanted backdoor at least :-) thank you for your help fanquake, seems this has been resolved