Call for testing: port migrate

A 'migrate' action has been added to MacPorts base in git on the master branch. If you are comfortable with checking out the git repo, installing MacPorts from source, running potentially buggy pre-release code, and reporting any issues, we would greatly appreciate you giving it a try. The

Re: propka/pdb2pqr

On 4/6/2024 23:43, Jack Howarth wrote: I am lost at sea about how to handle the newer pdb2pqr packaging. The ancient 2.1.1 pdb2pqr sources built a c-based propka as part of the pdb2pqr process. Upstream replaced this with propka entirely rewritten in python and as its own project. I believe

Re: There should be a requirement to check if a port exists before committing something right into the master

I remembered I wrote a script years ago to detect this very situation. Attaching in case it's of use to anyone. There are currently no other duplicate ports in macports-ports, BTW. :) - Josh On 1/6/2024 07:11, Joshua Root wrote: No, there's no guarantee that a PortIndex exists; you can run

Re: There should be a requirement to check if a port exists before committing something right into the master

the port index to verify that one and only one port exists for the current port name? On Fri, May 31, 2024 at 8:35 AM Joshua Root <mailto:j...@macports.org>> wrote: On 31/5/2024 21:22, Sergio Had wrote: > Otherwise we get this: > https://github.com/macports

Re: There should be a requirement to check if a port exists before committing something right into the master

On 31/5/2024 21:22, Sergio Had wrote: Otherwise we get this: https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed While LimeChat has existed for 4 years in

Re: A question about a potential error in portconfigure::should_add_stdlib{} in the master branch

On 30/5/2024 06:46, René J.V. Bertin wrote: Hi, I'm rebasing my LinuxPorts adaptation of "base" to a few days old checkout of the master branch, and saw something in the portconfigure::should_add_stdlib{} procedure: ``` # GCC also supports -stdlib starting with GCC 10 (and devel), but

Re: Fix: My dovecot install fails after macOS Sonoma 14.5 update and MacPorts update

On 27/5/2024 02:04, Gerben Wierda wrote: Thank you. I had all kinds of other issues as well, so I was starting to wonder my MacPorts registry was corrupted E.g. clamav-server did not activate because an older /opt/local/etc/clamd.conf.macports.orig was still there. Or a just installed

Re: Help with Ticket #68015

On 27/4/2024 23:09, mcalh...@macports.org wrote: Perhaps not. I am not quite sure what constitutes a genuine stack overflow. However, after building the offending binary using the backtrace_on_stack_overflow crate, and I saw no evidence of of infinite recursion

Re: Help with Ticket #68015

