Re: Publishing links to non-encrypted websites for MacPorts downloads
On Thu, 26 Sep 2019 at 07:19, Ryan Schmidt wrote: > On Sep 26, 2019, at 00:04, Mojca Miklavec wrote: > > > I ended up navigating to > >https://www.macports.org/install.php#installing > > which points to > > > > https://github.com/macports/macports-base/releases/download/v2.6.0/MacPorts-2.6.0-10.6-SnowLeopard.pkg > > which doesn't work on 10.6 without some additional software being > > installed first. > > > > Now, the file is already at > > > > http://distfiles.macports.org/MacPorts/MacPorts-2.6.0-10.6-SnowLeopard.pkg > > which I remembered from the last time, but I don't see any link to it > > (I'm not saying there's not one, but if it is, it's definitely not > > obvious to users). > > It's because I fail at git again. I pushed the change to my fork instead of > the main repo. I've pushed it to the main repo now. Thank you. > > (PS: we need a big visible Download button on the first page at some point > > ...) > > There's a download button at the top right of every page. > > Yes, we need to redesign the web site. I believe you already showed me > somebody else's redesign, which looked good. ... and we should pick up that thread again :) https://lists.macports.org/pipermail/macports-dev/2019-May/040674.html Mojca
Re: Publishing links to non-encrypted websites for MacPorts downloads
On Sep 26, 2019, at 00:04, Mojca Miklavec wrote: > On Thu, 26 Sep 2019 at 06:26, Ryan Schmidt wrote: > >> On Sep 25, 2019, at 00:43, Mojca Miklavec wrote: >> >>> I already mentioned this in the past, but I would like to repeat. >>> When someone opens our homepage and wants to download MacPorts using >>> Safari on, say, 10.6, the download link from GitHub doesn't work, and >>> it's not trivial for users to find out the alternative link >>> (http://distfiles.macports.org/MacPorts/). >>> >>> Could we please publish both links to download MacPorts on our homepage? >> >> When Joshua releases a new version, he tags the release on GitHub and >> uploads the files there, and switches the links on our web site to point to >> GitHub. When I download the files to our distfiles server, I switch the >> links on the web site back to our distfiles server. Is that not sufficient? > > I ended up navigating to >https://www.macports.org/install.php#installing > which points to > > https://github.com/macports/macports-base/releases/download/v2.6.0/MacPorts-2.6.0-10.6-SnowLeopard.pkg > which doesn't work on 10.6 without some additional software being > installed first. > > Now, the file is already at >http://distfiles.macports.org/MacPorts/MacPorts-2.6.0-10.6-SnowLeopard.pkg > which I remembered from the last time, but I don't see any link to it > (I'm not saying there's not one, but if it is, it's definitely not > obvious to users). It's because I fail at git again. I pushed the change to my fork instead of the main repo. I've pushed it to the main repo now. https://github.com/macports/macports-www/commit/193a51cfd22e431996e860d35829a5ea59df14b4 > (PS: we need a big visible Download button on the first page at some point > ...) There's a download button at the top right of every page. Yes, we need to redesign the web site. I believe you already showed me somebody else's redesign, which looked good.
Re: Publishing links to non-encrypted websites for MacPorts downloads
On Thu, 26 Sep 2019 at 06:26, Ryan Schmidt wrote: > > > > On Sep 25, 2019, at 00:43, Mojca Miklavec wrote: > > > I already mentioned this in the past, but I would like to repeat. > > When someone opens our homepage and wants to download MacPorts using > > Safari on, say, 10.6, the download link from GitHub doesn't work, and > > it's not trivial for users to find out the alternative link > > (http://distfiles.macports.org/MacPorts/). > > > > Could we please publish both links to download MacPorts on our homepage? > > When Joshua releases a new version, he tags the release on GitHub and uploads > the files there, and switches the links on our web site to point to GitHub. > When I download the files to our distfiles server, I switch the links on the > web site back to our distfiles server. Is that not sufficient? I ended up navigating to https://www.macports.org/install.php#installing which points to https://github.com/macports/macports-base/releases/download/v2.6.0/MacPorts-2.6.0-10.6-SnowLeopard.pkg which doesn't work on 10.6 without some additional software being installed first. Now, the file is already at http://distfiles.macports.org/MacPorts/MacPorts-2.6.0-10.6-SnowLeopard.pkg which I remembered from the last time, but I don't see any link to it (I'm not saying there's not one, but if it is, it's definitely not obvious to users). Mojca (PS: we need a big visible Download button on the first page at some point ...)
Re: Publishing links to non-encrypted websites for MacPorts downloads
On Sep 25, 2019, at 00:43, Mojca Miklavec wrote: > I already mentioned this in the past, but I would like to repeat. > When someone opens our homepage and wants to download MacPorts using > Safari on, say, 10.6, the download link from GitHub doesn't work, and > it's not trivial for users to find out the alternative link > (http://distfiles.macports.org/MacPorts/). > > Could we please publish both links to download MacPorts on our homepage? When Joshua releases a new version, he tags the release on GitHub and uploads the files there, and switches the links on our web site to point to GitHub. When I download the files to our distfiles server, I switch the links on the web site back to our distfiles server. Is that not sufficient?
How to have macports-built software use an alternate libc++.dylib ?
For purposes of testing newer libc++ versions, and as there are some new
features in newer libc++ (filesystem, eg) releases that will soon become
attractive, it would be desirable if we could find a way to build software
against a different libc++ than the one in the system's lib directory.
I know there are tools in the macOS to do this -- I think the one we would need
to use is:
DYLD_LIBRARY_PATH /path/to/alternate/libc++.dylib
And I see in macports.conf that it is possible to have MacPorts use these extra
environment variables if desired.
Obviously we'd have to sort out how to not install the new version of libc++
into the sysroot accidentally, but once we secured that end of things, how
would we go about building a macports installation against an alternate
libc++.dylib that we would keep installed somewhere like
${prefix}/lib/libc++.dylib ?
Best,
Ken
# Extra environment variables to keep. MacPorts sanitizes its
# environment while processing ports, keeping:
# - DISPLAY
# - DYLD_FALLBACK_FRAMEWORK_PATH, DYLD_FALLBACK_LIBRARY_PATH,
# DYLD_FRAMEWORK_PATH, DYLD_INSERT_LIBRARIES, DYLD_LIBRARY_PATH
# - JAVA_HOME
# - ARCHIVE_SITE_LOCAL, MASTER_SITE_LOCAL, PATCH_SITE_LOCAL
# - PORTSRC
# - ALL_PROXY, FTP_PROXY, http_proxy, HTTPS_PROXY, NO_PROXY, RSYNC_PROXY
# - GROUP, USER
# - COLUMNS, LINES
# Variables listed in extra_env are added to this list. This has no
# default value; setting it is intended for advanced users and is
# unsupported. (Note that sudo(8) sanitizes its environment on OS X 10.5
# and later, so it may have to be configured to pass the desired
# variables to MacPorts.)
#extra_env KEEP_THIS THIS_TOO
Re: gcc/g++ failures after xcode11 update
Beyond the /usr/include issue, Xcode 11 should be problematic when its bundled 10.15 SDK is used under either Mojave or Catalina due to the enforced use of the availability attribute in the headers. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 On Wed, Sep 25, 2019 at 5:46 AM Chris Jones wrote: > > >> (*) The package to add back /usr/include currently does not exist in > >> 10.15 beta, so unless it reappears come final release this is going to > >> be more of a problem there…. > > > > This package is not going to be coming back: > > > https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035623 > > > > Indeed, it is not at all unexpected to no longer have this option with > Xcode 11. >
Re: gcc/g++ failures after xcode11 update
(*) The package to add back /usr/include currently does not exist in 10.15 beta, so unless it reappears come final release this is going to be more of a problem there…. This package is not going to be coming back: https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035623 Indeed, it is not at all unexpected to no longer have this option with Xcode 11.
