Re: How to Reinstall postgresql96 for Data Migration; Was: Time to delete old PostgreSQL from MacPorts?

required to migrate data to more recent PostgreSQL versions. Steve > On Nov 23, 2024, at 2:32 PM, Steven Smith wrote: > > I just discovered that I’ve been impacted by this recent update to the port > postgresql96—my fault entirely as there’s been plenty of warning on MacPorts >

How to Reinstall postgresql96 for Data Migration; Was: Time to delete old PostgreSQL from MacPorts?

I just discovered that I’ve been impacted by this recent update to the port postgresql96—my fault entirely as there’s been plenty of warning on MacPorts threads. I have PG96 data files, but see that I’ve auto-uninstalled PG96, and also PG96 no longer builds. I’d like to migrate to the latest P

Trace Builds Fail at Extract Phase

Trace builds often fail at the extract phase (example below). I see plenty of tickets about this on trac, but I’m not sure what the fix is. Is there a fix to allow trace builds to extract tarballs? > sudo port -vst destroot adblock2privoxy > ---> Computing dependencies for adblock2privoxy. > --

Request Merge of PR 18009; Was: PyTorch CI Build Issue Request for Help

Would some please merge the major version update of PyTorch in https://github.com/macports/macports-ports/pull/18009 to avoid unnecessary update delays caused by a CI issue? > On Mar 23, 2023, at 08:26, Steven Smith wrote: > > PyTorch build and runs fine locally, but the CI con

PyTorch CI Build Issue Request for Help

PyTorch build and runs fine locally, but the CI consistently fails with error below. This issue has created unnecessary delays in merging new PT versions. > 2023-03-18T18:24:32.7624930Z CMake Error at > third_party/fbgemm/CMakeLists.txt:76 (message): > 2023-03-18T18:24:32.7638400Z A compiler

PyTorch CI Build Issue Request for Help

PyTorch build and runs fine locally, but the CI consistently fails with error below. This issue has created unnecessary delays in merging new PT versions.2023-03-18T18:24:32.7624930Z CMake Error at third_party/fbgemm/CMakeLists.txt:76 (message): 2023-03-18T18:24:32.7638400Z A compiler with AVX512

Re: Legacy Support for GHC-Based Projects

ges.macports.org/stack/ > > https://packages.macports.org/ghc/ > > > Ken > > > > > > > >> On Jan 25, 2023, at 7:27 AM, Steven Smith wrote: >> >> I’d recommend starting with the low-hanging fruit. These are all stack-based >> builds, and stack can bu

Re: Legacy Support for GHC-Based Projects

I’d recommend starting with the low-hanging fruit. These are all stack-based builds, and stack can build itself back to Snow Leopard: https://ports.macports.org/port/stack/details/ Why doesn’t stack-based pandoc also build back to Snow Leopard? Is this a MacPorts issue or a Haskell-world issue?

Re: Legacy Support for GHC-Based Projects

that stack-based pandoc is working (or not) on a legacy platform also supported by stack back to Sierra?On Jan 17, 2023, at 09:08, Sergio Had wrote: If PPC is fixed on our end, I will try to upstream patches, so we won’t need to carry those. On Jan 17, 2023 21:47 +0800, Steven Smith , w

Re: Legacy Support for GHC-Based Projects

, but it is for x86 (and not in Macports). If anyone is good at cross-compiling, please ping me. We need to first build the latest GHC on 10.6.8 Intel and then cross-compile GHC for PPC. On Jan 17, 2023 06:15 +0800, Steven Smith , wrote: I recently added legacy-based support to pandoc, but I’m not

Legacy Support for GHC-Based Projects

I recently added legacy-based support to pandoc, but I’m not sure that the code I used is working. I’ll issue a revised PR based on any feedback and use a working version for other GHC-based projects. I used this

Ventura Upgrade Requires Reinstall of Commandlinetools to Build Haskell cabal-Based Tools

FYSA, An upgraded Ventura system on either Apple silicon or Intel is observed not have the directory /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk required for prebuilt Haskell cabal tools, and most likely other projects. This can be fixed by uninstalling and reinstalling Command Line T

