I found three problems with the elog 'custom' module. The first is that it tries to use the elogfilename from the 'save' module, which does not exist. The second is that the replace function is used on the command to replace the arguments, but the return value is ignored. I fixed the first problem by returning the log file name from the save module, and using it, and the second problem by not ignoring the return value. This is in the attached patch. The third problem is not really a bug but a deception: the value of the PORTAGE_ELOG_COMMAND variable in make.conf should be given with single quotes to avoid the variables being expanded. This is not so in the make.conf.example. I must added that the syntax is misleading. If PACKAGE and LOGFILE are not shell variables, they should not use that syntax (eg, I would expect $LOGFILE to work as well as ${LOGFILE}, but this isn't so.) A solution would be to export PACKAGE and LOGFILE as real shell variables prior to running the command, instead of using the replace function
Created attachment 75078 [details] a patch to fix the first two described problems
Ok, fixed the issues mentioned, but not going to change the syntax (it's the same as used for the FETCHCOMMAND family).
(In reply to comment #2) > Ok, fixed the issues mentioned, but not going to change the syntax (it's the > same as used for the FETCHCOMMAND family). > I'm not saying the syntax must be changed, I'm just saying that if this is the syntax it is more reasonable to change the implementation, so that the environment variables are actually set before calling the command, instead of replacing them syntactically. Unfortunately, I don't know any python so I can't suggest a patch, but there must be a way to set environment variables in python
(In reply to comment #3) > (In reply to comment #2) > > Ok, fixed the issues mentioned, but not going to change the syntax (it's the > > same as used for the FETCHCOMMAND family). > > > > I'm not saying the syntax must be changed, I'm just saying that if this is the > syntax it is more reasonable to change the implementation, so that the > environment variables are actually set before calling the command, instead of > replacing them syntactically. Unfortunately, I don't know any python so I can't > suggest a patch, but there must be a way to set environment variables in python > Well, let me rephrase: I'm using exactly the same means as FETCHCOMMAND does, which does it this way, so not going to change one without also changing the other, and that's beyond this bug.
Released in 2.1_pre2.
