I'm attaching a text file of the build output.
Regarding avahi, I just built and installed the avahi 0.6.25 package. Not the latest version, but all I can install because I have an older GTK2 package.
I saw no error messages when trying to build kdelibs with avahi installed. Thus, my concern about Debian-specific package names was unfounded. I notice in the avahi package contents the files your build system seeks are include files, which would be the same on any system.
I installed avahi only to test the build process. I don't think avahi should be a prerequisite and the stock Slackware does not provide that package. Anyway, good news that the build works with or without avahi.
I hope the attached file helps.
Suspect messages I notice in the config process:
lua.h was not found or was not usable, Lua 5.0 headers are required ! ... configure: WARNING: Could not find krb5-config ... configure: creating ./config.status wrong input (flag != 4) at admin/conf.change.pl line 117, <> line 1998. ... config.status: creating kdecore/kde-config.cpp config.status: WARNING: 'kdecore/kde-config.cpp.in' seems to ignore the --datarootdir setting
D.
I'm attaching a text file of the build output.
Regarding avahi, I just built and installed the avahi 0.6.25 package. Not the latest version, but all I can install because I have an older GTK2 package.
I saw no error messages when trying to build kdelibs with avahi installed. Thus, my concern about Debian-specific package names was unfounded. I notice in the avahi package contents the files your build system seeks are include files, which would be the same on any system.
I installed avahi only to test the build process. I don't think avahi should be a prerequisite and the stock Slackware does not provide that package. Anyway, good news that the build works with or without avahi.
I hope the attached file helps.
Yes it does. Can you try this test: In the file kdelibs/kdecore/kxerrorhandler.h, insert the following line:
#include <tqevent.h>
directly before this block of text:
#include <tqvaluelist.h> #include <tqwindowdefs.h> #include <kdelibs_export.h> #include <X11/Xlib.h>
Retry the compilation; if it gets farther please let me know.
Suspect messages I notice in the config process:
lua.h was not found or was not usable, Lua 5.0 headers are required ! ... configure: WARNING: Could not find krb5-config ... configure: creating ./config.status wrong input (flag != 4) at admin/conf.change.pl line 117, <> line 1998. ... config.status: creating kdecore/kde-config.cpp config.status: WARNING: 'kdecore/kde-config.cpp.in' seems to ignore the --datarootdir setting
D.
The following patch has been part of Slackware since June 2007. I checked svn and do not see the same patch being applied. Here is the text from the Slackware change log:
kde/kdelibs-3.5.7-i486-2.tgz: Patched to call utempter in the proper location and with the right arguments. Thanks to Ken Milmore for the patch.
I hope this helps.
======================================== diff -Naur kdelibs-3.5.7.orig/kdecore/kpty.cpp kdelibs-3.5.7/kdecore/kpty.cpp --- kdelibs-3.5.7.orig/kdecore/kpty.cpp 2006-05-22 19:14:21.000000000 +0100 +++ kdelibs-3.5.7/kdecore/kpty.cpp 2007-06-10 14:08:18.000000000 +0100 @@ -401,7 +401,9 @@ #ifdef HAVE_UTEMPTER KProcess_Utmp utmp; utmp.cmdFd = d->masterFd; - utmp << "/usr/sbin/utempter" << "-a" << d->ttyName << ""; + utmp << "/usr/lib/utempter/utempter" << "add"; + if (remotehost) + utmp << remotehost; utmp.start(KProcess::Block); Q_UNUSED(user); Q_UNUSED(remotehost); @@ -444,7 +446,7 @@ #ifdef HAVE_UTEMPTER KProcess_Utmp utmp; utmp.cmdFd = d->masterFd; - utmp << "/usr/sbin/utempter" << "-d" << d->ttyName; + utmp << "/usr/lib/utempter/utempter" << "del"; utmp.start(KProcess::Block); #elif defined(USE_LOGIN) const char *str_ptr = d->ttyName.data(); ========================================
Committed in SVN revision 1167615.
Keep 'em coming! ;-)
Tim
The following patch has been part of Slackware since June 2007. I checked svn and do not see the same patch being applied. Here is the text from the Slackware change log:
kde/kdelibs-3.5.7-i486-2.tgz: Patched to call utempter in the proper location and with the right arguments. Thanks to Ken Milmore for the patch.
I hope this helps.
======================================== diff -Naur kdelibs-3.5.7.orig/kdecore/kpty.cpp kdelibs-3.5.7/kdecore/kpty.cpp --- kdelibs-3.5.7.orig/kdecore/kpty.cpp 2006-05-22 19:14:21.000000000 +0100 +++ kdelibs-3.5.7/kdecore/kpty.cpp 2007-06-10 14:08:18.000000000 +0100 @@ -401,7 +401,9 @@ #ifdef HAVE_UTEMPTER KProcess_Utmp utmp; utmp.cmdFd = d->masterFd;
- utmp << "/usr/sbin/utempter" << "-a" << d->ttyName << "";
- utmp << "/usr/lib/utempter/utempter" << "add";
- if (remotehost)
utmp << remotehost;@@ -444,7 +446,7 @@ #ifdef HAVE_UTEMPTER KProcess_Utmp utmp; utmp.cmdFd = d->masterFd;
- utmp << "/usr/sbin/utempter" << "-d" << d->ttyName;
- utmp << "/usr/lib/utempter/utempter" << "del"; utmp.start(KProcess::Block);
#elif defined(USE_LOGIN) const char *str_ptr = d->ttyName.data(); ========================================
Slackware uses the version number as part of the package name. Currently I am using 3.5.11. Yet I notice in various places that possibly 3.5.12 might be correct.
Does your svn tree contain a version number I can grab on-the-fly in my build scripts?
This would be a typical Slackware package name:
kdelibs-3.5.10-i486-3.tgz
The -3 is a sequential build number for the respective Slackware release.
I could create a package name such as:
kdelibs-3.5.10-i486-svn-2010-08-23.tgz
or
kdelibs-3.5.10-i486-svn_1166993.tgz
Is there a place somewhere in the svn tree to grab the correct date/time or svn release number?
I appreciate suggestions and help.
3.5.12 is the next release, which is being worked on in SVN right now. I have not gotten around to updating the code to refer to 3.5.12 yet, although it is on my to-do list.
Regarding the SVN revision number, I use Python for part of my automated build system. The Python code to extract the version number is as follows:
#!/usr/bin/python #GPL Licensed... run_or_die('svn up') svn_revno=os.popen("exec 6>&2 2>/dev/null; svn log | head -n 2 | tail -n 1 | awk '{print $1}'; exec 2>&6 6>&-").read().strip() while (svn_revno == ''): svn_revno=os.popen("exec 6>&2 2>/dev/null; svn log | head -n 2 | tail -n 1 | awk '{print $1}'; exec 2>&6 6>&-").read().strip() if svn_revno == '' : print "A fatal error occured--terminating" sys.exit(1) print svn_revno
You can copy that into a script and run it from the top level directory of the module you want the revision number of; e.g. kdelibs/, kdebase/, or dependencies/arts/ Be aware that my Email system may force parts of lines into the next line; you may have to manually "reassemble" the longer lines in the script above.
Tim
Slackware uses the version number as part of the package name. Currently I am using 3.5.11. Yet I notice in various places that possibly 3.5.12 might be correct.
Does your svn tree contain a version number I can grab on-the-fly in my build scripts?
This would be a typical Slackware package name:
kdelibs-3.5.10-i486-3.tgz
The -3 is a sequential build number for the respective Slackware release.
I could create a package name such as:
kdelibs-3.5.10-i486-svn-2010-08-23.tgz
or
kdelibs-3.5.10-i486-svn_1166993.tgz
Is there a place somewhere in the svn tree to grab the correct date/time or svn release number?
I appreciate suggestions and help.
I tried using the exec command to run the python script from within my shell script, but then received errors about not recognizing the run_or_die('svn up') command.
Not to worry. I saw enough in your script to derive the following in my build script:
SVN_VERSION="`head -n4 ./src/.svn/entries | tail -n1`"
I will use that variable as part of the package name. For example:
kdelibs-3.5.11-i486-svn_1167630.tgz.
I will have to watch your release announcements to know when to update 3.5.11 to 3.5.12.
Is that major version number cleverly hidden somewhere in the svn tree?
Some success!
I built arts from SVN. The package size is VERY close to the original Slackware package size. No errors!
With that news, hopefully --- eventually --- we find all the bugs to be able to compile KDE from your SVN tree!
D.
-
Darrell Anderson -
Timothy Pearson