Closed sydb closed 1 year ago
This post is just a log of my adventures trying to find rnv
.
I originally got it from what I thought of as David Ashen’s page. The version you get from that page now is 1.7.8. (I think I got 1.6 or 1.7.0 originally, but who cares.)
Interestingly, the readme.txt file says, under “Acknowledgements”:
Sebastian Rahtz encouraged me to continue working on RNV since the
first release, and has helped me to improve it on more than one
occasion.
Anyway, the readme.txt file ends with “Visit http://davidashen.net/ for news and downloads.” That page sends the user to https://dtolpin.github.io/, which is the (non-personal) blog of one David Tolpin, an ex-CS professor from Israel.
On more careful reading, I believe “Davidashen” is a username or nickname for David Tolpin. E.g., the license.txt file starts with “Copyright (c) 2003, 2004 David Tolpin, Davidashen”. And the file tools/fo.rnc has the comment “Converted to Relax NG Compact Syntax <sic>
using</sic>
by David Tolpin dvd@davidashen.net using Trang, http://relaxng.org/”.
In any case, Mr. Tolpin’s blog does not mention rnv, but it does mention that his GitHub username is dtolpin. Going to his GitHub page I find there is indeed an RNV repo, which README.md says (essentially) “don’t use this, go to Sebastian Pipping’s version instead”. If, instead of going to Mr. Pipping’s version you clone Mr. Tolpin’s version, you get version 1.8.0.
But moving to Mr. Pipping’s version, I was unable to compile it, but it looks like it claims it is version 1.7.7, because the file build_vms.com has “#define RNV_VERSION "1.7.7"” in it. On the other hand, the file packages/debian/rnv/debian/changelog implies the latest version is 1.7.11-1 (although the ultimate -1 will be for Debian, I am pretty sure).
BTW, I tried sudo apt install rnv
on my Ubuntu machine — no such luck.
Interestingly, the file packages/debian/rnv/debian/copyright has the string http://downloads.sourceforge.net/sourceforge/rnv/rnv-1.7.10.tar.gz in it. I downloaded that, and the file build_vms.com has “#define RNV_VERSION "1.7.7"” in it, but the files configure and configure.in say 1.7.10.
I think it is Mr. Pipping’s version that has a /tmp/rnv/tst/dt/ directory which has TEI test files in it.
Just noting that @HelenaSabel and I are planning to test this to see if the version of rnv in Docker gives us similar troubles!
@sydb, can you tell me what you're running that throws the error? I've got the Pipping version of rnv built. There doesn't appear to have been a release in a very long time, but there are recent updates to the Pipping version (which claims to be 1.7.11 fwiw).
Test files on today’s meeting notes, @hcayless. But will duplicate them here in an hour or two.
Or four (hours :-). booleans_to_test.tgz
Oh, I just realized @hcayless you may be asking about what in the build causes the problem, rather than for a test file to demonstrate the problem. In Test/ I have added a few elements from att.declarable which have @default
. One of those attributes (in detest.xml /TEI/teiHeader/fileDesc
) has the value "1". That attribute is considered invalid by rnv 1.8.0 and valid by most everybody else. (Except oXygen also considers it invalid when I do not explicitly associate a schema. So I wish I knew what schema it is using under the hood.)
So we could, of course, unblock #1981 by changing that "1" to "true".
My instinct here is we should be using a 1.7.x version in our docker and on Jenkins, etc., not the 1.8.0 version which Mr. Tolpin says not to use. Not sure which 1.7.x, though.
Hi!
Regarding the two Git repositories:
From what I can see in https://github.com/dtolpin/RNV master
is effectively RNV 1.7.8 code plus bug fix https://github.com/dtolpin/RNV/commit/ade71fffd97e252bf3e6d3f7651cbf6ac8c98860 plus branding as 1.8.0 plus a new readme and no version control history prior to 1.7.8.
https://github.com/hartwork/rnv master
is the Subversion history from https://sourceforge.net/p/rnv/code/HEAD/tree/ that ran until 1.7.11 converted to Git plus post-1.7.11 fixes including the (same) bugfix at https://github.com/hartwork/rnv/commit/eb769bce878343b432f6425780f3e4249fb22366 plus Debian packaging plus a simple CI.
I've updated the teic/teidev-docker image to build https://github.com/hartwork/rnv and it seems to me to behave correctly in that it flags 3 errors in @sydb's sample XML--same as oXygen's build in validation. make test
is still erroring out, however. Possibly a busted expected result? But I haven't got time tonight to debug further.
I think that was a temporary glitch. make test
runs fine now with the latest teic/teidev-docker
build. You will need to pull the latest image, using docker image pull teic/teidev-docker
. If the image used by Jenkins also has a broken rnv, that will need to be updated too.
The TEIC Jenkins image is building RNV from dtolpin, see https://github.com/TEIC/Jenkins/blob/6e0d5293095b3164cb4ff984bdd2dd90eaf75bd5/Dockerfile#L34-L37
So, this needs to be changed, too?
On my Jenkins the rnv version is 1.8.0, and I'm not seeing any build failures.
On my Jenkins the rnv version is 1.8.0, and I'm not seeing any build failures.
Yes, I think there's been yet another issue. The Dockerfile was building rnv in a separate build step and with some current (Debian) base image update (I assume) that failed due to missing/changed libraries. The error message was: rnv: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by rnv)
see https://jenkins.tei-c.org/view/TEI%20dev/job/TEIP5-Test-dev/1139/parsed_console/
I have modified the Dockerfile in https://github.com/TEIC/Jenkins/commit/f6063a1f1d18a444e6c37042008f090e0e5fe272 and now it seems to work again
The program
rnv
is a Relax NG vvalidator that we use in the build process. (It validates an XML instance against a RelaxNG compact syntax schema.)The problem is that the version of
rnv
our docker container uses (or at least, the container I was using — don’t know if it is @peterstadler’s or @hcayless’) incorrectly flags "1" as an invalid xsd:boolean. It says it is version 1.8.0The version on my computers says it is 1.7.8, and does not have this problem.