Re: [Monotone-devel] Can Monotone not diff across file renames?
On Tue, Oct 14, 2008 at 10:56 PM, Stephen Leake < [EMAIL PROTECTED]> wrote: > 'mtn automate get_corresponding_path' takes the name in the current > rev and gives you the name in some parent rev. ... gives you the name in some *specified* parent rev, meaning, take this name, look it up in that rev, and get the node id. At least that's how I understand it. > You can use that before invoking this log, or log could do it > automatically. > > I would argue log should do that automatically. Any given name can map to many different node ids through time. Should log include *all* of them? It might take some time to load every historical roster and check to see if the specified name maps to a known node there. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Can Monotone not diff across file renames?
On Tue, Oct 14, 2008 at 10:05 PM, Jack Lloyd <[EMAIL PROTECTED]> wrote: > On Wed, Oct 15, 2008 at 02:52:34PM +1100, Daniel Carosone wrote: > > > The confusion comes from the way names are specified for restrictions > > - in short, are you using the name of the file it has now, or the name > > it had in the revision you're asking for. > > That is a good question! I had assumed it would resolve my name > relative to my current workspace state, but clearly that is not the > case. (?) > It's trying to resolve the name to a roster node id (the stable thing that doesn't really care what it's called or where it's located at the moment) and to do this names are checked against one or two rosters (base and maybe current) to see what they might match. > Perhaps I should review the manual. Hrm. > > > I think in your specific example, it's made worse because you're > > using relative paths within a subdirectory of the workspace, where > > the actual rename was on a parent of that dir. > > Yeah I figured that was part of it. > > > We talked about a way to be explicit about this (a syntax for > > [EMAIL PROTECTED]) but it hasn't been implemented AFAIK. > > How hard would it be to implement? That is just some surface syntax > that boils down to a content hash (or revision id? I don't really know > how Monotone's internal structures work) and then goes into the normal > logic chain of the existing commands, right? I don't think it should be all that hard. The various restriction constructors would probably have to take a db argument to fetch rosters for revisions specified with @revision on a pathname. There might be some path shenanigans though, in the various places that use args_to_paths, since a path would have to allow @revid. I'm not sure if this would be a big deal or not. Once the names have been resolved to node id's in the restriction I think everything else would probably work just fine. This probably only makes sense for commands dealing with historical revisions (diff,log) but not others dealing with the current workspace (status,commit). For your diff ,you should be able use the current pathname, or the pathname in the revision you're attempting to compare with. I'm not sure why that's not working. Apparently we need some more tests. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Can Monotone not diff across file renames?
On Wed, Oct 15, 2008 at 12:56:04AM -0400, Stephen Leake wrote: > 'mtn automate get_corresponding_path' takes the name in the current > rev and gives you the name in some parent rev. Perfect. Thanks! > I would argue log should do that automatically. +1 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] question: remote checkout and remote checkin
"Hugo Cornelis" <[EMAIL PROTECTED]> writes: > I was wondering if it is possible to do remote checkout / checkin > operations ? I'm not sure what you mean by "remote checkout/checkin"; can you give an example? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Can Monotone not diff across file renames?
Jack Lloyd <[EMAIL PROTECTED]> writes: > On Wed, Oct 15, 2008 at 02:52:34PM +1100, Daniel Carosone wrote: > >> The confusion comes from the way names are specified for restrictions >> - in short, are you using the name of the file it has now, or the name >> it had in the revision you're asking for. > > That is a good question! I had assumed it would resolve my name > relative to my current workspace state, but clearly that is not the > case. (?) > > Perhaps I should review the manual. Hrm. > >> I think in your specific example, it's made worse because you're >> using relative paths within a subdirectory of the workspace, where >> the actual rename was on a parent of that dir. > > Yeah I figured that was part of it. > >> We talked about a way to be explicit about this (a syntax for >> [EMAIL PROTECTED]) but it hasn't been implemented AFAIK. > > How hard would it be to implement? That is just some surface syntax > that boils down to a content hash (or revision id? I don't really know > how Monotone's internal structures work) and then goes into the normal > logic chain of the existing commands, right? 'mtn automate get_corresponding_path' takes the name in the current rev and gives you the name in some parent rev. You can use that before invoking this log, or log could do it automatically. I would argue log should do that automatically. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Can Monotone not diff across file renames?
On Wed, Oct 15, 2008 at 02:52:34PM +1100, Daniel Carosone wrote: > The confusion comes from the way names are specified for restrictions > - in short, are you using the name of the file it has now, or the name > it had in the revision you're asking for. That is a good question! I had assumed it would resolve my name relative to my current workspace state, but clearly that is not the case. (?) Perhaps I should review the manual. Hrm. > I think in your specific example, it's made worse because you're > using relative paths within a subdirectory of the workspace, where > the actual rename was on a parent of that dir. Yeah I figured that was part of it. > We talked about a way to be explicit about this (a syntax for > [EMAIL PROTECTED]) but it hasn't been implemented AFAIK. How hard would it be to implement? That is just some surface syntax that boils down to a content hash (or revision id? I don't really know how Monotone's internal structures work) and then goes into the normal logic chain of the existing commands, right? -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Can Monotone not diff across file renames?
On Tue, Oct 14, 2008 at 09:35:10PM -0400, Jack Lloyd wrote: > > I am seriously confused by the behavior I am seeing. I thought this worked? It does, as evidenced by the fact that log is following the file deltas back across renames. The confusion comes from the way names are specified for restrictions - in short, are you using the name of the file it has now, or the name it had in the revision you're asking for. I think in your specific example, it's made worse because you're using relative paths within a subdirectory of the workspace, where the actual rename was on a parent of that dir. We talked about a way to be explicit about this (a syntax for [EMAIL PROTECTED]) but it hasn't been implemented AFAIK. -- Dan. pgpZLXdylbwMQ.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] question: remote checkout and remote checkin
Hi, I was wondering if it is possible to do remote checkout / checkin operations ? If I understand the manual correctly it cannot be done at the moment, and one always has to pull a full database before doing a first checkout ? Is there something I miss ? Thanks. 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] Can Monotone not diff across file renames?
I am seriously confused by the behavior I am seeing. I thought this worked? I am in a net.randombit.botan workspace, in src/math/bigint/mp_ia32_msvc. In that directory, I run: $ mtn log mp_asm.h I get this (I'm including the entire history of the file because it is not too long): o (Revision: 817f1956943c877dcc5aad97774ccd81804654fc) |\ o | - | | Revision: 141433027ee455b8c8b2829f5233eb577039bd41 | | Ancestor: 8a7dd28c69f965e853e95156a43db6d09be7d997 | | Author: [EMAIL PROTECTED] | | Date: 2008-10-15T00:47:14 | | Branch: net.randombit.botan | | | | Modified files: | | src/math/bigint/mp_ia32_msvc/mp_asmi.h | | | | ChangeLog: | | | | Clean up VC++ ia32 asm a bit, use new defs of word3_muladd* from generic mp_asmi.h o | - | | Revision: 8a7dd28c69f965e853e95156a43db6d09be7d997 | | Ancestor: 5d9b383350487fe81dd6196b9ffab20e51a7b094 | | Author: [EMAIL PROTECTED] | | Date: 2008-10-15T00:43:07 | | Branch: net.randombit.botan | | | | Modified files: | | checks/check.cpp src/build-data/botan.doxy.in | | src/math/bigint/mp_ia32_msvc/mp_asmi.h | | | | ChangeLog: | | | | Fix include of mp_asm.h in mp_ia32_msvc/mp_asmi.h (used quotes instead of brackets) o | (Revision: 5d9b383350487fe81dd6196b9ffab20e51a7b094) |\| o | - | | Revision: 511f71afad242186e9339d37f73036c239004281 | | Ancestor: 50e967691e675c407a12b14cdc24b0deb9c9f8a8 | | Author: [EMAIL PROTECTED] | | Date: 2008-09-17T22:38:10 | | Branch: net.randombit.botan | | | | Modified files: | | modules/mp_ia32_msvc/mp_asmi.h | | | | ChangeLog: | | | | Update to 8 word linmul2. Fix word8_madd3 o | (Revision: 50e967691e675c407a12b14cdc24b0deb9c9f8a8) |\| o | - | | Revision: 9e4dfdb079d2f320063d19f75de3fd355d28b613 | | Ancestor: ff7c836f6b49741e71026fff9595774f92d9950f | | Author: [EMAIL PROTECTED] | | Date: 2008-09-17T22:04:40 | | Branch: net.randombit.botan | | | | Modified files: | | modules/mp_ia32_msvc/mp_asmi.h | | | | ChangeLog: | | | | Add yet another version of the Visual C++ x86 asm by Luca Piccarreta, | | this version adding an SSE2 implementation of word8_linmul3 (though Luca | | added a comment noting that it was slower than the plain x86 version). | | | | I'm not intentionally checking these versions in order, this just happened | | to be the order I found them in! | | | | This version was dated 2006-01-23 o | - | | Revision: ff7c836f6b49741e71026fff9595774f92d9950f | | Ancestor: 7fc2dfd566b6c68c479bca037bedec3fbdfc731d | | Author: [EMAIL PROTECTED] | | Date: 2008-09-17T21:57:07 | | Branch: net.randombit.botan | | | | Modified files: | | modules/mp_ia32_msvc/mp_asmi.h | | | | ChangeLog: | | | | Update the Visual C++ assembler with another version also by Luca Piccarreta | | which uses 8 word blocks. This version was dated 2006-01-22 o | - |/Revision: 7fc2dfd566b6c68c479bca037bedec3fbdfc731d | Ancestor: ff2148e42baf841d99b68017be88dffdede3f07d | Author: [EMAIL PROTECTED] | Date: 2008-09-17T21:49:24 | Branch: net.randombit.botan | | Modified files: | modules/mp_ia32_msvc/mp_asmi.h | | ChangeLog: | | Reindent o - | Revision: ff2148e42baf841d99b68017be88dffdede3f07d | Ancestor: b077aedf04b1001eb385c7c5793bea80fab0c90c | Author: [EMAIL PROTECTED] | Date: 2008-09-17T21:43:36 | Branch: net.randombit.botan | | Added files: | modules/mp_ia32_msvc/modinfo.txt | modules/mp_ia32_msvc/mp_asmi.h | Added directories: | modules/mp_ia32_msvc | | ChangeLog: | | Add some inline assembler for x86 systems using Visual Studio's | inline asm syntax. This code was written and submitted by | Luca Piccarreta in 2006. Sometimes it takes a while for me to work | through patches. | | It does not implement the right functions (using 4 word blocks instead of | 8), so it will not work and of course also has not been tested at all. o (Revision: b077aedf04b1001eb385c7c5793bea80fab0c90c) So, I want to see what changed since 511f71afad242186e9339d37f73036c239004281, but: $ mtn diff -r 511f71afad242186e9339d37f73036c239004281 mp_asmi.h mtn: misuse: file modules/mp_ia32_msvc/mp_asmi.h does not exist # # old_revision [511f71afad242186e9339d37f73036c239004281] # # patch "modules/mp_ia32_msvc/mp_asmi.h" # from [a51f4b885bdf2d6844bc5c822a8f0c1d62c90365] #to [b3fa41862df8266419d9b7c1b88909588f53a6bf] # $ m
Re: [Monotone-devel] Monotone Security
On Tue, 2008-10-14 at 18:12 +0200, Daniel Carrera wrote:
> Hello,
>
> I have been working on a paper on Monotone's security. I have tried to
> make it accurate, but I'm sure that there are still errors. But it's
> probably good enough to merit posting.
>
>
> http://daniel.carrera.name/Monotone_Security/
>
> Yes, it's long. If you want a quick summary, here it is: "Monotone is
> really good; encrypted archives would make it better".
>
> I followed David A. Wheeler's criteria for secure SCMs. That is the best
> impartial standard for SCM security that I know of. If you choose to
> read some of this and spot some errors, please do let me know. Also,
> feel free to reuse any of all of this. It's public domain.
Availability
Anyone with write access can kill the server by sending
invalid data. Most of our error checking is similar to
"if (error) { complain(); die(); }".
A network read error (say, unplugging the client's network
cable) used to also kill the server in this manner, I don't
know if that's been fixed.
Outsiders without privileges
"If an attacker manages to insert a new RSA key into the
database"... commits with that key will be ignored *IF* everyone
is using custom get_revision_cert_trust hooks. If anyone uses
the default hook, they'll only notice if they're paying
attention. Keys are transferred whenever needed to validate a
cert that's also being transferred.
This should improve in the future, but there's no timeline for
it.
Malicious developers
"Encumbrance pollution attack"
Our solution includes "everyone delete your database",
does this really count as being able to resist such
attackts? About the only problem you *won't* have is
independent revisions changing their names the way some
centralized systems could potentially change revision
numbers.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] new include/exclude commands?
On Tue, Oct 14, 2008 at 11:17 AM, Derek Scherger <[EMAIL PROTECTED]> wrote: > > If there is general interest in this (and no objections?) I'll add some > tests, write up something in the manual and see about getting it included in > mainline. I've just thought of a personal use case -- my Firefox source trees for work contain a permanent, but never to be checked in, change to a file I otherwise have no reason to mess with, which makes it possible to run debugging builds simultaneously with a regular release of the browser. Being that MozCo uses Mercurial, I do this with an MQ patch which is perpetually at the bottom of the stack, but it's quite easy to fat-finger that and do a build that doesn't have the patch, which can then cause a bit of havoc. The proposed feature would let me just stick the file in question under "exclude" and forget it. That's the sort of thing that makes a good example for the manual... zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] new include/exclude commands?
On Tue, Oct 14, 2008 at 10:07 AM, Hugo Cornelis <[EMAIL PROTECTED]>wrote: > For me personally a real annoyance is changes to Makefile.in, > config.log and configure scripts due to development done on a > different architecture (distributed development). Excluding those > from (most) commits and status queries would be greatly appreciated. > If you are able to build your own monotone, you can try this stuff out on the net.venge.monotone.experiment.include-exclude branch. If there is general interest in this (and no objections?) I'll add some tests, write up something in the manual and see about getting it included in mainline. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped failing check for lua
On Tue, Oct 14, 2008 at 10:54:40AM -0700, Zack Weinberg wrote: > Aside to Jack Lloyd: It would be nice if botan provided a .pc file as > well as the botan-config executable. OK. Would it make sense to name the pkg-config based on the major and minor versions? pkg-config botan-1.7 --libs pkg-config botan-1.8 --cflags etc I'm guessing probably so, but I don't know pkg-config etiquette. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped failing check for lua
On Mon, Oct 13, 2008 at 9:51 PM, Zack Weinberg <[EMAIL PROTECTED]> wrote: > I remember writing a bunch of m4 to deal with [varying names of .pc files] > but it > doesn't seem to be on this computer; I'll look on the other one tomorrow. Found it. The attached file goes in the m4/ directory, and is used like so: # All of these libraries can be probed for by some combination of # pkg-config and foobar-config, but it's not as simple as it ought to # be, hence the macros. PKG_PROG_PKG_CONFIG MTN_3RDPARTY_LIB(botan) MTN_3RDPARTY_LIB(idn) MTN_3RDPARTY_LIB(lua) MTN_3RDPARTY_LIB(netxx) MTN_3RDPARTY_LIB(pcre) MTN_3RDPARTY_LIB(sqlite) MTN_REMOVE_REDUNDANT_LIB_SWITCHES Some of the logic in the file is specific to the setup on the library-build branch; in particular, it probably makes more sense in the .stripped context to make the minimum version requirement for each library be a second argument to MTN_3RDPARTY_LIB rather than digging it out of the metadata of the bundled copy. Aside to Jack Lloyd: It would be nice if botan provided a .pc file as well as the botan-config executable. zw thirdparty.m4 Description: Binary data ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
On Tue, Oct 14, 2008 at 06:07:54AM +0200, Richard Levitte wrote: > In message <[EMAIL PROTECTED]> on Mon, 13 Oct 2008 21:16:59 -0600, "Derek > Scherger" <[EMAIL PROTECTED]> said: > > derek> On Mon, Oct 13, 2008 at 8:45 PM, Jack Lloyd <[EMAIL PROTECTED]> wrote: > derek> > derek> > Attached is a patch for getting the PCRE runtime version as well. > derek> > > derek> > derek> Committed in ad7d563d114ba37fe5232fa429fecfc1681c3326, thanks again. > derek> > derek> Would you like to have commit access Jack? I'm not in a position to > grant > derek> that to you myself but I'm sure we could arrange it. > > That could certainly be arranged. Jack, if you're interested, please > send me public part of your monotone key, privately. Thanks guys. Who knows if I will ever have time to really work on Monotone (I would love to dig into the authorization/netsync system sometime, I still think there are some lessons we learned on OpenCM that Monotone could benefit from), but I can at least help with housecleaning occasionally. Richard, I'll send you my mtn key in a moment. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Monotone Security
Hello, I have been working on a paper on Monotone's security. I have tried to make it accurate, but I'm sure that there are still errors. But it's probably good enough to merit posting. http://daniel.carrera.name/Monotone_Security/ Yes, it's long. If you want a quick summary, here it is: "Monotone is really good; encrypted archives would make it better". I followed David A. Wheeler's criteria for secure SCMs. That is the best impartial standard for SCM security that I know of. If you choose to read some of this and spot some errors, please do let me know. Also, feel free to reuse any of all of this. It's public domain. Regards Daniel. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] new include/exclude commands?
For me personally a real annoyance is changes to Makefile.in, config.log and configure scripts due to development done on a different architecture (distributed development). Excluding those from (most) commits and status queries would be greatly appreciated. Hugo On Sun, Oct 12, 2008 at 7:15 PM, Derek Scherger <[EMAIL PROTECTED]> wrote: > On Sun, Oct 12, 2008 at 3:32 PM, Thomas Keller <[EMAIL PROTECTED]> wrote: >> >> Derek Scherger schrieb: >> > Since 0.40 there is a new hook `get_default_command_options` which could >> > >> > >> > Hrm, I hadn't used that before, but it does seem nice. Was it added just >> > after 0.40 or is it included in 0.40? (my system installed 0.40 doesn't >> > seem to have it but more recent builds do) >> >> Sorry, my bad, it was 0.41 where I introduced that. And I agree that a > > No worries, I was just confused for a minute. > >> >> frontend command would be nicer for this, but I wanted to note that its >> possible and available ;) > > Ok good, it is good to know that there are other possibilities too. I'll > commit what I have to a branch and we can bat it around a bit. > > Just to be clear, it does not use a versioned .mtn-exclude file at the > moment though. I currently have unversioned workspace files in _MTN/includes > and _MTN/excludes containing the accumulated mtn include and mtn exclude > paths respectively. The contents of these files are literally just added to > the list of paths specified to various commands or to the list of > --excludes. > > Cheers, > Derek > > > > ___ > 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
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
Hi, Alex Sandro Queiroz e Silva wrote: > The lua.h file defines LUA_RELEASE. That's the one I've been using before, which does not make much sense, because it can only serve as a build time check. It's not a runtime check like the global lua variable _VERSION. (And no, there is no _RELEASE global lua variable). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
Hallo, Markus Wanner wrote: > Hi, > > Zack Weinberg wrote: >> well, you could always do the moral equivalent in C: >> >> lua_getglobal(L, "_VERSION"); >> std::string luaversion(lua_tostring(L, -1)); // copies >> lua_pop(L, 1); > > Hm.. I've tried that and stumbled over two problems. One is, that > mt_version.cc doesn't have access to a Lua_state object (and gets called > from sanity.cc, which doesn't either). > > The other one is, the patch version isn't included in the _VERSION > global variable: > The lua.h file defines LUA_RELEASE. Cheers, -alex http://www.ventonegro.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
Hi, Zack Weinberg wrote: > well, you could always do the moral equivalent in C: > > lua_getglobal(L, "_VERSION"); > std::string luaversion(lua_tostring(L, -1)); // copies > lua_pop(L, 1); Hm.. I've tried that and stumbled over two problems. One is, that mt_version.cc doesn't have access to a Lua_state object (and gets called from sanity.cc, which doesn't either). The other one is, the patch version isn't included in the _VERSION global variable: > # lua > Lua 5.1.3 Copyright (C) 1994-2008 Lua.org, PUC-Rio >> print(_VERSION) > Lua 5.1 >> So there's utterly no point in showing that, since we (build time) require 5.1.x anyway. I've thus reverted to show only 'Lua 5.1' in rev 6b777e3eb453b3b0be4d9aaa93e81cd56c6ca635. (As opposed to showing the patch version (i.e. "5.1.3") we've built against). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped failing check for lua
Hi, Alex Sandro Queiroz e Silva wrote: > The Lua authors have had no problems with breaking API and ABI > compatibility with each new version so far. So programs usually work > with just one version of Lua only. Between 5.0 and 5.1, yes. But I've so far thought that 5.1.x are bugfix releases only. See: http://www.lua.org/bugs.html. That's why I made nvm.stripped require lua 5.1.x (and not 5.0.x). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] nvm.stripped failing check for lua
Hallo, Richard Levitte wrote: > > Yes. However, it seems like some packages make the library version > part of the library *name*, to make sure that you link against exactly > that version and none else. > > Why they do so for lua, I've no idea... > The Lua authors have had no problems with breaking API and ABI compatibility with each new version so far. So programs usually work with just one version of Lua only. Cheers, -alex http://www.ventonegro.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
Hi, Stephen Leake wrote: > Assuming we eventually integrate this branch into mainline, how many > versions of sqlite (and all the other libraries!) do we need the > buildbots to test? I think it's sufficient supporting the library versions shipped with the distributions. > And do we want to get into testing all possible combinations of > library versions? Certainly not *all* possible combinations. I'd say we don't even need to test every single patch version of each library. After all, these (should) provide a stable API and ABI. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: nvm.stripped
Markus Wanner <[EMAIL PROTECTED]> writes: > With these fixes I've been able to compile and successfully test > monotone against all of these sqlite versions: > > 3.3.8 (as currently included in debian etch / stable) > 3.3.12 > 3.3.17 > 3.4.1 (what we shipped up to now) > 3.5.9 (as currently included in debian lenny / testing) > 3.6.3 (newest upstream release) This raises an issue for the test suite and buildbots. Assuming we eventually integrate this branch into mainline, how many versions of sqlite (and all the other libraries!) do we need the buildbots to test? And do we want to get into testing all possible combinations of library versions? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
