When USE="afs" is specified to build app-crypt/kstart-3.16 the resulting k5start binary when invoked "k5start -t ..." with AKLOG _not_ specified in the environment will run the "yes" binary resulting in a non-terminating sequence of "y\n" written to the terminal. This is not useful default behaviour. Note this is a change from app-crypt/kstart-3.15 behaviour in which /usr/bin/aklog was run by default when "-t" was specified and AKLOG was not set in the environment. Reproducible: Always Steps to Reproduce: 1. build app-crypt/kstart-3.16 with USE="afs" 2. run "k5start -h" to see what would be run when invoked with "-t" 3. or run "k5start -t -H 30 $USER" Actual Results: shell$ k5start -h [...] If the environment variable AKLOG (or KINIT_PROG for backward compatibility) is set to a program (such as aklog) then this program will be executed when requested by the -t flag. Otherwise, the program executed will be yes. shell$ k5start -t -H 30 $USER [maybe prompts for kerberos creds] y y y y [...]^C shell$ tokens [shows no AFS tokens] Expected Results: shell$ k5start -h [...] If the environment variable AKLOG (or KINIT_PROG for backward compatibility) is set to a program (such as aklog) then this program will be executed when requested by the -t flag. Otherwise, the program executed will be /usr/bin/aklog. shell$ k5start -t -H 30 $USER [maybe prompts for kerberos creds] shell$ tokens [shows valid AFS tokens] The problem appears to be that kstart-3.16.ebuild now specifies econf ... "$(use_with afs aklog)" ... which results in a "--with-aklog" option passed to configure. Thus PATH_AKLOG is configured to "yes". This seems to be by upstream design. If "--with-aklog" is not specified at all then configure searches for "aklog" or "afslog" in PATH at configure time and uses the first it finds. This appears to result in a more useful behaving built k5start binary. It should possibly also be noted that kstart-3.16.ebuild currently lists afs? ( net-fs/openafs ) as a runtime RDEPEND which is apparently inconsistent with "$(use_with afs)" and "$(use_enable afs setpag)" supplied to configure both of which (I think) actually represent build time dependencies requiring headers and libraries to build against. Thus if "afs? ( net-fs/openafs )" were made into a plain DEPEND and the "$(use_with afs aklog)" configure argument were removed then both the above inconsistencies will be removed and configure will naturally find an appropriate "aklog" or "afslog" and configure an appropriate PATH_AKLOG. I hesititate to suggest this is an ideal solution.
Nevertheless, that is what we will do. Changed without a rev bump: + 27 Mar 2011; Eray Aslan <eras@gentoo.org> kstart-3.16.ebuild: + do not pass aklog to configure script - bug 360589 + Thanks for the report.