Closed tubatodd closed 2 months ago
I cannot promise any ETA, we are forced to move infrastructure, including the pipelines that produce the x86-64 versions of this RPM.
This is open source software, so anyone can bump the version and build it on an x86-64 or an aarch64 architecture in Docker.
The x86-64 part was moved to Actions at least in part. I have bumped the version, now let's see.
aarch64
packages are built locally once we have a GitHub release to publish them to.
@michaelklishin it appears that there is a newly published set of 26.2.5.2
artifacts under releases.
Edit:
I will be needing el8
packages. Will those be published as well?
Thank you for looking into this so quickly.
@tubatodd just in case you need them, aarch64
versions of the package are now also available from the GitHub release, and our Cloudsmith mirrors have been synced to provide 26.2.5.2
.
@michaelklishin what is the status of el8
packages? I noticed the source.zip code makes no mention of el8
where as the previous 26.2.5
provided that package option (and el7
)?
@tubatodd looks like they are no longer produced starting with the move to Actions. As for CentOS 7 packages, CentOS 7 has been dead for several years now.
I now see why CentOS 8 packages are not built: mirrorlist.centos.org no longer resolves.
The solution requires modifying the image and the certificates that CentOS 8 bundles seemingly will cease to work soon (or already have).
@michaelklishin so we are running RHEL 8 and that is what we need el8
packages for. Other clones like Alma 8.x and Rocky 8.x would also make use of el8
packages. So are you saying el8
is no longer going to be supported with this dot release? The rabbitmq packages are (or were) still being built for el8
. This is a major blocker for us and I imagine anyone using RHEL8, Alma 8 or Rocky 8.
I now see why CentOS 8 packages are not built: mirrorlist.centos.org no longer resolves.
The solution requires modifying the image and the certificates that CentOS 8 bundles seemingly will cease to work soon (or already have).
With CentOS 8 no longer being a thing, the logical next step most people are doing is moving to Rocky 8. Rocky was created by the same person who started CentOS back in the day.
@tubatodd I'm afraid you are asking for a bit too much. CentOS 8 is dead according to CentOS maintainers. Why should Team RabbitMQ maintain packages for a distribution whose repositories have been taken offline?
@tubatodd I'm afraid you are asking for a bit too much. CentOS 8 is dead according to CentOS maintainers. Why should Team RabbitMQ maintain packages for a distribution whose repositories have been taken offline?
@michaelklishin please see my comments above. I am not wanting CentOS 8. RHEL8, Alma 8 and Rocky 8 are still very much alive.
I still don't see why our small team should spend time worrying about Alma Linux 8 or Rocky Linux 8.
RHEL 8, CentOS 8 is a distribution from 2019, and CentOS 7 is a distribution from 2013. We do not support other distributions when they reach the fifth year, and we certainly do not support 10+ year old distributions.
Updating CentOS 8 image to use vault.centos.org was enough to get the el8
version to build.
If it requires more work than that, we will drop el8
support entirely. The source of this package is available to anyone who needs to build it. Even for CentOS 7 on x86-64, which still has a separate branch and all it takes to build it is a functional image plus
cd docker
./build-packages.sh
ls -l ./all_rpms
The el8
workflow has [finished successfully]() and the release was updated.
I will try to switch it to use a Rocky Linux 8 image. If it requires more than an hour to migrate, we will drop el8
support. We are not Rocky Linux maintainers and never intended to be.
Packaging software for old distributions is a responsibility of its users or maintainers (or maintainers of a fork such as Rocky Linux or Alma Linux).
Mirrors have been re-synced again to include the el8
package.
A Rocky Linux 8-based image builds successfully. Building the RPM on it and testing the result is for another day.
I still don't see why our small team should spend time worrying about Alma Linux 8 or Rocky Linux 8.
RHEL 8, CentOS 8 is a distribution from 2019, and CentOS 7 is a distribution from 2013. We do not support other distributions when they reach the fifth year, and we certainly do not support 10+ year old distributions.
Updating CentOS 8 image to use vault.centos.org was enough to get the
el8
version to build.If it requires more work than that, we will drop
el8
support entirely. The source of this package is available to anyone who needs to build it. Even for CentOS 7 on x86-64, which still has a separate branch and all it takes to build it is a functional image pluscd docker ./build-packages.sh ls -l ./all_rpms
The main reason I feel that el8
support should still be provided, is because Redhat Enterprise Linux 8 (RHEL8) commercial Linux OS is still supported through 2029 and there are various large companies, including mine, that are utilizing it for the time being.
It may seem like I am making this request specifically for my company, but I am really just highlighting the fact that RHEL8 is still a fairly widely used and commercially supported version.
And for the record, I am using this situation to pitch to our upper management to migrate to RHEL9 .
Mirrors have been re-synced again to include the
el8
package.A Rocky Linux 8-based image builds successfully. Building the RPM on it and testing the result is for another day.
@michaelklishin on behalf of my entire engineering team, we would like to thank you for providing this build. As I stated above, I will leverage this scenario to push forward our migration to RHEL9 in the future.
@tubatodd thank you for educating me about Rocky Linux 8. The aarch64
el8
packages of this release were produced on Rocky Linux 8 (locally) and it seems to work perfectly fine 👏
As for Red Hat supporting their distribution through 2029, it might as well be 2059, they do not share any of that extended support revenue with OSS maintainers, so it's up to them to deliver on their unrealistically long support schedule promises.
By 2029, OpenSSL/LibreSSL might bump a couple of majors and many tools (such as Erlang) will adopt the most recent one, leaving a lot of older distributions behind. We have seen exactly that happen to CentOS 7 with OpenSSL 3.x.
Is your feature request related to a problem? Please describe.
This bug was reported upstream to
erlang/otp
on my behalf a couple months ago. https://github.com/erlang/otp/issues/8482It has been been merged into
26.2.5.1
and was released a few weeks ago. Since then26.2.5.2
is now available. I would like to see thiserlang-rpm
project updated to26.2.5.2
Describe the solution you'd like
Upgrade to 26.2.5.2
Describe alternatives you've considered
No response
Additional context
No response