Re: port "cask" -- installing prebuilt binaries

n see the list of binary ports in a > clean way when browsing ports in the MacPorts website, it makes it easier to > do things like add an icon to signify binary only if a given port is in the > "binary" category, and not make possibly mistaken assumptions off of the name. > &

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 2:34 PM, Herby G wrote: > > > If we decide to go ahead with this, and if we decide to primarily use a > > category to mark these, we will need a plan for how to manage a name > > collision conflict when there are two ports that install the same software, > > one by buil

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 4:13 PM, Ken Cunningham > wrote: > > We need a new name. No trickery with categories is acceptable here. Picture the ticket: hello, user. Uhm before I can help you, does port list echo categories:binary and installed | grep macvim say “binary” ? No —wa

Re: port "cask" -- installing prebuilt binaries

yes, it's variant names that can't have + and - in them. Momentarily crossed that wire. K > On Aug 7, 2020, at 00:01, Ryan Schmidt wrote: > > > >> On Aug 6, 2020, at 09:10, Ken Cunningham wrote: >> >> So a port that installs the Zoom teleconf

Re: port "cask" -- installing prebuilt binaries

A few more issues: Handling supported_archs in binary-only ports. What if binary comes only as a universal binary, but the user asks for only one arch? We want that one binary to satisfy all the situations it can. Handling universal requests. What if user asks for universal? If binary comes wi

Re: port "cask" -- installing prebuilt binaries

On 2020-08-07, at 12:10 AM, Ryan Schmidt wrote: > > > On Aug 6, 2020, at 21:20, Ruben Di Battista wrote: > >> If they've been built somewhere by the upstream developer, shouldn't we be >> able to build them too and hence instead of providing them as binaries we >> would fix the ports in or

Re: port "cask" -- installing prebuilt binaries

nope, variant is just wrong in all ways. K

port example that extracts pkg

I'm working on something that comes as a 50MB pkg installer that installs into /usr/local. I'd like to extract all the files from the pkg and destroot them properly instead. Anyone know of a good example of an existing port that does something like this nicely? Thanks, Ken

Re: port example that extracts pkg

there are actually not too many examples in the ports tree of this: fuse/osxfuse/Portfile security/1password-cli/Portfile and perhaps science/SDRplay/Portfile science/SDRplay3/Portfile osxfuse seems to be doing it well, and I'll use that one for an example, for any others that come along with

update to icu has again broken all the macports-clang compilers

not exactly sure how I'm going to get around this just yet have to find some compiler that still works somewhere -- gcc? to rebuild libxmls2 and then again rebuild libxml2 +universal once some clang works again... configure:3623: $? = 1 configure:3643: checking whether the C compiler works conf

Re: update to icu has again broken all the macports-clang compilers

On 2020-08-12, at 7:37 AM, Ken Cunningham wrote: > not exactly sure how I'm going to get around this just yet > > have to find some compiler that still works somewhere -- gcc? to rebuild > libxmls2 and then again rebuild libxml2 +universal once some clang works > again...

Re: update to icu has again broken all the macports-clang compilers

the macports-clang compilers actually have no need for macports' libxml2 I believe, the libxml2 provided by the system is sufficient, and libxml2 itself is optionally used by one tiny component that is not relevant to a bootstrap compiler... I have disabled libxml2 in various llvm-related ports

Re: update to icu has again broken all the macports-clang compilers

On 2020-08-12, at 7:55 AM, Joshua Root wrote: > On 2020-8-13 00:37 , Ken Cunningham wrote: >> not exactly sure how I'm going to get around this just yet >> >> have to find some compiler that still works somewhere -- gcc? to rebuild >> libxmls2 and then again

Re: port "cask" -- installing prebuilt binaries

consider: $ port variants macvim Warning: port definitions are more than two weeks old, consider updating them by running 'port selfupdate'. MacVim has the variants:    big: Build big feature set * conflicts with huge    cscope: Enable source code browsing with cscope [+]huge: Build huge f

Re: port "cask" -- installing prebuilt binaries

I mean, you can maybe describe the “feature set” of the prebuilt binary in the variant description and forbid all the other variants… Can’t you? No doubt, with sufficient effort, we could take something inherently simple and make a complicated and undecipherable version of it. PS: Maybe “pr

Re: port "cask" -- installing prebuilt binaries

