Bug 740790 - gtkmm24 FTBFS in Fedora 15
Summary: gtkmm24 FTBFS in Fedora 15
Alias: None
Product: Fedora
Classification: Fedora
Component: gtkmm24   
(Show other bugs)
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Haïkel Guémar
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-23 10:55 UTC by Henrik Nordström
Modified: 2019-01-09 12:33 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-10-19 09:01:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Henrik Nordström 2011-09-23 10:55:47 UTC
Description of problem:

During F15 armv7 bootstrap it was detected that gtkmm24 FTBFS in Fedora 15.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. mock -r fedora-15-x86_64 gtkmm24-2.24.0-3.fc15.src.rpm
Actual results:

Can't open perl script "/usr/share/glibmm-2.4/doctool/doc-install.pl": No such file or directory

Expected results:

package built

Additional info:

Comment 1 Jiri Kastner 2011-10-07 16:38:36 UTC
for documentation of bug state:
upstream bug - https://bugzilla.gnome.org/show_bug.cgi?id=648860

workaround http://jkastner.fedorapeople.org/glibmm24-2.28.0-1.fc15.0.arm1/glibmm24-2.28.0-1.fc15.0.arm1.src.rpm

in configure is following snippet, which appeared first in glibmm in fc15 and which i don't understand (yet) how to invoke (convice configure to install it and therefore avoid workaround above)

 if test 'xdocs' != 'x'; then

Comment 2 Henrik Nordström 2011-10-07 19:13:32 UTC
gtkmm24-2.4.2-1.fc16 seems to use internal doc-install.pl, maybe the right solution is pushing that to f15 as well?

Comment 3 Henrik Nordström 2011-10-07 19:14:53 UTC
I obviously meant gtkmm24-2.24.2-1.fc16

Comment 4 Kalev Lember 2011-10-07 19:34:00 UTC
Yes, updating to 2.24.2 would certainly fix it. The question is, do we want to also push out an update for the primary arches?

If not, then the other alternative would be to just do a build with Karsen Hopp's targeted fix (http://pkgs.fedoraproject.org/gitweb/?p=gtkmm24.git;a=commit;h=1da1c73) and not push it out as an update through Bodhi. That way, the ARM guys can use the srpm and we can avoid introducing additional update churn for F15 users.

Haïkel, any opinions?

Comment 5 Henrik Nordström 2011-10-07 19:35:04 UTC
Same issue also hits gconfmm26 which is also failing on missing doc-install.pl.

It's a bit confusing. Is doc-install.pl supposed to be installed or not?

This is a problem for the arm secondary arch where F15 is rebuild from source.

Comment 6 Kalev Lember 2011-10-07 19:55:43 UTC
doc-install.pl used to be part of glibmm and used to be installed in /usr/share/glibmm-2.4/doctool/. At one point, upstream decided that it's better to distribute the script in mm-common.

mm-common is only meant to be needed when building from git (and rolling tarballs) and shouldn't be used when building from tarballs. To make that work, doc-install.pl which now lives in mm-common is also distributed in every mm module's tarball. That way, newly rolled tarballs use their internal doc-install.pl and build fine.

A nice change, but the oversight was that it broke older tarballs that relied on glibmm's doc-install.pl. The issue was complicated by the fact that the change happened very late in glibmm 2.28 cycle and most other mm module tarballs didn't get respinned in time for F15.

Comment 7 Henrik Nordström 2011-10-07 21:18:35 UTC
Thanks. Picture clear.

Found some more F15 packages failing on doc-install.pl. Updated list:


Most packages which have been built so far seem to use their own bundled doc-install.pl and only one (goocanvasmm2) are using the copy from mm-common.

It is possible there is additional packages having this issue but which are also failing for other reasons (build dependenceis not met etc).

Comment 8 Henrik Nordström 2011-10-17 19:32:43 UTC
Ping? Would be really good if some decision can be made on how to address this on the affected packages, primarily gconfmm26 and gtkmm24.

Comment 9 Kalev Lember 2011-10-18 15:01:54 UTC
I guess I'll need to volunteer; doesn't look like we're reaching any decision here.

This is what I'm planning to do:

In F15, build a patched glibmm24 that duplicates mm-common's doc-install.pl in /usr/share/glibmm-2.4/doctool/. This should be enough to make all the packages listed in comment #8 build.

In F16, everything should already build fine with latest glibmm24, except for gconfmm26. I'll look into fixing it upstream and getting a new tarball out which we can then use in Fedora.

Comment 10 Kalev Lember 2011-10-18 15:15:33 UTC
The workaround is in glibmm24-2.28.1-2.fc15 and should be enough to make the rest of the packages build.

Henrik, is it OK with you if I don't push it out as an update through Bodhi on the primary arches?

Comment 11 Kalev Lember 2011-10-18 15:48:14 UTC
Submitted a gconfmm patch upstream: https://bugzilla.gnome.org/show_bug.cgi?id=648860

Comment 12 Henrik Nordström 2011-10-18 17:34:28 UTC
A koji build is minimum requirement to assign an NVR to the change.

But if you don't mind then please file an update but don't push it to stable. This prevents koji from garbage collecting the build, and also provides a better record should there be an additional update needed for glibmm24 during the remaining life of F15.

Comment 13 Kalev Lember 2011-10-18 18:13:18 UTC
Right, glibmm24-2.28.1-2.fc15 is the koji NVR for the build and you can get the SRPM from there. If you rebuild it for ARM, the rest of the packages should hopefully build with glibmm24-2.28.1-2.fc15 in the buildroots.

Comment 14 Henrik Nordström 2011-10-18 23:53:15 UTC
It built fine and long dependency chains are now being walked by the builders. Many thanks!

Comment 15 Kalev Lember 2011-10-19 09:01:22 UTC
You're welcome.

Note You need to log in before you can comment on or make changes to this bug.