Call for legacy-support testing
The latest legacy-support-devel is an RC for the next release. Although the list of additions and bugfixes is fairly modest, there's been some substantial rework of the headers, both to allow full flexibility for SDK choice, and to provide the proper __DARWIN_C_LEVEL conditionals matching those in the Apple headers. Its own tests pass on all platforms, including in all cases involving CPU-compatible SDKs "not earlier" than the target OS, but in view of the extent of the modifications, more widespread testing would be a plus. If no issues are found, this will probably become a release in about a week. Fred Wright
Re: Git-devel has broken git-credential-osxkeychain.c for older systems
On Sat, 20 Apr 2024, Saagar Jha wrote: Wait, I use osxkeychain. It’s basically a requirement if you’re pushing to an authenticated server over HTTPS and don’t want to have to deal with storing keys yourself. I suspect it is used a lot for this. I have yet to see a Git repo that didn't allow you to push via SSH (git://) rather than HTTPS, and that's preferable, anyway. I usually configure repos to use git:// in both directions, though git allows you to configure fetch and push separately if you want. I avoid Keychain as much as I possibly can, after reading in some documentation somewhere that it stores all your passwords on the disk in cleartext the entire time you're logged in. I have no objection to having the osxkeychain feature, but I don't recommend actually using it. Fred Wright On Apr 19, 2024, at 23:52, Kirill A. Korinsky wrote: On Sat, 20 Apr 2024 00:25:47 +0200, Sergio Had wrote: What do we do? :) To fix the build you have two options: 1. Revert that patch for system before 10.7 2. Remove folder contrib/credential/osxkeychain I suggest to follow (2) as simpler thay and the good news that osxkeychain is something that isn't often used.
Re: livecheck and curl 8.7.1
On Fri, 19 Apr 2024, René J.V. Bertin wrote: On Friday April 19 2024 22:10:40 Kirill A. Korinsky wrote: Because MacPorts download distfiles and packages from HTTP, not HTTPS because it contains checksums for that it downloads :) Nope. Maybe for distfiles that are hosted on the own servers, but the past few years more and more ports have had their `master_sites` converted to https URLs. (With good reason: pure http sites are disappearing little by little.) A random bit of proof: DEBUG: fetch phase started at Fri Apr 19 23:04:39 CEST 2024 ---> Fetching distfiles for pulseaudio DEBUG: Executing org.macports.fetch (pulseaudio) ---> pulseaudio-17.0.tar.xz does not exist in /opt/local/var/macports/distfiles/pulseaudio ---> Attempting to fetch pulseaudio-17.0.tar.xz from https://www.freedesktop.org/software/pulseaudio/releases/ % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 1529k 100 1529k0 0 977k 0 0:00:01 0:00:01 --:--:-- 977k That "proof" is completely (well, almost) irrelevant for end users. It matters for port developers, but once a port is "published", its distfiles are copied to the MacPorts mirrors, where they can be fetched by the system curl on any OS. The "almost" is because the primary distfile source is still included as a candidate for fetching, and in some cases may be chosen ahead of the mirrors. In the non-working curl case, this at the very least adds delay, but there was a case a couple of years ago where MacPorts decided to prefer python.org to the mirrors (at my location), and the fetch (on 10.9) would hang in a way that wasn't subject to a timeout, so it never gave up and never moved on to the mirrors. The response when I reported this was "gee, it's supposed to have timeouts". I don't know exactly what got fixed, but I haven't seen this lately. Livecheck is completely different, since there's no mirroring of the content that livecheck is looking at. Fred Wright
Re: how to handle 'internal' logs for failed builds
On Thu, 4 Apr 2024, Chris Jones wrote: [...] The problem is the contents of that log are, of course, not in the macports build log, so I cannot see what it is that is causing it, and as it works for me I cannot look locally myself. I've tried looking at my versions of the logs, and just guess what might be wrong, missing new deps for instance, but that hasn't worked, so I really need to see whats in that log from the build bots... [...] In one sense, it seems rather dumb not to keep logs from failed builds. But since testing isn't the intended purpose of the buildbots, maybe that makes sense. Perhaps it wouldn't be too difficult to add a feature to the buildbots where one could manually trigger a build with a "keeplogs" option. Meanwhile, do the CI testers keep logs of failed builds? I would think that the answer is yes. If so, you should be able to get such a log just by submitting a dummy PR, provided that the failure occurs in one of the OS versions covered by the CI tests. Speaking of buildbot logs, commit a269bae01e9 for legacy-support referenced a build log (as a comment in the Portfile) as the reason for disabling parallel builds, but that's now a broken link. If a buildbot log is to be referenced in such a way, it should be copied to a more permanent location. I can *sometimes* see a parallel build failure locally, which may or may not be the same bug, and there's no way to tell. Usually, those are caused by missing dependencies in the Makefile. Fred Wright
Re: Create new version of legacy-support
On Wed, 3 Apr 2024, Marcus Calhoun-Lopez wrote: Are there any objections to creating version 1.3.0 of legacy-support? legacy-support-devel seems to be working, and some of the features are needed for the latest version of Rust. It looks like this has already happened (though as 1.2.2, not 1.3.0). Fred Wright
Re: XZ Utils Compromised Releases
On Fri, 29 Mar 2024, Blair Zajac wrote: I’m seeing it at 5.6.1 in our GitHub repoisory: https://github.com/macports/macports-ports/blob/master/archivers/xz/Portfile Ah, OK. The 5.4.6 was based on a selfupdate from two days ago. On Mar 29, 2024, at 10:40 AM, Fred Wright wrote: CCing the users list so they don't panic. :-) That didn't work since I don't subscribe to that list. Someone should post something there, since the original message was. Fred Wright
Re: XZ Utils Compromised Releases
On Fri, 29 Mar 2024, Frank Dean wrote: I received a security announcement on the Debian mailing list [1]. It appears versions 5.6.0 of XY Utils and later may be compromised. I also found a discussion on Openwall [2]. [1]: https://lists.debian.org/debian-security-announce/2024/msg00057.html <https://lists.debian.org/debian-security-announce/2024/msg00057.html> [2]: https://www.openwall.com/lists/oss-security/2024/03/29/4 <https://www.openwall.com/lists/oss-security/2024/03/29/4> I'm afraid that's all I know. Just a heads-up. In [1] they mention reverting to 5.4.5 to fix it. It's not 100% clear from that whether 5.4.6 is affected, but it sounds like it's not. Since MacPorts is currently at 5.4.6, the port is probably OK as long as it doesn't do any overzealous upgrading. CCing the users list so they don't panic. :-) Fred Wright
Re: Ruby question: solution for dependency version specs?
On Sun, 17 Mar 2024, Sergio Had wrote: I have no idea what is going on with archaic versions, but Ruby 3.1+ through ruby-devel (3.4) should work on every system. Please stop posting falsehoods. Ruby 3.1-3.3 most certainly do *not* work on every system (yet), and I posted a list of the failing cases in another thread where you were a participant. I haven't looked at 3.4. They are, and everything relevant is rb33-* etc. Unversioned one which use rb18 should re updated or removed: we have no reason to keep Ruby versions prior to 3.0, since 3.0 works on Tiger, and 3.1+ work on Leopard through Sonoma. That also includes PowerPC systems. Again, false. For at least the past few years, no version of Ruby has worked on all systems until I personally fixed it, and I haven't had a chance to fix anything later than 3.0 yet. And contrary to popular belief, Ruby 3.0 isn't (quite) EOL yet. As far as having multiple versions goes, Ruby is just like many other things, where having multiple versions is useful for (at least): 1) Testing code against multiple versions. 2) Using a textbook that is based on a particular version. 3) Avoiding brokenness in one or more versions. No too long ago, the instructions for building the RaspberryPi docs stated that asciidoctor needed to be run with Ruby 2.7 because it didn't work properly with 3.0 (at least for their files). While that no longer seems to be the case, it does serve to illustrate that newer isn't always better, and that it's best to give users a choice as to what version to use, rather than inflicting someone else's notion of the one true best version on them. On Sat, 16 Mar 2024, Austin Ziegler wrote: I also think that the `ruby` port needs to be renamed to `ruby18` and `port install ruby` should *either* fail (like `port install python` or `port install python3` does) or it should install the latest stable version (updated on Christmas Day every year). Agreed. Presumably this came about because having multiple versions wasn't initially anticipated. It's unfortunate that (unlike some other packaging systems) MacPorts doesn't have a way to directly make multiple versions of something available without resorting to the kludge of building the version number into the name. Fred Wright
Re: Testing a modified portgroup
On Mon, 5 Feb 2024, Joshua Root wrote: 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 works correctly, and that some existing ports still work correctly. That's a nice theory, but it often doesn't work. A while back, I tried doing something of that form, but my change was ignored. My setup is that I have a sparse overlay of the ports tree, containing any locally modified files, listed ahead of the normal mirror location in sources.conf. That works fine for testing port changes (as long as the complete directory for any modified port is in the overlay), but it didn't work for a PortGroup change. Looking in debug mode, I could see that it was fetching the PortGroup from the usual mirror source, rather than from the local overlay. At the time, I just gave up. Later, I ran across some evidence that it chooses the PortGroup source based on the source of the port that's including it. Since I wasn't modifying the including port, that explains the behavior, though it most certainly violates the principle of least surprise. So it may be necessary to make a dummy change to the including Portfile to test a PortGroup change. I'm not sure why MacPorts obsesses so much over the location of a Portfile rather than its content. The insanely long build-tree paths differ not only based on whether the Portfile is local or not, but also based on which particular mirror was used to fetch it in the "published" case. Since some build and/or test procedures may choke on the long pathnames, and since even the length of the pathname is mirror-dependent, that means that in some cases the success of a build and/or test may depend on which mirror provided the Portfile. Sheesh. Fred Wright
Re: ldid-procursus: new port review request
On Mon, 28 Aug 2023, Blair Zajac wrote: To reduce friction for reviewers, what’s the link to the PR? At least it included the port name, which often isn't the case. It shouldn't be necessary to follow the PR link (when provided) just to see what port is being referenced. It might not even be an unreasonable practice to include the output of "port info --description " in such emails. Fred Wright
Re: Xcode PortGroup: Xcode compiles code twice?
On Tue, 15 Aug 2023, Jason Liu wrote: Yes, you're right that clearing the build phase doesn't prove anything, but I'm not sure I'm following your other point. Are you saying that "make install" will compile the source code? I was under the impression that you need to manually run "make" in order to actually compile the source code, hence the traditional magic formula of './configure ; make ; make install'. Without the first make, the "make install" shouldn't have anything to install. Or am I wrong about that? Normally, "make install" implies "make" via dependencies, since with properly constructed dependencies, make will notice that it's trying to install something that hasn't been built, and correct that. The main advantage of doing them separately is that "make" doesn't require sudo, while "make install" usually does. If you skip the separate "make" without sudo, then the implied build products wind up owned by root, and even "make clean" requires sudo. Fred Wright
Re: Qt5 on <= 10.6
On Sat, 29 Jul 2023, Sergio Had wrote: Does Qt5 work on 10.5–10.6 Intel? It looks that at least earlier 5.x versions installed on 10.6: https://ports.macports.org/port/qt53/stats Presumably that should be fixable for 10.5 and PPC. (I am not sure if 5.3 is of much use though – do developers of ports depending on Qt5 support it still?) P. S. Given how much efforts it takes every time to fix something for Qt4, even if it means just digging out a right version and reverting some commits, I start asking a question if it is easier just to fix some early 5.x version. There should not be anything arch-specific, it should be just C++, I guess. Just find fallbacks for whatever misses in SDK, but if it works on 10.6 Intel, it might be pretty feasible. One shouldn't assume that Qt5 is a drop-in replacement for Qt4. At one point, I'd added an option to gpsd to allow building with Qt5, and it worked at the time I created it. But later on, something changed to break the build with Qt5, and I never tracked it down, so for now it's stuck on Qt4. This is unfortunate, since Qt4 seems to think that any processor that's not x86 must be ppc, so building against Qt4 on the M1 falls on its face trying to include ppc-specific code. The Qt4 build itself works, just not building gpsd against it. Fred Wright
Re: rldicl / rldicr for 32-bit powerpc?
On Sun, 16 Jul 2023, Sergey Fedorov wrote: The linked code is for an emulator, and is providing a *C* implementation, not a ppc32 machine-code Whatever provides the needed functionality, gonna be good enough, I guess. I can't imagine any context in which you can freely choose whether to supply C code or assembler code, so using the code you linked in this context is virtually guaranteed not to "provide the needed functionality". It also occurs to me that any code using rldicX instructions must be assuming 64-bit registers. But ppc32 doesn't have 64-bit registers, so a couple of missing opcodes may be just the tip of the iceberg. That being said, if the code *knows* it's dealing with 32-bit registers, then using rldicX instructions is just a bug. If it supports both i386 and x86_64, it might be instructive to look at how it handles the differences. If it doesn't support i386, that might be a clue that 32-bit support would be significant work. Fred Wright
Re: rldicl / rldicr for 32-bit powerpc?
On Sat, 15 Jul 2023, Ken Cunningham wrote: Adding it into cctools for the standard assembler to use whenever it might be needed would be something of a project, to be sure... I think it would be highly unusual for an assembler to replace instructions for one architecture with instructions for another architecture, even when the two are related. Anything generating actual machine instructions should know what architecture it's targeting, and generate appropriate code. However, patching it into a source file that needs it on a case-by-case basis is probably a fairly trivial thing to do. Probably so, once one works out the appropriate instructions. That's not hard in principle (though trickier for the "dotted" versions), but I'm busy with other stuff right now (and don't currently have a working ppc64 machine for comparison testing). The linked code is for an emulator, and is providing a *C* implementation, not a ppc32 machine-code implementation. Fred Wright
Re: Commit Messages
On Sat, 15 Jul 2023, David Gilman wrote: I imagine this can be linted in the git local commit-msg hook. It won't stop a dedicated offender who can push directly to master but it wouldn't hurt to ship it in the macports-ports repo and promote it in the guidelines. It would be fairly straightforward to catch this in a pre-commit hook, and those apply at the time commits are created, and hence don't care about whether the commits will eventually be pushed directly or submitted as PRs. But hooks don't propagate across repos, so such a hook would only apply to users who'd explicitly installed it. Another possibility would be a receiver-side hook on GitHub, but those aren't intended for this sort of purpose, so constructing such a hook would be more complicated. Fred Wright On Sat, Jul 15, 2023 at 2:58 PM Fred Wright wrote: In recent times, commit messages failing to conform to the guidelines have been becoming more common - specifically, the failure to include a blank line after the summary. The guidelines even state briefly why this matters, though perhaps not emphatically enough. Recent offenders are: 2d9585490dc87249c189c211a228984b3a3830c7 331c484f0c10d378bcbf011fa14cb7fc0e1768be f5ce144934601cc243df6e02b2d47b7956acd335 b395f71013212e625fb96051bcc9a31aa0b5bd26 The standard git tools split a commit message into a summary (a.k.a. subject) and a body, with the first blank line being the division point. In format strings, these are %s and %b, respectively. Some third-party git tools limit the summary to the first line, so people using such tools may not even notice the error, but such tools shouldn't be the standard. The output of commands like "git log --oneline" and "git branch -v" becomes quite annoying with this error. Fred Wright -- David Gilman :DG<
Commit Messages
In recent times, commit messages failing to conform to the guidelines have been becoming more common - specifically, the failure to include a blank line after the summary. The guidelines even state briefly why this matters, though perhaps not emphatically enough. Recent offenders are: 2d9585490dc87249c189c211a228984b3a3830c7 331c484f0c10d378bcbf011fa14cb7fc0e1768be f5ce144934601cc243df6e02b2d47b7956acd335 b395f71013212e625fb96051bcc9a31aa0b5bd26 The standard git tools split a commit message into a summary (a.k.a. subject) and a body, with the first blank line being the division point. In format strings, these are %s and %b, respectively. Some third-party git tools limit the summary to the first line, so people using such tools may not even notice the error, but such tools shouldn't be the standard. The output of commands like "git log --oneline" and "git branch -v" becomes quite annoying with this error. Fred Wright
Re: rldicl / rldicr for 32-bit powerpc?
On Sat, 15 Jul 2023, Sergey Fedorov wrote: Is there an implementation to replace these on ppc32? There is some Linux version online which I found: https://patchwork.kernel.org/project/kvm/patch/1403472217-22263-30-git-send-email-ag...@suse.de/ But since it is a magic code, no idea if it is portable or not. You'd have to be more specific about the intended context. AFAIK, OSX/macOS didn't have anything like KVM until 10.10, so this specific patch wouldn't be relevant. Fred Wright
Clang Clang Clang Went the Buildbots
It probably wasn't a good plan to push simultaneous updates to every clang version in sight. I imagine the buildbots are still struggling to catch up, and meanwhile users doing "upgrade outdated" are stuck doing long builds from source. My MacBook Pro alone took almost 19 hours, and the whole process took over 24. BTW, on 10.11, upgrading clang-14 wants clang-11, which fails to build, apprently due to building something for i386 and failing to link against the non-uiniversal libxslt. Fred Wright
Re: Buildbots down?
On Tue, 7 Feb 2023, Ryan Schmidt wrote: On Feb 6, 2023, at 14:09, Fred Wright wrote: Based on a couple of ports where I've had PRs merged recently, it looks like the buildbots are mostly back in service, but Mojave and arm64 are still out. Yes. Disk first aid found a minor problem on the Mojave disk that I had hoped to correct before putting it back into service by booting from the installer and running some fsck commands there, but it is hanging when booting from the installer. It is possible I created the installer image incorrectly. Did you do something other than run createinstallmedia from the installer app? If you copy an existing installer, make sure you copy the entire drive and not just the volume. The OS is incapable of fully booting from a volume (as I've found out the hard way). If it was just about running fsck for minor problems, why not just boot into single-user mode? I took the Apple Silicon machine offline in anticipation of upgrading it; see https://trac.macports.org/ticket/66637. Yes, I saw that. Fred Wright
Re: Buildbots down?
On Thu, 2 Feb 2023, Ryan Schmidt wrote: On Feb 2, 2023, at 18:25, Herby G wrote: There haven't been any builds for recent commits to master on Github in over 24 hours at the moment of writing this. https://build.macports.org/ is also failing to load. Can someone take a look? Unfortunately, Winter Storm Mara delivered several days of freezing rain to the Austin area. The ice and wind has broken a large number of tree branches which has downed a large number of power lines. 30% of the city, including the buildbot machines, has been without power, in the case of the buildbot for 38 hours already. As of four hours ago the power company has stated they are unable to provide an estimate for when power will be restored. https://twitter.com/austinenergy/status/1621235217909383169?cxt=HHwWgoC8zem15P8s This affects the build.macports.org web page, all build machines*, and also updates to rsync.macports.org. (*The Apple Silicon build machine is off-site and still online but can't get anything done without build.macports.org telling it what to do.) Based on a couple of ports where I've had PRs merged recently, it looks like the buildbots are mostly back in service, but Mojave and arm64 are still out. Fred Wright
Re: Maintainer Abuse
On Thu, 29 Dec 2022, Joshua Root wrote: 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. And just now I see that someone abused their write access to bypass the PR mechanism entirely for a gpsd update, so that I wasn't even notified of the change. And I've had good reason to hold off on updating gpsd, due to its missing dependency on asciidoctor, which is currently broken on some platforms due to the insistence on tying it to a broken version of ruby, which I've actually been working on fixing. Is this now the Wild West? Sorry you've been put out by these commits. Both of these ports are marked as openmaintainer, which according to the project policy [1] means that minor changes are allowed without obtaining the maintainer's permission first. That certainly isn't carte blanche to do whatever you want, but it does mean that pushing changes directly isn't necessarily against the rules. My understanding is that only time-critical changes, or stuff in the "cleanup" category, should be pushed without maintainer input. The definition of a minor update is left somewhat vague, but can probably be thought of as synonymous with low-risk. I would say anything beyond simple bugfixes, and certainly anything that changes the API or ABI, should be run by the maintainer first. And as the policy says, the committer is responsible for ensuring that the changes work properly. If you push a change to someone else's port, you should consider yourself "on the hook" for fixing anything that breaks as a result. More on "minor" and "low risk" below. When in doubt, run it by the maintainer. I'm not familiar enough with gpsd to say whether the recent update was minor or not. Marius, please work with Fred to resolve any issues that it may have caused. 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 it was well within the definition of a minor change. That isn't the change I was referring to (but see below); I was referring to 66c7d25d427. I had no objection to adding the py310 subport (though checking still would have been appropriate), but I strongly object to the removal of the py34-py36 subports. And no change that removes a capability can be considered "low risk" by any stretch of the imagination. I'm a firm believer in maximum compatibility, and one of the things I like about MacPorts is its support for a wide range of OS versions (though adequate testing is often lacking). But for some reason, that same courtesy isn't extended to older Python versions, and some even think that it's a good idea to engage in rampages of ethnic cleansing of older Python subports. One shouldn't look to the python.org folks for guidance on this issue; those are the same folks that (initially) expected everyone to immediately migrate to Python 3, and explicitly discouraged making code simultaneously compatible with both Python 2 and Python 3 at all. But Python versions can't be mixed within a single execution of a single program, so a given program and all its imported modules have to be compatible with at least one Python version. Similarly, every module needs to have at least one Python version compatible with itself and every program that uses it. This creates a massive interconnected web of Python code that needs to be simultaneously compatible with at least one Python version. Denying simultaneous Python 2/3 compatibility was tantamount to expecting the majority of all Python code in the entire world to be converted in lockstep from Python 2 to Python 3, which was utterly insane (particularly given that a lot of that code is maintained by volunteers working in their spare time). Once the pitchfork-carrying mobs appeared at the gates, the python.org folks relented and provided documentation and recommendations for "polyglot" code that works with both Python 2 and Python 3. They also extended the support period for Python 2.7, but even the extended period was woefully inadequate. There are substantial incompatibilities between Python 2 and Python 3, and it takes real work to fix existing Python 2 code to handle Python 3. I know of at least one project that was still fixing bugs related to Python 3 many months after dropping support for Python 2, so that running it with Python 2 wasn't an available workaround. Personally, I now try to write all *new* Python code so that it's compatible with both, and I've fixed a substantial amount of my existing code to do so, but I still have a substantial amount of
Maintainer Abuse
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. And just now I see that someone abused their write access to bypass the PR mechanism entirely for a gpsd update, so that I wasn't even notified of the change. And I've had good reason to hold off on updating gpsd, due to its missing dependency on asciidoctor, which is currently broken on some platforms due to the insistence on tying it to a broken version of ruby, which I've actually been working on fixing. Is this now the Wild West? Fred Wright
Re: MacPorts 2.8.0-beta1 now available for testing
On Sat, 15 Oct 2022, Joshua Root wrote: On 2022-10-15 13:20 , Fred Wright wrote: IMO, it should ask before following replaced_by, since replaced_by is sometimes a matter of opinion. For example, sometimes "port X is replaced by port Y" really means "We don't want to bother supporting port X any more, so you should use port Y instead; if it doesn't meet your needs then that's too bad." Typically a port with replaced_by set will have been converted to a stub that does nothing but error out if you try to install it, so the ability to bypass this feature doesn't help you much. But there is a --no-replace flag in case it's needed. Sure, but the inverted default is inconsistent with the way dependencies are handled. If one attempts to install a port with missing dependencies, it asks about the dependencies, and if one answers no, then the port isn't installed, without having to predict this possible scenario in advance and providing an extra option. I don't see why installing a port instead of what the user requested should be more aggressive than installing a port in addition to what the user requested. Fred Wright
Re: MacPorts 2.8.0-beta1 now available for testing
On Sat, 15 Oct 2022, Joshua Root wrote: On 2022-10-14 18:13 , Ken Cunningham wrote: the only other thing I noticed was that these helpful pre-fetch messages were no longer being displayed: https://github.com/macports/macports-ports/blob/c7a8d3cf75b8b48a90139cbb35e385bb7bcbd165/x11/xorg-server/Portfile#L103 <https://github.com/macports/macports-ports/blob/c7a8d3cf75b8b48a90139cbb35e385bb7bcbd165/x11/xorg-server/Portfile#L103> Instead there was just a message saying the build was known to fail, but try anyway? But the instructions about what to actually do are gone now… Perhaps no way around that? In that particular case, the solution is to set `replaced_by xorg-server-legacy` instead of erroring in pre-fetch. As of 2.8, replaced_by will be followed when installing as well as when upgrading. IMO, it should ask before following replaced_by, since replaced_by is sometimes a matter of opinion. For example, sometimes "port X is replaced by port Y" really means "We don't want to bother supporting port X any more, so you should use port Y instead; if it doesn't meet your needs then that's too bad." I can see why the ability to give an explanation more than "this is broken" is appealing, but it can't (easily) be done via pre-fetch messages while still resolving <https://trac.macports.org/ticket/54787>. We need to figure out that ports are known_fail before processing their dependencies. One annoyance that I've encountered is when a fetch dependency needs to be satisfied even when the distfile archive(s) is/are already present. Fred Wright
Re: help with a regex please
On Sun, 19 Jun 2022, Ken Cunningham wrote: to fix the universal build of some ports, eg jemalloc, I would like to strip out the host bits from these text strings, eg convert this: echo "--prefix=/opt/local --with-jemalloc-prefix= --host=aarch64-apple-darwin21.5.0 host_alias=aarch64-apple-darwin21.5.0 CC=/usr/bin/clang” to this: echo "--prefix=/opt/local --with-jemalloc-prefix= CC=/usr/bin/clang” however, my regex-fu is not strong. Anyone know the secret reinplace regex that might do that? I presume the lack of "--" in front of the "host_alias" is a typo. I don't know specificlly about reinplace, but here's an example with sed: MacPro:misc fw$ cat mpregex.txt echo "--prefix=/opt/local --with-jemalloc-prefix= --host=aarch64-apple-darwin21.5.0 --host_alias=aarch64-apple-darwin21.5.0 CC=/usr/bin/clang" MacPro:misc fw$ sed -E 's/ --(host|host_alias)=.* / /g' mpregex.txt echo "--prefix=/opt/local --with-jemalloc-prefix= CC=/usr/bin/clang" Fred Wright
Re: PR 14427: 10.14 tester wanted
On Tue, 5 Apr 2022, Joshua Root wrote: On 2022-4-5 15:49 , Fred Wright wrote: Empirically, it was ignored in this case, probably due to a bug. The sequence was: sudo port uninstall qt6-qtbase sudo port -sk install qt6-qtbase The install didn't build anything, unless I explicitly cleaned after the uninstall. What was the state to begin with? In the very initial state, I'd never installed this port at all. I first did, multiple times (since I was puzzled by the SDK complaint): sudo port install qt6-qtbase sudo port uninstall qt6-qtbase This built each time. At some point I decided that I wanted the log, so I added -k to the install. I *think* it was after that that the install stopped rebuilding (though that was on another day and another boot), even after adding -s. An existing build directory won't be cleaned by uninstalling an installed version. The uninstall *claims* to clean twice, once after the deactivate and once after the uninstall. But it's insufficient to avoid skipping the build on the next install. Cleaning explicitly after the uninstall seems to fix it. However, it appears that the implicit clean after the install (when not suppressed by -k) is sufficient. Fred Wright
Re: PR 14427: 10.14 tester wanted
On Tue, 5 Apr 2022, Joshua Root wrote:
On 2022-4-5 08:23 , Fred Wright wrote:
The fact that you have no 10.15 SDK at all suggests that you're running
Xcode 10.x, though up through 11.3.1 runs on 10.14. I usually run the
latest Xcode for each OS version, which is what the MacPorts documentation
recommends.
% xcodebuild -version
Xcode 11.3.1
Build version 11C504
However:
% pkgutil
--pkg-info=com.apple.pkg.{CLTools_Executables,CLTools_Base,DeveloperToolsCLI,DeveloperToolsCLILeo}
2>/dev/null | sed -n 's/^version: //p'
10.3.0.0.1.1562985497
Newer CLT versions are not offered to me via Software Update on 10.14.
But there's:
https://download.developer.apple.com/Developer_Tools/Command_Line_Tools_for_Xcode_11.3.1/Command_Line_Tools_for_Xcode_11.3.1.dmg
On Tue, 5 Apr 2022, Joshua Root wrote:
The -s option should never be ignored AFAIK, but depending on the action you
are using and the current state, it may be considered a noop with or without
-s (like 'port install' when the port is already installed, or 'port
destroot' when the statefile already shows the destroot phase as completed.)
Empirically, it was ignored in this case, probably due to a bug. The
sequence was:
sudo port uninstall qt6-qtbase
sudo port -sk install qt6-qtbase
The install didn't build anything, unless I explicitly cleaned after the
uninstall.
Fred Wright
Re: PR 14427: 10.14 tester wanted
On Mon, 4 Apr 2022, Fred Wright wrote: Meanwhile, it looks like the update was already pushed, since I had to fight the port command's refusal to honor -s during further testing. It seems that an explicit clean is needed to make -s work, in spite of the two alleged cleans during the uninstall. Actually, it doesn't look like the update was pushed, so maybe the -s is ignored when the binary archive already exists locally. Fred Wright
Re: PR 14427: 10.14 tester wanted
On Sun, 3 Apr 2022, Joshua Root wrote: On 2022-4-3 14:05 , Fred Wright wrote: lrwxr-xr-x 1 root wheel 15 Sep 26 2020 MacOSX.sdk -> MacOSX10.15.sdk drwxr-xr-x 7 root wheel 224 Sep 26 2020 MacOSX.sdk 1 lrwxr-xr-x 1 root wheel 10 Aug 17 2019 MacOSX10.14.sdk -> MacOSX.sdk drwxr-xr-x 8 root wheel 256 Nov 7 2019 MacOSX10.15.sdk I'm pretty sure I never changed anything there, other than by running Apple installers. I wouldn't be surprised if "MacOSX.sdk 1" is really a 10.14 SDK, but I didn't dig into it. Having MacOSX10.14.sdk ultimately pointing to MacOSX10.15.sdk is probably going to cause problems. On my 10.14 system it looks like this: % ls -l /Library/Developer/CommandLineTools/SDKs total 0 drwxr-xr-x 7 root wheel 224 9 Jul 2019 MacOSX.sdk drwxr-xr-x 5 root wheel 160 12 May 2018 MacOSX10.13.sdk lrwxr-xr-x 1 root wheel 10 4 Oct 2019 MacOSX10.14.sdk -> MacOSX.sdk % plutil -p /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/SDKSettings.plist | fgrep \"Version\" "Version" => "10.14" The fact that you have no 10.15 SDK at all suggests that you're running Xcode 10.x, though up through 11.3.1 runs on 10.14. I usually run the latest Xcode for each OS version, which is what the MacPorts documentation recommends. Using the unversioned name for the real directory and the versioned name for the symlink is rather backwards, but it seems to be par for the course. On Sun, 3 Apr 2022, Christopher Chavez wrote: Thank you for testing. However the proposed change is specifically to allow building with the 10.14 SDK, and so what I wanted to be sure of is whether it actually worked with the 10.14 SDK; I expected there to already not be any problems building with the 10.15 SDK on macOS 10.14. Well, you didn't say that. :-) I rearranged the SDKs to look like this: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs: total 0 drwxr-xr-x 4 fw wheel 128 Nov 7 2019 DriverKit19.0.sdk lrwxr-xr-x 1 fw wheel 15 Apr 4 14:10 MacOSX.sdk -> MacOSX10.14.sdk lrwxr-xr-x 1 fw wheel 56 Apr 3 15:47 MacOSX10.14.sdk -> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk drwxr-xr-x 8 fw wheel 256 Nov 7 2019 MacOSX10.15.sdk /Library/Developer/CommandLineTools/SDKs: total 0 lrwxr-xr-x 1 root wheel 15 Apr 3 15:30 MacOSX.sdk -> MacOSX10.14.sdk drwxr-xr-x 7 root wheel 224 Sep 26 2020 MacOSX10.14.sdk drwxr-xr-x 9 root wheel 288 Apr 3 15:30 MacOSX10.15.sdk So both 10.14 and 10.15 SDKs are available, to both GUI Xcode and CLT, with 10.14 as the default. I still get the warning, though it looks like it probably comes from base rather than the port. The beginning of the logfile looks like this: DEBUG: Starting logging for qt6-qtbase @6.2.1_4+openssl DEBUG: macOS 10.14.6 (darwin/18.7.0) arch i386 DEBUG: MacPorts 2.7.2 DEBUG: Xcode 11.3.1 DEBUG: SDK 10.14 DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.14 Warning: The macOS 10.14 SDK does not appear to be installed. Ports may not build correctly. Warning: You can install it as part of the Xcode Command Line Tools package by running `xcode-select --install'. DEBUG: epoch: in tree: 0 installed: 0 DEBUG: xz 5.2.5_0 exists in the ports tree So something isn't right with the SDK check. Meanwhile, it looks like the update was already pushed, since I had to fight the port command's refusal to honor -s during further testing. It seems that an explicit clean is needed to make -s work, in spite of the two alleged cleans during the uninstall. Fred Wright
Re: PR 14427: 10.14 tester wanted
On Sun, 3 Apr 2022, Joshua Root wrote: On 2022-4-3 12:00 , Fred Wright wrote: I got a warning about the 10.14 SDK not being installed, which I found surprising since I know I have the CLTs installed. Running the suggested "xcode-select --install" complains that the CLTs are already installed, and suggests Software Update, which doesn't do anything. Looking in the SDKs directory within the Xcode bundle, I see 10.15 but not 10.14, though that ought to work and seems to work. Perhaps the SDK check (which I think is separate from the port itself) is overly picky. I don't know about qt6 specifically, but in the general case, the warning is precisely as picky as it should be. Building anything that doesn't handle weak-linked symbols correctly (which is most things) against an SDK newer than the OS it will be run on will result in runtime crashes. This is why we always say to install the Command Line Tools, because Xcode doesn't necessarily have the SDK matching the current OS version, whereas the CLTs do. Building against the newer SDK doesn't cause weak-linking issues as long as the code uses MIN_REQUIRED instead of MAX_ALLOWED to decide what references to make. MIN_REQUIRED is the correct choice in most cases, but code often gets that wrong. Having them the same mostly sweeps that problem under the rug. Apple seems to think that using the newer SDK is OK, since it's set up (in the CLT area) like this: lrwxr-xr-x 1 root wheel 15 Sep 26 2020 MacOSX.sdk -> MacOSX10.15.sdk drwxr-xr-x 7 root wheel 224 Sep 26 2020 MacOSX.sdk 1 lrwxr-xr-x 1 root wheel 10 Aug 17 2019 MacOSX10.14.sdk -> MacOSX.sdk drwxr-xr-x 8 root wheel 256 Nov 7 2019 MacOSX10.15.sdk I'm pretty sure I never changed anything there, other than by running Apple installers. I wouldn't be surprised if "MacOSX.sdk 1" is really a 10.14 SDK, but I didn't dig into it. SDKs provided by the CLTs would be in /Library/Developer/CommandLineTools/SDKs. If you have a 10.14 SDK there but qt6 is not finding it, it may only be looking in Xcode, and hopefully it knows what it's doing. Or it's finding it but looking inside to see what version it is. Whether it knows what it's doing is unknown. Fred Wright
Re: PR 14427: 10.14 tester wanted
On Thu, 31 Mar 2022, Christopher Chavez wrote: Could someone with access to 10.14 please try this PR? https://github.com/macports/macports-ports/pull/14427 Does the port (or output object qapplekeymapper.mm.o more specifically) now build with the patch, or does it encounter other errors? I verified that qt6-qtbase builds on 10.14. I don't have an easy way to test it. I got a warning about the 10.14 SDK not being installed, which I found surprising since I know I have the CLTs installed. Running the suggested "xcode-select --install" complains that the CLTs are already installed, and suggests Software Update, which doesn't do anything. Looking in the SDKs directory within the Xcode bundle, I see 10.15 but not 10.14, though that ought to work and seems to work. Perhaps the SDK check (which I think is separate from the port itself) is overly picky. Fred Wright
Re: Policy on `obsolete` ports...
On Fri, 19 Nov 2021, Perry E. Metzger wrote: Howdy! As things stand, we don't explicitly say much in our rules about whether people can remove obsolete ports after a year even without a port maintainer's say-so. We also have circumstances where people leave "maintainer" lines in ports that have been put into `obsolete`. [...] 4. If a subport is set `obsolete`, the usual rules about the maintainer needing to consent to touching the Portfile should not apply for removing said subport in a year, as the one year is (again) enough time for them to think better on it. Any edit to a port potentially conflicts with something the maintainer(s) may be doing. The only justification for bypassing the normal maintainer timeout is when deploying the change is time-critical. Removing an obsolete port that's been in place for months hardly qualifies. Fred Wright
Re: Help with testing of PR 7074 - python27-bootstrap: stop using gettext-bootstrap
On Thu, 28 Oct 2021, Christopher Nielsen wrote: Folks, this PR has been open since 5/12/2020, and we’d love to finally merge it. Of note, it’s also the key dependency preventing merge of PR 7399, the latter for a long-awaited update to gettext. In short, we need someone to test a source-only install of clang-3.4 - along with all of its dependencies - for 10.6. I’ve done it twice, both via a VM, as well as a physical installation. But it would be beneficial to have one other person do this too, as it’s critical that we get this right the first time. In terms of what’s needed: * Setup a fresh MacPorts 2.7.1 installation on 10.6. * Update the port file for python27, per the PR. * Run ‘sudo port -s -N install clang-3.4’ * Wait for everything to build Depending on your 10.6 setup, this is likely to take at least a few hours. But apart from that, it’s essentially a hands-off process. Alternatively, if folks are comfortable with merging the PR as it is - with two rounds of testing, albeit from one individual - we can do that as well. But personally, I’d feel better if at least one other person validates this. Thoughts? To incentivize progress, I’ll give a $50 gift card to the first person who’s willing to validate this on 10.6. Any takers? I ran this on VMs for 10.6 i386, 10.6 x86_64, and 10.6 server x86_64. The good news is that all the builds succeeded. The bad news is that the list of installed ports afterward included gettext-bootstrap in the 64-bit cases, though not the 32-bit case. The total build time was about 39 minutes, though I think the prep took longer than that, due to the requirement to start from a fresh install, and my wanting to preserve my existing installs in a restorable state, Fred Wright
Re: upgrade to openssl 3.0.0
On Mon, 4 Oct 2021, Christopher Jones wrote: On 4 Oct 2021, at 5:54 pm, Ken Cunningham wrote: I was hoping to move this along for the overwhelming benefit of the license, but TBH the push-back so far is 99.99% negative about moving to openssl 3.0.0 this year, so too controversial for me to get involved with. I'll sit back for six to twelve months and see what you guys work out over the coming year. All the more reason to follow my suggested migration path then I would say, as it allows an openssl30 port to be made available, and those ports that wish to can use it via the new PG, but it doesn’t have to become the default until some later date. The PR thread contained (approximately) the following two statements: 1) Unless v3 is the default, nobody will bother to use it. 2) Everybody is really, *really* anxious to move to v3 for the more permissive license. Clearly those two statements are in conflict. At Google, we had a process called "canarying". Although technically a misnomer, it referred to the "canary in the coal mine" concept, with the idea that rolling out new stuff with possible issues should start small, so that problems could be found (and hopefully fixed) before they caused large-scale breakage. If the OpenSSL folks were committed to maintaining backward compatibility, then none of this nonsense would be necessary, but it's clear that they're not. And there's no reason to assume that they won't pull the same crap again in the future (having done so at least twice already), so having a mechanism for multiple coexisting OpenSSL "major" versions could have long-term value beyond the v3 transition. TBH I also was quite dubious of making 3.0.0 the default any time ’soon’ I agree, especially if the only end benefit is the license. Remember, OpenSSL is the poster child for why *not* to assume that that newer is more secure. :-) Fred Wright
Re: OpenSSL GPL conflict (was: Re: License GPL-2 conflicts with OpenSSLException)
On Fri, 16 Apr 2021, Ryan Schmidt wrote: On Apr 16, 2021, at 20:33, Fred Wright wrote: [...] For that matter, IMO this whole business of the OpenSSL license conflicting with the GPL is a bunch of nonsense (at least in the typical MacPorts scenario). Since when does *dynamically* linking against an *unbundled* shared library constitute "redistribution" of said library? And if anyone tries to claim that merely including the bits necessary to link against the library is "redistribution", the recent SCOTUS ruling in Oracle v. Google should put that to rest. Since you're now asking a different question than what I was asking, let's retitle the thread. I'm not aware of the Oracle / Google ruling. They ruled in favor of Google, meaning that copying Oracle's Java header files to use in conjunction with Google's Java implementation did not constitute a violation of Oracle's copyright. Essentially they said that APIs aren't copyrightable. The reason why the OpenSSL license and GPL conflict, unless an exception is granted, when the OpenSSL is not part of the operating system, is explained here: https://people.gnome.org/~markmc/openssl-and-the-gpl Yes, I'm aware of that alleged explanation. But the key point is that it relates to the *redistribution* of OpenSSL, and I contend that merely dynamically linking against a non-bundled OpenSSL library does not constitute "redistribution" of said library, and hence the alleged conflict is inapplicable. Fred Wright
Re: License GPL-2 conflicts with OpenSSLException
On Fri, 16 Apr 2021, Ryan Schmidt wrote: https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/55652/steps/gather-archives/logs/stdio "hydrogen" is not distributable because its license "GPL-2" conflicts with license "OpenSSLException" of dependency "qt5-qtbase" Does this make sense or is there an error in the script? Why would GPL-2 or anything conflict with OpenSSLException? It's just an exception. It lifts some restrictions imposed by the GPL. It shouldn't be imposing additional restrictions itself, should it? For that matter, IMO this whole business of the OpenSSL license conflicting with the GPL is a bunch of nonsense (at least in the typical MacPorts scenario). Since when does *dynamically* linking against an *unbundled* shared library constitute "redistribution" of said library? And if anyone tries to claim that merely including the bits necessary to link against the library is "redistribution", the recent SCOTUS ruling in Oracle v. Google should put that to rest. Fred Wright
Re: ARM64 Github CI
On Fri, 26 Mar 2021, Ryan Schmidt wrote: On Mar 24, 2021, at 17:50, Joshua Root wrote: we would have to set up a self-hosted runner. People have expressed interest in this (for x86_64) every now and then over the years, but as of now we have no ability to do this. Software would need to be written to allow this to happen. And then we would either need separate hardware to run it on, or the software would need to be written in such a way that it could coexist with the existing buildbot hardware (for example in a non-root MacPorts installation in another prefix, but a subset of ports are not able to be built in non-root installations). Does MacPorts play nicely with chroot? A VM would be another possibility, but chroot would make more sense if it works. Fred Wright
Re: fun fact about ICU +universal
On Sun, 14 Feb 2021, Ken Cunningham wrote: The i386/x86_64 universal build looks fine too, so far, with all the muniveral stuff out. Now -- have to see why it was ever put in there in the first place, I guess. One of the typical sources of trouble with "natural universal" builds is architecture-dependent configure checks, whose results are inherently forced to be single-valued across architectures. Since arm64 and x86_64 have both the same bitness and the same endianness, it might be a non-issue for that combination in many cases, even while being technically incorrect. If i386/x86_64 also works, that suggests that bitness isn't an issue, but endianness would be if ppc were included. Alignment is another potential issue, but less likely to be in these cases. Though another problem with this sort of issue is that merely building successfully doesn't verify that the code actually works correctly. Remember Apple was shipping Intel Macs to end users before they'd fixed all the endian bugs. Fred Wright
Re: change libcxx +emultated_tls to installing a binary please on < 10.7...
On Tue, 1 Dec 2020, Ryan Schmidt wrote: On Dec 1, 2020, at 00:07, Ken Cunningham wrote: 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-gcc42) would tell people what to do: require the installation of clang-5.0, then run: sudo port install libcxx -bootstrap and that gets the binary installed. From then on, people would just have to sudo port install libcxx and they would get the TLS version. apple-gcc42's +bootstrap variant is not suitable for the buildbot either because of that manual step. The solution would be to change it to a apple-gcc42-bootstrap subport that installs its files somewhere else, and apple-gcc-42 (non-bootstrap) knows how to use those files to build itself. I've wondered about that variant vs. subport issue myself. I don't think there's a need for "somewhere else" as long as it uses a different name. MacPorts compilers already use nonstandard names, so that would just require using a different nonstandard name. In fact, I think it would make sense for bootstrap compilers to be full-fledged compilers in the sense of having "MacPorts compiler names", with the only abnormality being that they shouldn't be considered to be compiler candidates by default. They're probably also not reasonable choices for gcc_select or clang_select. Fred Wright
Re: Shutting down the Atlas port
On Thu, 5 Nov 2020, Ryan Schmidt wrote:
On Nov 3, 2020, at 04:52, Vincent Habchi wrote:
Atlas, the software meant to provide scientific computing tools with a
high-performance assembly-based library has, IMHO, reached its end of life.
My case is this:
• Last developer (unstable) release is more than two years old;
• Last stable release is twice older (2016);
• Consequently, ASM snippets Atlas relies on might not be up to date with the
latest Intel processors;
• Atlas will prolly never be ported to the new ARM-based architecture Apple is
about to unveil;
• The method used by Atlas to select the best assembly snippet (a.k.a “kernel”)
for a given computation task is defeated by the power saving steps included in
recent versions of MacOS, namely a gradual lowering of the priority of any
power consuming task. This can lead to erratic, non-reproducible, and
sub-optimal choices, rendering Atlas pointless;
• Atlas build time from sources varies around 3 to 4 hours, regardless of the
number of cores available (the selection process is mono-threaded), which makes
Atlas cumbersome to build, and still more cumbersome to debug, barring on the
quickest machines;
• Since Atlas is CPU-based, no precompiled binaries should be available: at
best, they will be suboptimal; at worse, they could contain unknown
instructions old CPUs would crash on.
For all these reasons, I’m convinced that pulling the plug on Atlas is a good
idea. Any thoughts?
Can all of the ports that currently depend on atlas be made to work correctly
without atlas? If so, that would probably be the first step. You can't remove
atlas while other ports depend on it.
DSDP
R
esmf
gr-specest
itpp
levmar
lua-numlua
nco
psfex
py-numpy
py-scipy
scamp
shogun
shogun-devel
source-extractor
stimfit
sundials
sundials2
That's an incomplete list. For example:
MacPro:~ fw$ port installed $(port dependents atlas | awk '{print $1}')
The following ports are currently installed:
arpack @3.7.0_0+atlas+gfortran (active)
qrupdate @1.1.2_6+atlas+gcc48 (active)
SuiteSparse_SPQR @2.0.8_0+atlas
SuiteSparse_SPQR @2.0.9_0+atlas
SuiteSparse_SPQR @2.0.9_1+atlas (active)
I believe all three of those ports have alternative variants with similar
functionality, but one has to be careful to distinguish such cases from
cases where atlas is the only means of providing its functionality.
Fred Wright
Poisoned Savannah Mirror List
I was attempting to install gpsd (prior to an update for the new version), and ran afoul of this: ---> Fetching distfiles for gpsd ---> Attempting to fetch gpsd-3.20.tar.gz from http://babyname.tips/mirrors/nongnu/gpsd ---> Verifying checksums for gpsd Error: Checksum (rmd160) mismatch for gpsd-3.20.tar.gz Error: Checksum (sha256) mismatch for gpsd-3.20.tar.gz Error: Checksum (size) mismatch for gpsd-3.20.tar.gz *** The non-matching file appears to be HTML. See this page for possible reasons for the checksum mismatch: <https://trac.macports.org/wiki/MisbehavingServers> *** I don't know how "babyname.tips" got into the mirror list, since the name suggests that it's completely inappropriate, but it seems to have been there for almost three years, due to commit 49ffee556c1a. Perhaps that's been benign until recently, but now viewing that directory gives: babyname.tips is for sale on GoDaddy Auctions. Click here for more details. And a bunch of other crap. Making it worse is that MacPorts questions it based on its being HTML, but stores it anyway, doesn't attempt to fetch it from any other mirrors, and doesn't attempt another fetch unless you remove it (even though it was renamed). Hence, it completely blocks a successful distfile fetch (unless one does it manually). There are also quite a lot of other discrepancies between the current Savannah mirror list in mirror_sites.tcl and the one published at: https://download-mirror.savannah.gnu.org/releases/00_MIRRORS.txt Fred Wright
Re: port "cask" -- installing prebuilt binaries
On Wed, 29 Jul 2020, Daniel J. Luke wrote: On Jul 29, 2020, at 9:30 PM, Fred Wright wrote: [...] Personally, I'd prefer the MacPorts approach if it were less stingy with the binary archives. Ideally, one should be *able* to build from source, but not be *required* to do so. How is it stingy? We have binary archives for everything that the buildbots can build that the licenses allow us to distribute, right? Aside from the usual issues with non-default variants and certain old OS versions, the main problem seems to be what appears to be an overly strict interpretation of "distributable". As a random example, consider ffmpeg. The license for ffmpeg shows as GPL-2+. Although GPL prohibits binary-only distributions at the "meta level", it does *not* demand that sources be bundled with the binaries. It simply says that if they're not, there has to be clear information available to the user on how to obtain the sources. It doesn't even demand a working build procedure, just the sources. It might get a bit fuzzy in cases where the sources are patched, in which case it's not 100% clear that providing the original source plus the patches is adequate, or whether it's necessary to provide the actual patched sources (though the two are certainly morally equivalent), but in any case, MacPorts clearly does both. Anyone can get the upstream source archive(s) via "port fetch", get the sources in tree form via "port extract", and get the patched sources via "port patch". I don't see how this fails to meet the GPL requirements for any MacPorts user. Now if one were to be really paranoid, one might consider that providing binaries on servers that are accessible by means other than MacPorts could constitute a GPL violation, due to not having the "clear path to sources" that MacPorts provides. But if that's a concern, it could be easily addressed by including a README.sources file in every directory on the archive servers, either pointing to the corresponding source on a distfile mirror (or directly upstream if necessary), or perhaps just pointing to the MacPorts homepage. And to pick a random sub-example, Debian offers ffmpeg as a binary package. port, by default, will use the binary archives unless you tell it to build from source instead. BTW, on an only mildly related note, I've seen a number of cases lately where it successfully fetches a binary archive and than fails to fetch the corresponding checksum file. It seems that it gets only one chance to do this, and only from the same mirror where it fetched the archive. It's become common for me to need a "cleanup pass" after doing "upgrade outdated" across my VMs, where I manually retry the failed upgrades. On Tue, 4 Aug 2020, Ruben Di Battista wrote: There's is one compelling need for having "binary only" install, and that is for the port "osxfuse", that is currently broken for 10.14+. There was a discussion about it on the Github project about the choice of making it close closed source... Nonetheless it would be useful to have it in order to provide things like fuse file systems and so on. Hmm, I hadn't heard about that, but I don't run 10.14+ other than for testing. I was involved in fixing some osxfuse bugs right around the time that 10.10 came out, making kext signature checking mandatory. On 10.9, it warns you about an unsigned kext, but you can tell it to proceed. The fix at the time (for the relevant OS versions) was to have MacPorts fetch the binary distribution and extract the signed prebuilt kext from it, while building the rest from sources. This is done starting with 10.9, to avoid the dialog box, even though it's not strictly necessary until 10.10+. It sounds like some more tightening of the security noose has caused additional problems for osxfuse. On Tue, 4 Aug 2020, Ruben Di Battista wrote: 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). Huh? Are you suggesting *disallowing* the use of precompiled binaries? That would be crazy. The amount of both human and computer time that's wasted rebuilding the same binaries from the same sources with the same options is humongous. Another thing that's often overlooked is that installing precompiled binaries, especially when signed, is more secure than building from sources. This is because the attack surface of the tools required to install binaries is far smaller than the attack surface of the toolchains needed to build them. If you think this is purely hypothetical, consider the early Unix hack that implemented a backdoor that didn't appear in any source code. One of the reasons I chose Macports for is the fact it builds its own tree from source and it ships basically open source only software. Anyone is
Re: port "cask" -- installing prebuilt binaries
On Wed, 29 Jul 2020, Ken Cunningham wrote: there seems to be demand for replicating the “binary only” installers of homebrew cask. we have a few ports that do that now, and I see more and more coming in. From the user's perspective, how does that differ from a port that's available as a binary archive? I presume the idea is that it directly uses a precompiled binary from the upstream source, but from the user's perspective, does it really matter whether it was a binary from upstream or a binary from the buildbots? Or is this for ports where upstream doesn't provide source at all? Personally, I'd prefer the MacPorts approach if it were less stingy with the binary archives. Ideally, one should be *able* to build from source, but not be *required* to do so. Fred Wright
Re: Distfile Mirror Issues
On Wed, 29 Jul 2020, Ryan Schmidt wrote: On Jul 28, 2020, at 20:29, Ryan Schmidt wrote: I'll ask them if they want to enable older algorithms or allow non-https access. If they want to do neither, I'll configure MacPorts to remove that mirror on OS versions that can't connect to it. They've reinstated old ciphers so now it'll work back to Mac OS X 10.6. I'll get master_sites.tcl and archive_sites.tcl updated to pick this and other mirrors only on compatible OS versions. I'm not sure that's important, since the SSL-related failures are fairly quick, and having to maintain a compatibility du jour list for mirrors versus OS versions is just an added hassle. The mirrors that are actually down are more annoying, since that involves timeouts, but that's not something that one would expect to be reflected in a list (except for permanent decommisioning). Fred Wright
Re: Distfile Mirror Issues
On Tue, 28 Jul 2020, Ryan Schmidt wrote: On Jul 27, 2020, at 18:27, Fred Wright wrote: [...] DEBUG: Fetching distfile failed: Unknown SSL protocol error in connection to jnb.za.distfiles.macports.org:-9824 It appears they've enabled mandatory SSL on this server, which they weren't doing before. They've forgotten to add the MacPorts hostnames to the SSL certificate, so we can't connect. I've asked them to add those hostnames. When I use their hostname I'm able to connect using /usr/bin/curl on OS X 10.11 and later but not 10.10 and earlier. This is probably related to which encryption algorithms they've decided to support. Which macOS version were you using? I normally use 10.9 (though I have many other versions for testing). That sometimes has issues as discussed in: https://trac.macports.org/ticket/51516 But I thought the idea was that MacPorts' own mirrors should be configured to be compatible with all OS versions that it supports, which is why the compatibility issue usually only arises in connection with port development (before the disfiles have been mirrored). Fred Wright
Distfile Mirror Issues
While investigating the distfile fetch problem with the util-linux port, I noticed that a couple of the mirrors seem to be misbehaving in ways unrelated to the missing file: DEBUG: Fetching distfile failed: Unknown SSL protocol error in connection to jnb.za.distfiles.macports.org:-9824 DEBUG: Fetching distfile failed: Failed connect to nou.nc.distfiles.macports.org:80; Operation now in progress The other mirrors report the expected 404. Fred Wright
Re: Unable to authorize MacPorts Trac for GitHub auth
On Fri, 24 Jul 2020, Jason Liu wrote: It worked when I tried using a different browser. Apparently GitHub doesn't like the version of Safari that I was using. Did it give an "unsupported browser" warning? I get that all the time with Chrome 67 (the last version for 10.9). Most sites that complain still work fine, but some things on GitHub actually don't work, including some of the PR features. I have to switch to Firefox in such cases. Fred Wright
Re: Big Sur will be both 10.16 and 11.0
On Tue, 21 Jul 2020, Herby G wrote: Not sure if this has been posted previously or elsewhere, but as the title says: https://eclecticlight.co/2020/07/21/big-sur-is-both-10-16-and-11-0-its-official/ This is bizarre. The numeric version appears in the system itself, in /System/Library/CoreServices/SystemVersion.plist. Will SYSTEM_VERSION_COMPAT somehow mangle the file contents? Maybe it should have been code-named "Spinal Tap". :-) Fred Wright
Re: several messages
h files and when. Yes, the basic problem is that older includes don't have the newer definitions. So in general, if you want to support a wide range of OS versions, it's best to stick to the numeric constants. Question 3: As you can see from the attached file, I am currently creating a wrapper for AppKit.h. However, in the projects that I'm trying to package for MacPorts, their code usually uses '#include '; and the system Cocoa.h, in turn, has a '#import '. Is this going to be a problem? Is the MacPorts legacy support package able to intervene and insert its wrapper files even if a project's source code doesn't directly #include/#import that specific header file, but instead, the header to be patched is nested somewhere inside a tree/chain of header #includes? This will be — something new. Nobody actually knows how well this will work. It's also worth noting that this particular kind of fix probably only needs include additions and no library additions, which is something the PortGroup may not be set up to handle. Of course some ports may need the added library for *other* reasons, and that needs to be handled correctly. It probably might best be something optionally used rather than a default in legacysupport, as the opportunity for unexpected wreckage seems high. On the other hand, after year or so, if it helps but doesn’t break things, it might be defaultable. If a year or so sounds long, don’t worry. I wrote up the first version of legacysupport as “SnowLeopardFixes” in 2016, and it did not get really adopted until several years later, after a great deal of discussion. There are still many opinions that it should not be used, and the issues / fixes sent upstream instead, but I think we’re all coming to realize that something like legacysupprt is the only way forward if we’re going to support older systems. In general, direct upstream support seems preferable when possible, but some upstream developers refuse to support old OS versions, sometimes using "security" as a lame justification. Fred Wright
Re: shellescape proc
On Sun, 28 Jun 2020, Ryan Schmidt wrote: On Jun 27, 2020, at 23:18, Fred Wright wrote: On Fri, 26 Jun 2020, Ryan Schmidt wrote: [...] Looks like neither shellescape nor quotemeta are documented in the guide. Perhaps with good reason: MacML @21:03:49.192:: Error: Failed to extract curl-ca-bundle: invalid command name "shellescape" Whoops, didn't realize that it had only just been made available in the not yet released MacPorts 2.7.0 for Portfiles to use. Fixed: https://github.com/macports/macports-ports/commit/6c5276d315e64e99f0a7e57b6cf9940b83e9eab6 This happens on 10.5, 10.8, and 10.12. The missing binary archives are consistent with this. That's unrelated. Actually, it probably is related, though for a different reason than I was suggesting. :-) Presumably the only reason that the upgrade didn't fail for the other OS versions was because of the availability of the binary archives. The fact that those existed suggests that the buildbots are running with a prerelease version of base, which is why they worked (except when the buildbots weren't working for other reasons). I'm not convinced that using a prerelease version of base on the buildbots is a good idea, though. What would make more sense is to have CI jobs covering both the prerelease and release versions, but to stick to the release version on the buildbots for maximum consistency with what end users would see. Fred Wright
Re: shellescape proc
On Fri, 26 Jun 2020, Ryan Schmidt wrote: Somehow I missed that we have a shellescape proc. This is very exciting! I've wanted this function for a long time, and I'm just realizing now that it exists and that we've had it for 6 years. https://github.com/macports/macports-base/commit/494a1feafa2ad46c66f9714b760fb5b50ff5dd48 Thank you, Clemens! We should be using this everywhere, such as in portextract.tcl. It looks like it is available for use in portfiles too. Portfiles should switch to using this when specifying filenames or paths in a system call instead of manually quoting them with 'quotes' (or, more usually, not doing anything). Looks like neither shellescape nor quotemeta are documented in the guide. Perhaps with good reason: MacML @21:03:49.192:: Error: Failed to extract curl-ca-bundle: invalid command name "shellescape" This happens on 10.5, 10.8, and 10.12. The missing binary archives are consistent with this. Fred Wright
Re: problem with linking openssl for mailsend
On Wed, 17 Jun 2020, Ryan Schmidt wrote: On Jun 17, 2020, at 17:15, macpo...@parvis.nl wrote: my development machine is a macmini. the harddisk failed, so i restored time machine to a new disk. Did you try recovering the disk contents with ddrescue? but, the time machine backup (using directory hardlinks) had many missing directories, so most of my development is gone forever. so it seems i cannot trust time machine, any suggestions are welcome ;-) Sorry to hear that... Time machine does indeed use hard links but that's an implementation detail that you probably aren't supposed to need to know or care about. If you lost data that you thought was backed up to time machine, I hope you'll send feedback about your experience to Apple. https://feedbackassistant.apple.com Which will probably get a "working as intended". TimeMachine has always secretly excluded certain "system" directories from backups, with no GUI option to change that behavior. Somewhere along the line, I found out about this, resulting my adding the following to its preferences file: MacPro:~ fw$ plutil -p /Library/Preferences/com.apple.TimeMachine.plist [...] "IncludeByPath" => [ 0 => "/Applications" 1 => "/Developer" 2 => "/Library" 3 => "/System" 4 => "/bin" 5 => "/private" 6 => "/sbin" 7 => "/usr" ] [...] Note that this is for 10.9. Fred Wright
Re: make xorg-server a dependency of x11 ports?
On Thu, 21 May 2020, Ken Cunningham wrote: On Wed, 20 May 2020, Ken Cunningham wrote: > /i was imagining just one key port — gtk, or some other always installed > />/required supporting lib — would do the test. / I don't think gtk is remotely close to being an always-required lib for X11 apps. Fred Wright Fill in your fav then, with your extensive x11 experience. If there is no such library, well then, let's move on. I suspect that there is, but that it's provided by the system rather than by a port. New users can segfault, and let them sort it out. It's a litmus test I suppose, to see if they are worthy. Another issue is that an X11 app could be installed purely for remote use over an X11 connection from another machine. In that case, the server wouldn't be needed at all. Again, a warning note would be OK, but not a hard dependency. Fred Wright
Re: make xorg-server a dependency of x11 ports?
On Wed, 20 May 2020, Ryan Schmidt wrote: On May 20, 2020, at 21:09, Fred Wright wrote: Just because XQuartz is "out of date" doesn't mean that it might not be adequate in many cases, and I've found that switching from one X11 to another involves wrestling with some poorly documented configuration stuff, sometimes unsuccessfully. So forcing someone who already has XQuartz (or Apple's X11, for that matter) installed and working to switch to the MacPorts xorg-server could inflict unnecessary pain. XQuartz and xorg-server are the same software, maintained until a few years ago by the same person. He has become unavailable due to other commitments and has stopped updating XQuartz and contributing to MacPorts. Someone else has taken over keeping the MacPorts ports updated. But they are the same software and should require no different configuration. I found my notes on switching. What I'd found, by trial and error (not documentation), is that switching requires using some launchctl commands to switch the startx.plist, and it's necessary to reboot since logging out and logging in is insufficient (in spite of the classification as an "agent" rather than a "daemon"). And that procedure didn't work on the PowerBook, so there I wound up going back to XQuartz just to have a working X11. Apple's X11 only exists on Mac OS X 10.6 and earlier so it's not very interesting to talk about at this point. Well, some of us run old systems for testing. :-) And I believe Apple's X11 was provided at least as late as 10.7 as well. "could not open display" is a pretty normal error for an X11 app to give when it can't find the X11 server. I don't see an entry in our FAQ wiki page for this error. We could add one that tells the user how to install and set up the xorg-server port. That's also the error that one gets when there's a perfectly good X11 server installed but DISPLAY isn't set appropriately, so a distinction needs to be made between those cases. I've also seen a case where a missing DISPLAY results in a segfault from Gtk. macOS sets DISPLAY properly for you, ever since Mac OS X 10.5. So talking about a misconfigured DISPLAY isn't very interesting either; it would take a concerted effort on the user's part to deliberately set a wrong value. I assure you that I hadn't engaged in any "concerted effort" to screw myself when I got burned by this issue. And there was a time when it mattered whether one was launching from xterm or Terminal, though that discrepancy seems to have disappeared for no known reason. The best approach might be simply to have a conditional port note in any X11 app, that checks to see whether *some* X11 server is present, and gives a warning with an installation suggestion if not. What I'm trying to avoid is having to add boilerplate code to hundreds of ports. So I guess that means yet another portgroup to do this. But Sure - doing it in a PortGroup makes sense regardless of what it actually does. even that -- editing hundreds of possibly optionally X11-using portfiles to insert the inclusion of that portgroup only when X11 is actually going to be used -- is a big effort. Yup. And this peripherally relates to the +x11 vs. +quartz issue that shows up all over the place. At one point I started going down the rabbit hole of switching to +quartz as much as possible to minimize X11 dependencies, but that proved to be too much of a nightmare. On Wed, 20 May 2020, Ken Cunningham wrote: i was imagining just one key port — gtk, or some other always installed required supporting lib — would do the test. I don't think gtk is remotely close to being an always-required lib for X11 apps. Fred Wright
Re: make xorg-server a dependency of x11 ports?
On Wed, 20 May 2020, Ryan Schmidt wrote: On May 20, 2020, at 08:30, Ken Cunningham wrote: Should xorg-server should be made a dependency of some key x11 component, so that when people install an x11 application, xorg-server installs and it actually works for them “out-of-the-box”. For example, CherryTree is apparently a very popular gtk application, and there was some pressure for the past few years for a Mac version. I just stumbled across it recently — took about 15 minutes to write the Portfile (and a couple of minor edits after to get it completely right :>). But when people try "sudo port -v install cherrytree” it delivers a broken installation due to no xorg-server (see below). It’s one more step to go back and explain how to install the server, but really, as XQuartz.app is really out of date now, and MacOS no longer comes with any X11 window server, I think we could just make our xorg-server a dependency of some key part and have it installed automatically. Otherwise, it seems like just one more needless headache for people that they should not have to worry about, and we’re all about making this work “out of the box” for people, right? — or we should be, if we want to recruit keep users. Just because XQuartz is "out of date" doesn't mean that it might not be adequate in many cases, and I've found that switching from one X11 to another involves wrestling with some poorly documented configuration stuff, sometimes unsuccessfully. So forcing someone who already has XQuartz (or Apple's X11, for that matter) installed and working to switch to the MacPorts xorg-server could inflict unnecessary pain. Ken — example of cryptic error without xorg-server installed, gives people no clue what is wrong. = So I've tried to run this using port myself and get the following error: phillips321@Mac13:~$ cherrytree /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gtk-2.0/gtk/__init__.py:57: GtkWarning: could not open display "could not open display" is a pretty normal error for an X11 app to give when it can't find the X11 server. I don't see an entry in our FAQ wiki page for this error. We could add one that tells the user how to install and set up the xorg-server port. That's also the error that one gets when there's a perfectly good X11 server installed but DISPLAY isn't set appropriately, so a distinction needs to be made between those cases. I've also seen a case where a missing DISPLAY results in a segfault from Gtk. The best approach might be simply to have a conditional port note in any X11 app, that checks to see whether *some* X11 server is present, and gives a warning with an installation suggestion if not. Fred Wright
Re: new naming scheme for llvm/clang will cause wreckage fyi
On Mon, 20 Apr 2020, Ken Cunningham wrote: proposed new naming scheme for llvm & clang 10+ as prev discussed. explanation why in PR. Up to group, but will affect everything if it goes through. I'm fine either way, leave naming pattern as is or change it. Once in, no going back... see <https://trac.macports.org/ticket/60169> I thought that the naming scheme change involved how the version suffixing is handled, but I don't see how that relates to the ticket referenced here. Fred Wright
Re: [macports-ports] branch master updated: cmake: update to 3.17.1
On Tue, 14 Apr 2020, Frank Schima wrote: [...] -# Cmake is a depedency of clang +# CMake is a depedency of clang “dependency” is still spelled incorrectly here. :) [...] Was it really necessary to quote the entire 1400-line patch (3300 lines in the HTML version) just to point this out? Fred Wright
Re: How to set @macports up e-mail alias?
On Mon, 16 Mar 2020, Ryan Schmidt wrote: On Mar 15, 2020, at 21:22, Joshua Root wrote: On 2020-3-16 04:14 , Eric A. Borisch wrote: It's been a decade since I set it up previously, and we've moved over to GitHub Authentication in the interim. Any special directions for how to set up a committer's @macports.org <http://macports.org> account now? Are we talking about adding a new committer to the project, or an existing committer who doesn't have a working @macports.org email alias for some reason? If the former, they need to apply to PortMgr as documented at <https://guide.macports.org/chunked/project.membership.html>. If the latter, email and the infrastructure team should be able to help. Josh's answer is correct if you were asking about how to configure what email address your @macports.org alias forwards to. But if you were asking how to get Git to associate your commits with your @macports.org email address, then instructions for that are here: https://trac.macports.org/wiki/WorkingWithGit#setup And *those* instructions are probably not correct if you use git for anything other than MacPorts, assuming that you don't want to use your MacPorts alias for non-MacPorts uses. There are both global and per-repo settings in git. In the general case, one would use the per-repo settings for the MacPorts-related repo(s). It's the same commands without the --global, but while cd'ed to the relevant repo(s). Fred Wright
Re: gcc won't build i386 with our cctools assembler hack
On Wed, 4 Mar 2020, Ken Cunningham wrote:
On Tue, 25 Feb 2020, Ken Cunningham wrote:
building i386, gcc 5,6,7,8 misconfigures when our "as" redirects it to
clang for assembly, following our hack in cctools to do that. the gcc
build then fails.
I have not so far been able to overcome this other than:
1. deactivating all clangs 5+ prior to the build, to get the old gas
or
2. defaulting gcc to use --with-as=/usr/bin/as
Having the built gcc forever use /usr/bin/as as assembler would be
awful, so option 1 looks better than 2. but ugh.
I tried many things. gcc is complicated to build when you want it to do
non-standard stuff. There may be some way to make it work...pls chime
in...but I have likely tried it.
You don't make it clear whether this is solely about building gcc itself,
or about building things *with* gcc.
building gcc itself. I assume you have tried recently. It's been broken
since the cctools assembler hack went in, AFAICT.
Yes and no. My only i386 "machine" is my 10.5 VM, which currently has a
bunch of other broken ports. Except for that, I only build i386 when it's
universal, which tends to be an enormous rabbit hole in may cases.
The "forever" might just be "until there's a better solution", and it's
hard to see how option 2 would be more awful than creating yet another "X
can't build while Y is active" abomination.
If we build gcc to default to use /usr/bin/as then all those i386's are
forever sent to that truly ancient assembler. That is pretty awful --
who knows how many things will break doing that. It won't even accept
the -Q flag.
I'm puzzled. If this is solely about building gcc itself, doesn't that
mean that the iuse of /usr/bin/as is only inflicted on gcc itself? Or is
it something that would propagate to its targets? If so, does the gcc
bootstrap process include building gas, and if so, could it be hacked to
use /usr/bin/as to build gas and then gas for the real build?
If the concern is just for future gcc versions, then that could be in the
"cross that bridge when we come to it" category.
I don't know what this "cctools assembler hack is", but if that's breaking
the gcc build, it should probably be fixed not to. It's best if all ports
are fully Hippocratic ("first do no harm").
At least if we conflicts-build it, once it is built (a minor
inconvenience for the systems we're talking about, (10.4 i386, 10.5
i386, and 10.6 i386), it will use /opt/local/bin/as, which is current,
and also can redirect to clang for fancier assemblage (that usually
works still).
Unless precompiled binaries are offered for all variants, "once it is
built" will often be per-user in practice. It's getting to the point
where "upgrade outdated" needs an AI front end.
Fred, you might have built gcc once or twice I suspect.
More than I'd like to have. :-) Especially on slow machines. The last
upgrade of gcc7 on the PowerBook took about 15 hours.
Give an i386 build a try and see if you can come up with something. I
don't love this plan either.
On Fri, 6 Mar 2020, Ken Cunningham wrote:
I am discussing with the gcc darwin lead to see if any other options are
available.
Maybe that will help.
Fred Wright
Re: gcc won't build i386 with our cctools assembler hack
On Tue, 25 Feb 2020, Ken Cunningham wrote: building i386, gcc 5,6,7,8 misconfigures when our "as" redirects it to clang for assembly, following our hack in cctools to do that. the gcc build then fails. I have not so far been able to overcome this other than: 1. deactivating all clangs 5+ prior to the build, to get the old gas or 2. defaulting gcc to use --with-as=/usr/bin/as Having the built gcc forever use /usr/bin/as as assembler would be awful, so option 1 looks better than 2. but ugh. I tried many things. gcc is complicated to build when you want it to do non-standard stuff. There may be some way to make it work...pls chime in...but I have likely tried it. You don't make it clear whether this is solely about building gcc itself, or about building things *with* gcc. The "forever" might just be "until there's a better solution", and it's hard to see how option 2 would be more awful than creating yet another "X can't build while Y is active" abomination. Fred Wright
Re: Index Broken on 10.5
On Sun, 20 Oct 2019, Joshua Root wrote: On 2019-10-20 02:37 , Fred Wright wrote: Recently I've been seeing this on 10.5 (both x86 and ppc): MacXS:~ fw$ sudo port upgrade outdated Warning: No port clang-9.0 found in the index. Warning: No port llvm-3.7 found in the index. Warning: No port libcxx found in the index. Warning: No port clang_select found in the index. Warning: No port ld64 found in the index. Warning: No port perl5 found in the index. I thought the libc++ change in 2.6 wasn't being applied to 10.5, but the problem seems to be roughly coincident with the new base. Perhaps the index generator script was updated incorrectly? That's probably not actually the index being broken, but a circular dependency. See <https://trac.macports.org/ticket/59289>. The issue causing the circular dependency is that all the system compilers are blacklisted by whatever port you're building, and the compiler selection is falling back to macports-clang, which doesn't work out of the box on libstdc++ platforms. This should be fixed in MacPorts 2.6.2. <https://github.com/macports/macports-base/commit/48ec1123ad66a71d2ca4c1fe5fe51e7f210dc363> Will that also fix the problem where -p becomes an infinite loop in the presence of this error? Fred Wright
Index Broken on 10.5
Recently I've been seeing this on 10.5 (both x86 and ppc): MacXS:~ fw$ sudo port upgrade outdated Warning: No port clang-9.0 found in the index. Warning: No port llvm-3.7 found in the index. Warning: No port libcxx found in the index. Warning: No port clang_select found in the index. Warning: No port ld64 found in the index. Warning: No port perl5 found in the index. I thought the libc++ change in 2.6 wasn't being applied to 10.5, but the problem seems to be roughly coincident with the new base. Perhaps the index generator script was updated incorrectly? Fred Wright
Re: pymol crashing under Qt on Catalina
On Sun, 13 Oct 2019, Jack Howarth wrote: It seems one of the issues that have stymied progress there is that scons isn't python 3 compatible. https://github.com/SCons/scons/issues/3299 That issue seems to be about Python 3.8, not 3.x. SCons has been compatible with Python 3 since v3, though 3.0.0 had some rough edges. That being said, in general I'm not in favor of abandoning 2.7, since there's still lots of Python code in the world that doesn't work with Python 3. On Sun, Oct 13, 2019 at 9:31 AM Chris Jones wrote: [...] On 13 Oct 2019, at 1:52 pm, Jack Howarth wrote: The +python37 variant of pymol runs fine under its Qt interface on Catalina, however the stock +python27 variant crashes Qt as follows... Does pymol use any compiled Python extensions? If so, there are a couple of things to be aware of: 1) Python extensions need to be built against the same version of Python that they'll run with. I've seen symptoms ranging from ImportError to segfaults when one gets this wrong. This isn't just about the Python version. For example, I've seen segfaults resulting from switching between the MacPorts Python 2.7 and the Apple Python 2.7. 2) Python extensions need source-level differences between Python 2 and Python 3, though most likely getting this wrong would result in a build failure, not a runtime failure. Fred Wright
Re: Perl module Privileges::Drop Portfile Fails to Build on Azure
On Sun, 13 Oct 2019, Joshua Root wrote: On 2019-10-13 02:41 , Ryan Schmidt wrote: On Oct 12, 2019, at 10:20, Steven Smith wrote: I see that the build is trying to download CPAN stuff Add the needed dependencies so that that does not happen. It would be nice if we could somehow prevent that from happening like we do with python. Such as some way to make the non-interactive response "n" rather than "y": Install Module::Build now from CPAN? [y] y Fred Wright
Re: haskell 7 world -> moving to 8!
On Thu, 12 Sep 2019, Ken Cunningham wrote: On 2019-09-12, at 7:02 PM, Ken Cunningham wrote: ghc is only C code. Well, C code + haskell of course. Not c++ . It's primarily the c++ exception handling Darwin ABI issue with PPC llvm that limits releasing clang-5+ for PPC to the wild. At Google, C++ exceptions are considered unreliable enough to be completely forbidden, and that's on x86. Fred Wright
Screwy Fetch Behavior
A while back, I noticed that MacPorts was sometimes trying to fetch patch files from distfile mirrors. At the time, it only applied to some ports that I keep privately modified, so it was just in the "should look into this some time" category. But now it's biting me in attempting to update the ntpsec port. As usual, I started by just updating the version number in the Portfile and doing a "sudo port fetch" (to check the fetch and then check the signature on the resulting file). But it now (unsuccessfully) attempts to fetch the patchfile from the distfile mirrors, and then gives up without fetching the real distfile at all. I don't think base has changed since the last time I successfully did this, so perhaps there's something in the ports tree that changed the fetch behavior. I don't know if this only applies to locally modified portfiles or not, but even if it does, it blocks updating the port. What's causing this and how do I get around it? Fred Wright
Re: How to enforce a particular Python version during port build
On Sun, 1 Sep 2019, Clemens Lang wrote: On Sat, Aug 31, 2019 at 06:45:09PM -0700, Blair Zajac wrote: The problem could be scons. It looks like Re-iterating on that, the problem is likely SCons, because it will filter all environment variables and thus ignore any settings you do in configure.env, build.env, destroot.env, unless you patch the SConstruct file specifically to not remove them from its environment. True, but the only environment variable at issue was PATH, and changing that is almost never the right way to fix a port build problem, since it's best to decouple port builds from PATH as much as possible. I already suggested two possible alternatives in this case. Fred Wright
Re: How to enforce a particular Python version during port build
On Sat, 31 Aug 2019, Blair Zajac wrote: The problem could be scons. It looks like https://github.com/mongodb/mongo/blob/r4.2.0/SConstruct requires Python 3.5 but Scons runs against Python 2.7: $ head /opt/local/bin/scons #!/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 Well-designed build procedures allow the Python version to be specified distinctly from the SCons Python version. See if this build procedure has some sort of "target python" option. So try changing python.default_version in scons’ portfile and rebuilding it. Even if it's necessary to run SCons with the target Python to get around a dumb build procedure, there's no reason to alter the SCons installation. Just invoke SCons with the desired Python. I.e., instead of: scons use: $/bin/pythonX.Y scons Fred Wright
Re: Preparing for 2.6.0 beta
On Sat, 24 Aug 2019, Joshua Root wrote: I think we're pretty close to being ready to make a new stable branch and tag a beta. Clemens is going to make one more change related to Xcode checking; are there any other changes that really need to go in before the beta? Though I wouldn't call a 16-month-old ticket "urgent", it might be nice if someone could look at: https://trac.macports.org/ticket/56437 This might become more significant with the libcxx churn. Fred Wright
Re: New MacPorts ports database site
On Fri, 23 Aug 2019, Chris Jones wrote: On 23/08/2019 10:54 am, Dmitri Zaitsev wrote: I find the list of hundreds qt53-* with (nearly) identical description overwhelming and the grouping doesn't seem to work for them either. The breadcrumb numbers at the top give me no clue where to click next to skip that long list and 83 pages to click through feels quite frustrating :) I generally prefer infinite scrolls, where I can quickly scroll all the way down and then locate the keywords by search. There had been few ux designer blogs in the past in support of paginations, whose arguments I never understood, but they seem to be largely gone by now. I don't think making the number per page 'infinite' is a good idea, certainly not as the default/only option. What would be nice is to make the number per page, currently 100, selectable by the user. Perhaps then offer 'large number' as an option. But the default should be relatively small to prevent potential browser overloading I expect that what he was referring to is the arrangement that some websites use where the page is sized dynamically in response to scrolling. Though the naive implementation is nonfunctional if Javascript is disabled, which isn't ideal. Fred Wright
Re: accessing the notes of the active port version
On Tue, 16 Jul 2019, Clemens Lang wrote: On Tue, Jul 16, 2019 at 07:17:02PM +0200, Ren? J.V. Bertin wrote: This just came up: is there a quick way to get the notes for the active version of a port? $> port notes $portname This will use the notes from the current state of the ports tree. I don't think we have a simple way to use the notes from the Portfile stored when installing a port. Another problem (perhaps more easily fixed) is that if the notes are variant-dependent, then the notes reported by the above command will be based on the default variants rather than the active variants. To avoid this, one needs to determine the installed variants and then include them in the 'notes' command. Fred Wright
Re: Errors when changing cmake build directory
On Thu, 2 May 2019, Michael Dickens wrote: Why not leave the build directory alone & let the cmake 1.1 PG handle it? Most CMake-based ports can handle out-of-source building these days, and that's the default for the cmake 1.1 PG, and the default setting here should work for the vast majority of cmake-based ports. But note that CMake's own default is *not* to build out-of-source (with extra steps required when you want to), and not all projects build correctly out-of-source. So the PG default behavior is inconsistent with CMake itself, as well as just plain not working in some cases, and the poor discoverability of the option to change that (as well as the change in the default from 1.0) makes that default even more undesirable. Also note that the benefit of out-of-source builds is negligible in the MacPorts environment, anyway. Fred Wright
Re: GSoC 2019 [Collect build statistics]
On Sun, 24 Mar 2019, Mojca Miklavec wrote: On Sat, 23 Mar 2019 at 17:49, Craig Treleaven wrote: I see no reason to report inactive ports. Neither do I. I would remove those as I already mentioned in an earlier email. But in the spirit of lossless collection, those should be included and flagged as inactive, so that what to do with them can be decided later. There are different reasons for inactive ports. Sometimes they're just leftovers from upgrades without -u. But sometimes the user is intentionally keeping inactive ports, to permit switching fairly quickly via activate/deactivate, either to keep multiple variants or to keep conflicting ports. On Sun, 24 Mar 2019, Craig Treleaven wrote: I?m not familiar with the 2015 work. ?port? now returns zero for successful completion. Have we considered having port set a return code that indicates the general class of an unsuccessful operation? For example, we have 8 port phases defined (fetch through destroot). We could return -1 through -8 to indicate failure in a particular phase. More to the point, we could return a specific value for failures such as when active_variants determines that a required variant is not installed. Similarly, if the port is not supported on a particular OS configuration another specific code could be returned. I don?t contribute to base but that would seem to be a minimally invasive modification. Speaking of return codes, it's not very helpful that "upgrade outdated" returns error status if nothing is outdated. :-) Fred Wright
Re: Auto-Detection of Build Dependencies, Gsoc 2019
On Tue, 19 Mar 2019, Clemens Lang wrote: There are a couple of static rules (which wouldn't change for this task) and a dynamic component that checks which port installed the file that the installation is trying to access. At the moment, we allow requests if the currently built port depends on the port that provides the file and deny access otherwise. BTW, the current trace mode is riddled with false positives, so it's nowhere near being usable as authoritative information on dependencies. A lot of them might be explained by incorrect dependency analysis, though some are just silly, like complaining about "/opt". This is completely orthogonal to performance issues, of course. Fred Wright
Re: trying to understand the --no-exec activate option (on by default?)
On Thu, 29 Nov 2018, Ren? J.V. Bertin wrote: The default for this option should be OFF IMHO; there are also ports which do important things in the post-activate; the lldb ports remind the user that an executable needs to be code-signed for instance. Evidently this has to be done each time the port is (re)activated. In the particular case of code signing, would it be possible to do that in the post-destroot phase, so that the signature would remain across activations and deactivations, or does the signature mechanism defend against that (even though a verbatim copy of signed code should still be signed)? Fred Wright
Re: Issues with clock_gettime(CLOCK_REALTIME, ) pre macOS 10.13
riable-rate clock to standard units, it's necessary to know not only the current scale factor, but also the last time that the factor changed and what the correspondence was at that time. Since that information isn't provided, either the scale is actually constant or the API is deficient. Hopefully it's the former. My clock_gettime() replacement for ntpsec is defined directly in a header file as an inline function. Although it currently only supports CLOCK_REALTIME, it does include a switch() on the clock_id for extensibility. A significant advantage of the inline approach is that whenever the clock_id is a compile-time constant (as is almost always the case in real use cases), the optimizer can completely remove the switch() and degenerate into just the inline code needed (quite simple for CLOCK_REALTIME) in the relevant case. And of course it also avoids adding new link-time dependencies. Fred Wright
Re: RFC: Remove old Python versions
On Sun, 21 Oct 2018, Chih-Hsuan Yen wrote:
I'd like to remove old Python version - python{24,25,31,32,33}. I see no
ports depend on python{31,32,33} and no one maintains them, but those
ports are still kept for while. Is there a reason for not deleting them?
Some of us like to test Python code against as many versions as possible.
It's bad enough to have to maintain locally patched versions of a few
Python-related ports just to expand the version lists, without having the
Python versions themselves disappear.
My own philosophy is never to drop anything without a sound technical
reason, rather than just being "too old". If the same zeal for
eliminating Python versions were applied to OS versions, MacPorts wouldn't
run on anything older than 10.12.
Checking port dependents is inadequate, since it doesn't cover
"dependents" based on user interest. If one were to remove all ports
without dependents, and iterate, there would be no ports at all. :-)
Fred Wright
Re: [macports-ports] branch master updated: py-protobuf3: fix build on older systems
On Fri, 25 May 2018, Ryan Schmidt wrote:
> On May 25, 2018, at 11:04, Ken Cunningham wrote:
>
> > On 2018-05-25, at 8:38 AM, Ryan Schmidt wrote:
> >
> >> If this is supposed to help 10.6...
> >>
> >>
> >>> +@@ -197,6 +197,8 @@
> >>> + v = float('.'.join(v.split('.')[:2]))
> >>> + if v >= 10.12:
> >>> + extra_compile_args.append('-std=c++11')
> >>> ++extra_compile_args.append('@@MACPORTS_STDLIB@@')
> >>> ++extra_compile_args.append('@@MACPORTS_EXTRAARG@@')
> >>
> >> ...why is it inside an if statement that's for 10.12 and later?
> >
> >
> > Yeah, their logic for the test must be busted. My guess is that testing
> > for 10.12 passes everything 10.1 and above,
>
> Right.
>
> > but I defer to someone who can read python. Can you fix that v.float ()
> > business for them?
>
> I've never looked at this code before; I won't presume to know what the
> correct fix would be.
You don't want to use float() when the '.' is a delimiter rather than a
decimal point. Python is perfectly capable of comparing lists directly,
but:
1) The lengths of the lists matter, so you may need either padding or
truncation to make the comparison correct.
2) Comparing lists of strings uses a "naive" comparison of the elements.
If they're known to be purely numeric, that can be fixed with int().
In this particular case, you should be able to replace the first two
lines with:
if map(int, v.split('.')[:2]) >= [10, 12]:
Fred Wright
Re: Fixing a bunch of ocaml issues at once
On Sat, 18 Nov 2017, Perry E. Metzger wrote:
> So https://github.com/pmetzger/macports-ports/tree/ocaml-update
> has a bunch of fixes that bring the ocaml port up to 4.05, create a
> separate package for ocamlbuild (which was spun out of the main ocaml
> after the last version in macports), updates camlp4 and camlp5 as
> needed, fixes our very backrev findlib (without which you can't build
> a bunch of things), and as a sort of test, brings the coq port up to
> 8.7.0 (it was languishing) -- it builds fine with all these updates
> in place.
>
> My problem is that I didn't really know what I was doing and my
> commit messages on my ocaml-update branch are not really up to
> standard. I realized this when I tried doing a pull request and saw
> the form asked if they were.
>
> What should I do from here to get this stuff committed?
You can update the commit messages with interactive rebase (git rebase
-i), and then force-push the updated branch to your fork.
If you do a "git rebase -i master ocaml-update", it will put you in the
editor with a list of the new commits (in *forward* chronological order),
each prefixed by 'pick'. Replace 'pick' by 'reword' for any commit whose
message you want to update, then save and quit. It will then put you in
the editor for the first commit message to be updated. Update the text,
save, and quit, repeating for all the commits you flagged. Then
force-push the branch ("git push -f") to your fork.
If you only need to update the single most recent commit on the current
branch, you can just use "git commit --amend" instead of interactive
rebase.
There does seem to be a bug in GitHub related to this sort of thing,
though. Recently I created a pull request, and in the process noticed a
minor problem with the commit message. Since there's no 'Cancel' button
for PRs, I just closed the page. After updating and re-pushing the
commit, the PR page came up with the *old* commit message, presumably due
to some unwanted cacheing. I worked around it by going to the Compare
page and then using the PR button from there. Though I expect that
merging the PR would have used the correct commit message, and only the PR
text would have been incorrect.
Fred Wright
Re: Can anybody take a look at the buildbot?
On Mon, 1 May 2017, Leonardo Brondani Schenkel wrote: > Some time ago I submitted a new port (ntpsec) which failed to build on > pre-10.12 versions: > https://trac.macports.org/ticket/53928 > > I reported that to upstream and the conclusion from Eric S. Raymond was > that it's a buildbot problem: > https://gitlab.com/NTPsec/ntpsec/issues/261#note_27103442 It's not a buildbot problem. The clock_gettime()/clock_settime() fallback is completely broken, and thus ntpsec doesn't work on any OS that doesn't have those functions, including macOS <10.12. I have a fix for ntpsec which I haven't submitted yet since I haven't tested it as well as I'd like, but I'm in the middle of a major move right now and don't have time. Fred Wright
2.4.0 Annoyance
In doing a selfupdate followed by an upgrade outdated, I got this: [...] ---> Computing dependencies for wine The following dependencies will be installed: gstreamer1 gstreamer1-gst-plugins-base libpcap Continue? [Y/n]: [...] While asking about installing dependencies is a good thing in general, in this case the dependencies were already installed (which is probably almost always the case with "upgrade outdated"). In this case, the "upgrade" of the dependencies wasn't even due to new versions - it was just a change in the "universal" variants. Although asking before switching variants might make sense, in that case it should be more informative about what it's actually proposing to change. Fred Wright
Re: [macports-base] tag release_2_3_4 deleted (was d92ac26)
On Sun, 15 Jan 2017, Ryan Schmidt wrote: > > On Jan 15, 2017, at 07:22, Rainer Müller <rai...@macports.org> wrote: > > > > Rainer Müller (raimue) pushed a change to tag release_2_3_4 > > in repository macports-base. > > > > *** WARNING: tag release_2_3_4 was deleted! *** > > > > was d92ac26 merge https://trac.macports.org/changeset/140724 from > > trunk: 2.3.4 release date > > > > The revisions that were on this tag are still contained in > > other references; therefore, this change does not discard any commits > > from the repository. > > > > > What happened here? Probably the removal of a misnamed tag. > We still seem to have a "v2.3.4" tag in the repo like we should. But not a "release_2_3_4" tag. Fred Wright
Re: Central portindex'ing functional at the moment?
On Thu, 29 Dec 2016, [windows-1252] Marko Käning wrote: > On 29 Dec 2016, at 00:05 , Mojca Miklavec <mo...@macports.org> wrote: [...] > > Today I'm exercising a somewhat weird practice. I collect just a small > > number of symlinks to macports-ports from git in my local tree. I'm > > not too happy about this though, adding and removing symlinks is > > sometimes a bit annoying. > > I have the full clone with all ports. The initial portindex run takes ages, > subsequent > ones are then much faster. > > Yet, this makes my default rsync’ed port tree unusable, as the git-clone is > shadowing it > as a whole. > > I didn’t want to go for the symlink juggling… But then I seem to have to live > with the > fact that I can forget about > >$ sudo port selfupdate && sudo port upgrade outdated > > and rather always do a > >$ git pull upstream master && portindex && sudo port upgrade outdated I've been using the symlink approach, even in the subversion days. It just means having to create or remove a symlink whenever a given port changes between locally modified and not locally modified. It would probably be possible to create a script to manage the symlinks automatically, but it hasn't seemed worth the trouble. The local mods are all on a branch that can be trivially rebased except when there are actual conflicts. I'd never use "pull" as an update mechanism for this. With this approach, all content except the locally modified ports comes from rsync as usual, and the local portindex only contains the modified ports. The usual selfupdate/upgrade works fine, and mostly doesn't care whether the git repo is up to date. Fred Wright