On 2020-08-14 11:48 p.m., Lothar Haeger wrote: Am 15.08.2020 um 01:11 schrieb Ken Cunningham : so -- what would a user typing Obviously that variant would conflict with all other variants, much like +ruby21 conflicts with +ruby22. So the user would type sudo port -v install macvim

Re: port "cask" -- installing prebuilt binaries

Doesn't the port `ghc` do exactly this? https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile#L31-L33 The variant name is: +prebuilt throwaway bootstrap compiler only, totally different issue

port release candidate versioning question

This sounds like a dumb question, that I should already know the answer to, but apparently I don’t seem to: I would like to make sure this works the way I think it works before I do it. When I make a new port clang-11 with version 11-rc1 and then follow-up with versions 11-rc2, 11-rc3, etc and

Re: port release candidate versioning question

thanks to all for the helpful responses. I will try to get it right off the mark. K > On Aug 17, 2020, at 12:40, Ryan Schmidt wrote: > > > >> On Aug 17, 2020, at 13:39, Arno Hautala wrote: >> >>> On 17 Aug 2020, at 14:35, Arno Hautala wrote: >>> >>> To verify this, and to test other cases,

FYI -- Parallels 16 now supports BigSur as a VM on older systems

Like Catalina, Parallels will install BigSur as a VM even on older systems. https://kb.parallels.com/en/125105 for those of you who might have parallels but no current system to run BigSur Ken

Re: FYI -- Parallels 16 now supports BigSur as a VM on older systems

ah, apologies — after a while, the installation in the end failed, I’m afraid. I was a bit too trusting of the literature and initial installation steps. Ken > On Aug 20, 2020, at 9:33 PM, Ken Cunningham > wrote: > > Like Catalina, Parallels will install BigSur as a VM e

supertuxkart non-redistributable?

Just curious what makes this port non-redistributable…. it’s likely a pain for users to have to build it. Ken

Re: supertuxkart non-redistributable?

> On 8/24/20 7:30 PM, Ken Cunningham wrote: > > Just curious what makes this port non-redistributable…. > > > > it’s likely a pain for users to have to build it. > > > > Ken > > > A quick check shows: > > > "supertuxkart" is not dist

Re: supertuxkart non-redistributable?

> On Aug 24, 2020, at 7:13 PM, Joshua Root wrote: > > > Doesn't supertuxkart itself depend on curl? > > - Josh Oh, yes, of course you are right. It does. Is that what makes it non-distributable? Even though it doesn’t link against openssl? Ken

Re: supertuxkart non-redistributable?

> On Aug 25, 2020, at 4:09 AM, Joshua Root wrote: > > On 2020-8-25 19:42 , Eric F (iEFdev) wrote: >> Fedora, who usually are very restricted about things, have this take: >> >>> “ However, we consider that the OpenSSL library is a system library, >> as defined by the GPL, *on Fedora* and there

Re: supertuxkart non-redistributable?

Wikipedia got the libressl license totally wrong then, which I have not found is not usually the case: Apache License 1.0, 4-clause BSD License, ISC License, and some are public domain anyway, we're stuck for so many ports due

Re: Need help with troubleshooting Blender PR

Most ports that try to figure out the SDKROOT on their own don't do it right, so you should always force the port to use MacPorts ${configure.sdkroot} if there is a configure option to do so. There is an idiosyncrasy in MacPorts base wherein if the SDKROOT is "/" then MacPorts base leaves ${con

Re: Need help with troubleshooting Blender PR

On 2020-08-29, at 1:42 AM, Ryan Schmidt wrote: > > Is there a ticket about this? This is the ticket > > The place to fix it would be in src/port1.0/portconfigure.tcl in proc > portconfigure::configure_get_sdkroot, changing some or possibly all "retu

mariadb upstream is asking for some help to fix their macOS CI build which is failing

Hello, After fixing a build issue with mariadb, and hearing we have mariadb building on 10.7 to 10.15, the mariadb team are asking for some help getting their CI build on macOS working again. They are stuck, and worried about macOS support with no CI build working. Looks like a couple of diffe

promote older systems support

there is considerable grousing on the homebrew forums about their ruthless policy for dropping support for systems more or less right after apple does, and some of those forum posts about this topic have many thousands of views. as you folks have put such effort into older systems support over t

