Slackware from Scratch and X11

nobodino · 01-22-2017, 01:37 PM

This time, back to slackware-current, it is nearly complete (just linux-faq, howtos, hexchat, kdevelop-pg-qt and kdevelop-php packages remains), everything else has been built.
New packages like boost, sed and flex introduces incompatibilities with some packages, which need previous version to be built.
I enclosed a diff-list of the packages in slackware-current (up to 21/01/2017) and those I built.

nobodino · 01-29-2017, 05:17 AM

End of "the game", SFS is complete up to slackware-current-26/01/201, even linux-faqs and linux-howtos.
I enclosed a diff-list of the packages in slackware-current (up to 26/01/2017) and those I built.

worsel · 02-01-2017, 10:01 PM

Nododino,

I've been trying to build Slackware64-14.2 using your scripts from
2017-01-09. Everything seemed okay, except you dropped the patch needed
for a2ps, until build4_s.list. Then "make" started seg-faulting. When
I checked, the "tools/bin" problem was back.

Quote:

aclocal:#!/tools/bin/perl -w
aclocal:eval 'case $# in 0) exec /tools/bin/perl -S "$0";; *) exec /tools/bin/perl -S "$0" "$@";; esac'
aclocal-1.15:#!/tools/bin/perl -w
aclocal-1.15:eval 'case $# in 0) exec /tools/bin/perl -S "$0";; *) exec /tools/bin/perl -S "$0" "$@";; esac'
afmtodit:#! /tools/bin/perl -w
autoheader:#! /tools/bin/perl
autoheader:eval 'case $# in 0) exec /tools/bin/perl -S "$0";; *) exec /tools/bin/perl -S "$0" "$@";; esac'
autom4te:#! /tools/bin/perl -w
autom4te:eval 'case $# in 0) exec /tools/bin/perl -S "$0";; *) exec /tools/bin/perl -S "$0" "$@";; esac'
autom4te:my $m4 = $ENV{"M4"} || '/tools/bin/m4';
automake:#!/tools/bin/perl -w
automake:eval 'case $# in 0) exec /tools/bin/perl -S "$0";; *) exec /tools/bin/perl -S "$0" "$@";; esac'
automake-1.15:#!/tools/bin/perl -w
automake-1.15:eval 'case $# in 0) exec /tools/bin/perl -S "$0";; *) exec /tools/bin/perl -S "$0" "$@";; esac'
autoreconf:#! /tools/bin/perl -w
autoreconf:eval 'case $# in 0) exec /tools/bin/perl -S "$0";; *) exec /tools/bin/perl -S "$0" "$@";; esac'
autoscan:#! /tools/bin/perl -w
autoscan:eval 'case $# in 0) exec /tools/bin/perl -S "$0";; *) exec /tools/bin/perl -S "$0" "$@";; esac'
autoupdate:#! /tools/bin/perl -w
autoupdate:eval 'case $# in 0) exec /tools/bin/perl -S "$0";; *) exec /tools/bin/perl -S "$0" "$@";; esac'
autoupdate:my $m4 = $ENV{"M4"} || '/tools/bin/m4';
Binary file bison matches
c_rehash:#!/tools/bin/perl
Binary file flex matches
Binary file flex++ matches
glib-mkenums:#! /tools/bin/perl
grog:#! /tools/bin/perl
gropdf:#!/tools/bin/perl -w
ifnames:#! /tools/bin/perl -w
ifnames:eval 'case $# in 0) exec /tools/bin/perl -S "$0";; *) exec /tools/bin/perl -S "$0" "$@";; esac'
Binary file lex matches
libtool:SED="/tools/bin/sed"
libtool:GREP="/tools/bin/grep"
libtool:EGREP="/tools/bin/grep -E"
libtool:FGREP="/tools/bin/grep -F"
libtool:lt_truncate_bin="/tools/bin/dd bs=4096 count=1"
libtoolize:: ${EGREP="/tools/bin/grep -E"}
libtoolize:: ${FGREP="/tools/bin/grep -F"}
libtoolize:: ${GREP="/tools/bin/grep"}
libtoolize:: ${SED="/tools/bin/sed"}
mmroff:#! /tools/bin/perl
mtrace:#! /tools/bin/perl
mtrace:eval "exec /tools/bin/perl -S $0 $@"
pdfmom:#!/tools/bin/perl -w

