[gentoo-dev] How to spread intltool fixes to all packages

[gentoo-dev] How to spread intltool fixes to all packages

[Pacho Ramos]

Hello

Because of:
https://bugs.gentoo.org/show_bug.cgi?id=432848

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. 

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.

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)

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

Other possible solution would be to use ELT-PATCHES to achieve that, but
I am still unsure about how would it work.

What are your thoughts? 

Re: [gentoo-dev] How to spread intltool fixes to all packages

[Pacho Ramos]

El mar, 11-06-2013 a las 11:55 +0200, Pacho Ramos escribió:
> Hello
> 
> Because of:
> https://bugs.gentoo.org/show_bug.cgi?id=432848
> 
> 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. 
> 
> 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.
> 
> 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)
> 
> 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).
> 
> Other possible solution would be to use ELT-PATCHES to achieve that, but
> I am still unsure about how would it work.
> 
> What are your thoughts? 
> 

None? :|

Re: [gentoo-dev] How to spread intltool fixes to all packages

[Alexis Ballier]

On Fri, 14 Jun 2013 21:02:18 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> None? :|

I suppose doing it at the eclass level sounds good :)

Re: [gentoo-dev] How to spread intltool fixes to all packages

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1966 bytes --]

On Tuesday 11 June 2013 05:55:14 Pacho Ramos wrote:
> Because of:
> https://bugs.gentoo.org/show_bug.cgi?id=432848
> 
> 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.
> 
> 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.
> 
> 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)
> 
> 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).
> 
> 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 
call to patch things

you're basically talking about the same type of problem that 
https://bugs.gentoo.org/220040 tried to address.  maybe we should update 
autotools.eclass to have a general patching mechanism since any EAPI based one 
is doomed to failure.  and then we rebase elibtoolize to that.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] How to spread intltool fixes to all packages

[Pacho Ramos]

El lun, 17-06-2013 a las 01:05 -0400, Mike Frysinger escribió:
[...]
> ELT-PATCHES is only used by elibtoolize which means it requires an explicit 
> call to patch things
> 
> you're basically talking about the same type of problem that 
> https://bugs.gentoo.org/220040 tried to address.  maybe we should update 
> autotools.eclass to have a general patching mechanism since any EAPI based one 
> is doomed to failure.  and then we rebase elibtoolize to that.
> -mike

It looks a bit ambitious to me, but, if you think it is not so hard to
do, would be interesting :O