Re: ImageMagick Upgrade to version 7.1.0-54 Hitting OpenCL ld errors

tions, so you'd normally link with '-framework OpenCL' > to get them. I notice the brew formula configures with --disable-opencl. > > - Josh > > On 2022-12-12 02:34 , Steven Smith wrote: >> I’m trying to upgrade the ImageMagick Portfile to version 7.1.0-54 and a

ImageMagick Upgrade to version 7.1.0-54 Hitting OpenCL ld errors

I’m trying to upgrade the ImageMagick Portfile to version 7.1.0-54 and am hitting linker errors with OpenCL. I see that homebrew has a working version at https://github.com/Homebrew/homebrew-core/blob/master/Formula/imagemagick.rb

Re: Checksum -s of apple-pki-bundle fetches from MacPorts, not Source

t change, > you need to treat it like a stealth update - > https://trac.macports.org/wiki/PortfileRecipes#stealth-updates > >> On Nov 13, 2022, at 5:53 AM, Steven Smith wrote: >> I’ve updated this port locally, but port is still fetching the old file from >> https://dist

Re: Checksum -s of apple-pki-bundle fetches from MacPorts, not Source

issue? > On Nov 12, 2022, at 8:06 AM, Steven Smith wrote: > > Re: https://trac.macports.org/ticket/66230 > <https://trac.macports.org/ticket/66230> > > This issue is caused because port fetches an expired certificate from > ​https://distfiles.macpor

Checksum -s of apple-pki-bundle fetches from MacPorts, not Source

Re: https://trac.macports.org/ticket/66230 This issue is caused because port fetches an expired certificate from ​https://distfiles.macports.org/apple-pki-bundle, not source: > sudo port clean --all apple-pki-bundle > sudo port -s checksum apple-pki-bund

Selfupdate to MacPorts 2.8.0 Throws Error 'Couldn't change permissions of the MacPorts sources'

I’m consistently getting this error across multiple boxes when doing a selfupdate to 2.8.0: > Congratulations, you have successfully upgraded the MacPorts system. > > Error: Couldn't change permissions of the MacPorts sources at > /opt/local/var/macports/sources/rsync.macports.org/macports/rele

Re: How to convert command.env tcl lists with spaces into working env strings

may be useful some day. Steve > On Sep 1, 2022, at 5:06 PM, Joshua Root wrote: > > On 2022-9-1 21:51 , Steven Smith wrote: >> How does one convert a build.env list into a working string for sh env? >> If I specify this build.env >>> build.env-append \ &

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

Thanks for the pointers. I now have this working with MacPorts libiconv.dylib libraries, and have bootrapped ghc and cabal binaries that are independent of /usr/lib/libiconv.dylib. Relevant PR’s and issues: https://github.com/macports/macports-ports/pull/15770

How to convert command.env tcl lists with spaces into working env strings

How does one convert a build.env list into a working string for sh env? If I specify this build.env > build.env-append \ > CC=${configure.cc} \ > "CFLAGS=${configure.cflags} [get_canonical_archflags cc]" and later say something like > system "env ${build.env}" This tcl string with br

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

"CPPFLAGS=${configure.cppflags}" \ > "CXX=${configure.cxx}" \ > "CXXFLAGS=${configure.cxxflags}" \ > "LDFLAGS=${configure.ldflags}" > On Aug 30, 2022, at 9:05 PM, Steven Smith wrote: >

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

SDKs/MacOSX12.sdk -arch > x86_64' > export CPPFLAGS='-I/opt/local/include > -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk' > On Aug 28, 2022, at 7:34 PM, Steven Smith wrote: > > Also, I’m perplexed with this doesn’t just work with the default

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

tps://github.com/ghc/ghc/blob/161a6f1fd62e797e978e7808a5f567fefa123f16/libraries/base/cbits/iconv.c#L4> this should just use these: > CPATH='/opt/local/include' > LIBRARY_PATH='/opt/local/lib' > On Aug 28, 2022, at 3:01 PM, Steven Smith wrote: > > Thanks

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

