Re: [Monotone-devel] nvm.stripped failing check for lua

[Brian May]

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.
  
In general, this is a real pain in Debian, it means any updates to the 
library may require all clients to be rebuilt.


Unless the library is really unstable and prone to change its API it 
really isn't required, you just use the library soname.


Brian May


___
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

[Richard Levitte]

In message <[EMAIL PROTECTED]> on Mon, 13 Oct 2008 23:06:59 -0600, "Derek 
Scherger" <[EMAIL PROTECTED]> said:

derek> On Mon, Oct 13, 2008 at 10:51 PM, Zack Weinberg <[EMAIL PROTECTED]> 
wrote:
derek> 
derek> > Debian:
derek> >
derek> > $ (cd /usr/lib && ls -l liblua*)
derek> > -rw-r--r-- 1 root root 324860 2008-01-26 08:12 liblua5.1.a
derek> > -rw-r--r-- 1 root root825 2008-01-26 08:12 liblua5.1.la
derek> > lrwxrwxrwx 1 root root 18 2008-04-01 11:39 liblua5.1.so ->
derek> > liblua5.1.so.0.0.0
derek> > lrwxrwxrwx 1 root root 18 2008-03-31 07:09 liblua5.1.so.0 ->
derek> > liblua5.1.so.0.0.0
derek> > -rw-r--r-- 1 root root 171696 2008-01-26 08:12 liblua5.1.so.0.0.0
derek> > $ (cd /usr/lib/pkgconfig && ls -l *lua*)
derek> > -rw-r--r-- 1 root root 857 2008-01-26 08:12 lua5.1.pc
derek> >
derek> 
derek> Wow, that's odd. I thought the version numbers were supposed to come 
*after*
derek> the .so, where all those, um, numbers are?

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...

-- 
Richard Levitte [EMAIL PROTECTED]
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

Re: [Monotone-devel] nvm.stripped failing check for lua

[Zack Weinberg]

On Mon, Oct 13, 2008 at 10:06 PM, Derek Scherger <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 13, 2008 at 10:51 PM, Zack Weinberg <[EMAIL PROTECTED]> wrote:
>>
>> lrwxrwxrwx 1 root root 18 2008-04-01 11:39 liblua5.1.so ->
>> liblua5.1.so.0.0.0
>> lrwxrwxrwx 1 root root 18 2008-03-31 07:09 liblua5.1.so.0 ->
>> liblua5.1.so.0.0.0
>
> Wow, that's odd. I thought the version numbers were supposed to come *after*
> the .so, where all those, um, numbers are?

yeah, it's bizarre to me too.  It *might* have to do with there also
being 4.0 and 5.0 iterations of this library in the archive, but that
oughta only affect the package names, not the .so names.   More
likely, it's something that was done a long time ago by someone who
didn't know any better and now they're stuck with it.  Bleah.

zw


___
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

[Derek Scherger]

On Mon, Oct 13, 2008 at 10:51 PM, Zack Weinberg <[EMAIL PROTECTED]> wrote:

> Debian:
>
> $ (cd /usr/lib && ls -l liblua*)
> -rw-r--r-- 1 root root 324860 2008-01-26 08:12 liblua5.1.a
> -rw-r--r-- 1 root root825 2008-01-26 08:12 liblua5.1.la
> lrwxrwxrwx 1 root root 18 2008-04-01 11:39 liblua5.1.so ->
> liblua5.1.so.0.0.0
> lrwxrwxrwx 1 root root 18 2008-03-31 07:09 liblua5.1.so.0 ->
> liblua5.1.so.0.0.0
> -rw-r--r-- 1 root root 171696 2008-01-26 08:12 liblua5.1.so.0.0.0
> $ (cd /usr/lib/pkgconfig && ls -l *lua*)
> -rw-r--r-- 1 root root 857 2008-01-26 08:12 lua5.1.pc
>

Wow, that's odd. I thought the version numbers were supposed to come *after*
the .so, where all those, um, numbers are?

so, no.


I was afraid of that. ;)


> I remember writing a bunch of m4 to deal with this problem but it
> doesn't seem to be on this computer; I'll look on the other one
> tomorrow.
>

Great, thanks.

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

[Zack Weinberg]

