Re: [Monotone-devel] [bug #30065] MAXPATHLEN breaks builds on GNU/Hurd
On Tue, Mar 27, 2012 at 12:12 PM, Francis Russell fran...@unchartedbackwaters.co.uk wrote: I guess that means if it's broken it won't have any bad effects :) More seriously, perhaps it should be removed entirely then? I note that grepping the source shows multiple references to AF_LOCAL and there appears to be a reference to some type of 'local:' URL scheme? Presumably monotone did support this at some point? IIRC we *wanted* to support that -- if only because then the test suite could use it; there are some contexts, notably some ill-defined subset of the Debian build farm, where the testsuite can't open network sockets even on the loopback interface, so we can't actually test the networking -- but we never finished the project. I got sidetracked on trying to replace netxx with libevent, and then I stopped having time to hack on monotone. :-/ zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Monotone-debian] Bug#653764: FTBFS with Boost 1.48: lgamma_small.hpp:483:38: error: expected primary-expression before 'do'
On 2011-12-31 5:02 PM, Hendrik Boom wrote: On Sat, Dec 31, 2011 at 12:02:37PM +0100, Zack Weinberg wrote: I'm not in a position to verify this for myself for another week, but I have a horrible feeling I know what's wrong: Monotone defines several one-character macros for its own use, and L() is one of them. It looks like Boost is using L() for its own purposes and expecting it not to be a macro. ... Or by changing the name of L. L and several other one- or two-character macros (from memory: F, FL, I, M, MM; there are probably at least two more) are used dozens of times in every file -- and more important still, the coding style assumes they are short-yet-mnemonic. I cannot support changing them. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [Monotone-debian] Bug#653764: FTBFS with Boost 1.48: lgamma_small.hpp:483:38: error: expected primary-expression before 'do'
On Fri, Dec 30, 2011 at 9:53 PM, Steve M. Robbins s...@debian.org wrote: This package failed to build using the newest Boost version 1.48: ... /usr/include/boost/math/special_functions/detail/lgamma_small.hpp: In function 'T boost::math::detail::lgamma_small_imp(T, T, T, const mpl_::int_0, const Policy, const L)': ... /usr/include/boost/math/special_functions/detail/lgamma_small.hpp:483:38: error: expected primary-expression before 'do' I'm not in a position to verify this for myself for another week, but I have a horrible feeling I know what's wrong: Monotone defines several one-character macros for its own use, and L() is one of them. It looks like Boost is using L() for its own purposes and expecting it not to be a macro. I'd argue that Boost headers should take care to defend themselves from the possibility of such macros, but fixing that in Boost might be an enormous amount of work, and in any case, 1.48 is already out there. If I'm right, this can also be fixed in monotone by moving all Boost and stdlib #includes above most-but-not-all application #includes; unfortunately that's exactly the opposite coding style from the present usage, and may involve messing with the base.hh convention (config.h obviously still needs to be the very first thing included in every file). zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of blue sky ideas?
I wouldn't say that monotone is done; in addition to the things you listed, I can think of quite a few other things that badly need doing, such as * speed improvements * netsync bandwidth and latency improvements * memory-use and disk-space-use improvements * a sensible URL scheme * a replacement for die-die-die merge * a complete, directly-usable structural merge UI (*something* got committed, but I got the impression it was geared to the needs of a particular IDE and was not usable by humans directly) * network interoperability with git and hg * a replacement for the unmaintained, IPv6-incompatible, confusing-error-message-generating netxx library However, all the core developers - me included, sad to say - have moved on to other projects, so there is no manpower to *do* any of these things, and it's hard to attract new people because nearly everyone is using git or hg these days. If you had the time and the motivation, you could pretty much take over development and I don't think anyone would mind. :) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] GPLv3 code in monotone
On Sat, May 21, 2011 at 8:09 AM, Hendrik Boom hend...@topoi.pooq.com wrote: On Fri, May 20, 2011 at 07:18:21PM -0700, Zack Weinberg wrote: On Fri, May 20, 2011 at 6:51 PM, Hendrik Boom hend...@topoi.pooq.com wrote: Switching to GPL3 would make us license-incompatible with a large body of code (everything under a copyleft that isn't v3-compatible, in particular, code under v2-only). It would also make us license-compatible with a large body of code (anything that adds restrictions that are okay with v3 but not v2). GLP2+ is compatible with GPL2. GLP2+ is compatible with GPL3. I said v2-only. Yes, we're in agreement. The v2-only item was at the end of my first sentence. The mtn code should be GPL2+, mentioned at the start of both sentences. I misunderstood you. Sorry about that. I agree with your assessment. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] GPLv3 code in monotone
On 2011-05-20 4:46 PM, Stephen Leake wrote: GPLv3 was heavily reviewed before it was released, and has been out for almost 4 years. Can you elaborate? I'm sure there are good reasons not to bother going to GPLv3, but I don't understand what you mean by premature. Switching to GPL3 would make us license-incompatible with a large body of code (everything under a copyleft that isn't v3-compatible, in particular, code under v2-only). It would also make us license-compatible with a large body of code (anything that adds restrictions that are okay with v3 but not v2). It is my impression that the former body of code is much larger than the latter, and it is my opinion that we should not switch as long as that remains the case. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] GPLv3 code in monotone
On Fri, May 20, 2011 at 6:51 PM, Hendrik Boom hend...@topoi.pooq.com wrote: Switching to GPL3 would make us license-incompatible with a large body of code (everything under a copyleft that isn't v3-compatible, in particular, code under v2-only). It would also make us license-compatible with a large body of code (anything that adds restrictions that are okay with v3 but not v2). GLP2+ is compatible with GPL2. GLP2+ is compatible with GPL3. I said v2-only. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] GPLv3 code in monotone
I think that migration to GPLv3 remains premature at this time, and we should relicense the v3 files down to v2. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Not so minor problem in 0.99.1
On Wed, Jan 5, 2011 at 12:13 AM, Markus Wanner mar...@bluegap.ch wrote: Zack, Can you elaborate on what's wrong with that? libbotan1.7-dev correctly depends on libssl0.9.8, which provides libcrypto.so.0.9.8. And yes, linking that with -lcrypto works without the symlink libcrypto.so - libcrypto.so.0.9.8. (Symlink only provided by libssl-dev) Are you 100% sure that you can link a *program* with -lcrypto without that symlink existing? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Not so minor problem in 0.99.1
On Wed, Jan 5, 2011 at 10:46 AM, Richard Levitte rich...@levitte.org wrote: In message aanlktinohrv0dg19m1rxts9p8jbh=_j7fpmy_2brz...@mail.gmail.com on Wed, 5 Jan 2011 08:43:38 -0800, Zack Weinberg za...@panix.com said: zackw On Wed, Jan 5, 2011 at 12:13 AM, Markus Wanner mar...@bluegap.ch wrote: zackw Zack, zackw zackw Can you elaborate on what's wrong with that? libbotan1.7-dev correctly zackw depends on libssl0.9.8, which provides libcrypto.so.0.9.8. zackw zackw And yes, linking that with -lcrypto works without the symlink zackw libcrypto.so - libcrypto.so.0.9.8. (Symlink only provided by libssl-dev) zackw zackw Are you 100% sure that you can link a *program* with -lcrypto without zackw that symlink existing? Nope. [demo snipped] Exactly. So either botan-config shouldn't be adding -lcrypto to the link line, or libbotan1.7-dev needs to depend on libssl-dev. Either way, that's a bug in the botan packaging. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Not so minor problem in 0.99.1
On Tue, Jan 4, 2011 at 6:17 AM, Markus Wanner mar...@bluegap.ch wrote: On 01/04/2011 05:48 AM, Zack Weinberg wrote: On Mon, Jan 3, 2011 at 11:36 AM, Richard Levitte rich...@levitte.org wrote: Why should libbotan1.7-dev need to depend on libssl-dev? It's botan-config that adds -lcrypto to the link line, so it's libbotan1.7-dev's responsibility to ensure that the bare libcrypto.so symlink exists, which would be accomplished by depending on libssl-dev. I think you are mixing -dev and non-dev packages. libbotan1.7-dev doesn't depend on any other -dev package. While libbotan1.7 very well depends on libssl0.9.8 (but still not libssl-dev) (on lenny, that is). On squeeze, I'm able to compile monotone (c2d9a013..) just fine without having libssl-dev installed (but with libssl0.9.8). If that works correctly, then whatever added -lcrypto to the link line is wrong. Which would be libbotan1.7-dev again, if I understood the config.log snippet right. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Not so minor problem in 0.99.1
On Mon, Jan 3, 2011 at 9:26 AM, Hendrik Boom hend...@topoi.pooq.com wrote: hendrik conftest.cpp -lz -L/usr/lib -lm -lbz2 -lcrypto -lgmp -lpthread -lrt -lz hendrik -lbotan 5 hendrik /usr/bin/ld: cannot find -lcrypto That's where the problem is... Quite honestly, though, I'm a bit surprised this should happen at all. libbotan1.7 depends on libssl0.9.8, which delivers libcrypto... So the question is, what's up with that? libssl10.9.8 provides libcrypto in /usr/lib/i486/libcrypto.so.0.9.8 /usr/lib/i586/libcrypto.so.0.9.8 /usr/lib/i686/cmov/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.0.9.8 and all of these are present on my system. Is libssl-dev installed? Does the botan-dev package (whatever it's actually named) depend on libssl-dev, as it seems it needs to? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Not so minor problem in 0.99.1
On Mon, Jan 3, 2011 at 11:36 AM, Richard Levitte rich...@levitte.org wrote: In message aanlkti=buu5ovw3xwzkwg9-xamdmjn8xc1i5uaxvv...@mail.gmail.com on Mon, 3 Jan 2011 10:28:56 -0800, Zack Weinberg za...@panix.com said: zackw Is libssl-dev installed? Does the botan-dev package (whatever it's zackw actually named) depend on libssl-dev, as it seems it needs to? Why should libbotan1.7-dev need to depend on libssl-dev? It's botan-config that adds -lcrypto to the link line, so it's libbotan1.7-dev's responsibility to ensure that the bare libcrypto.so symlink exists, which would be accomplished by depending on libssl-dev. (I'm a little surprised this is the case, I thought botan had its own crypto primitives and that the weird libssl license precluded its using ssl's) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #31017] automate stdio session does not see external db changes
Follow-up Comment #4, bug #31017 (project monotone): There is no such thing as locking against deletion on Unix. How exactly did you get into this situation, Stephen? The lua tests are supposed to only mess with databases that they create. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?31017 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone-0.48 bug
Thanks for this information. I'm not sure what's going on; could you please send us the file tester_dir/tests.log , from your build directory? Please keep monotone-devel@nongnu.org in the To: line. zw 2010/6/29 Станислав Корсаков s...@stasoft.net: Hello. I unpacked source code to another folder (without multibyte characters). Did './confgigure', './make', './make check; and got 572 ws_ops_with_wrong_node_type ok 0:01, 0:00 on CPU Of 572 tests run: 481 succeeded 50 failed 37 had expected failures 0 succeeded unexpectedly 4 were skipped == 1 of 3 test suites failed Please report to monotone-devel@nongnu.org make[2]: *** [check-local] Ошибка 1 make[2]: Выход из каталога `/home/administrator/monotone-0.48' make[1]: *** [check-am] Ошибка 2 make[1]: Выход из каталога `/home/administrator/monotone-0.48' make: *** [check] Ошибка 2 Existing locale: administra...@gw1:~/monotone-0.48$ locale LANG=ru_RU.UTF-8 LC_CTYPE=ru_RU.UTF-8 LC_NUMERIC=ru_RU.UTF-8 LC_TIME=ru_RU.UTF-8 LC_COLLATE=ru_RU.UTF-8 LC_MONETARY=ru_RU.UTF-8 LC_MESSAGES=ru_RU.UTF-8 LC_PAPER=ru_RU.UTF-8 LC_NAME=ru_RU.UTF-8 LC_ADDRESS=ru_RU.UTF-8 LC_TELEPHONE=ru_RU.UTF-8 LC_MEASUREMENT=ru_RU.UTF-8 LC_IDENTIFICATION=ru_RU.UTF-8 LC_ALL= Regards, Stanislav 2010/6/28 Zack Weinberg za...@panix.com 2010/6/28 Станислав Корсаков s...@stasoft.net: mtn: fatal: error: failed to convert string from UTF-8 to ANSI_X3.4-1968: '/home/administrator/Загрузки/monotone-0.48/tester_dir/tests/_MTN' Your system locale has confused monotone into thinking that file names are not encoded in UTF-8, even though they clearly are. You may be able to fix this by tacking '.UTF-8' on the end of whatever it is (I don't speak any of the languages that use the Cyrillic alphabet so I cannot hazard a guess). If that doesn't work, the most likely problem is that you need to run 'dpkg-reconfigure -plow locales' as root and select the .UTF-8 variant of the locale you're using, then try again. You can probably work around the crash by moving /home/administrator/Загрузки/monotone-0.48 to an absolute path that contains no non-ASCII characters, but you may still see test failures until you get your locale corrected. We will make changes Real Soon Now so that you get a clearer error message when this happens. zw -- Best regards, Stanislav Korsakov ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone-0.48 bug
Hm. This is not a locale problem anymore. *All* the failures show this error message: mtn: fatal: std::runtime_error: network error: listen(2) error: Address already in use Each test that gets this error is trying to use a different, randomly-selected high-numbered port on the loopback interface, so it's not a case of inadequate privileges, or conflict with another monotone server running on the same machine. Do you have a firewall configuration that would block the use of such ports, or something like that? I don't know why you are getting error messages sending to monotone-devel. zw 2010/6/29 Станислав Корсаков s...@stasoft.net: Sorry, but i got error message when send to monotone-devel@nongnu.org -- Пересланное сообщение -- От кого: Станислав Корсаков s...@stasoft.net Дата: 29 июня 2010 г. 22:17 Тема: Re: [Monotone-devel] Monotone-0.48 bug Кому: monotone-devel@nongnu.org Hello. Log file in attachments. Regards, Stanislav PS. The same build produces the same result on xubuntu-10.04 i386 with same locale 2010/6/29 Zack Weinberg za...@panix.com Thanks for this information. I'm not sure what's going on; could you please send us the file tester_dir/tests.log , from your build directory? Please keep monotone-devel@nongnu.org in the To: line. zw 2010/6/29 Станислав Корсаков s...@stasoft.net: Hello. I unpacked source code to another folder (without multibyte characters). Did './confgigure', './make', './make check; and got 572 ws_ops_with_wrong_node_type ok 0:01, 0:00 on CPU Of 572 tests run: 481 succeeded 50 failed 37 had expected failures 0 succeeded unexpectedly 4 were skipped == 1 of 3 test suites failed Please report to monotone-devel@nongnu.org make[2]: *** [check-local] Ошибка 1 make[2]: Выход из каталога `/home/administrator/monotone-0.48' make[1]: *** [check-am] Ошибка 2 make[1]: Выход из каталога `/home/administrator/monotone-0.48' make: *** [check] Ошибка 2 Existing locale: administra...@gw1:~/monotone-0.48$ locale LANG=ru_RU.UTF-8 LC_CTYPE=ru_RU.UTF-8 LC_NUMERIC=ru_RU.UTF-8 LC_TIME=ru_RU.UTF-8 LC_COLLATE=ru_RU.UTF-8 LC_MONETARY=ru_RU.UTF-8 LC_MESSAGES=ru_RU.UTF-8 LC_PAPER=ru_RU.UTF-8 LC_NAME=ru_RU.UTF-8 LC_ADDRESS=ru_RU.UTF-8 LC_TELEPHONE=ru_RU.UTF-8 LC_MEASUREMENT=ru_RU.UTF-8 LC_IDENTIFICATION=ru_RU.UTF-8 LC_ALL= Regards, Stanislav 2010/6/28 Zack Weinberg za...@panix.com 2010/6/28 Станислав Корсаков s...@stasoft.net: mtn: fatal: error: failed to convert string from UTF-8 to ANSI_X3.4-1968: '/home/administrator/Загрузки/monotone-0.48/tester_dir/tests/_MTN' Your system locale has confused monotone into thinking that file names are not encoded in UTF-8, even though they clearly are. You may be able to fix this by tacking '.UTF-8' on the end of whatever it is (I don't speak any of the languages that use the Cyrillic alphabet so I cannot hazard a guess). If that doesn't work, the most likely problem is that you need to run 'dpkg-reconfigure -plow locales' as root and select the .UTF-8 variant of the locale you're using, then try again. You can probably work around the crash by moving /home/administrator/Загрузки/monotone-0.48 to an absolute path that contains no non-ASCII characters, but you may still see test failures until you get your locale corrected. We will make changes Real Soon Now so that you get a clearer error message when this happens. zw -- Best regards, Stanislav Korsakov -- Best regards, Stanislav Korsakov -- Best regards, Stanislav Korsakov ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone-0.48 bug
2010/6/28 Станислав Корсаков s...@stasoft.net: mtn: fatal: error: failed to convert string from UTF-8 to ANSI_X3.4-1968: '/home/administrator/Загрузки/monotone-0.48/tester_dir/tests/_MTN' Your system locale has confused monotone into thinking that file names are not encoded in UTF-8, even though they clearly are. You may be able to fix this by tacking '.UTF-8' on the end of whatever it is (I don't speak any of the languages that use the Cyrillic alphabet so I cannot hazard a guess). If that doesn't work, the most likely problem is that you need to run 'dpkg-reconfigure -plow locales' as root and select the .UTF-8 variant of the locale you're using, then try again. You can probably work around the crash by moving /home/administrator/Загрузки/monotone-0.48 to an absolute path that contains no non-ASCII characters, but you may still see test failures until you get your locale corrected. We will make changes Real Soon Now so that you get a clearer error message when this happens. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] verbosity options
On Sun, Jun 13, 2010 at 7:06 AM, Timothy Brownawell tbrow...@prjek.net wrote: On 06/13/2010 07:18 AM, Stephen Leake wrote: That could be reasonable, replace all four with a global --verbosity=-2,-1,0,1. Probably this should be part of resettable options, since --quiet and --reallyquiet need to be fixed anyway and can be made resettable along the way. For now, any objections to deleting quiet and reallyquiet from nvm? They turn off tickers and P() messages, and --reallyquiet also turns off W() messages. We probably want to keep them. I support mapping these options to a verbosity level internally, but please keep --quiet around [and its aliases -q and --silent] as a user visible option. Lots of commands recognize -q/--quiet/--silent as meaning no output except in case of errors (or in some cases no output other than exit status, e.g. grep(1)) and we want to keep that global consistency. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
On Fri, Jun 4, 2010 at 3:53 PM, Thomas Keller m...@thomaskeller.biz wrote: So, what should we do here? The addition of -E for all other unices would mean that we'd tamper the test. I distinctly remember having to add -E on SunOS, and I would not be at all surprised if, well, anyone else who doesn't use GNU patch had the same behavior. Therefore I think we should unconditionally add -E. (change a test diff to use /dev/nul instead of /dev/nul, f.e., to see the effect - the file is no longer removed on compliant systems). I assume you meant /dev/nul instead of /dev/null there? By the way, standard English is e.g. not f.e. It expands to exempli gratia. Yes, that's Latin. I blame the French. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] strptime not in MinGW time.h
On Sat, May 22, 2010 at 4:09 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Currently, 'status' checks to see if date_fmt (either from the option or from hook_get_date_format_spec) is valid, in the sense that date_t::as_formatted_localtime and date_t::from_formatted_localtime succeed when using it. On Win32, this check will always fail, because strptime is not implemented. So get_log_message_interactively should do the same check to decide whether to allow editing the commit date. That way, even on Unix, if the user provides a date_fmt that strptime doesn't like, commit won't fail. We need to make it visually obvious in the editor when editing the date won't have any effect, if we do this. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Failure to connect to IPV6 server
On Wed, May 19, 2010 at 3:01 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Well, it might not, tbh - it just exceeded my pain threshold :) The problem I was having was, in asio a network socket, a local domain socket, and an anonymous pipe are all different static types, but monotone wants to treat them identically, so a big dynamically typed wrapper was necessary and writing it was too much work. We now have a big dynamically typed wrapper in the netsync stuff, so this may not be so bad anymore. Might be worth looking at asio again, then. I don't have free coding cycles any time soon, though. Also it may have reimplemented the DNS client rather than calling getaddrinfo, which is not sysadmin-friendly. That is certainly odd. I've seen a lot of async network libraries do this - it's because getaddrinfo is synchronous, so if you want to integrate it into a reactor-type async main loop, you have to muck about with threads, which is no fun. Of course, writing your own DNS client is also no fun, but I guess it's less bad from the perspective of the network library author? Linux has getaddrinfo_a, but that's not universal and suffers from this bizarre notion that signals are a sensible IPC mechanism. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Failure to connect to IPV6 server
The problem here is that we are using an ancient networking library (netxx) that hasn't been updated since 2005 or something like that, and has no IPv6 support. We need a new networking library. Unfortunately, I don't know if there *is* a good low-level async networking library that meets all our requirements. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Failure to connect to IPV6 server
On Tue, May 18, 2010 at 4:47 PM, Jack Lloyd ll...@randombit.net wrote: On Tue, May 18, 2010 at 03:59:06PM -0700, Zack Weinberg wrote: The problem here is that we are using an ancient networking library (netxx) that hasn't been updated since 2005 or something like that, and has no IPv6 support. We need a new networking library. Unfortunately, I don't know if there *is* a good low-level async networking library that meets all our requirements. Just out of curiosity, how does asio fall down in this context? Well, it might not, tbh - it just exceeded my pain threshold :) The problem I was having was, in asio a network socket, a local domain socket, and an anonymous pipe are all different static types, but monotone wants to treat them identically, so a big dynamically typed wrapper was necessary and writing it was too much work. Also it may have reimplemented the DNS client rather than calling getaddrinfo, which is not sysadmin-friendly. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] setup creates _MTN/mtn.db
On Sat, May 8, 2010 at 5:08 AM, Thomas Keller m...@thomaskeller.biz wrote: Am 08.05.10 13:44, schrieb Stephen Leake: Second, what is the rationale, both for providing any default name, and choosing this particular name? The rationale is simply to make monotone less database-centric and verbose with respect to the commands needed to start with a fresh project. I can see that proving a default db name it makes it easy to start a totally new project. But it's a significant change, and I'm not happy with the path. I'm ok with initializing the database if needed. Once the project grows a branch that they want to checkout into a different directory, having the database in branch_1/_MTN/mtn.db will be very odd and confusing; people will wonder if there should be one db per branch, or one db per workspace. I sympathise with Stephen here a bit - Monotone's ability to share one database among many workspaces is a significant difference from Git and Mercurial, and one that should be up-front rather than buried. How about putting the database in the parent directory of the checkout and naming it something like _store.mtn by default? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
On Tue, Apr 27, 2010 at 4:42 PM, Timothy Brownawell tbrow...@prjek.net wrote: Is the occasional backslash really that bad? '%' conflicts with urlencoding (and '*' would only actually glob things if you have some really weirdly named files), and '?' is probably necessary for file/ssh sync. I think it's more important to avoid characters that are meaningful in URLs (*especially* %) than to avoid characters that are meaningful to the shell. People expect to have to quote URLs. Also, I don't like / as a separator when it's not traversing a directory-like hierarchy. So, how about this? protocol://u...@server.host.name/path/to/database?include,include,-exclude,-exclude should work equally well for mtn (with usher), ssh, and file. Without usher, you just leave out the /path part. (Also, ~ in the path part should absolutely have the 'go to home directory' semantic.) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] BUG
Please do $ mtn db init --db=XX.mtn --debug mtn-debug.txt 21 and send us mtn-debug.txt (read over it first and edit out any secrets, but please edit it as little as possible) zw On Mon, Apr 19, 2010 at 7:34 PM, Frizky friz...@gmail.com wrote: mtn db init --db=XX.mtn mtn: fatal: error: ../net.venge.monotone/paths.cc:307: I(!is_absolute_here(inT)) mtn: this is almost certainly a bug in monotone. mtn: please send this error message, the output of 'mtn version --full', mtn: and a description of what you were doing to monotone-de...@nongnu.org. mtn: discarding debug log, because I have nowhere to write it mtn: (maybe you want --debug or --dump?) mtn --version monotone 0.46 (base revision: e282b2cf8b86caf828930b3b1ec67f41153084e4) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: netsync connection info cleanup
I don't have any feedback on this stuff myself, but I want to mention that over a year ago, Roland McGrath posted some complaints about the mtn:// URI schema being either broken or not useful as designed -- it was never clear to me which, because I don't know how it's supposed to work. You might want to dig back through the list archives and see if you can't address his concerns as long as you're messing with this stuff. zw On Sun, Apr 18, 2010 at 11:49 AM, Thomas Keller m...@thomaskeller.biz wrote: Am 18.04.10 04:34, schrieb Timothy Brownawell: On 04/15/2010 07:59 AM, Thomas Keller wrote: However there is a bug in our parse_uri() implementation: If no scheme (f.e. mtn://) is given, it treats the string as path rather than as hostname. This leads to the problem that the scheme-less default server setting we store in the db vars is not treated correctly and that a host which is entered by the user is now also parsed wrongly. As I said, I'd rather change the implementation of parse_uri than forcing the user to pull mtn://monotone.ca instead of just monotone.ca... This should work now. parse_uri() will check for things that look like only a hostname or ip address and maybe a port, and skip most of the logic. It also uses everything before the query string in the db vars, and also uses that for the 'peer' string in the network session. This is what gets sent to the usher, so giving mtn://monotone.ca/foobar?include=... would send mtn://monotone.ca/foobar to the usher where it currently sends only the hostname (and the normal way of mtn sy monotone.ca ... would still send just the hostname), which should make it possible to use usher with neither wildcard dns nor pattern-based dispatch. There are still a couple of quirks in the url parsing code - f.e. path-like (invalid) URIs like the following one are accepted (it will only fail if no default branch pattern is stored in the DB): mtn://monotone.ca/monotone/net.venge.monotone\ /-net.venge.monotone.guitone which end up creating completly wrong default server entries. I think we should define first what we want to allow and how it should look like here. A small nuisance is f.e. that the ? in the URI makes problems on some shells (at least zsh), so you need to quote the complete string. We've supported that use case halfwhat in the past by not using as query separator, but /, but I think we can further improve this. The following URIs are currently supported: mtn://monotone.ca mtn://monotone.ca/monotone mtn://monotone.ca?foo.bar mtn://monotone.ca?foo.bar*/-foo.bar.baz mtn://monotone.ca/monotone?foo.bar mtn://monotone.ca/monotone?foo.bar*/-foo.bar.baz mtn://monotone.ca?include=foo.bar mtn://monotone.ca?include=foo.bar*/exclude=foo.bar.baz mtn://monotone.ca/monotone?include=foo.bar mtn://monotone.ca/monotone?include=foo.bar*/exclude=foo.bar.baz The first unfortunate thing here is that we have to support two different syntaxes, one time you can omit include= and replace exclude= with a - and one time these can be given (probably because we advertise that people could use weird branch name patterns which don't follow the reverse dns scheme almost everybody uses, but this doesn't seem to work correct either, try f.e. mtn://monotone.ca/monotone?include=foo/bar/baz*/exclude=foo/bar/baz/bla). The second unfortunate thing is that the short syntax, while being less verbose, still needs quoting because of ? as the query separator and * for branch expansion. So how should we continue? I think we should pick _one_ syntax and stick to that, and I'd vote for the simple one mtn://monotone.ca?foo.bar*/-foo.bar.baz but with a few modifications so it would look like this: mtn://monotone.ca/foo.bar%/-foo.bar.baz (or explicitely mtn://monotone.ca/+foo.bar%/-foo.bar.baz) Here no comand line quoting is needed at all and the SQL-like % wildcard should be recognizable as well. Secondly, I'd actively deprecate any branch name which does not match the following regular expression, i.e. by throwing a warning when a branch cert which a different value is created: ^([\w\d]+([-][\w\d]+)*)(\.[\w\d]+([-][\w\d]+)*)*$ (test script to play around: http://pastebin.ca/1866605) This way we ensure that a branch name later does not conflict with the URI separator nor with the wildcard character nor with the negation we need for branch exclusion in our URI scheme. Thirdly I'd unify the way includes and excludes are defined for netsync commands. I'd deprecate the SERVER BRANCH [--exclude=PATTERN [...]] options (but would leave them available and convert them to the internal representation with % as wildcard f.e.) and I'd make the new URI available for all commands (currently clone does not support the old URIs f.e.). Lastly, the only thing which has not yet been determined is how we can represent the server notion for usher - clearly this would conflict with the
Re: [Monotone-devel] mtn: fatal: std::logic_error: paths.cc:718: invariant 'I(!empty())' violated
On Thu, Apr 1, 2010 at 3:35 PM, hend...@topoi.pooq.com wrote: I've upgraded both their monotones to currently distributed Debian packages, and now one is mtn 0.45 and the other is mtn 0.40. Are these compatible when they act on the mtn database directly? I remember there was some incompatibility around that time and I thank you for making new versions network-compatible with old. But am I likely to run into trouble if I handle a monotone database with 0.45 and later reboot to stable and try to touch it with monotone 0.40? Unfortunately, there were several schema updates in between 0.40 and 0.45. The first time you touch the database with 0.45 it will ask you to migrate the schema, and after you do that, 0.40 will not be able to read it. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bug #29310] Currently impossible to escape from multi-parent workspace
The multi-parent workspace feature was never really finished. Patches welcome... zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
This seems like a good time to mention that I really don't want to be responsible for Debian packaging anymore. Packaging is not hard, but can be very time-consuming and tedious. I never got around to doing 0.46. There are a few bugs in their tracker that should definitely be fixed. zw On Thu, Mar 4, 2010 at 10:07 AM, Thomas Keller m...@thomaskeller.biz wrote: Hi all! I'm preparing the next monotone currently, which will probably happen Sunday evening. Please check if your translations are up-to-date (there hasn't happened much since 0.46 in this area though), if the current head builds on your platform and if all of the tests (beside the usual suspects which failed earlier as well) run through. If you have anything of which you think should stop the release process, then please let me know. Thanks in advance, Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Problems with the tutorial
On Sun, Feb 14, 2010 at 2:20 AM, Gary monotone-...@garydjones.name wrote: On Sat, Feb 13, 2010 at 09:10:07AM -0800, Zack Weinberg wrote: Does cygwin have strace? The error messages we get back from sqlite are very generic; if we can find the failing filesystem operation, that will probably tell us what needs changing. Yes, it does. It has now being running via strace for the last couple of hours. I don't know how long it should take, but that seems pretty excessive to me. Anyway, it does at least seem to be running - I can see the mtn.db file increasing in size (currently ~86MB) and mtn.db-journal file as well. So, curious, I created a new directory and went through the process again without strace and got the same result as before (sqlite error: SQL logic error or missing database and so on). Bother, said Pooh. I rather think you have found a bug in Cygwin. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Problems with the tutorial
On Sat, Feb 13, 2010 at 8:17 AM, Gary monotone-...@garydjones.name wrote: On Sat, Feb 13, 2010 at 10:00:09AM -0500, Stephen Leake wrote: Gary writes: g...@mimosa ~/src/monotone $ mtn --db=mtn.db pull monotone.ca net.venge.monotone* [...] mtn: warning: recoverable 'system' error while processing peer monotone.ca: 'er\ ror: sqlite error: SQL logic error or missing database' mtn: error: processing failure while talking to peer monotone.ca, disconnecting Is ~/ on an NFS mount, or other non-local disk? I've had problems with running mtn over an NFS mount (not exactly this problem). No, locally. I think I'm actually a jinx on open source software, I always seem to encounter problems nobody else does :( Does cygwin have strace? The error messages we get back from sqlite are very generic; if we can find the failing filesystem operation, that will probably tell us what needs changing. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] --docdir and --htmldir
On Mon, Jan 18, 2010 at 12:23 AM, Thomas Keller m...@thomaskeller.biz wrote: I stumbled upon a small possible issue (again) while building openSUSE rpm packages. Apparently documentation should go into PREFIX/share/doc/packages/monotone (or the output of `rpm --eval %_docdir`/monotone), but we install everything under PREFIX/share/doc/monotone. I guess the --docdir and --htmldir options are meant to control that behaviour, but both don't work and still just put everything into PREFIX/share/doc/monotone. This is almost certainly because we have hand-rolled rules for generating HTML from Texinfo, instead of using automake's rules. I tried to fix this about a month ago but ran into a brick wall related to the figures - each output format (info, pdf, ps, html) wants a different format for the figure files (.txt, .pdf, .eps, .png respectively) and some of them *break* if they find figures in a format other than they one they expect (most prominently, for no comprehensible reason, pdftex prefers .png figures over .pdf figures!) And automake's support for distinct include directories for the various formats is ... not really there. So I gave up. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
I'd like to draw people's attention to Debian bug 559893: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559893 This is, at root, a problem with contrib/get_passphrase_from_file.lua, which was never updated for the keys-by-hash changes. I doubt I will have time to look at this before your proposed release [my time to work on monotone is extremely limited these days] but it would be really nice if it could get fixed. It doesn't appear to me that the hook documentation was properly updated for keys-by-hash either. zw On Wed, Jan 6, 2010 at 5:20 AM, Thomas Keller m...@thomaskeller.biz wrote: Hey there! As I have announced earlier on IRC I plan to release monotone 0.46 in a few weeks, before February to be more precise. I'd like to get my nvm.automate-netsync branch in a mergable state until then (docs and tests are still missing) and I think we then have quite a sounding release with enough features and fixes. I'd like you to already check the latest head and report build problems since we do not have many functional build bots right now. (It would be even better to fix the bots, but apparently all the people who still manage one have disappeared since I've made this call for 0.45...) Also, translators, please already start and translate the strings, so we're safe in this area as well. The nvm.automate-netsync branch will not introduce many new ones, so translating these before 0.46 is released shouldn't then take so long. Thanks for your work! Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] merge conflicts
On Wed, Dec 16, 2009 at 1:43 PM, Hugo Cornelis hugo.corne...@gmail.com wrote: This behavior makes it hard if not impossible to fully automate regression testing for a software product. From viewpoint of the concepts, I would think that a merge conflict resolution implemented by one user and pushed to a central repository, would be honored automatically by repositories that only pull from that central repository, such that these 'pull-only repositories' can continue to serve their task. But our experience indicates otherwise: after manual resolution of all merge conflicts in one repository that occasionally syncs with the central server, we still have to go through other repositories that only pull from the server to resolve what is essentially the same conflict. This behavior just seems incorrect. Me and njs spent quite some time with a whiteboard back in the day, trying to convince ourselves that the least common ancestor selection algorithm would not do this. I think you have found a bug. Thing is, though, it's gonna be something obscure and specific to your use pattern, because all the simple scenarios are already in the test suite. Can you please try to write a shell script that demonstrates the effect by a sequence of commit, merge, and sync operations on synthetic databases? That will make it much easier to figure out what's going on. I could try to write one based on your description of the problem, but I estimate at least 75% chance I won't be able to make it happen. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] heads up: file system changes
On Thu, Sep 24, 2009 at 8:45 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: Sigh. I was quoting from libc.info, which is titled The Red Hat newlib C Library. I thought that was an implementation of the C standard runtime; apparently not. Sure it is; it's just that this is not behavior nailed down by C90 nor C99, so it's not surprising that the documentation is less than clear here. This is the ISO C function to remove a file. It works like unlink for files and like rmdir for directories. remove is declared in stdio.h. That certainly makes sense. But if it's in stdio.h, doesn't that mean it's defined by the C standard? So it should be the same on Win32? Hmm. Maybe that standard allows this variance as implementation defined. Yuck. Not all the stuff in stdio.h belongs to the C standard; for instance, mine declares tempnam(), which is SVID/XOPEN (not even POSIX), and various other such things. Anyway, since the C standard has no concept of directories, of course what remove() does to directories is not defined by the C standard. :) But it is defined by POSIX. I checked - contra my recollection, neither C90 nor C99 even has the concept of directories. But your quote above says it's the ISO C function; is ISO C something other than C90? ISO would prefer that ISO C without qualification referred to C99 (the 1990 standard is officially withdrawn at this point) but the 1999 revision is still (ten years later!) not universally adopted, and people tend to still mean C90 when they talk of the C standard. But this is kinda irrelevant. :) The *function* is defined by C90, but its behavior on directories isn't. POSIX.2001, incidentally, is available online at http://www.opengroup.org/onlinepubs/009695399/nfindex.html (free registration required). You have to read it carefully because not every system that we care about implements all of the 2001 spec, but it's a good starting point. So mtn assumes unix = POSIX, win32 != POSIX? Precisely. And to some extent you can't even trust MSVCRT to get C90 right. So the comment in platform.hh is not correct, but the directory must be empty for do_remove to succeed. I'll fix it. That sounds right to me. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] heads up: file system changes
On Thu, Sep 24, 2009 at 1:12 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Stephen Leake stephen_le...@stephe-leake.org writes: Zack Weinberg za...@panix.com writes: Closely related question: what the hell is going on with new_optimal_path? system_path constructors assume the input path is relative to the original process directory. But I needed a path that is relative to the workspace root, when reading from a stored conflicts file. Okay, but you could have added a system_path constructor that operated relative to the workspace root, couldn't you have? I remembered the rest of the reason. If the user provides a relative path in a conflict file, then I want to write out that same relative path when I update the conflict file. Why? What's wrong with writing it back out as an absolute path? But you could, again, add an as_external_relative_to_ws_root() method to system_path. So I need as_external() to dispatch on the path type when writing a path to a conflict file. The thing is, the paths classes are really, really not supposed to be used with dynamic typing. new_optimal_path introduces a hole through which horrible bugs could crawl (like, the conflicts file somehow getting added to a roster). zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] heads up: file system changes
On Wed, Sep 23, 2009 at 11:30 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: Daniel Atallah daniel.atal...@gmail.com writes: On Wed, Sep 23, 2009 at 07:30, Stephen Leake stephen_le...@stephe-leake.org wrote: Zack Weinberg za...@panix.com writes: Why is do_remove in platform.hh? The unix implementation requires C90 'remove'. Are we assuming C90 is not available on Windows? I assume MinGW provides that (but maybe it doesn't?); do we really care about any other compiler/runtime? remove() in the Windows CRT only will delete files, not directories: http://msdn.microsoft.com/en-us/library/2da4hk1d%28VS.80%29.aspx That's the same as Gnu libc: Use `remove' to dissolve the association between a particular filename (the string at FILENAME) and the file it represents. After calling `remove' with a particular filename, you will no longer be able to open the file by that name. That's not the documentation I have for GNU libc ... http://www.gnu.org/software/libc/manual/html_node/Deleting-Files.html first describes unlink() [which does not work on directories] and rmdir() [which only works on directories] and then says — Function: int remove (const char *filename) This is the ISO C function to remove a file. It works like unlink for files and like rmdir for directories. remove is declared in stdio.h. Right. But in this case, it is an implementation of the standard C library. I checked - contra my recollection, neither C90 nor C99 even has the concept of directories. The horse's mouth, therefore, is POSIX, which says # The remove() function shall cause the file named by the pathname pointed to by path # to be no longer accessible by that name. A subsequent attempt to open that file using # that name shall fail, unless it is created anew. # If path does not name a directory, remove(path) shall be equivalent to unlink(path). # If path names a directory, remove(path) shall be equivalent to rmdir(path). The second paragraph is marked as an extension to C90. POSIX.2001, incidentally, is available online at http://www.opengroup.org/onlinepubs/009695399/nfindex.html (free registration required). You have to read it carefully because not every system that we care about implements all of the 2001 spec, but it's a good starting point. However, the actual difference between the code in win32 and unix deals with what happens when the file to be removed does not exist. The Gnu libc manual quoted above does not specifically address this issue, so perhaps it is implementation dependent. Windows returns an error in this case; apparently Unix (whatever that is :) does not. I could not find the actual ISO C runtime library definition (I think I have a book at work), so I'm not clear what that says. That might actually be a bug. The underlying Unix system calls [rmdir() and unlink()] do return an error code if the last component of the pathname doesn't exist. I'm not sure whether our platform-independent code expects do_remove() to succeed in that case. do_remove_recursive definitely does need to succeed then, though. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] heads up: file system changes
On Wed, Sep 23, 2009 at 8:02 AM, Daniel Atallah daniel.atal...@gmail.com wrote: Interestingly in platform.hh there is a comment stating that the path argument to do_remove() must be a file, not a directory, but that appears to not be correct - is that correct or not? That comment is wrong. Platform independent code assumes that do_remove can delete directories. The approach that things like Glib use is to ensure consistency within the API (all paths are UTF-8); then wherever direct interaction with the filesystem occurs, the path is converted to the relevant encoding (in the Windows case, this is conversion to a UTF-16 wchar*). I think this is the right way to do it. This is what our paths.cc / fs.cc layer is trying to do, although it does have a lot of bugs. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] heads up: file system changes
On Wed, Sep 23, 2009 at 4:30 AM, Stephen Leake stephen_le...@stephe-leake.org wrote: Zack Weinberg za...@panix.com writes: On Tue, Sep 22, 2009 at 1:55 AM, Stephen Leake I'll look at it more later, but I suspect the simplest fix is to just move the original do_remove_recursive into win32/fs.cc. Yah, or you should be able to copy the unix version, which isn't very unix specific. You might need more make_accessible calls though. It turns out the fix to your code was simple; SHFileOperationA does not like '/' directory separators, and it returns non-zero when the path doesn't exist. Ugh. Well, thanks for fixing it. Side note: do_remove_recursive attempts to generate a nice error message, but it doesn't come out anywhere that I can see. It's probably being eaten by Lua. This is a long-standing general bug which would not be hard to fix, but it's tedious and fiddly -- basically, all of the points where control transfers in or out of the Lua interpreter need to convert between C++ and Lua exceptions, rather than throwing them away. Some, but not all, Lua exceptions are supposed to be thrown away -- for instance, if a hook is not defined -- so it isn't purely mechanical, either. I guess the only place raw pathname strings occur is inside do_remove_recursive, as it fetches file names from the OS? I think that right now there is no other place that needs to read *and process* arbitrary OS file names. Many other places fetch file names from the OS but can refuse to operate on pathnames that would be invalid any_path objects. Why is do_remove in platform.hh? The unix implementation requires C90 'remove'. Are we assuming C90 is not available on Windows? Yes (see Daniel's reply). The platform-independent code assumes C90 semantics. But it would seem a better approach is to enhance any_path objects to support all OS-supported filenames. That's how we keep people from checking in files that can't be checked out again on some other platform (e.g. the file named \ that the skip_invalid_paths test creates) so we certainly do not want that for file_path and bookkeeping_path. I could see the argument for system_path. I think we would then want to templatify most of file_io.cc rather than continuing to have it manipulate bare any_path objects, so that each class of path got the appropriate checks. Closely related question: what the hell is going on with new_optimal_path? AFAICT all users of that function ought to be using system_path, full stop. Does C90 not deal with this in a portable way? *hollow laughter* zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone server hangs
[please keep monotone-devel@nongnu.org in the cc:, there are several people reading that list who know more about netsync than I do.] On Wed, Sep 23, 2009 at 2:15 PM, Hugo Cornelis hugo.corne...@gmail.com wrote: Yes it hangs. Sometimes the transfer completes in a couple of minutes, but most of the time it takes an indefinite amount of time for exactly the same transfer. Sometimes it hangs after importing 50 revisions, sometimes after 120, sometimes it hangs from the early start. It seems fairly undeterministic where it hangs, so my first guess is that it is a race condition of some sort. ... What can I do to help you guys debug this problem? strace? ltrace? netstat? Reconfigure the database? If it's blocking other clients, that means it's not making it back to the select() loop in the server, which suggests a computational bug. You're the first person to report an actual hang rather than just OMG so slow, so I suspect it depends on the exact contents of your database. I can think of four things that would be useful: - Try enabling forward deltas; see if that makes the problem go away. - When the hang happens, is the server consuming 100% CPU, blocked on a system call, or what? - Build a mtn binary with debugging information; run it on the server under gdb; when it hangs, hit ^C to break into the debugger, and get a backtrace. (If it's consuming 100% CPU, please capture *several* backtraces, continuing execution in between and waiting for a few seconds before hitting ^C again, to probe the bounds of the infinite loop.) - Put a copy of your database somewhere we can retrieve it via FTP or HTTP, so we can attempt to reproduce the problem on our own machines. (I don't want to try to pull from you in case I trigger the bug!) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] heads up: file system changes
On Tue, Sep 22, 2009 at 1:55 AM, Stephen Leake
I'll look at it more later, but I suspect the simplest fix is to just
move the original do_remove_recursive into win32/fs.cc.
Yah, or you should be able to copy the unix version, which isn't very
unix specific. You might need more make_accessible calls though.
What is the rationale for making this platform-specific? It would help
if that rationale was documented in the code.
The immediate reason is, we need do_remove_recursive to work on raw
pathname strings so it can delete things that can't be represented as
pathname objects. The only place to put code that works on raw
pathname strings is {unix,win32}/fs.cc.
Notionally, in the future, we might want to switch everything in
win32/fs.cc over to the Unicode APIs, and do_remove_recursive would be
no exception, but I surely am not doing that work.
zw
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] heads up: file system changes
I've just pushed a bunch of cleanups to the file system access code. These should catch more cases where we needed to be skipping invalid paths, and improve the diagnostics for them, too. However, there is a very good chance that I have completely broken win32/fs.cc. For this I apologize, but must ask for help from Windows people in testing and fixing. (In particular, it might be that we really should not try to use SHFileOperation for recursive delete.) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [ANNOUNCE] monotone 0.45 released
On Thu, Sep 17, 2009 at 5:11 AM, Jack Lloyd ll...@randombit.net wrote: On Thu, Sep 17, 2009 at 01:36:05PM +0200, Lapo Luchini wrote: Thomas Keller wrote: The monotone project is proud to announce the release of version 0.45 of its version control software. Was just committed to FreeBSD Ports: http://www.freebsd.org/cgi/getmsg.cgi?fetch=617808+0+current/cvs-ports just in time for upcoming release 8.0 I think... 0.45 is also in Gentoo. I was hoping to do the Debian packages today, but the phone company has broken my DSL and it probably won't be fixed till next week. So if someone wants to do it first, that would be great. Note, however, that http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542287 is only partially fixed in the current org.debian.monotone. Please don't do a package that doesn't finish the job. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Time for a release
On Sat, Sep 12, 2009 at 12:45 AM, Lapo Luchini l...@lapo.it wrote: % make monotone.pot make: *** No rule to make target `monotone.pot'. Stop. This has been changed to $ make $LANG.po-update in the past. Both targets exist and do different things. Mhh, nay: the both of them (the latter has a precedence on the one I quoted, BTW) are produced #-commented in Cygwin's Makefile. I wonder why, but really I don't think I will investigate. configure failed to find at least one of the msgfmt, msgmerge, and xgettext programs. It won't enable those rules unless you have all three. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Cygwin-1.7 tests [Was: Time for a release]
On Fri, Sep 11, 2009 at 8:32 AM, Lapo Luchini l...@lapo.it wrote: --- testlib.lua a019d00ccc1a886e692abd143d8d62416d7dbf8e +++ testlib.lua 0c442921922f2a426334d2c38488f2acace48422 @@ -877,6 +877,7 @@ function run_tests(debugging, list_only, LC_TIME }) do set_env(name,C) end + os.setlocale(C); So right above this, we run through a big list of LC_ environment variables and set them all to C. Why is that not good enough? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
FYI, since the Debian translation teams have been very prompt about translating the extra messages used by the monotone-server package (this provides init.d scripts and so on for running a monotone server), I've asked them for help with the more out-of-date translations -- es, fr, ja, pt_BR. I hope this doesn't step on anyone's toes. I doubt they will be able to do anything by Friday, regardless. 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 Thu, Aug 27, 2009 at 12:31 PM, Markus Wannermar...@bluegap.ch wrote: A voucher cert places a new-form signature on a particular set of old-form certs for a revision. The data I think we need to sign is revision_id || ( cert_hash || old_keypair_id || new_keypair_hash )* All of this reminds me of the atomic cert (or super cert) thingie. Wouldn't that be the absolute perfect combination for a common flag day? Well, despite the fact that we don't have atomic certs implemented... :-( You mean the date+author+changelog thing? That doesn't require a flag day ... we just switch version 0.whatever to start generating them, and document that old clients will not give useful log output for revs created with the new clients. Netsync doesn't care. (If we wanted to merge in the branch cert that would be different, but I don't think we should do that. So.) I don't think that change ought to be tied with this one, really. 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 Tue, Aug 25, 2009 at 9:38 PM, Timothy Brownawelltbrow...@prjek.net wrote: It sounds like the keys-by-hash change introduces a weaker sort of cert flag day, where old signatures can no longer be unambiguously verified (do I understand correctly?) However, there's a straightforward way to keep old history meaningful (see below), and it doesn't sound like it will be hard to keep speaking the old protocol (modulo negotiation issues) so we should. The old-format certs become ambiguous about which key they were signed with. They can be disambiguated by trying to verify the signature against each matching key (typically there will only be one) and seeing which one works. But you might not be easily able to obtain the correct key, if the (old-format) server knows a different key with the same name. Once the certs are taken off the wire they'll be matched with the correct key (or I guess dropped with a warning if we can't find that key) before being stored in the db, so any ambiguity will be confined to netsync time. I'm confused. The old signatures are over text including the old key id. How do you verify the signature on an old cert if you don't have a definitive way of identifying the old key id? I mean, the *point* of this change is that keys' user visible handles can now be changed, ya? At which point you don't have the old key handle and you can't reconstruct the text that was signed. This is what I was trying to solve with the voucher certs. I guess the trust hooks would see this as if the voucher key had signed the original certs? I'd prefer it if the trust hooks saw it as if the original key had signed the original certs. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Bumping required library versions
On Tue, Aug 25, 2009 at 4:56 AM, Stephen Leakestephen_le...@stephe-leake.org wrote: Zack Weinberg za...@panix.com writes: I'd like to bump to: automake 1.11 autoconf 2.64 botan 1.8.2 or 1.8.3 sqlite 3.6.12 boost 1.34 or 1.35 As pointed out in the flag day discussion, it might be good to support Debian 5.0 Lenny via backports of new monotone versions for a couple more years. That means not bumping any package version higher than what Lenny has: automake 1.10.1 autoconf 2.61 botan 1.7.8 sqlite 3.5.9 boost 1.35 I could live with these. It's unfortunate that we can't get a newer version of botan, but 1.7.8 is at least after the API change that's producing the largest number of #ifdefs in our code. The Lenny backports requirements include building on Lenny with no other backports, so these automake and autoconf versions are required. Debian builds from tarball releases that contain the automake and autoconf output, so technically we could get away with later versions, but if we ever needed to patch the configure script it would be a pain. Automake 1.10 is enough for the most important thing I want (native support for generating HTML from Texinfo). 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 Tue, Aug 25, 2009 at 11:17 AM, Ludovic Brentaludo...@ludovic-brenta.org wrote: Richard Levitte rich...@levitte.org writes: stephen_leake I agree; we should hold the next monotone release until stephen_leake netsync version negotiation is supported. So now, all we gotta do is hack that as good and fast as we can? Cheers, Richard ( it won't help current clients anyway, will it? ) Yes, it would; a client built from today's n.v.m head cannot speak to a server running on a long-term-support operating system such as Debian stable. Not can it speak to any other client a week old, for that matter. This is bad enough that we might want to consider reverting the keys-by-hash change until we have protocol negotiation in place, however we wind up doing 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 Tue, Aug 25, 2009 at 6:24 PM, Timothy Brownawelltbrow...@prjek.net wrote: I'm now thinking we can make the about-to-be-released clients work with current-version servers. If they see an earlier-version hello from the server, they just need to store that in the session and use it for all packets sent. The only actual difference would be the cert data packets, and which hashes to use during cert refinement (would have to store both old and new hashes in the db). That sounds good, but what about old-client, new-server? After looking at Philipp's email about what SMTP does for SSL, it looks like just adding a third alternative to auth/anonymous would work, let the client send a SSL packet (with no data) and then SSL negotiation starts. Make this the required response for new protocol versions, so the non-SSL stuff can be taken out eventually. Yeah. How would we go about testing this? Would we have to have a test that looks for specifically named old monotone executables (mtn-netsync6, etc) in your path, and runs against those if they exist (and does nothing if they don't exist)? It'd be nice to not require that much special setup, so the test would be more likely to actually run. As long as we have the old protocol code in the executable, we could have a debugging option that makes it only speak the old protocol, and use that for testing. How long would we want to try to stay compatible with old versions, maybe 2.5 or 3 years? Debian releases last 4 years now (2 as stable, 2 as oldstable), and Ubuntu LTS releases happen every 2 years and are good for 3 or 5 years. RHEL versions are apparently supported to some degree for 7 (!) years. You can still send mail with the protocol defined in RFC 822. I think it's a mistake to think about this in terms of time. Instead, we should think about it in terms of code burden to maintain support for the old protocol, and security-model burden to maintain the meaningfulness of old signatures. We last had a you must re-issue all of your certs event at version 0.25. There's no point in maintaining wire compatibility past that point (in fact, I doubt there is any point in keeping the rosterify/changesetify code anymore). It sounds like the keys-by-hash change introduces a weaker sort of cert flag day, where old signatures can no longer be unambiguously verified (do I understand correctly?) However, there's a straightforward way to keep old history meaningful (see below), and it doesn't sound like it will be hard to keep speaking the old protocol (modulo negotiation issues) so we should. If you have old hashes in your history, then people will still be receiving them arbitrarily far in the future during initial pulls. And there's no way to tell when those hashes were created. What I think this calls for is a new cert type, which I'm going to call voucher. A voucher cert places a new-form signature on a particular set of old-form certs for a revision. The data I think we need to sign is revision_id || ( cert_hash || old_keypair_id || new_keypair_hash )* where || is concatenation-with-separator and ( ... )* is repetition. (There's no need to include any of the data of the old cert since its hash is over all of that.) New clients trust certs in the old form if and only if there is a new-form voucher cert attesting to their validity. We then document that for this transition, one person per project must run a special command to generate voucher certs for all the old certs in the database, then everyone should pull from them, and if you have unpublished revisions you need to generate vouchers for those yourself. zw ___ 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
[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] list branches on server?
On Sun, Aug 23, 2009 at 7:15 AM, Timothy Brownawelltbrow...@prjek.net wrote: This applies to any library written in C++, not just Boost. Botan is in C++. And it applies to C libraries as well, but apparently they are more stable? In general, anyone experimenting with new versions of compilers has to be aware of such issues, and compile everything consistently. Yes... I guess what made this a boost issue is that boost was the only library we didn't bundle at the time. Also, boost pushes the boundaries of C++ a lot more than any other C++ library -- that's what it's *for*, kinda. I expect Botan to be a lot less trouble that way. C libraries do tend to be more stable. Do you know of a way to detect at runtime which compiler version was used for the libraries? mtn version --full prints at least some of the necessary information. zw ___ 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 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. 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. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sat, Aug 22, 2009 at 12:59 PM, Timothy Brownawelltbrow...@prjek.net wrote: So the question is, what needs to be done on the asio branch? And how can we mitigate the problems people have with linking against boost? Do we have a list of such problems? Maybe we can just assume boost got better :). The two that come to mind are * different (and therefore annoying) build system * version skew wrt libstdc++, eg boost and monotone have different ideas of what exactly an std::string looks like I suppose I should pop back in at this point, since I started the asio branch, and admit that I got stuck. In addition to the above problems, asio has what is IMO a serious design flaw: its I/O channel objects are statically typed. Since we wish to treat sockets, pipes, and whatever-fds-0-and-1-are as interchangeable, this requires a large hairy wrapper around all asio interfaces, which I started but got bogged down on. I'm also not sure asio's Windows support is good enough for us. I've been looking at libevent instead, but it has its own problems, e.g. not handling the creation of a network socket. It's written in C, though, so there's no question of ABI skew, and it uses a normal build system. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sat, Aug 22, 2009 at 9:03 PM, Derek Schergerde...@echologic.com wrote: On Sat, Aug 22, 2009 at 3:45 PM, Zack Weinberg za...@panix.com wrote: My impression is that libevent doesn't give us anything in the way of ssl help, while asio does do provide some support and uses openssl under the covers. I vaguely recall that there were/are licensing issues with using openssl directly but maybe that was back in the days of bundling various library sources or something? I wasn't aware that SSL was on the table, to be honest :) Libevent does not have any SSL implementation. But shouldn't that be done by, or on top of, Botan rather than at a lower level? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] list branches on server?
On Sat, Aug 22, 2009 at 8:02 PM, Derek Schergerde...@echologic.com wrote: I have been looking at this a bit, largely staring at netsync.cc to try and get a better idea of what it's doing though. Note that the net.venge.monotone.asio branch that zack started a while ago does not use boost::asio, but the standalone variant that does not require linking against the boost libraries as far as I can tell. It doesn't need Boost.System, but it does still depend on a few pieces of boost that we're not currently using, notably boost::date_time::posix_time, bleah. It does seem to need -lpthread on linux though as asio apparently uses threads internally to simulate certain asynchronous operations. Yeah, there's not much of an alternative there unless you want to implement your own DNS resolver, which isn't a good idea. [Linux does have getaddrinfo_a, but it's not portable, it may still use threads under the hood, and it reports completion with *signals*. Gag.] Another thought on this that I've had floating around for a while is that perhaps rather than starting a second process and running netsync over stdio we could have two separate database instances open and sync between them from within a single process. I haven't looked at this in any detail at all so it might just be a crazy idea, but I think it would avoid all of the windows related network issues. Maybe some of the refactoring that zack and markus did a while ago relating to app_state, options and database arguments in various api's would make the idea of having two open database objects less crazy? That was one of my goals, in fact. We may not be 100% of the way there yet though. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] File Revisions
mtn au select a:hugo.corne...@gmail.com
will give you the complete list without any of the other stuff that
'mtn log' prints, and on stdout, for added convenience.
zw
On Wed, Aug 19, 2009 at 2:42 AM, Hugo Cornelishugo.corne...@gmail.com wrote:
If you are looking for a command line that informs you about the
revisions from one author, this is the command line that I use:
mtn log --from a:hugo.cornel...@gmail.com --last 1 21 /dev/null | less
I am not sure if this works under all circumstances, but so far it
seems to work fine for me.
Hugo
On Wed, Aug 19, 2009 at 4:23 AM, Daniel Carosoned...@geek.com.au wrote:
On Wed, Aug 19, 2009 at 01:59:07PM +0530, rk ka wrote:
This may be really trivial but how can I get a list of all revisions
(file versions) i have committed to the db?
All the revisions where a particular file changed? mtn log file
If you use --brief --no-graph | awk '{print $1}' or similar, you can
get just the rev id's.
--
Dan.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
--
Hugo
--
Hugo Cornelis Ph.D.
Neurospaces Project Architect
http://www.neurospaces.org/
Research Imaging Center
University of Texas Health Science Center at San Antonio
7703 Floyd Curl Drive
San Antonio, TX 78284-6240
Phone: 210 567 8112
Fax: 210 567 8152
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn and superuser on Fedora 11
This is a known bug in the Botan cryptography library that we use. I
don't know exactly which version fixed the bug, but it *has* been
fixed; try to get a newer version of libbotan.
zw
On Tue, Aug 11, 2009 at 3:54 PM, Nicolas Ruizjuan.r...@ula.ve wrote:
Apologies in advance if this had already been covered, but I couldn't
find anything related to this.
I use mtn to keep track of changes in the /etc directory (Linux). Since
there are plenty of files that are not world-readable I have to run mtn
as root (or under sudo). This works well under Debian unstable, but I'm
having problems getting it to work in Fedora 11.
For the record, on both distributions I'm using monotone 0.44 (base
revision: 7a4832143b3146ca89f5cb91e0e571d05e29d4b9)
On Fedora mtn gets stuck during commit or generating the keys. Under
strace I get (again, executing commit or genkey) to:
close(11) = 0
lstat64(/proc/kmsg, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
open(/proc/kmsg, O_RDONLY|O_NOCTTY) = 11
read(11,
and stays there. I had left mtn hang there for at least 24 hours while
doing other work and it doesn't complete.
I tried disabling SELinux, just in case, and it has no effect.
I also tried --ssh-sign yes|no|only, no effect.
Running with --debug does not give any useful info.
Any ideas?
Thanks in advance
nicolas
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 0.44 pull progress on windows
Maybe what we should do is believe isatty() if it returns true, but check TERM if it returns false? I can think of situations where that would break something, but I think they would be rarer than now. On Thu, Aug 6, 2009 at 9:37 AM, Diego Nieto Ciddnie...@gmail.com wrote: 2009/8/6 Thomas Keller m...@thomaskeller.biz: Stephen Leake schrieb: As far as I can see in win32/terminal.cc to get --ticker=count by default the environment variable TERM must be set to something other than or dumb. I have no windows box available, but maybe somebody else with such a box could improve the detection code there? Oh, I see. There's a comment // Win32 consoles are weird; cmd.exe does not set TERM, but isatty returns // true, Cygwin and MinGW MSYS shells set a TERM but isatty returns false. // Let's just check for some obvious dumb terminals, and default to smart. The unexpected behaviour of isatty seems to be a pretty old issue due to bash actually running on a pipe. http://osdir.com/ml/gnu.mingw.msys/2002-10/msg8.html : It's because of rxvt pty communcating to bash tty. I.E.: Through rxvt bash stdio is not interactive. cmd may be fixed by instructing it to set the TERM environment variable during monotone setup. This can be acomplished by changing the AutoRun[1] registry setting to something like set TERM=cmd. That would break front-ends' instances started from a command shell. However, that should be something rare on windows world. Other than setting stdin to a pipe, what are front-ends required to do for triggering dumb mode? i.e. do they have to set TERM to dumb? --- [1] http://technet.microsoft.com/en-us/library/cc779439%28WS.10%29.aspx ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] update --move-conflicting-paths
On Thu, Aug 6, 2009 at 4:22 PM, Stephen Leakestephen_le...@stephe-leake.org wrote: ... I'm not clear why the date-time was considered necessary. Recently, Thomas Keller suggested replacing it with the revision id. That would at least solve the Windows path problem. But I'm not clear what problem there is with just _MTN/resolutions/workspace_path. User forgets to clean up? ... That would need a better name if there is a use case that would try to move a file with the same workspace path there again (assuming the user forgets to clean up). I can't think of a reasonable use case that does that. It's not good UI to error out just because last week you did something and then forgot about it. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone 0.44 pull progress on windows
It thinks the Windows console is not a terminal for some reason. The display you see is intended for a front-end to consume. 1) Where did you get your 'mtn' exe? 2) Is your terminal window the normal Windows CMD.EXE, or something else (Cygwin bash, MSH, Interix, ...)? zw On Wed, Aug 5, 2009 at 1:46 PM, diego nieto ciddnie...@gmail.com wrote: I've pulled a repository on windows and the progress is displayed in a really weird and almost impossible to understand way: - mtn: halando anonimamente; use -kNOMBRE_LLAVE si necesita autenticaci¾n mtn: conectandose a pidgin.im mtn: buscando items que sincronizar: mtn: ticks: c=certificados/256, k=llaves/1, r=revisiones/64 mtn: ckr mtn: rrr [snip] mtn: ckk mtn: ticks: =bytes in/1024, =bytes out/1024, c=certs in/3, r=revs in/1 mtn: cr mtn: [snip] mtn: rccrcrcrccrcrcrccrcrcrccrcrcrccrcrcrccrcrcrccrcrcrccrcrcrccrcr mtn: crccrcrcrccrcrcrccrcrcrccrcrcrccrcrcrccrcrcrccrcrcrccrcrcrc [snip] - Is this the intended behaviour on the running os? I thought something like a table was shown. But probably that was on linux. I can't say it's been a long time since the last pull. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone 0.44 bug.
On Wed, Jul 29, 2009 at 7:38 PM, david crandalldavecrand...@gmail.com wrote: First, before you look too far into this, there's something I should mention that will probably set your mind at ease. I basically took a monotone database from version 0.40 on linux, and copied it over for use in windows on 0.44. I figure if it said, update your stuff, it would ask. There's no database migration needed going from 0.40 to 0.44. And if you did need one, yes, it is supposed to tell you, rather than crashing like this. Y:\mtn --db y:/mtn_db/.dave.mtn --key da...@fortunet.com --keydir y:/keystor co --branch com.fortunet.altanik -r 6ba39f0 --debug ... mtn.EXE: - begin 'inT' (in std::string normalize_path(const std::string), at paths.cc:262) mtn.EXE: /com.fortunet.altanik mtn.EXE: - end 'inT' (in std::string normalize_path(const std::string), at paths.cc:262) mtn.EXE: paths.cc:307: detected internal error, 'I(!is_absolute_here(inT))' violated Ok, this looks like a real bug: you are trying to do a checkout in the root directory of a Windows drive, which should be fine, but may never have been attempted before. And you didn't specify a directory to check out into, so it's trying to form the directory name from the branch name, and losing the drive letter, which makes the path normalization logic unhappy. I do not have a working Windows development environment right now, so I can't fix this bug. I don't know whether anyone else reading monotone-devel has the time and the setup to do it. [To anyone who tries: I think the problem is either in the system_path() constructor, or in workspace::create_workspace().] However, you should be able to work around the problem by doing your checkouts somewhere other than the root of a drive. You may also be able to work around the problem by specifying a directory for the checkout on the command line. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone 0.44 bug.
On Wed, Jul 29, 2009 at 2:24 PM, david crandalldavecrand...@gmail.com wrote: It failed to write a debugging log. I tried to do this: mtn --db y:/mtn_db/.dave.mtn --key da...@fortunet.com --keydir y:/keystor co --branch com.fortunet.altanik -r 6ba39f0 Please repeat this command with --debug appended to the command line, and post the complete and unedited output. (Unless for some reason your pass phrase appears in there. Edit that out. But don't touch anything else, please.) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] internalize_rsa_keypair_id()
On Sun, Jul 26, 2009 at 4:36 PM, Timothy Brownawelltbrow...@prjek.net wrote: Is there any particular reason that we ACE-encode[1] the domain part (after the '@') of key names on input, and then never decode them (the only place that externalize_rsa_keypair_id() is ever called is when writing _MTN/options)? I'm working on making certs link to keys by hash instead of name, which seems like a perfect opportunity to also get rid of this since the schema is changing anyway. I recall asking Graydone this many moons ago and being told that it was basically historical junk. And around the same time I surveyed a bunch of monotone databases and couldn't find anything that wasn't plain ASCII. You've maybe got a bigger data set with your hosting service, though. In principle I would be glad to see all of that go. However, two cautions: We are getting Unicode normalization (to some schema or other) as a side effect. We maybe don't need that anymore if keys are indexed by fingerprint rather than human-readable name, but I would think carefully about the consequences of a visual collision for each thing-in-the-database that loses normalization. Also, we are using libidn as a wrapper around libiconv (via stringprep_convert) as well as for ACE, and we *need* (but don't have) better Unicode awareness in several areas (e.g. pathnames) that libidn might be able to help with -- I haven't looked at its full API though. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn: Fataler Fehler after monotone Rev. 0.43 installation
On Wed, Jun 3, 2009 at 5:29 PM, Stephen Leake stephen_le...@stephe-leake.org wrote: I renamed the folder C:\monotone\locale to C:\monotone\locale_old and now i have nooo problems. Which raises the issue; why is the locale directory packaged with the Win32 monotone? It is not packaged with the Linux binary. Are the various translation strings linked into the executable somehow? If so, then we don't need the locale directory. The translation strings are not linked into the executable; you definitely need the locale directory if you want native language messages. We may not ship it with the standalone Linux binary, but it's definitely in the various distribution packages. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone serve - no listen port opened?
On Tue, Jun 2, 2009 at 3:24 PM, J Decker d3c...@gmail.com wrote:
How can I validate (other than with netstat) that monotone is opening
a tcp port? (I tried adding the --bind 0.0.0.0:4691 and --bind :4691
and --bind specific IP:4691, and none of them opened a port, as seen
in 'netstat -ant' (linux)
Try strace; the last few operations should be something like this
(beware, the trace may include your pass phrase in cleartext):
$ strace mtn -d monotone.mtn serve
...
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 13
fcntl(13, F_GETFL) = 0x2 (flags O_RDWR)
setsockopt(13, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(13, {sa_family=AF_INET, sin_port=htons(4691),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 14
fcntl(14, F_GETFL) = 0x2 (flags O_RDWR)
setsockopt(14, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(14, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(14, {sa_family=AF_INET6, sin6_port=htons(4691),
inet_pton(AF_INET6, ::, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = 0
listen(13, 128) = 0
listen(14, 128) = 0
write(2, mtn: beginning service on all i..., 50) = 50
mtn: beginning service on all interfaces : 4691
select(15, [13 14], [13 14], [13 14], NULL
and then it should block until a connection is received.
zw
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [ANN] monotone 0.44 released
On Sun, May 31, 2009 at 5:57 AM, Stephen Leake stephen_le...@stephe-leake.org How do you accomplish this? The monotone Makefile builds a dynamically linked executable. Simply by building the libraries with --disable-shared, and (in case of libidn which doesn't care about user wishes) moving the dll (and .dll.a) aside. The build automatically picks up the static libraries. configure doesn't take option --disable-shared. Or at least, it accepts that option, but it has no effect (I only tested this on Debian; my Windows system needs to be rebuilt). I think he means building all the *libraries* with --disable-shared, so that there aren't shared libraries for the system to pick up. So it would be useful if configure (or the Makefile) supported a --disable-shared option. This is a little harder than it looks because nowadays pkg-config goes to some length to not list recursive dependencies in its --libs output (these are harmful for shared linkage, but required for static linkage, for stupid historical reasons both ways). It could be done but it would require modifying the autoconf scriptage around pkg-config as well as the ultimate link line. Also, there's a very real question of exactly how static you want your binary to be. If I were doing it I would probably preserve shared linkage against everything that the compiler implicitly includes (libstdc++, libgcc_s, libc, and possibly one or two others) because staticly linking those can cause bizarre problems, but if you have libstdc++ version skew to deal with that may not be good for you either... zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Text under revision control
On Fri, May 29, 2009 at 12:00 PM, hend...@topoi.pooq.com wrote: On Fri, May 29, 2009 at 06:39:18PM +, Hendrik Boom wrote: So. Monotone does appear to merge on a line-by-line basis. Too bad for OpenOffice's .fodt file type. Actually, byte-by-byte or word-by-word probably wouldn't be enough. We'd need something that can guarantee to produce valid XML that satisfies Open Document Format syntax. A three-way merge algorithm aware of not only XML but the ODF schema is definitely out of scope for monotone itself. But I'd be happy to have a mechanism that could dispatch noninteractive three-way merges to external tools based on file attributes, file name extensions, or magic numbers in the file contents. (And of course also dispatch *interactive* conflict resolution requests similarly.) I could argue either way on the question of whether the default algorithm should be byte- or word-oriented rather than line-oriented. It's the usual tradeoff between false conflict and false lack of conflict -- for our core competency of program source code, two changes that modify the same line could easily be a true conflict even if they are independent in terms of byte ranges modified. On the other hand, I've heard plenty of this is obviously not a conflict, why did the computer throw a conflict at me complaints where the issue was that it wasn't going down to finer than lines, and Ediff's ability to do byte range comparison within a conflict is very handy. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn log now converts dates to the user's timezone
At present, the only thing affected is 'log'. My immediate thought is that absolutely we should *not* apply these changes to the automate interface, because that's intended for machine consumption; in particular, you don't want to have to parse whatever arbitrary gunk the user put in their date format spec. On the other hand I've never written anything that consumed automate output. Are there contexts where it would be useful to get dates (specifically, the values of date certs) still in ISO date format but converted to the local time zone? zw On Fri, May 29, 2009 at 12:15 PM, Support supp...@coosoft.plus.com wrote: Presumably these display times in local time changes will also affect any dates/times output via au and au stdio? Many thanks for making these changes btw :-)... Tony. This has been requested many times - I just now got around to doing it. You get output like this: o - | Revision: a12108115b1ba91ab5bc3cb58700f35c93fa18b0 | Ancestor: 31dc9889d2a9a1fecc4acf1abb8703aec3ea9113 | Author: mtn-...@zackw.users.panix.com | Date: 27 May 2009, 01:23:19 PM | Branch: net.venge.monotone There's command line options and a Lua hook to turn it off and/or customize the date formatting. I think log is the only command that actually prints dates to the user -- it would be easy to change any other command that does the same. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn log now converts dates to the user's timezone
On Thu, May 28, 2009 at 2:13 AM, Richard Levitte rich...@levitte.org wrote: Mmm, maybe we should think of having the --date option take local time specs as well then... I've seen many users get confused by date inconsistensies in other software... Yeah, that should really happen, and we should support more different input date formats too. I've not been able to find a date parser that I really like, though. The best thing out there is GNU getdate.y but that has some sketchy code in it and would add a build dependency on Bison. I'd love to hear what other people think. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn log now converts dates to the user's timezone
On Fri, May 29, 2009 at 12:39 PM, Thomas Moschny thomas.mosc...@gmx.de wrote: Zack Weinberg wrote: At present, the only thing affected is 'log'. My immediate thought is that absolutely we should *not* apply these changes to the automate interface, because that's intended for machine consumption; in particular, you don't want to have to parse whatever arbitrary gunk the user put in their date format spec. Exactly what I thought. Converting dates to some locale is something a presentation layer should do. I could argue, though, that back-converting from the textual UTC date format that monotone prints to a system time_t that can be handed to localtime() is a huge pain, and monotone already *has* that code... zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] mtn log now converts dates to the user's timezone
This has been requested many times - I just now got around to doing it. You get output like this: o - | Revision: a12108115b1ba91ab5bc3cb58700f35c93fa18b0 | Ancestor: 31dc9889d2a9a1fecc4acf1abb8703aec3ea9113 | Author: mtn-...@zackw.users.panix.com | Date: 27 May 2009, 01:23:19 PM | Branch: net.venge.monotone There's command line options and a Lua hook to turn it off and/or customize the date formatting. I think log is the only command that actually prints dates to the user -- it would be easy to change any other command that does the same. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mismatched certs
This can happen when the exact same revision is created more than once. It's very easy to do that with merge revisions, since they are mechanically generated and more than one person might notice the multiple-head condition. It's harmless. zw On Thu, May 21, 2009 at 10:14 AM, Mando Rodriguez mandorodrig...@gmail.com wrote: Hello, Does anybody know what causes multiple dates on a cert? I have three dates for this revision: *mtn: revision 2893019522d87d7f852763c3e317e1dab80683fd mismatched certs (1 authors 3 dates 1 changelogs) mtn: warning: 1 mismatched certs * *o - |\ Revision: 2893019522d87d7f852763c3e317e1dab80683fd | | Ancestor: 05530408cdc949033a8ce61a9b7c8fa4febb40cc | | Ancestor: 474941794d36ba7ed09ea7ddb92da2a619432eac | | Author: mandorodrig...@gmail.com | | Date: 2009-03-04T17:49:35 | | Date: 2009-03-04T19:48:48 | | Date: 2009-03-04T00:14:43 | | Branch: 0 | | | | Deleted entries: | | algorithms/aclocal.m4 algorithms/config.h.in | | algorithms/configure algorithms/configure.in | | algorithms/event/aclocal.m4 algorithms/event/config.h.in | | algorithms/event/configure algorithms/event/configure.in | | algorithms/symbol/aclocal.m4 algorithms/symbol/config.h.in | | algorithms/symbol/configure algorithms/symbol/configure.in | | configure.in convertors/aclocal.m4 convertors/configure | | convertors/configure.in glue/swig/aclocal.m4 | | glue/swig/configure glue/swig/configure.ac | | glue/swig/perl/aclocal.m4 glue/swig/perl/configure | | glue/swig/perl/configure.ac glue/swig/perl/install-sh | | glue/swig/python/aclocal.m4 glue/swig/python/configure | | glue/swig/python/configure.ac glue/swig/python/install-sh | | glue/swig/python/missing | | Modified files: | | .mtn-ignore Makefile.am Makefile.in aclocal.m4 | | algorithms/Makefile.in algorithms/event/Makefile.in | | algorithms/symbol/Makefile.in config.guess config.sub | | configure convertors/Makefile.in glue/swig/Makefile.in | | glue/swig/perl/Makefile.am glue/swig/perl/Makefile.in | | glue/swig/python/Makefile.am glue/swig/python/Makefile.in | | hierarchy/symbols neurospaces/config.h.in tests.config | | | | ChangeLog: | | | | merge of '05530408cdc949033a8ce61a9b7c8fa4febb40cc' | | and '474941794d36ba7ed09ea7ddb92da2a619432eac' * The Monotone version is 0.43. Thanks, -Mando ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [ANN] monotone 0.44 released
On Tue, May 12, 2009 at 2:19 PM, Thomas Keller m...@thomaskeller.biz wrote: monotone 0.44 was released today. This is a maintenance release which fixes a couple of bugs and regressions from 0.43 and earlier versions. As usual you can find a list of all changes in the NEWS file. Binaries are posted as they come in. I've pushed the required changes for the Debian package but I have not uploaded binaries anywhere because libbotan1.8 in unstable is severely broken (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527461). The botan package maintainer said over a week ago that a fix would happen today but, well, that was over a week ago. :-( zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone windows release 0.44....
zlib most definitely is used, but it might not be that copy of it that's getting used. libpcrecpp-0.dll and libpcreposix-0.dll, on the other hand, are definitely *not* needed. We don't play tricks with LoadLibrary as far as I know. For reference, this is the set of libraries required in an as-dynamically-linked-as-possible Linux build: $ objdump --private-headers /usr/bin/mtn | grep NEEDED NEEDED libpcre.so.3 NEEDED libbotan-1.8.2.so NEEDED liblua5.1.so.0 NEEDED libsqlite3.so.0 NEEDED libidn.so.11 NEEDED libz.so.1 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so.6 On Thu, May 21, 2009 at 4:11 PM, J Decker d3c...@gmail.com wrote: Why are zlib1.dll, libpcrecpp-0.dll and libpcreposix-0.dll included in the installation if they aren't used? copying mtn and dependancies only copes [ libiconv-2.dll libidn-11.dll libintl-8.dll libpcre-0.dll mtn.exe ] I guess they might be dynamically loaded with LoadLibrary and GetProcAddress... but there's no reference of the text 'zlib' in any of the files except zlib1.dll... uhmm I guess it might be unicode... ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone windows release 0.44....
Yes, I know. The point is that those are the libraries that the program actually uses; the list on Windows or any other platform should be similar. On Thu, May 21, 2009 at 4:32 PM, J Decker d3c...@gmail.com wrote: Hrm... that doesn't help me that's a list from a Linux or other distribution, the subject is Windows 0.44. On Thu, May 21, 2009 at 4:18 PM, Zack Weinberg za...@panix.com wrote: zlib most definitely is used, but it might not be that copy of it that's getting used. libpcrecpp-0.dll and libpcreposix-0.dll, on the other hand, are definitely *not* needed. We don't play tricks with LoadLibrary as far as I know. For reference, this is the set of libraries required in an as-dynamically-linked-as-possible Linux build: $ objdump --private-headers /usr/bin/mtn | grep NEEDED NEEDED libpcre.so.3 NEEDED libbotan-1.8.2.so NEEDED liblua5.1.so.0 NEEDED libsqlite3.so.0 NEEDED libidn.so.11 NEEDED libz.so.1 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so.6 On Thu, May 21, 2009 at 4:11 PM, J Decker d3c...@gmail.com wrote: Why are zlib1.dll, libpcrecpp-0.dll and libpcreposix-0.dll included in the installation if they aren't used? copying mtn and dependancies only copes [ libiconv-2.dll libidn-11.dll libintl-8.dll libpcre-0.dll mtn.exe ] I guess they might be dynamically loaded with LoadLibrary and GetProcAddress... but there's no reference of the text 'zlib' in any of the files except zlib1.dll... uhmm I guess it might be unicode... ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone windows release 0.44....
*shrug* It was probably statically linked against the other libraries, then. I wouldn't worry about it. zw On Thu, May 21, 2009 at 4:40 PM, J Decker d3c...@gmail.com wrote: depends indicates that the files I copied using my program which is also able to find the refernced DLL's (and their refrenced dlls) has no missing dependancies, and is only the 5 files I listed to start. depends on the initial installation reveals no reference to zlib1.dll On Thu, May 21, 2009 at 4:34 PM, Thomas Keller m...@thomaskeller.biz wrote: J Decker schrieb: On Thu, May 21, 2009 at 4:18 PM, Zack Weinberg za...@panix.com wrote: zlib most definitely is used, but it might not be that copy of it that's getting used. libpcrecpp-0.dll and libpcreposix-0.dll, on the other hand, are definitely *not* needed. We don't play tricks with LoadLibrary as far as I know. For reference, this is the set of libraries required in an as-dynamically-linked-as-possible Linux build: $ objdump --private-headers /usr/bin/mtn | grep NEEDED NEEDED libpcre.so.3 Hrm... that doesn't help me that's a list from a Linux or other distribution, the subject is Windows 0.44. What does Depends.exe [0] show you? [0] http://www.dependencywalker.com/ -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] what exactly is tests/spawn_redirected_hook_helper testing?
On Fri, May 8, 2009 at 5:23 AM, Timothy Brownawell tbrow...@prjek.net wrote: On Sun, 2009-04-05 at 17:46 -0700, Zack Weinberg wrote: The 0.43 package for Debian is failing to build on several of their architectures because tests/spawn_redirected_hook_helper is unreliable on a heavily loaded machine; there's a race where one of the processes created by the test can hang around and create a file just when the test runner is trying to blow away the test directory, causing that to fail. I'm pretty clear on how the race happens, but I'm not sure what the test is actually *testing*, so it's not clear how to fix it. Anyone know? ...how does it happen? The only thing that I'd think would be specific to that test is the cp that's spawned in the hook, but it waits for that on line 18 so it should be gone when the test ends (plus the last check would fail if that was the problem, which should make it *not* blow away the directory for that test). I added both the wait on line 18 of the hook and the check line that I think you're referring to, in revision ca9e27455b19faae0b4381613a18dec47a46b1de. This does seem to have eliminated the race condition, but may well have made the test no longer test anything meaningful... zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] what exactly is tests/spawn_redirected_hook_helper testing?
On Fri, May 8, 2009 at 7:25 PM, Timothy Brownawell tbrow...@prjek.net wrote: I added both the wait on line 18 of the hook and the check line that I think you're referring to, in revision ca9e27455b19faae0b4381613a18dec47a46b1de. This does seem to have eliminated the race condition, but may well have made the test no longer test anything meaningful... Oh, hmm. Well, I think that actually helps a bit since now it makes sure that the output file really was created in addition to checking that the command got executed. But now that I think about it, that test really says nothing useful and would only have been meaningful in the old GNU Autotest testsuite. It's meant to check that the spawn_redirected() call works properly, but that call is used internally in the tester for pretty much every command it executes. If it did break, probably every single test would fail. Maybe we should just delete the test then? Or move it to tester_tests somehow (and make it not use the main 'mtn' executable)? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug in monotone
Do you think this bug is significant enough to warrant an 0.43.1 patch release? zw On Thu, May 7, 2009 at 3:36 PM, Timothy Brownawell tbrow...@prjek.net wrote: On Thu, 2009-05-07 at 13:50 +0200, Petr Vorel wrote: Hello, I had problems with monotone 0.43 (base revision: ddc6546051abf6475c40a3fdba272e2f82a40e94). More info you can find in attached files. This occured when I tried to commit something. I solved it with downgrade to version 0.40: Thanks, this will be fixed in the next release. One of your hooks is calling includedir() on a directory that doesn't exist. This throws an exception, which does horrible things when it propagates into the system liblua that doesn't have exception support. Older monotone versions used a bundled liblua that I think knew how to convert the exception to a lua error. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net If monotone breaks network compatibility you'll see it here first (probably even before the new version shows up in your distro's repositories). ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] bug in monotone
On Thu, May 7, 2009 at 6:23 PM, Timothy Brownawell tbrow...@prjek.net wrote: ... Or we could just release 0.44, it has been over a month. I'd be fine with that. Richard, what do you think? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] integrating monotone
On Mon, May 4, 2009 at 10:00 PM, Dhana Sekar dhana...@gmail.com wrote: I am a newbee to Monotone. I would like to integrate the Monotone with SAS system to control the source codes that are developed by SAS system. Please help me to acheive this, thanks. That's an interesting project, but I doubt anyone here knows anything about SAS. I certainly don't. We're happy to help with specific problems but you're going to need to do most of the work yourself, I'm afraid. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] integrating monotone
I don't know, I've never used Tortoise SVN. Perhaps someone else on the list knows. zw On Tue, May 5, 2009 at 7:35 AM, Dhana Sekar dhana...@gmail.com wrote: Is Monotone look like Tortoise SVN? On Tue, May 5, 2009 at 12:18 PM, Zack Weinberg za...@panix.com wrote: On Mon, May 4, 2009 at 10:00 PM, Dhana Sekar dhana...@gmail.com wrote: I am a newbee to Monotone. I would like to integrate the Monotone with SAS system to control the source codes that are developed by SAS system. Please help me to acheive this, thanks. That's an interesting project, but I doubt anyone here knows anything about SAS. I certainly don't. We're happy to help with specific problems but you're going to need to do most of the work yourself, I'm afraid. zw -- Best, Dhanasekaran Programmer analyst Spatial Comps (I) Pvt. Ltd www.yourblacklab.com Mob: +919894419394 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: file-system archaeology
On Mon, May 4, 2009 at 10:07 AM, Lapo Luchini l...@lapo.it wrote: To experiment page_size, a simple shell script can be used, such as: ( echo 'PRAGMA page_size = 1024;' ; echo .dump | sqlite3 old-db ) \ | sqlite3 new-db Caution: you also need echo 'PRAGMA user_version = 1598903374;' inside the parentheses, or mtn will refuse to read the copied database. Arguably a bug in sqlite3 .dump, that. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Possible Minor Bug With Automate Stdio I/F select...
On Sun, May 3, 2009 at 5:49 AM, Anthony Edward Cooper aecoo...@coosoft.plus.com wrote: default: - W(F(unknown selector type: %c) % sel[0]); + E(false, origin::user, F(unknown selector type: %c) % sel[0]); break; That's a fairly significant behavior change and visible to non-automate use, but it seems to me that it's maybe what we actually want -- something like mtn log --from x: right now spews every revision in the database to stderr... I'd like to hear what other people think before it lands, though. Minor style nit: since E(false, ...) unconditionally throws, remove the 'break;' afterward. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] file-system archaeology
On Tue, Apr 28, 2009 at 1:11 PM, hend...@topoi.pooq.com wrote: I'm doing some file-system archaeology again, and I've found a monotone data base with no branches. It's 311296 bytes long, so it's unlikely to be empty. Yet, hend...@lovesong:~/monotone$ mtn list branches --db w.db hend...@lovesong:~/monotone$ This should give you all head revision IDs, despite the absence of branches: $ mtn -d w.db execute 'select hex(id) from revisions' | tail -n +3 | mtn -d w.db au erase_ancestors -@ - You should then be able to check one of them out with 'mtn co -ri:id' zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] file-system archaeology
On Tue, Apr 28, 2009 at 1:35 PM, Zack Weinberg za...@panix.com wrote: On Tue, Apr 28, 2009 at 1:11 PM, hend...@topoi.pooq.com wrote: I'm doing some file-system archaeology again, and I've found a monotone data base with no branches. It's 311296 bytes long, so it's unlikely to be empty. Yet, hend...@lovesong:~/monotone$ mtn list branches --db w.db hend...@lovesong:~/monotone$ This should give you all head revision IDs, despite the absence of branches: $ mtn -d w.db execute 'select hex(id) from revisions' | tail -n +3 | mtn -d w.db au erase_ancestors -@ - That's mtn -d w.db db execute, of course. *headdesk* This might also be interesting: $ mtn -d w.db db execute 'select hex(id),keypair,name,value from revision_certs order by id,name' | less zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] file-system archaeology
On Tue, Apr 28, 2009 at 2:15 PM, hend...@topoi.pooq.com wrote: What a surprise! 311296 bytes of nothing. Yet I have another data base from even darker dark ages, which I first had to upgrade with mtn upgrade and mtn rosterify. It gives me: hend...@lovesong:~/monotone$ ls -l database.db -rw-r--r-- 1 hendrik sbox 46080 2009-04-28 16:09 database.db hend...@lovesong:~/monotone$ mtn list branches --db=database.db com.pooq.topoi.sandbox hend...@lovesong:~/monotone$ This one is smaller -- only 46080 bytes -- and has something in it. I wonder what all that overhead is doing. What does 'mtn db info' print for these databases? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] file-system archaeology
On Tue, Apr 28, 2009 at 3:04 PM, Zack Weinberg za...@panix.com wrote: On Tue, Apr 28, 2009 at 2:15 PM, hend...@topoi.pooq.com wrote: I wonder what all that overhead is doing. What does 'mtn db info' print for these databases? I poked at this a little. SQLite database files are divided into pages; we set each page to be 8192 bytes long. There is one page of metadata (there could be more if we had a more complicated database schema), and each table or index occupies at least one page, even when empty. Our schema consists of 15 tables and 22 indexes. So, a totally empty database is 1 + 15 + 22 = 38 pages, and if you multiply that by 8192 you get 311296 bytes. Your old database was probably created at a time when we set a smaller page size; the page size cannot be changed after any tables are created. 'mtn db info' will say. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] finding the monotone root directory
On Wed, Apr 15, 2009 at 10:24 PM, Hugo Cornelis hugo.corne...@gmail.com wrote: I fairly regularly go crazy finding the monotone root directory in a workspace with many nested directories. I believe you are looking for mtn automate get_workspace_root. :-) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone bug
2009/4/14 Andrey Panchenko andrew.panche...@googlemail.com:
I tried to add files that have cyrillic letters.
Редактор ландшафта (тех. задание).doc for example.
[and it didn't work]
This is a well-known, and unfortunately difficult to fix, bug. It may
be easier to fix for Windows than Unix because Windows actually has
rules about the character encoding used for file names, but that
doesn't mean you're getting a fix anytime soon. We apologize.
If you are interested in helping us fix the bug, the problem is in
{unix,win32}/fs.cc: the Windows version should be using the W versions
of various system calls (notably FindFirstFile/FindNextFile) and
translating to utf8, the Unix version needs to check what comes back
from readdir() first for already-UTF8 and then for strings in the
current locale's charset.
zw
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] serving and locking databases
On Sun, Apr 12, 2009 at 2:47 PM, Hugo Cornelis hugo.corne...@gmail.com wrote: However, when I interrupt the server process using a kill command to send it a TERM signal, it leaves the database locked. Any operation against the locked database will fail seems. It's supposed to detect a stale lock and automatically remove it. Please post the complete output of any failing command, with --debug added to the command line. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] what exactly is tests/spawn_redirected_hook_helper testing?
The 0.43 package for Debian is failing to build on several of their architectures because tests/spawn_redirected_hook_helper is unreliable on a heavily loaded machine; there's a race where one of the processes created by the test can hang around and create a file just when the test runner is trying to blow away the test directory, causing that to fail. I'm pretty clear on how the race happens, but I'm not sure what the test is actually *testing*, so it's not clear how to fix it. Anyone know? Also, does anyone have a Linux/Sparc box (ideally Debian, but the problem is unlikely to be specific to them) that I could bum a login on? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] to make monotone build on OpenSolaris
2009/3/29 Patrick Georgi patr...@georgi-clan.de: - import more stuff from std:: and Botan:: into the globally visible namespace - clarify method selection for .insert(0,...) where studio isn't sure whether that 0 is unsigned int or void* and it has that method for both - consistent const attribute for arguments of various methods (studio is picky there, too) These all look safe to me; please go ahead and commit them. It's a little disappointing that Sun's compiler doesn't do the special lookup rule (I can't remember what it's called in the C++ standard) that means you shouldn't really need those additional using-directives, but adding them does no harm and makes for less cognitive load on human readers anyway. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn 0.43dev: failed to convert string from UTF-8 to ANSI_X3.4-1968
2009/3/14 Derek Scherger de...@echologic.com: 2009/3/7 Jack Lloyd ll...@randombit.net mtn: fatal: error: failed to convert string from UTF-8 to ANSI_X3.4-1968: '- mtn: error: Revision: 424e1cf5155ae4473250978ae6b7e44e12775741 ... mtn: error: Added to E28098contrib/E28099 an useful script by Richard Levitte. ... I've tracked this problem down to the following change Revision: 9c0bb9b509e63897e6a52c907988cef2d4a8fe0d Ancestor: 1c069d8736d169b25eaa747d9a5ceabcb59e79b6 Author: mtn-...@zackw.users.panix.com Date: 2009-01-23T22:43:07 Branch: net.venge.monotone.stripped ChangeLog: Configuration cleanup part 2. Thanks for finding the problem change. I've pushed a fix in rev 63361f1c30b0d8e84bbe32b758414e36fdb786e6. What's going on here is, revision 424e1cf... has curly quote marks in its change log (U+2018, U+2019) which are not representable in the C locale. We used to have special hacks to our local copy of libidn that would tell iconv() to substitute fallback characters (plain old ASCII U+0027 APOSTROPHE, in this case) if possible, and fall back to question marks otherwise. Obviously we can't do that anymore. The .stripped branch substituted a somewhat flimsier hack in our code (charset_convert()) that was dependent on an autoconf test. I thought that autoconf test was unused, so I took it out in configuration cleanup part 2. Boom. What I've done now is revise the flimsy hack in charset_convert() so it doesn't need an autoconf test. However, with iconv() implementations that do not support the //TRANSLIT modifier on the destination charset (this is all of them except glibc gnu iconv, I believe) mtn log will blindly dump out the unconverted string if it contains unrepresentable characters. I don't have any good ideas for how to avoid that, right now. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] commit and sink in same transaction
2009/3/23 serg sergeybely...@yandex.ru: Hi. Can I synchronize (serve, pull, ...) the repository and do commit changes in same transaction without data loss through software API? Thanks. No, but the question as phrased makes no sense in monotone's framework, so I suspect you're thinking about the task the wrong way. If you explain your larger goals we may be able to tell you how to do what you really want. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
