Re: port install hyper as a binary fails due to lack of arm64 variant (M1 chip)
Again, thank you! On Thu, Jun 15, 2023 at 5:14 PM Ryan Schmidt wrote: > > On Apr 14, 2023, at 23:01, Kenneth Wolcott wrote: > > > port install hyper (build from source) fails (see bug #67241) > > I see the maintainer has not responded to the ticket. If you like, you could > file a bug report with the developers and see if they have any suggestions > for how to resolve this problem. > > > > port install hyper as a binary fails due to lack of arm64 variant (M1 chip) > > Naturally; we can't provide a binary if we cannot build that binary. >
Re: how to prepare an existing Macports instance for an xCode update or fix Macports after xCode update?
Thank you! On Thu, Jun 15, 2023 at 5:03 PM Ryan Schmidt wrote: > > On Jun 2, 2023, at 13:53, Kenneth Wolcott wrote: > > > how to prepare an existing Macports instance for an xCode update or > > fix Macports after xCode update? > > No preparation is needed. > > > I have an xCode update notification. > > > > I have an existing MacPorts installation. > > > > Do I need to do anything to the MacPorts installation prior to the xCode > > update? > > No. > > > Do I need to do anything to the MacPorts installation after the cxCode > > update? > > No. > > > After upgrading Xcode, make sure you open it once and complete any prompts, > including installing "additional components" and possibly agreeing to a > license. You can quit Xcode after completing these steps. > > If you have the command line tools installed, it's probably best to install > the CLT version that matches the Xcode version you have. You can download > Xcode and the CLT from the Apple developer download page.
Re: Portfile question for 10.6.8
On Thu, Jun 15, 2023 at 07:00:57PM -0500, Ryan Schmidt wrote: > On Jun 6, 2023, at 20:16, raf wrote: > > > That still leaves the question of how 10.6.8 hosts can download distfiles > > from a non-https site (when https sites won't support TLS 1.0). Do distfiles > > magically end up on http://distfiles.macports.org? > > Yes. Well, it's not magical, but it is automatic. When commits are made to > the master branch of macports-ports, a notification is sent by GitHub to our > buildbot system. It evaluates each commit and determines which of the ports > that were modified need to be built. For each one, it downloads its distfiles > (if they haven't already been downloaded) to the distfiles area of a private > fileserver, and then it builds it for each compatible macOS version. After a > successful build, binary archives are uploaded to the packages area of the > private fileserver. On an hourly basis, the contents of the private > fileserver are mirrored to the public master fileserver, and within hours > after that, the other MacPorts mirror servers synchronize their contents with > the master. > > If you like to watch what the buildbot is doing you can visit > https://build.macports.org/waterfall > > Each of our mirror servers have different capabilities and requirements when > it comes to https. MacPorts is configured to know which mirror server is able > to be reached via https on each version of macOS. The code that does that is > here for distfiles: > > https://github.com/macports/macports-ports/blob/dbf0d04659eb119cdec6a4c3fef6247345c6/_resources/port1.0/fetch/mirror_sites.tcl#L410-L464 > > and here for archives: > > https://github.com/macports/macports-ports/blob/dbf0d04659eb119cdec6a4c3fef6247345c6/_resources/port1.0/fetch/archive_sites.tcl#L3-L55 Hi Ryan, Thanks for the explanation. It's an amazing setup. cheers, raf .
Re: port install hyper as a binary fails due to lack of arm64 variant (M1 chip)
On Apr 14, 2023, at 23:01, Kenneth Wolcott wrote: > port install hyper (build from source) fails (see bug #67241) I see the maintainer has not responded to the ticket. If you like, you could file a bug report with the developers and see if they have any suggestions for how to resolve this problem. > port install hyper as a binary fails due to lack of arm64 variant (M1 chip) Naturally; we can't provide a binary if we cannot build that binary.
Re: ports.tar owner/group
On May 7, 2023, at 19:42, Kastus Shchuka wrote: > After running port sync I see files extracted from ports.tar owned by a > non-existent group with numerical id 505: > > $ ls -l > /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ > total 474776 > -rw-r--r-- 1 root admin 20472245 Apr 30 17:46 PortIndex > -rw-r--r-- 1 root admin512 Apr 30 18:29 PortIndex.rmd160 > drwxr-xr-x 30 root 505 960 Jan 30 18:30 base > -rw-r--r-- 1 root admin 114272256 Jan 30 18:51 base.tar > -rw-r--r-- 1 root admin512 Jan 30 18:51 base.tar.rmd160 > drwxr-xr-x 65 root 505 2080 Apr 30 19:21 ports > -rw-r--r-- 1 root admin 108322816 Apr 30 18:29 ports.tar > -rw-r--r-- 1 root admin512 Apr 30 18:29 ports.tar.rmd160 > > All files in ports.tar are owned by buildbot:buildbot or numerically 500/505. > > drwxr-xr-x 0 buildbot buildbot0 Mar 29 17:36 ports/ > -rw-r--r-- 0 buildbot buildbot 234 Nov 16 2020 ports/.gitattributes > drwxr-xr-x 0 buildbot buildbot0 Nov 26 10:09 ports/.github/ > -rw-r--r-- 0 buildbot buildbot 84 Nov 16 2020 ports/.gitignore > -rw-r--r-- 0 buildbot buildbot 1476 Mar 29 17:36 ports/.mailmap > -rw-r--r-- 0 buildbot buildbot 1996 Feb 8 23:57 ports/LICENSE > > drwxr-xr-x 0 500505 0 Mar 29 17:36 ports/ > -rw-r--r-- 0 500505 234 Nov 16 2020 ports/.gitattributes > drwxr-xr-x 0 500505 0 Nov 26 10:09 ports/.github/ > -rw-r--r-- 0 50050584 Nov 16 2020 ports/.gitignore > -rw-r--r-- 0 500505 1476 Mar 29 17:36 ports/.mailmap > -rw-r--r-- 0 500505 1996 Feb 8 23:57 ports/LICENSE > > > As I don't have local user with id 500 and neither I have group with id 505, > I end up with files owned by unknown group. > > I think it is a side effect of extracting ports.tar by user root which can > preserve original numeric ids. > > I wonder if extracted tarball should be forced to root:admin ownership after > extraction. > > Or do I need to create local user buildbot:buildbot (500:505) to continue > using binary packages? You should not need to do anything. I agree that the use of the 500 uid and 505 gid is untidy when those users don't exist on your system (or may exist but be some random user or group not related to this tarball), but as far as I know it should not cause any problems. These just happen to be the uid and gid of the buildbot user and group on the server that creates the tarball. Ideally I should fix the problem on the server by having it use fakeroot to change all the user and group names to macports when creating the tarball, but I haven't done that yet.
Re: how to prepare an existing Macports instance for an xCode update or fix Macports after xCode update?
On Jun 2, 2023, at 13:53, Kenneth Wolcott wrote: > how to prepare an existing Macports instance for an xCode update or > fix Macports after xCode update? No preparation is needed. > I have an xCode update notification. > > I have an existing MacPorts installation. > > Do I need to do anything to the MacPorts installation prior to the xCode > update? No. > Do I need to do anything to the MacPorts installation after the cxCode update? No. After upgrading Xcode, make sure you open it once and complete any prompts, including installing "additional components" and possibly agreeing to a license. You can quit Xcode after completing these steps. If you have the command line tools installed, it's probably best to install the CLT version that matches the Xcode version you have. You can download Xcode and the CLT from the Apple developer download page.
Re: Portfile question for 10.6.8
On Jun 6, 2023, at 20:16, raf wrote: > That still leaves the question of how 10.6.8 hosts can download distfiles > from a non-https site (when https sites won't support TLS 1.0). Do distfiles > magically end up on http://distfiles.macports.org? Yes. Well, it's not magical, but it is automatic. When commits are made to the master branch of macports-ports, a notification is sent by GitHub to our buildbot system. It evaluates each commit and determines which of the ports that were modified need to be built. For each one, it downloads its distfiles (if they haven't already been downloaded) to the distfiles area of a private fileserver, and then it builds it for each compatible macOS version. After a successful build, binary archives are uploaded to the packages area of the private fileserver. On an hourly basis, the contents of the private fileserver are mirrored to the public master fileserver, and within hours after that, the other MacPorts mirror servers synchronize their contents with the master. If you like to watch what the buildbot is doing you can visit https://build.macports.org/waterfall Each of our mirror servers have different capabilities and requirements when it comes to https. MacPorts is configured to know which mirror server is able to be reached via https on each version of macOS. The code that does that is here for distfiles: https://github.com/macports/macports-ports/blob/dbf0d04659eb119cdec6a4c3fef6247345c6/_resources/port1.0/fetch/mirror_sites.tcl#L410-L464 and here for archives: https://github.com/macports/macports-ports/blob/dbf0d04659eb119cdec6a4c3fef6247345c6/_resources/port1.0/fetch/archive_sites.tcl#L3-L55
nvi port on Ventura
I got an MBP modern enough to run Ventura. (My workhorse MBA cannot go above
High Sierra).
For my personal needs I prefer nvi over vim that comes with macOS. This is my
daily driver on MBA.
I can build nvi on High Sierra just fine, also binary package for High Sierra
is available from buildbots.
When I tried to install nvi on Ventura, first I noticed absence of binary
package. Next, my attempt to build port failed miserably.
I also found ticket #64197 on trac.
My first instinct was to try clang of the same version as on High Sierra
(clang-9.0), but that did not make any change. Build was still failing.
Then I checked nvi on homebrew and found out that it builds there on all macOS
versions and they have binaries available.
Homebrew formula adds this flag to configure:
# Xcode 12 needs the "-Wno-implicit-function-declaration" to compile
successfully
# The usual trick of setting $CFLAGS in the environment doesn't work for
this
# configure file though, but specifying an explicit CC setting does
system "./configure", "--prefix=#{prefix}",
"--program-prefix=n",
"--disable-dependency-tracking",
"CC=" + ENV.cc + "
-Wno-implicit-function-declaration"
This got me over the error "implicit declaration of function 'conv_enc'", but
the build was still breaking on the linking step.
What I found next was that configure script populates libtool with correct
setting of allow_undefined_flag on High Sierra, but not on Ventura. Apparently,
the logic in configure works for MACOSX_DEPLOYMENT_TARGET 10.* but not on any
higher versions of macOS.
I guess homebrew works around it by running autoreconfigure, but I was
unsuccessful in that as it complained about missing configure.ac file.
So my crude fix was a patch for configure script (with appropriate adjustments
to the portfile).
With this patch I was able to build nvi, and it is quite usable (in my limited
testing)
I commented on my findings in https://trac.macports.org/ticket/64197.
Thanks,
Kastus