On Mon, Oct 13, 2008 at 7:55 PM, Derek Scherger <[EMAIL PROTECTED]> wrote:
> - PKG_CHECK_MODULES([LUA], [lua5.1],
> + PKG_CHECK_MODULES([LUA], [lua],
>
> Is this a reasonable change on other systems?

Debian:

$ (cd /usr/lib && ls -l liblua*)
-rw-r--r-- 1 root root 324860 2008-01-26 08:12 liblua5.1.a
-rw-r--r-- 1 root root825 2008-01-26 08:12 liblua5.1.la
lrwxrwxrwx 1 root root 18 2008-04-01 11:39 liblua5.1.so ->
liblua5.1.so.0.0.0
lrwxrwxrwx 1 root root 18 2008-03-31 07:09 liblua5.1.so.0 ->
liblua5.1.so.0.0.0
-rw-r--r-- 1 root root 171696 2008-01-26 08:12 liblua5.1.so.0.0.0
$ (cd /usr/lib/pkgconfig && ls -l *lua*)
-rw-r--r-- 1 root root 857 2008-01-26 08:12 lua5.1.pc

so, no.

I remember writing a bunch of m4 to deal with this problem but it
doesn't seem to be on this computer; I'll look on the other one
tomorrow.

zw


___
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

[Zack Weinberg]

On Mon, Oct 13, 2008 at 7:45 PM, Jack Lloyd <[EMAIL PROTECTED]> wrote:
> I could not figure out how to get the runtime Lua version (aside from
> executing a line of Lua that ruturns the value of the Lua _VERSION
> variable)

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);

zw


___
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

[Richard Levitte]

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.

Cheers,
Richard

-- 
Richard Levitte [EMAIL PROTECTED]
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

Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch

[Derek Scherger]

On Mon, Oct 13, 2008 at 8:45 PM, Jack Lloyd <[EMAIL PROTECTED]> wrote:

> Attached is a patch for getting the PCRE runtime version as well.
>

Committed in ad7d563d114ba37fe5232fa429fecfc1681c3326, thanks again.

Would you like to have commit access Jack? I'm not in a position to grant
that to you myself but I'm sure we could arrange it.

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] nvm.stripped failing check for lua

[Derek Scherger]

On my system (gentoo) the pkg-config check for lua fails with:

checking for LUA... no
checking for lua 5.1... no; guessing
checking for lua_load in -llua5.1... no
checking whether the lua library is usable... yes

Applying the following patch to patch m4/lua.m4 seems to make it happy:

#
# old_revision [6c5a8fa3d0437be28f59b448a5f72c90267df149]
#
# patch "m4/lua.m4"
#  from [1253a38c8df4cb482c3588d3d11e6478952f2b8c]
#to [18918826ac2f2eafefabe1c0038df4b1ab7a881c]
#

