Hello

The subject says it all! Feel free to post feedback, comments, bugs and so on in this forum.

Cheers
s.

All good so far. Smooth, quick, and stable. Nothing noteworthy to report.

1 members found this post helpful.

I noticed you're running 5.14 kernel. Will this be coming soon to Rpi3?

Stuart is shipping Slackware ARM 15.0 rc1 with Linux kernel 5.14.x and so the SARPi shizzle will follow suit. So that's a long-winded way of saying, "Yes. Absolutely!"

I've been building, testing, and running kernel 5.14.x for a few weeks. The only problem is the turnaround time for the RPi kernel guys pushing updates upstream and having them included into the mainline kernel source tree. If at all. Although that's nothing new, by any means. But it does seem to work perfectly for my needs with Slackware ARM 15.0 rc1 thus far, which I've been testing for approx. 24 hours and am suitably impressed with what Stuart has made available.

3 members found this post helpful.

It's there now if/when you want it.

Stu, over the last couple of days of testing (only on CLI - I haven't used a desktop environment yet) I've found Slackware ARM 15.0 release candidate 1 on the Raspberry Pi 2, 3, 4 to be flawless in operation. It's a little quicker to load, run and execute commands/programs, than previously. Not by a huge amount but it is noticeable to me in most situations.

Although xz compression with 'makepkg' seems to be a little slower, on the Raspberry Pi 2 and 3 but not on the Raspberry Pi 4. However, it's not any kind of problem at all. I'm still playing around and testing with it, comparing results, etc. I feel the way in which I use 'makepkg --threads 1' command options to create large pkgs on the Raspberry Pi 2 and 3 [with < 1GB RAM available] may be a contributing factor. I really don't know if multi-threading on multi-core CPUs is possible now with xz compression on Slackware ARM 15.0 rc1. If you have any thoughts on the matter I'd be interested to hear them.

One small request for the wish-list is an update for i2c-tools. The latest available version is i2c-tools-4.3 and Slackware ARM 15.0 rc1 still features i2c-tools-4.1 version.

Great work, as always. Loving it. Thanks a lot!

It defaults to 2 threads and in my test here, it's consistently 1 second slower when using 1 thread when tested on armv7 Hardware Models with 2GB and 1GB RAM.
I tested building a 44MB package, but perhaps there are noticeable differences when compressing larger volumes of data. I haven't looked at how xz assigns memory.
It certainly doesn't look like it's worth making any changes though.

done, thanks.

1 members found this post helpful.

Certainly no changes are warranted in this instance. Not something you need to waste any time on but thanks for testing it. I'm talking about large pkgs in the region of 80-100MB (bytes not bits) or greater in size, such as the Linux kernel source pkg which is currently 116MB after xz compression. With any pkg of this size (on the Raspberry Pi 2 and 3) 'makepkg' using the default 2 threads will crash out with a memory error because there's not enough available RAM to deal with such a large amount of data - which is why I need to use the '--threads 1' parameter to limit it. On the Raspberry Pi 4 [2/4GB RAM] this is never a concern and I just let 'makepkg' do its thing without negating the multi-threading. When creating smaller pkgs (on any Raspberry Pi device) any decrease in xz compression processing speeds is negligable.

Many of the recent Kernel packages were built on a 1GB RAM Banana Pi - it works. Perhaps you don't have enough swap?

1 members found this post helpful.

Now there's a thought. Thanks. I might try increasing swap partition size and see if it makes any difference. Although I do have a feeling I've been there before. It's not even an issue for me tbh. For example, the total build time for a SARPi batch is 4-5 minutes quicker to complete with Slackware ARM 15.0 rc1 than it was previously. So xz compression being a little slower than anticipated on the Raspberry Pi 2 and 3 has no impact whatsoever.

I usually disable multi-thread compression on single-board PC, since the memory usage from 1 to 2 threads jumps from 670MB to 2.5GB: on system with less than 3GB it will surely slow down things on big packages like kernel-source or kernel-firmware, even when enabling zswap.
Using more than 1 thread also increase a little the final size of the package.

For armv5te, since compressing with -9 will requires 65MB of RAM (some systems have only 64 or 32 MB of RAM...), I also put the XZ_DEFAULTS=--lzma2=dict=4MiB to reduce the memory required for decompression to only 5MB. The final size is usually greater by only 2-3% on bigger packages, and less than 1% on smaller/normal packages.

1 members found this post helpful.

Thanks for this information lucabon.

It's been a while since I've fathomed the benefits and drawbacks of compression format/ratio vs file size vs time taken vs personal preference. Mainly because time is not a factor in my considerations and Slackware ARM just works flawlessly anyway on the Raspberry Pi devices. So in the grand scheme of things all that really matters is that there aren't any problems, and there are zero problems that I've experienced with Slackware ARM 15.0 rc1 yet.

I don't know where it will be better to post it... I try here: if wrong place, please tell me!

If someone (apart me...) is interested in armv5 porting of Slackware-current (15), you can find packages and source code/scripts/patches here:

https://bonslack.bonnix.org/bonslack_armv5te-current/

I started the porting about 2 years ago, when I noted that the -current release of SlackwareARM requires armv7 hardware. Since I actually have many armv5 machines running, I really needed armv5 up-to-date porting of Slackware :-P

Hoping it could be useful for someone other than me!

The decision to drop software floating point support was made because the hardware is old technology and the software stack isn't as well-maintained as it was years ago when armv5 was generally the best available; and for new users in particular, you'll get a superior experience buying more modern hardware.

It's a good project though because much of the existing armv5 hardware is pretty solid, but please rename it from 'Slackware ARM'- it's not an official port. Once you rename it, I'll reference it as an option within the upgrade documentation for 15.0.

Thanks
s.

1 members found this post helpful.

Sure. I renamed the basename to "bonslack_armv5te": it will suffice, or it is better to rename also the architecture ("arm" => "armv5te") on all packages filename?

I also ported other architectures, including aarch64: actually it is "bonslack_aarch64". Should I also rename "aarch64" and its packages filename to something (e.g. armv8), or it will be ok leaving "aarch64"?

Thanks!
Luca

"ARMv8" and "AArch64" are just names for the architecture running the "A64" instruction set. I think "Arm7" is trademarked but not "Arm8" - but I could be wrong. See the ARM trademark list.

You should be OK using "AArch64" I think.

"Slackware" is a trademarked brand name so one needs to ask Patrick's permission before using it in certain ways. This page contains the relevant guidance on Slackware brand name usage.