Execute the cdrdao.SlackBuild, in the properly directory and you well see the truth.

BTW. I known the "required" patches to finalize the build, but... where I can yell?

You've abandoned your claim that cdrdao bricks every optical drive it runs on, then?

I asked you to prove these claims, and your idea of proving them is to... just repeat them?

1 members found this post helpful.

EDIT (The implication is that you can rebuild it all from a single simple build script) /EDIT

But that is a total fabrication... you just made that up too...

All Slackware build scripts are in the source directory.

I did not want to explain anything to him because he is a troll.

But, it's really quite simple. There is no "build it all" script used for Slackware. Packages are rebuilt when the need arises (and only then) but that is handiwork, and it involves nothing more than the stuff you find in the source directory.

The reason that there is no build script for the kernel sources is because the package for those is hand-crafted.

Eric

Of course that is total bullshit. The GPL requires you to make available the source code and scripts used to produce the binaries, which is exactly what you find in Slackware's source tree.

When you want to rebuild a package you will often find out that compilation fails because the overall system has been modernized (compiler, libraries, kernel) and some old software no longer compiles. That is of course the reason why you should (1) use a more up to date release of that software, or (2) find patches that make the old software compile again...

Eric

Well, without patches, you are not able to build this CDRDAO package in the slackware-current. So, no binaries, no CD/DVD RW control. Nothing. Because, IF one package build fail, your build fail. I known... It's difficult. I can try to find "yet another package that fail to build" in a easy way... Don't worry.

Well, you explain exactly WHY I used the CDRDAO package example. Slackware offer the entire source code, but this thing have no value in the current operating system. This is called "false open source".

I can build CDRDAO from source in the current Slackware? No. This is a false claim of GPL.

You have no idea what you are talking about, and you are making that very clear to everybody in this thread. Thanks. Now, go away and read the GPL license file (for the first time perhaps?).

Eric

LuckyCyborg, you seem to have a very strange idea of what is meant by Open Source. You have received the answer several times in this thread - notably by one of the Slackware team and you continue to persist in denying what you have been told. So, Open Soure means the sources are available to all (Slackware meets this requirement, by the way), yes you can rebuild Slackware entirely from scratch but there is no automated way to do it and to do it involves understanding what you are doing.

My suggestion to you, if the rebuild requirement is so important, is to grab the sources and the scripts and grab any release notes and a copy of the LFS book and go away and do it. That way, you can satisfy yourself that it is possible but hard.

Clearly you are refusing to accept the answers given to you and so this is the only way you will learn the truth of the matter.

I realize that Alien Bob and now a moderator have chimed in so I'll keep my post non-provoking, as much as possible.

The sources for cdrdao, for example, ARE the sources used to build the package. The fact that it doesn't work *now* does *NOT* mean they used different scripts to build the package -- it doesn't work *now* because it fails to compile against newer system libraries or with newer gcc etc. and that build script would have to be updated to work. However, the binary package that ships with Slackware *WAS BUILT* using those scripts -- just before all of the upgrades that have stopped the script from working. There is no breech of the GPL here -- Slackware has not used any scripts other than what is provided to build the software (with the notable exception of the kernels, which as far as I can tell were not really built with one script anyway and thus no breech there either). If that package is ever rebuilt in the future, the build script would be updated and it would work in current Slackware again (until it breaks again). Things I think have changed recently with the modernization of WindowMaker but there was a time when it was not possible to rebuild it, and since it had been abandoned there was no effort to fix that. It is *unfortunate* but not *illegal*.

There are distros that attempt to rebuild every package through each version, but Slackware isn't one of them -- this isn't necessary and frankly would be a bigger burden for the Slackware team. If you want the best possible help to rebuild the entire system, start from Slackware64, which obviously *did* have to be built from scratch much more recently than 32-bit Slackware, and work from there. You would probably have to use newer package versions for some software or apply patches and possibly rewrite more than a few build scripts, which again is unfortunate -- but there is no legal breech here.

Hi Eric,

Thanks for your reply.

I didn't mean to imply anything, i was just curious. So thankyou for clarifying.

I think before making these accusations you should read the ChangeLog.TXT from 13 to current, search for Ponce's threads revealing his efforts to patch slackbuilds from SBo and go through the LFS book to see how a linux system is actually built. At the very least you'll need a machine to host the initial build, a second toolchain to begin building the target system, and then there is likely to be a rebuild of the toolchain for the target system, which can finally build it's own packages. You'll also realize that there is a lot of time and effort involved in that so you'll be able to understand that there is a real good reason for a team with limited resources to not rebuild every single package on every single new release when there is likely to be no benefit other than to satisfy someone obsessed with a single point. That's not really the Slackware way. Slackware to some extent is what it is precisely because things don't just change on a whim, but only rather only when there is good reason to do so. At least that's my take on it.

1 members found this post helpful.

Well, I will use a shameful excuse to stop the war today; too much beer. Strange for an Russian but that's truth. I don't like vodka.

I will love to talk about building Slackware packages next day, but... now, I glad to see you! I'm out!

We give you the exact sources that were used to compile the packages. There's no guarantee (nor GPL requirement) that these sources will compile under any arbitrary development environment (including any particular version of Slackware).

Anyway, "Lucky", since you like to play a lawyer online, do you know much about libel laws?

4 members found this post helpful.

OK, both Eric and Pat Volkerding have responded. They have both said the exact same thing - the sources provided are the sources they use to create Slackware. And that is what everyone else has said too. And since this is getting to be a little too provocative, I am closing it.

So, if you are still unconvinced, get a copy of the GPL and look through it to see where you believe Slackware and the team are in violation. And then report them to the appropriate people. However, everyone else is satisfied that Slackware does not breach the GPL.

Pat and Eric - many thanks for giving up your time to respond to this. I am sure that you have better things to be doing. Like making Slackware exactly the way I want it to be