The FAQ and creating a submission entry by hand.

[SirWumpus]

While the section A warning about rule abuse strongly suggests using mkiocccentry to create a submission tarball else run the risk of breaking Rule 17, there is no explicit rule that says one MUST use the mkiocccentry tool, correct?

If I create a .info.json by hand, then the fields mkiocccentry_version, chkentry_version, fnamchk_version, and txzchk_version in theory could be left out or empty, since no tool(s) were used. Yet the FAQ section explaining the .info.json file states...

IMPORTANT: this MUST match THIS IOCCC’s ${TOOLNAME} version, defined as ${TOOLNAME}_VERSION in soup/version.h in the mkiocccentry repo. If this is not the case your submission WILL BE rejected!

The Rules do not mandate this and the FAQ is not part of the Rules and should not make such claims. While the tools should make life easier to submit an entry, one is not bound to use them. So the tool version fields are informational at best, their requirement should be optional. Moreover the submission server (ultimately the judges) should not reject an entry based on these fields.

Similar statements are asserted for the .auth.json file.

[xexyl]

Well look at it this way. It's not like the judges can verify you use it if you do everything right. Though that's a lot of work.

And as for version requirements - there are good reasons for that I would guess (I can think of some but I haven't given them much thought beyond). Certainly I have pondered whether it should be required or not but that's another matter entirely and not one for me to decide in the end (nor does it bother me really). But if that does change it's for the next one.

But you could also fake that if you so wished but again it' s a lot more work. I guess I know what this is about and if so I can't comprehend it but it's up to you and if you fake it correctly then there's no problem really if you wish to do it that way.

Just remember you have to:

• Set the correct permissions of the files. It's not just any permission and it depends on the filename too. Directories have to be a certain permission too.
• Make sure forbidden files and directories are excluded.
• Create the long JSON files. These also have to be the correct permissions..
• Have all the fields correct (and some are complex).
• Make sure the directory and JSON files check out (there are MANY checks).
• Make sure you tar it up correctly (with correct permissions too and no UID/GID by name). There are MANY, MANY checks, possibly more than chkentry even, and some of them are the same checks in chkentry but done in ways - and it has to be different due to it acting on a tarball listing rather than a directory.

And if you want to make sure you conform to the rules you have to run various tools in between certain steps. The above are only a few of many more things they all do.

[SirWumpus]

And if you want to make sure you conform to the rules you have to run various tools in between certain steps.

Nothing in the rules about having to use the tools, only recommendations else where. Its not an onerous task, especially once the .json files have been created, maybe just a lot of reading to make sure all the points of Rule 17 are covered.

But there is question as to WHY the tools need to be listed in the .json files IF they are not required to create an entry? The submission server is going to verify the submissions anyway (trust but verify).

[xexyl]

And if you want to make sure you conform to the rules you have to run various tools in between certain steps.

Nothing in the rules about having to use the tools, only recommendations else where. Its not an onerous task, especially once the .json files have been created, maybe just a lot of reading to make sure all the points of Rule 17 are covered.

But there is question as to WHY the tools need to be listed in the .json files IF they are not required to create an entry? The submission server is going to verify the submissions anyway (trust but verify).

To that all I can say is: ask Landon. The point (I guess) is you're SUPPOSED to use it. But obviously one cannot check it that much. One can also do something like:

mkiocccentry -T /usr/bin/true -C /usr/bin/true -F /usr/bin/true 

to make all tests pass. But that's on them if they wish to risk it.

As for it not being complicated. Well maybe you have ways to go about it (wouldn't surprise me) but the tools do do a lot of checks so you might wish to use them to do so.

Anyway as for why the tool versions are in the JSON files - that's not my design. I would guess in part it's to make sure (or try to) that things were done 'correctly' but of course there is only so much that can be done. And it might not be the at all. I don't know.

[xexyl]

As for it not being complicated. Well maybe you have ways to go about it (wouldn't surprise me) but the tools do do a lot of checks so you might wish to use them to do so.

By tools here I do not mean mkiocccentry. I mean the checkers. I also left out in the list earlier the fact that the tarball has to be properly named and the directory too. For another example.