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.
James
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