Summary: | dev-util/pkgconfig: pkg.m4 installs macro incompatible with autoconf-2.66 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | Samuli Suominen (RETIRED) <ssuominen> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gnome |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Diego Elio Pettenò (RETIRED)
2010-07-04 23:03:21 UTC
i'm not sure if we should fix this is pkg-config, or if this is another regression of autoconf itself... (In reply to comment #1) > i'm not sure if we should fix this is pkg-config, or if this is another > regression of autoconf itself... > s/is/in/ :) http://bugzilla.redhat.com/show_bug.cgi?id=611781 http://cvs.fedoraproject.org/viewvc/rpms/pkgconfig/devel/pkg-config-dnl.patch?view=log http://lists.gnu.org/archive/html/autoconf/2010-07/msg00031.html +*pkgconfig-0.25-r2 (11 Jul 2010) + + 11 Jul 2010; Samuli Suominen <ssuominen@gentoo.org> + +pkgconfig-0.25-r2.ebuild, +files/pkgconfig-0.25-dnl.patch: + Fix for sys-devel/autoconf-2.66 compat (but commit unkeyworded until it's + sorted out). Hrm, the fedora patch looks reversed, and on the other hand I'm not sure if _dropping_ dnl is going to be the right thing to do. To me it looks a lot more like it's an autoconf bug... that's why it's not keyworded :) waiting for upstream consensus. And the upstream pkg-config bug/patch that likely introduced this regression: http://bugs.freedesktop.org/show_bug.cgi?id=13892 Archlinux wins. That patch is proper, and we could very well be applying it just to be on the safe side. The problem is that all the packages bundling pkg.m4 will have the same problem. (In reply to comment #9) > Archlinux wins. That patch is proper, and we could very well be applying it > just to be on the safe side. applied in tree > The problem is that all the packages bundling pkg.m4 will have the same > problem. > will keep my eyes open... You do know that we're talking of about 60% of the pkg-config users in the tree, right? (In reply to comment #11) > You do know that we're talking of about 60% of the pkg-config users in the > tree, right? > I've seen it couple of times, but no idea on numbers... Perhaps tinderbox could run a custom pkg_ function and execute `find` pkg.m4 for ${WORKDIR} or ${S} in it? Sure I could... but at that point I'd rather ask for Zac to write me some code to simply run the unpack/prepare phase of all the packages and check for the pkg.m4 file with the mistake in it ;P http://bugs.freedesktop.org/show_bug.cgi?id=13892 was applied *after* 0.23 release, so the regression should be only in bundled 0.24 or 0.25 pkg.m4 files. Hm okay then it is feasible, I guess, sorry for the extra noise |