TEIC / TEI

The Text Encoding Initiative Guidelines
https://www.tei-c.org
Other
276 stars 88 forks source link

rnv broken? #2455

Closed sydb closed 1 year ago

sydb commented 1 year ago

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

ebeshero commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

sydb commented 1 year ago

Or four (hours :-). booleans_to_test.tgz

sydb commented 1 year ago

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 commented 1 year ago

Hi!

Regarding the two Git repositories:

hcayless commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

peterstadler commented 1 year ago

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