On Tue, Apr 13, 2021 at 9:51 PM Cédric Champeau <cedric.champ...@gmail.com> wrote:
> > > Le mar. 13 avr. 2021 à 13:04, Paul King <pa...@asert.com.au> a écrit : > >> We don't use the keys file (being binary) for the source build. I guess >> we could offer a way to bootstrap that too like we do for gradlew. Then >> users could choose if they wanted to do the build with or without. >> > > To me it feels a bit strange not to use this file because it's binary, > when we also happily use images... which are binary too :) Anyway the > format is a regular GPG keyring so it's easy to figure out what's inside. > It's not a common practice at the ASF to include such a file in the build yet but we could make a case for it I guess. > What would be good from the Gradle side is a better way to flush and >> restart verification when flakey key servers are stumbled across because >> there does seem to be some caching once the corruption occurs. >> > > This is already the case: Gradle tries different key servers and > exponential backoff. When ultimately it fails there's nothing much we can > do. An option is to setup your own key server mirror. > > >> Or perhaps there is a way I haven't discovered yet. >> >> Cheers, Paul. >> >> >> On Tue, Apr 13, 2021 at 8:00 PM Cédric Champeau < >> cedric.champ...@gmail.com> wrote: >> >>> Technically it's not Gradle's dependency verification which is flaky, >>> it's the key servers. That's why you must, from time to time, update the >>> local keyring, using `--export-keys` as explained in >>> https://docs.gradle.org/current/userguide/dependency_verification.html#sec:local-keyring >>> >>> Then the builds wouldn't have to ping the remote servers on every build, >>> because the keys would be found in the local keystore. >>> >>> Le mar. 13 avr. 2021 à 11:56, Paul King <pa...@asert.com.au> a écrit : >>> >>>> >>>> Oops, forgot the mailing list. >>>> >>>> ---------- Forwarded message --------- >>>> From: Paul King <pa...@asert.com.au> >>>> Date: Tue, Apr 13, 2021 at 7:56 PM >>>> Subject: Re: [VOTE] Release Apache Groovy 4.0.0-alpha-3 >>>> To: Guillaume Laforge <glafo...@gmail.com> >>>> >>>> >>>> Gradle's dependency verification (incubating feature) does seem to be a >>>> little flakey sometimes. Hopefully it will improve over time. I have >>>> numerous other environments where that error doesn't show but Daniel had a >>>> similar but different error. Regenerating the verification metadata didn't >>>> change anything for him which indicates the metadata is probably okay as >>>> is. I'd suggest running with dependency verification set to lenient or off >>>> and see if that helps: >>>> >>>> >>>> https://docs.gradle.org/current/userguide/dependency_verification.html#sec:disabling-verification >>>> >>>> Cheers, Paul. >>>> >>>> >>>> On Tue, Apr 13, 2021 at 6:51 PM Guillaume Laforge <glafo...@gmail.com> >>>> wrote: >>>> >>>>> I got a test failure (on Java 11): >>>>> >>>>> Execution failed for task ':groovy-testng:test'. >>>>> >>>>> > Dependency verification failed for configuration >>>>> ':groovy-testng:testRuntimeClasspath' >>>>> >>>>> One artifact failed verification: jcommander-1.78.jar >>>>> (com.beust:jcommander:1.78) from repository MavenRepo >>>>> >>>>> This can indicate that a dependency has been compromised. Please >>>>> carefully verify the signatures and checksums. >>>>> >>>>> Opening the report tells me: >>>>> >>>>> configuration ':groovy-testng:testRuntimeClasspath' 1 error >>>>> <#m_6355379836185312252_m_-7459414092519895439_m_-7713695666752602976_m_8153075787925662056_m_-2671871127063042544_m_5361968448074506625_m_-8064841157445032086_> >>>>> MODULEARTIFACTPROBLEM(S) >>>>> com.beust:jcommander:1.78 >>>>> jcommander-1.78.jar (.asc) >>>>> >>>>> Key 22e44ac0622b91c3 (not found) couldn't be found in any key server >>>>> so verification couldn't be performed >>>>> >>>>> >>>>> On Tue, Apr 13, 2021 at 6:58 AM Søren Berg Glasius <soe...@glasius.dk> >>>>> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> Med venlig hilsen / Best regards >>>>>> >>>>>> Søren Berg Glasius >>>>>> >>>>>> Sent from my phone, thus brief >>>>>> >>>>>> On Tue, Apr 13, 2021, 04:56 Paul King <pa...@asert.com.au> wrote: >>>>>> >>>>>>> Dear development community, >>>>>>> >>>>>>> I am happy to start the VOTE thread for a Groovy 4.0.0-alpha-3 >>>>>>> release! >>>>>>> >>>>>>> This release includes 152 bug fixes/improvements as outlined in the >>>>>>> changelog: >>>>>>> >>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12349469 >>>>>>> >>>>>>> Tag: >>>>>>> https://gitbox.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_4_0_0_ALPHA_3 >>>>>>> Tag commit id: bdd219508feef5893372bf1b96ead893f2f2869b >>>>>>> >>>>>>> The artifacts to be voted on are located as follows (r47022). >>>>>>> Source release: >>>>>>> https://dist.apache.org/repos/dist/dev/groovy/4.0.0-alpha-3/sources >>>>>>> Convenience binaries: >>>>>>> https://dist.apache.org/repos/dist/dev/groovy/4.0.0-alpha-3/distribution >>>>>>> >>>>>>> Release artifacts are signed with a key from the following file: >>>>>>> https://dist.apache.org/repos/dist/release/groovy/KEYS >>>>>>> >>>>>>> Please vote on releasing this package as Apache Groovy 4.0.0-alpha-3. >>>>>>> >>>>>>> Reminder on ASF release approval requirements for PMC members: >>>>>>> http://www.apache.org/legal/release-policy.html#release-approval >>>>>>> Hints on validating checksums/signatures (but replace md5sum with >>>>>>> sha256sum): >>>>>>> https://www.apache.org/info/verification.html >>>>>>> >>>>>>> The vote is open for the next 72 hours and passes if a majority of >>>>>>> at least three +1 PMC votes are cast. >>>>>>> >>>>>>> [ ] +1 Release Apache Groovy 4.0.0-alpha-3 >>>>>>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok >>>>>>> [ ] -1 Do not release Apache Groovy 4.0.0-alpha-3 because... >>>>>>> >>>>>>> Here is my vote: >>>>>>> >>>>>>> +1 (binding) >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Guillaume Laforge >>>>> Apache Groovy committer >>>>> Developer Advocate @ Google Cloud Platform >>>>> >>>>> Blog: http://glaforge.appspot.com/ >>>>> Twitter: @glaforge <http://twitter.com/glaforge> >>>>> >>>>
