[Monotone-devel] nvm.stripped on cygwin
...is basically working. Needs the existing pcre, libidn, sqlite3 packages. Needs also botan and lua, which are currently not packages, though I have an almost-ready package for the first and found a complete package for the second on CygPorts (an unofficial repository of source packages); I will probably propose as maintainer for those two in order to be able to create a package for monotone 0.43 (which I hope will be "stripped"). Configuration needs only the usual path for Boost: nice sh -c 'autoreconf -i && CXXFLAGS="-ggdb -I/usr/include/boost-1_33_1" ./configure && make' The testsuite reported no error in the first group, while there were some in the second group, and then it stopped. It's been a while since my last check of the standard Cygwin build, so this might not be a regression. 132 clone_creates_right__MTN_options FAIL (line 27) 134 clone_warning_with_multiple_heads FAIL (line 20) 197 empty_environment FAIL (line 40) 441 ssh_agent ok error: could not remove '/cygdrive/c/Works/monotone/stripped/tester_dir/tests/ssh_agent': Device or resource busy == 1 of 3 test suites failed -- Lapo Luchini - http://lapo.it/ “It is dangerous to be right when the government is wrong.” (Voltaire) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] git fast-export
On Sun, Jan 18, 2009 at 1:18 AM, Paul Aurich wrote: > And Felipe Contreras spake on 01/17/2009 02:52 PM, saying: >> I ran my comparison script, but unfortunately the first revision has a >> missmatch: >> >> yours: >> author Tailor Script 953780991 + >> >> mine: >> author Tailor Script 953773791 +0200 >> >> Which suggest that your script is not handling the timezone correctly >> (not sure about that). > > No, his script is handling it properly (based solely on this example). > > Monotone uses UTC internally and git does some crazy wacky things with > timezones (in short, the timezone shown is /just/ for prettifying the date; > the timestamp by itself *must* be the time of the commit in UTC). See > https://kerneltrap.org/mailarchive/git/2007/2/6/237902 > > $ mtn automate certs d137c7046bae7e4a0144fee82bfce8061f61e3b3 | grep date > -A 1 > name "date" > value "2000-03-23T03:09:51" > > $ date -d "2000-03-23 03:09:51" -u > Thu Mar 23 03:09:51 UTC 2000 > $ date -d "2000-03-23 03:09:51" -u +"%s" > 953780991 True. Then the issue is with my script (ruby date parsing). It looks like I would have to re-generate my repo clone (yay for one whole day of conversion) for the comparison. Before I do that, can we agree on a format for unknown committers? -- Felipe Contreras ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped on Win32 MinGW; pkg-config
On Sat, Jan 17, 2009 at 9:09 PM, Stephen Leake wrote: > Since most of the required libraries support pkg-config, it would make > sense to use pkg-config with MinGW. > > However, there is a classic catch-22: > > pkg-config requires glib > > glib requies pkg-config > > !!! > > So I need a MinGW-compatible binary of one of the above to get > started. > > The hosting website for pkg-config > (http://pkgconfig.freedesktop.org/releases) has no binaries. > > The hosting website for glib (http://www.gtk.org) has Win32 dlls, but > not the .a files needed by MinGW gcc. > > Does anyone have a solution for this? Binaries of both pkg-config and glib are available here: http://www.gtk.org/download-windows.html The "dev" downloads for glib include the headers and link libraries. -D ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: times to load various things from the database
On Sat, Jan 10, 2009 at 11:58 PM, Derek Scherger wrote:
>
> Sat Jan 10 09:24 PM ~/monotone/mainline $ time ./mtn db load_rosters
> mtn: loading rosters
> mtn: rosters
> mtn: 14,499/14,499
>
> real25m11.219s
> user24m20.875s
> sys 0m44.263s
>
The following patch improves this by a factor of 3:
Sat Jan 17 09:47 PM ~/monotone/mainline $ time ./mtn db load_rosters
mtn: loading rosters
mtn: rosters
mtn: 14,541/14,541
real7m55.062s
user7m46.029s
sys 0m9.061s
This patch does three things:
- every time a base roster (i.e. fulltext) is loaded, it is inserted into
the roster cache. this seems generally useful as every roster reconstruction
will require a base roster to start from. loading a 350KB roster seems to
take about 30ms here, grabbing one from the cache is around 3ms.
- after a reconstruction path is loaded it is scanned in forward order
looking for a cached roster to start from. if one is found, the
reconstruction path is truncated at that point and reconstruction will start
from the closest cached roster.
- when applying a chain of deltas to a base roster, every 64th roster is
cached so that the previous step is likely to hit something.
I'm not sure if this is likely to cause problems with other aspects of
performance or not. I'll try timing the testsuite, a full pull and maybe a
db check as well with and without to see what it does.
I also wonder whether our cache sizes should be configured via lua hooks
rather than header file constants. A 7MB static cache size doesn't seem very
generous, sitting here on a an older system with 2GB of ram. I don't see
anything in the roster cache stuff to report on sizes, hit rates, etc. so
evaluating the cache performance would require more work.
Cheers,
Derek
#
# old_revision [cef7a2d9c06e0b96648cce7980c5e700b93f5add]
#
# patch "database.cc"
# from [1d015db8c66b3d39c37b2bb7b759f5b21854a6b8]
#to [3fe17463fadcd76df9fcc1d45b6a7b698e2d0bf8]
#
--- database.cc 1d015db8c66b3d39c37b2bb7b759f5b21854a6b8
+++ database.cc 3fe17463fadcd76df9fcc1d45b6a7b698e2d0bf8
@@ -1620,6 +1620,17 @@ database_impl::get_roster_base(revision_
data dat;
decode_gzip(dat_packed, dat);
read_roster_and_marking(roster_data(dat), roster, marking);
+
+ // cache this base roster
+
+ shared_ptr r(new roster_t);
+ shared_ptr m(new marking_map);
+ cached_roster cr;
+ *r = roster;
+ *m = marking;
+ cr.first = r;
+ cr.second = m;
+ roster_cache.insert_clean(ident, cr);
}
void
@@ -1988,6 +1999,15 @@ database::get_roster_version(revision_id
get_reconstruction_path(ros_id.inner(), graph, selected_path);
}
+ // scan the reconstruction path in forward order looking for a cache hit
+ // if we find one, truncate the reconstruction path at that point
+ for (size_t i = 0; i < selected_path.size(); ++i)
+if (imp->roster_cache.exists(revision_id(selected_path[i])))
+ {
+selected_path.resize(i+1);
+break;
+ }
+
id curr(selected_path.back());
selected_path.pop_back();
// we know that this isn't already in the cache (because of the early
exit
@@ -1996,6 +2016,7 @@ database::get_roster_version(revision_id
shared_ptr marking(new marking_map);
imp->get_roster_base(revision_id(curr), *roster, *marking);
+ int cache_count = 0;
for (reconstruction_path::reverse_iterator i = selected_path.rbegin();
i != selected_path.rend(); ++i)
{
@@ -2006,6 +2027,20 @@ database::get_roster_version(revision_id
imp->get_roster_delta(nxt, curr, del);
apply_roster_delta(del, *roster, *marking);
curr = nxt;
+
+ if (++cache_count % 64 == 0 &&
!imp->roster_cache.exists(revision_id(*i)))
+{
+ // insert the current roster into the cache
+ shared_ptr r(new roster_t);
+ shared_ptr m(new marking_map);
+ *r = *roster;
+ *m = *marking;
+ cached_roster cr;
+ cr.first = r;
+ cr.second = m;
+ imp->roster_cache.insert_clean(revision_id(*i), cr);
+}
+
}
// Double-check that the thing we got out looks okay. We know that when
@@ -2027,7 +2062,8 @@ database::get_roster_version(revision_id
// const'ify the objects, to save them and pass them out
cr.first = roster;
cr.second = marking;
- imp->roster_cache.insert_clean(ros_id, cr);
+ if (!imp->roster_cache.exists(ros_id))
+imp->roster_cache.insert_clean(ros_id, cr);
}
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped on Win32 MinGW; Botan
On Sat, Jan 17, 2009 at 7:26 PM, Stephen Leake wrote: >./tester: error while loading shared libraries: libbotan-1.8.0.so: >cannot open shared object file: No such file or directory > > and yet: > > ste...@localhost$ ls /usr/local/lib/libbotan* > /usr/local/lib/libbotan-1.8.0.so /usr/local/lib/libbotan.a > /usr/local/lib/libbotan.so > ste...@localhost$ > > Any ideas? > > hmm. what path is searched for libraries? maybe I need to add > /usr/local/lib to something? probably /etc/ld.so.conf? although, on my system, libc seems to have set that up already... zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped on Win32 MinGW; Botan
"Zack Weinberg" writes: > On Sat, Jan 17, 2009 at 6:03 PM, Stephen Leake > wrote: >> >> m4/botan.m4 says we need botan > 1.6.3, but not 1.7.14. >> >> However, on debian, I have 1.7.8-3, which configure accepts, but at >> runtime mtn says we need 1.7.22. > > If we can't build .stripped with what's currently in debian unstable, > I'd say we need to relax our requirements. I'm only looking in Debian stable and testing; Botan 1.8.0 is in Debian unstable. > However, on an unstable-only system I've got libbotan1.6 (version > 1.6.5-3) and libbotan1.8 (version 1.8.0-1) and no 1.7 anything. > (packages.debian.org leads me to believe that libbotan1.7 is in > testing but will be replaced by libbotan1.8 in the near future.) I'd > have no objection to requiring 1.8.0 or greater. Ok. Except that it doesn't work for me, when I installed from source: ./tester: error while loading shared libraries: libbotan-1.8.0.so: cannot open shared object file: No such file or directory and yet: ste...@localhost$ ls /usr/local/lib/libbotan* /usr/local/lib/libbotan-1.8.0.so /usr/local/lib/libbotan.a /usr/local/lib/libbotan.so ste...@localhost$ Any ideas? hmm. what path is searched for libraries? maybe I need to add /usr/local/lib to something? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped on Win32 MinGW; Botan
On Sat, Jan 17, 2009 at 6:57 PM, Zack Weinberg wrote: > (packages.debian.org leads me to believe that libbotan1.7 is in > testing but will be replaced by libbotan1.8 in the near future.) ... I should know to check the testing migration report before saying things like that. Please read "after Lenny is released" where I wrote "in the near future." :-P zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped on Win32 MinGW; Botan
On Sat, Jan 17, 2009 at 6:03 PM, Stephen Leake wrote: > > m4/botan.m4 says we need botan > 1.6.3, but not 1.7.14. > > However, on debian, I have 1.7.8-3, which configure accepts, but at > runtime mtn says we need 1.7.22. If we can't build .stripped with what's currently in debian unstable, I'd say we need to relax our requirements. However, on an unstable-only system I've got libbotan1.6 (version 1.6.5-3) and libbotan1.8 (version 1.8.0-1) and no 1.7 anything. (packages.debian.org leads me to believe that libbotan1.7 is in testing but will be replaced by libbotan1.8 in the near future.) I'd have no objection to requiring 1.8.0 or greater. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Dealing with lost key
Timothy Brownawell wrote: Dropping anything really doesn't work with our architecture. If *anyone* forgets to drop it, it will come back next time that person syncs. Ok, rather than dropping, perhaps there should be a way for a user to invalidate a set of certs and then create new certs to replace them. The idea being to tell monotone that certain certificates are known to be invalid (for example because a key has been discovered to be invalid or untrustworthy), but that we have other reasons to trust various certs (ie. we've validated the changes ourselves and even though the key can't be trusted, we want to trust the revisions based on our own certificates). Let me give an example use case (other than the one that I have already encountered). Person A has been contributing to a project that Person B is participating in. Person A trusts person B's key. Person B begins to write code that Person A does not approve of (say it has some hidden functionality, backdoors, etc). person A wants to invalidate person B's keys for all future contributions, but retain the work that was done by person B before. Person A also wants to communicate to other members of the collaboration that he does not trust person B, and that he has reviewed person B's code and only approves of some of the changes... I could imagine that this sort of thing might happen every so often... and right now monotone doesn't seem to provide a clear mechanism for this kind of trust revocation and/or secondary certification. Thanks again, Dan ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Dealing with lost key
On Sat, 2009-01-17 at 15:05 -0800, dlakelan wrote: > Timothy Brownawell wrote: > > On Thu, 2009-01-15 at 14:19 -0800, dlakelan wrote: > >> I've lost a key which has been used to certify a variety of things in > >> one project. I've generated a new key, and now I'd like to replace all > >> the old certificates with new certificates from the new key, and have my > >> collaborators do the same... so we don't get a lot of warnings about > >> incorrect certs. How can I do this? > > > > There's no simple way to replace certs like that, the easiest solution > > is to just keep them and make sure the new key has a different name. > ... > > If you really do need to delete the old certs and generate new ones, > > something along these lines would probably work (not tested, may ruin > > your db)... > > > Thanks for your suggestions. I think we will simply keep the old public > key and certs. > > If there is no way to invalidate a key, then it seems difficult to deal > with a security issue such as when a key is compromised and that key may > be signing malicious code which collaborators are unaware of... for example. > > From a security standpoint, it seems to me that monotone should have a > way to at the very least, expire trust in a key. Currently the only way to do that is with the get_revision_cert_trust lua hook, http://monotone.ca/docs/Hooks.html#Trust-Evaluation-Hooks which will have to be set up by everyone. (Yes, we know this isn't ideal.) > Also, if asked to generate a new key, monotone should refuse if that key > name is already known to monotone, unless some kind of > --force-overwrite-key switch is given...perhaps it already does? It does. > Finally, the documentation should stress the fact that two keys with the > same name are not supported... ...I guess this would go in the Conecpts => Certificates section (1.4). > and it seems to me that it should be > possible within monotone to ask it to drop signatures and to re-sign > certificates with a new key. Dropping anything really doesn't work with our architecture. If *anyone* forgets to drop it, it will come back next time that person syncs. > Thanks to the monotone developers for a very nice revision control system! > Dan :) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] encrypted netsync (was: merging in "serve raw 'automate stdio' over network")
On Sat, 2009-01-17 at 19:44 -0600, Matthew Nicholson wrote: > Timothy Brownawell wrote: > > > > I should also mention that I'm thinking we eventually want to move to > > SSH2 for encryption/authentication (pending finding a good server-side > > SSH2 library, there only seem to be client-only libraries available > > now). This would let us only need to listen in one place for both > > netsync and stdio (and whatever else we might come up with), and would > > also mean not needing to keep our own authentication code or write our > > own encryption code (I know I've seen requests for encrypted netsync). > > Why ssh2 and not ssl/tls encryption? Just curious. I imagine ssl > libraries would be more prevalent. Because it didn't occur to me, probably because the main tls use I know is authenticating the server (mostly I think of https) while we also/mainly want to authenticate the client (which is what ssh is used for). We'd need our own multiplexing, but that should be quite a lot less work than pulling a library out of an ssh server. > And instead of relying on SSH for > authentication, we could add the option of using PAM for authentication > which is what SSH uses anyway. No, probably better to keep using keys for that. I had been thinking ssh pubkey authentication, but tls seems to allow for client certificates which should be what we want. -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] nvm.stripped on Win32 MinGW; pkg-config
Since most of the required libraries support pkg-config, it would make sense to use pkg-config with MinGW. However, there is a classic catch-22: pkg-config requires glib glib requies pkg-config !!! So I need a MinGW-compatible binary of one of the above to get started. The hosting website for pkg-config (http://pkgconfig.freedesktop.org/releases) has no binaries. The hosting website for glib (http://www.gtk.org) has Win32 dlls, but not the .a files needed by MinGW gcc. Does anyone have a solution for this? I guess I should ask on the Mingw mailing list. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped on Win32 MinGW; Botan
m4/botan.m4 says we need botan > 1.6.3, but not 1.7.14. However, on debian, I have 1.7.8-3, which configure accepts, but at runtime mtn says we need 1.7.22. On the botan website, I can download 1.8.0 or 1.6.5. I gather I should use 1.8.0, for both Debian and Windows MinGW. Should I also fix m4/botan.m4 to require > 1.7.21? or >= 1.8.0? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] encrypted netsync (was: merging in "serve raw 'automate stdio' over network")
Timothy Brownawell wrote: I should also mention that I'm thinking we eventually want to move to SSH2 for encryption/authentication (pending finding a good server-side SSH2 library, there only seem to be client-only libraries available now). This would let us only need to listen in one place for both netsync and stdio (and whatever else we might come up with), and would also mean not needing to keep our own authentication code or write our own encryption code (I know I've seen requests for encrypted netsync). Why ssh2 and not ssl/tls encryption? Just curious. I imagine ssl libraries would be more prevalent. And instead of relying on SSH for authentication, we could add the option of using PAM for authentication which is what SSH uses anyway. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Mini Summit 2009
Markus Wanner wrote: [...] Hi, I am here now, and I will be here for the rest of the evening and tomorrow after noon (America, South East (CDT)). I am willing to lend a hand to help anyone who needs it (testing, coding, whatever). Personally, I am interested in working on some of the quickie tasks on the wiki and some other things, specifically. * a mtn rename --guess command, or mtn rename --missing * mtn detach and mtn attach * concurrent access to a single database (not sure what is involved with this one, so I will need your help). I am 'man' in IRC (and matthew_i as well when I am at work). -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] merging in "serve raw 'automate stdio' over network"
On Sat, 2009-01-17 at 20:46 +, Timothy Brownawell wrote: > Branch net.venge.monotone.tbrownaw.serve_automate adds a --bind-automate > option to 'mtn serve', to allow serving raw automate stdio over the > network. This doesn't have any authentication, so it's only safe for > private interfaces (127.x.x.x). > > This allows for concurrent netsync and "automate stdio" access to a db. > > Does anyone object to merging this? (Maybe someone wants to add > authentication and a command to act as a front-end first, so it can > safely be run on on public interfaces?) I should also mention that I'm thinking we eventually want to move to SSH2 for encryption/authentication (pending finding a good server-side SSH2 library, there only seem to be client-only libraries available now). This would let us only need to listen in one place for both netsync and stdio (and whatever else we might come up with), and would also mean not needing to keep our own authentication code or write our own encryption code (I know I've seen requests for encrypted netsync). So I'd think un-secured stdio would be more useful for now than no network stdio, and we can clean up the networking later. But maybe there's a maintainable way to extend our current authentication to networked 'automate stdio', or maybe the potential for confusion resulting in putting an insecure protocol on a public interface is too great... -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] git fast-export
And Felipe Contreras spake on 01/17/2009 02:52 PM, saying: > I ran my comparison script, but unfortunately the first revision has a > missmatch: > > yours: > author Tailor Script 953780991 + > > mine: > author Tailor Script 953773791 +0200 > > Which suggest that your script is not handling the timezone correctly > (not sure about that). No, his script is handling it properly (based solely on this example). Monotone uses UTC internally and git does some crazy wacky things with timezones (in short, the timezone shown is /just/ for prettifying the date; the timestamp by itself *must* be the time of the commit in UTC). See https://kerneltrap.org/mailarchive/git/2007/2/6/237902 $ mtn automate certs d137c7046bae7e4a0144fee82bfce8061f61e3b3 | grep date -A 1 name "date" value "2000-03-23T03:09:51" $ date -d "2000-03-23 03:09:51" -u Thu Mar 23 03:09:51 UTC 2000 $ date -d "2000-03-23 03:09:51" -u +"%s" 953780991 ~Paul ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Dealing with lost key
Timothy Brownawell wrote: On Thu, 2009-01-15 at 14:19 -0800, dlakelan wrote: I've lost a key which has been used to certify a variety of things in one project. I've generated a new key, and now I'd like to replace all the old certificates with new certificates from the new key, and have my collaborators do the same... so we don't get a lot of warnings about incorrect certs. How can I do this? There's no simple way to replace certs like that, the easiest solution is to just keep them and make sure the new key has a different name. ... If you really do need to delete the old certs and generate new ones, something along these lines would probably work (not tested, may ruin your db)... Thanks for your suggestions. I think we will simply keep the old public key and certs. If there is no way to invalidate a key, then it seems difficult to deal with a security issue such as when a key is compromised and that key may be signing malicious code which collaborators are unaware of... for example. From a security standpoint, it seems to me that monotone should have a way to at the very least, expire trust in a key. Also, if asked to generate a new key, monotone should refuse if that key name is already known to monotone, unless some kind of --force-overwrite-key switch is given...perhaps it already does? Finally, the documentation should stress the fact that two keys with the same name are not supported... and it seems to me that it should be possible within monotone to ask it to drop signatures and to re-sign certificates with a new key. Thanks to the monotone developers for a very nice revision control system! Dan ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] nvm.stripped on Win32 MinGW
I'm working on nvm.stripped on Win32 MinGW. So far, configure gets to testing for pcre. I've installed pcre 7.8 from http://www.pcre.org/ configure finds pcre-config, and says it's using PCRE_CFLAGS=-I/usr/local/include but the actuall compiler command line does _not_ use that flag. I looked in m4/pcre.m4, and don't see anything obvious wrong. the configure script itself looks correct as well. I tried setting CFLAGS=-I/usr/local/include; that was ignored as well. Ah! I put debug statements in configure; something changed ac_link so it no longer includes $CFLAGS! it now has $CXXFLAGS $CPPFLAGS instead! This appears to be done by the AC_LANG([C++]) statment, or maybe one of the CXX statements after that. So I guess m4/pcre.m4 needs to be changed to set CXXFLAGS instead? or both, in case someone uses it with a C compiler. m4/lua.m4 sets both CFLAGS and CPPFLAGS. Applying that change in m4/pcre.m4 (in two places) lets configure recognize pcre. Aside; why doesn't mingw g++ look in -I/usr/local/include in the first place? It does on Debian, which may be why this bug in pcre.m4 has not been found yet. On to Botan ... -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] git fast-export
On Sat, Jan 17, 2009 at 9:04 AM, Derek Scherger wrote: > On Wed, Jan 14, 2009 at 12:50 AM, Felipe Contreras > wrote: >> >> >> 1) Your tool adds a bunch of "Monotone-" fields, can those be disabled? >> > >> > There's no option at the moment but it would be easy to add. >> >> It would be really useful. > > I've added --log-revids and --log-certs to enable including revision ids and > cert values in the commit logs. These are off by default . Great! >> >> 2) There's no author mapping, can this option be added? >> > >> > I'm not exactly sure what you mean by author mapping but I assume >> > translating between things like "f...@bedrock.com" and "Fred Flintstone >> > "? Is there a generally accepted format that other >> > tools >> > use for this? >> >> Yes, that's what I meant. >> >> The only format I know is the one from git-svn: >> felipec = Felipe Contreras > > I've added --authors-file and --branches-file options that work like this > for mapping author names and branch names respectively. Names not found in > these maps are used as-is. I've also changed the default branch to "unknown" > from "master" but this can be changed with the branches-file mapping to > whatever you want with a line like "unknown = whatever-you-want." Very nice. Now the only difference is that for unknown users my script maps them to "Unknown ". >> >> 3) I add the mtn sha1 in refs/mtn/ >> > >> > This is easy to add too. I have added refs/mtn/roots/ and >> > refs/mtn/leaves/ and was wondering about all of the monotone >> > revision >> > ids. I assume the leaf refs would prevent git from wanting to garbage >> > collect otherwise unreferenced revs if there were any? > > I've added --refs=roots, --refs=leaves and --refs=revs to include > refs/mtn/roots, refs/mtn/leaves and refs/mtn/revs respectively. Great :) >> If there's a ref pointing to it, then it's not pruned. > > Good. Including --refs=leaves should make sure that nothing is subject to > garbage collection then. > > Branches and tags can be manually fixed a posteriori, no big issue. >> >> The important things are the commits themselves. > > Not always. Monotone allows things in branch names that git does not. If > these aren't changed git will fail to import them. > Use --branches-file to map offending names to something git can handle. True. >> It probably depends on the intent of the clone: >> a) migrate the repo forever >> b) mirror a mtn repo >> >> Right now I'm interested in b), so I find the ref/mtn approach very >> useful since I can quickly look for the mtn or git sha1. > > The --refs=revs option does clutter up the gitk display somewhat but > otherwise seems fine. I tested your changes and converted the pidgin repo, on the second try I was finally able to convert it, took me 8 hours (1 revs/s). I ran my comparison script, but unfortunately the first revision has a missmatch: yours: author Tailor Script 953780991 + mine: author Tailor Script 953773791 +0200 Which suggest that your script is not handling the timezone correctly (not sure about that). Would it be possible to pause after a certain amount of commits, or at least issue a checkpoint? (maybe git fast-import has this option) Very good job! I'll try to look further into this later. Cheers. -- Felipe Contreras ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Mini Summit 2009
On Sat, Jan 17, 2009 at 1:47 PM, Felipe Contreras wrote: > On Sat, Jan 17, 2009 at 6:36 PM, Emile Snyder wrote: >> There's a link off of the monotone home page. It's channel #monotone on >> irc.oftc.net I think. > > Why oftc? Why not freenode? "Because it always has been." -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Documentation Texinfo XML to Wiki converter
In the course of the current Mini Summit I spent the afternoon hacking on a (yet still) small XSLT file whose purpose will be the conversion of Monotone's Texinfo Documentation to a set of multiple files which can be used for the Wiki. Unfortunately I have to use a rather new Java based version of Saxon [1] for the transformation process, because neither Gnome's libxml nor Apache Xalan where able to process a XSLT 2.0 template, which is needed for the file splitting and some regular expression stuff. XSLT 1.0 and 1.1 do not have these features AFAIK, or only as vendor specific extensions, which doesn't help either. The current state is that the XSLT searches the whole Texinfo XML file, collects the node hierarchy and therefrom builds up a directory structure with one file for each node (or rather: chapter). Next task would be to take each chapter's XML code and transform it to the desired output format. Currently I have the choice between HTML and the Wiki's own MDWN format, with the possibility to implement both and allow the user to chose between the two before the actual transformation. The number of target formats is not limited and is only depending on how many of them will be needed and, after all, how many complete and working style transformation templates will be created. So the question at the moment is: which output format would be the most useful? According to Thomas Keller there could be some formatting limitations in the Wiki format, but due to lacking experience with that format I can't affirm that. What I can say is that HTML can surely cope with almost everything, but would likely be more time consuming to implement. Also it could be more reasonable to directly create files for the Wiki, since HTML can already be created by makeinfo, though lacking Monotone's Wiki style. That's it for the moment! Greetings, Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Mini Summit 2009
On Sat, Jan 17, 2009 at 6:36 PM, Emile Snyder wrote: > There's a link off of the monotone home page. It's channel #monotone on > irc.oftc.net I think. Why oftc? Why not freenode? -- Felipe Contreras ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] merging in "serve raw 'automate stdio' over network"
Branch net.venge.monotone.tbrownaw.serve_automate adds a --bind-automate option to 'mtn serve', to allow serving raw automate stdio over the network. This doesn't have any authentication, so it's only safe for private interfaces (127.x.x.x). This allows for concurrent netsync and "automate stdio" access to a db. Does anyone object to merging this? (Maybe someone wants to add authentication and a command to act as a front-end first, so it can safely be run on on public interfaces?) -- Timothy Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Dealing with lost key
On Thu, 2009-01-15 at 14:19 -0800, dlakelan wrote: > I've lost a key which has been used to certify a variety of things in > one project. I've generated a new key, and now I'd like to replace all > the old certificates with new certificates from the new key, and have my > collaborators do the same... so we don't get a lot of warnings about > incorrect certs. How can I do this? There's no simple way to replace certs like that, the easiest solution is to just keep them and make sure the new key has a different name. I don't think we have a command that can delete particular certs (except branch certs, and that isn't by key), and I also don't think we have a command to get all certs from a particular key. If you really do need to delete the old certs and generate new ones, something along these lines would probably work (not tested, may ruin your db)... # in case this breaks things horribly cp your_db your_db_backup # get a list of old certs mtn -d your_db db execute "select hex(id), name, replace(value,x'0A','NEWLINE') from revision_certs where keypair = 'your_keypair_id'" >old_certs # delete old certs mtn -d your_db db execute "delete from revision_certs where keypair = 'your_keypair_id'" # create new certs to replace them IFS='|' while read revid cert_name cert_value do mtn -d your_db -k your_new_keypair_id cert $revid $cert_name "$(echo $cert_value | sed 's/NEWLINE/\n/g')" done Collaborators would have to either (1) delete/rename their databases and pull a fresh db from you (this includes any dedicated server databases, those would also have to be deleted/replaced) or (2) run the backup and delete-old-certs steps and re-pull (again including any dedicated servers). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] comments on merging nvm.error-handling?
net.venge.monotone.error-handling is meant to clean up our E(), I(), N()
usage somewhat, so that for example receiving an invalid revision from
the network will be treated differently than internally generating an
invalid revision and won't crash the server.
N() is gone, and E() takes an extra argument, E(condition, origin,
message). The origin is an origin::type enum (see origin_type.hh), and
indicates where the data causing the error is from. E(...,
origin::user, ...) is equivalent to what N() was.
All vocab types and most other classes now track where their data came
from with a origin::type made_from member (which can be obtained by
inheriting from origin_aware), and this is required when making a vocab
type from a string (so "branch_name(arg())" won't work, but
"branch_name(arg(), origin::user)" or "typecast_vocab(arg)"
will work.
This also removes informative_failure, and replaces it with
recoverable_failure and unrecoverable_failure. Which one is thrown by
E() depends on the origin, currently unrecoverable for internal and
database origins, and recoverable for others.
Does anyone have problems with merging this?
An example of the changes is:
=== revision.hh ===
struct
revision_t : public origin_aware
{
void check_sane() const;
=== snip ===
=== revision.cc ===
void revision_t::check_sane() const
{
E(!null_id(new_manifest), made_from, F("Revision has no manifest
id"));
if (edges.size() == 1)
{
// no particular checks to be done right now
}
else if (edges.size() == 2)
{
// merge nodes cannot have null revisions
for (edge_map::const_iterator i = edges.begin(); i != edges.end();
++i)
E(!null_id(edge_old_revision(i)), made_from,
F("Merge revision has a null parent"));
}
else
// revisions must always have either 1 or 2 edges
E(false, made_from, F("Revision has %d edges, not 1 or 2") %
edges.size());
// we used to also check that if there were multiple edges that had
patches
// for the same file, then the new hashes on each edge matched each
other.
// this is not ported over to roster-style revisions because it's an
// inadequate check, and the real check, that the new manifest id is
correct
// (done in put_revision, for instance) covers this case
automatically.
}
=== snip ===
--
Timothy
Free (experimental) public monotone hosting: http://mtn-host.prjek.net
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Mini Summit 2009
There's a link off of the monotone home page. It's channel #monotone on irc.oftc.net I think. -emile On Sat, Jan 17, 2009 at 8:16 AM, Stephen Leake < stephen_le...@stephe-leake.org> wrote: > > Where is the IRC? I can't find instructions for that on the mtn wiki > (I _really_ miss the search facility there!). I have Jabber with an > IRC backend installed on my Debian box; where do I point it? > > ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Mini Summit 2009
On Sat, 2009-01-17 at 11:16 -0500, Stephen Leake wrote: > Where is the IRC? I can't find instructions for that on the mtn wiki > (I _really_ miss the search facility there!). I have Jabber with an > IRC backend installed on my Debian box; where do I point it? It's on the front page, not the wiki. #monotone on OFTC (irc.oftc.net). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Mini Summit 2009
Lapo Luchini writes: > Markus Wanner wrote: >> Welcome to the Monotone Mini Summit 2009, >> >> I will be around mostly, but also have important non-mtn things on my >> agenda (I'm looking for work in Zurich). > > I'm here 'till 18:00 CET (more or less) both today and tomorrow unless > some real life decides to intrude in the agenda; and I mean life as in > life: a close friend of mine is in the process of fork()-ing ;-) I'm here (east coast America, near Washington, DC) for the weekend, and Monday (Martin Luther King holiday) and Tuesday (Barack Obama inauguration; nobody in their right mind will leave their house around here, due to the millions of visitors :). I can work on Debian, Windows, and Cygwin. Where is the IRC? I can't find instructions for that on the mtn wiki (I _really_ miss the search facility there!). I have Jabber with an IRC backend installed on my Debian box; where do I point it? >> For the summit, I have only one goal: preparing nvm.stripped for landing. > > As a FreeBSD Port mantainer and CygWin package mantainer, I really look > forward it; I never liked the "we include it all" approach much, even if > I can appreciate its reasons... > >> First of all, that involves more testing. I've successfully compiled >> nvm.stripped on these systems already: >> * Debian + Ubuntu Linux >> * FreeBSD (6.4 and 7.1), Lapo reported 7.0 as well >> * Gentoo Hardened > > I'll be testing CygWin shortly. Do we have updated/test installation instructions for nvm.stripped? I suggest we start one in monotone/INSTALL.windows, INSTALL.cygwin I understand the basic idea is to unbundle the various "other packages" from monotone. That means we need to install them manually on Windows, and maybe thru the Cygwin installer for Cygwin. Either way, we need detailed instructions. In particular, a canonical source for each package, and a list of versions of each package that are known to work. >> As we have reports from users on Windows and Solaris, I want to try >> these as well, before landing. I've virtual machines in place, but their >> lack of a usable packaging system (and lack of a real shell with ssh, in >> case of windows) makes testing pretty hard. Help with that is greatly >> appreciated. > > Cygwin is a life-saver in that regard. > I use its rxvt-zsh even to execute plain win32 commands... > I can't suffer cmd.exe lack of features! MSYS/Mingw also works, and is necessary for a non-Cygwin Win32 build. I managed to get a Windows buildbot working once; the instructions are on the wiki somewhere. They should probably be moved to INSTALL.windows.buildbot, or something. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: mtnopt manpage
Zack Weinberg wrote: > We need a manpage for mtnopt, if only so lintian will stop complaining > about there not being one ;-) Still lacking... > I can see what it does, but I don't > know what the intended uses and so on are. Same here. OK, digging in the log to the first commit I know know a little more: - Revision: 484bda8a6268214180bdac5dd857ab4ff4174976 Ancestor: 217d9b0e270ecc5bcbe7acb30297dee64afab8c6 Author: Richard Levitte Date: 2008-04-25T11:19:36 Branch: net.venge.monotone Added files: contrib/mtnopt Modified attrs: contrib/mtnopt ChangeLog: * contrib/mtnopt: New script to extract values from _MTN/options in a form that a shell can understand. It works in two modes, one that outputs shell variable definitions, suitable for operations such as "eval `mtnopt`", and one that simply outputs the value of the keys. There are options available to say what _MTN directory to use as well as to specify exactly what keys shouls be output. -- Lapo Luchini - http://lapo.it/ “I do engineering, not religion.” (Daniel J. Bernstein) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Mini Summit 2009
Markus Wanner wrote: > Welcome to the Monotone Mini Summit 2009, > > I will be around mostly, but also have important non-mtn things on my > agenda (I'm looking for work in Zurich). I'm here 'till 18:00 CET (more or less) both today and tomorrow unless some real life decides to intrude in the agenda; and I mean life as in life: a close friend of mine is in the process of fork()-ing ;-) > For the summit, I have only one goal: preparing nvm.stripped for landing. As a FreeBSD Port mantainer and CygWin package mantainer, I really look forward it; I never liked the "we include it all" approach much, even if I can appreciate its reasons... > First of all, that involves more testing. I've successfully compiled > nvm.stripped on these systems already: > * Debian + Ubuntu Linux > * FreeBSD (6.4 and 7.1), Lapo reported 7.0 as well > * Gentoo Hardened I'll be testing CygWin shortly. > As we have reports from users on Windows and Solaris, I want to try > these as well, before landing. I've virtual machines in place, but their > lack of a usable packaging system (and lack of a real shell with ssh, in > case of windows) makes testing pretty hard. Help with that is greatly > appreciated. Cygwin is a life-saver in that regard. I use its rxvt-zsh even to execute plain win32 commands... I can't suffer cmd.exe lack of features! If you have doubts regarding CygWin, ask me (I'm on IRC right now, but also in mail or on Jabber...). > * And second... enjoy the summit! > > Happy hacking Yup ;-) My personal plans include continuing work on nvm.lapo.selectors, but that's lower priority than things we can do better as a summit-crowd, as I can work on that anytime else too. PS: I guess the american part of the globe will not be online for at least 4 more hours... -- Lapo Luchini - http://lapo.it/ “The Magic Words are Squeamish Ossifrage” (Ron Rivest, RSA-129 challenge, 1977) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Mini Summit 2009
Welcome to the Monotone Mini Summit 2009, I will be around mostly, but also have important non-mtn things on my agenda (I'm looking for work in Zurich). For the summit, I have only one goal: preparing nvm.stripped for landing. First of all, that involves more testing. I've successfully compiled nvm.stripped on these systems already: * Debian + Ubuntu Linux * FreeBSD (6.4 and 7.1), Lapo reported 7.0 as well * Gentoo Hardened As we have reports from users on Windows and Solaris, I want to try these as well, before landing. I've virtual machines in place, but their lack of a usable packaging system (and lack of a real shell with ssh, in case of windows) makes testing pretty hard. Help with that is greatly appreciated. Second, I'd like to get the buildbot system into better shape. As pointed out above, I've virtual machines for all the systems mentioned so far. I've setup three buildbot slaves at work recently, so turning my virtual machines into buildbots for monotone should be doable within reasonable time. (However, as those virtual thingies consume memory, I might not be able to run all of them all the time. My host server has 6 GiB of memory, the virtuals mostly have 0.5 GiB - not sure if that's sufficient for compiling monotone w/o having to swap) As for the summit, I'm asking for two things: * Please keep discussions on the mailing list, on IRC or if you absolutely need to on skype. But please don't abuse the wiki for that. It's utterly hard to tell who said what there and close to impossible to browse that offline (unlike plain mails). (Original question: why submitting ideas for this summit there? Who's the "I" who proposed the "branch rename" command?...) * And second... enjoy the summit! Happy hacking Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: heads up on nvm.stripped
Markus Wanner wrote: >> nice sh -c 'SHELL=/bin/sh ; autoreconf -i && >> CXXFLAGS="-I/usr/local/include" LUA_CFLAGS="-I/usr/local/include/lua51" >> LUA_LIBS="-llua-5.1" LDFLAGS="-L/usr/local/lib" ./configure && gmake' > > Aha, so it was lua, which posed some problems. > > What's the purpose of "SHELL=/bin/sh"? Is that required if there's > already a 'configure' (i.e. as in the tarball)? I'm not really sure about that, but my shell of choice is zsh and without that configure would sometimes give an error reported by zsh... I guess somewhere it assumes the shell to be sh and doesn't check, or something. The internals of the compiled configure are a bit scary and that empirical solution worked well enough to satiate my curiosity ;) I'll check again in the future maybe, but I guess it's something specific to my installation and you can probably avoid it. >> Actually lua installs a .pc for pkg-config, but it's versioned: >> % pkg_info -L lua-5.1.3_3|fgrep .pc >> /usr/local/libdata/pkgconfig/lua-5.1.pc > > Hm.. on Debian it's just "lua5.1". Strange. I guess the "correct" name would be just "lua", but when two version are not compatible the port/package-maintainers need to come up with a different name, not necessarily consistent across systems... > However, it's simple enough to teach the lua.m4 script. Done in > 2a7c7d45284e1eedee141f5627f612a954c6eb9d. > > Not having to use flags is even easier, no? Of course ;-) > Having a monotone ports package for FreeBSD would be great! > And along the way, update botan's port to 1.8.x as well... :-) Hey, we do have monotone in the Ports since quite a few, since well before my arrival in fact ;-) (and packages get compiled automatically when there is a working port) http://www.freshports.org/devel/monotone/ I'm looking forward to "stripped" landing! -- Lapo Luchini - http://lapo.it/ “The sky above the port was the color of television, tuned to a dead channel.” (William Gibson, "Neuromancer") ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
