Okay. I restored the .h file and kept the mod in the cpp file. I tried building with that setup.

Results were the same --- a failed build after about 20 minutes. I don't know if that result will change by moving to a virtual machine environment with 3.5.10 not installed.

I will try that next!

I'll keep testing as my schedule allows the next few days but I know I won't be able to provide much attention thereafter for a few weeks. I should be able to putter and tinker a little bit during that time, so any bugs we resolve now will help much the next few weeks.

Do you have the Slackware equivalent of the libgssapi-krb5-2 ( http://packages.ubuntu.com/lucid/libgssapi-krb5-2 ) package installed?  If so, can you send me a listing of all files that it installs on the system?

If this package is not needed for KDE3.5.10 under Slackware then I will see what is needed to remove it as a build requirement.

No such package is installed in Slackware.

There is a kerberos (krb5) package available in the slackbuilds repository.

I could build the package and send you a package listing, but krb5 is not a requirement in Slackware.

Let me know what you need.

When building arts in my new build environment I notice the following messages when building. I don't know whether the messages are harmless or meaningful.

(repeats several times with different line numbers) ltdl.c: In function 'sys_dl_open': ltdl.c:605: warning: unused parameter 'loader_data'

(repeats many times with different line numbers) gslmath.c:1005: warning: suggest explicit braces to avoid ambiguous 'else'

(repeats many times with different line numbers) gsloscillator-aux.c:37: warning: unused parameter 'ifreq' gsloscillator-aux.c:38: warning: unused parameter 'mod_in' gsloscillator-aux.c:39: warning: unused parameter 'sync_in' gsloscillator-aux.c:40: warning: unused parameter 'pwm_in'

(repeats several times) libtool: link: warning: `/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../libstdc++.la' seems to be moved (the file exists at /usr/lib/libstdc++.la so I don't know what is checking in that directory.)

The package compiles and the package size seems reasonable. Package contents are the same as the original stock 3.5.10 package.

Darrell

The kdelibs sources were modified to avoid compile errors when the --disable-dnssd option is used and avahi is not installed.

In the stock Slackware build script that option is not used. The stock Slackware build script compiles without those errors.

In configure --help, the default option is not explicitly declared. Only the --disable-dnssd option is mentioned in the help output. There is no --enable-dnssd option mentioned in the --help options. I think the latter option is valid, however. In the stock configure there is a test for --enable-dnssd. One way or another, I presume that dnssd support is enabled by default.

To the best of my knowledge Slackware does not include any kind of dnssd service. So an obvious question is why does the Slackware build script not fail?

The stock configure file contains the following mild warning:

if test "$have_libdns_sd" = "no"; then echo "" echo "You're missing Apple mDNSResponder 85 or later, therefore" echo "dnssd will be compiled as stub, without any real functionality." echo "If you want zeroconf support (www.zeroconf.org), you should install mDNSResponder first." echo "See dnssd/INSTALL for details." echo "" all_tests=bad fi

I think this warning is the same as Trinity KDE. Yet the stock KDE 3.5.10 builds without halting if no such service is installed while the Trinity version does not.

Based upon that warning, kdelibs should compile with or without the --disable-dnssd option and the KDE DNS-SD watcher service should compile as an unfunctional stub.

At this point I don't think being required to use the --disable-dnssd option is the correct approach.

Related to this issue, what will happen if I compile kdelibs with avahi installed, but an end-user installs that package without avahi installed? Will KDE choke or spew forth a bunch of error messages? As we have not yet ironed out the bugs that will allow me to install these recompiled packages, I have no idea of the result. I can see the KDE DNS-SD watcher service in the my stock version of the Control Center. Hopefully compiling with avahi but installing without causes no problems and the KDE watcher services just shrugs, so to speak. I can add some verbosity in the build script explaining that building with avahi installed is a good idea but installing the kdelibs package does not require having avahi installed.

I doubt the Slackware maintainer compiled kdelibs with avahi installed. He's not that kind of person. His philosophy is to provide a basic operating system. If an end-user wants DNS-SD suppor then that would be up to the end-user. Therefore I think kdelibs should compile without needing the --disable-dns option or having avahi installed.

I have all the original stock KDE 3.5.10 sources. Please let me know what information to forward to better resolve this issue. I can send anything from the stock Slackware build process too.

Thanks.

Darrell

1. In which package is the mouse cursor defined? I want to make the

passive mouse cursor the default when I build the package. Where do I do that in the code?

I believe that is the default; if you want to verify that search in kdelibs or kdebase for the mouse cursor control code.

2. I'm unsure, but I think your modified Kubuntu uses the oxygen mouse

cursors as the default. I want to set the traditional mouse cursor as the default when I build the package. Where do I do that in the code?

That is the Ubuntu system default, not a Trinity default. Trinity honors the system wide settings unless specifically told to override them by the end user.

3. When a person runs the Personalizer applet, usually run the first time

a person runs KDE, I want the passive mouse pointer set when the person selects zero desktop effects. Where do I do that in the code?

Not sure OTOH. I believe the kpersonalizer code is in kdebase.

4. The default mouse double-click time is too fast. People with

disabilities cannot operate the mouse buttons that fast. I want to set the default double-click time to about 700 ms. Where do I do that in the code?

Look for the mouse configuration module in kdebase/kcontrol and change the default value in the appropriate configuration template file (*.kcfg).

I realize some of this might require enhancement requests in the bugzilla, but I need to know where to start looking.

Thanks.

Darrell

That is exactly what happens when you use the --disable-dnssd flag.  I am a bit confused as to why you do not want to use the flag; you are disabling a built-in Trinity feature (which I have no problem with), but why do you want the feature to be off by default?  Other distributions would take the opposite approach, wanting everything turned on by default. I personally would like to keep all Trinity features enabled by default; this avoids much confusion as to why stock source builds don't support feature <X> that was advertised by the Trinity project itself.

Ah, okay. My mind is/was stuck in thinking like the default Slackware and not the default Trinity. For whatever reason, the default with the original stock 3.5.10 must have been off by default.

I'll add some comments in the build script so users understand the change and need for the option.

<snip> > but krb5 is not a requirement in Slackware. > > Let me know what you need. > </snip>

That was part of it! ;-)

Is the previously mentioned error still occurring in the virtual machine build?  It may have originally arisen due to the old KDE3.5.10 header files, and krb5 may be a red herring.  I will wait for the build log from the virtual machine before passing judgment.

I sent the build log in a previous message.

As a comparison test, I built the kdelibs package with the stock 3.5.10 and there were no messages about -lgssapi_krb5. Thus something has changed since then. :)

I searched the kdelibs sources and found only two files using the lgssapi_krb5 term:

kdelibs/kioslave/http/configure.in.in: GSSAPI_LIBS="${GSSAPI_LIBS}-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err ${LIBRESOLV}"

kdelibs/kioslave/http/Makefile.am:kio_http_la_LDFLAGS = $(all_libraries) $(GSSAPI_RPATH) -module $(KDE_PLUGIN) -lgssapi_krb5

The kdelibs/kioslave/http/configure.in.in files in svn and 3.5.10 are identical.

I looked at the two configure files but found nothing obvious why the svn version requires krb5.

The configure --help output mentions a --with-gssapi= option, but I found no clue as to which option to pass to disable that support. I tried NOTFOUND but that did not work.

Hopefully this information helps you!