to Is there a way to hack this out to transform _iconv_open to _libiconv_open in the .a file? > On Aug 28, 2022, at 2:57 PM, Joshua Root wrote: > > On 2022-8-29 04:42 , Steven Smith wrote: >> Re: https://gitlab.haskell.org/ghc/ghc/-/issues/22118 >> <https://git

Re: Missing macOS libiconv.dylib Breaks ghc Bootstrap

P.S. CLT provides the file /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libiconv.tbd But is points to the nonexistent file: > install-name:'/usr/lib/libiconv.2.dylib' > On Aug 28, 2022, at 2:42 PM, Steven Smith wrote: > > Re: https://gitlab.haskel

Missing macOS libiconv.dylib Breaks ghc Bootstrap

Re: https://gitlab.haskell.org/ghc/ghc/-/issues/22118 I'm self-bootstrapping ghc 9.4.2 using hadrian for deployment on MacPorts. Running hadrian -f binary-dist throws this error: > :info:build "_iconv_close", referenced from: > :info:build

Re: Stack-Based Ports No Longer Building on ARM

find MacPorts’s libunwind? Or is there a way to declare a conflict with MacPorts’s native libunwind? Something like this should probably go into a platform arm {} block in haskell_stack-1.0.tcl. Steve > On Aug 24, 2022, at 7:43 AM, Joshua Root wrote: > > On 2022-8-24 21:20 , Steven Sm

Stack-Based Ports No Longer Building on ARM

I’ve observed on my M1 box that stack-based ports no longer build because of compiler issues with mixed architecture libraries, as more ports become native ARM. I’ve done enough troubleshooting (reinstalling CLT, Xcode, use_code=yes and so forth) to believe that this is a general problem—error m

Re: MacPorts custom installation prefix and precompiled binaries

not reality. > On Aug 7, 2022, at 07:57, Steven Smith wrote: > >  > You can use any prefix you want, precompiled binaries or no. Just go ahead > and do it. > > It appears that you may be misinterpreting the docs. This page simply tells > devs not to do stuff with ins

Re: MacPorts custom installation prefix and precompiled binaries

You can use any prefix you want, precompiled binaries or no. Just go ahead and do it. It appears that you may be misinterpreting the docs. This page simply tells devs not to do stuff with installers that will conflict with existing files in /opt/local: https://guide.macports.org/#using.binaries

Re: bazel 4.2 and 3.7 no longer building with native clang

idt wrote: >>> On Jul 13, 2022, at 11:46, Steven Smith wrote: >>> How does one reconfigure the bazel Portfile to use a previous version of >>> clang that has a chance of working to build previous versions of bazel, >>> which are in turn necessary to build the te

bazel 4.2 and 3.7 no longer building with native clang

