>> Yes.  All of that information is available on the
>> QuickBuild system (
>> https://quickbuild.pearsoncomputing.net/~trinity/+archive/trinity
>> ), but
>> keep in mind that it was built for Debian, and therefore
>> includes
>> Debian-specific patch files.  Click on the package
>> name you want to see
>> details for, then look for a tar.gz file.  That file
>> contains the source
>> code that produced the binaries listed.
>> >
>> That build *will* fail for the reasons you mentioned.
>> 3.5.12 will be
>> released within the next couple of months; wouldn't you
>> rather wait and
>> iron out the remaining build bugs in SVN?  Just a
>> thought.
>
> I'll think about all of that.
>
> Bottom line, yes I can wait. Yet I am making such horrific progress
> getting these packages to build on Slackware. Just a tad frustrated. I'd
> like at least the benefits of 3.5.11.
>
> I have individually patched 3.5.10 to support xz in Ark, added the process
> manager to the panel, and updated kdelibs to support inotify requirements.
> A nice start but I would like to enjoy the other changes too. I wanted to
> add support to 3.5.10 for resizing the system tray icons, but I don't all
> of the required patches.
>
> I'll wait another week or so before deciding. If by then we are close to
> getting svn working in Slackware then my qyestion is moot. But if not, I
> might consider that side route.

Speaking of which, how is kdebase building (or not)?

>
> With that said, what is your policy about releases? When do you place a
> freeze on tinkering and then focus solely on bug fixes to set a release
> date?

We are fast approaching a feature freeze.  I think I'll set it at
September 15 at this point; that will leave a few weeks to debug anything
major prior to the 3.5.12 release, which will most likely coincide with
the release of Ubuntu Maverick.  Any debugging information you can give me
in the meantime would be great; I would very much like 3.5.12 to build
properly under a non-Debian distribution.

Thanks!

Tim