If you actually try what bartgymnast provides and find bugs, issues or problems, we will be grateful of your reports. Till then, couldn't you please leave us alone?


IIRC Slackware is not a source distribution and can't be rebuilt from scratch, at least not without a lot of work, but maybe I am wrong. Would you mind to tell us a little more about this recent successful attempt and what were these few minor fixes?

3 members found this post helpful.

Didier, why don't you try learning to actually use the forum search function before mouthing off...

http://www.linuxquestions.org/questi...-a-4175464648/

BTW, Bart not sure, but this might have some useful insight to aid in your project.

Thanks for the advise but I did follow this thread and had it in mind while posting, so there was no need for me to use the search function in that specific case

But tuxbg himself warns in the first post of this thread that he uses "minimal system installation". This is easily confirmed, as he rebuilt 291 packages, out of 1142 listed in PACKAGES.TXT in Slackware64-14.0. So yes, tuxbg's endeavor is interesting and helpful but no, it does not support your claim that "Slackware was able to rebuild against itself".

2 members found this post helpful.

The minimal GNU developer and tool system along with the Linux kernel and module handing tools is all you technically have to build, and tuxbg did actually get it built, with some work mind you but he did get it built. The rest is just add-ons. If you follow the LFS handbook with exceptions according to the Slackware packages, build scripts, and patch works, you need a handful of packages to get a working system without adding in extra software.

His audit of the packages and available sources was actually invaluable in a research perspective that the system is self-buildable, though it will take work, but then again which OS doesn't take some elbow-grease?

It's a shame we don't have more audits done to the Slackware source to see if it is minimally buildable. It could be useful to a researcher to see if there are any incompatibilities and problems that could be lingering in a package, especially those from even SlackBuilds, and not just the main project itself.

For Bart, having a Slackware from source buildable unit, could prove key to his research to look for potential problems and incompatibilities. This link below was from the LFS attempt at getting it working. It's unmaintained, but it does have some insights that could prove useful. I've built it in a VM, but it had some issues with service daemons not shutting down properly as others have noted and an improperly dismounted disk image that resulted in a corruption and data loss in the VM, though luckily it was only a virtual disk.

http://www.linuxfromscratch.org/lfs/view/systemd/

Unlike other distros, Slackware is not built from scratch on every release. Live with it. The old mantra "if it ain't broken, don't fix it" is quite strongly adhered to. Also, tuxbg was not building Slackware "from scratch", but rather rebuilding on top of a pre-installed minimal Slackware.

If you want a real "from scratch" experience you may be able to adapt my Slackware ARM bootstrap for x86_64 or i486 (should not be hard to do: http://taper.alienbase.nl/gitweb/?p=bootstrap.git . Note that this port to ARM was started from absolute scratch and modifications to the official SlackBuilds went into that git repository when a package would not compile out of the box. I intend to use my X-mas holiday to polish up that port and bring the bootstrap, but also the remaining packages, on par with Slackware 14.1.

I have a very different idea when I read the word "audit" by the way.

Eric

3 members found this post helpful.

@ReaperX7: I know the link of the systemd of LFS,
it has been useful in some ways.

However beteen v204 and v208 is a period of 5 months.
I started with these slackbuilds with version v204 (after reading the LFS systemd attempt) and at that time I had some different issue, shutdown hanging, mounts not always working etc.

Since the v206 release these things seems to be solved, and since the v208 release I have not notice any issues so far.
every single release of systemd has solved a lot of issues.
This is also the reason that I started to post here to see if other people have any issues or not.
and if so, we can use it to improve the slackbuild or submit patches upstream, so that in future systemd releases we dont need to use patches and it would be easier to adapt to systemd for slackware if it comes that far.

Have you considered at this point Bart to draft up a forked distribution of Slackware for research and development purposes?

Even better would be to look in the yocto project (based off of openembedded).

I did exactly that. Following these instructions.
http://metaeca.wordpress.com/create-...ono-and-yocto/
It took three days and 37 some-odd gigs of source storage to build a 300 meg "minimal" distro.

It, unfortunately, has systemd.
http://pastebin.com/9G08tKYB


But where I'm wanting to take it, is add some extra "layers":
http://layers.openembedded.org/layer...master/layers/

(elightenment or xfce, multimedia/guacamayo, and meta-ti)
And compile it for an ARM OMAP processor).

(and use it on a B&N nook)

or at least that's my plan.

yes, they do exist

What I knew before this thread: systemd sucks
What I learnt on it: why

Do you have a link for it?

The answer has been given already in this thread (see post #167 and my answer in post #168).

For the record, with the Thread Title formatting with all the dots.... everytime someone posts a new reply my screen shows in bold blue print "...Slack needs systemd" and it feels like someone defecated on the kitchen table and I have to suppress a choking, gag response. Sheeesh! Just sayin'.....

Oh I see. Well, it looks like he rebuild eveything that was needed. As far as I know, from that point he can rebuild everything else but I might be wrong.

You'll know when it will be done, if that ever happens.

Ok, I just fail to realise how being able to do that is or not an advantage.