Attached is a log of the failed kdebase build.
The follwing message appears several times:
TEPty.h:43: error: invalid use of incomplete type 'struct KPty'
Another message:
/usr/include/kprocess.h:34: error: forward declaration of 'struct KPty'
I checked /usr/include and kprocess.h is installed from my previous kdelibs svn package.
Darrell
Attached is a log of the failed kdebase build.
The follwing message appears several times:
TEPty.h:43: error: invalid use of incomplete type 'struct KPty'
Another message:
/usr/include/kprocess.h:34: error: forward declaration of 'struct KPty'
I checked /usr/include and kprocess.h is installed from my previous kdelibs svn package.
Darrell
I had encountered the exact same problem a day or so ago. The fix actually lies in kdelibs, and is available in SVN revisions r1170159 and r1170194. You will probably have to update and recompile tqtinterface before kdelibs can be updated and recompiled due to a couple of changes that were made for Qt4 compatibility
Tim
I had encountered the exact same problem a day or so ago. The fix actually lies in kdelibs, and is available in SVN revisions r1170159 and r1170194. You will probably have to update and recompile tqtinterface before kdelibs can be updated and recompiled due to a couple of changes that were made for Qt4 compatibility
Hmm. I had some suspicions when I updated svn today and saw the tqtinterface updates.
Okay, back to square one!
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
Updated svn to 1170271.
Rebuilt and installed tqtinterface.
Did the arts compilation succeed at some point in the recent past?
What configure flags did you use?
Attempted to build arts. Final snippet from the build:
<snip>
Problem would be in /dev/shm/arts/qtmcop/Makefile.in, lines 671-672.
FYI, my Makefile.in will be different than yours due to the fact that it is an automatically generated file.
I don't see where in any of the files where the variable $(srcdir) is assigned. Is this something make does on-the-fly?
Yes.
Darrell
Tim
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
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?
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.
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.
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.
Tim
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
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
TQt only needs to be rebuilt if Qt is changed/upgraded. It is nothing more than a thin wrapper on top of Qt to provide the "old style" features that were removed from Qt4, as well as a good place to put Trinity-specific widgets so that they are available to all Trinity applications.
Tim
TQt only needs to be rebuilt if Qt is changed/upgraded. It is nothing more than a thin wrapper on top of Qt to provide the "old style" features that were removed from Qt4, as well as a good place to put Trinity-specific widgets so that they are available to all Trinity applications.
Okay. But you stated previously that qt3 should be rebuilt with each new distro release, which then implies rebuilding tqtinterface too.
TQt only needs to be rebuilt if Qt is changed/upgraded. It is nothing more than a thin wrapper on top of Qt to provide the "old style" features that were removed from Qt4, as well as a good place to put Trinity-specific widgets so that they are available to all Trinity applications.
Okay. But you stated previously that qt3 should be rebuilt with each new distro release, which then implies rebuilding tqtinterface too.
I did? I don't remember now...heh.
Bottom line is that it would be a good idea to rebuild it on each new major release of your distribution. Anything in between those major releases shouldn't require a rebuild, as the Qt ABI for minor/point releases is quite stable.
Tim
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.
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?
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
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.
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/src...
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.
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.
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/src...
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.
Works for me. I can generate tarballs of each module just as easily I can generate the monolithic one.
Tim
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
I'm stumped. The problem is with my chroot environment.
I spent the past few hours whittling away at both the chroot environment and the virtual machine trying to find the difference. Currently, as far as package installations go, the two machines are identical.
Granted, although sandboxed, the chroot is not perfectly isolated like the virtual machine. Something is confusing the build process in the chroot environment that the virtual machine can't see. A chroot environment is not supposed to be able to see above/outside its internal root level. Thus I don't know what the chroot environment sees that the virtual machine can't.
I can build in the virtual machine but as I mentioned previously, the build process is slower than on physical hardware. I wanted the chroot environment so I could use the physical hardware and build faster.
I'll see how far I get rebuilding arts and kdelibs in the virtual machine. Then I'll try kdebase with your changes from a couple of days ago. I'll keep troubleshooting with the chroot environment too.
With that said, I am attaching a new log of the failed arts build in the chroot environment. Perhaps something there might provide you a clue where I can troubleshoot or what might cause arts to fail in one environment but not the other.
-
Darrell Anderson -
Timothy Pearson