I plan on adding steps to the release documentation to mitigate this in the future including how to verify reproducibility.
At the moment I already have a PR [1] for other, unrelated updates to the release doc that I'd like to get merged first, though. Justin [1] https://github.com/apache/activemq-artemis/pull/5304 On Mon, Oct 21, 2024 at 3:59 PM Clebert Suconic <clebert.suco...@gmail.com> wrote: > I don't understand how to avoid this in the future... and how to check it? > I think we should update the RELEASE.md with steps to verify and avoid it > but I don't understand it 100%.. just that something got the wrong mask on > Justin's env causing a reproducing issue. > > Clebert Suconic > > > On Mon, Oct 21, 2024 at 3:05 PM Justin Bertram <jbert...@apache.org> > wrote: > > > I'm cancelling this vote due to the build-reproducibility issue that > Robbie > > outlined. > > > > > > Justin > > > > On Mon, Oct 21, 2024 at 1:58 PM Justin Bertram <jbert...@apache.org> > > wrote: > > > > > For the sake of clarity and consistency I'm going to cancel this vote, > > > re-spin to fix the build-repeatability issue, and send another vote. > > > > > > Thanks for testing this, Robbie! > > > > > > > > > Justin > > > > > > On Mon, Oct 21, 2024 at 9:39 AM Robbie Gemmell < > robbie.gemm...@gmail.com > > > > > > wrote: > > > > > >> As an explainer, the cause for the reproducibility check failing looks > > >> to be from a difference in umask between Justin's env and those used > > >> for previous releases and in turn the Reproducible Central buildspec > > >> used to verify the reproducibility. > > >> > > >> On previous systems that did the release, a umask of [0]022 was in > > >> effect. On Justins, a umask of [0]002 was in effect. When I changed > > >> umask to [0]002 I was then able to do a 100% reproduction of the > > >> build. > > >> > > >> I'm not yet clear on why, but for the 3 war files in the build, the > > >> permissions on the embedded maven detail files (but none of the actual > > >> content files) are influenced by the umask: > > >> META-INF/maven/<groupId>/<artifact-id>/pom.xml > > >> META-INF/maven/<groupId>/<artifact-id>/pom.properties > > >> > > >> The war files contents then in turn influence the binary assembly and > > >> related checksum files, giving a total of 7 differences in the overall > > >> build. None of the 'actual content' differs as such, just the > > >> permissions, the metadata for which throws off the overall assembly. > > >> > > >> The same type of generated files are also embedded in all the jar > > >> files, but are not influenced by the differing umasks so the jars all > > >> came out the same regardless. > > >> > > >> We could either proceed and try to update the buildspec at > > >> Reproducible Central to compensate (and then need to update it again > > >> to switch back in future if we make things consistent). Or we could > > >> redeploy the build to make this consistent with prior releases, the > > >> binary assembly and sig+checksum would get updated, as would the sig > > >> for the source release (embedded timestamp) though not the source > > >> archive itself. > > >> > > >> Thoughts, Justin? > > >> > > >> On Fri, 18 Oct 2024 at 17:26, Robbie Gemmell < > robbie.gemm...@gmail.com> > > >> wrote: > > >> > > > >> > -1, for now at least. > > >> > > > >> > The deployed convenience binaries failed a reproducibility check, > even > > >> > though all the sub-content in them ultimately seems to be the same > as > > >> > in the rebuild. A permissions difference in a few modules (the 3 > > >> > console war files) META-INF files seems to be the cause, which in > turn > > >> > rippled through to the binary assembly archives as a whole. > > >> > > > >> > I'd like to try some redeployments on Monday to see whether we could > > >> > resolve the issue, or at least isolate a reason/env-difference that > > >> > prompts it. > > >> > > > >> > Note -1's are not a veto on releases, and even with my -1 it still > > >> > meets the criteria necessary to proceed, i.e can currently still be > > >> > released as-is if so desired. > > >> > > > >> > I checked things over as follows: > > >> > - Verified the signature + checksum files. > > >> > - Checked for LICENCE + NOTICE files in the archives. > > >> > - Checked licence headers in the source archive by running: > > >> > "mvn apache-rat:check" > > >> > - Ran the Qpid JMS 2.6.1 HelloWorld against a broker from the binary > > >> > archive on JDK 17. > > >> > - Ran the source build and the AMQP integration tests on JDK 17 > with: > > >> > "mvn clean install -DskipTests && cd tests/integration-tests/ && > mvn > > >> > -Ptests -Dtest=org.apache.activemq.artemis.tests.integration.amqp.** > > >> > test" > > >> > - Verified the build reproducibility using the tooling at > Reproducible > > >> > Central, which failed as per above. > > >> > > > >> > Robbie > > >> > > > >> > On Wed, 16 Oct 2024 at 17:13, Justin Bertram <jbert...@apache.org> > > >> wrote: > > >> > > > > >> > > I would like to propose an Apache ActiveMQ Artemis 2.38.0 release. > > >> > > > > >> > > Highlights include: > > >> > > > > >> > > - WebSocket compression is now supported. This compression can be > > used > > >> > > transparently for AMQP, STOMP, or MQTT when communication is over > > >> > > WebSockets. > > >> > > - The ActiveMQServerMessagePlugin now has a messageMoved() > callback. > > >> > > - Core bridge configuration now supports client-id which will make > > it > > >> much > > >> > > easier to identify bridge connections on remote brokers. > > >> > > - The consumer CLI command now supports consuming messages > > "forever." > > >> > > - The authentication & authorization caches now have detailed > debug > > >> logging. > > >> > > - There’s been a handful of updates to broker management > including: > > >> > > - The documentation has been improved with more examples for > > >> Jolokia > > >> > > and a new sub-section on management method option syntax. > > >> > > - It’s now possible to pass empty "options" to the management > > >> methods > > >> > > that accept them. > > >> > > - The management methods which return paged results can now > > >> return all > > >> > > the results together by specifying -1 for either the page or the > > >> pageSize. > > >> > > - The management method option syntax now supports the > > NOT_EQUALS > > >> > > operator for greater flexibility with filtering results of > > management > > >> > > operations. > > >> > > - Configuration for diverts created via management can now be > > >> done via > > >> > > JSON. > > >> > > > > >> > > The release notes can be found here: > > >> > > > > >> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315920&version=12355013 > > >> > > > > >> > > Ths git commit report is here: > > >> > > > > >> > > > https://activemq.apache.org/components/artemis/download/commit-report-2.38.0 > > >> > > > > >> > > Source and binary distributions can be found here: > > >> > > > > >> > > https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.38.0/ > > >> > > > > >> > > The Maven staging repository is here: > > >> > > > > >> > > > https://repository.apache.org/content/repositories/orgapacheactivemq-1410 > > >> > > > > >> > > If you would like to validate the release: > > >> > > > > >> > > > https://activemq.apache.org/components/artemis/documentation/hacking-guide/#validating-releases > > >> > > > > >> > > It is tagged in the git repo as <version> > > >> > > > > >> > > [ ] +1 approve this release > > >> > > [ ] +0 no opinion > > >> > > [ ] -1 disapprove (and reason why) > > >> > > > > >> > > Here's my +1 > > >> > > > > >> > > > > >> > > Justin > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > >> For additional commands, e-mail: dev-h...@activemq.apache.org > > >> For further information, visit: https://activemq.apache.org/contact > > >> > > >> > > >> > > >