I’m trying to update a bunch of tensorflow packages, but am getting hung up on bazel issues (see https://trac.macports.org/ticket/64442 ). I have a fix for this issue, but am unable to build either bazel 4.2 or 3.7 with the native /usr/bin/clang compiler,

Portfile test if specific port exists

How does one test the existence of a specific port? E.g. if {port_exists py310-tensorflow} { do this } else { do that }

Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance

> On May 16, 2022, at 2:19 PM, Ryan Schmidt wrote: > > Whenever the curl-ca-bundle port is updated to a new version, the > privoxy-pki-bundle port's revision should be increased so that it rebuilds > with the new bundle. A comment can be added to the curl-ca-bundle port to > remind people to d

Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance

> What has changed between the time that the buildbot built the package and the > time that the user installs it? The certs in curl-ca-bundle are updated regularly to clear out expired certs. Per the previous discussion, privoxy-pki-bundle uses these certs via a depends_lib, and unless a port r

Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance

s.macports.org/privoxy-pki-bundle > On May 22, 2022, at 5:19 AM, Ryan Schmidt wrote: > > On May 21, 2022, at 12:40, Steven Smith wrote: > >> Is there a way to achieve the second objective: prevent MacPorts from >> building and caching its own copy of the port content

Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance

from “source” with `port -s install`. > On May 19, 2022, at 11:02 PM, Daniel J. Luke wrote: > > On May 17, 2022, at 4:31 PM, Steven Smith wrote: >>> Whenever the curl-ca-bundle port is updated to a new version, the >>> privoxy-pki-bundle port's revision should

Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance

: > > On May 12, 2022, at 18:04, Steven Smith wrote: >> >> I tried to write privoxy-pki-bundle to have these two basic behaviors: >> >>• Updates to the file ${prefix}/share/curl/curl-ca-bundle.crt via port >> curl-ca-bundle will force reinstallation of th

privoxy-pki-bundle not Behaving as Desired – Request for Assistance

I tried to write privoxy-pki-bundle to have these two basic behaviors: Updates to the file ${prefix}/share/curl/curl-ca-bundle.crt via port curl-ca-bundle will force reinstallation of the CA file ${prefix}/etc/privoxy/CA/trustedCAs.pem with the new CAs. port install privoxy-pki-bundle will gener

Re: python2.7 pip install fails with SSLError

virtualenv mystery solved. It’s just a symlink to the now-removed native python 27 framework: > $ sudo ls -l /private/var/calendarserver/Library/CalendarServer/virtualenv > Password: > total 8 > lrwxr-xr-x 1 calendarserver wheel63 May 16 2019 .Python -> > /System/Library/Frameworks/P

Re: python2.7 pip install fails with SSLError

h file), '/usr/lib/.Python' > (no such file) Thanks for the conflicts_build advice—I’ll add it. > On Mar 17, 2022, at 15:41, Ryan Schmidt wrote: > > On Mar 17, 2022, at 14:37, Steven Smith wrote: > >> Thanks everyone for your responses and suggestions. >> &g

Re: python2.7 pip install fails with SSLError

gt; >> Does the port *have* to use python 2.7 ? Is it not compatible with python >> 3.x ? > > See https://github.com/apple/ccs-calendarserver/issues/537 where Steven asked > upstream for guidance on migrating to Python 3. There was no reply. The > project is no longer being developed. >

Re: python2.7 pip install fails with SSLError

cert issue) fails with the same error: > pip-2.7 install --cert /opt/local/etc/openssl/cert.pem -I --user setuptools > On Mar 14, 2022, at 9:18 PM, Jim DeLaHunt wrote: > > On 2022-03-14 17:09, Steven Smith wrote: >> I’m trying to update calendar-contacts-server to macOS 1

python2.7 pip install fails with SSLError

I’m trying to update calendar-contacts-server to macOS 12.3. This requires installing a bunch of stuff with python2.7’s pip. I’m hitting an SSLError at the command: > /opt/local/bin/python2.7 -m pip install -I --user setuptools==18.5 Is there a way of pointing MacPorts python2.7 pip at a set of

Re: M1 MacPorts failures, "configure: error: C compiler cannot create executables"

Thanks. I tried uninstall/reinstall Xcode/CLT. Unfortunately, same issue. I’m at a loss. Here’s the errors from e.g. expat’s config.log (not sure which of these belong in “ordinary” trapped errors for config tests): > configure:4453: /usr/bin/clang -V >&5 > clang: error: argument to '-V' is mis

M1 MacPorts failures, "configure: error: C compiler cannot create executables"

I’m recently hitting a ton of configure/build failures on an M1. This is, perhaps coincidentally, after an update to MacPorts 2.7.2. E.g. error on sqlite3: > configure: error: C compiler cannot create executables Is anyone else seeing this? To the best of my knowledge I haven’t changed any com

Re: /usr/bin/python will be removed in macOS 12.3!

> On Sat, Feb 19, 2022 at 05:23:41PM +, Christopher Jones wrote: >>> But how does one (a) find out the dependency exists and (b) make >>> sure the software finds python from MacPorts? Lots of ports take the obvious approach of simply creating a symlink or “python3" to MacPorts’s Python in,

Re: Any Django volunteers to co-mentor for Google Summer of Code?

years and would love to contribute what I can to help the community. - Steven > On Feb 3, 2022, at 8:44 AM, Mojca Miklavec wrote: > > Hi, > > I wanted to ask if we happen to have any volunteers to co-mentor a > Django project for GSOC > for further improvements of https

