Great many thanks for making Slackware possible on the ARM (and RPi).

I hope someone will pick up and continue it.

And last but not least, what can we (SlackARM enthuziasts) do to help, continue with it, make it live on?

P.S.
Though a huge Slackware fan, I am probably one who made least use of it on ARM so far, though not by choice.

Continuing SlackwareARM
 

What does it take to continue SlackwareARM ?

Would Stuart Winter (and other that worked on it) document and share his experience developing and maintaining SlackwareARM such that someone(s) else may pick up and continue his legacy?

I mean:

• a build farm, how to set one up and configure it and use it?
• kernels: how to set them up for the various ARM devices (like tegra, kirkwood, armv7, etc)?
• packages: on what criteria should a package be excluded (eg graphical browser)
• build scripts: how to write / modify a build script for the ARM platform?
• cross compile(?): set up package build on PC using cross compiling
• what significant issues need to be overcome to make things work on ARM architecture?
• anything else worth mentioning?

What about migrating the distro to hard-float (there are guides on how to rebuild SlackwareARM for the RaspberryPi with hard-float)?
What about the new ARM64 architecture (RaspberryPI 3)?

Thank you very much.

There have been a few people who contacted me about it. If anybody wanted to continue it, they'd need to fork it and call it something other than "Slackware" or "ARMedslack". The "Slackware" name is Patrick's and it's up to him to decide who can use it, and "ARMedslack" was the previous name I used prior to it becoming the official port, which still represents my work.


I can answer questions if anybody has any as long as they are on this forum so others can read the replies; but if someone could maintain it (there are people who've already built an entire ARM tree) then they'd usually have figured all of main stuff out by themselves. There are some nuances that aren't obvious, but most of them are documented in the ARM tree if you look for them.

I did speak to someone from Linaro about 64 bit hardware recently, and certainly that would be a good idea as that's the future.

I don't think it's worth continuing the soft float port for anyone unless they have some specific reason to keep using the armv5 hardware, and I'm certain -- based on the reading I do (it's not just maintenance of Slackware, it helps to look at what the other ARM porters are doing for the other distributions) -- the large parts such as X will begin to stop working for anything less than ARMv7 hard float.

A hard float port isn't hard and I started changing the ARM source tree to accommodate it some time ago, so I plan to chip away at it as time permits. No promises.

https://github.com/idlemoor/distcc-tools
... which packages http://slackware.uk/slackwarearm/sla...s/x-toolchain/

Whats the issue with the hard vs soft float, I seem to have missed that.
Ahh, I see it now http://www.linuxquestions.org/questi...at-4175512987/

Looks pretty straightforward. I've been using the minirootfs recently anyway rather than the full install (fatdog) so there are not that many packages, looks like 80. So all I'd have to do is just recompile each of those to hard float?

What is the plan for 14.2, will be supported until 14.3/15?

I have a couple spare Raspberry Pi 2's now as I've upgraded my 'production' servers to 3's, if I can use them to help in anyway such as test/compile.

I've been thinking about building a hard float system like the Slackwarearm miniroot filesystem to keep me out of trouble this winter. I've been doing some reading trying to get up to speed on what's required. 14.2 is just around the corner and I've been waiting for it to arrive before I take the plunge. I don't need X, xfce, and much more from a full install for my toying around and I'd probably be able to add what I need to get myself in a bind.

I've a couple banana pros to compile on using distcc might add a raspberry pi B gathering dust into the equation as well. There's also a b pi m2 lying about somewhere that I might try to breath some life into while waiting for things to compile on the working gear.

I must say thanks again to Stuart for Slackwarearm and all his effort as I probably would've never bothered to play with these little boards if I had to use some other distro.

I would not say "just". You have to start from scratch and you'll need ancillary packages for the build only, which you don't necessarily need at run time -- e.g. documentation creation packages such as texinfo, perl, and stuff like that. You can hack the builds to ignore docs (which is what I did the first time around).

One of the old armv5 build machines died recently, and two of them already had PSU replacements - so who knows how long they will survive. There's no end date I have in mind for it though, assuming the build machines stay alive.


