Re: find_lang

2012/1/24 Jeffrey Johnson <[email protected]>

>
> On Jan 24, 2012, at 3:29 PM, Alexander Khryukin wrote:
>
> >
> >
> > thread bump.
> >
> > I have same error.
> >
> > Package: wesnoth
> > In output i have a lot of *.mo files
> > but macro
> >
> > %find_lang %{name} --all-name
> >
> > %files -f %{name}.lang
> >
> > not working.
> > How to fix it?
> >
>
> Well I'm sure Per Oyvind is likely going to fix Real Soon Now.
>
> Meanwhile its just a script that breaks from time to time for lots
> of reasons.
>
> If all else fails, and you need to get a package built *now*, and can't
> wait for
> the "proper" fix for some reason:
>
> 1) Look at the %find_lang macro. Its just a template to invoke a
> convenience script:
>            rpm --showrc | grep find_lang
>
> 2) Expand the macro template either mentally or doing
>             rpm --eval '%find_lang %{name} --all-name'
>     Note that a --eval will have side effects and run other scripts; in
> the case of %find_lang
>     the consequences are likely minor (it will generate a %name.lang file
> in the current directory)
>
> 3) Grab a copy of the script and fix as needed: the script is usually in
> /usr/lib/rpm/find_lang.sh
>     by default, sometimes is elsewhere depending on how a build system
> configures rpm.
>
> 4) Put a copy of the script into a SourceN: directive (choosing N as
> appropriate):
>            SourceN: find_lang.sh
>    Every SourceN: directive also silently defines a %{SOURCEn} macro with
> full path
>    (and N == n chosen appropriately)
>
> 5) Replace the %find_lang macro in the *.spec with its expansion from step
> 2). Instead
>     of using the hardwired path to the script, substitute %{SOURCEn}.
>
> 6) Send the "… fix as needed …" patch from step 3) to Per Oyvind (who will
> likely
>     say "Thank you!".
>
> All I'm saying is that %find_lang is nothing more than a convenience
> wrapper
> to invoke a mostly simple script. Most of the conventional uses of macros
> in *.spec recipes
> are little more than convenience wrapper templates for common tasks in
> most cases.
>
> And scripts break because … well … they are scripts.
>
> hth
>
> 73 de Jeff
>
>
>
thanks a lot for response.