Bug 740790 - gtkmm24 FTBFS in Fedora 15
Summary: gtkmm24 FTBFS in Fedora 15
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gtkmm24
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Haïkel Guémar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
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:
Clone Of:
Environment:
Last Closed: 2011-10-19 09:01:22 UTC
Type: ---
Embargoed:


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):

gtkmm24-2.24.0-3.fc15

How reproducible:

always

Steps to Reproduce:
1. mock -r fedora-15-x86_64 gtkmm24-2.24.0-3.fc15.src.rpm
2.
3.
  
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)

MMDOCTOOLDIR='${top_srcdir}/docs'
 if test 'xdocs' != 'x'; then
  DIST_DOCTOOLS_TRUE=
  DIST_DOCTOOLS_FALSE='#'
else
  DIST_DOCTOOLS_TRUE='#'
  DIST_DOCTOOLS_FALSE=
fi

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:

  gconfmm26-2.28.2-2.fc15
  goocanvasmm-0.15.4-3.fc15
  gtkmm24-2.24.0-3.fc15
  libvtemm-0.23.1-2.fc15

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.