ebuild merge seems to have stopped working. It gives "ebuild generated output during depend phase (bad)" which doesn't help a lot. I tracked down the error to line 4201 of portage.py: lcfile=open(inforoot+"/COUNTER","w") and the error is obviously cased by a non-existent inforoot (i.e. settings["BUILDDIR"]+"/build-info"). A statement following this "lcfile=open" is not executed. This behaviour may be caused by manual compiles. Reproducible: Always Steps to Reproduce: 1. ebuild some.ebuild unpack 2. compile the package manually 3. touch $BUILDDIR/.compiled 4. ebuild some.ebuild merge Actual Results: i got an error message - "this ebuild produced output during depend phase (bad)" Expected Results: the package should have been merged
A workaround is available with manually creating $BUILDDIR/build-info If I do a mkdir $BUILDDIR/build-info ebuild some.ebuild merge cp some.ebuild $BUILDDIR/build-info/ it works, but there are only two files in $BUILDDIR/build-info - COUNTER and CONTENTS. The some.ebuild file is not copied to build-info on a merge and portage complains that it is missing.
portage is version 2.0.48
Well... I've changed ebuild.sh to accomodate this situation a bit better, but there is no reason for portage to endorse an app ou've built by hand. The data for the directory is created by the compile phase, which you are skipping. The CFLAGS and friends will not be created automatically by portage if you choose to not have portage do the work.
There is a situation when this could be needed. For example, when i "emerge transcode" (versions 0.6.3 or 0.6.4), I get a compilation error at a file, because the needed #include <glib.h> is missing from that file. It is easier for me to fix the error and then finish the compilation by myself (i.e. cd ${S}; make), and then touch .compiled and "ebuild merge". The alternative is to copy the package to my $PORTAGE_OVERLAY and add a patch to it and start all over with emerge. This reminds me that I haven't submitted a bugreport for transcode.