On 27/4/2024 19:30, Marcus Calhoun-Lopez wrote: As part of its build process, Rust creates a program called `bootstrap`, which reports a stack overflow on 10.9 and 10.10 (see ticket #68015). What I cannot figure out is the following. If I take the `bootstrap` built on 10.8, then it works just

Re: how to handle 'internal' logs for failed builds

On 5/4/2024 01:39, Chris Jones wrote: So what is happening is the build internally packages its own versions of some externals, freetype being one of them, and its this that fails during configure for some reason. The problem is the contents of that log are, of course, not in the macports

Re: [macports/macports-ports] Update ImageMagick to 6.9.13-7 (PR #23307)

On 2/4/2024 01:11, Langer, Stephen A. (Fed) via macports-dev wrote: I got this message about rev bumping my port because of changes in its dependencies.  I'm relatively new to port maintenance and am not sure what I need to do here.    Do I just tweak the version number on my port so that it's

Re: XZ Utils Compromised Releases

A friendly reminder: if there's an issue, please file a ticket! The one exception to that is if there's a vulnerability that has not been made public, in which case contacting the port maintainer and possibly portmgr privately is appropriate. Discussing issues on the mailing lists,

Re: MacPorts vs. Apple compiler issues, Handle

On 20/3/2024 03:23, Riccardo Mottola wrote: Hi, Joshua Root wrote: And this is where it happened. Since this is not a full debug build, there is no line number information, but you at least know which method is doing the bad memory access. But it should be a debug build. Well a build

Re: MacPorts vs. Apple compiler issues, Handle

(Moving to macports-dev as it is a better fit for this topic.) On 18/3/2024 22:50, Riccardo Mottola wrote: I will do another compilation reducing the optimization level. GCC has an issue where beyond gcc6 certain optimizations need to be disabled, or AF crashes. Issues that only appear at

Re: CI are forcing tests for ports where tests are disabled

On 18/3/2024 09:35, Daniel J. Luke wrote: On Mar 12, 2024, at 12:20 PM, grey wrote: But, I am guessing, it's either not that simple, or at a minimum, I might need some additional insights into how to placate it. The test phase (like most other phases) doesn't run as root by default. When

Re: PRs for new ports that depend on new ports

On 29/2/2024 19:56, contextnerror wrote: I’m hoping to possibly submit a portfile for morshutalk that I got working the other day. This would require submitting additional new ports which are required as dependencies. What is the proper way to do this? Is it one PR per port, or a single PR

Re: CI are forcing tests for ports where tests are disabled

nevertheless and b) is not clearly a superior choice, since it becomes less clear if some optional dependencies are missing (which we may care about in specific cases). On Feb 29, 2024, at 2:17 PM, Joshua Root wrote: On 29/2/2024 17:01, Sergey Fedorov wrote: There is something broken with CI

Re: CI are forcing tests for ports where tests are disabled

On 29/2/2024 17:01, Sergey Fedorov wrote: There is something broken with CI now. Tests phase must not be run when it is disabled (test.run is set to no), but it is. Built-in tests can always be run. See 2.9 release notes. - Josh

Re: How to force run tests as non-root?

On 25/2/2024 03:07, Ken Cunningham wrote: Some of your macports installations are installed as the root user, instead of the macports user. This happened because there is no installer for 10.6-ppc to automatically create the macports user. You have an open ticket about this too, where I

Re: How to force run tests as non-root?

On 24/2/2024 17:27, Sergey Fedorov wrote: If Macports is running as root, but tests require non-root user, how to do that? There is no test.asroot no, apparently. All the usual ways you can run something as another user when you are root. You could prefix your build.cmd with 'sudo -u

Re: Automatic port replacement

On 19/2/2024 00:49, Karl-Michael Schindler wrote: I have a series of cross compilers which conflict with each other. Therefore, only one should be installed and installing one should replace the installed one with a Y/n question. How can I achieve this? This is my current snippet with

Re: Antlr: Rebuild on 12.x86_64

On 5/2/2024 16:10, Dave Allured - NOAA Affiliate via macports-dev wrote: Would someone with builder access please trigger a rebuild of antlr on the 12.x86_64 builder?  There seems to be a difference between builders and github CI, and I need to check a recent builder log file.  Thanks for your

Re: Testing a modified portgroup

On 5/2/2024 14:58, Austin Ziegler wrote: I think I have found a bug in the golang portgroup, and I think I have an idea on how to fix it, but I'm not sure how to test such a modification. You'd make the change in your local copy of the ports tree and check that a port affected by the bug now

Re: Lazarus package update

On 4/2/2024 09:40, Karl-Michael Schindler wrote: Hi. There is a new version of Lazarus, a major update from 2.2.6 to 3.0. What are the conditions, whether to update the current package from 2.2.6 to 3.0 vs creating an additional package, called lazarus3? If the new version breaks

Re: Difference between mpbb and local builds

On 3/2/2024 14:08, Link Dupont wrote: On Feb 2, 2024, at 19:04, Joshua Root wrote: __MAC_OS_X_VERSION_MAX_ALLOWED is from AvailabilityInternal.h, which as its name suggests is only intended to be used internally (by Availability.h). I’m not sure that’s the intention of the file

Re: Difference between mpbb and local builds

On 3/2/2024 08:09, Dave Allured - NOAA Affiliate via macports-dev wrote: Now this is odd.  Socket_vmnet is a package specifically intended for Mac OS, yet availability.h has been hard coded as all lowercase in the source code for more than two years.  Are there two versions,

Re: Difference between mpbb and local builds

On 3/2/2024 07:54, Link Dupont via macports-dev wrote: I suppose the solution here is to patch it in the Port to inlclude “Availability.h” instead? As per its comments, Availability.h is for the use of OS headers to declare what is available. Programs wanting to check what is available

Re: TCL 9.0?

On 30/1/2024 01:18, Mark Anderson wrote: Woah, never thought I'd see it: https://www.tcl.tk/software/tcltk/9.0.html I wonder how big an impact it will be? Since we ship out own, not rush (It's also still beta) but interesting nonetheless. The

Re: mailing list "dev" vs "user"

