Re: FileZilla: current version requires SDK 11

Sorry for the long delay, busy times had me loose this topic out of sight a bit. > Would it help if we had a port in MacPorts that installed the macOS 11 SDK? I'm not sure about that, since I have XCode 12.4 (which afaik includes the latest SDK) installed on Catalina 10.15.7: > $ ls -l /Library

Re: the whole world is renaming the git default branch to main...

Why? > Am 14.03.2021 um 18:40 schrieb Ken Cunningham > : > > I suggest we should do that too. > > Ken

FileZilla: current version requires SDK 11

The latest version of FileZilla fails to build on my Catalina system and the developer states, it requires the latest BigSur SDK to compile (though the final binary should be running on macOS 10.11 and newer): → https://trac.filezilla-project.org/ticket/12358 If I understand that correc

Re: port "cask" -- installing prebuilt binaries

> Am 03.10.2020 um 03:00 schrieb Ryan Schmidt : > > Lothar, I agree with most of your reasoning for why a variant is a reasonable > choice for indicating a prebuilt binary. I am less concerned with how to > indicate prebuilt status than I am with whether we should do it at all. Interesting, b

Re: port "cask" -- installing prebuilt binaries

Ryan, > Am 03.10.2020 um 03:00 schrieb Ryan Schmidt : > >> Just MacPorts did not implement it yet and when the necessity arose a >> seemingly simple workaround was chosen instead of solving the underlying >> problem. > > As for MacPorts, it's not that we haven't implemented it because we're la

Re: port "cask" -- installing prebuilt binaries

> Am 02.10.2020 um 17:02 schrieb Ken Cunningham > : > > 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. Ken, it's not "people", it's just me who provided a

Re: Thoughts on switching our archive compression method

Reading "xz" and "archive" in the same sentence reminds me of https://www.nongnu.org/lzip/xz_inadequate.html While it's easy to read the above as a rant of a disappointed competitor, he seems to make some valid points about why lzma/xz should be

Re: port "cask" -- installing prebuilt binaries

> Am 15.08.2020 um 10:37 schrieb Lothar Haeger : > >> The variant name is: +prebuilt > > I like that name for its conciseness, lack of an underscore and correct > tense. :-) So here's an example how this could look like in real life: https://github.com/macport

Re: port "cask" -- installing prebuilt binaries

> Am 15.08.2020 um 09:47 schrieb Eric F (iEFdev) : > > Doesn't the port `ghc` do exactly this? > https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile#L31-L33 > > Yes, looks like it does. Thr

Re: port "cask" -- installing prebuilt binaries

> 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 +prebuild_binary

Re: port "cask" -- installing prebuilt binaries

> Am 07.08.2020 um 01:13 schrieb Ken Cunningham > : > An example: let’s take the port MacVIM, which is ripe for this treatment. > > We can build and install the current macvim on some newer systems - let’s say > 10.12 to current. > > port -v install macvim gets you that. > > We will all kno

Re: port "cask" -- installing prebuilt binaries

> Am 05.08.2020 um 15:11 schrieb Ken Cunningham > : > > the indicator should not be a variant. Variant indicates an option to install > one way or the other, and a given port on a given system will not have such > an option. Well, it's just a suggestion, here's another one: I suggested a port

Re: port "cask" -- installing prebuilt binaries

> Am 05.08.2020 um 14:52 schrieb Georges Martin : > > If MacPorts starts to mix both approaches, I worry we may end up having (open > source) packages depending on closed source, binary packages. And have less > control on ensuring a consistent, compatible distribution. That's already the cas

Re: port "cask" -- installing prebuilt binaries

> Am 05.08.2020 um 14:28 schrieb Ken Cunningham > : > > I wasn't imagining a variant for binary-only installs. That's just an idea on how this could be presented to users. Also an easy way to identify ports that are basically binary redistribution (`port list variant:prebuilt`). Also would

Re: port "cask" -- installing prebuilt binaries

> Am 04.08.2020 um 19:52 schrieb Ruben Di Battista : > > So my take here is to not provide pre-built binaries packages if not strictly > unavoidable, like for the osxfuse project (since it was open source before). I think we all agree that building from source is preferred, so nothing should

Re: port "cask" -- installing prebuilt binaries

> Am 30.07.2020 um 08:03 schrieb Ken Cunningham > : > I only raise the idea as people are already doing this, and submitting such > ports, and before we have too many, there is an opportunity to say how it > should best be done (custom category, naming convention, etc). Reminds me of an earlie

Re: Best practices for port testing environment?

A separate macOS install in Parallels or Fusion would be another option, I guess. > Am 27.06.2020 um 16:31 schrieb Joshua Root : > > On 2020-6-28 00:23 , David Richmond wrote: >> New here to hacking on MacPorts; please talk to me like I'm dumb. Can >> anyone point me to a resource (or offer the