--- m4/lua.m41253a38c8df4cb482c3588d3d11e6478952f2b8c
+++ m4/lua.m418918826ac2f2eafefabe1c0038df4b1ab7a881c
@@ -10,7 +10,7 @@ AC_DEFUN([MTN_FIND_LUA],
if test -n "${LUA_CFLAGS+set}" || test -n "${LUA_LIBS+set}"; then
  found_liblua=yes
else
- PKG_CHECK_MODULES([LUA], [lua5.1],
+ PKG_CHECK_MODULES([LUA], [lua],
[found_liblua=yes], [found_liblua=no])
fi

checking for LUA... yes
checking whether the lua library is usable... yes

Is this a reasonable change on other systems?

Cheers,
Derek
___
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

[Jack Lloyd]

On Mon, Oct 13, 2008 at 11:52:53PM +0200, Markus Wanner wrote:
> Hi,
> 
> Richard Levitte wrote:
> > In the same vein, the code to display the versions of SQLite, Botan
> > and so on might be misleading in a shared library environment.  Maybe
> > it should display both the versions it was compiled against and the
> > versions it's running against (if that's possible to find out, which
> > isn't always a given).
> 
> I've done that for SQLite and botan now. The mtn version --full output
> now looks like (as an example):
[...]

Attached is a patch for getting the PCRE runtime version as well.

I could not figure out how to get the runtime Lua version (aside from
executing a line of Lua that ruturns the value of the Lua _VERSION
variable)

$ ./mtn version --full

monotone 0.41 (base revision: 7aa69891001cc53af518ca9bff8e1c7dae0c280d)
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.2
C++ standard library: GNU libstdc++ version 20080827
Boost version   : 1_35
SQLite version  : 3.5.9 (compiled against 3.5.9)
Lua version : Lua 5.1.3
PCRE version: 7.7 2008-05-07 (compiled against 7.7)
Botan version   : 1.7.18 (compiled against 1.7.18)
Changes since base revision:
unknown
#
# old_revision [7aa69891001cc53af518ca9bff8e1c7dae0c280d]
#
# patch "mt_version.cc"
#  from [76772c0f83691ab5bed123dd6c95616904360c52]
#to [0e9248c3606fce1b99798bb29705b5b3293e9580]
#

--- mt_version.cc   76772c0f83691ab5bed123dd6c95616904360c52
+++ mt_version.cc   0e9248c3606fce1b99798bb29705b5b3293e9580
@@ -83,7 +83,7 @@ get_full_version(string & out)
"Boost version   : %s\n"
"SQLite version  : %s (compiled against %s)\n"
"Lua version : %s\n"
-   "PCRE version: %d.%d\n"
+   "PCRE version: %s (compiled against %d.%d)\n"
"Botan version   : %d.%d.%d (compiled against %d.%d.%d)\n"
"Changes since base revision:\n"
"%s")
@@ -93,7 +93,7 @@ get_full_version(string & out)
 % BOOST_LIB_VERSION
 % sqlite3_libversion() % SQLITE_VERSION
 % LUA_RELEASE
-% PCRE_MAJOR % PCRE_MINOR
+% pcre_version() % PCRE_MAJOR % PCRE_MINOR
 % Botan::version_major() % Botan::version_minor() % Botan::version_patch()
 % BOTAN_VERSION_MAJOR % BOTAN_VERSION_MINOR % BOTAN_VERSION_PATCH
 % string(package_full_revision_constant);
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: converting a monotone repository

[Derek Scherger]

On Mon, Oct 13, 2008 at 6:12 PM, Timothy Brownawell <[EMAIL PROTECTED]>wrote:

> There's a new --no-workspace option to turn off this behavior even when
> you're in the root of a workspace.
>

Oh good, that's better than the --root option, I'll switch things over to
that. I'm still having problems with conversion that I haven't managed to
track down yet (mostly because I've been distracted with other things).
There are two different revs in my monotone database that seem to give hg
some grief. One of them is on the net.venge.monotone.guitone branch and
fails with a utf8 problem iirc. The other is somewhere in monotone's own
history but I don't have any more details at the moment.

My motivation here is just to see how fast mercurial would pull the monotone
history for interests sake and to see how far off of that benchmark we would
be. From what I've seen so far, hg seems generally quite nice, but giving up
versioned directories and a bunch of the other good things that monotone has
isn't all that appealing. There are somewhat interesting discussions on the
hg list about named branches (which appear to have similar characteristics
to monotone branches) vs clones which appear to be somewhat more transient
and lighter weight.

Cheers,
Derek
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: converting a monotone repository

[Timothy Brownawell]

On Sat, 2008-10-04 at 23:55 -0600, Derek Scherger wrote:
[...]

> One easy way to fix this problem is to have mercurial run monotone
> with the '--root=.' option to prevent monotone from searching for a
> _MTN directory. 
> 
[...]
> 
> It also seems somewhat questionable to me that the monotone automation
> interface goes looking for a workspace root directory in the first
> place although I'm sure there are reasons for this that escape me at
> the moment.

There's a new --no-workspace option to turn off this behavior even when
you're in the root of a workspace.

I think the reason it looks for a workspace is at least partly that
there are some automate commands that do interact with a workspace, such
as get_base_revision_id.


-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net



___
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

[Markus Wanner]

Hi,

Markus Wanner wrote:
> Richard Levitte wrote:
>> Just a moment ago, I saw a change that made the montone code depend on
>> the version of SQLITE as described by a C macro.  That's fine and
>> dandy provided you link monotone with the static library, but what
>> happens if it's linked with the shared library and then moved to
>> another machine with a more modern (or even slightly older!) version
>> of SQLite?

Proper runtime checks are in place for SQLite and Botan since revision
7aa69891001cc53af518ca9bff8e1c7dae0c280d.

SQLite seems to maintain a backwards compatible API for all versions
3.x.x. Compiling against 3.3.8 and running with 3.5.9 worked just fine
for all unit test.

Botan has a stable branch 1.6.x and a development one being 1.7.x.
Supporting the moving target 1.7.x branch is a bit of a hassle, but OTOH
we well be up and running right away when 1.8.x alias next stable branch
comes out.

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

[Markus Wanner]

Hi,

Richard Levitte wrote:
> In the same vein, the code to display the versions of SQLite, Botan
> and so on might be misleading in a shared library environment.  Maybe
> it should display both the versions it was compiled against and the
> versions it's running against (if that's possible to find out, which
> isn't always a given).

I've done that for SQLite and botan now. The mtn version --full output
now looks like (as an example):

monotone 0.41 (base revision: 35c9a1b5661fa713059728bec11204df5d0fe7c4)
Running on  : Linux 2.6.27-rc6-markus1 #4 SMP Thu Sep 18
13:30:24 CEST 2008 x86_64
C++ compiler: GNU C++ version 4.3.2
C++ standard library: GNU libstdc++ version 20080905
Boost version   : 1_34_1
SQLite version  : 3.5.9 (compiled against 3.3.8)
Lua version : Lua 5.1.3
PCRE version: 7.8
Botan version   : 1.6.3 (compiled against 1.6.3)
Changes since base revision:
format_version "1"

new_manifest [84b53d2311043f42fcd55b15e9b548b3b9fb7e48]

old_revision [67a5c30e1c38753ca92bda29120299e4872ac34b]

  Generated from data cached in the distribution;
  further changes may have been made.


The cost for being independent of the actual SQLite library is having to
use sqlite3_prepare() instead of sqlite3_prepare_v2(), which exists only
since 3.3.14. However, as that's just 1.5 years old and because 3.3.8 is
in etch, I'm trying to still support those versions.

Regards

Markus Wanner



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Concerns about the net.venge.monotone.stripped branch

[Markus Wanner]

Hi,

Bruce Stephens wrote:
> No idea.  Choose a file that you expect to have been altered
> frequently and do "cvs log ".  At the top will be any tags or
> branch names.

Hm.. "cvs rlog" did the trick. However, it looks like they are not
tagging releases. I've so far only found these:

version_3_3_13
version_3_3_17

:-(

Regards

Markus Wanner



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Re: Concerns about the net.venge.monotone.stripped branch

[Bruce Stephens]

Markus Wanner <[EMAIL PROTECTED]> writes:

[...]

> Any idea what CVS tags they define? I've checked out their CVS tree, but
> I'm missing 'cvs ls tags' :-)

No idea.  Choose a file that you expect to have been altered
frequently and do "cvs log ".  At the top will be any tags or
branch names.


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Re: Concerns about the net.venge.monotone.stripped branch

[Markus Wanner]

Hi,

Bruce Stephens wrote:
>  suggests it should be
> easy enough.

Thanks for the hint.

Any idea what CVS tags they define? I've checked out their CVS tree, but
I'm missing 'cvs ls tags' :-)   And their downloads website doesn't list
order versions...

Regards

Markus Wanner



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] Re: Concerns about the net.venge.monotone.stripped branch

[Bruce Stephens]

Markus Wanner <[EMAIL PROTECTED]> writes:

[...]

> Agreed. Thanks for pointing this out. I'll check if we can add dynamic
> version checks as well.

 suggests it should be
easy enough.


___
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

[Markus Wanner]

Hi,

Richard Levitte wrote:
> Just a moment ago, I saw a change that made the montone code depend on
> the version of SQLITE as described by a C macro.  That's fine and
> dandy provided you link monotone with the static library, but what
> happens if it's linked with the shared library and then moved to
> another machine with a more modern (or even slightly older!) version
> of SQLite?

Yeah, I've been thinking about that as well. I'm not sure where to look
for run time version information of the library, but I've been able to
exchange *.so files without any hassle so far for versions which do not
require the hex() function.

> I don't know how SQLite handles such cases, but I do know that not
> paying attention to that kind of thing have and still can lead to
> problems.

Agreed. Thanks for pointing this out. I'll check if we can add dynamic
version checks as well.

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

[Richard Levitte]

In the same vein, the code to display the versions of SQLite, Botan
and so on might be misleading in a shared library environment.  Maybe
it should display both the versions it was compiled against and the
versions it's running against (if that's possible to find out, which
isn't always a given).

Cheers,
Richard

In message <[EMAIL PROTECTED]> on Mon, 13 Oct 2008 16:12:01 +0200 (CEST), 
Richard Levitte <[EMAIL PROTECTED]> said:

richard> Hello,
richard> 
richard> I've been watching the development of the net.venge.monotone.stripped
richard> branch for a bit, and I'm starting to notice some dependencies that I
richard> find concerning.
richard> 
richard> Just a moment ago, I saw a change that made the montone code depend on
richard> the version of SQLITE as described by a C macro.  That's fine and
richard> dandy provided you link monotone with the static library, but what
richard> happens if it's linked with the shared library and then moved to
richard> another machine with a more modern (or even slightly older!) version
richard> of SQLite?
richard> The hex function that was just defined might already exist on a target
richard> machine that has SQLite 3.3.14, but monotone would still try to inject
richard> its own version if it was built on a machine that has SQLite 3.3.12.
richard> I don't know how SQLite handles such cases, but I do know that not
richard> paying attention to that kind of thing have and still can lead to
richard> problems.
richard> 
richard> Cheers,
richard> Richard
richard> 
richard> -- 
richard> Richard Levitte [EMAIL PROTECTED]
richard> http://richard.levitte.org/
richard> 
richard> "Life is a tremendous celebration - and I'm invited!"
richard> -- from a friend's blog, translated from Swedish
richard> 
richard> 
richard> ___
richard> Monotone-devel mailing list
richard> Monotone-devel@nongnu.org
richard> 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] Concerns about the net.venge.monotone.stripped branch

[Richard Levitte]

Hello,

I've been watching the development of the net.venge.monotone.stripped
branch for a bit, and I'm starting to notice some dependencies that I
find concerning.

Just a moment ago, I saw a change that made the montone code depend on
the version of SQLITE as described by a C macro.  That's fine and
dandy provided you link monotone with the static library, but what
happens if it's linked with the shared library and then moved to
another machine with a more modern (or even slightly older!) version
of SQLite?
The hex function that was just defined might already exist on a target
machine that has SQLite 3.3.14, but monotone would still try to inject
its own version if it was built on a machine that has SQLite 3.3.12.
I don't know how SQLite handles such cases, but I do know that not
paying attention to that kind of thing have and still can lead to
problems.

Cheers,
Richard

-- 
Richard Levitte [EMAIL PROTECTED]
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

Re: [Monotone-devel] Re: nvm.stripped

[Markus Wanner]

Hi,

Markus Wanner wrote:
>  3.4.1  (what we shipped up to now)

Oops, revoking that. 3.4.1 and 3.4.2 currently fail on test
'database_dump_load', which is fishy because 3.4.1 was integrated
before, no?

I'm investigating on the issue.

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]

