...

Please try passing the --enable-closure flag to the configure script; it is a poorly documented and obscure flag that is required to build Trinity correctly under the newer gcc versions.

To all build scripts or just kdebase?

Just kdebase for now; if other modules fail in the future, --enable-closure would be the first thing to try adding to the configure flags.

Tim

...

Just kdebase for now; if other modules fail in the future, --enable-closure would be the first thing to try adding to the configure flags.

So the flag is more or less a troubleshooting device?

No, it forces certain linker flags in the generated Makefiles. If the flag allows the package to compile, keep it.

Tim

...

No, it forces certain linker flags in the generated Makefiles.  If the flag allows the package to compile, keep it.

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 would go with chroot myself (and do so on the QuickBuild system). Without further information about Slackware I can't help out much more on this topic; I know Debian provides a tool that can create a minimal chroot image given only the release codename and URL to package repository. Perhaps Slackware has something similar?

Once you have the chroot, it is very simple to use: chroot /path/to/chroot/root/directory

Then do whatever compilations, etc. inside that shell. When done, a simple "exit" command will return you to the host system.

Tim

FYI:

The web site patches page (http://trinity.pearsoncomputing.net/patches/) is empty.

Not good!

Lesser note, I notice the page does not update automatically to keep sync with SVN.

It only syncs once each night; I can set it to sync more frequently but at a greater risk of the blank page problem occurring, as a bad/slow Internet connection can wreak havoc on the generator program.

Hope this helps.

Darrell

Thank you for informing me of the issue!

Tim

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

1. What process do you use to identify which daily svn changes require building new packages? If I am going to support this project then I should eat my own dog food and update packages regularly.

2. Any tips about configuring kdevelop? I'd like to start learning C++.

3. Is there a way to import trinity svn into a kdevelop project? If I can get setup then perhaps I can start trying my hand at small patches.

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