< jeremyrubin> by the way; last call for OP_CTV BIP 119 registrations
< fanquake> 5-6 gitian sigs each for the 0.19.1rc1 binaries so far, and the windows detached sigs are up, thanks cfields
< fanquake> jonasschnelli are you able to get some osx detached sigs up soon?
< bitcoin-git> [bitcoin] fanquake closed pull request #17565: Fixed freezing GUI on reindex (master...freezing-gui-on-reindex) https://github.com/bitcoin/bitcoin/pull/17565
< 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
< jonasschnelli> I have a different hash than wumpus for bitcoin-0.19.1rc1-osx-unsigned.tar.gz (https://bitcointools.jonasschnelli.ch/data/builds/1333/bitcoin-core-osx-0.19-build.assert)
< jonasschnelli> I guess wumpus'es are off (everyone else has the same)
< jonasschnelli> I pushed the osx detatched signature. Sorry, had to force push since my git email was set wrong.
< jonasschnelli> looks like my irc messages end up in the nirvana...
< jonasschnelli> (good now though)
< fanquake> jonasschnelli: thanks
< wumpus> strange...
< wumpus> at least it's only osx that mismatches, linux and windows are ok
< wumpus> will try rebuilding
< fanquake> wumpus might have modified your macOS SDK somehow?
< wumpus> no, not as far as I know
< wumpus> pretty sure this is the same setup I've used to build
< fanquake> ok. If you wanted to upload bitcoin-0.19.1rc1-osx-unsigned.tar.gz I'd take a look
< wumpus> will do! first going to try again to see if it's not just a fluke
< wumpus> re-built: same problem. The .tar.gz differs (but it is determinstic) but the dmg matches
< wumpus> fanquake: put up my version of the file here if anyone wants to try to compare it: https://download.visucore.com/bitcoin/bitcoin-0.19.1rc1-osx-unsigned.tar.gz
< fanquake> wumpus: thanks. Having a look
< wumpus> thankyou!
< fanquake> wumpus the difference is in the .note.gnu.build-id section of the dmg tool
< fanquake> can you do a readelf --string-dump .note.gnu.build-id path/to/dmg
< fanquake> wumpus in the second part of that section I'm seeing
< fanquake> [ 10] r^[T???'??d?*???f?? for my binary
< fanquake> [ 10] #{?^Vv^[s_?b?^D? ? for yours
< fanquake> Looks like the difference is actually a little bigger.
< fanquake> Our libdmg package in the 0.19 branch hasn't been changed since it was introduced, https://github.com/bitcoin/bitcoin/blob/0.19/depends/packages/native_libdmg-hfsplus.mk, so I'm quite interested to no what might be causing this difference
< kanzure> #proposedmeetingtopic topic idea collection for physical meeting
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/28fbe68fdcac...c26b05c2b78f
< 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
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #17999: refactor: Add ChainClient setMockTime, getWallets methods (master...pr/ipc-clients) https://github.com/bitcoin/bitcoin/pull/17999
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #17999: refactor: Add ChainClient setMockTime, getWallets methods (master...pr/ipc-clients) https://github.com/bitcoin/bitcoin/pull/17999
< hebasto> are detached sigs for 0.19.1rc1 tagged?
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #17997: refactor: Remove mempool global from net (master...2001-netMempool) https://github.com/bitcoin/bitcoin/pull/17997
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #17997: refactor: Remove mempool global from net (master...2001-netMempool) https://github.com/bitcoin/bitcoin/pull/17997
< 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> fanquake: in your comparisons in https://gist.github.com/fanquake/3303ac3bc9efc63293d59df5b81d1cef, there's
< wumpus> - 0x0001ccf0 7c69736f 7c646d67 5d203c69 6e3e203c |iso|<elf>] <in> <
< wumpus> + 0x0001ccf0 7c69736f 7c646d67 5d203c69 6e3e203c |iso|dmg] <in> <
< 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
< fanquake> wumpus https://uploadfiles.io/xb1hzk0i 5023cb07d685a7f4b6ff3e1c12753da0b7cbf4f492d309d9b74b1f4e76af21eb
< jonatack> fanquake: am gitian building 0.19.1rc1, is that the correct tag atm?
< fanquake> that's the most recent tag, yes
< jonatack> thanks
< jeremyrubin> Independent of Taproot PR; would there be any strong objections to picking *an* implementation of std::optional (from some compiler's includes) or adding a minimal optional subsititue and eliminating the boost dependency? see https://github.com/martinmoene/optional-bare/blob/master/include/nonstd/optional.hpp and https://github.com/tcbrindle/cpp17_headers/blob/master/include/stx/optional.hpp as copyable examples
< 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
< fanquake> heh
< fanquake> wumpus The iso <elf> substitution is a bug in diffoscope
< fanquake> I think the only difference between the two tools might actually just be the build ID
< sipa> fanquake: more like crazy feature
< fanquake> sipa a good time waster
< gwillen> oh, good find fanquake, thanks, I was going to go nuts trying to track that down
< gwillen> I guess you named one of the files "dmg" when passing it to diffoscope, triggering the overzealous search-and-replace on only one side
< fanquake> gwillen yea the binary is just named dmg
< fanquake> I was doing diffoscope wumpus.dmg dmg
< gwillen> that is a pretty nasty bug / misfeature in diffoscope
< fanquake> If I swap that for diffoscope wumpus.dmg fanquake.dmg I see
< 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)
< sipa> fanquake: so that's how you do it
< 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
< fanquake> wumpus great!