Updated svn to 1170271. Rebuilt and installed tqtinterface. Attempted to build arts. Final snippet from the build: Making all in qtmcop make[2]: Entering directory `/dev/shm/arts/qtmcop' /usr/bin/moc-tqt /usr/lib/qt/bin/moc ./qiomanager_p.h qiomanager_p.moc cp: cannot stat `./qiomanager_p.h': No such file or directory sed: can't read ./qiomanager_p.h: No such file or directory sed: can't read ./qiomanager_p.h: No such file or directory moc: ./qiomanager_p.h: No such file cp: cannot stat `./qiomanager_p.h.bkp': No such file or directory /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I../mcop -I../artsc -I../mcop -I../mcop -I/usr/include -I/usr/lib/qt/include -I. -include tqt.h -I../libltdl -I/usr/lib/qt/include -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -march=i486 -mtune=i686 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -ftemplate-depth-99 -MT qiomanager.lo -MD -MP -MF .deps/qiomanager.Tpo -c -o qiomanager.lo qiomanager.cc mkdir .libs g++ -DHAVE_CONFIG_H -I. -I.. -I../mcop -I../artsc -I../mcop -I../mcop -I/usr/include -I/usr/lib/qt/include -I. -include tqt.h -I../libltdl -I/usr/lib/qt/include -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -march=i486 -mtune=i686 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -ftemplate-depth-99 -MT qiomanager.lo -MD -MP -MF .deps/qiomanager.Tpo -c qiomanager.cc -fPIC -DPIC -o .libs/qiomanager.o qiomanager.cc:299:28: error: qiomanager_p.moc: No such file or directory make[2]: *** [qiomanager.lo] Error 1 make[2]: Leaving directory `/dev/shm/arts/qtmcop' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/dev/shm/arts' make: *** [all] Error 2 A little investigating showed the tqt-replace shell script won't parse the dot symbol for the directory path (./). Problem would be in /dev/shm/arts/qtmcop/Makefile.in, lines 671-672. I don't see where in any of the files where the variable $(srcdir) is assigned. Is this something make does on-the-fly? Darrell

Typical free/libre software practice when providing packages is to also provide the sources and build scripts at the time the packages were made. Is there a snapshot available of the sources from the day when you issued the Trinity 3.5.11 packages? In addition to our current efforts I would like to try building from the 3.5.11 sources. I want to start using Trinity KDE at some point after the stock 3.5.10. The build process might again fail --- I don't know about that because of some of the Debianization that we are troubleshooting now --- but I'd like to try. Darrell

What are the requirements for building the tqtinterface package? With each distro update, there are updates to the kernel, kernel headers, gcc, etc. Does tqtinterface need to be rebuilt with each distro release? Darrell

Okay. But you stated previously that qt3 should be rebuilt with each new distro release, which then implies rebuilding tqtinterface too.

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. 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?

If we get that far, I think we'll have to provide a snapshot of the official 3.5.12 source tarballs. As I mentioned, Slackers tend to be DIY folks and many who might want to try 3.5.12 will want to build their own packages rather than download binary packages. Here is an example of what many Slackers will expect to find: http://slackware.mirrors.tds.net/pub/slackware/slackware-12.2/source/kde/sr… Just a directory of tarballs. Initially many will not be interested in the third-party apps. Only after they prove to themselves they can build and use 3.5.12 will they look into the third-party apps. Yet once again, they will want to find a source tarball of some kind and not svn. There will be some Slackers who will want to download binary packages. You have offered to provide those packages but currently, I amusing 12.2. Many Slackers are using 13.0, 13.1, and Current. If all goes well I'll be able to test building packages in those releases, but if you provide packages, you'll have to support 12.2, 13.0, and 13.1. YOu can support Current, but nobody will be upset if you do not. I realize lots has to happen between now and then. I'm just letting you know ahead of time.

My first response is that a problem exists with my new chroot environment. Short story is I can build arts in my virtual machine with the latest svn and tqtinterface but can't in my chroot environment. At the moment I can't say what caused arts not to build. I'm running tests between the two environments to find the problem. Stay tuned. Darrell