Slackware ARM 14.1 and -current End of Life Announcement
 

Hello,

From:
http://arm.slackware.com/

A rolling EOL reminder notice will be placed in to 14.1's ChangeLog when the next update batch is pushed.

Thanks are not enough for the work you do, or have done, Mozes. :)

Slackware ARM 14.1 and -current End of Life Announcement
 

Thanks for all the hard work! It is much appreciated. :)

I never had the occasion to use your port to ARM but this does not prevent me to realize the huge work you devoted to this project and that it made happy a lot of Slackware users.

I hope that your schedule will allow you to continue contributing to Slackware in other fields.

Huge thanks and kudos, Stuart!

My sincerest thank you for your work and best wishes as well!

Thanks! (to be read as factorial thanks) isn't enough for what you have done, and what you propose to do for the foreseeable future.

Thanks for all the hard work.

I take it then no one else offered to carry the torch so there will never be a 14.3? I need to start migrating my Pi's to something else.

[citation needed]

Why? What sort of fast train to Brokenville are you imagining? "Slackware ARM 14.2 will continue to receive updates for the foreseeable future".

Stuart anticipates diminishing maintainability of soft float. That doesn't prevent someone else doing a hard float successor to Slackware ARM 14.2; and of course, all Pis support hard float.

I'm asking the question not stating anything. I suppose I could have worded it differently. What happens to Slackware ARM long term, is 14.2 the last release

Actually I move quite slow, I suppose that comes from working in an enterprise size IT shop for years. IF 14.2 is the end of the line for slackware arm than its time I start researching a replacement now so I can but a test board in a year and move it to production usage in a 2-3 years from now.

Thank you for providing the Slackware community with an ARM port over the years.
It has been a great resource for enjoyment and learning, and for that I'm very grateful.
Best wishes on your future endeavors drmozes!

Slackware ARM 14.1 and -current End of Life Announcement
 

Thanks for your work, it is a huge pleasure to run slackware on a RPi !

Stuart,

For many years you've done more and shared more than most. Thank you for all you've given. The world is a little better for your efforts.

Jim

.....

Um, yeah. What they said.

You made Slackware possible on my Raspberry Pi's, and protected us from the evil known as systemd (*ptui*). That last bit especially qualifies you as a Slackware Hero.

I sincerely hope you get bored of driving around farmer´s fields in a clapped out banger like a crazy person and rescind your decision. Nobody does what you do. No-one but you can conjure that special magic you, personally, put into Slackware ARM. So I don´t want this wonderful port of Slackware to fade away and die. I sincerely hope some day you will return to doing what you do best.

Alternatively, when we finally get hold of you, you´ll wake up (eventually) and find yourself in a dark cellar chained to a terminal running Ubuntu on a Raspberry Pi 1 with loud Rick Astley punk-rock Christmas-cover songs blasting out 24/7. There´ll be a webcam pointing at you wih a permanent live feed to http://www.wekidnappedmozes.com/dark_cellar/cam-01. You´ll also be wearing a florescent pink leotard, electro-blue false eyelashes, and neo-orange lipstick - not forgetting the custom Debian DVD earrings. Just when you thought it was about as bad as it gets, the Ubuntu terminal will produce multiple systemd errors which you need to solve in order to be rewarded with sustenance, which will not include biscuits of any kind.

Thank you for all you've done, enjoy your 'retirement' :)

Thanks and good luck in whatever you decide to do next

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...

Very good analogy. :)

Was more of a thinking out loud than asking and stopping to figure out what for dinner.
I realize now since I'm on a RPi I used their kernel so I don't have the config or the headers or anything.

I wonder if it's easier to rebuild glibc, and then slowly rebuild everything to hard float? At least some of the DE and WM along with some of the applications. I'm going to start doing that tomorrow and see how it goes.

Thats what I was thinking. But for the glibc rebuild I'm going to have to pull more bits from the rasbain image I got the install from.

I'm running the minirootfs rather than the full install on both my Pi3's as I did that before the fatdog full installer was available. So when i just upgraded the 2 to the second 3 I rebuilt the 2 with the minirootfs as well. Just have the other 2 and the 1 to go now. This gives me <100 packages. Going back to see how to set up my own Slackpkg repo and I'll use the latest minirootfs as the source then as packages in it get upgraded in the full I'll built that package hardfloat and move into my minirootfs repo.
Mine are all "servers" so no DE or desktop apps.

Thats the plan anyway, after I get some sleep it might not make any sense :)

Sounds like a great plan. My experience with messing with minirootfs is zero. I have to start somewhere, right? ;) I'll be doing some reading tomorrow. Headed to bed also now.

It's not 4.4.8 slackkit, it's 4.4.8 of the Kernel headers. I'd had a cleaning session and must have become over zealous and wiped the older versions of the headers out. You can change glibc.SlackBuild to use 4.4.13 headers instead, which is now what I've done in the source tree.

That was supposed to be written "what is telling it to look for 4.4.8, slackkit" I was meaning is slackkit where the version is specified or was it glibc. I found my issue though right after that. Since I'm running just the minitrootfs and on a Pi I don't have the header sources which was easy enough to add but I also don't have it in usr/lib since I'm not using the slackware compiled kernel but using rasbains's inserted into the minirootfs.

So I need to pull rasbians config and compile the kernel to get the headers made again
http://docs.slackware.com/howtos:sla...kernelbuilding

Anyone running a Pi from the fatdog installer, can you check and see if you have the headers, i.e. did fatdog compile a kernel or did they just stick rasbain's in their installer. I'm at work and don't have ssh open to my home at the moment to check.

and for the record I'm not asking the top chef apprentice level questions (such as how to compile a kernel though I admit its been a long time since I've done so out of slack^D^D^D^D^Dlazyness) :p . I'm trying to document my thought process so others can follow if they are interested. Perhaps I should move my (probably incoherent) ramblings to another thread or LQ blog and leave this as a thank you thread for those who have supported arm so far.

If you look at glibc.SlackBuild and look at the error you pasted in, you'll see that it's not using the system headers, it's set up to extract the archived headers (from a previous kernel build by me) from the source/d/kernel-headers/sources directory and use those instead. This is different from x86 because of a legacy reason (before ARM was mainstream there was the master kernel.org and RMK's (the ARM kernel maintainer)'s tree, and some packages needed more recent headers than RMK's kernel had -- yet I needed RMK's kernel for the ARM system support, and so I had a mixture of headers from different Kernel versions (which is a "bad thing")-- it's just the way it was back then for the distributions)). This also means it's easier to boot strap since I just drop an archive of headers in place, and it'll use those rather than the system ones -- less to figure out next time around (as is the case now).

I'm in the process of rebuilding glibc now. As for rebuilding other packages with hard float, should I be using the following cflags?
Perhaps it's time to open a new thread about this.

Ok, lack of sleep due to last nights storm I'm being a little slow.

In the official SlackwareARM kernel source and kernel headers packages which headers do I get the source/d or system. I thought originally it was just missing the source/d headers so all I have to do is install the packages and they would be there. But then I started thinking you probably compiled the official kernel differently otherwise I could just boot off an unmodified minirootfs so I need to grab raspbain's config anyway.

I bet if I boot up the other Pi2 with the full (fatdog) install the "missing" headers will be there, I'm probably just missing stuff from the full that not in the minirootfs. (must stop posting from work where I can't see my Pi's, Or get a display for the zero sitting in my backpack :) )

saw the other thread now about recompiling glibc, since I'm running mine as servers then the hard/soft issue doesn't really matter to me. So I can just make my own repo and if/when 14.2 support ends just manually build packages myself as necessary.