Hi,

I've now corrected or worked around issues with various sqlite versions.
These tests have failed before:

Markus Wanner wrote:
> 146 database_checkFAIL (line 23)
> 216 i_selectorFAIL (line 32)

Revision 40dba08582bcb2eecde9c9700fcab85b11f2ff61 adds a 'hex()'
function for sqlite versions below 3.3.13, which didn't have that, yet.
That made these two tests succeed for sqlite 3.3.8 - 3.3.13.

> 192 empty_environment FAIL (line 29)

The 'empty_environment' test does no longer completely wipe the
environment, but maintains the given LD_LIBRARY_PATH environment
variable. This only works under Linux for now. I'm lacking any other
systems to test on. Added in rev f67d1482d7c2aa37adaeeb7db09161be9dc8b616

This should also help other linked libraries.

> 203 fail_cleanly_on_unreadable_db unexpected success

Rev b268fec033da5902f6af76e8e56b2ace759e090f fixes this issue by
removing he offending checks.

Investigating revealed, that newer sqlite3 versions are trying to
read/write a journal file in the same directory where the database
resides. That of course fails for unreadable, but only searchable
directories. Here's an strace of sqlite3 trying to open a journal file
on a a-rw+x parent directory '/home/markus/test':

open("/home/markus/test/test.db-journal",
O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE|O_NOFOLLOW, 0644) = 4
open("/home/markus/test", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission
denied)
close(4)


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)

I didn't care to test anything older than 3.3.8.

Regards

Markus Wanner


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] nvm.stripped test results + adding version numbers to version --full

[Markus Wanner]

Hi,

Jack Lloyd wrote:
> New version. Use the version macros for Botan instead of calling the
> string function. Mostly for consistency with the rest of the version #
> sources.

Thanks, very cool.

Committed as rev ce0db5b1f6d3b9ab45535784e298599733d0d6ab.

Regards

Markus Wanner



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel