Did someone bork eval_variants?

James Berry jberry at macports.org
Mon Apr 16 06:00:46 PDT 2007

Hi Jordan,

Yes, I cannot tell  lie. I did bork eval_variants in r24071. My  
change to option parsing suddenly allowed the malformed rsync_options  
to begin to be passed into the engine, which then broke. This option  
was apparently always silently ignored.

Not long after I discovered this problem I checked in r24072, which I  
believe fixed the issue. It fortified the engine against such  
malformed options, and also put in a special case to fix the  
mailformed rsync_options option in your ports.conf.

Let me know if the problem persists with ToT.

And sorry I didn't see your email before I went to bed.


On Apr 15, 2007, at 10:34 PM, Jordan K. Hubbard wrote:

> I'm seeing this from any port and any operation, so it looks like  
> something has gone south in ToT
> jkh at sam-> port -d -v livecheck
> DEBUG: Changing to port directory: .
> Can't map the URL 'file://.' to a port description file ("extra  
> characters after close-quote").
> Please verify that the directory and portfile syntax are correct.
> To use the current port, you must be in a port's directory.
> (you might also see this message if a pseudo-port such as
> outdated or installed expands to no ports).
> DEBUG: invalid command name "eval_variants"
>     while executing
> "eval_variants variations livecheck"
>     invoked from within
> "$workername eval eval_variants variations $target"
>     (procedure "dportexec" line 7)
>     invoked from within
> "dportexec $workername $target"
> Error: Unable to execute port: invalid command name "eval_variants"
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev

More information about the macports-dev mailing list