Re: Splitting up the INSTALL file Was: Re: [Monotone-devel] status of nvm.stripped
Hi, Thomas Keller wrote: >> I was thinking we should split INSTALL into separate files >> (INSTALL.windows_mingw, etc), but let's see how big it gets first. +1 That's what I'm often seeing for other projects and I think it works well. > INSTALL really became somewhat of a monster in 0.43. I've actually never > seen a project which put all these distro-specific package names and > setup procedures in an INSTALL file - but rather on some website / wiki. Please *not* a website or wiki. The build instructions should be part of the source tarball, IMO. > On the other hand having very detailed installation instructions > especially for 0.43, the first unbundled release, will probably > overweight someone's disability to search for the contents he needs - > maybe we decide in a later version to shrink down the contents of > INSTALL, or split the files up even. I wouldn't do that for the upcoming > release though. Splitting into OS specific files (instead of sections in INSTALL) doesn't necessarily mean shrinking docu. I think we rather have to organize it better. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, Thomas Keller wrote: > Whats the status of this? The INSTALL file still contains a > > FIXME: yet to be confirmed > > message in the Solaris / opencsw.org section. Sorry, I didn't have much time for testing or developing mtn recently. > Shall we then remove this > section, mark it "not tested" or somthing? I just don't like to see a > FIXME note in this file for the next release ;) Agreed. Yes, please remove it. Maybe somebody with more experience on Solaris can contribute detailed build instructions. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Splitting up the INSTALL file Was: Re: [Monotone-devel] status of nvm.stripped
Stephen Leake schrieb: > Markus Wanner writes: >> I've updated the INSTALL document and documented as good as I can. I'm >> missing instructions for Windows/Cygwin. Lapo? > > I can provide MinGW. It may be rather long, depending on detail. I > guess we can assume a competent developer, not a complete newbie. > > I was thinking we should split INSTALL into separate files > (INSTALL.windows_mingw, etc), but let's see how big it gets first. INSTALL really became somewhat of a monster in 0.43. I've actually never seen a project which put all these distro-specific package names and setup procedures in an INSTALL file - but rather on some website / wiki. On the other hand having very detailed installation instructions especially for 0.43, the first unbundled release, will probably overweight someone's disability to search for the contents he needs - maybe we decide in a later version to shrink down the contents of INSTALL, or split the files up even. I wouldn't do that for the upcoming release though. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi! Markus Wanner schrieb: > I've just run through the testsuite with mtn compiled against an up to > date sqlite 3.6.10 (released Jan 15th). All tests succeed. > >> monotone 0.43dev (base revision: 2d8426478d56750e764a5ce552ba3ce7c22acb0a) >> Running on : Linux 2.6.26-1-686 #1 SMP Thu Jan 1 02:26:25 UTC 2009 >> i686 >> C++ compiler: GNU C++ version 4.3.2 >> C++ standard library: GNU libstdc++ version 20080905 >> Boost version : 1_34_1 >> SQLite version : 3.6.10 (compiled against 3.6.10) >> Lua version : Lua 5.1 >> PCRE version: 7.6 2008-01-28 (compiled against 7.6) >> Botan version : 1.8.1 (compiled against 1.8.1) > > However, I'm still having troubles with Solaris. Maybe mostly due to my > lack of understanding of that system, though. Whats the status of this? The INSTALL file still contains a FIXME: yet to be confirmed message in the Solaris / opencsw.org section. Shall we then remove this section, mark it "not tested" or somthing? I just don't like to see a FIXME note in this file for the next release ;) Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Thomas Keller schrieb:
> I wrote:
>> openSuSE 10.3 ("Microsoft-Linux") compiled as well with system libraries:
>>
>> $ ./mtn version --full
>>~/private/monotone
>> monotone 0.43dev (base revision: 77ef9a2989aae5e9ad7844c1d30c759118c68ed5)
>> Running on : Linux 2.6.22.18-0.2-default #1 SMP 2008-06-09
>> 13:53:20 +0200 x86_64
>> C++ compiler: GNU C++ version 4.2.1 (SUSE Linux)
>> C++ standard library: GNU libstdc++ version 20070724
>> Boost version : 1_33_1
>> SQLite version : 3.4.1 (compiled against 3.4.1)
>
> Testsuite is passing except for one test, "database_dump_load". This
> fails with an SQLite error
>
> "String or BLOB exceeded size limit"
>
> The string which should be loaded was 2.109.198 bytes large, so roughly
> 470 times smaller than the default SQLITE_MAX_LENGTH limit [1]. I'm
> still investigating this issue.
I'm clueless on this error. I've downloaded the source rpm of the used
sqlite-3.4.1-14 package I'm using above and checked the configure lines
in the specfile; SQLITE_MAX_LENGTH was nowhere applied there. I checked
the default sources of 3.4.1 and the limit was 1.000.000.000 there
already (so no, no smaller value in earlier versions). I checked the
patches the openSuSE guys apply on the upstream sources, but no change
there either. I applied their patches to our intree version of sqlite
(3.4.1 as well), compiled and run the specific test, and the test
succeeds. I grep'd over monotone's source code (nvm and nvm.stripped)
but this particular define was nowhere set / overwritten.
So, yeah, I have no idea where this error comes from. Any idea?
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
I wrote:
> openSuSE 10.3 ("Microsoft-Linux") compiled as well with system libraries:
>
> $ ./mtn version --full
>~/private/monotone
> monotone 0.43dev (base revision: 77ef9a2989aae5e9ad7844c1d30c759118c68ed5)
> Running on : Linux 2.6.22.18-0.2-default #1 SMP 2008-06-09
> 13:53:20 +0200 x86_64
> C++ compiler: GNU C++ version 4.2.1 (SUSE Linux)
> C++ standard library: GNU libstdc++ version 20070724
> Boost version : 1_33_1
> SQLite version : 3.4.1 (compiled against 3.4.1)
Testsuite is passing except for one test, "database_dump_load". This
fails with an SQLite error
"String or BLOB exceeded size limit"
The string which should be loaded was 2.109.198 bytes large, so roughly
470 times smaller than the default SQLITE_MAX_LENGTH limit [1]. I'm
still investigating this issue.
Thomas.
[1] http://www.sqlite.org/limits.html
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Markus Wanner schrieb:
> Hi,
>
> the list of systems on which nvm.stripped has reportedly compiled fine
> grows, thanks to Lapo, oxygene, Stephen, Thomas K., Thomas M. and others
> trying it.
>
> The list now consists of:
>
> * Debian (since etch)
> * Ubuntu (since at least hardy)
> * Fedora 10
> * FreeBSD 6.4, 7.0 and 7.1
> * Windows/Cygwin
> * Gentoo 2008 (hardened)
> * MacOS X (with MacPorts)
openSuSE 10.3 ("Microsoft-Linux") compiled as well with system libraries:
$ ./mtn version --full
~/private/monotone
monotone 0.43dev (base revision: 77ef9a2989aae5e9ad7844c1d30c759118c68ed5)
Running on : Linux 2.6.22.18-0.2-default #1 SMP 2008-06-09
13:53:20 +0200 x86_64
C++ compiler: GNU C++ version 4.2.1 (SUSE Linux)
C++ standard library: GNU libstdc++ version 20070724
Boost version : 1_33_1
SQLite version : 3.4.1 (compiled against 3.4.1)
Lua version : Lua 5.1
PCRE version: 7.2 2007-06-19 (compiled against 7.2)
Botan version : 1.6.3 (compiled against 1.6.3)
Changes since base revision:
unknown
I cannot check newer versions (11.0, 11.1) since I don't have local
access to them, but I guess they'll compile as well.
`make check` is running currently on 10.3 and hasn't reported anything
so far.
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, I've just run through the testsuite with mtn compiled against an up to date sqlite 3.6.10 (released Jan 15th). All tests succeed. > monotone 0.43dev (base revision: 2d8426478d56750e764a5ce552ba3ce7c22acb0a) > Running on : Linux 2.6.26-1-686 #1 SMP Thu Jan 1 02:26:25 UTC 2009 > i686 > C++ compiler: GNU C++ version 4.3.2 > C++ standard library: GNU libstdc++ version 20080905 > Boost version : 1_34_1 > SQLite version : 3.6.10 (compiled against 3.6.10) > Lua version : Lua 5.1 > PCRE version: 7.6 2008-01-28 (compiled against 7.6) > Botan version : 1.8.1 (compiled against 1.8.1) However, I'm still having troubles with Solaris. Maybe mostly due to my lack of understanding of that system, though. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Markus Wanner writes: > Hi, > > Stephen Leake wrote: >> I have a patch for m4/pcre.m4 that fixes a similar problem on Win32 >> (it will show up on any system that doesn't have pkg-config). >> ac_link uses CPPFLAGS, _not_ CFLAGS. try specifying CPPFLAGS on the >> configure command line. > > Oh, yeah, thanks for that hint. Specifying CPPFLAGS on Solaris did the > trick. > > However, CFLAGS_LUA is certainly inappropriate within m4/pcre.m4. Hmm. I think you mean LUA_CFLAGS; yes, that is a cut-paste-forget-to-edit error. > I've read the autoconf manual and figured, that all our > AC_PREPROC_IFELSE and AC_LANG_PROGRAM calls use C++, as we set > AC_LANG([C++]). Thus all CFLAGS are simply ignored. I've cleaned up that > mess (rev 2d842647..), we now have: > > PCRE_CPPFLAGS > LUA_CPPFLAGS > IDNA_CPPFLAGS > SQLITE3_CPPFLAGS > > (and no more *_CFLAGS) That sounds good. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, Stephen Leake wrote: > I have a patch for m4/pcre.m4 that fixes a similar problem on Win32 > (it will show up on any system that doesn't have pkg-config). > ac_link uses CPPFLAGS, _not_ CFLAGS. try specifying CPPFLAGS on the > configure command line. Oh, yeah, thanks for that hint. Specifying CPPFLAGS on Solaris did the trick. However, CFLAGS_LUA is certainly inappropriate within m4/pcre.m4. I've read the autoconf manual and figured, that all our AC_PREPROC_IFELSE and AC_LANG_PROGRAM calls use C++, as we set AC_LANG([C++]). Thus all CFLAGS are simply ignored. I've cleaned up that mess (rev 2d842647..), we now have: PCRE_CPPFLAGS LUA_CPPFLAGS IDNA_CPPFLAGS SQLITE3_CPPFLAGS (and no more *_CFLAGS) However, we do not currently respect BOTAN_CPPFLAGS or BOTAN_LIBS, it seems. m4/botan.m4 simply overrides them. Specifying global CPPFLAGS should work, though. > I was thinking we should split INSTALL into separate files > (INSTALL.windows_mingw, etc), but let's see how big it gets first. Yes, that's a good idea, IMO. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, Thomas Moschny wrote: > Zack Weinberg wrote: >> I'd prefer not to drop the minimum version below the most recent point >> at which an exploitable crasher bug was fixed, which (according to >> pcre's NEWS file) was 7.6. There probably isn't an attack vector with >> our usage but I can't prove it so I'd rather be safe. >> >> (Can you find out if FC9 backported those fixes?) > > The pcre package in F9 has a backported fix for CVE-2008-0674, and also > a fix for the more recent CVE-2008-2371 problem. Hm.. so.. what's the way to go here? I'd propose leaving our own minimum requirement at 7.6 and advice to Fedora 9 packagers to drop it to 7.3 on their own (simply by patching pcrewrapper.hh). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, Thomas Moschny wrote: > A Fedora botan package is on the way, see > https://bugzilla.redhat.com/show_bug.cgi?id=480528. Also very nice, thank you. Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, Thomas Keller wrote: > A small note here: There is a botan package in MP, but it is currently > unusable since botan-config --libs behaves wrongly. I've created a > ticket for that [0] and hope that it is resolved until we release 0.43. As a work-around, you can provide BOTAN_LIBS and BOTAN_CPPFLAGS to monotone's configure. > Anyways, this was the past, I now plan to take over the maintenance of > the package now that there are a couple of dependencies which will > probably make it a bit harder to quickly create (static) builds. Very cool, thanks! Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Zack Weinberg wrote: > I'd prefer not to drop the minimum version below the most recent point > at which an exploitable crasher bug was fixed, which (according to > pcre's NEWS file) was 7.6. There probably isn't an attack vector with > our usage but I can't prove it so I'd rather be safe. > > (Can you find out if FC9 backported those fixes?) The pcre package in F9 has a backported fix for CVE-2008-0674, and also a fix for the more recent CVE-2008-2371 problem. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Hi, thanks for your efforts on the MinGW build, very nice. Stephen Leake wrote: > Instructions for MinGW for monotone bundled are in > monotone.web/wiki/Building/Windows/MinGW.mdwn; 137 lines. Adding the > info for stripped at a similar level of detail will take about another > 50 lines. > > Does that make it worth a separate file? Hm.. I'd even strip down the explanation in the INSTALL file. Splitting the MinGW page on the wiki doesn't make much sense to me, because landing nvm.stripped will supersede the 'old' variant. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Markus Wanner schrieb: > Hi, > > the list of systems on which nvm.stripped has reportedly compiled fine > grows, thanks to Lapo, oxygene, Stephen, Thomas K., Thomas M. and others > trying it. > > The list now consists of: [...] > > * MacOS X (with MacPorts) A small note here: There is a botan package in MP, but it is currently unusable since botan-config --libs behaves wrongly. I've created a ticket for that [0] and hope that it is resolved until we release 0.43. The monotone package in MP is currently unmaintained and still on 0.41; I refused to take over the package in the past, mainly because of the lack of interest (I used the native installer msh provides) and also because the MP version depends on boost (and compiling boost takes a while, since I can't tell it to "just download it and use the headers"). Anyways, this was the past, I now plan to take over the maintenance of the package now that there are a couple of dependencies which will probably make it a bit harder to quickly create (static) builds. Thomas. [0] http://trac.macports.org/ticket/18074 -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Markus Wanner wrote: > Fedora 9 doesn't ship botan, either. I compiled from source, through the > project website you can also find RPMs for botan. A Fedora botan package is on the way, see https://bugzilla.redhat.com/show_bug.cgi?id=480528. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Stephen Leake writes: > Markus Wanner writes: >> >> I'm still fiddling with Solaris 10 with packages from opencsw.org, where >> gcc refuses to see the pcre.h header file, even though I'm providing >> necessary -I flags in CFLAGS, PCRE_CFLAGS > > I have a patch for m4/pcre.m4 that fixes a similar problem on Win32 > (it will show up on any system that doesn't have pkg-config). > ac_link uses CPPFLAGS, _not_ CFLAGS. try specifying CPPFLAGS on the > configure command line. > > I'll commit my patch after my laptop reboots. I've now committed this -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
On Sun, Jan 18, 2009 at 3:39 AM, Markus Wanner wrote: > I'd like to lower the required PCRE version as much as possible, since > Fedora 9 ships with PCRE 7.3 and RHEL 5 date back to PCRE 6.6. The unit > tests run through fine on FC9 with 7.3. I didin't test earlier PCRE > versions, though. I remember there's a '%R' syntax change in 7.6. Can > one install newer RPMs for fedora and RHEL easily? Shall we bother with > older pcre versions? I'd prefer not to drop the minimum version below the most recent point at which an exploitable crasher bug was fixed, which (according to pcre's NEWS file) was 7.6. There probably isn't an attack vector with our usage but I can't prove it so I'd rather be safe. (Can you find out if FC9 backported those fixes?) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Stephen Leake writes: > Markus Wanner writes: > >> I've updated the INSTALL document and documented as good as I can. I'm >> missing instructions for Windows/Cygwin. Lapo? > > I can provide MinGW. It may be rather long, depending on detail. I > guess we can assume a competent developer, not a complete newbie. > > I was thinking we should split INSTALL into separate files > (INSTALL.windows_mingw, etc), but let's see how big it gets first. Instructions for MinGW for monotone bundled are in monotone.web/wiki/Building/Windows/MinGW.mdwn; 137 lines. Adding the info for stripped at a similar level of detail will take about another 50 lines. Does that make it worth a separate file? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] status of nvm.stripped
Markus Wanner writes: > Stephen Leake is trying a MinGW variant. This has now successfully configured, compiled, linked, and started running tests. But then my laptop ran out of power (I mistakenly switched of the power strip), and I can't restart untill I get back to work (it _must_ be on the domain network to survive a restart! Just amazing). More later today (I have to go in to work for another reason). > There are only few outstanding issues: > > I'm still fiddling with Solaris 10 with packages from opencsw.org, where > gcc refuses to see the pcre.h header file, even though I'm providing > necessary -I flags in CFLAGS, PCRE_CFLAGS I have a patch for m4/pcre.m4 that fixes a similar problem on Win32 (it will show up on any system that doesn't have pkg-config). ac_link uses CPPFLAGS, _not_ CFLAGS. try specifying CPPFLAGS on the configure command line. I'll commit my patch after my laptop reboots. > I've updated the INSTALL document and documented as good as I can. I'm > missing instructions for Windows/Cygwin. Lapo? I can provide MinGW. It may be rather long, depending on detail. I guess we can assume a competent developer, not a complete newbie. I was thinking we should split INSTALL into separate files (INSTALL.windows_mingw, etc), but let's see how big it gets first. I'll add instructions for what's working now, then try to get pkg-config working (that should simplify some things). -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] status of nvm.stripped
Hi, the list of systems on which nvm.stripped has reportedly compiled fine grows, thanks to Lapo, oxygene, Stephen, Thomas K., Thomas M. and others trying it. The list now consists of: * Debian (since etch) * Ubuntu (since at least hardy) * Fedora 10 * FreeBSD 6.4, 7.0 and 7.1 * Windows/Cygwin * Gentoo 2008 (hardened) * MacOS X (with MacPorts) Some notes: Debian etch doesn't ship botan, using a package from testing should work fine. I might arrange for libbotan1.8 being backported. Fedora 9 doesn't ship botan, either. I compiled from source, through the project website you can also find RPMs for botan. Stephen Leake is trying a MinGW variant. I'm still fiddling with Solaris 10. There are only few outstanding issues: I'm still fiddling with Solaris 10 with packages from opencsw.org, where gcc refuses to see the pcre.h header file, even though I'm providing necessary -I flags in CFLAGS, PCRE_CFLAGS I'd like to lower the required PCRE version as much as possible, since Fedora 9 ships with PCRE 7.3 and RHEL 5 date back to PCRE 6.6. The unit tests run through fine on FC9 with 7.3. I didin't test earlier PCRE versions, though. I remember there's a '%R' syntax change in 7.6. Can one install newer RPMs for fedora and RHEL easily? Shall we bother with older pcre versions? There has been some discussion about lua error handling. AFAICT we already do catch lua errors in nvm and "convert" them to C++ exceptions - or rather just interpret them as empty results, which is a bit scary. However, that's independent of how lua is compiled (as C++ code, as we do now, or as plain C code, as commonly shipped) and IMO shouldn't hinder the landing of nvm.stripped. Some tests fail on various platform, especially on Gentoo Hardened. I don't think this is related to stripped, but haven't tested. I've updated the INSTALL document and documented as good as I can. I'm missing instructions for Windows/Cygwin. Lapo? Any outstanding platforms you absolutely want to have supported? Comments? Regards Markus Wanner A note more to myself: remember to update nvm.debian-diff with nvm.stripped related changes: mtn: propagating net.venge.monotone -> net.venge.monotone.stripped mtn: [left] 3ed44e41b6047258d7d471ceefc250f5d9962027 mtn: [right] 895209e91afa299bd3069b6f4e8563996634b25a mtn: warning: Content changes to the file 'debian/control' mtn: warning: will be ignored during this merge as the file has been mtn: warning: removed on one side of the merge. Affected revisions include: mtn: warning: Revision: 4c625e162bf17c69406de23482187313dafd29cd mtn: [merged] c3a9ad42a6bbbcea3cf7894a388abee19886525a ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
Hi, Stephen Leake wrote: > If you are refering to the conflicts resolution stuff in > nvm.resolve_conflicts, that has already been merged into main. Oh, I missed that. Sorry for the noise, then. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
Markus Wanner writes: > Or review > Stephen Leake's work and land that. If you are refering to the conflicts resolution stuff in nvm.resolve_conflicts, that has already been merged into main. That is _not_ the suture stuff in nvm.automate_show_conflict; that work is on hold indefinitely (ie, until I run into a situation that really needs it). -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
Hi, Thomas Moschny wrote: > Totally agree. I agree as well. However, we currently have absolutely no coverage for any library version. WRT library version checking: it does not make sense to state that we only support botan 1.8.0 (and not 1.8.1 or 1.8.2). The branch already features extensive static as well as dynamic version checking and refuses to work with botan 1.9.x, for example. > Are we (when combining different versions of the used libraries) to > expect subtle bugs that eat peoples databases with no one noticing? Hopefully not, because the used library versions are expected to be backwards compatible. But theoretically possible, yes. > I guess most problems will rather arise at compile time or when running > the test suite. And distributions should run the test suite before > shipping their builds to the end user. For the Fedora package we surely > do that. That does not help much. Any of the libraries could get upgraded without having to repackage or even recompile monotone. So a mtn compiled against botan 1.8.0 (hopefully) runs with botan 1.8.3 (once released) without ever having run the test suite. > So, I'm in favor of merging this branch earlier rather than later, so > maybe very soon after releasing 0.42. Not much happened on that branch since just after 0.41. What's the reasoning for landing it now? Don't get me wrong, I'm absolutely for this change. However, it currently needs porting to and testing on different platforms, not landing. (And no, I don't believe that landing gets us more time to do this. It's only hindering us from releasing 0.43, if we didn't get around doing it.) Please rather (re)consider landing nvm.dates (and then nvm.dates.statistics as well), which are IMO ready to land. Or review Stephen Leake's work and land that. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
Thomas Keller wrote: The other (lazy) way would be to define a list of external libraries with which we know the build works (i.e. because we've tested them) and leave everything else to the downstream packagers. We receive bug reports and incorporate their fixes for the next release. This just became a rather small open source project, I don't think people have ressources to additionally check if monotone builds and behaves correct with all seven boost versions, three botans, two luas and whatever. Totally agree. Are we (when combining different versions of the used libraries) to expect subtle bugs that eat peoples databases with no one noticing? I guess most problems will rather arise at compile time or when running the test suite. And distributions should run the test suite before shipping their builds to the end user. For the Fedora package we surely do that. So, I'm in favor of merging this branch earlier rather than later, so maybe very soon after releasing 0.42. - Thomas ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
Markus Wanner schrieb: > Hi, > > Thomas Keller wrote: >> Understood - then please merge it in after 0.42 is released. > > I absolutely agree with Zack, that merging just *after* a release is the > way to go. But please do not merge, before further testing on various > platforms. We can do that before landing it on mainline. > > I've set up some virtual machines, which I intend to use as buildbots, > but didn't get around installing all the required libraries and tools. > > Another issue that came up is, that we'd have to test against various > versions of the dependent libraries. I'm not sure how much coverage we > can really achieve with reasonable efforts. The other (lazy) way would be to define a list of external libraries with which we know the build works (i.e. because we've tested them) and leave everything else to the downstream packagers. We receive bug reports and incorporate their fixes for the next release. This just became a rather small open source project, I don't think people have ressources to additionally check if monotone builds and behaves correct with all seven boost versions, three botans, two luas and whatever. Hell, we don't even have more than half a dozen *working* general buildbots to test different *platforms* for one and the same code... Of course you might correct me here and you're free to provide VMs for automated testing. Richard will happily accept them! Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
Hi, Thomas Keller wrote: > Understood - then please merge it in after 0.42 is released. I absolutely agree with Zack, that merging just *after* a release is the way to go. But please do not merge, before further testing on various platforms. We can do that before landing it on mainline. I've set up some virtual machines, which I intend to use as buildbots, but didn't get around installing all the required libraries and tools. Another issue that came up is, that we'd have to test against various versions of the dependent libraries. I'm not sure how much coverage we can really achieve with reasonable efforts. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
Thomas Keller writes: > Whats the status of this branch? Would people like to see this in > mainline for 0.42 or is it not yet ready? It is _not_ tested on Windows MinGW or Cygwin, to my knowledge. In addition, we need detailed install instructions for MinGW, since that doesn't have a packaging tool that supports dependencies. I've been meaning to do that, but round toits are in short supply. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
Zack Weinberg schrieb: > On Sun, Dec 14, 2008 at 3:48 PM, Thomas Keller wrote: >> Whats the status of this branch? Would people like to see this in >> mainline for 0.42 or is it not yet ready? > > IMO even if it is ready, a change of that magnitude should not be > landed immediately before a release; ideally it would land right > *after* a release so we have plenty of time for wider testing of dev > builds to find problems. Understood - then please merge it in after 0.42 is released. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
On Mon, Dec 15, 2008 at 12:48:13AM +0100, Thomas Keller wrote:
>
> Whats the status of this branch? Would people like to see this in
> mainline for 0.42 or is it not yet ready?
I asked Markus about the status a day or two ago, he indicated he felt
it was pretty much working but had not been sufficiently tested yet.
I have been using nvm.stripped as /usr/local/bin/mtn on my desktop
(Gentoo/amd64) for a week or so with no problems. Test suite also
looks OK on this platform.
Building it on FreeBSD 7.0/amd64 shows some snags:
Lua is installed into /usr/local/{include,lib}/lua51 which is not
searched by default. Unfortunately FreeBSD 7.0 does not seem to
include pkg-config info for lua (argh), so this does not get picked up
and autoconf dies as it cannot find Lua. Setting CPPFLAGS, CFLAGS, and
LDFLAGS to search these directories before running configure makes
things happy.
FreeBSD 7.0 packages PCRE 7.4, which is apparently too old. I
installed PCRE 7.8 from source. (FreeBSD 7.1 has PCRE 7.7.something so
this should not be a problem with future releases)
FreeBSD's make is unhappy with the Makefile:
$ make
Error expanding embedded variable
(Yes that is really all it tells me, no line number or anything). GNU
make works fine. I haven't checked if this is specific to nvm.stripped
or not.
Once built:
$ ./mtn version --full
monotone 0.41 (base revision: 0d3abccd30a68d30f70dd35e3f8acf6a49f3698c)
Running on : FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24
10:35:36 UTC 2008
r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
C++ compiler: GNU C++ version 4.2.1 20070719 [FreeBSD]
C++ standard library: GNU libstdc++ version 20070719
Boost version : 1_34_1
SQLite version : 3.4.1 (compiled against 3.4.1)
Lua version : Lua 5.1
PCRE version: 7.8 2008-09-05 (compiled against 7.8)
Botan version : 1.8.0 (compiled against 1.8.0)
Changes since base revision:
format_version "1"
new_manifest [fc676821822bdcba693d9823013d607ce40bd4cd]
old_revision [0d3abccd30a68d30f70dd35e3f8acf6a49f3698c]
With this binary I see one test failure, database_dump_load line 23.
Maybe a SQLite issue?
I think nvm.stripped is the right thing, looking long-term, but Zack's
suggestion of landing it after 0.42 for the widest possible testing to
work out the kinks probably makes more sense than merging it and then
immediately releasing.
-Jack
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Status of nvm.stripped
On Sun, Dec 14, 2008 at 3:48 PM, Thomas Keller wrote: > > Whats the status of this branch? Would people like to see this in > mainline for 0.42 or is it not yet ready? IMO even if it is ready, a change of that magnitude should not be landed immediately before a release; ideally it would land right *after* a release so we have plenty of time for wider testing of dev builds to find problems. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Status of nvm.stripped
Whats the status of this branch? Would people like to see this in mainline for 0.42 or is it not yet ready? Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