Re: FAQ and Wiki page about -Wimplicit-function-declaration warning, review welcomed

Thanks for this. I found the FAQ and guide very useful. > On Jan 24, 2022, at 2:42 AM, Jim DeLaHunt wrote: > > Hello, MacPorts developers: > > I was working on a Portfile, and came across the ever-popular "Warning: > Configuration logfiles contain indications of > -Wimplicit-function-declarat

Re: bazel build points to builder directory _opt_bblocal_var_buildworker_ports_build_ports_devel_bazel

Thanks. Please see https://trac.macports.org/ticket/64442. > On Jan 14, 2022, at 08:30, Christopher Jones wrote: > >  > > please open a trac ticket and we will discuss there. better than a mailing > list. > >> On 14 Jan 2022, at 11:55 am, Steven Smith wrote

Re: bazel build points to builder directory _opt_bblocal_var_buildworker_ports_build_ports_devel_bazel

build stage. Attachments: main.log.xz Description: application/xz Portfile Description: Binary data On Jan 14, 2022, at 2:52 AM, Christopher Jones <jon...@hep.phy.cam.ac.uk> wrote:On 14 Jan 2022, at 3:14 am, Steven Smith <steve.t.sm...@gmail.com> wrote:I’m trying to build/update py

bazel build points to builder directory _opt_bblocal_var_buildworker_ports_build_ports_devel_bazel

I’m trying to build/update py-tensforflow-metadat and am hitting this (bizarre) bazel issue. First, the build fails with the error: > :info:build Execution platform: @local_config_platform//:host > :info:build Use --sandbox_debug to see verbose messages from the sandbox > :info:build xcrun: erro

Re: Significant security vulnerability discovered in Log4j

Also please see https://github.com/macports/macports-ports/pull/13361 > On Dec 14, 2021, at 6:47 PM, Nils Breunese wrote: > > A couple of hours ago > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 >

Re: Significant security vulnerability discovered in Log4j

Thank you for posting! Please see https://github.com/macports/macports-ports/pull/13353 . > On Dec 14, 2021, at 6:47 PM, Nils Breunese wrote: > > A couple of hours ago > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 >

Re: Significant security vulnerability discovered in Log4j

Please see https://github.com/macports/macports-ports/pull/13331 > On Dec 12, 2021, at 7:36 AM, Nils Breunese wrote: > > 2. elasticsearch 7.15.2_0 includes log4j-core-2.11.1.jar, which is a > vulnerable version of Log4J 2.x > > https://github.com/elastic/elasticsearch/issues/81618 >

Re: Significant security vulnerability discovered in Log4j

Please see: https://github.com/macports/macports-ports/pull/13322 > On Dec 12, 2021, at 7:36 AM, Nils Breunese wrote: > > https://github.com/apache/solr/pull/454#issuecomment-991066278 > says: "Just > open your solr.in.sh in your

Re: upgrade to openssl 3.0.0

FYSA `postfix +tls` must also be updated after the jump to OpenSSL 3. Please see https://github.com/macports/macports-ports/pull/12856.

Re: Request CI Help with PR #122660: find: /tmp/mpbb: No such file or directory

This is now fixed; the cause was several user errors. > I’m getting persistent CI errors on #12660: find: /tmp/mpbb: No such file or > directory > > I’ve already tried a few empty force-pushes to restart the CI, and a rebase > with the latest HEAD. > > I’m not aware of any Portfile issues and

Request CI Help with PR #122660: find: /tmp/mpbb: No such file or directory

I’m getting persistent CI errors on #12660: find: /tmp/mpbb: No such file or directory I’ve already tried a few empty force-pushes to restart the CI, and a rebase with the latest HEAD. I’m not aware of any Portfile issues and believe this is some CI issue. Any pointers would be appreciated. h

rspamd version 3.0 fails to build with implicit type checking error

I'm trying to update MacPorts rspamd from version 2.7 to 3.0.Version 3.0 fails to build on macOS, using the same build commands as a successfully built 2.7.  I’ve opened upstream issue https://github.com/rspamd/rspamd/issues/3893, and the developer says that he has no problem building on macOS with

