On Sun, Mar 20, 2016 at 09:28:43PM -0700, John Menerick wrote: > Works for me on Kali Rolling > > 19f315c8317105a89d5b6fde6c2caa63ffa2e150df5fb0d67ee20ac985b0b191 > pidgin-otr-4.0.2.exe > > 7e9dc2175591d7aabc9f96e737817fa917f3e4441b62727bb9730e516c47822e > pidgin-otr-4.0.2.zip > > > Warmly, > > John Menerick > https://securesql.info
Wow; I didn't really expect it to work on a totally different distro. Very cool! This weekend is the first time that I know of that anyone other than me and my former student Rob has ever even *tried to build* the Windows binary. And it's reproducible from the tarball, w00t! :-) So now that we can reproduce from the tarball, we should try to make the tarball itself reproducible from git. This is better than just making the binary reproducile directly from git, since (a) we do distribute the tarball, and we want people to be able to check that the tarball we distribute does not have anything snuck in there that doesn't come from git, and (b) the pidgin-otr Windows binary build process just downloads the libotr source tarball (it does not try to access the libotr git), so the libotr tarball should itself be a reproducible build from its git. So who knows how to make a reproducible tarball? We'd need to normalize: - The order of the files (I think make dist already does this, though) - The timestamps (--mtime), owners (--owner, --group), permissions (I guess we could chmod the files first, or some combination of --no-same-permissions and umask?) of the files - Anything else? And getting autoconf to get the "make dist" target actually *do* that might take some examining, but worst case, we can override $TAR or $am__tar, I suppose. Thanks again, all. Welcome to spring! [He says as there's a light dusting of snow on the ground after a couple of weeks in the plus-teens-Celcius range.] - Ian _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
