Re: [gentoo-alt] Prefix bootstrap stage3 pinentry fails when host system has FLTK

[Fabian Groffen]

Hi Stephen,

Thanks for the followup and better fix.

The bootstrap script indeed allows for certain "tricks", in a way it is
intended to be used like that, but it will never suggest that for
obvious reasons. :)

Good to hear bootstrapping succeed.  I still haven't had the time to
look into the ca-certificates issue, but it sounds nasty, and hard to
get by.

Thanks,
Fabian

On 14-05-2018 10:35:43 -0500, Stephen McCamant wrote:
> >>>>> "FG" == Fabian Groffen <grobian@g.o> writes:
>
> FG> Hi Stephen,
> FG> pinentry indeed has an "automagic dependency", the USE-flag would
> FG> solve this (be it that the patch you mention actually misses the
> FG> dependency when USE=fltk is in effect).
>
> FG> There is no easy way for you to fix it, other than faking it:
> FG> create a dummy $EPREFIX/usr/bin/fltk-config that returns false,
> FG> e.g. using
> FG> #!/usr/bin/false
>
> FG> You can add this file, make sure it is executable, and restart
> FG> bootstrapping.
>
> FG> I've filed https://bugs.gentoo.org/655290 for the automagic
> FG> dependency.
>
> In case anyone else is following along at home, the one amendment to
> make to Fabian's workaround suggestion is that it turns out that just
> having "fltk-config --api-version" return a failure error code is not
> enough to make the configure test fail. The test is written as:
>
>    FLTK_VERSION=`${FLTK_CONFIG} --api-version`
>    if test ${FLTK_VERSION} != "1.3" ; then
>
> so that failures of test are also not !=. So the fake fltk-config
> script needs to print a number other than 1.3, not just return false.
> But with that change, the workaround works as intended.
>
> The other key debugging technique that I ended up figuring out on my
> own is that you can test a bootstrap using a different version of the
> Portage tree by pre-filling a $PREFIX/usr/portage directory (for
> instance based on any commit from the repo/gentoo.git repository) and
> touching a ".unpacked" file within it. Another useful piece of
> information to know is that the Git commit corresponding to a Portage
> tree is in $PREFIX/usr/portage/metadata/timestamp.commit .
>
> In the time since, the bug that Fabian filed has also been fixed in a
> new ebuild from the pinentry maintainer. I've checked that that fixes
> things, by copying it into an older Portage tree (e.g., 6f597edb was
> the one from my original experiment) and doing a successful bootstrap.
>
>  -- Stephen
>

-- 
Fabian Groffen
Gentoo on a different level