where to find darwintest.h and the rest of the Apple darwin testing infrastructure?

I’m trying to upgrade the testing for legacy-support, and I thought I might try to bring in some of Apple’s existing testing files, eg > for the new futimens and

Re: Factors determining binary archivability --> OpenSSL 3.0 is coming along with a new license

OpenSSL 3.0 has a new, more compatible license. It is coming along. Alpha5 released July 16. https://www.mail-archive.com/openssl-users@openssl.org/msg88452.html

if we are going to support universal arm/x86_64 ports, we'll likely need a multi-architecture gcc again

I’m not sure if the MacPorts plan is to support universal arm/x86_64 builds, but I can imagine that for some years we might want to consider doing that. The last gcc version we had that supported multiarchitecture building was apple-gcc42 (Intel, PPC). We might have built a suitable newer cross

Re: Apple ARM binary codesign issue

On 2020-09-22, at 11:58 AM, Ryan Schmidt wrote: > > I hope that Apple fixes their toolchain to work without such intervention. > I believe this may ultimately come under the category of "intended behaviour". I can understand why they would want these changes to invalidate the signature. I su

Re: Apple ARM binary codesign issue

On 2020-09-22, at 12:58 PM, Ryan Schmidt wrote: > > To me it seems unrealistic for Apple to suggest that an infinite number of > open source projects, many of whose developers have never seen a Mac, should > now add code to their build systems to codesign things on macOS. Apple made a > point

Re: Apple ARM binary codesign issue