I redid the build, deleting /tools after build1_s.list and running the
attached c.list. No more "tools/bin"lists 2 and 3 built okay. Am about
to launch build4_s.list. Will report any errors.

Attached are the above mentioned c.list and a patch to sfsinit-r29.sh
to add the a2ps patch. Check it out. I tried not to disturb anything
on the 32 bit side, but have had no opportunity to test it.

nobodino · 02-09-2017, 01:19 AM

Back to slackware-current x86_64 up 26/01/2017.

I built everything, as you can see in the enclosed diff.list for x86_64, nothing is left.
I solved the building of p2c, lxc, reiserfsprogs and isapnptools (no more need upgraded packages).
I simplified the building of newspost, procmail and seyon (one "sed line" in the SlackBuild).
I upgraded preelflibs64/postlibelfs64 (missing ncurces-5.9 and libtermcap).
It builds quite the same way as x32 version except for very few packages: xfce, eudev.

I reintroduced dlackware, but it's not active by default, I haven't worked on it for several months: Bartgymnast can play with it.

nobodino · 02-26-2017, 09:34 AM

Back to slackware-current for x86.
-sfsinit as been split in 4 scripts: patch_generator, list_generator, sources_alteration and sfsinit.
-dlackware active: able to build up to xfce.

nobodino · 02-26-2017, 09:35 AM

added the list of the dlackware packages built:

bersl2 · 02-28-2017, 09:30 AM

Quote:

Originally Posted by nobodino

I had to introduce old version of cmake, subversion and taglib from slackware-14.1 in 'others' to be able to build the missing packages.

I couldn't build KDE even in a clean 14.2 container. This is just plain a bug in 14.2, that it can't bootstrap itself. Did you at least report it to Pat?

bassmadrigal · 02-28-2017, 10:21 AM

Quote:

Originally Posted by bersl2

I couldn't build KDE even in a clean 14.2 container. This is just plain a bug in 14.2, that it can't bootstrap itself. Did you at least report it to Pat?

But it isn't a bug... Slackware is not designed to be able to be built from scratch. Some, like nobodino, have done the work to be able to build Slackware from scratch, but anything that prevents them from doing that is not considered a bug in Slackware, and I highly doubt they would do anything to "fix" it.

See this post from Alien Bob (Eric Hameleers, one of the core Slackware dev team members) for more details on how Pat and team see Slackware.

a4z · 02-28-2017, 12:54 PM

Quote:

Originally Posted by bassmadrigal

But it isn't a bug... Slackware is not designed to be able to be built from scratch. Some, like nobodino, have done the work to be able to build Slackware from scratch, but anything that prevents them from doing that is not considered a bug in Slackware, and I highly doubt they would do anything to "fix" it.

See this post from Alien Bob (Eric Hameleers, one of the core Slackware dev team members) for more details on how Pat and team see Slackware.

unfortunately, the situation if this is a bug or not is not that clear. If a package does not build anymore on a current system, than it is -obviously - broken. But some have decided to discuss this fact away. And so Slackware and it's users have to live with some limitations, nothing disturbing, like missing PAM, because those who are disturbed by those facts are already on a different distribution and do not complain here ;-)

bassmadrigal · 02-28-2017, 02:45 PM

Quote:

Originally Posted by a4z

unfortunately, the situation if this is a bug or not is not that clear. If a package does not build anymore on a current system, than it is -obviously - broken. But some have decided to discuss this fact away. And so Slackware and it's users have to live with some limitations, nothing disturbing, like missing PAM, because those who are disturbed by those facts are already on a different distribution and do not complain here ;-)

I guess I should clarify that while it may be a bug, it is not considered a Slackware bug by Slackware devs... because Slackware devs won't care if can't be recompiled if they don't need to rebuild it.

Slackware devs do not consider a package that can't be compiled on the installed system a bug. As you yourself stated in that previously linked thread, for a time, windowmaker wasn't able to be recompiled on a more modern Slackware because it didn't support the modern toolchain. But the Slackware devs kept including the pre-compiled package because it didn't need to be rebuilt against newer libraries.

