This is a popular non-core package. If many of these non-core package are unavailable to end-users, then I call that a show-stopper. Many people will lose interest in Trinity when such non-core packages remain unavailable. I would like to get this package to build as soon as possible.
I'm attaching a log. Same as a previous report, but attached here for quicker access.
This is a build from the source tarball.
Build errors:
============================================ checking cdda_interface.h usability... no checking cdda_interface.h presence... no checking for cdda_interface.h... no
----------------------------------------- ERROR: Could not find cdparanoia headers. -----------------------------------------
configure: error: could not find cdparanoia headers make: *** No targets specified and no makefile found. Stop. ============================================
The cause is straightforward. In Slackware the cdda_paranoia.h file is found in /usr/include/cdda rather than /usr/include.
A short term fix is creating a sym link. I could revise the build script to create such a link on-the-fly, but that is not the default in Slackware. Generally, I dislike the idea of tampering with expected upstream defaults. Another solution is to patch the configure files to look in /usr/include/cdda as well as /usr/include.
Also conspicuous are these errors:
============================================ *** Creating configure configure.in:92: warning: KDE_ENABLE_HIDDEN_VISIBILITY was called before AC_PATH_QT_1_3 acinclude.m4:3645: KDE_ENABLE_HIDDEN_VISIBILITY is expanded from... configure.in:92: the top level *** Creating config.h template configure.in:92: warning: KDE_ENABLE_HIDDEN_VISIBILITY was called before AC_PATH_QT_1_3 acinclude.m4:3645: KDE_ENABLE_HIDDEN_VISIBILITY is expanded from... configure.in:92: the top level *** Creating Makefile templates configure.in:92: warning: KDE_ENABLE_HIDDEN_VISIBILITY was called before AC_PATH_QT_1_3 acinclude.m4:3645: KDE_ENABLE_HIDDEN_VISIBILITY is expanded from... ============================================
Also these:
============================================ kaffeine/src/input/dvb/lib/libdvbapi/Makefile.am:11: `CFLAGS' is a user variable, you should not override it; kaffeine/src/input/dvb/lib/libdvbapi/Makefile.am:11: use `AM_CFLAGS' instead. kaffeine/src/input/dvb/lib/libdvben50221/Makefile.am:21: `CFLAGS' is a user variable, you should not override it; kaffeine/src/input/dvb/lib/libdvben50221/Makefile.am:21: use `AM_CFLAGS' instead. kaffeine/src/input/dvb/lib/libucsi/Makefile.am:17: `CFLAGS' is a user variable, you should not override it; kaffeine/src/input/dvb/lib/libucsi/Makefile.am:17: use `AM_CFLAGS' instead. kaffeine/src/input/dvb/lib/libucsi/dvb/Makefile.am:19: `CFLAGS' is a user variable, you should not override it; kaffeine/src/input/dvb/lib/libucsi/dvb/Makefile.am:19: use `AM_CFLAGS' instead. kaffeine/src/input/dvb/lib/libucsi/mpeg/Makefile.am:12: `CFLAGS' is a user variable, you should not override it; kaffeine/src/input/dvb/lib/libucsi/mpeg/Makefile.am:12: use `AM_CFLAGS' instead. ============================================
Then there are the many "undefined reference" errors, of which the build finally fails. As seen in the build log, all expected component packages are installed.
Darrell
This is a popular non-core package. If many of these non-core package are unavailable to end-users, then I call that a show-stopper. Many people will lose interest in Trinity when such non-core packages remain unavailable. I would like to get this package to build as soon as possible.
I'm attaching a log. Same as a previous report, but attached here for quicker access.
This is a build from the source tarball.
Build errors:
============================================ checking cdda_interface.h usability... no checking cdda_interface.h presence... no checking for cdda_interface.h... no
ERROR: Could not find cdparanoia headers.
configure: error: could not find cdparanoia headers make: *** No targets specified and no makefile found. Stop. ============================================
The cause is straightforward. In Slackware the cdda_paranoia.h file is found in /usr/include/cdda rather than /usr/include.
A short term fix is creating a sym link. I could revise the build script to create such a link on-the-fly, but that is not the default in Slackware. Generally, I dislike the idea of tampering with expected upstream defaults. Another solution is to patch the configure files to look in /usr/include/cdda as well as /usr/include.
Also conspicuous are these errors:
============================================ *** Creating configure configure.in:92: warning: KDE_ENABLE_HIDDEN_VISIBILITY was called before AC_PATH_QT_1_3 acinclude.m4:3645: KDE_ENABLE_HIDDEN_VISIBILITY is expanded from... configure.in:92: the top level *** Creating config.h template configure.in:92: warning: KDE_ENABLE_HIDDEN_VISIBILITY was called before AC_PATH_QT_1_3 acinclude.m4:3645: KDE_ENABLE_HIDDEN_VISIBILITY is expanded from... configure.in:92: the top level *** Creating Makefile templates configure.in:92: warning: KDE_ENABLE_HIDDEN_VISIBILITY was called before AC_PATH_QT_1_3 acinclude.m4:3645: KDE_ENABLE_HIDDEN_VISIBILITY is expanded from... ============================================
Also these:
============================================ kaffeine/src/input/dvb/lib/libdvbapi/Makefile.am:11: `CFLAGS' is a user variable, you should not override it; kaffeine/src/input/dvb/lib/libdvbapi/Makefile.am:11: use `AM_CFLAGS' instead. kaffeine/src/input/dvb/lib/libdvben50221/Makefile.am:21: `CFLAGS' is a user variable, you should not override it; kaffeine/src/input/dvb/lib/libdvben50221/Makefile.am:21: use `AM_CFLAGS' instead. kaffeine/src/input/dvb/lib/libucsi/Makefile.am:17: `CFLAGS' is a user variable, you should not override it; kaffeine/src/input/dvb/lib/libucsi/Makefile.am:17: use `AM_CFLAGS' instead. kaffeine/src/input/dvb/lib/libucsi/dvb/Makefile.am:19: `CFLAGS' is a user variable, you should not override it; kaffeine/src/input/dvb/lib/libucsi/dvb/Makefile.am:19: use `AM_CFLAGS' instead. kaffeine/src/input/dvb/lib/libucsi/mpeg/Makefile.am:12: `CFLAGS' is a user variable, you should not override it; kaffeine/src/input/dvb/lib/libucsi/mpeg/Makefile.am:12: use `AM_CFLAGS' instead. ============================================
Then there are the many "undefined reference" errors, of which the build finally fails. As seen in the build log, all expected component packages are installed.
Darrell
Well, it's obviously a bit late to change the 3.5.12 files, so let's see what we can do to patch up the package until 3.5.13.
You'll have to work around the cdparanoia problem for now with the symbolic link as you mentioned. This will be fixed for 3.5.13.
Also, try passing the --without-lame flag to the Kaffeine configure script. Does the compilation proceed?
Tim
Well, it's obviously a bit late to change the 3.5.12 files, so let's see what we can do to patch up the package until 3.5.13.
You'll have to work around the cdparanoia problem for now with the symbolic link as you mentioned. This will be fixed for 3.5.13.
Also, try passing the --without-lame flag to the Kaffeine configure script. Does the compilation proceed?
Yup, no build failures regarding lame when using the --without-lame option. I have lame-3.98.4 installed.
Still FTBFS. Similar build failure regarding cdda_paranoia.h. Seems I need to create the same temporary sym link to /usr/include.cdda/cdda_paranoia.h.
I updated my build script with appropriate checks and link creations.
Kaffeine built fine.
I tried building in my non-chroot regular KDE 3.5 desktop. Kaffiene FTBFS with the same header file errors. Thus, I have no idea how the package successfully built previously. Then again I built a lot of these packages long ago.
Next I removed the --without-lame option. FTBFS. So only partially resolved.
Well, it's obviously a bit late to change the 3.5.12 files, so let's see what we can do to patch up the package until 3.5.13.
You'll have to work around the cdparanoia problem for now with the symbolic link as you mentioned. This will be fixed for 3.5.13.
Also, try passing the --without-lame flag to the Kaffeine configure script. Does the compilation proceed?
Yup, no build failures regarding lame when using the --without-lame option. I have lame-3.98.4 installed.
Still FTBFS. Similar build failure regarding cdda_paranoia.h. Seems I need to create the same temporary sym link to /usr/include.cdda/cdda_paranoia.h.
I updated my build script with appropriate checks and link creations.
Kaffeine built fine.
I tried building in my non-chroot regular KDE 3.5 desktop. Kaffiene FTBFS with the same header file errors. Thus, I have no idea how the package successfully built previously. Then again I built a lot of these packages long ago.
Next I removed the --without-lame option. FTBFS. So only partially resolved.
The fixes will have to wait for 3.5.13; why don't you open new bugs for both issues?
For 3.5.12, --disable-lame will simply be required, as well as the include statement ln hack. I've seen much worse hacking in Ubuntu as they try to force an upstream package to work on their distribution. ;-) Both issues will be a priority for 3.5.13.
Tim
The fixes will have to wait for 3.5.13; why don't you open new bugs for both issues?
For 3.5.12, --disable-lame will simply be required, as well as the include statement ln hack. I've seen much worse hacking in Ubuntu as they try to force an upstream package to work on their distribution. ;-) Both issues will be a priority for 3.5.13.
Within my chroot environmnet I built both kaffeine 0.8.7 and 0.8.8 from the upstream tarball. That tended to indicate the problem is not with any installed packages.
Tried building with no -j flag. FTBFS.
Next tried --enable-closure.
Kaffeine built.
Well, well. That old ghost returns.
Played an AVI video and MP3.
I'll update the --enable-closure list in the wiki.
I'll submit a bug report for the build warning messages.
I'll submit a bug report for updating the version. Trinity is at 0.8.6. Last KDE3 release was 0.8.8, which I built without error in my chroot. Tested an AVI and MP3 in my virtual machine running Trinity was satisfactory.
Oy!
Well done!
On 10/4/10, Darrell Anderson humanreadable@yahoo.com wrote:
The fixes will have to wait for 3.5.13; why don't you open new bugs for both issues?
For 3.5.12, --disable-lame will simply be required, as well as the include statement ln hack. I've seen much worse hacking in Ubuntu as they try to force an upstream package to work on their distribution. ;-) Both issues will be a priority for 3.5.13.
Within my chroot environmnet I built both kaffeine 0.8.7 and 0.8.8 from the upstream tarball. That tended to indicate the problem is not with any installed packages.
Tried building with no -j flag. FTBFS.
Next tried --enable-closure.
Kaffeine built.
Well, well. That old ghost returns.
Played an AVI video and MP3.
I'll update the --enable-closure list in the wiki.
I'll submit a bug report for the build warning messages.
I'll submit a bug report for updating the version. Trinity is at 0.8.6. Last KDE3 release was 0.8.8, which I built without error in my chroot. Tested an AVI and MP3 in my virtual machine running Trinity was satisfactory.
Oy!
-
Darrell Anderson -
Katheryne Draven -
Timothy Pearson