Re: kibana submission node version conflict issue

I’ve updated this submission with a working Portfile that uses the elastic build, just like the elasticsearch port. > On Sep 2, 2021, at 20:14, Steven Smith wrote: > >  >> Why not use bazel? > > > Because bazel a major PITA, doesn’t work well or at all behind firewa

Re: kibana submission node version conflict issue

Why not use > bazel? > >> On Sep 2, 2021, at 2:32 PM, Steven Smith wrote: >> >> Newer versions of kibana need bazel to build: >> https://github.com/elastic/kibana/blob/7.14/package.json >> >>>> On Sep 2, 2021, at 16:54, Blair Zajac wrote: >>

Re: kibana submission node version conflict issue

Newer versions of kibana need bazel to build: https://github.com/elastic/kibana/blob/7.14/package.json > On Sep 2, 2021, at 16:54, Blair Zajac wrote: > > Newer kibana? Nodejs16 doesn’t need bazel... > >> On Sep 2, 2021, at 1:41 PM, Steven Smith wrote: >> >> T

Re: kibana submission node version conflict issue

The newer ones need (ugh) bazel to build. I’m thinking of just throwing in the towel and just using the pre-“built” download. > On Sep 2, 2021, at 10:26, Blair Zajac wrote: > > Is nodejs10 really needed? A newer nodejs won’t work? > > Blair > >> On Sep 2, 2021,

kibana submission node version conflict issue

I submitted a PR for Kibana: https://github.com/macports/macports-ports/pull/12055 The CI fails because of an issue with a conflicting dependency on the node version. kibana needs nodejs10 to build and run, and yarn to build; therefore,

Re: Haskell Stack Ports on Apple Silicon

Please see https://github.com/macports/macports-ports/pull/11897 <https://github.com/macports/macports-ports/pull/11897> for a working approach on both x86_64 and arm64. > On Aug 15, 2021, at 8:16 AM, Steven Smith wrote: > > I confirm that this approach does not wo

Re: Haskell Stack Ports on Apple Silicon

I confirm that this approach does not work on an M1 Mac. Trying to install a stack portion an M1—whether or not `supported_archs x86_64` is set—throws this architecture mismatch error when trying to install on the M1: > Cannot install shellcheck for the arch 'arm64' because > It’s dependency sta

Re: Haskell Stack Ports on Apple Silicon

nstall properly on an M1 Mac, using the fallback archs? > On Aug 15, 2021, at 00:12, Ken Cunningham > wrote: > >  > >> On Aug 14, 2021, at 7:13 PM, Joshua Root wrote: >> >>> On 2021-8-15 11:52 , Steven Smith wrote: >>> stack (and ghc, cabal) c

Re: Haskell Stack Ports on Apple Silicon

stack (and ghc, cabal) can only build x86_64, so it’s an x86_64 binary that runs on the M1 (whether built on x86_64 or arm64). The problem is that with the current supported_archs setting in stack, you hit this architecture mismatch error when trying to install pandoc on the M1: > Cannot instal

Re: Haskell Stack Ports on Apple Silicon

simply download the build-bot x86_64 binaries (if available), and avoid building on the M1. That this doesn’t happen by default on the M1 appears to be a related issue. > On Aug 14, 2021, at 00:48, Ryan Schmidt wrote: > > On Aug 13, 2021, at 10:58, Steven Smith wrote: >> If the Mac

Re: Haskell Stack Ports on Apple Silicon

