search

Ravenports / ravenadm

Administration tool for Ravenports
http://www.ravenports.com
ISC License
17 stars 3 forks source link

Port builds in unkindness but fails in conspiracy #17

Closed kraileth closed 4 years ago

kraileth commented 4 years ago

After (finally) updating the texlive-texmf WIP port I initially thought that I'd need to do some more tuning. This seems not to be the case (the file that I had in mind is part of texlive-bin). So I wanted to transfer the texlive-texmf port from customports to ravensource.

The port in customsource builds fine when I have it in my unkindness tree. When I move it out and put it into ravensource, I'm experiencing a strange problem however. Doing ravenadm dev generate-index works just like it always does. But by executing a ravenadm dev buildsheet . save in that directory, something breaks. Trying to generate the index afterwards leads to this message:

Failure encountered: Port_Specification.string_create.First_Element: Container is empty

Then I need to delete conspiracy and re-populate it with ravenadm update-ports to be able to continue working with ports. Since the port builds from unkindness it obviously passes ravenadm's checks. So I guess that I somehow hit an edge case here.

@jrmarino Any ideas on what's happening here?

kraileth commented 4 years ago

Adding some more info to this: Removing /var/ravenports/conspiracy/bucket_11/texlive-texmf fixes the "Container is empty" on generate-index. Also that file has 0 diff against the buildsheet created as /var/ravenports/primary/unkindness/bucket_11/texlive-texmf.

I have no clue what that "Container is empty" means, since the buildsheet must be valid or ravenadm couldn't build it from unkindness...

jrmarino commented 4 years ago

i'll have to get it on the next update. It's going to take some time to check out.

jrmarino commented 4 years ago

it's failing on the repology.json generation which is done currently with conspiracy generation. I see some culprits but don't understand how container could be empty yet.

jrmarino commented 4 years ago

Okay, so the problem is comes first of two mistakes. mistake 1) download groups "copying" and "lppl" are defined in DOWNLOAD_GROUPS but not SITES[copying] and SITES[lppl] mistake 2 is you don't set DF_INDEX= 1 2 3 I think. There might be a mistake 3 by not setting distfiles 2 and 3 to "no extract"

anyway, this needs to be caught by "ravenadm dev buildsheet" as well as guarded against during generation.

kraileth commented 4 years ago

Duh, I didn't realize this. Guess it was copied over from the texlive-bin port where you added those correctly but I probably hit an incomplete version or something. Corrected it, tested the port in conspiracy and pushed it a couple of minutes ago.

Anyway it's good that this case would at least help to further improve error checking in ravenadm. I'm going to leave the customsource version of bucket_11/texlive-texmf with the missing stuff for now in case you want to test something. If you're already done, feel free to kick it off customsource and close this issue.

And thanks for digging into it and pointing me to the solution! Next step for me is to rework texlive-bin to make the whole TeXLive distribution actually usable, but we're almost there. We'll probably be able to take this biggie off the wishlist pretty soon.

jrmarino commented 4 years ago

No, this wasn't your fault. Ravenadm should have caught it during parsing. With version 1.57, it does. Additionally, I made the json report more robust. Yes, if the parsing validation checks were there, the json report would have been fine but it doesn't hurt to fix all the possible breakages.