On 25/1/2024 20:54, Riccardo Mottola via macports-dev wrote: Questions about bugs (e.g. discussions similar to track) belong to which list best? Is "dev" only for "macports" itself or also for the ports in it? I thought the former, then I checked the archives casually and noticed there is lot

Re: Question on architechture

If the universal variant doesn't work in one or more of the dependencies, disable it with 'universal_variant no'. Doing that for even one of them will make it so that, if supported_archs is also set correctly, you get an error during dependency calculation. - Josh On 24/1/2024 12:48, Mark

MacPorts 2.9.0-rc2 now available for testing

Source code and pkgs for MacPorts 2.9.0-rc2 are now available [1]. Testing of either of these install methods is helpful. Be prepared to encounter bugs. As always, having a recent backup would be wise. Please report any bugs that you find [2] (after first searching Trac [3], of course!) If no

Re: pre-built quartz variant packages

On 17/1/2024 05:42, Valerio Messina via macports-dev wrote: Using the pre-built gtk3 from macport (and osxcross), saved me the library built time just for test of my apps, and the requirement to access macOS on every run. Then I discovered to start the app I had to install Xquartz on the real

MacPorts 2.9.0-rc1 now available for testing

Source code and pkgs for MacPorts 2.9.0-rc1 are now available [1]. Testing of either of these install methods is helpful. Be prepared to encounter bugs. As always, having a recent backup would be wise. Please report any bugs that you find [2] (after first searching Trac [3], of course!) If no

Re: Builder request, h5fortran on Sonoma x86

On 14/1/2024 12:04, Dave Allured - NOAA Affiliate via macports-dev wrote: Would someone please push through a rebuild of h5fortran on Sonoma x86, such that the status page is correctly updated?  I think this bad build: https://ports.macports.org/port/h5fortran/builds/

Re: Support for ancient machines and operating systems

On 9/1/2024 01:53, Kirill A. Korinsky wrote: How do you see the way to backport changes from upstream MacPorts to legacy MacPorts? at some point automatical merge would be broken on conflicts, and I assume quite fast. I would posit that if maintaining a patch set in your fork is a lot of

Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)

On 9/1/2024 05:26, Perry E. Metzger wrote: On 1/8/24 12:50, Sergey Fedorov wrote: 2. Standard 10.6.8 release from Apple does support building and running ppc binaries via Rosetta. Why would one want to spend time and effort on doing that, though? You wouldn't, if you were running a public

Python dependencies (was: MacPorts 2.9.0-beta1 now available for testing)

On 2/1/2024 11:24, grey wrote: Installing llvm-17 goes OK, but: Why are python310 and python311 considered dependencies if I already have python312 installed and selected? Pretty sure that some other BSD ports systems I use do not seem to regress like MacPorts in similar dependency walks, the

Re: MacPorts 2.9.0-beta1 now available for testing

On 31/12/2023 23:01, Kirill A. Korinsky wrote: Greeting, Any news / changes on Github PG / extract.rename = yes for multiple distfiles? See: - https://trac.macports.org/ticket/66993 -

MacPorts 2.9.0-beta1 now available for testing

Source code and pkgs for MacPorts 2.9.0-beta1 are now available [1]. Testing of either of these install methods is helpful. Be prepared to encounter bugs. As always, having a recent backup would be wise. Please report any bugs that you find [2] (after first searching Trac [3], of course!) There

Re: Portfile magic / xinstall usage / defect?

On 10/12/2023 16:33, Frank Stock wrote: So every macOS installer that expect certain ownership, needs a pre/post install script that ensures the expected users exist (or create them). It should then explicitly set ownership of files with non-default ownership. Well let's first confirm that

Re: Portfile magic / xinstall usage / defect?

(Moving to macports-dev) Frank Stock wrote: My main focus is .pkg component installers targeting systems where a development toolchain is not realistic. * Do you think it would be possible to use mtree and add_users data to generate code for a postinstall script handling user/group creation

Re: How to parse a Portfile?

On 2/12/2023 15:22, Frank Stock wrote: Thank you for that detailed explanation Josh! It provided all the missing pieces I needed. -Frank No worries. One note, you shouldn't need to use _mportkey for homepage, as that is in the portinfo that you get even just from the index. Also you

Re: How to parse a Portfile?

On 1/12/2023 11:27, Frank Stock wrote: Section 6.4.1 has an interesting bullet… "Ports API - API for Portfile parsing and execution” I would like to extract information from a Portfile such as, version, license, add_users, startupitem, post-destroot, etc. for analysis/processing in a Node.js

