Re: [Monotone-devel] Hmmm, time is lacking
In message <[EMAIL PROTECTED]> on Thu, 2 Aug 2007 23:50:41 -0700, "Zack Weinberg" <[EMAIL PROTECTED]> said: zackw> On 8/2/07, Richard Levitte <[EMAIL PROTECTED]> wrote: zackw> > zackw> > Things are pretty calm, so I can do a bit now. It's a good thing zackw> > there was this pause, it gave Zack the possibility to correct the zackw> > Debian stuff. zackw> zackw> Are you going to send packages to Ludovic for sponsoring or zackw> should I? I just got myself an account, so I'll give it a shot. I gotta start somewhere ;-). (btw, I'm still supposed to upload it as per the intro you sent me a while ago, right?) Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [ANNOUNCE] monotone 0.36 released
Finally, monotone 0.36 has arrived. There are quite a number of changes and corrections in this release, well worth investigating. Take a closer look at http://monotone.ca/ Fri Aug 3 06:08:36 UTC 2007 0.36 release. Changes - The help command is now able to show documentation on subcommands (such as 'attr set'). - The help command now shows a brief abstract of each command, instead of only listing their names. - The command `list changed` now outputs the new path of any renamed item making it easier to copy and paste these paths for external program usage. - `automate attributes` has been renamed to `automate get_attributes`, also a bug has been fixed there so resurrected attributes are now properly outputted as "new" and not "changed". New features - Two new commands to set and drop attributes over automate: `automate set_attribute` and `automate drop_attribute` - There is a new function available to the lua hooks, 'server_request_sync(what, address, include, exclude)', which will initate a netsync connection to the server at "address", with the given include and exclude patterns, and will sync, push, or pull, as given in the "what" argument. If called from a monotone instance which is not acting as a server, this function will do nothing. - There is a new hook available, 'get_netsync_key(server, include, exclude)', which is called to determine which key to use for netsync operations. Note that the server calls this once at startup with the address it is listening on, "*", and "" as arguments, rather than for each connection. Other - Giving the --confdir argument will automatically set the key store directory to keys/ under that directory, unless --keydir is also given. This is a bugfix. - Fixed a regression in 0.35 that resulted in some databases becoming significantly larger when storing new revisions. Existing databases with this problem can be fixed by pulling into a fresh database using 0.36. - contrib/lua-mode.el, a Lua mode for GNU emacs. - contrib/monotone-buildbot-notification.lua, a netsync hook to have a server notify a buildbot when new changes have arrived. Useful for anyone who uses a buildbot with monotone as source. - contrib/monotone-cluster-push.lua, a netsync hook script to have arriving changes be forwarded to other servers automatically. It uses the new internal lua function 'server_request_sync'. - contrib/mtn_makepermissions, a simple script to create read-permissions and write-permissions from files in the directories read-permissions.d and write-permissions.d, Debian style. - contrib/Monotone.pm, a first attempt to write a Perl module to interface with 'monotone automate stdio'. - contrib/monotone-import.pl has been removed since monotone now has an internal import command. Internal - Commands are now defined as a tree of commands instead of a plain list, which allows the help system to look up information of a command at an level in the tree. - The command class, the automate class and all the associated macros have been cleaned up. - All C++ files now depend on base.hh, which includes the few things that are used virtually everywhere. 'make distcheck' will check for the presence of base.hh in all source files and will protest if it's not there. This is explained further in HACKING. - Update the internal SQLite to version 3.4.0. - Updated Visual C building system, which now also builds the test programs. The script visualc/runtests.bat can be used to run the tests. - Monotone can now be built successfully with Boost 1.34. Older versions of monotone would sometimes seem to work depending on the compiler used, but would have bugs in path normalization. - Monotone now requires Boost 1.33 or later. - The Boost filesystem library is no longer required. - The Boost unit test system is no longer required. Cheers, Richard -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn fatal error on mtn up
On Thu, 2007-08-02 at 18:27 -0600, Eoin Coffey wrote: > Error Message: > > mtn: fatal: std::logic_error: paths.cc:307: invariant > 'I(is_valid_internal(data()))' violated You have a file named libpurple/plugins/mono/\ , which monotone doesn't like (file names can't contain '\'). ...we *really* need to have better error handling here. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [Monotone-debian] net.venge.monotone.debian-diff proposed policy
"Zack Weinberg" <[EMAIL PROTECTED]> writes: > * To make a Debian release, starting from a release tarball: Rename > the release tarball to Debian's convention > (monotone_VERSION.orig.tar.gz). Unpack it. Take the diff between the > corresponding release tag and the head of n.v.m.debian-diff, and apply > it to the unpacked directory. Proceed with dpkg-buildpackage. > > (You do not simply check out the head of n.v.m.debian-diff and run > autoreconf -i, because that risks skew between the generated files in > the tarball and the generated files on the branch, which will lead to > problems.) > > Alles klar? > zw I kind of disagree with this proposed policy. I find it too complicated and leaves too much opportunity for mistakes. In particular, the part about applying a diff outside of a checkout worries me quite a lot, as it means the Monotone database does not directly contain the Debian scripts that are released. I believe the whole point of maitaining packaging scripts in a version control system is to be able to make packages from within a working copy :) I would propose an alternative: * Create a new independent branch named org.debian.monotone, containing *only* the packaging scripts (i.e. the debian and, if necessary, patches directories). (The new branch name is for consistency with all the other packages I maintain with monotone, but not mandatory; I would replicate this branch to my monotone server on www.ada-france.org). This makes it possible to build a Debian package like so: - unpack the release tarball - rename the top-level directory to monotone_VERSION.orig - cp --archive monotone_VERSION.orig monotone_VERSION - cd monotone_VERSION - checkout --branch org.debian.monotone . - dpkg-buildpackage -i'_MTN|\.mt'(note: this is in my .bashrc aliases :)) I think this is much more reproducible than your proposed policy, and more obviously correct (as opposed to just "correct"). * Remove the debian/ subdirectory from n.v.m, and thereby from the release tarballs. This removes the need for merges between branches, and most of the associated 'don't' rules and opportunities for error in your proposed policy, and consequently the need to enforce these rules. It also makes the release tarballs more distribution-agnostic. Thoughts? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] mtn fatal error on mtn up
Hmm thats odd. I don't even know how that file got created. In any event I rm -rfed my working copy and rechecked it out, so its all good. Thanks for the reply, and I'll make sure to keep an eye out for bizarre file names next time :-) -Eoin On 8/3/07, Timothy Brownawell <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-08-02 at 18:27 -0600, Eoin Coffey wrote: > > Error Message: > > > > mtn: fatal: std::logic_error: paths.cc:307: invariant > > 'I(is_valid_internal(data()))' violated > > You have a file named >libpurple/plugins/mono/\ > , which monotone doesn't like (file names can't contain '\'). > > ...we *really* need to have better error handling here. > > > ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Speeding up automate stdio
Hi,
I'm still working on an hg2mtn facility and tried to import the files of
the first revision of that hg repository (34000 files) with automate
stdio using the put_file command.
On my regular filesystem (ZFS), it took approx. 20 minutes.
For fun, I tried again with the monotone repository on tmpfs (swap based
ramdisk), and came out with only a bit more than 5 minutes.
ZFS is usually a pretty fast filesystem with aggressive caching before
it writes to disk, but it wrote small chunks to disk all the time - so I
blamed transactions, and added a big transaction in automate stdio
around "everything".
With that change, it took only 4 minutes on tmpfs, and feeling more
courageous, I removed the transaction guards in put_file (there's a big
one around it, after all), which gave another 30 seconds.
Then I tried on ZFS again - and it finished in 4:50, so it's 4 times
faster! (for this absolutely non-scientific and specialized test)
What to do with it result: I'm thinking about adding an option to
automate stdio that tells it to use one global lock
("--all-or-nothing"?) and disables the transaction guards for every
single commands it calls, but I wanted to discuss it first, as I have no
idea what kind of impact such a change might have.
I'm thinking of implementing it as follows:
- add a transaction_guard around exec_from_automate(..) invocation in
"automate" (non-stdio)
- add an optional transaction_guard around exec_from_automate(..) in
"automate stdio"
- add global transaction_guard in "automate stdio" (or not: that should
be covered by the first change already)
- remove all old transaction_guards in automate commands
I see one problem with this change: Reusing the automate commands in
some other code path means that you get to do your transactions yourself
(and might forget them)
Comments highly appreciated :-)
Regards,
Patrick Georgi
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hmmm, time is lacking
In message <[EMAIL PROTECTED]> on Thu, 2 Aug 2007 23:50:41 -0700, "Zack Weinberg" <[EMAIL PROTECTED]> said: zackw> On 8/2/07, Richard Levitte <[EMAIL PROTECTED]> wrote: zackw> > zackw> > Things are pretty calm, so I can do a bit now. It's a good zackw> > thing there was this pause, it gave Zack the possibility to zackw> > correct the Debian stuff. zackw> zackw> Are you going to send packages to Ludovic for sponsoring or zackw> should I? I'm changing my mind. I currently don't have a Debian [unstable] system that I can build the package on, so unless I can upload something that only contains monotone_0.36-1_i386.changes and the tarball, I think I have to delegate this to you. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Hmmm, time is lacking
Richard Levitte wrote: > I'm changing my mind. I currently don't have a Debian [unstable] > system that I can build the package on, so unless I can upload > something that only contains monotone_0.36-1_i386.changes and the > tarball, I think I have to delegate this to you. But is a Debian package to be ready BEFORE the actual software is release.. or... I guess I simply didn't receive/see the release message, as on the website it certainly is visible, now that I notice ;-) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Speeding up automate stdio
On Fri, Aug 03, 2007 at 01:59:10PM +0200, Patrick Georgi wrote: > With that change, it took only 4 minutes on tmpfs, and feeling more > courageous, I removed the transaction guards in put_file (there's a big > one around it, after all), which gave another 30 seconds. This last part sounds like a bug -- transaction guards are supposed to nest, so that if we are already in a transaction all that they should do is increment a variable somewhere. Fixing this would help with some of your later concerns about removing transaction guards as well, since there should never be any reason to remove a transaction guard... You might also want to look into the "checkpoint" (IIRC it's called that) functionality, if you're thinking about automate stdio and transactions. -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [Monotone-debian] net.venge.monotone.debian-diff proposed policy
On 8/3/07, Ludovic Brenta <[EMAIL PROTECTED]> wrote: > "Zack Weinberg" <[EMAIL PROTECTED]> writes: > > * To make a Debian release, starting from a release tarball: Rename > > the release tarball to Debian's convention > > (monotone_VERSION.orig.tar.gz). Unpack it. Take the diff between the > > corresponding release tag and the head of n.v.m.debian-diff, and apply > > it to the unpacked directory. Proceed with dpkg-buildpackage. > > > > (You do not simply check out the head of n.v.m.debian-diff and run > > autoreconf -i, because that risks skew between the generated files in > > the tarball and the generated files on the branch, which will lead to > > problems.) > > I kind of disagree with this proposed policy. I find it too > complicated and leaves too much opportunity for mistakes. In > particular, the part about applying a diff outside of a checkout > worries me quite a lot, as it means the Monotone database does not > directly contain the Debian scripts that are released. I believe the > whole point of maitaining packaging scripts in a version control > system is to be able to make packages from within a working copy :) I think I didn't explain things clearly enough. The Monotone database does directly contain the released scripts, and you could in principle make packages from a checkout of nvm.debian-diff by running autoreconf -i and then dpkg-buildpackage, as long as the current release tarball was sitting in the parent directory. The reason I don't recommend this procedure is simply that it risks autoconf / automake version skew (at best producing unnecessary junk in the .diff.gz, at worst causing build failures). Taking the diff between mainline and .debian-diff and applying it to a non-working-copy unpack of the release tarball avoids this problem. > * Create a new independent branch named org.debian.monotone, > containing *only* the packaging scripts (i.e. the debian and, if > necessary, patches directories). (The new branch name is for > consistency with all the other packages I maintain with monotone, > but not mandatory; I would replicate this branch to my monotone > server on www.ada-france.org). My problem with this suggestion is that we currently have to make small changes outside the debian directory (see present content of the branch). I would really rather not drag in a build-time patching system for them, especially as IMO storing Debian-specific changes as proper changes to the files in a branch will be more convenient. For instance, if we backport fixes from mainline (which we did do for the 0.35 packages) they'll automatically get superseded by the next upstream release when we merge from trunk to branch. I see the question of whether there should be a debian/ directory in trunk as entirely independent of how the branch holding Debian-specific changes is managed. I like having it on trunk, myself - for instance, it means that schema upgrades can be checked in together with the necessary update to monotone-server.postinst and dummy entry in the Debian changelog. (Although, having just typed that, perhaps we should look for a way to eliminate the need...) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [Monotone-debian] net.venge.monotone.debian-diff proposed policy
Zack Weinberg writes: > I think I didn't explain things clearly enough. The Monotone database > does directly contain the released scripts, and you could in principle > make packages from a checkout of nvm.debian-diff by running autoreconf > -i and then dpkg-buildpackage, as long as the current release tarball > was sitting in the parent directory. The reason I don't recommend > this procedure is simply that it risks autoconf / automake version > skew (at best producing unnecessary junk in the .diff.gz, at worst > causing build failures). Taking the diff between mainline and > .debian-diff and applying it to a non-working-copy unpack of the > release tarball avoids this problem. I understand why we don't want to run autoreconf as part of Debian packaging, and I agree with this. I think the origin of the problem is that the files generated by autoreconf are in the release tarball, but not in the working copy after a fresh checkout. How about keeping these files in the .debian-diff branch? That makes it possible to patch them if necessary, too. And without rerunning autoreconf from debian/rules. >> * Create a new independent branch named org.debian.monotone, >> containing *only* the packaging scripts (i.e. the debian and, if >> necessary, patches directories). [...] > > My problem with this suggestion is that we currently have to make > small changes outside the debian directory (see present content of > the branch). I would really rather not drag in a build-time > patching system for them, especially as IMO storing Debian-specific > changes as proper changes to the files in a branch will be more > convenient. For instance, if we backport fixes from mainline (which > we did do for the 0.35 packages) they'll automatically get > superseded by the next upstream release when we merge from trunk to > branch. OK, that makes sense. > I see the question of whether there should be a debian/ directory in > trunk as entirely independent of how the branch holding > Debian-specific changes is managed. I like having it on trunk, > myself - for instance, it means that schema upgrades can be checked > in together with the necessary update to monotone-server.postinst > and dummy entry in the Debian changelog. (Although, having just > typed that, perhaps we should look for a way to eliminate the > need...) OK, that's convenient because you happen to be a Monotone developer and the Debian package maintainer at the same time :) -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: beginner's question: write permission prob
Timothy Brownawell <[EMAIL PROTECTED]> wrote: > Joe Brenner wrote: > > I'm trying to get a simple monotone setup working over my internal > > network, and I'm seeing a permissions problem: I can get read access, > > but not write access. I've run out of ideas for things to check, and > > I'm looking for suggestions. > > > On the server: > > > function get_netsync_read_permitted (collection, identity) > > if (identity == "[EMAIL PROTECTED]") then return true end > > return false > > end > > > > function get_netsync_write_permitted (collection, identity) > > if (identity == "[EMAIL PROTECTED]") then return true end > > return false > > end > > Since 0.20, write permission is all or nothing, and this hook only takes > one argument, "identity". Since you have "identity" being the second > argument, it will always be nil. (Also since 0.20, the "collection" > argument to get_netsync_read_permitted has become "branch", and it is > called for each branch that would be sent to the client.) > > The read-permissions and write-permissions files are checked by the > default versions of these hooks. I'd recommend that you delete your > versions of these hooks and just use those files, unless you need > something fancy. Thanks, that's exactly what I needed to do. This must be some left-over cruft from my experiments with previous versions of Monotone (perhaps using out-of-date documentation). (I was wondering about this stuff, actually... it did seem redundant with the *-permissions files.) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] 0.36 error on cygwin
Whops. (Baka) Lapo didn't notice a bug in latest changes in file I/O code... if launched without workspace tries to open //_MTN and fails to find the network share with that UNC name... (of course on my PCs I have lots of _MTN dirs to be found around... this time I was checking the cygwinpackage from my girlfriend's laptop...) Well, I guess I'll delay the cygwin 0.36 package a bit further, it's almost midnight and tomorrow I have the flight so soon in the morning... I'll try to take a look at the problem with my mother's laptop, if there's some day that the weather is not good enough to sunbathe ;) else all will be done on my return, 26/8 =) Lapo $ mtn -d .monotone/it.lapo.mtn --debug pull lapo.it it.lapo.homedir mtn: started up on CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 mtn: command line: 'mtn', '-d', '.monotone/it.lapo.mtn', '--debug', 'pull', 'lapo.it', 'it.lapo.homedir' mtn: set locale: LC_ALL=C mtn: initial abs path is: /home/lapo mtn: ssh_agent: connect: ssh-agent socket not found mtn: started up on CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 mtn: command line: 'mtn', '-d', '.monotone/it.lapo.mtn', '--debug', 'pull', 'lapo.it', 'it.lapo.homedir' mtn: set locale: LC_ALL=C mtn: initial abs path is: /home/lapo mtn: ssh_agent: connect: ssh-agent socket not found mtn: searching for '_MTN' directory with root '/' mtn: '_MTN' not found in '/home/lapo' with '' removed mtn: '_MTN' not found in '/home' with 'lapo' removed mtn: /home/lapo/packaging/tmp/monotone-0.36/unix/fs.cc:124: detected error 'E(false)' violated mtn: saving current work set: 4 items mtn: finished saving work set mtn: contents of work set: mtn: Current work set: 4 items mtn: - begin 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at /home/lapo/packaging/tmp/monotone-0.36/mtn-sanity.cc:21) mtn: monotone 0.36 (base revision: unknown) mtn: Running on : CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 mtn: C++ compiler: GNU C++ version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) mtn: C++ standard library: GNU libstdc++ version 20050519 mtn: Boost version : 1_33_1 mtn: Changes since base revision: mtn: unknown mtn: - end 'full_version_string' (in virtual void mtn_sanity::initialize(int, char**, const char*), at /home/lapo/packaging/tmp/monotone-0.36/mtn-sanity.cc:21) mtn: - begin 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at /home/lapo/packaging/tmp/monotone-0.36/sanity.cc:57) mtn: CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 mtn: - end 'system_flavour' (in virtual void sanity::initialize(int, char**, const char*), at /home/lapo/packaging/tmp/monotone-0.36/sanity.cc:57) mtn: - begin 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at /home/lapo/packaging/tmp/monotone-0.36/sanity.cc:71) mtn: 'mtn', '-d', '.monotone/it.lapo.mtn', '--debug', 'pull', 'lapo.it', 'it.lapo.homedir' mtn: - end 'cmdline_string' (in virtual void sanity::initialize(int, char**, const char*), at /home/lapo/packaging/tmp/monotone-0.36/sanity.cc:71) mtn: - begin 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at /home/lapo/packaging/tmp/monotone-0.36/sanity.cc:76) mtn: C mtn: - end 'string(lc_all)' (in virtual void sanity::initialize(int, char**, const char*), at /home/lapo/packaging/tmp/monotone-0.36/sanity.cc:76) mtn: statement cache statistics mtn: prepared 0 statements mtn: error: error accessing file //_MTN: No such host or network path ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Speeding up automate stdio
Nathaniel Smith wrote: This last part sounds like a bug -- transaction guards are supposed to nest, so that if we are already in a transaction all that they should do is increment a variable somewhere. Hmm.. Did I forget the bit about the unscientific benchmark? Maybe that fooled me here (but 4:00 -> 3:30 seems to be a large error margin) I also read the code wrongly and thought that the guards commit every x-th invocation, but that's actually a checkpointing mode. Fixing this would help with some of your later concerns about removing transaction guards as well, since there should never be any reason to remove a transaction guard... In this case, this change would be trivial (add an option, look for it and create a global transaction guard) You might also want to look into the "checkpoint" (IIRC it's called that) functionality, if you're thinking about automate stdio and transactions. It might be good to provide an "automate commit" then (so that the user of automate stdio can decide when to commit, eg. when a full revision was pushed into mtn). Thank you for the feedback! Regards, Patrick Georgi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] Re: on the semantics of 'mtn mv'
I've just gotten around to pushing this patch. mtn mv should behave more consitently now, in my view. -Ben On 7/30/07, Ben Walton <[EMAIL PROTECTED]> wrote: > Ok, then I could likely commit this patch directly. > > Thanks > -Ben > > On 7/30/07, Richard Levitte <[EMAIL PROTECTED]> wrote: > > In message <[EMAIL PROTECTED]> on Mon, 30 Jul 2007 10:56:33 -0400, "Ben > > Walton" <[EMAIL PROTECTED]> said: > > > > bdwalton> As an aside (and I haven't tested at all), were keys and > > bdwalton> permissions that existed on venge.net moved over directly to > > bdwalton> monotone.ca? > > > > Yes, as far as I can tell. I never got direct information, but I > > assumed that all keys that had signed anything related to monotone > > were good enough. > > > > Cheers, > > Richard > > > > - > > Please consider sponsoring my work on free software. > > See http://www.free.lp.se/sponsoring.html for details. > > > > -- > > Richard Levitte [EMAIL PROTECTED] > > http://richard.levitte.org/ > > > > "When I became a man I put away childish things, including > > the fear of childishness and the desire to be very grown up." > > -- C.S. Lewis > > > > > -- > --- > Ben Walton <[EMAIL PROTECTED]> > > When one person suffers from a delusion, it is called insanity. When > many people suffer from a delusion it is called Religion. > Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance > > --- > -- --- Ben Walton <[EMAIL PROTECTED]> When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Religion. Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance --- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] build failure of 0.36 release on linux
I'm seeing a build failure of the 0.36 code. I'm on a Gnu/Linux box, with an AMD64 architecture (dual core opteron) running Kubuntu (dapper): [...] g++ -DLOCALEDIR=\"/usr/local/monotone/monotone-0.36/share/locale\" -DHAVE_CONFIG_H -I. -I./lua -g -O2 -Wall -W -Wno-unused -fno-strict-aliasing -MT mtn-cmd_netsync.o -MD -MP -MF .deps/mtn-cmd_netsync.Tpo -c -o mtn-cmd_netsync.o `test -f 'cmd_netsync.cc' || echo './'`cmd_netsync.cc mv -f .deps/mtn-cmd_netsync.Tpo .deps/mtn-cmd_netsync.Po g++ -DLOCALEDIR=\"/usr/local/monotone/monotone-0.36/share/locale\" -DHAVE_CONFIG_H -I. -I./lua -g -O2 -Wall -W -Wno-unused -fno-strict-aliasing -MT mtn-cmd_list.o -MD -MP -MF .deps/mtn-cmd_list.Tpo -c -o mtn-cmd_list.o `test -f 'cmd_list.cc' || echo './'`cmd_list.cc hybrid_map.hh: In constructor âhybrid_map::const_iterator::const_iterator(const hybrid_map*, const typename std::map, std::allocator > >::const_iterator&) [with Key = unsigned int, Val = boost::shared_ptr]â: hybrid_map.hh:190: instantiated from âhybrid_map::const_iterator hybrid_map::begin() const [with Key = unsigned int, Val = boost::shared_ptr]â cmd_list.cc:376: instantiated from here hybrid_map.hh:119: error: no matching function for call to âInternal::hashtable_iterator >, true, false>::hashtable_iterator()â /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/tr1/hashtable:237: note: candidates are: Internal::hashtable_iterator::hashtable_iterator(const Internal::hashtable_iterator&) [with Value = std::pair >, bool is_const = true, bool cache = false] /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/tr1/hashtable:235: note: Internal::hashtable_iterator::hashtable_iterator(Internal::hash_node**) [with Value = std::pair >, bool is_const = true, bool cache = false] /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/tr1/hashtable:233: note: Internal::hashtable_iterator::hashtable_iterator(Internal::hash_node*, Internal::hash_node**) [with Value = std::pair >, bool is_const = true, bool cache = false] /usr/lib/gcc/x86_64-linux-gnu/4.0.3/../../../../include/c++/4.0.3/tr1/hashtable:226: note: Internal::hashtable_iterator >, true, false>::hashtable_iterator(const Internal::hashtable_iterator >, true, false>&) make[2]: *** [mtn-cmd_list.o] Error 1 make[2]: Leaving directory `/home/doom/End/Slot/Monotone/monotone-0.36' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/doom/End/Slot/Monotone/monotone-0.36' make: *** [all] Error 2 [EMAIL PROTECTED]:~/End/Slot/Monotone/monotone-0.36$ I'm pretty sure I have libboost 1.31.1 installed (and "configure" doesn't complain about it). The installed packages with names matching "libboost" are: libboost-date-time1.33.1 libboost-date-time-dev libboost-dev libboost-doc libboost-filesystem1.33.1 libboost-filesystem-dev libboost-graph-dev libboost-iostreams1.33.1 libboost-iostreams-dev libboost-program-options1.33.1 libboost-program-options-dev libboost-python1.33.1 libboost-python-dev libboost-regex1.33.1 libboost-regex-dev libboost-serialization-dev libboost-signals1.33.1 libboost-signals-dev libboost-test1.33.1 libboost-test-dev libboost-thread1.33.1 libboost-thread-dev libboost-wave-dev Let me know if any other information would be of use. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
