Darwin Version

Jeffrey A. Singleton gvibe06 at gmail.com
Sat Oct 3 06:35:53 PDT 2015


So I just read through this whole thread and it appears not a single person
understands the problem

After upgrading to El CapitanŠthen proceeding to do Œport selfupdate¹ I am
show the error reported by the original poster.

> root at minimac ~ #  port -v selfupdate
> Error: Current platform "darwin 15" does not match expected platform "darwin
> 14"
> Error: If you upgraded your OS, please follow the migration instructions:
> https://trac.macports.org/wiki/Migration
> OS platform mismatch
>     while executing
> "mportinit ui_options global_options global_variations"
> Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform
> mismatch

So I go to the migration page as mentioned in the error and begin with Step
1:

> root at minimac ~ #  port -qv installed > myports.txt
> Error: Current platform "darwin 15" does not match expected platform "darwin
> 14"
> Error: If you upgraded your OS, please follow the migration instructions:
> https://trac.macports.org/wiki/Migration
> Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform
> mismatch

As you can seeŠthe very first command run as instructed by the so-called
migration steps shows the same error. BasicallyŠ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.

Since the Œselfupdate¹ process won¹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Ša
very common step they do in almost every OS upgrade. It seems to me that
reinstalling MacPorts is the only way around thisŠ

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Šafter backing up all the
configuration files in /opt/local/etc/macports firstŠthen install.

Success!

After re-compiling MacPorts from source and confirming any custom
configurations were restoredŠthe Œselfupdate¹ process worked flawlessly.
Following this with Œport upgrade outdated¹ - order is once again restored
in the world.

I won¹t be responding to anything other than mature repliesŠif you can¹t be
smart without being an assŠsave your breath.

J

On 10/3/15, 8:02 AM, "Clemens Lang"
<macports-users-bounces at lists.macosforge.org on behalf of cal at macports.org>
wrote:

> Hi Jeremy,
> 
> ----- On 3 Oct, 2015, at 10:56, Jeremy Huddleston Sequoia jeremyhu at apple.com
> wrote:
> 
>>>  In theory, we have a solution for this problem: trace mode hides anything
>>> from
>>>  a port's build system that doesn't come with the system and is not in the
>>> list
>>>  of dependencies, so *in theory* we could replace migration with
>>>   sudo port -t upgrade outdated,
>>>  and in fact, I successfully tested this during the last OS upgrade. With
>>> the
>>>  upgrade to El Capitan, though, Apple's System Integrity Protection actually
>>>  breaks trace mode (Yay!), so this not an option, leading us to recommend
>>> the
>>>  migration procedure.
>>  
>>  How does SIP break it?  Do you have a radar or MP ticket?  I'm curious to
>>  followup on that.
> 
> DYLD_ variables are stripped from the environment when executing binaries
> under
> SIP. That no longer allows us to preload our tracing library into lots and
> lots
> of tools we use, such as /bin/sh, /usr/bin/python, /usr/bin/make,
> /usr/bin/clang,
> etc.
> 
> My impression is that this was a deliberate security decision to make sure the
> binary you are executing is actually the one protected by SIP and the exact
> version Apple provided. Please correct me if this assumption is wrong.
> 
> For now, I think trace mode can be modified to work around this limitation by
> keeping a shadow copy of all binaries under SIP it wants to execute; since we
> wrap posix_spawn and execve, we can determine whether the executed binary has
> SIP enabled, copy it if that's the case, and run the copy instead,
> circumventing the security measures.
> 
> Btw, what I would actually consider a bug is that running /usr/bin/env (or
> printenv) now no longer show any DYLD_* variables that may be set in your
> environment. Previously we would ask users to run env | grep DYLD_ to check
> for environment variables if they had trouble executing binaries installed
> using MacPorts. I guess we'll go with (set -o posix; set) | grep DYLD_ now,
> even though that's not the same.
> 
> -- 
> Clemens Lang
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20151003/f25b4d60/attachment.html>


More information about the macports-users mailing list