OK, try it again with SVN revision 1173253 or newer.
Aargh!
Rebuilt kdebase. FTBFS. Log attached.
OK, try it again with SVN revision 1173253 or newer.
Aargh!
Rebuilt kdebase. FTBFS. Log attached.
Looks like you are getting much closer! Try it again with revision 1173590 or above.
For some reason when I do a build test here these issues don't show up, so something is different (stricter?) under Slackware.
Tim
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:
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
Looks like you are getting much closer! Try it again with revision 1173590 or above.
Okay. Updating svn now as I write and will try again.
For some reason when I do a build test here these issues don't show up, so something is different (stricter?) under Slackware.
I would not know. :( I wish I could help. There are many Slackers who could answer your question. Getting them involved is something else.
Some people might argue Slackware is "more pure" than Debian with respect to patching upstream code. Generally, that probably is correct. Patrick Volkerding tends to resist patching upstream sources. He patches as often as necessary to get things to function in Slackware, but prefers to provide upstream tools as intended by the upstream developers. Possibly then a missing include file works on your setup because you have and expect Debianized sources where that won't be true with Slackware.
I notice from some of the patches you make that the tqtinterface layer contributes to some of the differences. In several of the patches all you did was add a single tqtinterface include file. Possibly your system finds those files but can't on Slackware without explicit declaration. Is there a way you can configure or test your system for strict explicit declarations?
You never have shared that adding all of these specific include file patches cause failures on your build system for Debian and Kubuntu. Thus I'm guessing these patches probably make the system more robust and less prone to other errors. I suspect that is a good thing despite being an awkwardly slow process to get this to work on Slackware.
I realize there is MUCH to know with what needs to be repaired with these errors. Yet is there some guidelines I can follow to try to patch things here? Yes I have other things to do and a little patience doesn't hurt, but sure would be nice if I could try to find a simple patch here and test rather than wait for you to patch. A little frustrating for me and I know you're swamped. If I could learn to understand some of the error messages I could expedite this process a tad.
<snip>
I notice from some of the patches you make that the tqtinterface layer contributes to some of the differences. In several of the patches all you did was add a single tqtinterface include file. Possibly your system finds those files but can't on Slackware without explicit declaration. Is there a way you can configure or test your system for strict explicit declarations?
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 never have shared that adding all of these specific include file patches cause failures on your build system for Debian and Kubuntu. Thus I'm guessing these patches probably make the system more robust and less prone to other errors. I suspect that is a good thing despite being an awkwardly slow process to get this to work on Slackware.
You are correct; each change does not break Debian, but instead seems to make the build process more robust.
I realize there is MUCH to know with what needs to be repaired with these errors. Yet is there some guidelines I can follow to try to patch things here? Yes I have other things to do and a little patience doesn't hurt, but sure would be nice if I could try to find a simple patch here and test rather than wait for you to patch. A little frustrating for me and I know you're swamped. If I could learn to understand some of the error messages I could expedite this process a tad.
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
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).
My local rsync scripts are heavily modified for local usage, but are based on these original scripts:
http://connie.slackware.com/~alien/tools/rsync_current.sh
http://connie.slackware.com/~alien/tools/rsync_slackware_patches.sh
Those two scripts, modified for your QuickBuild system, should help you sync any Slackware mirror.
I would expect you to hold off for a bit yet as long as I am still here doing the grunt work. :) But eventually you'll need something like those scripts to keep the sources synced.
Regarding my build scripts I think I now have them written to support fully automated runs. Of course, I won't know this for certain until we know that all the (main) packages build without errors. :) When we get that far I plan to run several tests.
I can send you copies now, but I am likely to modify them again. We still have several main packages to go and with each new package that I try to build, seems I need to tweak the entire process just a bit.
The original Slackware build scripts were noticeably generic and did the job, but we no longer are dealing with generic stock KDE sources. I also am trying to think ahead for other Slackers and build versatile and robust scripts for them. For example, some people will want to build from svn and some from source tarballs. When you go live with Slackware support, those build scripts should be flexible for many kinds of Slackware users and not just me. :)
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.
Noted! Thanks.
Is there a pecking order in which include files must be listed in the declarations? Or is including those files similar to sourcing files in shell scripts and the order is (most of the time) unimportant?
Is there a pecking order in which include files must be listed in the declarations? Or is including those files similar to sourcing files in shell scripts and the order is (most of the time) unimportant?
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
I tried to search the developer list and received the following error message:
Error: Failed to load KinoSearch modules.
Darrell
I want to test my build scripts against source tarballs. How do you plan to provide source tarballs when 3.5.12 goes official?
To test here, I presume I need to strip the svn directory of the svn files and directories. Yet how are you planning to provide the make and configure files in tarballs?
Are you going to provide static snapshots of the make and configure files, as was the practice back in the original KDE tarball days, or are you going to expect end-users to build those files like we do now with svn?
Darrell
I want to test my build scripts against source tarballs. How do you plan to provide source tarballs when 3.5.12 goes official?
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.
To test here, I presume I need to strip the svn directory of the svn files and directories. Yet how are you planning to provide the make and configure files in tarballs?
Are you going to provide static snapshots of the make and configure files, as was the practice back in the original KDE tarball days, or are you going to expect end-users to build those files like we do now with svn?
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
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?
I'm no expert. I trust your expertise. Currently my concern is ensuring my build scripts support both svn and tarballs.
I will test with the presumption that the make and configure files will be built locally on-the-fly.
I agree that building the make and configure files locally sounds safer. :)
I'll probably copy the instructions off the Wiki and place them in a text file called BUILDING or similar.
Thoughts? Comments?
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?
I'll probably copy the instructions off the Wiki and place them in a text file called BUILDING or similar.
Thoughts? Comments?
To create a tarball locally, do I need to do anything special other than remove the svn files and directories?
Nope.
Past practice for KDE tarballs was tar.bz2. Is this going to be the case for 3.5.12?
Yes.
Tim
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
-
Darrell Anderson -
Timothy Pearson