The package builds and seems to contain the expected files. Package installs and appears in KControl. Yet many warning messages.
Log attached.
===========================================================
-- WARNING: you are using the obsolete 'PKGCONFIG' macro use FindPkgConfig
Is this warning important? Is there anything I can do about this warning?
===========================================================
-- PKGCONFIG() indicates that libbonoboui-2.0 is not installed (install the package which contains libbonoboui-2.0.pc if you want to support this feature)
-- bonoboui not found. Some features of the theme engine will not work as intended.
There is a non-stock build script available for libbonoboui. The dependency chain includes libgnome, libbonobo, libgnomecanvas, gnome-vfs, GConf2, gnome-mime-data, avahi, ORBit2. Possibly more. To many Slackers that is considered a lot of cruft. Therefore, exactly what features are lost by not having libbonoboui installed when building gtk-qt-engine?
===========================================================
There are many "warning: unused parameter" messages.
===========================================================
/dev/shm/applications/gtk-qt-engine/src/qt_qt_wrapper.cpp: In function 'void drawArrow(GdkWindow*, GtkStyle*, GtkStateType, GtkArrowType, int, int, int, int)':
/dev/shm/applications/gtk-qt-engine/src/qt_qt_wrapper.cpp:1698: warning: 'element' may be used uninitialized in this function
[I built the package in tmpfs, hence the reference to /dev/shm. I am focusing on the warning messages.]
Darrell
The package builds and seems to contain the expected files. Package installs and appears in KControl. Yet many warning messages.
Log attached. (Oops I forgot to attach the log!)
===========================================================
-- WARNING: you are using the obsolete 'PKGCONFIG' macro use FindPkgConfig
Is this warning important? Is there anything I can do about this warning?
===========================================================
-- PKGCONFIG() indicates that libbonoboui-2.0 is not installed (install the package which contains libbonoboui-2.0.pc if you want to support this feature)
-- bonoboui not found. Some features of the theme engine will not work as intended.
There is a non-stock build script available for libbonoboui. The dependency chain includes libgnome, libbonobo, libgnomecanvas, gnome-vfs, GConf2, gnome-mime-data, avahi, ORBit2. Possibly more. To many Slackers that is considered a lot of cruft. Therefore, exactly what features are lost by not having libbonoboui installed when building gtk-qt-engine?
===========================================================
There are many "warning: unused parameter" messages.
===========================================================
/dev/shm/applications/gtk-qt-engine/src/qt_qt_wrapper.cpp: In function 'void drawArrow(GdkWindow*, GtkStyle*, GtkStateType, GtkArrowType, int, int, int, int)':
/dev/shm/applications/gtk-qt-engine/src/qt_qt_wrapper.cpp:1698: warning: 'element' may be used uninitialized in this function
[I built the package in tmpfs, hence the reference to /dev/shm. I am focusing on the warning messages.]
Darrell
The "My Documents" device icon dialog box was broken but partially repaired in SVN 1176545.
The dialog box no longer appears, but when the $HOME/Documents directory does not exist then Konqueror opens with an error message.
The Konqueror error message indirectly reveals the solution to competant computer users, but might not be obvious to the less technically inclined.
Similar behavior is found when selecting "Documents Folder" from the K-Menu, which results in an error message that the $HOME/Documents does not exist.
A more elegant solution for both would be to provide a Yes/No/Cancel dialog box stating the directory does not exist and asking permission to create the directory.
I think $HOME/Documents is specified somewhere as a default, but any associated dialog box should provide a text box allowing more technically inclined users to change the location of that path.
Darrell
Hi,
So, with Trinity 3.5.12 nearing, it's time for me to update the BLFS
books with Trinity
and create RPM spec files from them.
So, what configure options did everyone use? I know I mentioned it
before, but it's probably easier to have one central place
so we can compare what options and why.
(Here. :D )
--
later, Robert Xu
After updating my build scripts to support the tarball naming and compression scheme, I started another build run.
kdebase-3.5.12.tar.gz FTBFS.
My apologies for incorrectly referencing kdelibs in a previous post.
I can include a big log, but I think the error is clear:
make[4]: Entering directory `/dev/shm/kdebase/kcontrol/energy/pics'
make[4]: *** No rule to make target `energybig.png', needed by `all-am'. Stop.
make[4]: Leaving directory `/dev/shm/kdebase/kcontrol/energy/pics'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/dev/shm/kdebase/kcontrol/energy'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/dev/shm/kdebase/kcontrol'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/dev/shm/kdebase'
make: *** [all] Error 2
The energybig.png pic is in SVN but not the 3.5.12 tarball. I downloaded that earlier file today. Just to be sure, I again downloaded the tarball a couple of minutes ago and there is no such png file.
Darrell
I have created a set of pre-release source tarballs for Trinity 3.5.12.
They are currently publishing to the mirror, and should be available
within 48 hours from this link:
http://ppa2.quickbuild.pearsoncomputing.net/redirect.php?file=releases/3.5.…
If no issues are found in the next four days, there is a very good chance
these files will become the final release.
Please keep this information on this list for now; I am releasing the
files early for testing purposes only, not for general consumption.
Thanks!
Tim
Hi,
Being that 3.5.12 is on the verge of being released, I've decided to
include this release in BLFS to replace the aging 3.5.10.
Given that KDE 4 has rapidly changed quickly, we can't keep up with
the pace, and that stupid cmake.
I've also decided to build RPMs of the KDE 3.5.12 release. They'll be
built for Mandriva, Fedora, and SuSE :)
What configure options would you recommend for stuff like this?
I saw a thread on trinity-devel, but given the fact that I just
subscribed (when I should have done so earlier -.-"), I don't have the
emails.
--
later, Robert Xu
Hello,
As I see, in kde4 api-dox are not handled anymore by building system (actually
apidox is not handled by autotools anyway in kde3, but by script named
doxygen.sh). Is there any reason to include apidox support in cmake scripts?
--
Serghei