t works on arm >> add that to the list, or probably better just remove it and rely on the >> defaults. >> >> Chris >> >>>> On 13 Aug 2021, at 1:55 pm, Steven Smith wrote: >>> >>> Is this line in the stack Portfile the issue? Ports (l

Re: Haskell Stack Ports on Apple Silicon

Is this line in the stack Portfile the issue? Ports (like pandoc) that are built using stack depend on the stack port, and port stack says that x86_64 is supported, but not arm64. However, stack installs and runs just fine on an M1 box. > supported_archs x86_64 https://github.com/macports

Haskell Stack Ports on Apple Silicon

I have an M1 box on which I’d like to install some haskell ports. The good news: `sudo port install stack` works and the binary runs on an M1. But when I try to install, e.g., pandoc, I hit this architecture mismatch error: > Cannot install pandoc for the arch 'arm64' because > It’s dependency s

Request for Review and Merge of graph-tool fix PR #11288

I’ve fixed an issue with graph-tool that has prevented its use on macOS 11 for 7 months: https://trac.macports.org/ticket/61583 ; and posted a PR: https://github.com/macports/macports-ports/pull/11288

Publicizing MacPorts

asonably asks for a reference link, for which there is none because MacPorts has made no such announcement. If MacPorts doesn’t tell its story, someone else will. > On Apr 22, 2021, at 10:09, Zero King wrote: > > On Mon, Apr 19, 2021 at 01:24:51PM +0200, Mojca Miklavec wrote: >>>

Re: Publicizing MacPorts

instead, the goal should be to identify > those who are unhappy with them and help them realize that there are > alternatives that might better suit their needs. For Homebrew at least I > honestly believe that they would be glad to send their underserved users our > way. We ju

Re: Publicizing MacPorts

mit new content, either basic HTML or HTML plus images. I must launch a localhost jekyll server? This looks like a high hurdle. How would I contribute content about a specific port? > On Apr 20, 2021, at 15:03, Rainer Müller wrote: > On 20/04/2021 12.40, Steven Smith wrote: >> That’s

Re: Publicizing MacPorts

without commit authority. > On Apr 20, 2021, at 03:05, Mojca Miklavec wrote: > > On Mon, 19 Apr 2021 at 15:14, Steven Smith wrote: >> >>> If you have contacts to tech reporters, please use them. I don't have any. >>> If Ars Technica or any other news s

Re: Publicizing MacPorts

> If you have contacts to tech reporters, please use them. I don't have any. If > Ars Technica or any other news site wants to cover MacPorts, they can do that > any time. This is the wrong attitude. MacPorts must tell them, not some random user/contributer like me. Everyone has tech reporter

Re: Publicizing MacPorts

> We never made any announcement since it basically "worked from day 1" Then that’s the announcement! No one will know this stuff if MacPorts doesn’t tell them. There must be one or two regular broadcast channels: perhaps a blog on your website for major announcer, and Twitter feed for regular

Re: Publicizing MacPorts

w now supports Apple Silicon natively, albeit not with every package. > On Apr 19, 2021, at 03:40, Ryan Schmidt wrote: > On Apr 18, 2021, at 07:28, Steven Smith wrote: > >>>> I completely agree that Homebrew is currently winning at publicity. >>> >>> Wha

Publicizing MacPorts

>> I completely agree that Homebrew is currently winning at publicity. > > What should the MacPorts community be doing do publicize MacPorts better? The new M1 architecture is a perfect opportunity to champion MacPorts’s strengths: • Strong emphasis on binaries built from source code, often spe

Existing fix for py-scipy shared objects with incorrect @rpath/libmkl_rt.dylib?

Re: https://trac.macports.org/ticket/62578 Is there a python or Portfile one-liner fix for the incorrect @rpath issues in py-scipy’s shared objects? We can code up an exhaustive search of the build for all the .so's and use install_name_tool-correct to correct this, but if possible I’d like to

Re: Bazel Builds Fail on macOS 10.15

Also affects tensorflow build itself. See: https://trac.macports.org/ticket/62474 > On Mar 17, 2021, at 10:05 AM, Steven Smith wrote: > > I’m trying to build a bunch of tensorflow and related ports whose upstreams > use the wonderful bazel build system. > > These used to

Bazel Builds Fail on macOS 10.15

I’m trying to build a bunch of tensorflow and related ports whose upstreams use the wonderful bazel build system. These used to work a few months ago, but now are all throwing the error below. Does anyone know how to resolve this issue. E.g. see: https://github.com/macports/macports-ports/pull/

Subtleties of Modifying post-configure

I need to run some post-configure steps in a cmake Portfile. I’m running into two these issues: Issue 1: cmake already has some post-configure code. How do I add stuff to whatever cmake already has? Not post-configure-append, I see. Not {*}${post-configure}. I don’t know enough of the guts of

Re: Dovecot Update Fails to Build in CI, Trace Mode

> I don't see bison listed as a build dependency in that port. Doh! It’s kind of obvious now that you say it. Thank you. This looks like a difference between: > $ /usr/bin/bison --version > bison (GNU Bison) 2.3 > > $ /opt/local/bin/bison --version > bison (GNU Bison) 3.7.5 If you don’t mind,

Dovecot Update Fails to Build in CI, Trace Mode

Re: https://github.com/macports/macports-ports/pull/10132 I’m trying to update dovecot. A vanilla `port install` works perfectly and produces perfectly working binaries. However, both CI and trace mode builds fail at the same point below. After the build errors out, I’m able to run the exact sa

Re: Very Large Number of Python ports Don't Exist in ${python.default_version } (py39)

As a user, I’d much rather report a rare package that doesn’t work than the current situation in which hundreds or more of dependencies are unavailable in MacPorts and I have to go through the process of updating Portfiles by hand or managing the pip installs. A major reason that many Python p

Re: Very Large Number of Python ports Don't Exist in ${python.default_version } (py39)

The approach of other Python package managers (conda, pip) is to simply use whatever the installed version is and presume that the package will build and work. If it doesn’t, post an issue. Currently, keeping MacPorts Python ports up-to-date requires hand editing every single Portfile, committi

Very Large Number of Python ports Don't Exist in ${python.default_version } (py39)

A very large number of Python ports don't exist in ${python.default_version} (py39). Is there an efficient way to include these in MacPorts without all those individual edits and commits? I expect that most/all of these will simply work with a 39 tacked on to python.versions. Here’s the ones

Re: Xcode error with cmake build of grpc

/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreFoundation.framework', > needed by `libgpr.14.0.0.dylib'. Stop. Is there a Portfile incantation that will fix this, or at least code around the issue? > On Jan 17, 2021, at 3:08

Re: Xcode error with cmake build of grpc

> Not sure why this build is insisting on trying to use the 10.15 SDK when it > does not exist. That is a bug that should be fixed. Is this an upstream grpc issue, a cmake issue, or a MacPorts issue? I’ll post the issue if I know where to post it. smime.p7s Description: S/MIME cryptographic sig

Xcode error with cmake build of grpc

I am unable to build grpc on a specific machine because of some Xcode error: > make[2]: *** No rule to make target > `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreFoundation.framework', > needed by `libgpr.14.0.

Re: Request Merge of Machine Learning Frameworks

com/macports/macports-ports/pull/7733> Apache-Arrow: https://github.com/macports/macports-ports/pull/7791 <https://github.com/macports/macports-ports/pull/7791> > On Oct 14, 2020, at 2:44 PM, Steven Smith wrote: > > I’ve posted several ML ports this year, believe that they’re

November Deadline for dovecot APNS Service, PR #8719

Apple’s legacy binary protocol is deprecated as of November 2020: https://developer.apple.com/news/?id=11042019a&1572897862 The PR https://github.com/macports/macports-ports/pull/8719 addresses the new protocol. Would someone please take a look at this PR and if possible merge before the 1 Nov

Request Merge of Machine Learning Frameworks

I’ve posted several ML ports this year, believe that they’re ready to be merged, and hope that they can be soon. These are holding up adding other ML frameworks that use these as dependencies. I’d appreciate any help getting these into the main branch for general use. Apache-Arrow: https://gith

Re: Supporting installing arbitrary port versions

This is a Terrible Idea. The first rule of computer security is to update your stuff. Adding the complexity of allowing arbitrary software versions means that now we have to make sure that we update our stuff and make sure that we’re not still running old, insecure code even after we’ve updated

ghc link dyld error: initializer in image does not link with libSystem.dylib

We’re trying to upgrade the ghc port to compile and link with MacPorts’s libiconv (at long last). The good news is that there are configure directives for this that work! The bad news is that their inclusion creates another link error: > dyld: initializer in image (/usr/lib/libc++.1.dylib) that

  1   2   >