Just a brainstorm.  Isn’t this something apache parent should prevent? Or
maybe the Maven release plugin?

Clebert Suconic


On Tue, Oct 22, 2024 at 8:21 AM Robbie Gemmell <robbie.gemm...@gmail.com>
wrote:

> PR merged, and followed up with reworked addition around checking the
> reproducibility:
>
>
> https://github.com/apache/activemq-artemis/blob/main/RELEASING.adoc#verify-build-reproducibility
>
> https://github.com/apache/activemq-artemis/commit/ef09a95fb206af49bc91c0b4966f15075b292c10
>
> On Tue, 22 Oct 2024 at 12:31, Robbie Gemmell <robbie.gemm...@gmail.com>
> wrote:
> >
> > Well, crap...I just added a whole section about the reproducibility
> > checks before seeing this, and hadn't noticed your other PR. I'll
> > review the PR and perhaps revert my change, merge, and then redo it.
> >
> > On Mon, 21 Oct 2024 at 22:03, Justin Bertram <jbert...@apache.org>
> wrote:
> > >
> > > 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
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > >
>
> ---------------------------------------------------------------------
> 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
>
>
>

Reply via email to