I'm currently building a hard float port using the current ARM tree, so that I don't get out of touch entirely with Linux.
If I get it all working (looks good so far and it's only been a few days), I may release that and develop and maintain it at a slower rate than I used to.

So are you building it currently on the arm box or cross compiling on an x86 box and using the v5 machines just for testing?

I see Bananna Pi on the lost of officially supported, I just grabbed one of those at a local store that was marking them down.

I always wondered how the official Slackware packages are built (arm or x86). Do you compile by hand each time or just create a slackbuild so if the source gets a minor update you can just run your slackbuild again?

I've been meaning to dedicate one of my Pi's to be my own local slackpkg repo anyway instead of having multiple hitting yours. So my though was setting up one for the repo and one for the build. Then when I run slackpkg update I just take the list of new packages from the log and build them as v7 hard float on the build box then put those packages onto the repo box in place of the soft float (after the initial rebuild of all the original 80).

I have three of mine in my prototype 1/2with 1U height rack mount chassis, I'm learning OpenScad now so I can see if I can 3dprint the cases cheap enough to not cut and glue acrylic then get the rest racked.

The soft float port originally was bootstrapped with a mixture of traditional cross compiling and using a tool called "Scratchbox", since you can't build everything natively - some builds expect to run the binaries that were just built, so Scratchbox enabled that.
The OS is built natively and has been since the initial boot strap years ago, but farming out compilles to distcc on a few x86 machines.

At the moment I'm actually messing around with the hard float version using Fedora 24 ARM (after hacking it up a bit) and doing it natively there until I've built the bare minimum set of packages that form a bootable OS + toolchain. I didn't feel the desire to play with cross compiling this time around. I've entirely killed Fedora three times but have got it doing what I want now until I get the base set of packages built. I also have realised that I think I made a good decision making the Slackware installer available for ARM rather than providing pre-built images, and than determining what is wrong on a broken OS with systemd is no fun at all. Actually seeing how it really wasn't to my taste was what prompted me to see how easy it would be to use Fedora to boot strap Slackware.

Everything is built natively. The ARM tree is an overlay:
ftp://ftp.arm.slackware.com/slackwar...DME_SOURCE.txt

Within the private version of the ARM source tree there are stored copies of the x86 SlackBuilds, that were taken at the time they were modified/last used for x86. I keep my local x86_64 tree in sync with the Slackware pre-public tree, and run some scripts to mostly just diff the current x86_64 tree's scripts against my stored ones, and merge anything necessary into the ARM scripts (some times just patches, docs changes, changes to the way the package is built, and of course version numbers).
The change log from x86 serves as the build list (normally the pre-public tree has the original build order Patrick used, which is handy when the update batches run into 20+ packages which need a certain order), and I have a script that parses all of that and sets about building everything four times over (as some times the build order isn't actually correct, so I found rebuilding everything several times is the best way - and since it's automated, I don't need to baby sit it -- I just check the output of my tools).


that's cool. I have 3 Orange Pi's -- one of which is the A20 chip set (same as Banana Pi) - which I want to set up at some point.
At the moment I plan to put it into an ex Thai Takeaway plastic box and do something like you'd see on whitetrashrepairs.com ;-)

ok, yea, I didn't think about build order. Is that anywhere a mere mortal like myself can see?

If the kernel already supports hardfloat and I have an (arm) box running that can compile and I go in the right order shouldn't I be able to step through the packages one at a time recompiling then upgradepkg each one?

Hey, I'd like to add my thanks too. Still running 14.1 on my ix2-200 NAS with kirkwood (armv5te) hardware; it works well as a file server and is isolated from the web, so updates are currently not a issue. I'd have thought the hardware would have died by now, certainly both disks have been swapped out at least once.

It's not quite as simple as that, hardfloat and softfloat use different ABI's, the way they pass information from program to program or library to library is different.

It might be more useful to think of it in this way, imagine trying to build a 64bit version of a package on a 32bit OS. Even if your processor is 32/64bit capable it's just not going to happen.

It can be made to happen but you are into the land of cross compilers, think first of building a 32bit compiler that knows how to build 64bit compiler that runs on 32bit, then you need to use that to build a compiler that runs on 64bit and can build 64bit. And then there's all the libraries and other packages round about that. And then there's all the things that don't like being built on one architecture while being told to get ready to run on another.

And all that's still a most gross simplification.

And it's slow, the glibc sanity checks alone take, from memory, 4 days to run on an RPi-B

And that's if it works first time.

In short, it hurts :D

It's a fantastic education to try, if nothing else one gains a whole new level of appreciation for the expertise and amount of pure hard work put into it by Stuart and other crossbuilders.

They are not mere mortals like you and I.

Stuart, thank you, no wonder you need a break :)

Thank you so much Stuart for all of your great work! I'd be willing to help out in a conversion to hard float. I think I can gather enough resources to build a mini web farm. My problems is that other than building packages from source, I've never messed around in re-building Slackware core packages. Is there a specific documentation that you can suggest for all of us that would like to help?

For anyone trying the instructions https://mindplusplus.wordpress.com/2...-raspberry-pi/ have an old link to slackkit 1.04

the current appears to be:
http://mirrors.vbi.vt.edu/linux/slac...1.05-arm-1.txz


Missing headers also it seems:

OIC, 4.4.13 is in current-now, what is telling it to look for 4.4.8 slackkit?

Some of the questions being asked look like apprentice sandwich maker level questions being asked of a top chef, maybe some of those questions are best directed at google...

But from the department of trying to be helpful but will probably sound very unhelpful...

http://trac.clfs.org/
ftp://ftp.arm.slackware.com/slackwar...urrent/source/
http://alien.slackbook.org/blog/armport/
http://mirrors.slackware.com/slackwa...urrent/source/
http://www.intestinate.com/pilfs/

ahau.porteus.org::slackware-armv6 (server is not contactable at time of writing, permanently?)

Then there's raspbian, arch, gentoo, linaro etc etc etc

https://gcc.gnu.org/onlinedocs/

man distcc, man distccd

Oh, don't forget

https://www.google.com

Take all these and stir them together and get ready to put a *lot* of work into it.

My own first attempt was a frankensteins monster mix of CLFS and Slackware that I could *gasp* telnet into, I was chuffed as f**k, but it was also prone to crashing a lot and with no proper build system no two builds were the same.

My latest attempt is slightly more organised, scripted (as makes sense to my head) so each build follows the same path. It's also, as of today, broken again, that happens a lot. So it's back to the log files and looking at my changes and trying to work out why what I thought would work didn't. That will no doubt involve a lot more reading and a lot more learning.

It still doesn't look like Slackware, not even in the dark with one eye shut and a rose tinted eyeglass on the other and being able to telnet in looks like a far off dream.

But I'm cool with that, I'm in no rush, it's an on/off project of a couple of years now and I'm having fun with the challenge

Note that when Stuart started ArmedSlack he was blazing a trail, things have gotten a lot better wrt to gcc/glibc/kernel etc etc on Arm in the last few years.

Anyways, time for me to go back to teaching myself how to make sandwiches...