eprintsug / EPrintsOpenAIRE

Export to OpenAIRE (Guidelines for Literature Repositories v4) from EPrints digital repository software
GNU General Public License v3.0
5 stars 0 forks source link

checksums in epm/.epmi file don't match those in Git repo #9

Closed drn05r closed 2 hours ago

drn05r commented 19 hours ago

It looks like the checksums for lib/plugins/EPrints/Plugin/Export/OPENAIRE.pm and lib/plugins/EPrints/Plugin/Export/OPENAIRE_via_PMH.pm do not match the checksums of these files in the Git repo:

In .epm/.epmi file

b32a539c4f00c467dc5bfd23d5e49afa plugins/EPrints/Plugin/Export/OPENAIRE.pm
1ef9bce4627e27776a7914d01202bf21 plugins/EPrints/Plugin/Export/OPENAIRE_via_PMH.pm

In Git repo

4934aa595af0fb526490dd3bc71cf047  plugins/EPrints/Plugin/Export/OPENAIRE.pm
5d619d387e3de69732c2259485b599ba plugins/EPrints/Plugin/Export/OPENAIRE_via_PMH.pm

I plan to investigate what the changes are a generate new .epm/.epmi files and call this v1.0.5 if there are significant changes, as there is already a v1.0.4 on the Bazaar, which I don't want to touch beyond maybe pushing a new version to the Bazaar to supersede this.

drn05r commented 19 hours ago

This looks to be a DOS/UNIX formatting issue. I ran dos2unix on the two files from the Bazaar that had the same checksums as the .epm/.epmi file and afterwards they had the same checksum as the Git repo. As there is not functional difference, I think the easiest thing to do is update the checksums in the .epmi and .epm files and then produce a GitHub release version called v1.0.4. However, the base64 data for the file in the .epm file may not be updated to unix rather than dos format?

photomedia commented 19 hours ago

Thank you for catching that and doing this analysis of the issue. I'm glad it's "just" a DOS/UNIX formatting issue. I have to admit though, I'm still a little lost here, sorry. Would it make sense to push the Unix formatted OPENAIRE.pm and OPENAIRE_via_PMH.pm content files to GitHub to fix the issue?

drn05r commented 19 hours ago

I was seeing if I could tidying the files up by hand but that does not to be doable. So I will use EPrints Services EPM builder to generate consistent .epm and .epmi files and commit them back after revert the epm id attribute and uri used in the XML in these files.

photomedia commented 18 hours ago

Thank you for working on this. Do you think you could also speculate on what most likely happened to cause this mismatch? I ask because I would obviously want to avoid making the same mistake again.

drn05r commented 1 hour ago

@photomedia I have merged the pull request and produced a release version (v1.0.4). This makes my check happy that confirms the .epmi file checksums match does generated when running md5sums against the files themselves.