LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 10-01-2020, 10:15 AM   #31
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 690

Original Poster
Rep: Reputation: 416Reputation: 416Reputation: 416Reputation: 416Reputation: 416
SARPi changes and updates


For the Raspberry Pi 3 & 4 the Broadcom brcmfmac firmware for wireless and Bluetooth is now updated automagically on a "per-build-process" basis. So it should always be current, and updated a lot quicker than it has been in the past - which was when I remembered and then could be bothered to do it.

For the Raspberry Pi (1) & 2 the Broadcom brcmfmac firmware has been omitted from the build process as it's superfluous in any event.

From now on all SARPi releases are created with a "batch ID" which covers the installer image, and packages. This is to make it easier for me to know which build process created a given file, when I have 100s of files with the same release-version in their filenames. Also easier for you if you have a problem then the *sarpi*.txz pkgs you've installed can be traced to a specific job.

For example, on the Rasperry Pi 3 - the "BuildLog Ref" from the latest SARPi3 batch [https://sarpi.fatdog.nl/index.php?p=rpi3getcurrent] ties in with the "Build Ref" on all other *sarpi* downloads from the same build process. So if you have installed the latest release versions onto your Slackware ARM system check out the BuildLog from the SARPi3 download page:

Code:
# SARPi3.SlackBuild Batch ID
BuildLog Ref..: SP320275102231
Then, if you look at the contents of your /boot/version-kernel-sarpi3.txt file you will see the same "Build Ref":

Code:
Package: kernel_sarpi3-5.4.68-armv7-1_slackcurrent_01Oct20_sp1.txz
Download: https://sarpi.fatdog.eu/index.php?p=downloads
Build ref: SP320275102231
Build date: 2020-10-01 10:24:55
Git revision: 61b7f805d
For the inquisitive, this SARPi "Build Ref" tag is unique to each individual build process and is broken down as follows:
SP3 = SARPi Project rpi3 build version
20 = 2 digit year
275 = 275th day of the year
102231 = 10:22:31 - the system time when this build process was requested

You'll also see a '/boot/version-sarpi3-hacks.txt' file [if you have installed this pkg] containing the same build ref. The "Build Ref" is also included in the accompanying README file for each installer image. This is how *sarpi*.txz pkgs can be identified as coming from the same build process from now on. Saves me ripping my hair out sometimes, if nothing else! Easy for you to tell me what the "Build Ref" is of your current files if/when any problems arise.

I'm sure there's a dozen other new things I could mention but it's mostly devel shizzle and would bore you. All you need to know is if the software works as designed, and it does.

New SARPi batch uploaded earler containing all the latest updates: https://sarpi.fatdog.nl/index.php?p=downloads
 
3 members found this post helpful.
Old 10-02-2020, 02:13 AM   #32
Desiderius
Member
 
Registered: Jun 2017
Posts: 111

Rep: Reputation: Disabled
In fact SARPI downloads are VERY VERY OLD ! 1970-01-01 !

Quote:
Originally Posted by Exaga View Post
For the Raspberry Pi 3 & 4 the Broadcom brcmfmac firmware for wireless and Bluetooth is now updated automagically on a "per-build-process" basis. So it should always be current, and updated a lot quicker than it has been in the past - which was when I remembered and then could be bothered to do it.

For the Raspberry Pi (1) & 2 the Broadcom brcmfmac firmware has been omitted from the build process as it's superfluous in any event.

From now on all SARPi releases are created with a "batch ID" which covers the installer image, and packages. This is to make it easier for me to know which build process created a given file, when I have 100s of files with the same release-version in their filenames. Also easier for you if you have a problem then the *sarpi*.txz pkgs you've installed can be traced to a specific job.

For example, on the Rasperry Pi 3 - the "BuildLog Ref" from the latest SARPi3 batch [https://sarpi.fatdog.nl/index.php?p=rpi3getcurrent] ties in with the "Build Ref" on all other *sarpi* downloads from the same build process. So if you have installed the latest release versions onto your Slackware ARM system check out the BuildLog from the SARPi3 download page:

Code:
# SARPi3.SlackBuild Batch ID
BuildLog Ref..: SP320275102231
Then, if you look at the contents of your /boot/version-kernel-sarpi3.txt file you will see the same "Build Ref":

Code:
Package: kernel_sarpi3-5.4.68-armv7-1_slackcurrent_01Oct20_sp1.txz
Download: https://sarpi.fatdog.eu/index.php?p=downloads
Build ref: SP320275102231
Build date: 2020-10-01 10:24:55
Git revision: 61b7f805d
For the inquisitive, this SARPi "Build Ref" tag is unique to each individual build process and is broken down as follows:
SP3 = SARPi Project rpi3 build version
20 = 2 digit year
275 = 275th day of the year
102231 = 10:22:31 - the system time when this build process was requested

You'll also see a '/boot/version-sarpi3-hacks.txt' file [if you have installed this pkg] containing the same build ref. The "Build Ref" is also included in the accompanying README file for each installer image. This is how *sarpi*.txz pkgs can be identified as coming from the same build process from now on. Saves me ripping my hair out sometimes, if nothing else! Easy for you to tell me what the "Build Ref" is of your current files if/when any problems arise.

I'm sure there's a dozen other new things I could mention but it's mostly devel shizzle and would bore you. All you need to know is if the software works as designed, and it does.

New SARPi batch uploaded earler containing all the latest updates: https://sarpi.fatdog.nl/index.php?p=downloads
Attached Thumbnails
Click image for larger version

Name:	sarpi.jpg
Views:	19
Size:	22.8 KB
ID:	34212  
 
Old 10-02-2020, 07:56 AM   #33
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 690

Original Poster
Rep: Reputation: 416Reputation: 416Reputation: 416Reputation: 416Reputation: 416
Quote:
Originally Posted by Desiderius View Post
In fact SARPI downloads are VERY VERY OLD ! 1970-01-01 !
OK. There's a transition time between me uploading the files and them transferring to slackware.uk/sarpi repository. This period is no longer than 30 minutes. In years gone by I have put the SARPi website into "maintenance mode" while I'm uploading, so that users will not be otherwise inconvenienced. I shall start doing the same thing in future and then there's no confusion.

What you're seeing is a 'null_value' [UNIX epoch] date because the files cannot be located. My guess is that you caught that page early on during the upload. Next time please wait at least 30 mins before alerting me of a problem that doesn't exist at the end of that 30 minutes.
 
Old 10-02-2020, 08:38 AM   #34
Desiderius
Member
 
Registered: Jun 2017
Posts: 111

Rep: Reputation: Disabled
Smile

Quote:
Originally Posted by Exaga View Post
OK. There's a transition time between me uploading the files and them transferring to slackware.uk/sarpi repository. This period is no longer than 30 minutes. In years gone by I have put the SARPi website into "maintenance mode" while I'm uploading, so that users will not be otherwise inconvenienced. I shall start doing the same thing in future and then there's no confusion.

What you're seeing is a 'null_value' [UNIX epoch] date because the files cannot be located. My guess is that you caught that page early on during the upload. Next time please wait at least 30 mins before alerting me of a problem that doesn't exist at the end of that 30 minutes.
Dont'worry @Exaga ; It was only a joke
 
Old 10-02-2020, 08:56 AM   #35
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 690

Original Poster
Rep: Reputation: 416Reputation: 416Reputation: 416Reputation: 416Reputation: 416
Quote:
Originally Posted by Desiderius View Post
Dont'worry @Exaga ; It was only a joke
Not worried at all. Next time it'll be in maintenance mode for the duration and I'm not joking. Thanks for apprising me of your predicament.

For future reference if it's so urgent that you need to download a sarpi file without delay then they are available from slackware.uk/sarpi mirror.
 
Old 10-06-2020, 11:41 AM   #36
eduardr
Member
 
Registered: Sep 2011
Distribution: Slackware64 14.2+ (-current)
Posts: 82

Rep: Reputation: Disabled
As always thanks Exaga for the latest updates!

One thing I haven't been clear about for some time regarding the packages "kernel-source" and "kernel-headers" that come with Slackware ARM. It appears I should be removing these and then installing kernel-headers-sarpiX and sarpiX-kernel-source?

The manual page https://sarpi.fatdog.eu/index.php?p=endinstall doesn't talk about removing these 2 system packages.
 
Old 10-06-2020, 01:40 PM   #37
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 690

Original Poster
Rep: Reputation: 416Reputation: 416Reputation: 416Reputation: 416Reputation: 416
Quote:
Originally Posted by eduardr View Post
As always thanks Exaga for the latest updates!

One thing I haven't been clear about for some time regarding the packages "kernel-source" and "kernel-headers" that come with Slackware ARM. It appears I should be removing these and then installing kernel-headers-sarpiX and sarpiX-kernel-source?

The manual page https://sarpi.fatdog.eu/index.php?p=endinstall doesn't talk about removing these 2 system packages.
Hi eduardr.

The 'sarpi*-kernel-source*.txz' and 'kernel-headers-sarpi*.txz' packages are not included in the '/sarpi-extras' dir within the initrd.gz and do not get installed after Slackware ARM 'setup' with the usual packages. That's why they don't feature on the SARPi 'Completing the install process' page.

If you are building/compiling - especially system software - I would highly recommend installing the sarpi*-kernel-source package if you are using SARPi kernel/modules, etc. NB: not because there's anything wrong with MoZes' packages! Installing the 'sarpi*-kernel-source' package means you have the same source that was used to build the kernel you are running. So any software which depends on the kernel source being present when compiling will use the exact same version. To ensure compatibility, if nothing else.

The 'kernel-headers-sarpi*' package is not usually needed as the headers are included within the kernel source-tree. This package has been available in the event that the headers may be required. In years gone by it has been requested a few times. Installing it hopefully won't cause any problems - it will just overwrite the kernel headers which are already on the system. If you are already running a SARPi kernel that's perfectly fine. Otherwise I'm not sure - that would be in the "uncharted territory" category.
 
2 members found this post helpful.
Old 10-06-2020, 02:27 PM   #38
eduardr
Member
 
Registered: Sep 2011
Distribution: Slackware64 14.2+ (-current)
Posts: 82

Rep: Reputation: Disabled
Thanks for the detailed notes Exaga!

I've removed the system "kernel-source" and "kernel-headers" packages and installed the sarpi ones instead. I don't prefer to install on top of the system ones because then I have duplicate packages and it gets confusing, especially when the latest kernel source from slackware arm and kernel source from sarpi happen to be the same version (which happens once in a while).
 
1 members found this post helpful.
Old 10-06-2020, 03:27 PM   #39
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 690

Original Poster
Rep: Reputation: 416Reputation: 416Reputation: 416Reputation: 416Reputation: 416
Quote:
Originally Posted by eduardr View Post
Thanks for the detailed notes Exaga!

I've removed the system "kernel-source" and "kernel-headers" packages and installed the sarpi ones instead. I don't prefer to install on top of the system ones because then I have duplicate packages and it gets confusing, especially when the latest kernel source from slackware arm and kernel source from sarpi happen to be the same version (which happens once in a while).
The reason I decided to create a kernel-headers package was predominantly for aarch64 related building and testing. It's now super-quick for me to maintain and update the sarpi/sarpi64 build scripts after spending all of September rebuilding and restructuring them - so was quite easy to include in both.

You aren't required to install either the source or headers packages. They should be treated as "optional extras" for specific purposes, like package building/compiling and such.
 
4 members found this post helpful.
Old 10-21-2020, 03:22 AM   #40
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 690

Original Poster
Rep: Reputation: 416Reputation: 416Reputation: 416Reputation: 416Reputation: 416
Updated SARPi installer image and packages running kernel 5.4.72 for Slackware ARM on a Raspberry Pi.

Available from https://sarpi.fatdog.eu/index.php?p=downloads

 
2 members found this post helpful.
Old 10-23-2020, 01:29 PM   #41
mralk3
Senior Member
 
Registered: May 2015
Distribution: Slackware on ARM and Aarch64
Posts: 1,573

Rep: Reputation: 892Reputation: 892Reputation: 892Reputation: 892Reputation: 892Reputation: 892Reputation: 892
Exaga, please see: https://www.linuxquestions.org/quest...rm-4175684124/

I did find a bug in sarpi4-hacks doinst.sh, where /mnt/etc/rc.d/rc.local is not found by grep, due to the installer looking for /etc/rc.d/rc.local. I believe this will only happen during a fresh installation of Slackwarearm, but not when the package is upgraded on an existing system. I haven't ran explodepkg to see what the doinst.sh is actually doing though. I hope this helps.
 
Old 10-24-2020, 01:20 AM   #42
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 690

Original Poster
Rep: Reputation: 416Reputation: 416Reputation: 416Reputation: 416Reputation: 416
Quote:
Originally Posted by mralk3 View Post
Exaga, please see: https://www.linuxquestions.org/quest...rm-4175684124/

I did find a bug in sarpi4-hacks doinst.sh, where /mnt/etc/rc.d/rc.local is not found by grep, due to the installer looking for /etc/rc.d/rc.local. I believe this will only happen during a fresh installation of Slackwarearm, but not when the package is upgraded on an existing system. I haven't ran explodepkg to see what the doinst.sh is actually doing though. I hope this helps.
Many thanks for making me aware. From what you have described, if it's anything to do with 'ROOT=/mnt installpkg' at the end of Slackware ARM 'setup' (which I suspect it is) then I know exactly what causes it. I'll certainly investigate and get back to you.
 
Old 10-24-2020, 11:58 AM   #43
mralk3
Senior Member
 
Registered: May 2015
Distribution: Slackware on ARM and Aarch64
Posts: 1,573

Rep: Reputation: 892Reputation: 892Reputation: 892Reputation: 892Reputation: 892Reputation: 892Reputation: 892
Exactly, the error from grep pops up just before sarpi4-hacks finishes installing while running ROOT=/mnt installpkg, etc.
 
Old 10-31-2020, 05:14 PM   #44
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 690

Original Poster
Rep: Reputation: 416Reputation: 416Reputation: 416Reputation: 416Reputation: 416
Quote:
Originally Posted by mralk3 View Post
Exactly, the error from grep pops up just before sarpi4-hacks finishes installing while running ROOT=/mnt installpkg, etc.
mralk I am at a loss here. The latest sarpi-hacks pkg installs/upgrades as expected without error(s) and functions as designed.

Code:
+==============================================================================
| Upgrading sarpi3-hacks-3.0-armv7-1_slackcurrent_19Oct20_sp1 package using ../sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz
+==============================================================================
Pre-installing package sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1...
Removing package: sarpi3-hacks-3.0-armv7-1_slackcurrent_19Oct20_sp1-upgraded-2020-10-31,22:03:48
Verifying package sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz.
Installing package sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz:
PACKAGE DESCRIPTION:
# sarpi3-hacks-3.0 (Raspberry Pi 3 modifications and fixes)
#
# This package modifies a new Slackware ARM installation with required
# fixes, specific to the Raspberry Pi 3. See the included README for
# further details of modifications and fixes.
#
#
#
# SARPi Project - https://sarpi.fatdog.eu - SP320305090611
#
Executing install script for sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz.
Package sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz installed.
Package sarpi3-hacks-3.0-armv7-1_slackcurrent_19Oct20_sp1 upgraded with new package ../sarpi3-hacks-3.0-armv7-1_slackcurrent_31Oct20_sp1.txz.

root@jook:/tmp#
My guess is that you have an older version which I remember on one batch did have an error in the doinst.sh code - '/etc/' was specified and it should have been 'etc/' which caused the error. Without spending too much time trolling through past builds I'm guessing it was around kernel 5.4.50 / 5.4.60 sort of period. If you have a build ref for the pkg you're using that would be a great help and save me wasting some time on it. If it's pre-build ref then forget about it. Haha!
 
  


Reply

Tags
docker, nginx, raspberry pi, slackware arm


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Sarpi / Raspberry (RPi 3) - sound issue under 5.4.18-v7-arm eduardr Slackware - ARM 11 02-28-2020 04:12 AM
SARPi - Slackware ARM 14.2 installer images and packages updated to kernel 5.4.x. Exaga Slackware - ARM 2 01-26-2020 12:44 PM
SARPi - Slackware ARM -current installer images & packages updated to kernel 5.4.x Exaga Slackware - ARM 5 01-22-2020 04:35 PM
SARPi website new URL - sarpi.co.uk Exaga Slackware - ARM 4 01-28-2018 06:36 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 08:26 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration