rnv broken?

[sydb]

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

The version on my computers says it is 1.7.8, and does not have this problem.

[sydb]

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 [email protected] 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.

[ebeshero]

Just noting that @HelenaSabel and I are planning to test this to see if the version of rnv in Docker gives us similar troubles!

[hcayless]

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

[sydb]

Test files on today’s meeting notes, @hcayless. But will duplicate them here in an hour or two.

[sydb]

Or four (hours :-).
booleans_to_test.tgz

[sydb]

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.

[hartwork]

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 dtolpin/RNV@ade71ff 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 hartwork/rnv@eb769bc plus Debian packaging plus a simple CI.

[hcayless]

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.

[hcayless]

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.

[peterstadler]

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?

[martindholmes]

On my Jenkins the rnv version is 1.8.0, and I'm not seeing any build failures.

[peterstadler]

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 TEIC/Jenkins@f6063a1 and now it seems to work again