GNOME Bugzilla – Bug 793459
gedit 3.27.90 does not build
Last modified: 2018-02-16 16:51:13 UTC
gedit 3.27.90 does not build: config.status: error: po/Makefile.in.in was not created by intltoolize. [00:00:38] FAILURE [core/gedit.bst]: Running configure-commands [00:01:37] FAILURE [core/gedit.bst]: Command './configure --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --datadir=/usr/share \ --includedir=/usr/include \ --libdir=/usr/lib \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --sharedstatedir=/usr/com \ --mandir=/usr/share/man \ --infodir=/usr/share/info --disable-static --disable-gtk-doc --disable-Werror' failed with exitcode 1 It builds fine from git master: only the tarball release is broken. The autogen.sh looks really suspicious. The combination of autopoint and intltoolize seems like a recipe for disaster. Why is it running autopoint at all, if it is using intltool? I am going to try to change it to standard gettextize and see if that works. autopoint --force || exit $? AUTOPOINT='intltoolize --automake --copy' autoreconf --force --install --verbose
(In reply to Michael Catanzaro from comment #0) > I am going to try to change it to standard gettextize and see if that works. It's got custom goo, including a perl script. That's scary. Jeremy is trying now. Thanks Jeremy. :)
We both failed to find an easy solution to this. It's complicated by bug #776367, which is not helping, and the custom script gedit-tool-merge.pl that depends on intltool. I had to actually go in and delete gedit.bst from GNOME 3.27.90 to make this release, because I couldn't find any way to build it. Please, gedit maintainers, consider this a top priority issue. (In reply to Michael Catanzaro from comment #0) > gedit 3.27.90 does not build: > > config.status: error: po/Makefile.in.in was not created by intltoolize. Underlying problem is that intltool is competing with autopoint/gettext to generate po/Makefile.in.in. You have two different sets of infrastructure for generating this file, stomping on each other, which is not good. But removing one or the other seems to introduce bug #776367, in my quick testing.
To reproduce using GNOME build infrastructure, download https://download.gnome.org/teams/releng/3.27.90/gnome-3.27.90.tar.xz and add gedit.bst under elements/core with the following contents: kind: autotools sources: - url: https://download.gnome.org/sources/gedit/3.27/gedit-3.27.90.tar.xz kind: tar ref: a68f45999edcead0f8339c7b3bdbac72e00834373392322ee37b67aef6e35d16 depends: - core-deps/gspell.bst - core-deps/gtksourceview-3.bst - core-deps/libpeas.bst - core-deps/yelp-tools.bst - core/gsettings-desktop-schemas.bst - base.bst Then: $ bst build --track-all --track-save core/gedit.bst $ bst build core/gedit.bst wait a while, then it will eventually fail once it reaches gedit. I think a workaround would be to release a vanilla git archive without any of the generated autotools files, since builds from git work fine.
A vanilla git archive tarball (after deleting the .git directory) is 15 MB compared to 3 MB for 3.27.90.tar.xz .
The gedit-3.27.90.tar.xz tarball builds just fine - both as hosted on download.gnome.org and built by myself with ./autogen.sh + make distcheck from a git clone. It seems the problem is some autoreconf alike runs by BuildStream. But just autoreconf after unpack outside bst still works fine.
(In reply to Jeremy Bicha from comment #4) > A vanilla git archive tarball (after deleting the .git directory) is 15 MB > compared to 3 MB for 3.27.90.tar.xz . Weird, the only difference should be rm -rf the world stuff. (In reply to Mart Raudsepp from comment #5) > The gedit-3.27.90.tar.xz tarball builds just fine - both as hosted on > download.gnome.org and built by myself with ./autogen.sh + make distcheck > from a git clone. It seems the problem is some autoreconf alike runs by > BuildStream. But just autoreconf after unpack outside bst still works fine. Yes, BuildStream should not be manually running autoreconf. That's very broken. gedit is broken too, because it is using incompatible tools that fight over po/Makefile.in.in. But the build would not fail if BuildStream were not messing it up. The other module that failed for this reason was gnome-documents, but I didn't connect the two issues yesterday because gedit's failure was so subtle.
It seems like BuildStream is breaking the tarball via autoreconf -ivf call in https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/plugins/elements/autotools.yaml#L5 Though I'm just guessing here without actually having BuildStream installed and testing this. Perhaps try adding this to the gedit.bst file, and see if that "fixes" it: variables: autogen: /bin/true If that helps, then BuildStream shouldn't be breaking released tarballs like this. If you run autoreconf -ivf, you HAVE to also run the other tooling needed, like autogen.sh does. In Gentoo we do it like this: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/autotools.eclass#n156 Note the intltoolize and other calls. The lack of that (or some of the others) is causing this problem, as autoreconf -ivf force installs gettext po/Makefile.in.in without having "intltoolize --automake --copy --force" copy it over with the intltool one.
(In reply to Michael Catanzaro from comment #6) > (In reply to Jeremy Bicha from comment #4) > > A vanilla git archive tarball (after deleting the .git directory) is 15 MB > > compared to 3 MB for 3.27.90.tar.xz . > > Weird, the only difference should be rm -rf the world stuff. There's probably a bunch of stuff checked in to git that isn't in EXTRA_DIST or whatever.
Moving to BuildStream: https://gitlab.com/BuildStream/buildstream/issues/256 gedit is still broken, since it's creating po/Makefile.in.in, deleting it, and then creating it again with a different competing tool, which is nuts. But it's BuildStream's fault for only creating it once and not allowing gedit to delete it and recreate it by running intltoolize. ;)
(In reply to Michael Catanzaro from comment #9) > gedit is still broken, since it's creating po/Makefile.in.in, deleting it, > and then creating it again with a different competing tool, which is nuts. I think that was pretty much modus operandi with intltool out of technical limitations (and intltool needing some of the gettextize stuff). E.g. https://mail.gnome.org/archives/gtkmm-list/2009-August/msg00072.html The fix of course is new gettext stuff that does what intltool did before as an addon, but I guess bug 776367 and other stuff is complicating a port.
(In reply to Mart Raudsepp from comment #10) > (In reply to Michael Catanzaro from comment #9) > > gedit is still broken, since it's creating po/Makefile.in.in, deleting it, > > and then creating it again with a different competing tool, which is nuts. > > I think that was pretty much modus operandi with intltool out of technical > limitations (and intltool needing some of the gettextize stuff). E.g. > https://mail.gnome.org/archives/gtkmm-list/2009-August/msg00072.html You're not supposed to use AM_GNU_GETTEXT/AM_GLIB_GNU_GETTEXT and also intltool.
Digging through Debian/Ubuntu packages for something else, I noticed that it carries this patch since 2012: https://salsa.debian.org/gnome-team/gedit/blob/debian/master/debian/patches/03_no_gnu_gettext.patch I don’t know how relevant that is. Fedora has zero patches for gedit and it works (as of gedit-3.22.1-2.fc27.x86_64).
That would be a clear step in the right direction (but it won't fix BuildStream).