From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 1E6141381F3 for ; Mon, 17 Jun 2013 05:05:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B4046E0856; Mon, 17 Jun 2013 05:05:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C4A89E07FD for ; Mon, 17 Jun 2013 05:05:37 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id C09B433E300; Mon, 17 Jun 2013 05:05:36 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] How to spread intltool fixes to all packages Date: Mon, 17 Jun 2013 01:05:41 -0400 User-Agent: KMail/1.13.7 (Linux/3.8.3; KDE/4.6.5; x86_64; ; ) Cc: Pacho Ramos , "gnome@gentoo.org" References: <1370944514.4583.28.camel@localhost> In-Reply-To: <1370944514.4583.28.camel@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2270717.6n2mr4vWG1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201306170105.42908.vapier@gentoo.org> X-Archives-Salt: f860b011-ea53-4b8d-a745-fcc5b3e1189c X-Archives-Hash: f51b868c7fe47f3ce3147282ecbd3e80 --nextPart2270717.6n2mr4vWG1 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tuesday 11 June 2013 05:55:14 Pacho Ramos wrote: > Because of: > https://bugs.gentoo.org/show_bug.cgi?id=3D432848 >=20 > We discovered an old bug affecting intltool that causes prefix of > localedir to be always hardcoded to the same location instead of > respecting configure flags. >=20 > The patch is fixed by intltool upstream in their master branch but still > no new version was released including it. Anyway, we now have > dev-util/intltool-0.50.2-r1 with the bug fixed. >=20 > The problem of this issue (and most involving intltool) is that we need > to run: > intltoolize --copy --automake --force > (it doesn't seem to trigger maintainer mode in all ebuilds I have tried, > then, doesn't look to require eautoreconf to be run) >=20 > for all packages to get new and fixed ${S}/po/Makefile.in.in copied to > the sources, otherwise bundled file is used and, then, the one unfixed. > As it's unreliable to ping all upstreams involving intltool (they are a > ton) and this kind of problem will likely re-appear again in the future > (since the Makefile.in.in will be fixed in intltool upstream tarball but > will take a lot of time to reach all affected packages) we were > considering to run above command always at eclass level -> that way we > would stop using bundled ${S}/po/Makefile.in.in and, then, we would > always use the one provided by our intltool package (that should get > fixed and updated more often). >=20 > Other possible solution would be to use ELT-PATCHES to achieve that, but > I am still unsure about how would it work. ELT-PATCHES is only used by elibtoolize which means it requires an explicit= =20 call to patch things you're basically talking about the same type of problem that=20 https://bugs.gentoo.org/220040 tried to address. maybe we should update=20 autotools.eclass to have a general patching mechanism since any EAPI based = one=20 is doomed to failure. and then we rebase elibtoolize to that. =2Dmike --nextPart2270717.6n2mr4vWG1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJRvpkmAAoJEEFjO5/oN/WBk9QQAOUOavOJG17zUEqnk61wlUKZ cVX0TtaGhlKo2gI10wLtec+LLfMTvZZYAH7F+SasBu6wLXqGi4IE4qkR54l8k2XH mGvLKZhn98GYWKs9cszS/OXtCmlwbLDyQxrJQZ+eTkDczRlH32I3lopOjD8ltiCS RZPrTcY1DdRm5x1j+CpLyfLL0YL778QoYauo34Fo4eG8ol3lsUi8BRQHTmNc+i5M k5EzpLmGGAGo1XkibLpNDQjmds43P5KLyLuRBQt4fMwSTfvgKkskKVQmD80jHRQA idANKpLvMMzvkaRP7Hl844ZJ8MnLfV5tjSOROY1rytezD+7Hdrfcn+iFm/OKjZp/ oMFV9tY7mazneXdlgJm4bmd6urCH2lG65JkFLCLqf5xyOKOpPP09INQbWgnz8ut9 vGAxdtwSgsaGOr5jp18TYQFTbEK8xBogu6PrHXgVyewiEpcmR2BnNYh1T1RqQonC UtyHpKWlaoWlNbqGom+6GMYhzcOhOWjMurhBHHj+z1p4omnbCWWeqpbKi+zDjndi 3wVV2eCUMs2JwIrCbtbewA6skDkY81MgasO8a7t1CRXPFBziFDwS1LgyxuqhgD1E HmajotacEoKSrajZCsHoRG/CNv+YNo5XXupCWmG8PcJ+b6fWz2iv41QJbc6PW0fO 7pC04qPJaHJBeBhQpXWC =4qsj -----END PGP SIGNATURE----- --nextPart2270717.6n2mr4vWG1--