Re: nvm.stripped

Hello Jack,

Jack Lloyd wrote:
> Currently (rev 44c07854971c158f07da7f53d811d2e298c3f354) I am seeing
> this:
> 
> $ ./configure
> [the usual configure output]
> checking for Botan version 1.7.8 or newer... no
> configure: error: Your botan library version not match (1.7.15).

Hm.. thanks for this notification. I've never tried non-standard
locations so far.

> Note that at compilation no cflags (such as -I) are set. Against my
> local workspace, botan-config does this:
> 
> $ botan-config --cflags
> -I/home/lloyd/projects/botan/mainline/build/include
> $ botan-config --libs
> -L/home/lloyd/projects/botan/mainline/ -lm -lpthread -lrt -lbotan
> $ botan-config --version
> 1.7.15

Hm.. you manually added 'botan-config' from /home/lloyd/.. to your PATH,
right?

> And I checked with an echo that botan_CFLAGS is being set properly.
> 
> (My Botan workspace was configured and I confirmed that

[ANN] guitone-0.9 released

Hi Folks!

I've released guitone-0.9 today. This is mainly a bugfix release which
contains only two new features:

  1. People can select the correct encoding for a file which is
     displayed in guitone's diff dialog. Guitone is capable of setting
     and restoring a custom file attribute for diffed workspace files
     and automatically render the file with the correct encoding next
     time it is diffed.

  2. There is now a "Node information" dubbed info window which displays
     a couple of interesting information for selected workspace paths.

The usual download location for the new release is

  http://guitone.thomaskeller.biz/g/download

Check the NEWS file there for a complete set of changes.

And before you ask - the Win32 setup file should be ready on Monday - I
don't have access to a windows machine before... ;)

Have a good night,
Thomas.

--

-- 
GPG-Key 0x160D1092 | tommyd3mdi <at> jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information

Re: library build

"Zbigniew Zagórski" <z.zagorski <at> gmail.com> writes:

> 2008/9/28 Stephen Leake <stephen_leake <at> stephe-leake.org>:
>> "Zbigniew Zagórski" <z.zagorski <at> gmail.com> writes:
>>
>>> 2008/9/28 Stephen Leake <stephen_leake <at> stephe-leake.org>:
>> ...
>>>> I agree this is a reasonable goal, at least on platforms that have
>>>> decent package managers.
>>>>
>>>> MinGW doesn't have a decent package manager, and I don't know where to
>>>> get pcre for MinGW; I looked for that a while ago. I haven't looked
>>>> for the others.
>>>
>>> AFAIR, on properly configured mingw+msys
>>
>> "properly" is of course the issue.
>
> Well, the only changes i have is custom  m4, autoconf, automake a
> result of private battle in order to get recent versions of these.
> Rest is standard ... i think.

This monotone wiki page:

http://www.venge.net/mtn-wiki/BuildingOnWindows 

has instructions for installing the mingw tools needed to build mtn.
Can you test with a setup following those instructions, and add the
pcre etc instructions?

Bug: invariant 'fetching nonexistent entry from nodes' violated

_MTN/debug attached. If help is needed replicating just let me
know. Is this known? I feel like I might have reported this before,
but didn't see anything in my mail archives.

I'm not really sure what I did... normally when mtn has an invariant
failure I can at least see why. Here I had some various modifications
to src/ciphers/≤various things> and while in src I typed mtn revert .
which got me this:

$ mtn revert .
mtn: fatal: std::logic_error: roster.cc:681: invariant 'fetching nonexistent entry from nodes' violated
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 <at> nongnu.org.
mtn: wrote debugging log to /home/lloyd/projects/botan/modularized/_MTN/debug
mtn: if reporting a bug, please include this file

$ mtn version --full
monotone 0.41 (base revision: 9b264ec9247ce99cd1fdc5293e869c1a60b01c4c)
Running on          : Linux 2.6.24.7 #1 SMP Tue Jun 24 10:34:47 EDT 2008 x86_64
C++ compiler        : GNU C++ version 4.3.1
C++ standard library: GNU libstdc++ version 20080606
Boost version       : 1_35
Changes since base revision:
unknown

Current work set: 4 items
----- begin 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at sanity.cc:75)

library build

Hi,

I've taken out the library-build branch again today and played around a 
bit. It took me several approaches and fiddling with auto* just to get 
it to compile again.

I still feel uncomfortable maintaining a special wrapper and multiple 
3rd party libraries inside monotone with the additional option to use a 
system provided library.

It seems obvious to me that we don't have the manpower to maintain such 
a multi-purpose build harness, so I'm proposing to go the easier way and 
make monotone dependent on 3rd party libraries, without providing them 
(and a kitchen-sink build harness).

Instead we should IMO simply rip out the still-bundled stuff (pcre, 
sqlite, idna, botan) and adjust the Makefile cruft to build against 
system provided libraries - as the vast majority of other software does. 
Or how often did you encounter a 'configure' which doesn't configure 
anything but leaves that task for 'make', making you fiddle with aclocal 
in subdirectories if things don't work out as planned?

Comments?

Regards

Markus Wanner

upgrade of included botan for mtn

Hi,

