I'm guessing it doesn't like the ~ character. I haven't looked at the registry in-depth, but I'm assuming it just uses the receipts (/opt/local/var/db/dports/receipts). If you delete the slrn-dev folder from receipts that might fix your registry. Of course, theoretically you might have a problem with your file map, but since it failed at the activation phase I doubt it had gotten around to modifying the file map yet. On Jan 3, 2007, at 2:20 PM, Sbranzo wrote:

I thinks there's a bug in the way port names are handled. I'm trying to compile a cvs snapshot of slrn, the same present in debian experimental. The debian maintainer assigned 0.9.8.1pl2~cvs20061116 as version number, and I wish to keep this convention.

If I manually change some links before the ./configure phase (refer to my previous email) I can build and install my port using macports, but it blocks here:

$ sudo port -vc install slrn-dev +ssl +pull [...] ./opt/local/share/slrn/macros/xcomment.sl ---> Archive slrn-dev-0.9.8.1pl2~cvs20061116_0+pull+ssl.powerpc.tgz packaged ---> Archive for slrn-dev 0.9.8.1pl2~cvs20061116_0+pull+ssl packaged ---> Installing slrn-dev 0.9.8.1pl2~cvs20061116_0+pull+ssl ---> Activating slrn-dev 0.9.8.1pl2~cvs20061116_0+pull+ssl Error: Target com.apple.activate returned: Registry error: slrn-dev cvs20061116_0+pull+ssl not registered as installed. Warning: the following items did not execute (for slrn-dev): com.apple.activate Error: Status 1 encountered during processing.

If you notice the version should be 0.9.8.1pl2~cvs20061116_0+pull+ssl but com.apple.activate sees only cvs20061116_0+pull+ssl.

Now I officially have a screwed installations of macports :-D

$ port installed Error: port installed failed: Registry error: slrn-dev cvs20061116_0+pull+ssl not registered as installed. No ports are installed.

How can I repair it?

-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com

On Jan 3, 2007, at 6:08 PM, Kevin Ballard wrote:

I've CC'ed the dev list - anybody have any thoughts on modifying the version-matching regex here? And does anybody know of any other locations where the version is matched against a regex?

Final thoughts: I just remembered that this same routine uses glob to find the version directory, so versions would also have to restrict asterisks, questionmarks, braces, brackets, and backslashes (basically, anything that's special to glob). But my stance is the more liberal we can make the version matching, the better.

We had a bunch of problems in the past with more liberal name allowances and ended up being this restrictive to prevent future problems. I'm not sure if the people who worked on this before are still around to comment or not. In any case, any changes to this would need a lot of testing to be sure it doesn't break more than it fixes. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+