Red Hat Bugzilla – Bug 25052
cdrdao does not build xcdrdao
Last modified: 2008-05-01 11:37:59 EDT
When building the cdrdao package from SRPM, the xcdrdao app is not built,
even though there is an xcdrdao.desktop file included in the SRPM.
It appears that when using gtkmm-1.2.1-8 (from Powertools 7.0) or
gtkmm-1.2.3-10 and corresponding gtkmm-devel packages, configure has a
problem correctly detecting gtkmm and as a result disables building of the
gtkmm is specified as a Require: to support xcdrdao, so it should be built.
If this is for the version shipped in 5.1, we didn't support it at the time the problem was discovered (your report lists the bug as for 5.1). We did release a package for Red Hat Powertools which no longer requires gtk-- or gtkmm, as it doesn't build the binary for X, and it doesn't include a desktop file.
You may or may not be able to build it on 5.1, I can't guarantee anything. The errata announcement for this is at http://www.redhat.com/support/errata/powertools/RHBA-2000-068-02.html
Sorry, that should have been 7.0. Actually, the version that I was working with
was from Rawhide, but there didn't seem to be a cdrdao option under Rawhide (no
powertools), or a Rawhide option under powertools....
I downloaded the most recent version available from the rawhide site, and tried
to build on Redhat 7. (I had the gtkmm packages from rawhide as well.) The
configure script is unable to detect the fact that gtkmm is available and
therfore will not build xcdrdao. Am I to understand from the above errata that
when next updated, the rawhide packages will also not require gtkmm, and that
there is currently no expectation of supporting xcdrdao in a rpm?
Additionally, I was unable to view bug 17318 (Insufficient permissions). Can
you summarize, or make that available?
In summary of the bug that wasn't marked public, it was basically concerning
the problem with the package requiring gtk--, and not gtkmm. The change in names
for gtkmm didn't get picked up in that package.
Your first question about whether or not we will be shipping xcdrdao is correct
in the assumption that xcdrdao won't be in the next package we ship.
I'm not holding out hope on xccdrdao though. Hopefully in the future it won't
require gtkmm (which is horribly broken ATM) and use inti instead. I can't recall
off the top of my head when inti will be merged into GNOME officially though.
Also, I should have resolved this with errata instead of won'tfix, for some reason
I didn't notice I did that before.