You now have links posted to provide instructions for downloading binaries. Hopefully we will see some Slackware links if we ever get to the point of successfully building all packages. I'm sure that day is near, but seems so far away with each FTBFS error. :) You asked for information to build Slackware binaries on your QuickBuild system. I'm using Slackware 12.2. That is where I have done my testing. So 12.2 will be the first link in your web page list. :) The primary feed for all Slackware mirrors is Oregon State University. The top level link: http://slackware.osuosl.org/ Slackware 12.2: http://slackware.osuosl.org/slackware-12.2/ Please do not use the slackware.com site to sync the tree. The Slackware maintainer, Patrick Volkerding, is one of the few people who abides by the letter in making the build sources available. With each release, the sources are found in a directory by that same exact name. There are two source directories in each release tree. One you will find in the top level of the release tree. The other source tree is found in the patches directory, which is where security patches are found. I maintain local mirrors on my systems. I'm guessing you are interested only in the source trees and not the full trees. Hence, much less space will be required. To help you gauge storage space requirements, here is my approximate usage locally for each source tree: 12.2: 1.9GB 13.0: 1.9GB 13.1: 2.2GB Current: 2.2GB 13.0 (64-bit): 1.7GB 13.1 (64-bit): 1.7GB Current (64-bit): 2.0GB I use a shell script that is an rsync wrapper. I can send you a copy of the script if you like and you can strip the script to essentials. Die-hards and snobs will consider the 12.2 release obsolete (Dec. 2008). Yet that was the last Slackware release officially supporting KDE 3.5. Hence, a very good place to start. Slackware releases are maintained a very long time. Much longer than just about any distro available. Thus, 12.2 is not obsolete by any means. Only security patches are provided for past releases. So after you create a local mirror for your build system, there should be little that changes and probably nothing will change that will affect building 3.5.x packages. After I am reasonably content the 3.5.12 packages build and function correctly on 12.2, I hope to update my base system to Slackware 13.1. I have no plans to move intermittently to 13.0. I already tried that when 13.0 was released. 13.0 comes with the 2.6.29 kernel. The network driver in that kernel that I need to use is broken and never was repaired correctly. The driver works as expected in 2.6.28 and 2.6.30. Hence, my reason for not updating to 13.0 as an interim step. With that said, I can set up some testing partitions to at least locally test the 13.0 build process. Building packages on Slackware is much the same as most distros: shell scripts. When we both are comfortable that 3.5.12 builds and runs as expected on 12.2, I can forward you copies of my build scripts. I have expanded the original Slackware build scripts to support Trinity. The build scripts you'll find in the 12.2 sources won't work for Trinity. Again, you can strip those build scripts to essentials because you want to run non-interactively for nightly builds. Regarding your web page links, there are some command line tools Slackers use to automate the update process. Most use a tool called slackpkg. I don't use the tool, but the general idea is similar to apt-get. Your web page instructions will need information for both binaries and source files. Those folks using tools such as slackpkg will want the locations of the final binaries. They will update their slackpkg configuration with those source locations, just like updating sources.list in Debian. As I mentioned previously, there are many Slackers who prefer to build from source rather than download binaries. They will expect to build locally and will want the locations for the source tarballs and not the svn tree. Those who want to use svn will do so on their own and likely will join the discussion list. My build scripts currently look for the svn tree. I have them designed to support building 3.5.10, but I plan to modify that design to work with the final 3.5.12 tarballs. Anybody who wants to nit-pick around the web for individual patches to run 3.5.10 can use the original 3.5.10 build scripts and hack to their heart's content. When we finally get some working packages, I suppose then we start testing links and mirrors. Let me know what additional information you need. Darrell

<snip> Not easily it would seem. If this keeps up I will need to install Slackware on a VM here, but that will take a few days when downloads are included and also would require me to have a current copy of your build script(s). You are correct; each change does not break Debian, but instead seems to make the build process more robust. Generally what I do is look for a class name at the failing line number, then search the entire Trinity source directory for <classname>::<classname>, where <classname> is the class name you found referenced in the failing file. When I find it, I look for a .h header file with the same name, then include that in the failing file. Hope this helps! Tim

Well, new #includes should go under existing ones within their respective blocks, unless that would cause a build failure. Typically, system defines are in the first block, then TQt defines in the next block, then Trinity defines in the next, the finally any local includes (the includes in this last block are in quotes, not angle brackets). Note that this is specific to the Trinity project and is merely a style preference. Tim

Fixed. Thanks for letting me know about the problem! Tim

Most likely in two forms; one tarball for each module and application, and also one large tarball containing all modules and applications, with the individual tarballs contained therein. Each individual tarball will contain the application and a copy of the shared admin directory required to build it. With the variety of platforms Trinity targets, I am concerned that providing static configure and make files will be more trouble than it is worth. You can get very strange errors if the automake files on the system are even a slightly different version than those that generated the static files (trust me, been there done that!). Now consider that Trinity officially supports Debian Lenny through Ubuntu Maverick (at this point) and I think you have a recipe for disaster. I'll probably copy the instructions off the Wiki and place them in a text file called BUILDING or similar. Thoughts? Comments? Tim

To create a tarball locally, do I need to do anything special other than remove the svn files and directories? Past practice for KDE tarballs was tar.bz2. Is this going to be the case for 3.5.12?

Now that I can build the foundation packages of arts, kdelibs, and kdebase, I am testing the remaining packages. So far: kdebindings, nope kdeaccessibility ,yup kdeutils, yup kdemultimedia, nope kdenetwork, yup kdeadmin, yup Seems the --enable-closure option is necessary for most of these. Darrell