Good to hear you got it working, but the G15 daemons and support programs compiled for Slackware 12 are all up on LinuxPackages.net.

Okay, I understand now that you mention debconf. This is part of some fairly old code in src2pkg. When running with pretty normal options, when a build fails it looks inside the sources for an rpm *.spec file or debian control file and parses out the 'depends' info in the file. Of course, you don't really need these programs on Slackware. It's just that src2pkg reads the whole line of info. It's not always very useful -sometimes the thing you are missing is not listed in the depends anyway or the build has failed because of needing certain arguments to configure.
The behaviour has been changed a couple of times -in one recent version I had it printing out the complete contents of the file which was terrible -the whole screen full with mostly useless info. And this was changed back to the former beahviour right away.

This info is only shown if you are running in QUIET mode. If you use -VV for verbosity you'll neve see these printouts. Also, if running in the normal QUIET mode, if you use the -R option you won't see these messages. Instead src2pkg reruns the failed command for you inverbose mode you can see the whole error and what preceeds it. You might try this: when starting a first-time build use the -A and -R options together. That way if the build is successful you get a script written with some detail, plus a slack-desc -also with detail if available, and if the build fails you'll get a 'replay' of the failed command.

Ever since I put the code in which looks into the spec or control files, I had in mind to do more with the information in them. Hence, in the last version (1.8) I had finally gotten around to having src2pkg automatically parse the description info in them and format it into a nice slack-desc file. It also parses out the options to configure from spec files or debian 'rules' files. This is still a work in progress as the options to configure need to be 'translated' from 'rpm-speak' and some variables need to be changes to slackware directory conformance -especially with 'debianized' sources.

Anyway, as to your last suggestion, it is nearly in place. As mentioned, starting with the last version, src2pkg can parse out the Description info from rpm spec, debian 'control', or python PKG-INFO files. It also accepts $NAME.txt files -but these are Slackware-type files that are found along-side the packages. They are the same as the slack-desc file for the sources of the package except that they have no header with a 'handy ruler' and are named $NAME.txt instead of slack-desc.
Since src2pkg always looks first for a slack-desc in the current directory and uses it if found, it was easy to have it look for a $NAME.txt file and treat it like a slack-desc file. If one of these are found and appears to be valid, then no steps are taken to create a new slack-desc -the slack-desc or $NAME.txt you provide is used. If no slack-desc or $NAME.txt is found then it looks for a spec or control file. If neither is found and you are using the -Q option then src2pkg will stop and let you type in a description. Otherwise it creates a default slack-desc with no specific info.

It will be fairly easy to write a few lines which check any $NAME.txt file found and if it isn't just a copy of a slack-desc, then parse the text into a new slack-desc. The real trouble about these routines is making sure there is a good default behaviour. As it is, if a slack-desc or $NAME.txt with the same format is found, then they are used -providing they are 'valid' for the package.

The concept I use for all the accesory files and src2pkg scripts is that, if src2pkg finds one of the files with its' 'real' name the it assumes you know what you are doing. If you place a doinst.sh in the current directory the src2pkg just uses it without question(since they can't even be validated). For the same reason new files which src2pkg generates always have a 'new.' prefix or '.auto' suffix. Once you rename the file to simply its' real name you are telling src2pkg 'Use this and I mean it!' Otherwise they are regenrated each time you rebuild.

I'm still evaluating how the mixture of automatic(-A), interactive(-Q) and deafult(no options) beahviours work -that is what should be done or left undone in each mode. So, feedback is appreciated to help in making these decisions.

I am running 64bit Slamd64 (as is clearly shown in my registration info to the left). I am very aware of the 32bit packages, as I was in contact with the author of it, trying to get a slackbuild for it. Now I don't need to. Next, I will compile g15macro, hopefully.

Shingoshi

I know that you have the EXTRA_CONFIGS for setting configure options. But what about make, where you have an option for the type of system you're building on (linux-x86_64), which needs to be passed to make?

Sorry! I just noticed the option in src2pkg.conf to let you edit the slack-desc file. But I've only been using this for one day, and I admit I also tend to be lazy. If I weren't, I wouldn't be using src2pkg. 8-)

Shingoshi

You can set the make command using the '-m' option: -m=linux-x86_64

I don't have any 64bit machines so I'm not sure, but I suspect that this command is not universal for 64bit builds. One general suggestion to keep in mind is this: Only put options that should always apply into your srcpkg.conf file. For non-standard options that are only used for some packages, use a src2pkg script for the package and place the options in the src2pkg script. Note that, for options which can be set from the command-line, if you inlcude those options and use the "-N" switch, src2pkg will write thise options into the script for you. The whole purpose of having and suing a src2pkg script is to record these 'one-off' configuration changes so that you can easily reproduce the build at a later date, without having to try to remember what you had to do differently for the build.
There is a kind of tradeoff between using the -N option to generate a script before starting and using the -A option which generates a script when finished: the '-N' option won't pick up any information automatically since it doesn't do anything except write the script; the '-A' option will record some non-standard things that it finds during the build process. Still, there are some options which are not available from the command and which must be manually coded into your src2pkg script. but, when using a script, the door is wide open and you can do anything you want in a script -adding code, leaving out steps, repeating steps, making mulitple packages from one source -literally whatever you want.