I've finally taken the time to go through upgrading the included botan 
library to 1.7.9 first, then 1.7.12. Some renaming and name conflicts 
during merging were a PITA to solve and made me do it in two steps.

The Global_RNG of botan has gone, so I've added a pointer to an RNG to 
the app_state, the key_store and the database. Most places using an RNG 
have access to a key_store object, so we could maybe even get rid of the 
pointer in the database object.

Only mkstemp.cc was puzzling me: I've now changed it to assign its own 
RNG. Dunno if that can be optimized to use monotone's, but OTOH it maybe 
doesn't matter.

The Memory_Exhausted exception has now gone, so we don't need a special 
check for that and can rely on std::bad_alloc now.

Performance of the SHA-1 remains pretty much the same since we cannot 
use the optimized SSE2 variant (+60% sha1 throughput [1]). That alone is 
a good reason to push the library-build branch.

Regards

Markus Wanner

[1]: benchmark results for sha1:

(using "mtn benchmark_sha1"):
default botan sha1: ~ 144 MiB/s

bugreport monotone

Just doing the daily update of the openembedded.dev branch.  The mtn pull 
worked yesterday and it worked when I retried the same command sequence.

Console:
oem <at> develnix:~/build/nslu2.dev$ pushd oe/; mtn pull && mtn up; popd
~/build/nslu2.dev/oe ~/build/nslu2.dev
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to monotone.openembedded.org
mtn: finding items to synchronize:
mtn: certificates | keys | revisions
mtn:        79216 |   76 |     26096
mtn: bytes in | bytes out | certs in | revs in
mtn:  151.6 k |    86.7 k |    96/96 |   24/24
mtn: fatal: std::runtime_error: network error: recv failure: Connection 
timed out
mtn: this is almost certainly a bug in monotone.
mtn: please send this error message, the output of 'mtn --full-version',
mtn: and a description of what you were doing to monotone-devel <at> nongnu.org.
mtn: wrote debugging log to /home/oem/build/org.openembedded.dev/_MTN/debug
mtn: if reporting a bug, please include this file
~/build/nslu2.dev
oem <at> develnix:~/build/nslu2.dev$
===================================

oem <at> develnix:~/build/nslu2.dev$ mtn --full-version
monotone 0.31 (base revision: 1bd1fe1e811dce82bee09b9f0effca3225bd1cee)
Running on          : Linux 2.6.8-1-386 #1 Thu Nov 11 12:18:43 EST 2004 i686
C++ compiler        : GNU C++ version 3.3.5 (Debian 1:3.3.5-13)
C++ standard library: GNU libstdc++ version 20050304
Boost version       : 1_33_1

[PATCH] fix use of hostname from parsed uri

This looks like an obvious fix.  Without this, the local variable 'host' is
set and then never used.  For me, this seems to make:

	mtn sync mtn://server/

work happily.  By making that:

	mtn sync mtn://server/foobar

I think this is already all that was needed for usher to get really useful
for sensible multi-db hosting.  So I hope this fix goes in ASAP!

(Beyond this, it seems like there ought to be some actual checking on the
uri scheme, instead of treating any scheme name not handle by the lua hook
as meaning netsync.)

Thanks,
Roland

#
# old_revision [6341444c06293469f66f1c431063282004c5be9d]
#
# patch "netsync.cc"
#  from [faa9a58eb3dd3f07ec771969251ba8c5c8f2d91d]
#    to [500fec0e1c25b6ed2e1cf03ee6bd25039e1a1e01]
#
============================================================
--- netsync.cc	faa9a58eb3dd3f07ec771969251ba8c5c8f2d91d
+++ netsync.cc	500fec0e1c25b6ed2e1cf03ee6bd25039e1a1e01
@@ -2461,8 +2461,7 @@ build_stream_to_server(options & opts, l

[bug] mtn genkey / list keys

_______________________________________________
Monotone-devel mailing list
Monotone-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Database locked...

Monotone previously did not do this... but I have a server that serves
a .DB file.  On the same server I'm using viewmtn to check statuses of
branches,etc.  Our server recently crashed, so I ended up installing
the latest monotone.

At some point during 0.3x monotone's behavior changed from being able
to use the same database after a sync completed to  being locked after
a sync.

Now, as soon as the server starts, the database is locked, and no
other mtn may access it.

I checked real quick for running mtn through xinetd... but I guess
that's not probable?

How can I use viewmtn on the host with my central repository?

mtn: misuse: rename target 'Foo/bla' already exists

Can anyone tell me what I should do here:

mtn: updating along branch 'mybranch'
mtn: selected update target 4e34dedb6e8a9cb16f3a303b86c61fd384328e42
mtn: [left]  5a641ac778ae8acab3f1415febc4582bc9204810
mtn: [right] 4e34dedb6e8a9cb16f3a303b86c61fd384328e42
mtn: adding Foo/bla
mtn: misuse: rename target 'Foo/bla' already exists

I was trying to check out the two revisions and compare the directories  
and files but I can't check out the left side:

mtn: misuse: no match for selection '5a641ac778ae8aca'

Before I mess up everything and lose revisions maybe someone can tell me  
how I can proceed safely? I'm using monotone 0.40 (both on Windows XP and  
Cygwin).

Boris