Re: MacPorts 2.9

On 1/12/2023 07:08, Clemens Lang wrote: Hey Joshua, On Thu, Nov 30, 2023 at 07:06:51AM +1100, Joshua Root wrote: Just a heads up that I'm planning to create a new release branch and tag a 2.9.0 beta soon. Do you have a specific plan on when you're going to do this? I'm currently finishing

MacPorts 2.9

Just a heads up that I'm planning to create a new release branch and tag a 2.9.0 beta soon. - Josh

Re: Help with zef Portfile

raf wrote: I tried just putting "system" before the command but it didn't work. I couldn't find the documentation for tcl's system, System isn't a standard Tcl thing, it's provided by MacPorts. It's closely analogous to system(3). It takes a single string which is passed to 'sh -c'. It's

Re: Help with zef Portfile

raf wrote: The destroot part looks like this: destroot { "${prefix}/bin/rakudo" -I"${worksrcpath}" bin/zef \ --to="inst#${destroot}${prefix}/share/perl6/site" \ install "${worksrcpath}" ln -s "${prefix}/share/perl6/site/bin/zef" "${prefix}/bin/zef"

Re: How to change Xcode/CLT version in CI/Github Actions

On 22/11/2023 01:46, Dave Allured - NOAA Affiliate wrote: There is no possible port workaround for an Xcode/CLT mismatch such as the current situation on CI OS 13 which I mentioned earlier.  CI OS 13 is in an illegal condition, according to Macports specifications. Is it? We certainly

Re: How to change Xcode/CLT version in CI/Github Actions

On 21/11/2023 12:51, Dave Allured - NOAA Affiliate via macports-dev wrote: Is there an easy way to select a specific Xcode or CLT version for CI workflows?  Developers could insert such temporary control into individual PR's, to be excluded upon merging.   Alternatively, Macports could insert

Re: Port Reclaim

On 7/11/2023 17:39, Saagar Jha wrote: I have noticed that “port install” will not mark a port as requested if it is already installed (e.g. as a dependency of something else you installed). Perhaps this is something that might be worth changing? Saagar Jha

Re: More classes of maintainer

On 6/11/2023 05:58, Perry E. Metzger wrote: On 11/5/23 13:37, Daniel J. Luke wrote: To clarify - this was in the context of commits to base/ (That may or may not change your perception - but like I said, I didn’t measure and this is totally measurable). I don't think the base tools are

Re: More classes of maintainer

On 6/11/2023 05:57, Perry E. Metzger wrote: On 11/5/23 13:36, Joshua Root wrote: There has been an increase in commit volume in more recent years, but it certainly didn't coincide with the GitHub migration in 2016. Put it differently: I do a lot of merges of updates from random people

Re: More classes of maintainer

On 6/11/2023 05:37, Daniel J. Luke wrote: To clarify - this was in the context of commits to base/ (That may or may not change your perception - but like I said, I didn’t measure and this is totally measurable). Indeed, the picture is even more clear with base.

Re: More classes of maintainer

On 6/11/2023 05:26, Perry E. Metzger wrote: On 11/4/23 02:42, Daniel J. Luke wrote: (Before we moved to github there were many people saying we'd get lots more commits by moving to it, but the volume doesn't seem much higher to me - of course, I also didn't measure before/after so my

More classes of maintainer (was: Re: branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms)

On 2/11/2023 12:32, Perry E. Metzger wrote: As an aside, as it stands, the rules situation with closed maintainer / open maintainer is kind of unpleasant already. For example, I'd like to be able to indicate that I'm happy with anyone making reasonable changes to my ports on their own without

Re: [macports-ports] branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms

An understandable presumption in itself, however there was another force push after dluke's last comment, so the changes that ended up being merged had not been reviewed by the maintainer. This was pretty clearly just a misunderstanding, but maybe we should clarify the policies to only allow

Re: [MacPorts] #68563: intermittent 503 errors from {packages, distfiles}.macports.org

Thank you for the fix, and for letting us know. I'll revert the changes on our end and see how we go. - Josh On 30/10/2023 18:32, Michael Meier (FTP-Admin) wrote: On 10/28/23 10:39, MacPorts wrote: #68563: intermittent 503 errors from {packages,distfiles}.macports.org   * cc:

Re: [MacPorts] #68577: ywg.ca.*.macports.org throttled to 1.6Mbps

Thanks, ticket Cc updated. I guess we should update the contact address on as well. On 29/10/2023 02:19, Adam Thompson wrote: I no longer actively manage this mirror.  Can you please CC mir...@muug.ca on the ticket? Meanwhile, I've forwarded this so

Re: librsvg, and what MacPorts is for

On 11/10/2023 06:25, Perry E. Metzger wrote: That said, I presume there's a strong overall consensus that on current hardware, we run the current (supported) versions of software, and that older operating systems and hardware are supported only on a "if it doesn't hurt anything" basis. The

Re: Updating alpine

On 4/10/2023 15:05, contextnerror wrote: I was hoping to update the portfile for alpine. Currently the 2.26 release will not build due to a passfile bug, but this was fixed in a newer commit. (https://repo.or.cz/alpine.git) I had a few questions about how to implement this: - Should I add the

Re: Update port reinstallation instruction on wiki

On 3/10/2023 08:17, Jimmy Wong wrote: On Oct 2, 2023 at 8:13 AM +0100, Joshua Root , wrote: This won't necessarily restore the variants of non-requested ports correctly, and will sometimes install the same port multiple times (a requested port that is a dep

Re: Update port reinstallation instruction on wiki

On 2/10/2023 10:36, Jimmy Yuen Ho Wong wrote: Currently, the Migration guide on the wiki denotes a 6-step process to restore ports after an upgrade, one of which requires the user to download a script that hasn't worked properly for a few years

Re: { darwin any } ports getting reinstalled after OS upgrade

On 27/9/2023 21:47, Christopher Jones wrote: Is the logic behind what all the various options we can now use with platforms documented somewhere ? It's documented in the Guide. - Josh

Re: { darwin any } ports getting reinstalled after OS upgrade

On 27/9/2023 23:01, Nils Breunese wrote: Christopher Jones wrote: I had no idea we supported single tarballs for multiple OS versions. I must say, the distinction between platforms { darwin any } and platforms {darwin >= 11} which *does* result in specific tarballs for each OS is a bit

Re: { darwin any } ports getting reinstalled after OS upgrade

On 27/9/2023 20:42, Nils Breunese wrote: Hi, I’ve updated to macOS 14, installed MacPorts 2.8.1 for Sonoma and then upgraded my ports. I noticed that ports that use ‘platform { darwin any }’ get reinstalled during this process, and ‘port outdated’ shows ‘(platform darwin 22 ≠ 23)’. Does

Re: portfile questions

On 13/9/2023 14:12, Langer, Stephen A. (Fed) via macports-dev wrote: Hi -- I'm getting ready to update the oof2 and oofcanvas ports and have a few questions.   I created the initial portfiles with a lot of help from the admins and I'm still more or less a novice at this. The original

Re: unset or change CPATH/LIBRARY_PATH for build in a portfile

On 11/9/2023 00:58, christos koninis wrote: Hello all, Is there any way to unset or change the CPATH/LIBRARY_PATH environment variables in a portfile during the build? I have tried build.env-delete        CPATH build.env               CPATH=something but they don't seem to be working. The

Re: Regarding github CI

I have wanted to add some testing to the CI and buildbot for some time, but there are a few complications to consider. The first and simplest barrier is that the current release of MacPorts errors out if you try to run tests on a port that doesn't explicitly enable them. Related to that is the

Re: Portfile for osxphotos

On 7/9/2023 16:03, Nils Breunese wrote: Does someone here think MacPorts could install osxphotos without using an intermediary package manager like pipx? Yes, it looks like it's a standard setuptools build system, so the python portgroup should handle it fine. The bigger job might be adding

Re: Close trac #66411

On 30/8/2023 01:13, Dave Allured - NOAA Affiliate via macports-dev wrote: Someone please close https://trac.macports.org/ticket/66411 as completed.  I can't do it myself, and it did not auto-close on the PR.  Thanks. For the record, the "Closes: " text

Re: Build bot notifications

On 23/8/2023 22:25, Kirill A. Korinsky via macports-dev wrote: Folks, Is it possible to have a email notification when build bot have failed to build a port where I'm a maintainer? This is a feature that our buildbot has, but it stopped working at some point and most of us don't have the

Re: Xcode PortGroup: Xcode compiles code twice?

On 16/8/2023 04:29, Jason Liu wrote: Hi everyone, I'm working on a Portfile that uses the xcode PortGroup, and I've noticed something that surprised me: It seems that the MacPorts build is compiling the source code during the build phase, and then compiling the source code AGAIN during the

Re: Why some ports seem to install universal when I do not request it ?

On 15/8/2023 05:06, Christopher Jones wrote: Hi All, Just migrated from an intel to AppleSilicon machine. Reinstalling MacPOrts, from scratch off course, I’ve noticed some ports get install universal, when it’s not something I have requested. e.g. ---> Fetching archive for zlib --->

Re: Problem fetching with git in MacPorts

On 17/5/2023 07:44, Robert Kennedy wrote: I am unable to fetch a file in a git repo using MacPorts.  I get an SSL expired error. fatal: unable to access 'https://codeberg.org/schilytools/schilytools.git/': *SSL certificate problem: certificate has expired* *Command failed:

Re: Help getting new port nrsc5 working

On 17/4/2023 09:01, bl...@netjibbing.com wrote: It looks like I had a previous partial install that was causing this error. I edited the CMakeLists.txt and got it to build, which in turn cleaned up the edited file. Doing a port clean and installation it’s now working as expected. 18291.png

Re: Help getting new port nrsc5 working

On 9/4/2023 06:13, bl...@netjibbing.com wrote: I have had this nrsc5 port sitting around for a long time in a broken state. Would you happen to have any suggestions on how to address this build error? Full build log: https://gist.github.com/trodemaster/2ef9d94db3b894ff690ebd365afed0cd

Re: MacPorts install guide and Xcode dependency

On 4/4/2023 10:49, contextnerror wrote: Currently guide.macports.org tells new users to download a full install of Xcode before installing MacPorts. While some ports do require this, most ports still work with just a copy of the command line tools. Should a CLT installation be the recommended

Re: PyTorch CI Build Issue Request for Help

On 24/3/2023 01:41, Chris Jones wrote: requiring AVX512 is a really rather stringent requirement, most machines will not have these instructions. In fact, even if the build bots where able to make binary tarballs, if they are using these instructions (without runtime capability checks)

Re: PyTorch CI Build Issue Request for Help

On 23/3/2023 23:26, Steven Smith wrote: 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):

Re: Java portgroup default fallback?

On 24/2/2023 11:44, Nils Breunese wrote: Latest LTS (currently openjdk17) could be reasonable, but ideally the fallback version should be verified to work. If that implicitly happens on CI, because there is never a pre-existing Java installation there, then I guess that’s could be ok,

Java portgroup default fallback?

Does anyone know why there is no default value for java.fallback? The assumption appears to be that if a port is using this portgroup, it requires Java, since it errors out in pre-fetch if no Java is found. So it seems like having no fallback by default is just causing builds to fail

Re: ports website says port has been deleted ... but it is there.

cports/macports-webapp/commit/89b85aef53bd83e5c7b6981fd123e13263defc48 <https://github.com/macports/macports-webapp/commit/89b85aef53bd83e5c7b6981fd123e13263defc48> On 04-Feb-2023, at 5:11 AM, Joshua Root wrote: Yeah, failing to parse on that system would also do it. The general rule is to

Re: ports website says port has been deleted ... but it is there.

Yeah, failing to parse on that system would also do it. The general rule is to not use new options unconditionally until they have been in a release for 2 weeks. - Josh On 4/2/2023 04:23, Ken Cunningham wrote: oh, maybe it’s because the ports installation of macports does not accept the

Re: Problem Building Port After Upgrading Macports from 2.8.0 to 2.8.1

not building.  I still get the same extract.rename related error. But I suspect it will take a day before the fix is pushed out to the main repo. I will try again tomorrow. Rob *From:* Joshua Root *Sent:* January 31, 2023 3:43 PM

Re: Problem Building Port After Upgrading Macports from 2.8.0 to 2.8.1

On 1/2/2023 04:49, Robert Kennedy wrote: Error: Failed to extract totp-cli: extract.rename: multiple directories exist in /opt/local/var/macports/build/_Users_grinch_Macports_ports_security_totp-cli/totp-cli/work: etc etc etc What has changed between Macports 2.8.0 and 2.8.1

Re: Maintainer Abuse

On 2022-12-30 16:05 , Fred Wright wrote: On Thu, 29 Dec 2022, Joshua Root wrote: If the change to py-serial you're referring to was mine of Dec 13, that was part of a mass update to adopt a new feature in MacPorts 2.8.0, which only touched openmaintainer and nomaintainer ports. IMO

Re: Maintainer Abuse

On 2022-12-29 15:59 , Fred Wright wrote: Twice recently I've had changes made to ports I maintain without respecting the maintainer timeout (and not for any urgent security-related reasons).  The first was py-serial, where the change was merged without waiting for the maintainer timeout. 

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

Those are OpenCL functions, 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 am hitting linker

Re: using /usr/bin/python3 on Ventura +

On 2022-11-27 13:18 , Ken Cunningham wrote: Well, it didn’t take very long for that to be a problem. Building llvm and clang-9.0 went OK, but building lldb-9.0 fails: - Check size of el_rfunc_t - done -- Found PythonLibs:

Re: Weird outdated state of ports (in webapp)

I see however that the server's HTTP responses do not have Cache-Control:, Expires:, or Last-Modified: headers, so clients don't have much to go on when deciding how long to cache the content. We could likely get better results by setting some or all of these appropriately. - Josh On

Re: Review a fix for OpenSSL3 CVE

On 2022-11-3 06:56 , Clemens Lang wrote: Speaking of this CVE… we don't actually build with the common set of security flags in MacPorts, do we? We should probably look into getting the common set -fstack-protector-strong -fstack-clash-protection -fPIE (probably not required on modern macOS?)

Re: Using platforms in 2.8.0

On 2022-11-1 13:41 , Nils Breunese wrote: Joshua Root wrote: According to https://guide.macports.org/#reference.variables ${os.arch} is either “powerpc”, “i386”, or “arm”. Does this mean all Intel machines have ${os.arch} set to ‘i386', regardless of whether they’re 32 or 64 bit machines

Re: Using platforms in 2.8.0

On 2022-11-1 13:31 , Nils Breunese wrote: Joshua Root wrote: On 2022-11-1 11:45 , Nils Breunese wrote: So when a port installs one pre-built binary on x86_64 and another on arm64, regardless of OS version, setting 'platforms {darwin any}’ would be appropriate and correct? Sure. Unless

Re: Using platforms in 2.8.0

On 2022-11-1 11:45 , Nils Breunese wrote: Joshua Root wrote: On 2022-11-1 11:14 , Nils Breunese wrote: Joshua Root wrote: There is another way that platforms can be used: platforms any platforms {darwin any} The first one indicates that the port will install identical files no matter

Re: Using platforms in 2.8.0

On 2022-11-1 11:40 , Nils Breunese wrote: Joshua Root wrote: On 2022-10-22 21:56 , Kirill A. Korinsky wrote: I'm asking is there a way to support specified arch inside platform block's condition. Like: platform {aarch64} { ... } You can certainly do things like: platform darwin arm

Re: Using platforms in 2.8.0

On 2022-11-1 11:14 , Nils Breunese wrote: Joshua Root wrote: There is another way that platforms can be used: platforms any platforms {darwin any} The first one indicates that the port will install identical files no matter what platform it is built on, and will set the platform

Re: which package to install for macOS 13

On 2022-10-26 06:38 , Helmut K. C. Tessarek wrote: There's no package to install for macOS 13. Does this mean that I can't use MacPorts on Ventura? Or can I just install the Monterey package? Never mind. It just showed up. ;-) Thanks for providing the package for Ventura! For future

Re: macOS 13 minimum required Xcode

On 2022-10-25 10:44 , Aaron Madlon-Kay wrote: Hi all. I have just upgraded to macOS 13 and am attempting to migrate my MacPorts installation. When I try to install a port I get the following error: Error: The installed version of Xcode (14.0.1) is too old to use on the installed OS version.

Re: Using platforms in 2.8.0

On 2022-10-22 21:56 , Kirill A. Korinsky wrote: I'm asking is there a way to support specified arch inside platform block's condition. Like: platform {aarch64}  { ... } You can certainly do things like: platform darwin arm { ... } or: if {$build_arch eq "arm64"} { ... } There is no arch

Re: Using platforms in 2.8.0

On 2022-10-22 20:34 , Kirill A. Korinsky wrote: Does it support somehow arch? I'm not sure what you're asking exactly. There was already the supported_archs option of course, and either a specific set of archs or "noarch" is included in the archive filename. - Josh

  1   2   3   4   5   6   7   8   9   >