[OE-core] [PATCH 08/11] lrzsz: remove the recipe

[Ross Burton]

On 26/11/2019 12:06, Phil Blundell wrote:
> On Tue, Nov 26, 2019 at 12:59:54PM +0100, Phil Blundell wrote:
>> On Mon, Nov 25, 2019 at 12:07:25PM +0000, Ross Burton wrote:
>>> If you can send a patch sooner rather than later for lrzsz to fix the build
>>> with modern gettext then that would be *awesome*, as this recipe is the sole
>>> blocker.
>>
>> This works for me and should resolve your immediate issue.  We can think about
>> a better long-term solution separately.
> 
> Incidentally, "gettextize -f" would have taken care of the majority of this.  In
> autotools.bbclass we have:
> 
> 		elif [ "${BPN}" != "gettext" ] && grep -q "^[[:space:]]*AM_GNU_GETTEXT" $CONFIGURE_AC; then
> 			# We'd call gettextize here if it wasn't so broken...
> 
> and we then proceed to do a slightly half-baked partial version of what
> gettextize would have done.  This results in using the Makefile.in.in from
> the version of gettext that's in the sysroot, but without any of the other
> bits that gettextize would have copied and this is arguably the worst of
> all possible outcomes.  Actually running gettextize is indeed problematic
> because it has a tendency to require you to press RETURN on the terminal
> (and it reads from /dev/tty to avoid any attempt to subvert this check
> by redirecting stdin!) but I think one could argue that if we can't/won't
> run the full gettextize then we oughtn't to be messing around with any
> of the files that it installs and we should rely on the ones that the
> upstream package shipped.  That may not always work either, but I have at
> least half a suspicion that the current autotools.bbclass behaviour is
> creating as many problems as it solves.

gettextize is dead, autopoint is the glorious future, and I've a branch 
that is practically complete implementing that (ross/autopoint).

Ross