Re: [Monotone-devel] mtn 0.43dev: "failed to convert string from UTF-8 to ANSI_X3.4-1968"
2009/3/7 Jack Lloyd > > If I run mtn log on my nvm db with mtn 0.43-dev, rev > d24b59732a5b3293592457cba013c8f8b716a875, monotone fails with the > following error. I do not have any LANG/LC_* environmental variables > set. Also perhaps relevant: using glibc 2.9-20081201 snapshot. The > _MTN/debug file is attached. I ran the tests after building the > binary, looked OK. > > mtn: fatal: error: failed to convert string from UTF-8 to ANSI_X3.4-1968: > '- > mtn: error: Revision: 424e1cf5155ae4473250978ae6b7e44e12775741 > mtn: error: Ancestor: fc85e75bcd1af555052e4c1d48a11ff37434fec1 > mtn: error: Author: l...@lapo.it > mtn: error: Date: 2009-01-14T15:28:20 > mtn: error: Branch: net.venge.monotone > mtn: error: > mtn: error: Added files: > mtn: error: contrib/display_branches.lua > mtn: error: > mtn: error: ChangeLog: > mtn: error: > mtn: error: Added to <80><98>contrib/<80><99> an useful script by > Richard Levitte. > mtn: error: Message-ID: <20060423.185254.52768015.rich...@levitte.org> > mtn: error: > mtn: error: ' > 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-devel@nongnu.org > . > mtn: wrote debugging log to > /home/lloyd/projects/net.venge.monotone/_MTN/debug > mtn: if reporting a bug, please include this file > 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. If anyone has time to look into the details it would probably be good to get it fixed before releasing 0.43. Initially, I tried bisecting revs manually but that got old pretty quickly. So, instead of grinding ahead I decided to write a proper bisect command to do the work for me. What I have so far worked well enough to help find the rev above and I've committed it to net.venge.monotone.bisect for now. It needs more work, docs, tests, etc. before it'll be ready for mainline. At the moment it does not update the workspace its running from, it just spits out a suggested revision to try next as you mark things as good or bad. I ran it in one workspace (as I was developing it) and updated and tested revs in another workspace to find the problem above. I'm going to be busy the next few days and them I'm going to be away for a couple of weeks so I won't have a chance to look into this problem myself or finish bisect in time for the next release. I'll be in the San Diego area though so if anyone from around there wants to get together for a beer or lunch I'm game for that. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
In message <86r61012tz@stephe-leake.org> on Sat, 14 Mar 2009 12:33:44 -0400, Stephen Leake said: stephen_leake> Thomas Keller writes: stephen_leake> stephen_leake> > 2) The buildbots i386-win32-mingw, stephen_leake> stephen_leake> This was mine. The machine physically died, and I don't have the stephen_leake> resources (or time) to replace it yet. I've temporarly removed it. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Suspending abandoned branches
Hi all! During the preps for the 0.43 release I tried to check what branches were actually actively propagated to or even developed on [0]. Many branches however seem to got abandoned (I tip my finger at my own nose here, having a couple of these laying around) and I'd vote to suspend these to get a more "up-to-date" list of branches which are actually still useful. Dan came up with a good idea here, he said we should add some notification / comment to the suspended revision which tells an interesting fellow _why_ it was suspended. I did this with two of branches Derek told me he abandoned and with a few others. The best thing here might be to include the URL of a mailing list message or something similar which explains why the branch is abandoned, so the discussion is kept on the list and the suspended revs just point to this discussion. So, if you people have some spare time (f.e. sitting in a plane with nothing to do ;) it would be cool if you could check your own branches and maybe also those of other people which haven't been seen since more than a year or so in the project. Thanks in advance, Thomas. [0] ...using this utility script: http://pastebin.ca/1361168 -- 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 signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Splitting up the INSTALL file Was: Re: [Monotone-devel] status of nvm.stripped
Stephen Leake schrieb: > Markus Wanner writes: >> I've updated the INSTALL document and documented as good as I can. I'm >> missing instructions for Windows/Cygwin. Lapo? > > I can provide MinGW. It may be rather long, depending on detail. I > guess we can assume a competent developer, not a complete newbie. > > I was thinking we should split INSTALL into separate files > (INSTALL.windows_mingw, etc), but let's see how big it gets first. INSTALL really became somewhat of a monster in 0.43. I've actually never seen a project which put all these distro-specific package names and setup procedures in an INSTALL file - but rather on some website / wiki. On the other hand having very detailed installation instructions especially for 0.43, the first unbundled release, will probably overweight someone's disability to search for the contents he needs - maybe we decide in a later version to shrink down the contents of INSTALL, or split the files up even. I wouldn't do that for the upcoming release though. 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 signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi! Markus Wanner schrieb: > I've just run through the testsuite with mtn compiled against an up to > date sqlite 3.6.10 (released Jan 15th). All tests succeed. > >> monotone 0.43dev (base revision: 2d8426478d56750e764a5ce552ba3ce7c22acb0a) >> Running on : Linux 2.6.26-1-686 #1 SMP Thu Jan 1 02:26:25 UTC 2009 >> i686 >> C++ compiler: GNU C++ version 4.3.2 >> C++ standard library: GNU libstdc++ version 20080905 >> Boost version : 1_34_1 >> SQLite version : 3.6.10 (compiled against 3.6.10) >> Lua version : Lua 5.1 >> PCRE version: 7.6 2008-01-28 (compiled against 7.6) >> Botan version : 1.8.1 (compiled against 1.8.1) > > However, I'm still having troubles with Solaris. Maybe mostly due to my > lack of understanding of that system, though. Whats the status of this? The INSTALL file still contains a FIXME: yet to be confirmed message in the Solaris / opencsw.org section. Shall we then remove this section, mark it "not tested" or somthing? I just don't like to see a FIXME note in this file for the next release ;) 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 signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Zack Weinberg schrieb: > On Wed, Mar 11, 2009 at 6:29 PM, Thomas Keller wrote: >> As I've already announced on IRC I want to do a release in the next >> couple of days, a possible date could be Sunday, 2009-03-15, but >> depending on the feedback what people like to get done before 0.43 hits >> the world, I'll not insist on this date. > > The Debian packaging scripts need a major overhaul for the .stripped > work. I will not have time for this until a week from Friday (that's > the 20th). This does not *have* to hold the release but I would > prefer that it did, because it is likely that I will find changes > needing to be made in the code proper, or at least the documentation. Ok, I'm fine with that. Then I schedule the release for 22nd of March. >> 0) I've came across a couple of older systems where our dependency for >> prce (7.6, released in January 2008) could not be met. I know 7.6 >> includes an important buffer overflow fix and I know this probably was >> backported by some lts distros, but still, from a *functional* point of >> view, what version of pcre is required? Seems as if the first pcre >> version we've included was 7.4 in monotone-0.37 (at least this was the >> most recent one before 0.37 was released). > > I believe 7.4 is the minimum for functionality, yes. I've lowered our requirement to 7.4. Thanks, 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 signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] public/private key hashes
There are a few places that output private-key hashes: automate genkey automate keys ls keys The private key hash doesn't really identify the private half of a particular keypair, because it's of the encrypted (depends on passphrase and some randomization) form. We also don't store bare private keys any more, when written out they always include the public half as well. Does anyone object to removing privkey hashes completely, and using the hash of the public half instead? Mostly this would mean that "automate keys" and "automate genkey" stanzas would have one "hash [...]" line instead of "public_hash [...]" and "private_hash [...]" lines. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bug #25859] disapprove does not resurrect files properly
Ludovic Brenta writes: > I just filed a new bug: http://savannah.nongnu.org/bugs/?25859 > This is a result of the current die-die-die merge algorithm. It might be possible to improve things so this bug goes away with the current code. > I still use 0.40 and I would like to know: > > - whether Stephe Leake's file suturing work solves this bug It would. > - whether it is merged I assume "it" here is the file suturing; no, it is not in main. > - which release of monotone contains or will contain it Probably none. I started working on file suturing because I wanted a simple way to handle duplicate name conflicts. After several months work, I realized it was _not_ simple! So I implemented the current 'conflicts' commands instead. I'm not clear if using the conflicts commands would solve your bug above; I suspect not. I have no plans to resume working on file suturing. File suturing is an interesting idea, but it has many deep consequences, and I don't think it's worth the effort. At the moment, the branch nvm.automate_show_conflict contains the file suturing code. It is significantly out of date with main, and would be painful to merge. There are tests, so it might be possible, if someone wants to pursue it. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Time for a release
Thomas Keller writes: > 2) The buildbots i386-win32-mingw, This was mine. The machine physically died, and I don't have the resources (or time) to replace it yet. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #25859] disapprove does not resurrect files properly
I just filed a new bug: http://savannah.nongnu.org/bugs/?25859 I still use 0.40 and I would like to know: - whether Stephe Leake's file suturing work solves this bug - whether it is merged - which release of monotone contains or will contain it Thanks -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
