To all build scripts or just kdebase?

So the flag is more or less a troubleshooting device?

Seems to be working! I'm building kdebase now. Might take 3-4 hours or so, but seems to be chugging hard. Building is much slower in a virtual machine. :( I think I might copy my setup to a spare drive (minus the KDE packages) so I can reboot at night to build packages faster. Or learn to setup a chroot environment. I don't have a fast second machine for this kind of project. Any suggestions?

I have a cron job that runs every night. What it does is fire off a bunch of build scripts in sequence, one for each module (tqtinterface, arts, kdelibs, kdebase, etc.). Each build script keeps a record of the SVN revision number of the last build of that module. Each build script first does an "svn up" on the module it wants to build, and if the version number is not identical to the previous build then it proceeds to upload the package to the automated QuickBuild build system. This is where I would like to figure out a way to interface a Slackware build setup to the QuickBuild backend. That way you can take advantage of the computing horsepower available on the QuickBuild cluster as well as the high speed package mirror. To do that, I would need to know some basic things about the Slackware system: 1. All recent releases / codenames from the version you want to support up through current. 2. Whether a tool exists to create a local copy of the entire Slackware source and package repository, and where that repository (or repositories) reside. 3. The configuration file that controls the repository location on an installed Slackware system, as well as the commands to both perform a full upgrade and install specific packages by name. 4. The control file format for a Slackware package. This one is important, because QuickBuild needs to install all required package dependencies before the build process starts. Each build on this system starts from a bare-bones chroot image so as to avoid any weird interactions like the one you were describing earlier with mesa. It's pretty easy to use...just run the new project wizard and select a Hello World C++ or Qt/KDE project. Look through the code, and when you want to compile and run just hit Shift+F9. Not really. You can use kdevelop to edit the source files in a module, but the build system remains separate. What I would suggest is this: 1. Create a copy of the module you want to alter, including all the hidden .svn files, and change directory to the copy. 2. Run the automake/autoconf/configure portion of your build script (i.e. everything before the actual "make" command). This generates all Makefiles required to compile the code. 3. Edit the C++ source files you are attempting to fix bugs in. 4. Run "make". The first time it will take a long time, then probably fail around your changes unless you are a better programmer than most. Read the output, fix your code, then run make again. Note that the second time around it almost immediately starts compiling the changed file(s)--this is because all the dependent files were already built with the initial make command. 5. When you think you have it all fixed and want to test, just run "make install". If the fixes work as intended, run "svn diff > patch.diff" to generate a patch file, which can be uploaded to the bug report detailing the problem you resolved. It will be reviewed, and if found acceptable it will go straight into SVN. NOTE: If you change ANY Makefile.am files, the entire automake/autoconf/configure portion of the build script must be re-run before the make command can be executed again. Hope this helps anyone trying to get into Trinity development! Tim

