will the current version of 64bit ARMv8 AArch64/ARM64 "current" become stable? and current version marches on?

I thought this was asked before or was maybe a reply in a topic related thread.

Yes, no change to the life cycle: Slackware AArch64-current will be branched into a release of Slackware AArch64 15.1 (possibly this year).

2 members found this post helpful.

The releases and installation guides always represent the current state.

2 members found this post helpful.

Please mark your thread as "SOLVED" if your question has been answered.

solved

What is the official stance on slarm64?

What is the official Slackware aarch64 -current support status on Radxa Rock 5?

It's its own entity: it's not developed by anybody in the Slackware core team, thus has no connection to the Slackware project.

It's not on the roadmap. If someone wants to be a Hardware Custodian for it, they're welcome to figure it out and submit changes to make it work out of the box. Most of the documentation to assist is already online, but needs organising better (that's for later this year).

The next Hardware Model of interest/work in progress is the Honeycomb LX2.

2 members found this post helpful.

While i have no idea what a Hardware custodian of a device entails (do i need to feed it? wash it when it poops it self?) I would very gladly like to be able to run official Slackware on the Radxa Rock 5 i have.

One of the first steps in that direction would be enabling rk3588 support in the kernel - i am not sure yet if that requires patching or merely waiting for mainline to support it?

Further, there are some issues (i'm currently investigating) with u-boot support for the device.

And i would like to know where could one hang a "Slackbuilds that fail to build" thread for aarch64 or any arm arch for that matter? Here in the Arm subforum?

I saw your post in ponce’s thread mentioning lua53 which builds fine for me. But I’d be interested in what’s failing to build for you. Most of the scripts should work as-is, providing you’ve added aarch64 to them. But there is the occasional oddball or extremely old software that needs extra help. I wish sbo would just add aarch64 but they worry about not being able to support (though things seems rarely tested anyway). I for one, would love to hear what you’re having problems with.

tell sbo maintainers you commit to supporting aarch64 slackbuilds, then maybe they'll entertain adding aarch64?

1 members found this post helpful.

I have asked them to consider it. Offered to run tests to see what builds/fails, or if its viable. Considering a few factors though, aarch64 has no actual stable release yet, so it wouldn't be supported in the current form. Now when 15.1 does release, that may be an option. But there is much push-back since they do not have the machines to do testing with (and qemu doesn't exist, it seems).

"Support" is not something I assumed I received by using things on SBo. It's a repository of user-submitted scripts to build software not included with Slackware, which may or may not work, and is done "at the users risk". This is how I've always viewed SBo. If I can't get something to build, the rules state to email the maintainer, it's not offered they will support me. As a last ditch effort, they say to mail the list if you've checked all the other dots. They offer a sane "trustable" location to find software scripts for Slackware, which have presumably been vetted to at least build.

It shouldn't be this hard to get them to add a if statement to SlackBuilds for arm/aarch64. The ARM port has been official for over a decade, and ARM isn't going anywhere, and neither is Slackware ARM. To me, it's sad that admins basically refuse to accept the ARM port even exists, the community will never grow without the things people are used to using even having just basic support to be used on the ARM port.

It's silly that this is even a question people have to ask, and because of things like this, why would anyone recommend Slackware ARM to anyone when you can't even use the user repos with it? There's almost literally zero reason to have to fork the repo and maintain a separate instance just for arm/aarch64, and popular apps like sbopkg and sboui would just work, if it weren't for the lack of definitions in the SlackBuilds.

It could be added simply enough, and all of us users could be the testers (as it appears to be for x86). Some scripts are x86 only and sure, some things would need fixing, but it's impossible to know without simply adding the arch in the first place.

Venting in the wrong place I know, and I didn't join into the chaos in the mailing list a month or so ago, but it's likely not going to happen anyway. And I couldn't possibly support every package on the site, nor have any intent to. Likely the only real option is creating ones own fork, or finding a work-around that would continue to work with existing tools that slackers are used to using. TBH off the top of my head, I can't think of a single script that doesn't work that I've used from there, excluding x86-bin repacks. ARM is a pretty stable thing in the Linux world these days, and there really isn't a reason to omit it.

1 members found this post helpful.

Hehe, that's basically what it is - and occasionally you'll need to wash the bed sheets at a high temperature on a long cycle ;-)
A HWM custodian is described here.
Slackware ARM is built to support new HWMs easily. Initially it's labor intensive but once we merge the support into OS, over the long term it's a case of maintaining the Kernel module loader script, and testing the support on a monthly basis.
As we merge in the changes for the HoneyCombLX2 I'll be updating the HWM integration documentation. I also need to merge a number of patches for the Installer back to Patrick so I can make available the ARM installer build system, but this won't hold anybody up.

Slackware ARM isn't aiming at broad coverage of Hardware Models because maintaining the quality of the OS and documentation is unsustainable with the small development team (me and Brent) at scale: the idea is that there are a handful of useful HWMs that work as well as possible using the upstream materials, which serve as a reference that the community can use to support others and contribute those changes back if they wish.

2 members found this post helpful.

[..]

Two of the admins are in the core Slackware team and are fully aware of the existence of the ARM port, and one of the SBo package maintainers contacted me to adjust some settings in SA64 to enable running on AArch64 hardware in AWS where they were testing builds of their packages. When I began porting to AArch64 I thought that a change to the default SlackBuild template had been submitted to set the compiler flags for AArch64, but perhaps it didn't make it -- I'll check with them.
In the most part though you don't need to change the scripts - the CFLAGS will default to -O2 which is usually sufficient.

2 members found this post helpful.

The only glaring issue for aarch64 is the libs end up in /usr/lib rather than /usr/lib64, ARM32 builds fine as-is OOB. But pending the 15.1 release when aarch64 is officially launched, we'll have messy systems if using the SlackBuilds as-is.

Ah yes. The change I submitted duplicated x86_64's settings.

1 members found this post helpful.