[Monotone-devel] Re: nvm.stripped botan on FreeBSD [Was: propose to land .stripped on Tuesday]
Zack Weinberg wrote: Please try replacing line 198 of revision.cc with this code: #if BOTAN_VERSION_CODE = BOTAN_VERSION_CODE_FOR(1,7,7) It works, I committed it in revision 6d9507fb29ddf2eb. (I guess you might already have committed it, but can't hurt...) With this, stripped works on FreeBSD-7. -- Lapo Luchini - http://lapo.it/ “The death rate is the same for us as for anybody… one person, one death, sooner or later.” (Robert A. Heinlein, Tunnel in the Sky, 1955) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.stripped botan on FreeBSD [Was: propose to land .stripped on Tuesday]
Zack Weinberg wrote: This is the danger of moving huge blocks of code around, I guess ... there *was* appropriate #ifdeffage in the previous incarnation of this code on .stripped, in revision.cc, but I did the reorganization on mainline. Please try replacing line 198 of revision.cc with this code: Yes, it passes the file and goes on. Now I must hurry and can't see the end of it, or the end of make check, but I will report problems tomorrow, if needs be! -- Lapo Luchini - http://lapo.it/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
Stephen Leake stephen_le...@stephe-leake.org writes: Zack Weinberg za...@panix.com writes: On Tue, Jan 20, 2009 at 2:31 PM, Zack Weinberg za...@panix.com wrote: I noticed a severe slowdown in the time for nvm.stripped to run the testsuite (from five to twelve minutes on my big beefy quad-core machine) which *seems* to be all down to initializing botan's RNG. Most subcommands don't use cryptographic random numbers at all. I just pushed changes to .stripped that make us wait to instantiate a RandomNumberGenerator object until we actually need one (under the =1.7.7 API). That takes the testsuite runtime back down to a little more than five minutes. I consider the performance with botan 1.8.0 acceptable now. I'm pretty happy with .stripped. I was able to muck out an incredible amount of gunk from the configure script, and if we get rid of netxx even more can go. The binary's smaller, the build is faster, and the Debian security team will be happy with us. What remains to be done before we can land it? There is still the mysterious libintl-11.dll on MinGW. I have not yet made progress with this Folks with exotic systems (non-Linux, non-*BSD) might wanna check what I did to the configure script, btw. I might have been overoptimistic. :-/ I don't have my MinGW box available at the moment; it's my work laptop, and I normally leave it at work. I'll look into changes since the mini-summit when I have time. I finally got around to this. configure on MinGW is leaving a mal-formed Makefile: it has @am__fastdepCC_TRUE@ and similar things in it. I'll try to make time to investigate this later this week. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
Hi, Zack Weinberg wrote: On Sat, Jan 31, 2009 at 12:53 PM, Markus Wanner mar...@bluegap.ch wrote: However, testing quickly on FreeBSD 7.1, I get: checking for botan... gnome-config: not found no usage: basename string [suffix] basename [-a] [-s suffix] string [...] checking for botan using --cflags: not found no checking for botan... not found; guessing checking whether botan is usable... no Here's the output of a pkg-config request, as run by configure from that same machine: freebsd71-i386% /usr/local/bin/pkg-config --exists --print-errors botan = 1.6.3 gnome-config: not found Package botan was not found in the pkg-config search path. Perhaps you should add the directory containing `botan.pc' to the PKG_CONFIG_PATH environment variable No package 'botan' found gnome-config: not found Package 1.6.3 was not found in the pkg-config search path. Perhaps you should add the directory containing `1.6.3.pc' to the PKG_CONFIG_PATH environment variable No package '1.6.3' found What's obviously wrong on FreeBSD is, that there's no .pc file for botan. However, there's a botan-config executable: freebsd71-i386% which botan-config /usr/local/bin/botan-config freebsd71-i386% botan-config --libs -L/usr/local/lib -lm -lbotan freebsd71-i386% botan-config --cflags freebsd71-i386% I'm a bit puzzled about why there's no -I/usr/local/inculde in the --cflags output. As the earlier check for boost shows, gcc doesn't add that automatically. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Sun, Feb 1, 2009 at 4:35 AM, Markus Wanner mar...@bluegap.ch wrote: Here's the output of a pkg-config request, as run by configure from that same machine: freebsd71-i386% /usr/local/bin/pkg-config --exists --print-errors botan = 1.6.3 gnome-config: not found Package botan was not found in the pkg-config search path. Perhaps you should add the directory containing `botan.pc' to the PKG_CONFIG_PATH environment variable No package 'botan' found gnome-config: not found Package 1.6.3 was not found in the pkg-config search path. Perhaps you should add the directory containing `1.6.3.pc' to the PKG_CONFIG_PATH environment variable No package '1.6.3' found Do you get the same output if you write it like this? $ /usr/local/bin/pkg-config --exists --print-errors 'botan = 1.6.3' There could easily be some additional quoting needed in library.m4. Also, what does pkg-config --version print? What's obviously wrong on FreeBSD is, that there's no .pc file for botan. However, there's a botan-config executable: IIRC Jack only added the .pc file in 1.7.something, so yeah. I'm a bit puzzled about why there's no -I/usr/local/inculde in the --cflags output. As the earlier check for boost shows, gcc doesn't add that automatically. It looks like botan-config deliberately does not print an -I switch if it would be -I/usr/include or -I/usr/local/include. This is sane, because you have to patch gcc to get it not to search those directories by default. Is this the stock FreeBSD 7.1 gcc? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
Hi, Zack Weinberg wrote: Do you get the same output if you write it like this? $ /usr/local/bin/pkg-config --exists --print-errors 'botan = 1.6.3' Hm.. not quite: freebsd71-i386% /usr/local/bin/pkg-config --exists --print-errors 'botan = 1.6.3' gnome-config: not found Package botan was not found in the pkg-config search path. Perhaps you should add the directory containing `botan.pc' to the PKG_CONFIG_PATH environment variable No package 'botan' found freebsd71-i386% There could easily be some additional quoting needed in library.m4. Also, what does pkg-config --version print? freebsd71-i386% /usr/local/bin/pkg-config --version 0.23 It looks like botan-config deliberately does not print an -I switch if it would be -I/usr/include or -I/usr/local/include. This is sane, because you have to patch gcc to get it not to search those directories by default. Is this the stock FreeBSD 7.1 gcc? I think so, yes: freebsd71-i386% gcc --version gcc (GCC) 4.2.1 20070719 [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Sun, Feb 1, 2009 at 9:05 AM, Markus Wanner mar...@bluegap.ch wrote: freebsd71-i386% /usr/local/bin/pkg-config --exists --print-errors 'botan = 1.6.3' gnome-config: not found Package botan was not found in the pkg-config search path. Perhaps you should add the directory containing `botan.pc' to the PKG_CONFIG_PATH environment variable No package 'botan' found freebsd71-i386% Ok, that's what I was expecting. The trace output you sent me indicates that the quoting in configure is correct, so we're good there. I poked around a bit and figured out that pkg-config will try to run gnome-config for any package it doesn't have a .pc file for. It's harmless. Mine (0.22) doesn't complain about it when it can't find gnome-config, *shrug* With the trace output I was able to find several typos in library.m4 and mtn-gettext.m4. I believe these were what was making it fail to use botan-config correctly (or even attempt to use libintl). I've tested on my system that configure can now find botan if there's no .pc file for it, but I can't test the no-gettext-in-libc case. Would you please update to the tip of .stripped and try again? It looks like botan-config deliberately does not print an -I switch if it would be -I/usr/include or -I/usr/local/include. This is sane, because you have to patch gcc to get it not to search those directories by default. Is this the stock FreeBSD 7.1 gcc? I think so, yes: freebsd71-i386% gcc --version gcc (GCC) 4.2.1 20070719 [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Hm, what do you get from this command? $ gcc -v -E -x c++ /dev/null 21 | sed -ne '/^#include/,/End of/p; /^ignoring/p' zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
Hi, Zack Weinberg wrote: As we now expect nvm.stripped to compile and run on most of the supported systems, I think we should land nvm.stripped in about a week, given further testing succeeds. I have no objection to this plan, provided no horrible breakage turns up in the next few days. I just wanted to test nvm.stripped on some OSes again, but unfortunately I can't even get automake to run through. automake-1.9 (from my debian sid development machine) just aborts without any I can identify as an error message. Running it with -W -v spits out (trailing lines only): automake-1.9: # and 'distcheck' gets cranky if we don't. So basically what this automake-1.9: # line does is tell 'distcheck' to shut up and ignore those two files. automake-1.9: automake-1.9: value: find . -type f -a ! -name package_revision.txt -a ! -name package_full_revision_dist.txt automake-1.9: owner: Makefile automake-1.9: } automake-1.9: } automake-1.9: with `TRUE' = `find . -type f -print' automake-1.9: reading /usr/share/automake-1.9/am/footer.am automake-1.9: reading /usr/share/automake-1.9/am/install.am automake-1.9: reading /usr/share/automake-1.9/am/clean.am automake-1.9: not writing ./Makefile.in because of earlier errors I've also tested automake 1.10 on the same machine and 1.9 on Gentoo and FreeBSD without any success. What's wrong? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Sat, Jan 31, 2009 at 11:32 AM, Markus Wanner mar...@bluegap.ch wrote: I just wanted to test nvm.stripped on some OSes again, but unfortunately I can't even get automake to run through. automake-1.9 (from my debian sid development machine) just aborts without any I can identify as an error message. There's two things that coulda gone wrong: first, I accidentally checked in an incorrect change to Makefile.am last night; I've just reverted that, so please update and try again. Second, if you're not using autoreconf, you have to do the commands in this order or it doesn't work: aclocal-1.9 -I m4 autoheader autoconf automake-1.9 --add-missing --copy --no-force (It doesn't seem to matter which order you do autoheader and autoconf in, but aclocal has to be first and automake has to be last.) I'm re-running make distcheck on my Debian sid machine, having used automake-1.9 (normally I use 1.10) and will report whether it worked. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
Hi, Zack Weinberg wrote: There's two things that coulda gone wrong: first, I accidentally checked in an incorrect change to Makefile.am last night; I've just reverted that, so please update and try again. Okay, that did the trick on debian sid. Thank you. However, testing quickly on FreeBSD 7.1, I get: checking for botan... gnome-config: not found no usage: basename string [suffix] basename [-a] [-s suffix] string [...] checking for botan using --cflags: not found no checking for botan... not found; guessing checking whether botan is usable... no configure: *** botan_CFLAGS= configure: *** botan_LIBS=-lbotan configure: error: Must be able to compile and link programs against botan. See `config.log' for more details. What is 'gnome-config' doing there? botan-config is within $PATH. I fear your changes to this branch are severe enough to require further testing (and fixing) on various platforms. :-( Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Sat, Jan 31, 2009 at 12:53 PM, Markus Wanner mar...@bluegap.ch wrote: However, testing quickly on FreeBSD 7.1, I get: checking for botan... gnome-config: not found no usage: basename string [suffix] basename [-a] [-s suffix] string [...] checking for botan using --cflags: not found no checking for botan... not found; guessing checking whether botan is usable... no This shouldn't be possible. Please re-run configure as follows (starting from the top of the source directory): $ sh -x ./configure config.trace 21 and then send me (off-list) both config.log and config.trace. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.stripped versus botan
Zack Weinberg wrote: On Sat, Jan 24, 2009 at 11:51 PM, Lapo Luchini l...@lapo.it wrote: nvm.stripped: % fgrep _PLATFORM config.status S[WIN32_PLATFORM_FALSE]=# S[WIN32_PLATFORM_TRUE]= Yes, it seems to be at reverse indeed... Ok, please try again with the change I just pushed (ef6b444ed286c55788bc258b1dda83d5da695ea2). % fgrep _PLATFORM config.status S[WIN32_PLATFORM_FALSE]= S[WIN32_PLATFORM_TRUE]=# Yep, it compiles. Also, what version of autoconf are you using? I get something much harder to read when I do that grep. Oh, the one by default in Cygwin... either 2.13 or 2.63, AFAIK it's chosen automatically by a wrapper depending on values in configure.ac (so, in our case it should be 2.63). -- Lapo Luchini - http://lapo.it/ “Gentlemen do not read each others mail.” (Henry Lewis Stimson) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
Hi, Zack Weinberg wrote: Unfortunately it is not practical... Well, the code before did exactly that for these four libraries. However, the current approach is certainly cleaner. The output of mtn version --full is dumped into the log files for the test suite; might that be good enough? If not, when would you like to see this reported? Well, knowing the libraries it is *going* to (try to) compile against in advance was pretty helpful, sometimes. Especially when fiddling with various versions of these libraries. But... as end-users won't ever have that requirement... never mind. I have no objection to this plan, provided no horrible breakage turns up in the next few days. Yup, let's hope so. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Sun, Jan 25, 2009 at 8:29 PM, Lapo Luchini l...@lapo.it wrote: Zack Weinberg wrote: Ok, please try again with the change I just pushed (ef6b444ed286c55788bc258b1dda83d5da695ea2). % fgrep _PLATFORM config.status S[WIN32_PLATFORM_FALSE]= S[WIN32_PLATFORM_TRUE]=# Yep, it compiles. Oh good. Also, what version of autoconf are you using? I get something much harder to read when I do that grep. Oh, the one by default in Cygwin... either 2.13 or 2.63, AFAIK it's chosen automatically by a wrapper depending on values in configure.ac (so, in our case it should be 2.63). Ah, I have 2.61. I guess they figured out a less horrible way to do that. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
Hi, Zack Weinberg wrote: I'm pretty happy with .stripped. I was able to muck out an incredible amount of gunk from the configure script, and if we get rid of netxx even more can go. The binary's smaller, the build is faster, and the Debian security team will be happy with us. What remains to be done before we can land it? Thank you very much for cleaning up the autoconf stuff, that indeed looks pretty clean now. Thanks as well for tracking down and fixing the loading speed issue. [ The only thing I'm missing now is the version information during configure. I.e. what version of botan, pcre, idna, .. I'm going to compile against. ] As we now expect nvm.stripped to compile and run on most of the supported systems, I think we should land nvm.stripped in about a week, given further testing succeeds. Or is landing it on nvm potentially hindering anybody from doing something important on nvm? Folks with exotic systems (non-Linux, non-*BSD) might wanna check what I did to the configure script, btw. I might have been overoptimistic. :-/ I haven't tested much on my systems, but will do so within the next few days. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Sat, Jan 24, 2009 at 11:51 PM, Lapo Luchini l...@lapo.it wrote: nvm: % fgrep _PLATFORM config.status S[AIX_PLATFORM_FALSE]= S[AIX_PLATFORM_TRUE]=# S[WIN32_PLATFORM_FALSE]= S[WIN32_PLATFORM_TRUE]=# nvm.stripped: % fgrep _PLATFORM config.status S[WIN32_PLATFORM_FALSE]=# S[WIN32_PLATFORM_TRUE]= Yes, it seems to be at reverse indeed... Ok, please try again with the change I just pushed (ef6b444ed286c55788bc258b1dda83d5da695ea2). Also, what version of autoconf are you using? I get something much harder to read when I do that grep. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.stripped versus botan
Zack Weinberg wrote:
Folks with exotic systems (non-Linux, non-*BSD) might wanna check what
I did to the configure script, btw. I might have been overoptimistic.
:-/
Well, configure worked on CygWin, compile less so ;-)
% make
[...]
In file included from ./sanity.hh:19,
from win32/read_password.cc:12:
./numeric_vocab.hh:45:44: macro max requires 2 arguments, but only 1 given
% context 45 numeric_vocab.hh
42else
43 {
44const size_t char_bit = std::numeric_limitsunsigned
char::digits;
45T mask = std::numeric_limitsT::max();
46size_t shift = (sizeof(T) - sizeof(V)) * char_bit;
47mask = shift;
48return static_castT(v) mask;
--
Lapo Luchini - http://lapo.it/
“…one of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination of
their C programs.” (Robert Firth)
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
Zack Weinberg za...@panix.com writes: On Tue, Jan 20, 2009 at 2:31 PM, Zack Weinberg za...@panix.com wrote: I noticed a severe slowdown in the time for nvm.stripped to run the testsuite (from five to twelve minutes on my big beefy quad-core machine) which *seems* to be all down to initializing botan's RNG. Most subcommands don't use cryptographic random numbers at all. I just pushed changes to .stripped that make us wait to instantiate a RandomNumberGenerator object until we actually need one (under the =1.7.7 API). That takes the testsuite runtime back down to a little more than five minutes. I consider the performance with botan 1.8.0 acceptable now. I'm pretty happy with .stripped. I was able to muck out an incredible amount of gunk from the configure script, and if we get rid of netxx even more can go. The binary's smaller, the build is faster, and the Debian security team will be happy with us. What remains to be done before we can land it? There is still the mysterious libintl-11.dll on MinGW. I have not been able to work on this; the MS developer SDK is only available as a DVD image, and I don't have the facilities to burn a DVD. Folks with exotic systems (non-Linux, non-*BSD) might wanna check what I did to the configure script, btw. I might have been overoptimistic. :-/ I don't have my MinGW box available at the moment; it's my work laptop, and I normally leave it at work. I'll look into changes since the mini-summit when I have time. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.stripped versus botan
Stephen Leake wrote: I have not been able to work on this; the MS developer SDK is only available as a DVD image, and I don't have the facilities to burn a DVD. You can mount it using the free MagicDisc or similar tools. http://www.magiciso.com/tutorials/miso-magicdisc-overview.htm -- Lapo Luchini - http://lapo.it/ “Few false ideas have more firmly gripped the minds of so many intelligent men than the one that, if they just tried, they could invent a cipher that no one could break.” (David Kahn) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Sat, Jan 24, 2009 at 6:35 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: I have not been able to work on this; the MS developer SDK is only available as a DVD image, and I don't have the facilities to burn a DVD. You should be able to mount it on linux over the loopback device with something like: $ mount -o loop -t iso9660 /tmp/foo.isa /mnt/iso I don't know if that helps though, if you're running on windows. Maybe you can do that on linux, assuming your laptop is dual boot, and copy the contents to a fat partition, assuming you have one with enough free space kicking around. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Sat, Jan 24, 2009 at 2:27 AM, Lapo Luchini l...@lapo.it wrote: ... In file included from ./sanity.hh:19, from win32/read_password.cc:12: ./numeric_vocab.hh:45:44: macro max requires 2 arguments, but only 1 given ... 45T mask = std::numeric_limitsT::max(); At first glance that looks like heinous breakage in the system headers, but it occurs to me that I changed the way we detect Windows and it might be mis-classifying Cygwin. Can you compile mainline on Cygwin, and how are the Makefile conditionals set after you run configure on mainline? (You can just grep for _PLATFORM in config.status and post the gobbledygook that it outputs. I know how to read it.) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Sat, Jan 24, 2009 at 09:34:52PM -0800, Zack Weinberg wrote: At first glance that looks like heinous breakage in the system headers Win32 does indeed have min() and max() macros, by default in windows.h One can define NOMINMAX before including th header to disable this 'feature', or just undef them directly. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Sun, Jan 25, 2009 at 12:41:27AM -0500, Jack Lloyd wrote: On Sat, Jan 24, 2009 at 09:34:52PM -0800, Zack Weinberg wrote: At first glance that looks like heinous breakage in the system headers Win32 does indeed have min() and max() macros, by default in windows.h One can define NOMINMAX before including th header to disable this 'feature', or just undef them directly. Or in the code in question, I suppose just reorder the includes of sanity.hh and windows.h -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.stripped versus botan
Zack Weinberg wrote: Can you compile mainline on Cygwin, and how are the Makefile conditionals set after you run configure on mainline? (You can just grep for _PLATFORM in config.status and post the gobbledygook that it outputs. I know how to read it.) nvm: % fgrep _PLATFORM config.status S[AIX_PLATFORM_FALSE]= S[AIX_PLATFORM_TRUE]=# S[WIN32_PLATFORM_FALSE]= S[WIN32_PLATFORM_TRUE]=# nvm.stripped: % fgrep _PLATFORM config.status S[WIN32_PLATFORM_FALSE]=# S[WIN32_PLATFORM_TRUE]= Yes, it seems to be at reverse indeed... -- Lapo Luchini - http://lapo.it/ “You don't have to distrust the government to want to use cryptography.” (Phil Zimmermann) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.stripped versus botan
On Tue, Jan 20, 2009 at 2:31 PM, Zack Weinberg za...@panix.com wrote: I noticed a severe slowdown in the time for nvm.stripped to run the testsuite (from five to twelve minutes on my big beefy quad-core machine) which *seems* to be all down to initializing botan's RNG. Most subcommands don't use cryptographic random numbers at all. I just pushed changes to .stripped that make us wait to instantiate a RandomNumberGenerator object until we actually need one (under the =1.7.7 API). That takes the testsuite runtime back down to a little more than five minutes. I consider the performance with botan 1.8.0 acceptable now. I'm pretty happy with .stripped. I was able to muck out an incredible amount of gunk from the configure script, and if we get rid of netxx even more can go. The binary's smaller, the build is faster, and the Debian security team will be happy with us. What remains to be done before we can land it? Folks with exotic systems (non-Linux, non-*BSD) might wanna check what I did to the configure script, btw. I might have been overoptimistic. :-/ zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Tue, Jan 20, 2009 at 10:05 PM, Jack Lloyd ll...@randombit.net wrote: ... In particular I'd prefer not to simply disable particular sources, unless there really is no other workable solution. Having spent all of 3 minutes thinking about it, I'm wondering if the thing to do is drop the fast poll/slow poll distinction, which is pretty artificial, and instead use a notion like polling for no more than a given amount of time (possibly returning nothing if the source believes it cannot successfully poll in the given time slot [*]), or polling for a certain # of bits of entropy (estimated based on the particular sources knowledge/assumptions about what it is doing), or maybe both. This sounds like it's going in the right direction. Something else to consider is that the RNG user might like to specify a quality parameter, based on what's being done with the randomness, and sources could use that to adjust their behavior. For instance, I understand that best practice on Linux is only to use /dev/random for long-lived random numbers, such as stored keys; for nonces and session keys using only /dev/urandom is considered more considerate to other entropy users on the same system. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
Zack Weinberg wrote: On Tue, Jan 20, 2009 at 4:16 PM, Jack Lloyd ll...@randombit.net wrote: That said, it's no good to slow mtn startup down so much since that is clearly not the Right Thing either. Do you think we could get away with skipping es_unix if we have something else, though? That's the really slow one. Indeed using --disable-modules=unix_procs while configuring botan makes a huge difference for monotone's startup time. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.stripped versus botan
On Tue, Jan 20, 2009 at 02:31:30PM -0800, Zack Weinberg wrote: Jack - Can we get this fixed in botan? It seems to me that the Right Thing is for each entropy source to report whether it works on a particular system, and then for the RNG object to use only the first one that works. Thus, if we've got /dev/random we don't even look for EGD, if we've got EGD we don't try the programs, and so on. I don't think I buy that this really is the Right Thing, because while an entropy source can claim it works or not, in the sense that it will produce some output, it really has no way of knowing if that output is in any way random/unguessable by an attacker, which is really the purpose of this code. For instance in the case of /dev/random - normally it's probably good enough on its own, but at the same time I audited several implementations (mostly in fairly obscure OSes, admittedly), that turned out to have very weak implementations (RC4 seeded with boot time, or even worse). And personally I do not trust the implementations in, for instance, Linux or FreeBSD to actually live up to their claim that 1 bit of /dev/random output contains 1 bit of conditional entropy (the paper Analysis of the Linux Random Number Generator contains some analysis on this topic for Linux - http://www.pinkas.net/PAPERS/gpr06.pdf). That said, it's no good to slow mtn startup down so much since that is clearly not the Right Thing either. Also, I'm confused about the use of high-resolution timers as entropy sources -- it seems like they don't belong, or at least ought to be subordinated to the real entropy sources. Maybe the idea is to avoid dipping into the more expensive entropy pools as much? Only I'm not sure I trust rdtsc (e.g.) to give entropy *at all*... The current approach, as you know, is highly kitchen sink. That is why, for instance, rdtsc/rpcc/etc is used - it's basically free (especially compared to the alternatives, which at a minimum will make a syscall) and it _might_ well provide a nibble or two of entropy, especially if the local machine is safe and attackers only have remote acess. The PRNG is designed such that even if some or most of the inputs are known, guessed, or chosen by an attacker, as long as some sufficient amount is not known/guessable the PRNGs output will also remain hard to guess. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Tue, Jan 20, 2009 at 4:16 PM, Jack Lloyd ll...@randombit.net wrote: ... while an entropy source can claim it works or not, in the sense that it will produce some output, it really has no way of knowing if that output is in any way random/unguessable by an attacker, which is really the purpose of this code. For instance in the case of /dev/random - normally it's probably good enough on its own, but at the same time I audited several implementations (mostly in fairly obscure OSes, admittedly), that turned out to have very weak implementations (RC4 seeded with boot time, or even worse). And personally I do not trust the implementations in, for instance, Linux or FreeBSD to actually live up to their claim that 1 bit of /dev/random output contains 1 bit of conditional entropy (the paper Analysis of the Linux Random Number Generator contains some analysis on this topic for Linux - http://www.pinkas.net/PAPERS/gpr06.pdf). That said, it's no good to slow mtn startup down so much since that is clearly not the Right Thing either. Do you think we could get away with skipping es_unix if we have something else, though? That's the really slow one. The author of the Linux /dev/random responded to that paper here: http://lkml.indiana.edu/hypermail/linux/kernel/0605.2/0299.html and if you check http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/char/random.c;h=7c13581ca9cd6ac1ea4a2d54e80397831cebd75f;hb=HEAD you can see that there have been a whole bunch of fixes since the paper was written, although I can't tell if any of them specifically address the authors' concerns. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped versus botan
On Tue, Jan 20, 2009 at 09:11:06PM -0800, Zack Weinberg wrote: Do you think we could get away with skipping es_unix if we have something else, though? That's the really slow one. Probably, yes. However what I would like to do here is figure out a seeding discipline such that - The default initial seed is reasonbly safe - The default seed is fast enough that nobody minds [or at least minds enough to complain to me ;)] - If someone wants to, they can initiate a seed using some, or all, of the sources. In particular I'd prefer not to simply disable particular sources, unless there really is no other workable solution. Having spent all of 3 minutes thinking about it, I'm wondering if the thing to do is drop the fast poll/slow poll distinction, which is pretty artificial, and instead use a notion like polling for no more than a given amount of time (possibly returning nothing if the source believes it cannot successfully poll in the given time slot [*]), or polling for a certain # of bits of entropy (estimated based on the particular sources knowledge/assumptions about what it is doing), or maybe both. [*] For instance by keeping a running average of some kind of how long previous poll requests took; I'm not sure if doing this is actually clever or cleverly stupid. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
Markus Wanner [EMAIL PROTECTED] writes: With these fixes I've been able to compile and successfully test monotone against all of these sqlite versions: 3.3.8 (as currently included in debian etch / stable) 3.3.12 3.3.17 3.4.1 (what we shipped up to now) 3.5.9 (as currently included in debian lenny / testing) 3.6.3 (newest upstream release) This raises an issue for the test suite and buildbots. Assuming we eventually integrate this branch into mainline, how many versions of sqlite (and all the other libraries!) do we need the buildbots to test? And do we want to get into testing all possible combinations of library versions? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
Hi, Stephen Leake wrote: Assuming we eventually integrate this branch into mainline, how many versions of sqlite (and all the other libraries!) do we need the buildbots to test? I think it's sufficient supporting the library versions shipped with the distributions. And do we want to get into testing all possible combinations of library versions? Certainly not *all* possible combinations. I'd say we don't even need to test every single patch version of each library. After all, these (should) provide a stable API and ABI. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
Derek Scherger schrieb: On Sun, Oct 12, 2008 at 2:49 PM, Zack Weinberg [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I put some patches on .library-build to deal with this. The 'best effort' functionality is not available in 1.5 as far as I know, but I don't know any reason why the //TRANSLIT//IGNORE thing that we had before the 'best effort' patches isn't good enough... Lapo is perhaps That's what I was wondering too. I also wonder if maybe libidn might have fixed the problem in the intervening 5 years since Graydon grabbed a copy. IIRC Lapo was fighting with the changelog comment on one particular revision in the monotone history. It would be interesting to have this test case if we can dig it up. In the meantime I'll probably just move the //TRANSLIT stuff up into charset.cc and then go ahead with switching to the system installed libidn. Isn't the //TRANSLIT//IGNORE thing a libiconv or gettext issue? It shouldn't have anything to do with libidn in particular. Regards, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
Hi, I've now corrected or worked around issues with various sqlite versions. These tests have failed before: Markus Wanner wrote: 146 database_checkFAIL (line 23) 216 i_selectorFAIL (line 32) Revision 40dba08582bcb2eecde9c9700fcab85b11f2ff61 adds a 'hex()' function for sqlite versions below 3.3.13, which didn't have that, yet. That made these two tests succeed for sqlite 3.3.8 - 3.3.13. 192 empty_environment FAIL (line 29) The 'empty_environment' test does no longer completely wipe the environment, but maintains the given LD_LIBRARY_PATH environment variable. This only works under Linux for now. I'm lacking any other systems to test on. Added in rev f67d1482d7c2aa37adaeeb7db09161be9dc8b616 This should also help other linked libraries. 203 fail_cleanly_on_unreadable_db unexpected success Rev b268fec033da5902f6af76e8e56b2ace759e090f fixes this issue by removing he offending checks. Investigating revealed, that newer sqlite3 versions are trying to read/write a journal file in the same directory where the database resides. That of course fails for unreadable, but only searchable directories. Here's an strace of sqlite3 trying to open a journal file on a a-rw+x parent directory '/home/markus/test': open(/home/markus/test/test.db-journal, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE|O_NOFOLLOW, 0644) = 4 open(/home/markus/test, O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied) close(4) With these fixes I've been able to compile and successfully test monotone against all of these sqlite versions: 3.3.8 (as currently included in debian etch / stable) 3.3.12 3.3.17 3.4.1 (what we shipped up to now) 3.5.9 (as currently included in debian lenny / testing) 3.6.3 (newest upstream release) I didn't care to test anything older than 3.3.8. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
Hi, Markus Wanner wrote: 3.4.1 (what we shipped up to now) Oops, revoking that. 3.4.1 and 3.4.2 currently fail on test 'database_dump_load', which is fishy because 3.4.1 was integrated before, no? I'm investigating on the issue. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
Hi, Derek Scherger wrote: I've made this change Cool, thanks. and also moved sqlite to the Attic ..oops, looks like we've done duplicate work. I've just committed and pushed what I have. It's not quite complete, yet (rev 4c625e162bf17c69406de23482187313dafd29cd). Have you pushed your work, yet? which went much more smoothly than I was expecting since it involved upgrading from 3.4.2 to 3.5.9. One test fails with this later change, fail_cleanly_on_unreadable_db, which I assume is an actual change in sqlite behaviour but I'm not certain of this. Yes, Ralf S. Engelschall has noted that before, see my other mail. I've tested my variant against sqlite 3.3.8 (included in debian etch), 3.5.9 (debian testing, IIRC) and 3.6.3 (current stable release). These tests fail: sqlite 3.3.8: 146 database_checkFAIL (line 23) 192 empty_environment FAIL (line 29) 203 fail_cleanly_on_unreadable_db unexpected success 216 i_selectorFAIL (line 32) (does not have the 'hex()' function, but obviously works like we expect for 'fail_cleanly_on_unreadable_db') sqlite 3.5.9: 192 empty_environment FAIL (line 29) 203 fail_cleanly_on_unreadable_db FAIL (line 62) sqlite 3.6.3: 192 empty_environment FAIL (line 29) 203 fail_cleanly_on_unreadable_db FAIL (line 62) The 'empty_environment' test fails due to LD_LIBRARY_PATH required for building against libraries in non-standard locations. I'm now looking at idna (libidn) which ought to be easy but isn't because of some changes that were made at the 2007 summit iirc. Lapo, do you recall the best effort stuff that got added to idna/toutf8.c? This is not in idna 1.5 but I'm wondering if maybe idna 1.5 might just do the right thing? Okay, so I let you take care of libidn. If you don't mind, I'll follow the sqlite things and try to fix those tests. Certainly not today, though. ... just trying to avoid duplicate work... Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Sun, Oct 12, 2008 at 7:31 AM, Markus Wanner [EMAIL PROTECTED] wrote: and also moved sqlite to the Attic ..oops, looks like we've done duplicate work. I've just committed and pushed what I have. It's not quite complete, yet (rev 4c625e162bf17c69406de23482187313dafd29cd). Have you pushed your work, yet? Heh, just noticed that too. I've merged and pushed so things are good. I removed -DTEMP_STORE from AM_CFLAGS in Makefile.am in the merged version. As near as I can tell this was only relevant for SQLITE. Okay, so I let you take care of libidn. If you don't mind, I'll follow the sqlite things and try to fix those tests. Certainly not today, though. ... just trying to avoid duplicate work... Sure, sounds good. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Sun, Oct 12, 2008 at 09:53:34AM -0600, Derek Scherger wrote: Heh, just noticed that too. I've merged and pushed so things are good. I removed -DTEMP_STORE from AM_CFLAGS in Makefile.am in the merged version. As near as I can tell this was only relevant for SQLITE. Two things on nvm.stripped (rev b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1) I am warned: Makefile.am:339: whitespace following trailing backslash There is a trailing tab on that line. Also, here is the output currently when configure encounters a version of Botan from the future: checking for Botan... configure: WARNING: Your botan library version (1.7.18) is newer than expected. Monotone might not build cleanly. yes (version 1.7.18) By reordering the messages in botan.m4 # # old_revision [b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1] # # patch m4/botan.m4 # from [c3b115c9be716601db0f21612a5a6b1e4ac720ab] #to [e9cd9dc87a81965e626353055f6c58c86a63d947] # --- m4/botan.m4 c3b115c9be716601db0f21612a5a6b1e4ac720ab +++ m4/botan.m4 e9cd9dc87a81965e626353055f6c58c86a63d947 @@ -43,13 +43,14 @@ AC_DEFUN([MTN_FIND_BOTAN], #endif], [botan_version_match=yes], [botan_version_match=no]) -if test $botan_version_match = no; then - AC_MSG_WARN([Your botan library version ($BOTAN_VERSION) is newer than expected. Monotone might not build cleanly.]) -fi CPPFLAGS=$save_CPPFLAGS AC_MSG_RESULT([yes (version $BOTAN_VERSION)]) +if test $botan_version_match = no; then + AC_MSG_WARN([Your botan library version ($BOTAN_VERSION) is newer than expected. Monotone might not build cleanly.]) +fi + # AC_MSG_NOTICE([using botan compile flags: $BOTAN_CPPFLAGS]) # AC_MSG_NOTICE([using botan link flags: $BOTAN_LIBS]) more readable output is produced: checking for Botan... yes (version 1.7.18) configure: WARNING: Your botan library version (1.7.18) is newer than expected. Monotone might not build cleanly. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Sun, Oct 12, 2008 at 10:13 AM, Jack Lloyd [EMAIL PROTECTED] wrote: Two things on nvm.stripped (rev b6c549d4c9c28227000b62a3fe26b8e9aa7d6ab1) I am warned: Makefile.am:339: whitespace following trailing backslash There is a trailing tab on that line. Also, here is the output currently when configure encounters a version of Botan from the future: checking for Botan... configure: WARNING: Your botan library version (1.7.18) is newer than expected. Monotone might not build cleanly. yes (version 1.7.18) By reordering the messages in botan.m4 more readable output is produced: checking for Botan... yes (version 1.7.18) configure: WARNING: Your botan library version (1.7.18) is newer than expected. Monotone might not build cleanly. Thanks, I've committed these changes in 17398bbfe76852cb9ac73cf3cb13912050982e1a Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Sat, Oct 11, 2008 at 9:28 PM, Derek Scherger [EMAIL PROTECTED] wrote: I'm now looking at idna (libidn) which ought to be easy but isn't because of some changes that were made at the 2007 summit iirc. Lapo, do you recall the best effort stuff that got added to idna/toutf8.c? This is not in idna 1.5 but I'm wondering if maybe idna 1.5 might just do the right thing? I put some patches on .library-build to deal with this. The 'best effort' functionality is not available in 1.5 as far as I know, but I don't know any reason why the //TRANSLIT//IGNORE thing that we had before the 'best effort' patches isn't good enough... Lapo is perhaps the only person who would know. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Sun, Oct 12, 2008 at 2:49 PM, Zack Weinberg [EMAIL PROTECTED] wrote: I put some patches on .library-build to deal with this. The 'best effort' functionality is not available in 1.5 as far as I know, but I don't know any reason why the //TRANSLIT//IGNORE thing that we had before the 'best effort' patches isn't good enough... Lapo is perhaps That's what I was wondering too. I also wonder if maybe libidn might have fixed the problem in the intervening 5 years since Graydon grabbed a copy. IIRC Lapo was fighting with the changelog comment on one particular revision in the monotone history. It would be interesting to have this test case if we can dig it up. In the meantime I'll probably just move the //TRANSLIT stuff up into charset.cc and then go ahead with switching to the system installed libidn. the only person who would know. Yeah, hopefully he reads some of this at some point. ;) Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Thu, Oct 9, 2008 at 7:43 PM, Jack Lloyd [EMAIL PROTECTED] wrote: On Thu, Oct 09, 2008 at 07:39:51PM -0600, Derek Scherger wrote: Looking at the current checks for botan versions it seems that if I happened to have 1.8.12 we would let it in because we check for major ==1 and patch between 8 and 17. Would using the version macros that botan defines be a better way to check things? +1 I've made this change and also moved sqlite to the Attic which went much more smoothly than I was expecting since it involved upgrading from 3.4.2 to 3.5.9. One test fails with this later change, fail_cleanly_on_unreadable_db, which I assume is an actual change in sqlite behaviour but I'm not certain of this. I'm now looking at idna (libidn) which ought to be easy but isn't because of some changes that were made at the 2007 summit iirc. Lapo, do you recall the best effort stuff that got added to idna/toutf8.c? This is not in idna 1.5 but I'm wondering if maybe idna 1.5 might just do the right thing? Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Thu, Oct 09, 2008 at 11:08:40AM +0200, Markus Wanner wrote: I've removed my system wide botan and can confirm that the issue is solved now. (As of e5f6d85442972da43d641bd3d7bf5d6667bbd23a). Works here too. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
Hi, Jack Lloyd wrote: OK, if I change in botan.m4 -CFLAGS=$CFLAGS $BOTAN_CPPFLAGS +CPPFLAGS=$CPPFLAGS $BOTAN_CPPFLAGS Ah! Thank you very much for pointing this out. Looks like configure on my system simply picked the system installed botan during that stage, but then continued to use the provided botan :-( I've removed my system wide botan and can confirm that the issue is solved now. (As of e5f6d85442972da43d641bd3d7bf5d6667bbd23a). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Thu, Oct 09, 2008 at 11:08:40AM +0200, Markus Wanner wrote: Hi, Jack Lloyd wrote: OK, if I change in botan.m4 -CFLAGS=$CFLAGS $BOTAN_CPPFLAGS +CPPFLAGS=$CPPFLAGS $BOTAN_CPPFLAGS Ah! Thank you very much for pointing this out. Looks like configure on my system simply picked the system installed botan during that stage, but then continued to use the provided botan :-( I've removed my system wide botan and can confirm that the issue is solved now. (As of e5f6d85442972da43d641bd3d7bf5d6667bbd23a). I've attached some changes to botan.m4 Use quotes around #error messages - I saw spurious GCC errors that popped up about the use of unmatched single quotes and punct - these errors might be confusing to someone trying to debug a build problem. Accept versions up to 1.7.17 (which is basically just ticking the sover up on mainline post-1.7.16, nothing substantial so far). [It Works For Me (tm)] Print the found version of Botan (perhaps mildly informative to the user, and the version is already in a variable for us). -Jack # # old_revision [e5f6d85442972da43d641bd3d7bf5d6667bbd23a] # # patch m4/botan.m4 # from [f6702730c3d9eb82ccc969d705d200dfa34f5581] #to [910876c2b7187e564deb220e01b953d36cb55cc8] # --- m4/botan.m4 f6702730c3d9eb82ccc969d705d200dfa34f5581 +++ m4/botan.m4 910876c2b7187e564deb220e01b953d36cb55cc8 @@ -1,6 +1,6 @@ # Currently we accept botan version 1.7.8 and newer, limited to the # development branch 1.7, emitting a warning if the found botan is -# newer than 1.7.16. +# newer than 1.7.17. AC_DEFUN([MTN_FIND_BOTAN], [ @@ -25,11 +25,11 @@ AC_DEFUN([MTN_FIND_BOTAN], #include botan/build.h #ifndef BOTAN_VERSION_MAJOR -#error Botan didn't define version macros?!? +#error Botan did not define version macros #endif #if BOTAN_VERSION_MAJOR != 1 -#error Botan major version mismatch. +#error Botan major version mismatch #endif], [botan_version_match=yes], [botan_version_match=no]) @@ -43,7 +43,7 @@ AC_DEFUN([MTN_FIND_BOTAN], #include botan/build.h #if BOTAN_VERSION_PATCH 8 -#error Botan is too old +#error Botan is too old #endif], [botan_version_match=yes], [botan_version_match=no]) @@ -56,7 +56,7 @@ AC_DEFUN([MTN_FIND_BOTAN], AC_PREPROC_IFELSE([ #include botan/build.h -#if BOTAN_VERSION_PATCH 16 +#if BOTAN_VERSION_PATCH 17 #error Botan from the future #endif], [botan_version_match=yes], @@ -66,7 +66,7 @@ AC_DEFUN([MTN_FIND_BOTAN], fi CPPFLAGS=$save_CPPFLAGS -AC_MSG_RESULT([yes]) +AC_MSG_RESULT([yes ($BOTAN_VERSION)]) AC_MSG_NOTICE([using botan compile flags: $BOTAN_CPPFLAGS]) AC_MSG_NOTICE([using botan link flags: $BOTAN_LIBS]) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
Looking at the current checks for botan versions it seems that if I happened to have 1.8.12 we would let it in because we check for major ==1 and patch between 8 and 17. Would using the version macros that botan defines be a better way to check things? Here's what I'm talking about: # # old_revision [65c86292f2fe48513d3838b348c8b3b745c80d80] # # patch m4/botan.m4 # from [af36e8abd5d4a0159409387ab8cd56c55dcb00de] #to [c3b115c9be716601db0f21612a5a6b1e4ac720ab] # --- m4/botan.m4af36e8abd5d4a0159409387ab8cd56c55dcb00de +++ m4/botan.m4c3b115c9be716601db0f21612a5a6b1e4ac720ab @@ -22,27 +22,9 @@ AC_DEFUN([MTN_FIND_BOTAN], save_CPPFLAGS=$CPPFLAGS CPPFLAGS=$CPPFLAGS $BOTAN_CPPFLAGS AC_PREPROC_IFELSE([ -#include botan/build.h +#include botan/version.h -#ifndef BOTAN_VERSION_MAJOR -#error Botan did not define version macros -#endif - -#if BOTAN_VERSION_MAJOR != 1 -#error Botan major version mismatch. -#endif], -[botan_version_match=yes], -[botan_version_match=no]) -if test $botan_version_match = no; then - AC_MSG_RESULT([no]) - AC_MSG_ERROR([Your botan library version not match ($BOTAN_VERSION).]) -fi - -# prevent from building against older, no longer supported versions -AC_PREPROC_IFELSE([ -#include botan/build.h - -#if BOTAN_VERSION_PATCH 8 +#if BOTAN_VERSION_CODE BOTAN_VERSION_CODE_FOR(1,7,8) #error Botan is too old #endif], [botan_version_match=yes], @@ -54,9 +36,9 @@ AC_DEFUN([MTN_FIND_BOTAN], # check against unknown versions from the future and warn AC_PREPROC_IFELSE([ -#include botan/build.h +#include botan/version.h -#if BOTAN_VERSION_PATCH 17 +#if BOTAN_VERSION_CODE BOTAN_VERSION_CODE_FOR(1,7,17) #error Botan from the future #endif], [botan_version_match=yes], Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Thu, Oct 09, 2008 at 07:39:51PM -0600, Derek Scherger wrote: Looking at the current checks for botan versions it seems that if I happened to have 1.8.12 we would let it in because we check for major ==1 and patch between 8 and 17. Would using the version macros that botan defines be a better way to check things? +1 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.stripped
Hello Jack, Jack Lloyd wrote: On Tue, Oct 07, 2008 at 01:10:55PM +0200, Markus Wanner wrote: Hm.. you manually added 'botan-config' from /home/lloyd/.. to your PATH, right? Yes (and edited it slightly so it would produce the right output for an in-dir build) Are you sure this emits proper CFLAGS and LIBS? Is the PATH set correctly? Have you recreated configure from configure.ac of monotone before retrying? Not so far, but I'll check the issue. Sorry, I cannot reproduce this issue. When installing botan to /usr/botan/include. In that case I get these from the resulting botan-config: # PATH=/usr/local/botan/bin:$PATH botan-config --libs --cflags -L/usr/local/botan/lib -lm -lpthread -lrt -lbotan -I/usr/local/botan/include With the same PATH variable set, monotone's configure correctly finds the installed botan and spits out the following: checking for Botan version 1.7.8 or newer... yes configure: using botan compile flags: -I/usr/local/botan/include configure: using botan link flags: -L/usr/local/botan/lib -lm -lpthread -lrt -lbotan Checking with ldd (and a proper LD_LIBRARY_PATH) confirms that monotone got built against the library in /usr/local/botan/libs. The tests succeed, except for empty_environment, which fails to load the botan library due to a cleaned up LD_LIBRARY_PATH. We need to adjust that test to support builds against libraries in non-standard locations. However, I want to make sure my modifications work on Windozen as well. I've adjusted the m4 scripts a bit, mostly cosmetics, though. monotone is not also accepting the upcoming botan 1.7.16 and builds cleanly against it (mtn rev 3030f61139f208ffd7c91ad13d88d9a376bc6139). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.stripped
On Wed, Oct 08, 2008 at 10:30:21AM +0200, Markus Wanner wrote: Are you sure this emits proper CFLAGS and LIBS Yes. Normally botan-config will not produce the right thing for pointing in-workspace Botan builds, but I made the modifications I wanted in src/build-data/botan-config.in so that the paths are set correctly. This is what I do when I am testing other things (Ajisai, Botan examples and lang wrappers, etc) against a workspace build (I don't even have any version of Botan installed on my system (except in /usr/bin/mtn (but that's not visible))). (I checked in my changes as some commented out lines in src/build-data/botan-config.in, if you uncomment those and comment out the normal install lines you will hopefully be able to replicate my setup) Is the PATH set correctly? As far as I know. Have you recreated configure from configure.ac of monotone before retrying? Yes. I pulled down latest as of now (3030f61139f208ffd7c91ad13d88d9a376bc6139), did aclocal-1.9 autoreconf --install, and reconfigured: same thing. The latest config log: configure:12728: g++ -E -g -O2 -fno-strict-aliasing -fexceptions conftest.cpp conftest.cpp:2:25: error: botan/build.h: No such file or directory conftest.cpp:5:2: error: #error Botan did not define version macros?!? conftest.cpp:9:2: error: #error Botan major version mismatch. configure:12734: $? = 1 configure: failed program was: | | #include botan/build.h | | #ifndef BOTAN_VERSION_MAJOR | #error Botan did not define version macros?!? | #endif | | #if BOTAN_VERSION_MAJOR != 1 | #error Botan major version mismatch. | #endif (The did not vs didn't is because GCC doesn't like the single quote mark - probably you missed that since you cannot replicate thus this would not have been triggered). From a shell: (motoko ~/projects/monotone-stripped)$ botan-config --cflags -I/home/lloyd/projects/botan/mainline/build/include (motoko ~/projects/monotone-stripped)$ botan-config --libs -L/home/lloyd/projects/botan/mainline/ -lm -lpthread -lrt -lbotan So I still don't get it... -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
On Wed, Oct 08, 2008 at 11:07:13AM -0400, Jack Lloyd wrote: On Wed, Oct 08, 2008 at 10:30:21AM +0200, Markus Wanner wrote: Are you sure this emits proper CFLAGS and LIBS OK, if I change in botan.m4 -CFLAGS=$CFLAGS $BOTAN_CPPFLAGS +CPPFLAGS=$CPPFLAGS $BOTAN_CPPFLAGS Then Botan's -I flags got picked up properly. $ autoconf --version autoconf (GNU Autoconf) 2.61 -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: nvm.stripped
Hello Jack, Jack Lloyd wrote: Currently (rev 44c07854971c158f07da7f53d811d2e298c3f354) I am seeing this: $ ./configure [the usual configure output] checking for Botan version 1.7.8 or newer... no configure: error: Your botan library version not match (1.7.15). Hm.. thanks for this notification. I've never tried non-standard locations so far. Note that at compilation no cflags (such as -I) are set. Against my local workspace, botan-config does this: $ botan-config --cflags -I/home/lloyd/projects/botan/mainline/build/include $ botan-config --libs -L/home/lloyd/projects/botan/mainline/ -lm -lpthread -lrt -lbotan $ botan-config --version 1.7.15 Hm.. you manually added 'botan-config' from /home/lloyd/.. to your PATH, right? And I checked with an echo that botan_CFLAGS is being set properly. (My Botan workspace was configured and I confirmed that build/include/botan/build.h did exist, so it should have found it, if the -I flag had been passed to g++) Any ideas? Not so far, but I'll check the issue. Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
