Yes, 1 for fixing some libraries El lun, 3 mar 2025 a las 16:57, James Dailey (<jdai...@apache.org>) escribió:
> I fixed a small error in my KEY in KEYS. Should be working now. > > Victor - are you planning on adding some PRs? > > On Mon, Mar 3, 2025 at 11:55 AM Ádám Sághy <adamsa...@gmail.com> wrote: > >> Hi guys, >> >> Adam, James: I am afraid something is not right around the keys and i was >> unable to verify :( >> >> Let me share my steps and findings: >> - Downloaded "apache-fineract-1.11.0-binary.tar.gz.asc” and >> "apache-fineract-1.11.0-binary.tar.gz”. >> >> Run "gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc >> apache-fineract-1.11.0-binary.tar.gz” on them gave the following: >> >> gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT >> gpg: using EDDSA key >> BD58EA9F85201ADB52CFC0444F169FF263F5F98E >> gpg: Can't check signature: No public key >> >> Run "gpg --keyserver keys.openpgp.org --recv-key >> BD58EA9F85201ADB52CFC0444F169FF263F5F98E” >> >> gpg: key 4F169FF263F5F98E: no user ID <- THIS LOOKS BAD! >> gpg: Total number processed: 1 >> >> Run "gpg --verify apache-fineract-1.11.0-binary.tar.gz.asc >> apache-fineract-1.11.0-binary.tar.gz” once ag >> gpg: Signature made Sat 1 Mar 02:06:12 2025 GMT >> gpg: using EDDSA key >> BD58EA9F85201ADB52CFC0444F169FF263F5F98E >> gpg: Can't check signature: No public key >> >> >> I have tried to import the KEYS from >> https://dist.apache.org/repos/dist/dev/fineract/KEYS but got the very >> same issue that Victor mentioned. >> >> I have taken a look on the patch that was shared by Adam Monsen, but i am >> not comfortable with that since it contains many changes compared to the >> uploaded file! >> >> Also the previous PGP keys and the one that was uploaded by James? not >> even similar in length. >> >> Are we sure the proper keys were created? >> >> Regards, >> Adam >> >> >> On 2025. Mar 3., at 17:45, VICTOR MANUEL ROMERO RODRIGUEZ < >> victor.rom...@fintecheando.mx> wrote: >> >> @Adam Monsen <amon...@mifos.org> I found that the testing on >> binaryDistTar task is taking my JVM locale (which is es-MX), so then >> changing the locale to en-US fixes it. >> >> Caused by: PlatformApiDataValidationException{errors=[The parameter >> `startDate` is invalid based on the dateFormat: *`dd MMMM yyyy` and locale: >> `en` provided*:]} >> at >> app//org.apache.fineract.portfolio.loanaccount.service.reaging.LoanReAgingValidatorTest.lambda$testValidateReAge_ShouldThrowException_WhenLoanIsNotActive$13(LoanReAgingValidatorTest.java:361) >> Caused by: java.time.format.DateTimeParseException: Text '*08 abril 2025*' >> >> >> El lun, 3 mar 2025 a las 11:36, Adam Monsen (<amon...@mifos.org>) >> escribió: >> >>> Hi Victor, thank you for helping me with this! >>> >>> Others: *we need help* *from at least two more people* to get this >>> release out the door. Please: >>> >>> 1. download the release candidate artifacts and verify their integrity >>> 2. run a build using only the source tarball and the recommended JDK >>> 3. start up a Fineract server using the war in the binary tarball >>> >>> These are just suggestions and I apologize for being brief/vague, I'm >>> looking forward to helping out with documenting and detailing this process. >>> If you have feedback on the best way to perform these steps, please share. >>> >>> Victor wrote: >>> >>>> The attached file contains the commands executed and shows checksum >>>> error verification for the KEYS file. >>> >>> >>> Good catch! I was able to reproduce this. The "invalid armor header" / >>> "cabecera de armadura inválida", "CRC error" / "Error en suma de >>> comprobación", and "[don't know]: invalid packet (ctb=40)" messages are all >>> due to *one missing newline in the last key*. I hadn't run into this >>> error previously because I think James gave me that key directly when we >>> were able to do a mini keysigning party in person and it was properly >>> formatted. But yeah, that's an invalid key there. Probably a copy/paste >>> error or something. >>> >>> I'd like to improve this KEYS file to fix the broken key, add some >>> documentation at the top, and use consistent formatting. James or Aleks, >>> will you please review, apply and commit the attached patch against >>> https://dist.apache.org/repos/dist/dev/fineract/KEYS at r71016? >>> >>> Regarding verifying the release candidate, I don't think there's much >>> value in running the srcDistTar task, but I suppose it doesn't hurt. The >>> binaryDistTar task is a bit more useful since it does build the code and >>> run some basic tests. I'm not sure exactly what failed there but I'd say >>> start with the recommended JDK version and try running the build from a >>> *very* clean environment. For example, I've found I need to sometimes >>> run `git clean -fdx` remove all of ~/.gradle to get a successful Fineract >>> build and/or test run. I think this helps get rid of cached artifacts or >>> old/bad dependencies or something. >>> >>> I wrote: >>> >>>> The help I'm seeking is for PMC members to fetch and verify these >>>> artifacts are valid, following "Step 9: Verify Distribution Staging" from >>>> the official docs (current-enough copy at >>>> https://fineract.apache.org/docs/current/ ) and >>>> https://www.apache.org/legal/release-policy.html . Additionally, my >>>> unofficial suggestions are currently living at >>>> https://github.com/meonkeys/fineract-asf-release-checklist/ (there's >>>> some overlap and it's a work in progress, but I've got some good ideas >>>> there). >>>> >>>> I'm working on updates to the docs to reflect what worked and didn't >>>> for us today. >>> >>> >>
