<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-family: Calibri, sans-serif; font-size: 14px; color: rgb(0, 0, 0);"><div>So I just read through this whole thread and it appears not a single person understands the problem</div><div><br></div><div>After upgrading to El Capitan&#8230;then proceeding to do &#8216;port selfupdate&#8217; I am show the error reported by the original poster.</div><div><br></div><div><blockquote style="margin:0 0 0 40px; border:none; padding:0px;"><div>root@minimac ~ #  port -v selfupdate</div><div>Error: Current platform "darwin 15" does not match expected platform "darwin 14"</div><div>Error: If you upgraded your OS, please follow the migration instructions: https://trac.macports.org/wiki/Migration</div><div>OS platform mismatch</div><div>    while executing</div><div>"mportinit ui_options global_options global_variations"</div><div>Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform mismatch</div></blockquote><div><br></div></div><div>So I go to the migration page as mentioned in the error and begin with Step 1:</div><div><br></div><div><blockquote style="margin:0 0 0 40px; border:none; padding:0px;"><div>root@minimac ~ # &nbsp;port -qv installed &gt; myports.txt</div><div>Error: Current platform "darwin 15" does not match expected platform "darwin 14"</div><div>Error: If you upgraded your OS, please follow the migration instructions: https://trac.macports.org/wiki/Migration</div><div>Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform mismatch</div></blockquote></div><div><br></div><div>As you can see&#8230;the very first command run as instructed by the so-called migration steps shows the same error. Basically&#8230;nothing anyone has suggested so far even remotely comes close to a solution, and the migration page is useless. All of you making smart-ass comments, that seem to think you know everything need to shut up and let someone that intends to help try to provide a solution to the problem for the masses.</div><div><br></div><div>Since the &#8216;selfupdate&#8217; process won&#8217;t let you upgrade MacPorts, and the migration page assumes you are still using the same version of MacPorts, thus will not work since Apple bumped the platform version to Darwin 15&#8230;a very common step they do in almost every OS upgrade. It seems to me that reinstalling MacPorts is the only way around this&#8230;</div><div><br></div><div>To reinstall from PKG, we need to assume the package was compile on an El Capitan system so that the correct platform is used. Or if you are like me, and compiled your own MacPorts from source, then all that should be needed is to download the latest source and recompile&#8230;after backing up all the configuration files in /opt/local/etc/macports first&#8230;then install.</div><div><br></div><div>Success!</div><div><br></div><div>After re-compiling MacPorts from source and confirming any custom configurations were restored&#8230;the &#8216;selfupdate&#8217; process worked flawlessly. Following this with &#8216;port upgrade outdated&#8217; - order is once again restored in the world.</div><div><br></div><div>I won&#8217;t be responding to anything other than mature replies&#8230;if you can&#8217;t be smart without being an ass&#8230;save your breath.</div><div><br></div><div>J</div><div><br></div><div>On 10/3/15, 8:02 AM, "Clemens Lang" &lt;<a href="mailto:macports-users-bounces@lists.macosforge.org">macports-users-bounces@lists.macosforge.org</a> on behalf of <a href="mailto:cal@macports.org">cal@macports.org</a>&gt; wrote:</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div>Hi Jeremy,</div><div><br></div><div>----- On 3 Oct, 2015, at 10:56, Jeremy Huddleston Sequoia <a href="mailto:jeremyhu@apple.com">jeremyhu@apple.com</a> wrote:</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> In theory, we have a solution for this problem: trace mode hides anything from</div><div> a port's build system that doesn't come with the system and is not in the list</div><div> of dependencies, so *in theory* we could replace migration with</div><div>&nbsp;&nbsp;sudo port -t upgrade outdated,</div><div> and in fact, I successfully tested this during the last OS upgrade. With the</div><div> upgrade to El Capitan, though, Apple's System Integrity Protection actually</div><div> breaks trace mode (Yay!), so this not an option, leading us to recommend the</div><div> migration procedure.</div></blockquote><div> </div><div> How does SIP break it?&nbsp;&nbsp;Do you have a radar or MP ticket?&nbsp;&nbsp;I'm curious to</div><div> followup on that.</div></blockquote><div><br></div><div>DYLD_ variables are stripped from the environment when executing binaries under</div><div>SIP. That no longer allows us to preload our tracing library into lots and lots</div><div>of tools we use, such as /bin/sh, /usr/bin/python, /usr/bin/make, /usr/bin/clang,</div><div>etc.</div><div><br></div><div>My impression is that this was a deliberate security decision to make sure the</div><div>binary you are executing is actually the one protected by SIP and the exact</div><div>version Apple provided. Please correct me if this assumption is wrong.</div><div><br></div><div>For now, I think trace mode can be modified to work around this limitation by</div><div>keeping a shadow copy of all binaries under SIP it wants to execute; since we</div><div>wrap posix_spawn and execve, we can determine whether the executed binary has</div><div>SIP enabled, copy it if that's the case, and run the copy instead,</div><div>circumventing the security measures.</div><div><br></div><div>Btw, what I would actually consider a bug is that running /usr/bin/env (or</div><div>printenv) now no longer show any DYLD_* variables that may be set in your</div><div>environment. Previously we would ask users to run env | grep DYLD_ to check</div><div>for environment variables if they had trouble executing binaries installed</div><div>using MacPorts. I guess we'll go with (set -o posix; set) | grep DYLD_ now,</div><div>even though that's not the same.</div><div><br></div><div>-- </div><div>Clemens Lang</div><div>_______________________________________________</div><div>macports-users mailing list</div><div><a href="mailto:macports-users@lists.macosforge.org">macports-users@lists.macosforge.org</a></div><div><a href="https://lists.macosforge.org/mailman/listinfo/macports-users">https://lists.macosforge.org/mailman/listinfo/macports-users</a></div><div><br></div></blockquote></body></html>