If the program needs to be recompiled, then Slackware and team will find any issues and resolve them, but just because someone in the community can't recompile a program does not make it a Slackware bug and Pat will likely disregard any bug reports about it.

bersl2 · 02-28-2017, 03:56 PM

Quote:

Originally Posted by bassmadrigal

But it isn't a bug... Slackware is not designed to be able to be built from scratch. Some, like nobodino, have done the work to be able to build Slackware from scratch, but anything that prevents them from doing that is not considered a bug in Slackware, and I highly doubt they would do anything to "fix" it.

See this post from Alien Bob (Eric Hameleers, one of the core Slackware dev team members) for more details on how Pat and team see Slackware.

¯\_(ツ)_/¯

I have no problem with WONTFIX. It's just that it doesn't clearly follow to me (though it is understandable in retrospect) from most treatises on distro philosophy I've read over the years that basic problems building a package are just plain not even worth reporting. Either that, or I completely glossed over those parts. Fair enough, though.

a4z · 03-01-2017, 02:08 AM

Quote:

Originally Posted by bassmadrigal

I guess I should clarify that while it may be a bug, it is not considered a Slackware bug by Slackware devs... because Slackware devs won't care if can't be recompiled if they don't need to rebuild it.

and this is the point where things become ridiculous, unfortunately, and I know more than one person personal who does not use Slackware because of this.

Quote:

Originally Posted by bassmadrigal

Slackware devs do not consider a package that can't be compiled on the installed system a bug. As you yourself stated in that previously linked thread, for a time, windowmaker wasn't able to be recompiled on a more modern Slackware because it didn't support the modern toolchain. But the Slackware devs kept including the pre-compiled package because it didn't need to be rebuilt against newer libraries.

so you get a binary blob, and source code that might be for this binary blob, or not. You do not even know how many version to go back until it works to rebuild. Absurd

Quote:

Originally Posted by bassmadrigal

If the program needs to be recompiled, then Slackware and team will find any issues and resolve them, but just because someone in the community can't recompile a program does not make it a Slackware bug and Pat will likely disregard any bug reports about it.

what was worth for efficiency 20 years ago, because rebuilding world took for ever, is today a question of how to organize your build chain.
some people invest time to show that building the Slackware world is possible, provide order and dependecy and patch information, but it never goes back into the Slackware project. It is just ignored. this is very sad.
if you do not adopt, you are outdated and on the way to extinct, what we see actually happen, even if some who do not want to look outside of their world reject to notice.
Well, if you do not go with the time, than you go with the time, that is the alternative. I am total aware that some will now start to cry around as usual, that they do not need change, and that is is OK for them, but actually, that's not true, because non of these people is sitting in a cave with no fire. So adoption is essential. But all this is of course just IMHO

ponce · 03-01-2017, 03:16 AM

sorry guys but it could be nice to continue this discussion in another topic: nobodino has already stated in the other topic linked that he's not interested philosophical debates so it's not very nice to pollute also this one...

bassmadrigal · 03-01-2017, 11:48 AM

Quote:

Originally Posted by ponce

sorry guys but it could be nice to continue this discussion in another topic: nobodino has already stated in the other topic linked that he's not interested philosophical debates so it's not very nice to pollute also this one...

Thanks ponce. I wasn't trying to get in some philosophical debate. I wasn't stating I agree or disagree with the Slackware team on how they manage this (which as you said, doesn't belong here), just trying to show that they likely won't accept bug reports on the matter.

nobodino · 03-04-2017, 08:31 AM

Back from the "front".

This time I built an experimental SFS up to build2_s.list (blackbox) with a lot of new packages:
- binutils: 2.28
- glibc: 2.25
- gcc: 6.3.0
- xorg-server: 1.19.2
- linux LTS: 4.9.13
I built it with an updated 'tools' (script enclosed), and 50 modified and updated packages (enclosed list in /var/log/packages).
I thought it would be more complicated, but there are very few patches needed to achieve this.
I enclosed also the build1_s.list which a little different from normal: "lzip" before "ed", and "util-linux" before "glib2".
I can't send every modification made to the source tree, but with the version of the package and test each SlackBuild you can do the same.
I'll try now to go further up to xfce.

Nota: It works like a charm!