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