Re: [Monotone-devel] [PATCH] Broken migration code? (Merging branch to allow duplicate key names, have certs use key hash)
Zack Weinberg za...@panix.com writes: On Sun, Aug 23, 2009 at 7:08 PM, Stephen Leakestephen_le...@stephe-leake.org wrote: [1] Makefile:897: *** Recursive variable `V_bcxx_' references itself (eventually). Stop. I get that same error on Debian, but not on Windows. I think the problem is that AM_DEFAULT_VERBOSITY is not being set anywhere in the Makefile on Debian. But I don't know why; it is set on Windows. Is it possibly that you have automake 1.11 on Windows but an older version on Debian? I should have tested with older versions. Yes, I have 1.11 on Windows, 1.10.1 on Debian Possible proper fix: -m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES]) +m4_ifdef([AM_SILENT_RULES], + [AM_SILENT_RULES], + [AM_DEFAULT_VERBOSITY=1 + AC_SUBST([AM_DEFAULT_VERBOSITY])]) in configure.ac. Yes, that fixes it. Another fix is to delete the lines labeled verbosity goo in Makefile.am. Do we really need them? At one point in investigating this, I deleted them, and 'make check' succeeded. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] Broken migration code? (Merging branch to allow duplicate key names, have certs use key hash)
Timothy Brownawell tbrow...@prjek.net writes: On Thu, 2009-08-20 at 19:37 -0500, Timothy Brownawell wrote: On Fri, 2009-08-14 at 05:04 +, Timothy Brownawell wrote: I think branch net.venge.monotone.keys-by-hash is ready now. The central change is that certs contain a key hash instead of a key name, to get rid of the problem with key collisions. This does require a netsync flag day, because certs on the wire contain a key hash instead of a key name now (just like certs in the db). This is merged now. ...and it looks like I forgot to make the migration code fix the cert hashes (which AFAICT are only used for netsync, so possible wierdness if people 'db migrate' with out-of-sync db's and then try to sync the migrated certs). I'm getting make errors[1] when I try to build even a clean checkout right now, so could someone try this patch and check that the lua-testsuite.lua change makes the testsuite fail, Yes, at least schema_migration fails and the other changes make it pass again? No. The relevant part of the log: runcmd: /home/Projects/monotone-build/mtn, local_redir = false, requested = nil schema_migration:101: /home/Projects/monotone-build/mtn --norc --root=/home/Projects/monotone-build/tester_dir/tests/schema_migration --confdir=/home/Projects/monotone-build/tester_dir/tests/schema_migration --rcfile /home/Projects/monotone-build/tester_dir/tests/schema_migration/test_hooks.lua --db=/home/Projects/monotone-build/tester_dir/tests/schema_migration/test.db --keydir /home/Projects/monotone-build/tester_dir/tests/schema_migration/keys --key=tes...@test.net --db 1db80c7cee8fa966913db1a463ed50bf1b0e5b0e.mtn db execute select hex(hash) from revision_certs stdout: 'select hex(hash) from revision_certs' - 21 rows ADB37CD94183246AA984D0529DD76593A83A6F97 6EA0AC1980436807CF51953340A5154504524C58 445DCAB09D7DAFEC6D5DFEB2E6BD333A22C8998D 3FE59FD967810C97CB2C9AD982EED94D74106437 C6AAD4B70F193BE703FA542D158D49AAD984BA4A 6C12258AB6F4458722DC1B675C8CC672230B05AE B827369AE89241746B34503013C437C82B745858 DAB7817B32BD495E07A0DFA5E44C1E624C27D31F C3DC68C0E904D3D562BF3648D897EC6A225BD63C BFAE4D24CE61525FCC4B7C585D5A9F37A904D200 45F74888AEF054B7978040FD536CBF9CFB082F09 1B933E609DD14806968E50331F20A04FB1283A4A E877AED3EF0740A2C5778F3EAF58FD413E24FDDD 2E552A5E39C97B52EB7F105CCF36B48E8AA456BE 60D8BCB5F1CD4721F9F22B594F7FA4DB04AA8516 1339FD579EABAD3A48DBEAC0AA83285A0B470044 15C7FE3E6BCFEEA2883AAA0408479EED74B971FA 618B68A39CB4CEF595642117F973E8DAF427EACE 2F79FD7E4BC7D95E062205C334BFB14C15762131 24A945A23F512DCF5B049DBA123A5F1A4B5617E3 DA32371EED33ED9F1CD5974FF7427344A9DAFB93 stderr: exit code: 0 schema_migration:101: rename stdout stdout-first Destination stdout-first exists; removing... stdin: runcmd: /home/Projects/monotone-build/mtn, local_redir = false, requested = nil schema_migration:101: /home/Projects/monotone-build/mtn --norc --root=/home/Projects/monotone-build/tester_dir/tests/schema_migration --confdir=/home/Projects/monotone-build/tester_dir/tests/schema_migration --rcfile /home/Projects/monotone-build/tester_dir/tests/schema_migration/test_hooks.lua --db=/home/Projects/monotone-build/tester_dir/tests/schema_migration/test.db --keydir /home/Projects/monotone-build/tester_dir/tests/schema_migration/keys --key=tes...@test.net --db latest.mtn db execute select hex(hash) from revision_certs stdout: 'select hex(hash) from revision_certs' - 21 rows 972AFE73ECD4560D442B74503FB5D85DC51109B9 5A325CA256744AC7A0F537676A46F05625D6EEE3 60169E268653E509090465B3B3FF2B55BE1CAB4B 2D26C59E1CFA4A4CEB8BF71B6C258A5E6C40715F 4469A9FD40B05D3C4BFDA124659F5B600DDDF9E7 009C3F44ACC716364454773013B8E444E45BD499 DCF6A300C4906BE912EAACF809AB11C881247A14 39C4B62BBF5597167BC1CF0B1F5E8F509D4D521F D58935D2945CB8DCC8B975DDF1BDA878A66F188C 8FC714357592B9FA6DE057AA9B1EF9B8F9248CC0 5AB5F460E5CAAB98A1403C1C1785AC39D1282DED 7D7FC520B26C686B124AB3F293DCF9DB82BF7A7E BA39A26BD638A0E5E753B0BB5B7D7F82679439A1 C8456EB84E054B47D3112C11E5566C39973A65A4 881593D28B9AD1051EC816FAE0CEC852996F85FC 4C45D0DFDA971024DCA2C66063CC785102EEDD3A AE8B7730461D38111EF907450B8BEC47C79CD476 9C8920131303AC56E0CA8779B6987609C6C226A7 9CB461C68241A0A9D706DCB62FEFD72BCB82EBAE 13E6D8E4A9FF8D036CE0BAAF78CB4BF1D53391BC 05D14E02F9DFD3B077139C3BD3611DBC40732711 stderr: exit code: 0 schema_migration:101: rename stdout stdout-second Destination stdout-second exists; removing... schema_migration:101: readfile stdout-first schema_migration:101: readfile stdout-second Check failed: false stack traceback: [string testlib.lua]:107: in function 'err' [string testlib.lua]:808: in function 'check' /home/Projects/monotone/lua-testsuite.lua:287: in function /home/Projects/monotone/lua-testsuite.lua:282 (tail call): ? /home/Projects/monotone/lua-testsuite.lua:277: in function 'check_same_db_contents' ...jects/monotone/tests/schema_migration/__driver__.lua:98: in function
Re: [Monotone-devel] Merging branch to allow duplicate key names, have certs use key hash
Richard Levitte rich...@levitte.org writes: In message 1250815028.4392.1.ca...@localhost on Thu, 20 Aug 2009 19:37:08 -0500, Timothy Brownawell tbrow...@prjek.net said: tbrownaw On Fri, 2009-08-14 at 05:04 +, Timothy Brownawell wrote: tbrownaw I think branch net.venge.monotone.keys-by-hash is ready now. tbrownaw tbrownaw The central change is that certs contain a key hash tbrownaw instead of a key name, to get rid of the problem with key tbrownaw collisions. tbrownaw tbrownaw This does require a netsync flag day, because certs on the tbrownaw wire contain a key hash instead of a key name now (just tbrownaw like certs in the db). tbrownaw tbrownaw This is merged now. Cool! I wonder, what do you propose for a flag day for our repository? (and lets not forget to announce it clearly on http://monotone.ca/ and to make sure there's ample time for people to adapt, rebuild, yada yada yada) One thing we need is an up to date Cygwin release. I think Lapo Luchini is working on one, but the latest in the Cygwin repository is 0.42. Lapo, can you check in your Cygwin package stuff? or notes on it? Can I help? I have built mtn on Cygwin in the past, but not since the libraries were split out. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] netsync flag day justifies bumping version number to 1.0
Hello, I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. This would allow us, maintainers of monotone in Debian, to provide two versions of monotone in parallel: monotone (the latest) and monotone0 (0.44), or monotone1 and monotone. This would allow people to have both versions installed at the same time, without a clash. I think this would be desirable because Debian 5.0 Lenny contains version 0.40, runs on many servers including www.ada-france.org, and will remain in service for at least another two years. Thus the transition period for the netsync change cannot be shorter than that. In fact, I would suggest a policy whereby the major version number changes whenever netsync changes; if this policy had been in place since the beginning of monotone development the next version would be 3.0 or 4.0, I believe, -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, Aug 24, 2009 at 12:06:12PM +0200, Ludovic Brenta wrote: Hello, I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. This would allow us, maintainers of monotone in Debian, to provide two versions of monotone in parallel: monotone (the latest) and monotone0 (0.44), or monotone1 and monotone. This would allow people to have both versions installed at the same time, without a clash. I think this would be desirable because Debian 5.0 Lenny contains version 0.40, runs on many servers including www.ada-france.org, and will remain in service for at least another two years. Thus the transition period for the netsync change cannot be shorter than that. I suppose the other option would be for monotone to detect which versions of netsync are available at the other end, and use whichever is the most recent. That way you could upgrade and still be compatible with those who haven't. Whether this is technically feasible (is enough information available in the data base to support both protocols? Does the netsync protocol have a version-number field somewhere in an early packet?) I don't know. It looks as if monotone is used in enough places that a flag day is a big event, and not just something that can be handled informally in a small community. I guess that's good news -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, 24 Aug 2009 09:58:23 -0400 hend...@topoi.pooq.com wrote: On Mon, Aug 24, 2009 at 12:06:12PM +0200, Ludovic Brenta wrote: Hello, I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. I suppose the other option would be for monotone to detect which versions of netsync are available at the other end, and use whichever is the most recent. That way you could upgrade and still be compatible with those who haven't. I would also like to see this option. In the optimal situation the client and the server could negotiate the latest netsync protocol automatically. Or perhaps user could specify the used protocol? mtn serve --protocol=v1.0 mtn serve --protocol=v1.1 -- Tero Koskinen tero.koski...@iki.fi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] Broken migration code? (Merging branch to allow duplicate key names, have certs use key hash)
On Mon, Aug 24, 2009 at 1:38 AM, Stephen Leakestephen_le...@stephe-leake.org wrote: Possible proper fix: -m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES]) +m4_ifdef([AM_SILENT_RULES], + [AM_SILENT_RULES], + [AM_DEFAULT_VERBOSITY=1 + AC_SUBST([AM_DEFAULT_VERBOSITY])]) in configure.ac. Yes, that fixes it. Thanks, I'll commit that shortly. Another fix is to delete the lines labeled verbosity goo in Makefile.am. Do we really need them? At one point in investigating this, I deleted them, and 'make check' succeeded. Try make clean; make V=0 on the machine with automake 1.11 before you say that. :-) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, Aug 24, 2009 at 3:06 AM, Ludovic Brentaludo...@ludovic-brenta.org wrote: Hello, I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. I agree with this *if* we can't persuade the new server to speak the old protocol as well as the new one, but I think we should seriously try to make the new server speak the old protocol first. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Hi, Ludovic Brenta wrote: I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. -1 A flag day certainly doesn't justify a version increment to 1.0, quite the opposite, IMO. BTW: I'm a bit surprised by this flag day and don't remember any discussion about whether it's worth it or not. Or when. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Bumping required library versions
If we're thinking about bumping the major version number to 1.0, that would seem to be the right time to bump up our minimum library requirements as well. We currently have backward compatibility kludges in place for: - automake 1.11 (current: 1.11) - autoconf 2.64 (current: 2.64) - botan 1.7.22 (current: 1.8.5) - sqlite 3.3.14 (current: 3.6.17) - boost 1.3[45] (not sure exactly) (current: 1.39) I'd like to bump to: automake 1.11, autoconf 2.64 (these are both brand new, but only developers need them) botan 1.8.2 or 1.8.3 (whichever is the earliest version that fixes the netsync server run as root on Linux hangs reading /proc/kmsg bug) sqlite 3.6.12 (sqlite.org recommends upgrading from any version older than this) boost 1.34 or 1.35 (whichever is the oldest version that provides boost/circular_buffer.hpp, so we can drop our bundled copy) Thoughts? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, 2009-08-24 at 09:58 -0400, hend...@topoi.pooq.com wrote: On Mon, Aug 24, 2009 at 12:06:12PM +0200, Ludovic Brenta wrote: Hello, I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. This would allow us, maintainers of monotone in Debian, to provide two versions of monotone in parallel: monotone (the latest) and monotone0 (0.44), or monotone1 and monotone. This would allow people to have both versions installed at the same time, without a clash. I think this would be desirable because Debian 5.0 Lenny contains version 0.40, runs on many servers including www.ada-france.org, and will remain in service for at least another two years. Thus the transition period for the netsync change cannot be shorter than that. I suppose the other option would be for monotone to detect which versions of netsync are available at the other end, and use whichever is the most recent. That way you could upgrade and still be compatible with those who haven't. Whether this is technically feasible (is enough information available in the data base to support both protocols? All the same information is there, but the cert hashes have changed. I suppose the old hash could be stored in the db as well... It's now possible to have multiple keys with the same name, so incoming old-format certs could be ambiguous. I suppose they could be disambiguated by trying to verify the signature with each of the keys with that name. Does the netsync protocol have a version-number field somewhere in an early packet?) I don't know. The packets all have a version field, but there's nothing to allow for negotiation. The server sends the first packet, so the clients would all have to be upgraded first. It looks as if monotone is used in enough places that a flag day is a big event, and not just something that can be handled informally in a small community. I guess that's good news Annoying, but yes, probably good. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, Aug 24, 2009 at 07:50:34PM +0200, Markus Wanner wrote: Hi, Ludovic Brenta wrote: I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. -1 A flag day certainly doesn't justify a version increment to 1.0, quite the opposite, IMO. BTW: I'm a bit surprised by this flag day and don't remember any discussion about whether it's worth it or not. Or when. Wasn't there a list of things that also needed a flag day -- with the intent that we do them all together and thus need only one flag day? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, 2009-08-24 at 19:50 +0200, Markus Wanner wrote: Hi, Ludovic Brenta wrote: I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. -1 A flag day certainly doesn't justify a version increment to 1.0, quite the opposite, IMO. Well, it depends on what you take the version numbers to mean. :) If 1.0 means it's done and 2.0 is something to do a decade later, then yeah it doesn't make sense. If it's incompatible change count.update count, then it makes perfect sense. Well, assuming a large enough user-base that 0.x == anything-goes doesn't fly. BTW: I'm a bit surprised by this flag day and don't remember any discussion about whether it's worth it or not. Or when. Yes, the next one (SSL, etc) needs better planning. Some reasons for this one getting less discussion than otherwise are that it's fixing a longstanding bug with moderately severe consequences (which was starting to really annoy the pidgin people), that there wasn't anything else to batch it up with, and even to some extent that things have seemed rather dead lately. And that nobody said anything about it when I asked about merging the branch in two weekends ago. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, 2009-08-24 at 19:23 -0400, hend...@topoi.pooq.com wrote: On Mon, Aug 24, 2009 at 07:50:34PM +0200, Markus Wanner wrote: Hi, Ludovic Brenta wrote: I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. -1 A flag day certainly doesn't justify a version increment to 1.0, quite the opposite, IMO. BTW: I'm a bit surprised by this flag day and don't remember any discussion about whether it's worth it or not. Or when. Wasn't there a list of things that also needed a flag day -- with the intent that we do them all together and thus need only one flag day? All I'm aware of is the NetsyncTodo page, which isn't terribly concrete or complete, and generally has things that we either don't know how to do or haven't started on. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, 2009-08-24 at 12:06 +0200, Ludovic Brenta wrote: Hello, I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. This would allow us, maintainers of monotone in Debian, to provide two versions of monotone in parallel: monotone (the latest) and monotone0 (0.44), or monotone1 and monotone. This would allow people to have both versions installed at the same time, without a clash. Sounds good to me. I guess we'd also have to commit to some level of maintenance/support for the old version. I think this would be desirable because Debian 5.0 Lenny contains version 0.40, runs on many servers including www.ada-france.org, and will remain in service for at least another two years. Thus the transition period for the netsync change cannot be shorter than that. So we'd end up having 3 versions to support. The one out there now, the one (presumably) about to be released, and the one after we move to SSL and make whatever other changes. Then in 2012 we get SHA-3 and would want a major flag day with a history rebuild, but by then the version out there currently would be gone. All of which could be taken to mean that we should try to have the batch of SSL and other changes ready in about 18 months. But then that seems a bit long, if we actually maintain active development... In fact, I would suggest a policy whereby the major version number changes whenever netsync changes; if this policy had been in place since the beginning of monotone development the next version would be 3.0 or 4.0, I believe, I like this idea. We'd also want to make sure to present it as an integral part of the program name (although not necessarily the executable, or do the symlink thing like gcc does), to try to minimize confusion from people trying to use a monotone1 client to download a project that uses a monotone2 server. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Timothy Brownawell spake unto us the following wisdom: Some reasons for this one getting less discussion than otherwise are that it's fixing a longstanding bug with moderately severe consequences (which was starting to really annoy the pidgin people), that there wasn't anything else to batch it up with, and even to some extent that things have seemed rather dead lately. And that nobody said anything about it when I asked about merging the branch in two weekends ago. Yeah, this has indeed been rather painful for us, and I for one am glad to see it go in. Flag days are no fun, but they're manageable. (At least, for us.) Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
On Mon, Aug 24, 2009 at 06:08:43PM -0500, Timothy Brownawell wrote: On Mon, 2009-08-24 at 09:58 -0400, hend...@topoi.pooq.com wrote: On Mon, Aug 24, 2009 at 12:06:12PM +0200, Ludovic Brenta wrote: Hello, I am of the opinion that the next version of monotone should be 1.0 because of the netsync flag day. This would allow us, maintainers of monotone in Debian, to provide two versions of monotone in parallel: monotone (the latest) and monotone0 (0.44), or monotone1 and monotone. This would allow people to have both versions installed at the same time, without a clash. I think this would be desirable because Debian 5.0 Lenny contains version 0.40, runs on many servers including www.ada-france.org, and will remain in service for at least another two years. Thus the transition period for the netsync change cannot be shorter than that. I suppose the other option would be for monotone to detect which versions of netsync are available at the other end, and use whichever is the most recent. That way you could upgrade and still be compatible with those who haven't. Whether this is technically feasible (is enough information available in the data base to support both protocols? All the same information is there, but the cert hashes have changed. I suppose the old hash could be stored in the db as well... It's now possible to have multiple keys with the same name, so incoming old-format certs could be ambiguous. I suppose they could be disambiguated by trying to verify the signature with each of the keys with that name. Does the netsync protocol have a version-number field somewhere in an early packet?) I don't know. The packets all have a version field, but there's nothing to allow for negotiation. The server sends the first packet, so the clients would all have to be upgraded first. So this time around we're stuck. Well, not entirely. I suppose it *is* possible for a development group to upgrade all their clients first... And I suppose we could leave a monotone server that serves the new-protocol monotone source code running on the old protocol so that people are capable of upgrading. But could we install negotiation in the new protocol we're introducing now so that next time around we have a chance of avoiding this mess? There will be even more monotone users out there by then. I don't think we want monotone to end up like gnutella, which treats the use of an obsolete client as an attack. That's something I learned years back when I was implementing OSI protocols. Always negotiate the protocol version. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
