Re: portindex fails due to portfile parsing
On 20 Mar 2018, at 00:34, Ryan Schmidt wrote: > Error: Unable to determine location of a macOS SDK. Could it instead be a warning?
jupyter-2.7 vs. ipython
I can't tell if this is a bug in MacPorts, or if I have simply misconfigured something. When I start up `ipython notebook`, with python-2.7 as my selected python, everything works fine, but I get a complaint echoed to the shell: ``` [TerminalIPythonApp] WARNING | Subcommand `ipython notebook` is deprecated and will be removed in future versions. [TerminalIPythonApp] WARNING | You likely want to use `jupyter notebook` in the future ``` All works well, nevertheless, and I'm happy, except for the crabby note from ipython. But, if I try to do what the message says, and run `jupyter notebook` instead, I get an error: ``` $ jupyter-2.7 notebook Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/jupyter-notebook", line 6, in from pkg_resources import load_entry_point File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3195, in @_call_aside File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3179, in _call_aside f(*args, **kwargs) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3208, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 681, in _build_master ws.require(__requires__) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 999, in require needed = self.resolve(parse_requirements(requirements)) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", line 885, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'futures' distribution was not found and is required by tornado ``` So I was wondering if there's an issue with jupyter or, if somehow I've gotten things misconfigured. Thanks
Re: jupyter-2.7 vs. ipython
I just posted a ticket for this very issue: https://trac.macports.org/ticket/56111 > On Mar 20, 2018, at 1:19 PM, Robert Goldman wrote: > > I can't tell if this is a bug in MacPorts, or if I have simply misconfigured > something. > > When I start up ipython notebook, with python-2.7 as my selected python, > everything works fine, but I get a complaint echoed to the shell: > > [TerminalIPythonApp] WARNING | Subcommand `ipython notebook` is deprecated > and will be removed in future versions. > [TerminalIPythonApp] WARNING | You likely want to use `jupyter notebook` in > the future > All works well, nevertheless, and I'm happy, except for the crabby note from > ipython. > > But, if I try to do what the message says, and run jupyter notebook instead, > I get an error: > > $ jupyter-2.7 notebook > Traceback (most recent call last): > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/jupyter-notebook", > line 6, in > from pkg_resources import load_entry_point > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 3195, in > @_call_aside > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 3179, in _call_aside > f(*args, **kwargs) > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 3208, in _initialize_master_working_set > working_set = WorkingSet._build_master() > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 681, in _build_master > ws.require(__requires__) > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 999, in require > needed = self.resolve(parse_requirements(requirements)) > File > "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pkg_resources/__init__.py", > line 885, in resolve > raise DistributionNotFound(req, requirers) > pkg_resources.DistributionNotFound: The 'futures' distribution was not found > and is required by tornado > So I was wondering if there's an issue with jupyter or, if somehow I've > gotten things misconfigured. > > Thanks > Marius -- Marius Schamschula
Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
So I installed gcc6 on my 10.5 G5 PowerMac a few days ago and it was a breeze. It took just a few minutes. It looked like the installer just grabbed the binaries and installed them. No big deal at all. Now I am trying to install gcc6 on my 10.4 G4 Mac Mini and it seems to build everything from sources and it's taking ages. Building apple-gcc42 took two hours alone and that was just the first of many packages to come. I'm worried about my hardware because the CPU is at 100% all the time causing the Mac Mini fan to be in full ventilation all the time. It has been running like that for 3 hours now and there are still many more packages to go. If it's going to continue at that speed, I'd estimate the gcc6 installation to take about 12 hours or so. Where does this difference come from? On my 10.5 G5 PowerMac it really was just a few minutes and now it's taking hours. Yes, the G5 is faster but certainly not that much. To me it looked as if on 10.5 binaries were downloaded and installed whereas on 10.4 everything is built from scratch. Is that right? If it is, there really should be a warning that this is going to take ages because once the thing has been started there's no way out since I don't want to interrupt it in the middle of installing for fear of breaking something. And I'm worried about my hardware. It's 13 years old and now has to run under full stress for hours and hours and hours :-/ Why doesn't Mac Ports simply provide ready to run binaries for 10.4 PPC? The current installation process feels a little bit like maximum overdose for my poor old PPC Mac Mini... -- Best regards, Andreas Falkenhahn mailto:andr...@falkenhahn.com
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 10.5 you installed a prebuilt binary. gcc6 takes 12 to 24 hrs to build on a PPC machine. I should make my premade binaries available. K > On Mar 20, 2018, at 14:32, Andreas Falkenhahn wrote: > > > > So I installed gcc6 on my 10.5 G5 PowerMac a few days ago and it was a breeze. > It took just a few minutes. It looked like the installer just grabbed the > binaries > and installed them. No big deal at all. > > Now I am trying to install gcc6 on my 10.4 G4 Mac Mini and it seems to build > everything from sources and it's taking ages. Building apple-gcc42 took two > hours alone and that was just the first of many packages to come. > > I'm worried about my hardware because the CPU is at 100% all the time causing > the Mac Mini fan to be in full ventilation all the time. It has been running > like that for 3 hours now and there are still many more packages to go. If > it's > going to continue at that speed, I'd estimate the gcc6 installation to take > about 12 hours or so. > > Where does this difference come from? On my 10.5 G5 PowerMac it really was > just a few minutes and now it's taking hours. Yes, the G5 is faster but > certainly not that much. To me it looked as if on 10.5 binaries were > downloaded and installed whereas on 10.4 everything is built from scratch. > Is that right? > > If it is, there really should be a warning that this is going to take ages > because once the thing has been started there's no way out since I don't > want to interrupt it in the middle of installing for fear of breaking > something. And I'm worried about my hardware. It's 13 years old and now > has to run under full stress for hours and hours and hours :-/ Why doesn't > Mac Ports simply provide ready to run binaries for 10.4 PPC? The current > installation process feels a little bit like maximum overdose for my > poor old PPC Mac Mini... > > > > -- > Best regards, > Andreas Falkenhahn mailto:andr...@falkenhahn.com >
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 20.03.2018 at 21:35 Ken Cunningham wrote: > On 10.5 you installed a prebuilt binary. > gcc6 takes 12 to 24 hrs to build on a PPC machine. Oh my, that's too much for me, I've just hit CTRL-C. Of course this might leave me with a corrupt installation but I'm just too paranoid about Mac Ports killing my hardware. IMHO there really should be prebuilt binaries for 10.4. It's a waste of energy and resources to have everybody build this on his own... -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On Mar 20, 2018, at 4:43 PM, Andreas Falkenhahn wrote: > IMHO there really should be prebuilt binaries for 10.4. It's a waste of > energy and resources to have everybody build this on his own... IMHO we shouldn't do anything to support Mac OS versions that aren't getting security patches from Apple anymore (since it's a dis-service to the rest of the people who use the internet when we make it easier for people to keep unpatched machines connected to that shared resource). if you really want it, it's possible for anyone to run a 10.4 build machine and share archives: https://trac.macports.org/wiki/howto/ShareArchives2 -- Daniel J. Luke
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 2018-03-20 21:43, Andreas Falkenhahn wrote: > On 20.03.2018 at 21:35 Ken Cunningham wrote: > >> On 10.5 you installed a prebuilt binary. >> gcc6 takes 12 to 24 hrs to build on a PPC machine. > > Oh my, that's too much for me, I've just hit CTRL-C. Of course this might > leave me with a corrupt installation but I'm just too paranoid about Mac > Ports killing my hardware. > > IMHO there really should be prebuilt binaries for 10.4. It's a waste of > energy and resources to have everybody build this on his own... I try to understand your frustration, but how many users of 10.4 on PPC are out there? It probably takes more energy to build all the ports nobody is ever going to install. As you noticed it takes a lot of time to compile for 10.4 PPC. I see no benefit of building for that, as the resources are better spent on building binary archives for recent releases. Personally, I do not understand why you are still running such an old machine with macOS. This system is unsupported by Apple for about 10 years by now. In my opinion if you want to keep using the hardware, install Linux or FreeBSD, but macOS for that platform is dead for a long time already. Rainer
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On 20.03.2018 at 21:58 Rainer Müller wrote: > Personally, I do not understand why you are still running such an old > machine with macOS. It's retro, there doesn't have to be a rational reason for it :-) Besides, in the retro scene 10.4 is quite popular because it's the last Mac OS capable of running Mac OS 9 software. I also have a 10.6 installation which I won't update because 10.6 has Rosetta (PPC emulation). It's vintage - it needn't make sense. -- Best regards, Andreas Falkenhahnmailto:andr...@falkenhahn.com
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
+1. Uli > On Mar 20, 2018, at 4:27 PM, Andreas Falkenhahn > wrote: > > On 20.03.2018 at 21:58 Rainer Müller wrote: > >> Personally, I do not understand why you are still running such an old >> machine with macOS. > > It's retro, there doesn't have to be a rational reason for it :-) > Besides, in the retro scene 10.4 is quite popular because it's the > last Mac OS capable of running Mac OS 9 software. > > I also have a 10.6 installation which I won't update because 10.6 > has Rosetta (PPC emulation). It's vintage - it needn't make sense. > > -- > Best regards, > Andreas Falkenhahnmailto:andr...@falkenhahn.com >
Re: portindex fails due to portfile parsing
> On Mar 19, 2018, at 4:34 PM, Ryan Schmidt wrote:
>
> Ok, I've figured out that the reason why I'm not seeing the "Unable to
> determine location of a macOS SDK" message is that I was running MacPorts
> 2.4.2 and the message is new for MacPorts 2.5. MacPorts 2.5 considers it an
> error when it can't find an SDK. MacPorts 2.4.x and earlier just returned the
> empty string. So you must be running the unreleased MacPorts 2.5.
>
> Jeremy added this error message and the change in configure.sdk_root
> behavior. Jeremy, what should we do about this?
We definitely want to err out if we cannot find an SDK, so we should figure out
a way to support a better pattern that addresses the problems below.
> For background: the textmate2 port requires the 10.11 SDK or later, so if
> configure.sdk_version is less than 10.11, it sets it to 10.11. It then tests
> if configure.sdkroot is nonempty, and if so, uses it. I've used this idiom in
> a handful of other ports.
Eek. We should figure out a nicer way to describe that. Perhaps we should add
support for SDK version requirements.
> This user is on 10.8, which doesn't have the 10.11 SDK. So with MacPorts
> 2.4.2, configure.sdkroot is empty, the port tries to build without an SDK,
> and fails. Fine; we know about that and it's on my to-do list to fix it. But
> MacPorts 2.5 changes it so that configure.sdkroot is undefined, and the port
> thus fails to be usable at all, preventing even "port info" and "portindex"
> from working:
>
> Error: Unable to determine location of a macOS SDK.
> Can't map the URL 'file://.' to a port description file ("can't read
> "configure.sdkroot": Unable to determine location of a macOS SDK.").
> Please verify that the directory and portfile syntax are correct.
> To use the current port, you must be in a port's directory.
For now, can you maybe do the shenanigans with configure.sdk_version in
pre-configure?
> One possible solution: I've been working on a project to make all SDKs
> available on all macOS versions, via a set of new ports. (I'm sure we're not
> allowed to distribute the SDKs, so these new ports work by requiring the user
> to download a specific version of Xcode from Apple, and it extracts the SDK
> from there.) My intention is that if a port requires an SDK that does not
> exist in the installed version of Xcode, it will add a dependency on the
> corresponding macOS SDK port and use that. If that behavior were in base,
> then that should eliminate the situations (other than user error) where
> configure.sdk_root would return an error.
This starts getting complicated because SDKs are very tied to the toolchains.
It's hard enough trying to get the OSS toolchains to work with all of the SDKs
we support. I cringe at trying to get an older Xcode's toolchain to work with
a newer SDK.
Re: portindex fails due to portfile parsing
On Mar 20, 2018, at 17:22, Jeremy Huddleston Sequoia wrote:
> On Mar 19, 2018, at 4:34 PM, Ryan Schmidt wrote:
>
>> Ok, I've figured out that the reason why I'm not seeing the "Unable to
>> determine location of a macOS SDK" message is that I was running MacPorts
>> 2.4.2 and the message is new for MacPorts 2.5. MacPorts 2.5 considers it an
>> error when it can't find an SDK. MacPorts 2.4.x and earlier just returned
>> the empty string. So you must be running the unreleased MacPorts 2.5.
>>
>> Jeremy added this error message and the change in configure.sdk_root
>> behavior. Jeremy, what should we do about this?
>
> We definitely want to err out if we cannot find an SDK, so we should figure
> out a way to support a better pattern that addresses the problems below.
>
>> For background: the textmate2 port requires the 10.11 SDK or later, so if
>> configure.sdk_version is less than 10.11, it sets it to 10.11. It then tests
>> if configure.sdkroot is nonempty, and if so, uses it. I've used this idiom
>> in a handful of other ports.
>
> Eek. We should figure out a nicer way to describe that. Perhaps we should
> add support for SDK version requirements.
Yes we should have a way to specify a requirement on a range of SDK versions. I
mentioned it in another thread. I proposed a syntax similar to the one used for
compiler blacklist versions.
>> This user is on 10.8, which doesn't have the 10.11 SDK. So with MacPorts
>> 2.4.2, configure.sdkroot is empty, the port tries to build without an SDK,
>> and fails. Fine; we know about that and it's on my to-do list to fix it. But
>> MacPorts 2.5 changes it so that configure.sdkroot is undefined, and the port
>> thus fails to be usable at all, preventing even "port info" and "portindex"
>> from working:
>>
>> Error: Unable to determine location of a macOS SDK.
>> Can't map the URL 'file://.' to a port description file ("can't read
>> "configure.sdkroot": Unable to determine location of a macOS SDK.").
>> Please verify that the directory and portfile syntax are correct.
>> To use the current port, you must be in a port's directory.
>
> For now, can you maybe do the shenanigans with configure.sdk_version in
> pre-configure?
Possibly, but it's crappier to have to do that.
>> One possible solution: I've been working on a project to make all SDKs
>> available on all macOS versions, via a set of new ports. (I'm sure we're not
>> allowed to distribute the SDKs, so these new ports work by requiring the
>> user to download a specific version of Xcode from Apple, and it extracts the
>> SDK from there.) My intention is that if a port requires an SDK that does
>> not exist in the installed version of Xcode, it will add a dependency on the
>> corresponding macOS SDK port and use that. If that behavior were in base,
>> then that should eliminate the situations (other than user error) where
>> configure.sdk_root would return an error.
>
> This starts getting complicated because SDKs are very tied to the toolchains.
> It's hard enough trying to get the OSS toolchains to work with all of the
> SDKs we support. I cringe at trying to get an older Xcode's toolchain to
> work with a newer SDK.
I'm not concerned about that at all. The ports will simply blacklist
unacceptable compiler versions, as they would for any other reason.
Re: portindex fails due to portfile parsing
On Mar 20, 2018, at 08:29, db wrote: > On 20 Mar 2018, at 00:34, Ryan Schmidt wrote: >> Error: Unable to determine location of a macOS SDK. > > Could it instead be a warning? If a port specifies that it requires an SDK, and the SDK does not exist, it is proper for MacPorts to exit with an error at install time. What we need to figure out is how best to prevent MacPorts from exiting with an error at non-install times.
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
On Mar 20, 2018, at 15:32, Andreas Falkenhahn wrote: > Where does this difference come from? On my 10.5 G5 PowerMac it really was > just a few minutes and now it's taking hours. Yes, the G5 is faster but > certainly not that much. To me it looked as if on 10.5 binaries were > downloaded and installed whereas on 10.4 everything is built from scratch. > Is that right? Yes. We have never offered binaries for Mac OS X Tiger v10.4 or earlier. The ability for MacPorts to use binaries was added in version 2.0.0, released in 2011, at which point Tiger and Leopard had already been superseded by Snow Leopard for two years. We initially offered binaries for Snow Leopard x86_64, and added binaries for subsequent versions of macOS as they were released. When we left macOS forge at the end of 2016 and set up our own infrastructure and redesigned our build system, we also began building binaries for Snow Leopard i386 and Leopard ppc. We could purchase a second Power Mac G5 and start building binaries for Tiger ppc. There is not a great deal of interest in Tiger anymore, but I understand that the computers that are still running Tiger are slow and are thus the ones that might most benefit from the existence of binaries.
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
> On 20 Mar 2018, at 8:43 pm, Andreas Falkenhahn wrote: > >> On 20.03.2018 at 21:35 Ken Cunningham wrote: >> >> On 10.5 you installed a prebuilt binary. >> gcc6 takes 12 to 24 hrs to build on a PPC machine. > > Oh my, that's too much for me, I've just hit CTRL-C. Of course this might > leave me with a corrupt installation but I'm just too paranoid about Mac > Ports killing my hardware. > > IMHO there really should be prebuilt binaries for 10.4. It's a waste of > energy and resources to have everybody build this on his own... The user base still using 10.4 is tiny tending to zero. It simply is not worth the effort. > > -- > Best regards, > Andreas Falkenhahnmailto:andr...@falkenhahn.com >
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
> On 20 Mar 2018, at 8:48 pm, Daniel J. Luke wrote: > >> On Mar 20, 2018, at 4:43 PM, Andreas Falkenhahn >> wrote: >> IMHO there really should be prebuilt binaries for 10.4. It's a waste of >> energy and resources to have everybody build this on his own... > > IMHO we shouldn't do anything to support Mac OS versions that aren't getting > security patches from Apple anymore (since it's a dis-service to the rest of > the people who use the internet when we make it easier for people to keep > unpatched machines connected to that shared resource). Glad someone else has the same view on this as me. Completely agree. > > if you really want it, it's possible for anyone to run a 10.4 build machine > and share archives: https://trac.macports.org/wiki/howto/ShareArchives2 > -- > Daniel J. Luke > > >
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
> On 20 Mar 2018, at 9:27 pm, Andreas Falkenhahn wrote: > >> On 20.03.2018 at 21:58 Rainer Müller wrote: >> >> Personally, I do not understand why you are still running such an old >> machine with macOS. > > It's retro, there doesn't have to be a rational reason for it :-) > Besides, in the retro scene 10.4 is quite popular because it's the > last Mac OS capable of running Mac OS 9 software. > > I also have a 10.6 installation which I won't update because 10.6 > has Rosetta (PPC emulation). It's vintage - it needn't make sense. You can call these OSes ‘retro’ if you want, to make it sound good, but all they really are, are outdated and insecure. > > -- > Best regards, > Andreas Falkenhahnmailto:andr...@falkenhahn.com >
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
Hi, Chris Jones wrote: IMHO we shouldn't do anything to support Mac OS versions that aren't getting security patches from Apple anymore (since it's a dis-service to the rest of the people who use the internet when we make it easier for people to keep unpatched machines connected to that shared resource). Glad someone else has the same view on this as me. Completely agree. Personally, I disagree... it may be because I usem and because any of the mac I have can get updates, even if the hardware is fine and perfectly fine software can run on it. Almost any dual-core intel mac is quite fine for everyday usage, and running the last available (sadly becoming obsolete) Firefox versions shows hoe nice those computers are. Regarding PPC of course things are a bit worse, but there is "high value" in those machines because of their architecture (in my opinion "superior" or in an case "unique") and which is still a nice way to test e.g. Big-Endianness in a conveninet way or in any case portability. For others it has some "value", being the last in-house developed boards of Apple instead of commodity stuff slapped in a cool Apple case. I get a tear that I can run more op-to-date software on an old WIndows XP PC than on a much more modern Mac, with 10.5 or even 10.7. Just because Apple leaves people in the dust much earlier, free software shouldn't, even if it does. Sorry for the rant... I just love those old Macs too much. I need for them only one thin.. current TLS and a browser and they would be ready for every day! Riccardo
Re: portindex fails due to portfile parsing
On 2018-03-20, at 4:22 PM, Jeremy Huddleston Sequoia wrote: > > I cringe at trying to get an older Xcode's toolchain to work with a newer > SDK. > > Perhaps I shouldn't even say it, but here's what I do: symlink into the Xcode SDK the following toolchain bits from current MacPorts installs: clang clang++ ld64 strings nm set the compiler to clang 1.0 and the standard lib to libc++. And a tremendous amount of things then build on 10.6.8. Now I will duck before someone punches me. Ken
Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell
For the record, you can always stop a build by typing CTRL-C, and it will not corrupt anything. Only at the install stage are any files permanently changed. If you do "port clean" after stopping the build, you will be right back where you were before the build. David On Tue, Mar 20, 2018 at 4:13 PM, Riccardo Mottola via macports-users < macports-users@lists.macports.org> wrote: > Hi, > > Chris Jones wrote: > >> IMHO we shouldn't do anything to support Mac OS versions that aren't >>> getting security patches from Apple anymore (since it's a dis-service to >>> the rest of the people who use the internet when we make it easier for >>> people to keep unpatched machines connected to that shared resource). >>> >> Glad someone else has the same view on this as me. Completely agree. >> >> > > Personally, I disagree... it may be because I usem and because any of the > mac I have can get updates, even if the hardware is fine and perfectly fine > software can run on it. Almost any dual-core intel mac is quite fine for > everyday usage, and running the last available (sadly becoming obsolete) > Firefox versions shows hoe nice those computers are. > > Regarding PPC of course things are a bit worse, but there is "high value" > in those machines because of their architecture (in my opinion "superior" > or in an case "unique") and which is still a nice way to test e.g. > Big-Endianness in a conveninet way or in any case portability. > For others it has some "value", being the last in-house developed boards > of Apple instead of commodity stuff slapped in a cool Apple case. > > I get a tear that I can run more op-to-date software on an old WIndows XP > PC than on a much more modern Mac, with 10.5 or even 10.7. > Just because Apple leaves people in the dust much earlier, free software > shouldn't, even if it does. > > Sorry for the rant... I just love those old Macs too much. I need for them > only one thin.. current TLS and a browser and they would be ready for every > day! > > Riccardo >