Would it not be easier to add that codesign line in the existing script that the cctools port writes to wrap those tools for the +xcode variant of cctools, perhaps? (well, NB cctools is not presently wrapping install_name_tool for the +xcode variant, but that looks like an oversight trivially f

Re: Apple ARM binary codesign issue

> On Sep 25, 2020, at 7:55 AM, Michael Dickens wrote: > > Also: many build scripts call /usr/bin/strip directly or xcrun strip ... so > that would bypass our MP efforts ... we'd have to patch up all of those ports > to coerce them into running the MP strip ... that seems like a lot of work!

Re: port "cask" -- installing prebuilt binaries

So this issue seems still active, but without a decided plan here, people are just starting to PR their favourite approach, which is of course exactly what we are tring to avoid. The idea of identifying them by a variant suffers from the fact that these are obviously not variants, they are imm

Re: port "cask" -- installing prebuilt binaries

> On Oct 2, 2020, at 8:02 AM, Ken Cunningham > wrote: > > Chris says put them in a category. Logical, but I don't know if most users > would note that when trying to install them, as it is not perhaps obvious > enough these are different beasts. Also, it it is decid

Re: port "cask" -- installing prebuilt binaries

Ok. So contenders for the metadata identifying non-buildable binary-only ports we have: name suffix (like the hs- ports had) category only variant as identifier We have spent far too long on this nonsense. Some admin pick one, then lets move on. K

Re: How to abort a macports portfile on an error condition?

Martin, I'm trying to understand how this is happening to you. you should not need to be doing that in your Portfile, and users should never need to make that symlink. The linuxdoc-tools port has this: depends_build bin:latex:texlive \ path:bin/perl:perl5 But it seems that y

Re: How to abort a macports portfile on an error condition?

hey, thanks Ryan for taking care of this little detail. K On 2020-10-03, at 11:48 AM, Ken Cunningham wrote: > Martin, I'm trying to understand how this is happening to you. > > you should not need to be doing that in your Portfile, and users should never > need to

Re: Hardcoding Xcode.app

and if we're coding this in somewhere to get all systems, it's this: xcode-select -print-path I already fixed that particular thing in base once, so somewhere in base this is already being called... Ken On 2020-10-09, at 1:14 PM, Andrew Janke wrote: > Just one data point here, but as a some

Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'

We’d need: 1. the ability to install and keep a toolchain on the buildbot in some fashion I’m very in favour of this, if possible, but I can see that it is not trivial to implement — I think all the OS versions < about 10.12 should use clang-9.0 to build everything, and save us all a lot of tro

Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'

> On Oct 15, 2020, at 9:32 PM, Ken Cunningham > wrote: > > 2. an “openmp” PortGroup that all ports that want openmp could subscribe to, > that forces an openmp setup that works for various systems. > > Not overly hard, I think. or maybe the compiler.openmp settin

Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'

> It's correct that I would rather people didn't blacklist compilers that are > capable of building a port. It wastes user and buildbot time and wears out > the buildbot SSDs unnecessarily. Half (more?) of the tickets on MP are from trying to build port X with ancient xcode clang Y. When those

Re: New py-cryptography and old macOS versions

> How to properly handle a case when a new version explicitly drops support for > older macOS? I suggest don't change anything, and see how MacPorts' enhanced build systems, legacysupport, etc, handle it first... K

Re: OpenMP on MacOS Clang

Is this report saying that Xcode clangs will use openmp now with the -Xclang -fopenmp flags added? That would be very interesting news, if so, I think. If that is true, do we know what version of Xcode clang can use openmp? The open-source (macports) clangs have accepted -fopenmp for some years

does libhttpseverywhere have to have a 7MB uncompressed file of rules in the files dir?

The ports tree is getting bloaty as it is, but is is fairly egregious bloat… ls -la total 13680 drwxr-xr-x 5 root wheel 160 22 Oct 18:46 . drwxr-xr-x 4 root wheel 128 23 Aug 15:39 .. -rw-r--r-- 1 root wheel 6992700 23 Aug 15:39 default.rulesets -rw-r--r-- 1 root wheel 664 2

Re: does libhttpseverywhere have to have a 7MB uncompressed file of rules in the files dir?

The file is here, it seems: https://gitlab.gnome.org/GNOME/libhttpseverywhere/-/blob/master/data/default.rulesets

Re: does libhttpseverywhere have to have a 7MB uncompressed file of rules in the files dir?

as far as I can see, the one from the website and the one in the ports tree are identical: $ ls -la /Users/Shared/Downloads/default.rulesets.1 ./www/libhttpseverywhere/files/default.rulesets -rw-r--r-- 1 root admin 6992700 20 Jul 12:11 ./www/libhttpseverywhere/files/default.rulesets -rw-

Re: does libhttpseverywhere have to have a 7MB uncompressed file of rules in the files dir?

.org/GNOME/libhttpseverywhere/-/blob/9c43785fe5ce13c70b8a1abfece834d12fc9d0fb/data/default.rulesets >> <https://gitlab.gnome.org/GNOME/libhttpseverywhere/-/blob/9c43785fe5ce13c70b8a1abfece834d12fc9d0fb/data/default.rulesets> >> >>> On 23 Oct 2020, at 7:22 pm, Ken Cunningham >>> wrote: >>> >>> The file is here, it seems: >>> >>> https://gitlab.gnome.org/GNOME/libhttpseverywhere/-/blob/master/data/default.rulesets >>> >>> >>> >

how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

It's easy to prepend or append to PATH in a Portfile, but I'm having difficulty seeing how to modify, rather than overwrite, DYLD_LIBRARY_PATH. Usually you just want to set it, but now that it might or might not be set in legacysupport 1.1, I was hoping to just modify rather than overwrite it.

Re: how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

> On Oct 24, 2020, at 8:52 AM, Joshua Root wrote: > > On 2020-10-25 02:18 , Ken Cunningham wrote: >> It's easy to prepend or append to PATH in a Portfile, but I'm having >> difficulty seeing how to modify, rather than overwrite, DYLD_LIBRARY_PATH. >> &g

Re: how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

> On Oct 24, 2020, at 9:46 AM, Ken Cunningham > wrote: > > configure.env-append"DYLD_LIBRARY_PATH=${prefix}/lib/lilbgcc" > configure.env-append“DYLD_LIBRARY_PATH=${workpath}/build” > > but I found the second one just obliterates the first on

Re: how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

> On Oct 24, 2020, at 9:50 AM, Ken Cunningham > wrote: > > > >> On Oct 24, 2020, at 9:46 AM, Ken Cunningham > <mailto:ken.cunningham.web...@gmail.com>> wrote: >> >> configure.env-append"DYLD_LIBRARY_PATH=${prefix}/lib/lilbgcc&

Re: how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

> On Oct 24, 2020, at 3:36 PM, Ryan Schmidt wrote: > > > > On Oct 24, 2020, at 11:46, Ken Cunningham wrote: > >> So instead of this method, I will look into running lsearch on *.env, and >> see if I can sort out how to add some entries if something is alre

Re: how to prepend or append to DYLD_LIBRARY_PATH in Portfile?

> On Oct 24, 2020, at 19:51, Ken Cunningham wrote: > > > On Oct 24, 2020, at 3:36 PM, Ryan Schmidt wrote: > > > >> On Oct 24, 2020, at 11:46, Ken Cunningham wrote: > >> > >>> So instead of this method, I will look into running lsearch on *.env,

port diagnose on new catalina install says Xcode 12.1 not supported

new install on a catalina system, then run port selfupdate, and then port diagnose: % sudo port -v diagnose Error: currently installed version of Xcode, 12.1, is not supported by MacPorts. For your currently installed system, only the following versions of Xcode are supported: 11.6 11.5

Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

you're timing out downloading perl modules... try downloading a few manually to see what's going on, perhaps K

Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

> Running ’sudo port fetch p5.28-locale-gettext’ also crashes my machine. By manually, I meant using curl or something other than MacPorts to download it, so you can see perhaps where it is going wrong. K

Re: FYI -- Parallels 16 now supports BigSur as a VM on older systems

> h, apologies — after a while, the installation in the end failed, I’m afraid. > I was a bit too trusting of the literature and initial installation steps. > > Ken > > > > > > On Aug 20, 2020, at 9:33 PM, Ken Cunningham > gmail.com <https://lists.macpor

homebrew moving to /opt/homebrew

As of Apple silicon, apparently. https://github.com/Homebrew/brew/issues/7857 Being in /usr/local was always said to be homebrew's biggest, no-sudo advantage... So those of you who said previously that they would eventually figure out they would have to move to /opt look to have been right on

Re: homebrew moving to /opt/homebrew

On 2020-11-18 7:12 a.m., Ken Cunningham wrote: As of Apple silicon, apparently. https://github.com/Homebrew/brew/issues/7857 <https://github.com/Homebrew/brew/issues/7857#issuecomment-727561968> Being in /usr/local was always said to be homebrew's biggest, no-sudo advantage...

Re: Force Xcode SDK instead of CLI SDK?

The SDK in the Xcode.app and the SDK in the CLTs for MacOSX11.0.sdk are essentially identical (I just diff -ur'd them), so it doesn’t appear that the extra tools are in the SDK exactly. So from that point of view, the 10.15 SDK in the CLTs might still be used if there is a good reason to do so

Re: install_name_tool problem with symlinks on Xcode 12.2

> install_name_tool in Xcode 12.2 -- the version we are using for Big Sur -- > has a bug that could affect ports. The source code for the Xcode 12.2 version is not yet up on the Apple Open Source website. The last version up there is Xcode 11.3.1 (cctools-949).

llvm/clang/lldb -devel on Apple Silicon

So the latest build of llvm etc did build through and install on Apple Silicon That is a milestone of sorts I think. This allows openmp, and the first alternative compiler to try for failed builds. I’ll move this into llvm/clang 11 soon, once I finish wrestling with the github PG. Best, Ken

Re: llvm/clang/lldb -devel on Apple Silicon

sadly, today, flang is pretty much useless for us. It can only process source and send it off to another fortran compiler ( a commercial one from the company that donated flang to the community) to be compiled. But obviously that will disappear in due course, and flang will work independently

fixing curl fetches on older MacPorts versions by using MacPorts' self-installed version of curl

MacPorts on older systems has fetch issues due primarily to an old system curl & ssl infrastructure. There is a long-open-unlikely-to-ever-fix ticket where we (more or less) have decided not to bundle curl/openssl with MacPorts, for various reasons. I think it’s fair to say that if we were going

Re: fixing curl fetches on older MacPorts versions by using MacPorts' self-installed version of curl

> On Nov 25, 2020, at 11:19 AM, Joshua Root wrote: > > On 2020-11-26 06:08 , Ken Cunningham wrote: >> <https://github.com/macports/macports-base/blob/938d8528b896f15dc10c21a208b795f78acac127/src/port1.0/portfetch.tcl#L565> >> >> where fetch just calls “cu

Re: fixing curl fetches on older MacPorts versions by using MacPorts' self-installed version of curl

thanks for taking the time to outline that. I think that is likely the only method that will be officially sanctioned, and fair enough. Ken

change libcxx +emultated_tls to installing a binary please on < 10.7...

So — figuring out how to bootstrap libcxx to the +emulated_tls variant (which we increasingly need) is a real PITA. I might sort it out — building another libcxx in some tucked-away location, with a bunch of stuff needed to get to clang-5.0 linked against that one, and using that to build the r

Re: change libcxx +emultated_tls to installing a binary please on < 10.7...

another reasonably simple option would be to have a manual step, and copy what happens with apple-gcc42 +bootstrap. We make up a non-TLS variant of libcxx, call it libcxx +bootstrap, and default to installing that if there is nothing in /usr/lib/libc++.dylib. Then the port notes (like apple-gc

Re: change libcxx +emultated_tls to installing a binary please on < 10.7...

On 2020-12-01 10:01 a.m., Ryan Schmidt wrote: apple-gcc42's +bootstrap variant is not suitable for the buildbot either because of that manual step. Just so I understand the equipment -- is the buildbot system at all manually controllable? ie is it even technically possible to do this o

Re: Problem with libomp (was supertux)

> Attempting to install supertux complains on libomp. > > Logfile shows compiler complaints about atomic and variable templates. > I noticed that the recent update to libomp-11 failed on 10.8 and 10.9 (and 10.6 and less). This is not a big surprise — more likely a miracle that libomp up to 10.0

Re: Problem with libomp (was supertux)

OS 10.9 and older to the last > version that builds there, version 10.x. Probably a bit simpler than having > to deal with multiple libomp-X ports... > > Chris > >>> On 5 Dec 2020, at 5:57 am, Ken Cunningham >>> wrote: >>> >>>  >>> At

Re: Problem with libomp (was supertux)

(leave as a separate port, pinned to older > versions on older systems, or build it as part of each clang independently), > but I think removing it as something that comes along with MP’s clang would > be a mistake. > > Thanks, > - Eric > > On Sat, Dec

Re: Problem with libomp (was supertux)

> On Dec 5, 2020, at 10:18 AM, Christopher Jones > wrote: > > Hi, > >> On 5 Dec 2020, at 5:20 pm, Eric Borisch > > wrote: >> >> It's part of the LLVM project, and can be built at the same time >> (-DLLVM_ENABLE_PROJECTS=openmp)as other tools; I think losing Ope

Re: Problem with libomp (was supertux)

> On Dec 5, 2020, at 11:21 AM, Eric Borisch wrote: > > We could: > > * leave the current patch applied to clang-* (to teach clang where to get > the library if it is installed) > * make clang-* no longer depend upon libomp > * Add a post-install note of "to enable OpenMP support, install

cmake 3.19 has two possibly important changes

https://cmake.org/cmake/help/latest/release/3.19.html#deprecated-and-removed-features 1. SDK search algorithm change: it will by default now find the newest SDK rather than prefer the system or deployment-target-matching SDK as it previously did. The probably doesn’t affect many ports for us, a

Re: FYI -- Parallels 16 now supports BigSur as a VM on older systems

All my System Software came from CD’s, DVDs, and machines I own, but I presume some of you know about the munki project and have seen this . I have seen other similar scripts that do the same downloading from Apple here

qt6 is out, and now it looks like we need a plan ....

I installed qt6 this morning on my 2006 MacBook 2,1 running Ubuntu 20.10. So that is out. On macOS it builds on 10.15+, and deploys to 10.14+. qt6 so far appears to me to be a continuation of the qt5.x line, not a totally incompatible jump like qt4 -> qt5 was I think, although I have to explore

Re: pkg-config sometimes strips -I/opt/local/include from its output

> There is another variable PKG_CONFIG_ALLOW_SYSTEM_CFLAGS which prevents > the affected paths from being removed from the output. Might as well mention there is another similar one PKG_CONFIG_ALLOW_SYSTEM_LIBS: Don't strip -L/usr/lib out of libs; I was looking into this when Michael was havin

Re: port "cask" -- installing prebuilt binaries

So, I'm looking to install iTerm2 for old systems from binary as building is becoming increasingly impossible - have we come to a consensus on any of this? —Mark ___ Mark E. Anderson https://lists.macports.org/mailman/listinfo/macports-dev>> MacPorts Trac WikiPage

script to revbump all the deps of a port?

octave has like 117 deps does anyone have a script that will do this? I have just done it by hand before, but that’s too much gruntwork if there’s an easier way. thx ken

Re: Swift Package Manager

we are not likely to win this...we accept the package manager when it cones to ghc/stack, and doing this has added a formidable amount of complication to the go ports that is daunting for contributors and maintainers... Perhaps we just forget about doing this with ghc /go / swift and friends? I

what say we just use MacOSX.sdk preferentially on BigSur and up?

That will save a lot of heartburn with all the gcc ports, python, perl, and all the others that bake in a path to the SDK. And it's how Apple is going now anyway. And helps ports build when they need a newer SDK than the versioned one that matches their system. This was undesirable in the 10.4

Re: port "cask" -- installing prebuilt binaries

I've been building a few of these "cask" installers for my own use. I'm finding using the normal port activate/deactivate process quite inefficient for this... For example, SageMath is a 1.5GB dmg, and is about 4GB installed. Downloading the dmg, decompressing it and copying the contents into d

Re: port "cask" -- installing prebuilt binaries

> On Dec 24, 2020, at 10:58 AM, Jason Liu wrote: > > A more efficient method that overrides activate/deactivate and does not > needlessly de&re&decompress everything would seem useful. > > Since the dmg itself is a compressed archive, it would seem to make sense > that activate/deactivate w

cctools xcode variant conflicts with universal -- why?

We will want to be able to use the cctools +xcode variant of cctools when building universal with x86_64 & arm64 it would seem. The xcode variant is just a wrapper script that calls the cctools tool in Xcode; it was marked as conflicting with the universal variant in 2018. I’m trying to underst

Re: port "cask" -- installing prebuilt binaries

Another prime example for a cask port, but showing yet different issues, looks to be osxfuse. osxfuse is required for a number of other ports, but the current osxfuse port is three years out of date because it’s no long open source, and users need to use the upstream installer. For this one, w

Re: what say we just use MacOSX.sdk preferentially on BigSur and up?

So I will make another push for this, before we get hundreds of ports built with incorrect burned-in SDKs that make a total mess for us to manage. What is different now is that almost all current configure software does a test-compile and run rather than look for a specific header or function t

Re: what say we just use MacOSX.sdk preferentially on BigSur and up?

the latest: https://trac.macports.org/ticket/61953 It’s to be also noted that all the availability tests that are now build into the current SDK are designed to make sure that you’re going to be able to run on your requested DEPLOYMENT_TARGET So even if the build system flubs it, the SDK will

Re: what say we just use MacOSX.sdk preferentially on BigSur and up?

> On Dec 31, 2020, at 1:51 PM, Ryan Schmidt wrote: > > On Dec 31, 2020, at 10:56, Ken Cunningham wrote: > >> So I will make another push for this, before we get hundreds of ports built >> with incorrect burned-in SDKs that make a total mess for us to manage. >>

Re: what say we just use MacOSX.sdk preferentially on BigSur and up?

Happy New Year to all! > On Dec 31, 2020, at 2:10 PM, Ryan Schmidt wrote: > > We want to avoid ports installing files that contain the specific SDK path. > Some ports do so only for information so it doesn't matter. Others might use > those values later to build other software, like maybe pyt

Pallet LIVES!

Pallet LIVES!!!

Re: Pallet LIVES!

> On Jan 6, 2021, at 6:02 PM, Ken Cunningham > wrote: > > Pallet LIVES!!! > > <https://github.com/macports/pallet/pull/1#issuecomment-755834338> I cleaned up the commits a bit, and put it here for now: <https://github.com/kencu/pallet/tree/ken_10_7_build <h

Re: Qt and Apple Silicon

> My MythTV ports depend heavily on Qt but I’m not up to speed on that > project’s plans wrt the new Apple-silicon (ASi) Macs. AIUI, our current Qt5 > port is X86_64 only. Is or will Qt5 be compatible with ASi? Do we need to > port Qt6 to become compatible? Any rough timetable? > > If I’ve

pdftk

Based on yet another complaint I fixed pdftk and made it nomaintainer; it's been broken for more than a year, and Ryan indicated his disinterest here . I just went ahead as it was dead for such a long while, but by all means, please switch it ba

Re: Xcode error with cmake build of grpc

> This kind of problem is the reason why I keep our Buildbot machines on a > version of Xcode and command line tools that contains the SDK version > matching the OS version. The downside is all the newer software that should but won’t build on that system, and the fact that almost 100% of users

<    1   2   3   4   5   6   7   8   >