FYI: The web site patches page (http://trinity.pearsoncomputing.net/patches/) is empty. Lesser note, I notice the page does not update automatically to keep sync with SVN. Hope this helps. Darrell

Adding the --enable-closure flag stopped the build from compiling so quickly. I think the build ran for about an hour or or more before failing. I'm still fiddling with my build scripts and unfortunately there was no log during this failure. I'm running another build now and the log is working again. Good news is we're making progress, albeit slowly. :) Darrell

Okay, lots to chew on here. I have no formal background or education with software development. Several one-class exposures to some programming languages, but nothing with data structures, etc. I enrolled in a one semester class in C about 23 years ago. Still have the text book but have forgotten almost everything. No formal exposure to C++ or Python, both of which I would like at least nominal skills. Funny thing is I hated vi 23 years ago and I hate vi today too. :) Bottom line is that most of my computer skills are from the school of hard knocks. But I have been attending that school for 30 years. :) Sounds as though you are offering to host final binary packages for Slackware. Do I understand correctly? I have a small personal web site and don't have the bandwidth or capacity to host an off site build process or hosting binary packages. I considered that particular challenge when I posted my web page for this project but don't have an answer. I need to ensure this build process succeeds here locally without issues before moving to the next step of hosting automatic builds. We are progressing forward, albeit at a slow pace. There just seems to be no fast way of getting through this. There are many Slackers who could help, but they have to volunteer. Pure Slackers tend to be much like pure Debians --- stuck in their own little command line world and ambivalent toward improvements. I have used Slackware many years and recently Debian and have seen this behavior among the purists. On the other hand, many Slackers do not trust binaries from anywhere except the stock packages provided by the distro maintainer. Most tend to build their own non-stock packages. This is a peculiar behavior but one I have learned to accept in the Slackware community. I build my own packages too, mostly out of habit, but I'm not religious about that. There really isn't an audience of Slackware users like (K)Ubuntu users who want 100% point-and-click. There is a strong vein of Slackware users who detest point-and-click. As with every single distro community, there are people in the Slackware community who argue what is and what is not the "Slackware Way." Generally, the presumed "Slackware Way" is for end-users to compile their own packages from build scripts. Build scripts are readily available at several popular web sites, but building is presumed an end-user responsibility. Unlike many distros, the default stock Slackware installation includes a full development environment. Thus the tools are all available to perform these tasks. People new to Slackware soon discover this mentality when they post questions at the forums. If they do not possess the motivation to build packages, then they are softly encouraged to move on. I have fought this philosophy many times to no avail. Never try teaching pigs to sing --- you waste your time and irritate the pigs. The point is that offering to host binary packages might be a moot point. Perhaps offering to provide build scripts is all you need. Both of us can do that. As far as syncing the online Slackware mirrors, I use a shell script with rsync that I run manually and from cron. I run the script here every Saturday afternoon from cron. I maintain my own local mirror for releases 12.2, 13.0, 13.1 and Current. You probably would save much time and bandwidth by not syncing the KDE4 packages and sources. There are a handful of command line package managers, but I think the rsync script is what you seek. Slackware packages previous to release 13.0 use a compressed tar gzip format (tgz). From 13.0 thereafter the package system uses tar xz (txz). Hence the urgency to get Ark to recognize those formats. :) I have notes/comments in my build scripts that I need to add dependency checking. Historically, Slackware itself does not provide dependency checking when building or installing packages. Overall most Slackers prefer this, including me. For this project I want to add those checks. Right now my build scripts only remind the user that certain packages must be rebuilt and that the stock 3.5.10 packages cannot be installed or the builds will fail. Right now my build scripts check for the tqtinterface package being installed. The scripts terminate if any dependency packages are not installed. I designed my build scripts to function with your SVN and to support people who want to individually patch the stock 3.5.10. The default is to build SVN packages. I have not yet progressed to testing with releases 13.0, 13.1, or Current. I have only tested with 12.2. With those three more recent releases I would need to rebuild the dependency packages. I then probably would focus on adding some dependency checks and rebuilding options. This is a huge project. I wish I could encourage other Slackers to get involved. There are some really sharp Slackers out there who could move this project faster than me. My web site stats show Slackers are visiting my web page devoted to this project. Yet nobody is offering to help. I am hoping that perhaps when I get the basics rolling and confirm all the packages at least build, that then some of those people might become more interested when they see the improvements you've added to 3.5.10. Hence my interest in parsing the svn logs to create a more readable change log for use as a marketing tool. Possibly part of the lack of interest is the Slackware maintainer declared 3.5.x dead and the die-hards are going to follow blindly. Most people are under the illusion that qt3 is a problem. They do not know that you are building the interface required to adapt to qt4. I think if more people knew that there might be more interest in 3.5.x. My (hopeful) attitude right now is "if we build it they will come." Important is I need to get to the point where all of these packages build without incident AND I am using them on a daily basis. If I am eating my own dog food then that might encourage people to become involved. I appreciate what you mentioned previously about how much you have to do at your end. With the current response among Slackers, at moments I wonder whether all the work I am doing is only for me. :) Well, if that is the case, this won't be the first time a person scratched his or her own itch. If others benefit from my work without helping then great but I get no less than I seek. If I had even rudimentary C++ skills I would be trying to patch things like crazy. In summary, let's proceed with all of this one day at a time. Otherwise I'll overload! Darrell

Hi People I did 5 years of user studies for the, as far as I know, dead distro Ark Linux (my fav of all distro, so its very depressing). The studies ranged from usability, initial impact (how a user responded during the first 1 hour of exposure to a new distro), installation ease or difficulty, kmenu construction, "user" menus and more. The purpose of these studies where to create a distro that users could call their own (rather than dealing with all the nonesense distro do to their releases to customize them, most of which is undone anyway), but was easy to use and understand, customizable to the USER's needs, not the devels person preferences. Logic is key here. It isn't about 1 person's POV, its about the commonalities among them. Would this project be interested in any of this? It would be easy for me to recreate the study in about month (everything is already setup and the users (ranging from 40 to 70 volunteers, ages range 4 YO to 96 YO) have been through the paces, but are still noobie class users. Please be advised I instructed the volunteers to be brutally honest (and bloody hell were they). So please take the results with a grand of salt, should this distro be interested in such a study. Thanks, Kate Draven