Re: Time to delete old PostgreSQL from MacPorts?
On Jul 12, 2024, at 4:54 PM, David Gilman wrote: > Is there any opposition to dropping all unsupported PostgreSQL > versions from MacPorts? That would be any version of PostgreSQL before > 12. Version 12 runs out of support later this year. I'm strongly in favor of removing versions that are no longer supported upstream. -- Daniel J. Luke
Re: CI are forcing tests for ports where tests are disabled
On Mar 12, 2024, at 12:20 PM, grey wrote: > But, I am guessing, it's either not that simple, or at a minimum, I > might need some additional insights into how to placate it. The test phase (like most other phases) doesn't run as root by default. When you run `port test` it's failing because it can't read ssh-keysign which has "-rws--x--x 1 root admin" permissions (so it /can't/ work). You can - stop setting 'tests.run yes' since that's the port advertising that 'port test' will work (and it doesn't), tell macports to run the test phase as root (test.asroot yes should work here, but when I did a quick test it didn't and I didn't have a chance to see why), or alter the openssh tests/build to not need to be run as root. -- Daniel J. Luke
Re: More classes of maintainer
To clarify - this was in the context of commits to base/ (That may or may not change your perception - but like I said, I didn’t measure and this is totally measurable). -- Daniel J. Luke > On Nov 5, 2023, at 1:26 PM, Perry E. Metzger wrote: > > >> On 11/4/23 02:42, Daniel J. Luke wrote: >> >> (Before we moved to github there were many people saying we'd get lots more >> commits by moving to it, but the volume doesn't seem much higher to me - of >> course, I also didn't measure before/after so my perception could be >> incorrect). > I think that's very, very wrong. There are vastly, vastly more community > submitted updates now, and they are easy to apply to the repository with low > effort on the part of the macports committers. It's been an unequivocal win. > > Perry > >
Re: Process (was Re: [macports-ports] branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms)
On Nov 2, 2023, at 9:17 PM, Perry E. Metzger wrote: > On 11/2/23 10:28, Daniel J. Luke wrote: >> On Nov 1, 2023, at 9:32 PM, Perry E. Metzger wrote: >>> As an aside, as it stands, the rules situation with closed maintainer / >>> open maintainer is kind of unpleasant already. For example, I'd like to be >>> able to indicate that I'm happy with anyone making reasonable changes to my >>> ports on their own without waiting three days for me, but there's no way to >>> do that, because "open maintainer" really means "three day timeout" just >>> like closed. >>> >> openmaintainer means that - but just for other committers. > That's not my understanding, though I could be wrong. Perhaps the exact > policy needs to be better documented? Probably, the guide says: "If a port's maintainer contains the address , this means that the author allows minor updates to the port by other committers without contacting them first. But permission should still be sought for major changes. Committers are expected to investigate as thoroughly as necessary to confirm that an update is in fact minor. Some projects have made quite major changes with only a tiny change to the version number. And of course a committer should always verify that a port not only builds but works correctly after a change, before pushing it. Pull requests for maintained ports should not be merged by anyone other than their creator or the port maintainer until the 72-hour timeout period has passed, even if the port is openmaintainer. This is because the change is either from a non-committer, or from a committer who could have just pushed the change directly, and by opening a PR is signalling a desire to have the change reviewed by the maintainer." So, I'm guessing the change you want to add here is to let committers vet non-committers proposed changes and merge PRs to openmaintainer ports? It doesn't seem unreasonable to me (but I've also moved most things to no longer have openmaintainer b/c of people changing things without pinging me at all about those changes). -- Daniel J. Luke
Re: More classes of maintainer
On Nov 2, 2023, at 9:26 PM, Perry E. Metzger wrote: > On 11/2/23 20:58, Rainer Müller wrote: >> Did the situation change since our assessment back then? As far as I am >> aware, there is still not a way to categorize GitHub Issues except with >> labels. How would we manage the ~4000 open tickets for ports with GitHub >> Issues? > > I think that much of what's changed in the last seven years has been people's > expectations and how people engage with open source projects hosted on > Github. It's clearly the case that moving tickets to Github would mean loss > of some information, but I think it would be far outweighed by the > improvement in engagement by the user community. I don't have an opinion here other than to say that without any testing, it's hard to know what will actually improve engagement. (Before we moved to github there were many people saying we'd get lots more commits by moving to it, but the volume doesn't seem much higher to me - of course, I also didn't measure before/after so my perception could be incorrect). -- Daniel J. Luke
Re: [macports-ports] branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms
On Nov 1, 2023, at 9:32 PM, Perry E. Metzger wrote: > As an aside, as it stands, the rules situation with closed maintainer / open > maintainer is kind of unpleasant already. For example, I'd like to be able to > indicate that I'm happy with anyone making reasonable changes to my ports on > their own without waiting three days for me, but there's no way to do that, > because "open maintainer" really means "three day timeout" just like closed. openmaintainer means that - but just for other committers. I don't think we want anyone to be able to commit anything to any openmaintainer port w/o review from a committer. (Maybe we need more committers or to be quicker in giving people commit, though). > It would be nice if we had some sort of larger set of gradations for what > people prefer, from "I handle all commits on this, period" to "if you have > commit access and want to help, don't ask, just do it." that's what openmaintainer means (with the exception of large changes changes) > As another aside, we also have a ton of ghost maintainers who never respond > but whose name being on the port means you have to ritualistically wait three > days for a reply you know will never come. Maybe we need an update to the port abandoned process (or some sort of positive checkin for maintainers to make sure they're still interested in maintaining a port)? -- Daniel J. Luke
Re: [macports-ports] branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms
Perry - I had not yet signed off on this PR. The port is not openmaintainer. Please refrain from making changes to non-openmaintainer ports without the maintainer's approval. > On Nov 1, 2023, at 12:48 PM, Christopher Chavez via macports-changes > wrote: > Perry E. Metzger (pmetzger) pushed a commit to branch master > in repository macports-ports. -- Daniel J. Luke
Re: call for Xcode15 Intel testers ?
On Oct 2, 2023, at 10:05 AM, Christopher Jones wrote: > Could I ask if anyone is running an Intel system, with Xcode 15 installed to > take a look at > > https://trac.macports.org/ticket/68322 > > and in particular report if they can build libgcc12 or not. The report there > is seemingly showing issues with the ‘ld -ld_classic’ workaround we are using > for the linker issues Xcode 15 has, which I don’t yet understand. I built it today and it built fine (I didn't do any testing to make sure it worked, though). -- Daniel J. Luke
Re: Update port reinstallation instruction on wiki
On Oct 2, 2023, at 5:58 PM, Joshua Root wrote: > If you understand the process well enough to evaluate the tradeoff of not > restoring quite all the state, you are not really the target audience for the > Migration instructions. If you don't mind dealing with the occasional problem > due to opportunistic use, you're free to simply run 'sudo port upgrade > outdated' after reinstalling base. FWIW, this is what I've done for the past several MacOS updates and the only problems I've run into have been ports that just fail to build on the new OS. YMMV (especially since the set of ports you care about is probably not the same as the set of ports I have installed), and I'm prepared to debug/fix any problems I see, but I find it much easier than the other options. -- Daniel J. Luke
Re: Revisiting the idea of "pinning" ports
On Oct 2, 2023, at 1:46 PM, Gregorio Litenstein wrote: > More than pinning per-se, I'm wonndering if it'd be feasible to add some > mechanism to opt-out from updates/rebuilds of outdated ports in some specific > cases. You can do this today by creating your own local (partial) portindex with the version of the port(s) you don't want to upgrade. See also /opt/local/etc/macports/sources.conf -- Daniel J. Luke
Re: Need Help with the "conflicts_build" PortGroup
The generic rule is "do not do this"
Ports are all intended to work with the current other ports as distributed by
MacPorts - when you install or upgrade a port MacPorts will walk the dependency
tree and install or upgrade all of the necessary things first, so your port can
assume the 'current' version of things it declares to be installed.
> On May 20, 2023, at 11:35 AM, Robert Kennedy wrote:
>
> It looks like I can tell whether a port is installed and get the version of a
> installed port in question via the MacPorts registry API. But I do not see
> any docs on how to use the MacPorts registry API in a Portfile.
>
> Once I know whether a port is installed and its version number, I should be
> able to use conflcts_build-append in a tcl block in the Portfile (e.g. in a
> pre-configure{} or pre-build{} block. pre-configure{} probably makes the
> most sense).
>
> Can someone point me to some docs on how to use the MacPorts registry API or
> to some example Portfiles?
>
> Rob
>
> From: macports-dev on behalf of
> Robert Kennedy
> Sent: May 20, 2023 9:47 AM
> To: macports-dev@lists.macports.org
> Subject: Need Help with the "conflicts_build" PortGroup
> I am upgrading a port where only certain installed releases will prevent the
> building of the upgraded port.
>
> Is there a way to use conflicts_build from the conflicts_build PortGroup with
> only certain installed releases? Maybe it could be done by using a pre-build
> {} tcl block?
>
> Is there a global variable available that is set to the installed version
> number?
> And is there an easy way to tell if a port is already installed before
> upgrading?
>
> Rob
--
Daniel J. Luke
Re: Checksum -s of apple-pki-bundle fetches from MacPorts, not Source
-s just tells port to not fetch the 'binary archives', it doesn't tell port to not use the macports distfile mirror. The files on the mirror will have a hash that matches the portfile, so they'll be the same as what the port maintainer downloaded from the master_sites (and the port command will validate this). If the problem is that upstream files changed but the version didn't change, you need to treat it like a stealth update - https://trac.macports.org/wiki/PortfileRecipes#stealth-updates > On Nov 13, 2022, at 5:53 AM, Steven Smith wrote: > I’ve updated this port locally, but port is still fetching the old file from > https://distfiles.macports.org/apple-pki-bundle, not the master_sites URL > specified in the Portfile. > > May I please get some help determining what is causing this issue? > > >> On Nov 12, 2022, at 8:06 AM, Steven Smith wrote: >> >> Re: https://trac.macports.org/ticket/66230 >> >> This issue is caused because port fetches an expired certificate from >> https://distfiles.macports.org/apple-pki-bundle, not source: >> >>> sudo port clean --all apple-pki-bundle >>> sudo port -s checksum apple-pki-bundle +additional_pki_bundle >>> +system_roots_keychain >>> … >>> ---> Attempting to fetch AppleISTCA2G1.cer from >>> https://distfiles.macports.org/apple-pki-bundle >> >> But I’m explicitly passing -s to the port command—download from source: >> >> What’s the fix to this? (Simple revbump?) And why don’t I detect it but the >> OP does? -- Daniel J. Luke
Re: Review a fix for OpenSSL3 CVE
I don't mind waiting a bit for the maintainer for this one (especially since it looks like it's already been approved and merged by the maintainer :) ), but the policy that allows waiving maintainer permission was intended to specifically cover security issues (ie. we discussed this when creating the policy and decided that point that says 'A critical port is broken that affects many users' covered security fixes to ports). > On Nov 1, 2022, at 2:15 PM, grey wrote: > > I think neverpanic tends to be pretty responsive? > > Moreover in the severity was downgraded from Critical to High between the > time the vulnerability was circulating through the grapevine until it > actually was disclosed. There are also no known exploits in the wild > thankfully. > > LibreSSL (which is what macOS ships in base) is also not vulnerable, neither > is OpenSSL1. > > Anyway, I agree it's important to get tested and merged, but I'm not sure if > it would be necessary to jump the gun of the maintainers? > > On Tue, Nov 1, 2022, 11:04 Kirill A. Korinsky via macports-dev > wrote: > Folks, > > OpenSSL team released a fix for found CVE: > https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/ > > May I ask someone to review a PR to fix this CVE? > > https://github.com/macports/macports-ports/pull/16545 > > I think that this CVE should be a reason to merge such PR ASAP without > maintainers confirmation. -- Daniel J. Luke
Re: having the "+test" or "+tests" variant propagate causes unexpected builds
On Oct 30, 2022, at 11:42 PM, Ken Cunningham wrote: > I wonder if there was consideration given way-back-when to the idea of having > NO propagation of variants at all. It was an intentional design. > Anything you wanted to apply to every port, you would put in variants.conf. > Otherwise, your variant applied to the port you were currently installing, > and that is it. The behavior predates variants.conf > To me — that makes quite a bit of sense, actually…might solve a lot of > problems. > > But I’m sure some scenario arises where it was needed. Maybe? We could probably figure out what depends on the current behavior and then decide whether to change it or not. Back in the beginning, we didn't really know how much to use or not use variants and over time we've (ab)used variants for a lot more than just enabling or disabling a set of features on a given port. -- Daniel J. Luke
Re: having the "+test" or "+tests" variant propagate causes unexpected builds
I have the same situation in a port I maintain. I would like to be able to specify pre/post phase actions inside a phase block (so when running ‘port test’ a pre-configure that does the necessary setup will run) I haven’t looked at base/ to see how I’d want to implement it, but I think the port files would look cleaner (and we wouldn’t need variant-specific magic), so complexity there seems worthwhile. -- Daniel J. Luke > On Oct 30, 2022, at 6:23 AM, Ryan Schmidt wrote: > > On Oct 28, 2022, at 21:33, Daniel J. Luke wrote: >> >> I don't think implementation difficulty is the barrier here - but that all >> variants should just have the same behavior. >> >> In my mind, the real problem is the need for +test variants, there should be >> a way to just use the test phase - and perhaps changes to base/ to enable >> that are a better option. > > In one of my ports that has a tests variant, the reason why the variant > exists is that the build system looks for certain test dependencies at > configure time. If they're not there, it doesn't build the test suite and > doesn't allow tests to be run later. I'm not sure how MacPorts could be > improved to handle that better in the absence of a tests variant. Would you > have MacPorts do the configuration in the configure phase, do the build in > the build phase, and then redo the configuration and build in the test phase? > Or would you suggest in this case that the test dependencies that are needed > at configure time should be added unconditionally, so that even users who > won't be running the tests need to install them? In my port's case the > dependencies are probably small and that wouldn't make much of a difference, > but I'm not sure it'll always be that way for all ports. > >
Re: having the "+test" or "+tests" variant propagate causes unexpected builds
Test dependencies exist already. MacPorts Guideguide.macports.org--Daniel J. LukeOn Oct 30, 2022, at 7:30 AM, Nils Breunese wrote:Maybe MacPorts could introduce the concept of ‘test dependencies’ (dependencies only required for running tests). I work with Apache Maven quite a bit, and apart from build and runtime dependencies (which MacPorts already distinguishes) it also supports declaring test scope dependencies, that don’t need to be installed until tests are actually run: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_ScopeNils.Op 30 okt. 2022 om 11:23 heeft Ryan Schmidt het volgende geschreven:On Oct 28, 2022, at 21:33, Daniel J. Luke wrote:I don't think implementation difficulty is the barrier here - but that all variants should just have the same behavior.In my mind, the real problem is the need for +test variants, there should be a way to just use the test phase - and perhaps changes to base/ to enable that are a better option.In one of my ports that has a tests variant, the reason why the variant exists is that the build system looks for certain test dependencies at configure time. If they're not there, it doesn't build the test suite and doesn't allow tests to be run later. I'm not sure how MacPorts could be improved to handle that better in the absence of a tests variant. Would you have MacPorts do the configuration in the configure phase, do the build in the build phase, and then redo the configuration and build in the test phase? Or would you suggest in this case that the test dependencies that are needed at configure time should be added unconditionally, so that even users who won't be running the tests need to install them? In my port's case the dependencies are probably small and that wouldn't make much of a difference, but I'm not sure it'll always be that way for all ports.
Re: having the "+test" or "+tests" variant propagate causes unexpected builds
I don't think implementation difficulty is the barrier here - but that all variants should just have the same behavior. In my mind, the real problem is the need for +test variants, there should be a way to just use the test phase - and perhaps changes to base/ to enable that are a better option. > On Oct 23, 2022, at 7:58 PM, Jason Liu wrote: > > My own personal opinion has been that +test/+tests and +debug, by default, > should not propagate through the chain of dependencies; and then perhaps > there might be some way to enable propagation (maybe with a command line > option?). > > However, if I recall correctly, all variants propagate through the dependency > chain, so it might be difficult to make certain variant keywords behave > differently? > > -- > Jason Liu > > > On Sun, Oct 23, 2022 at 1:58 PM Ken Cunningham > wrote: > Various ports implement a “test” or “tests” variant to allow extra features > and deps required for testing to be enabled. > > This variant, when requested, will propagate up the chain to all the ports, > however. There is no real use case where someone would desire the test/s > variant to propagate up. > > This generates needless builds, and often enables features people neither > need nor want, and then guarantees manual rebuilds, forever, of the involved > ports. > > I recently came back to a massive building project involving clang and llvm > when I was trying to build “mesa +tests”. Because clang-15 and llvm-15 also > have a “+tests” variant, and had not yet been installed, port was building > those (and possibly others) with the tests variant rather than use the > prebuilt binary. > > Of course I just aborted the huge llvm/clang-15 build, cleaned them up, and > installed them separately. But others would probably not know to do this. > > I had suggested a few years ago we might namespace the test/tests variants, > by having a convention that the portname be prepended to the test variant, to > be more specific and avoid this — but not a widely acceptable idea at that > time. So we’re still in the same situation… > > Is it possible that a “test” or “tests” variant might not be propagated up > the ports chain by base, instead? > > > K > > > > PS. A similar thing happens with “+debug” variants, another common variant > that you *usually* don’t want propagated up to *every single port* in the > chain either. > > This one is occasionally something that people would want up their chain, but > it is so fragile of a plan to rely on variant propagation (ie if you have the > port installed already, it won’t be reinstalled with the “+debug” variant), > that such rare users might best install each port they want to be installed > as “debug” do that specifically. Certainly most of us don’t want clang-15 > installed with it’s debug variant when you’re trying to debug some little > port. -- Daniel J. Luke
Re: Fastly Mirrors Throttled to 1 MB/sec?
On Jun 8, 2022, at 1:41 PM, Joshua Root wrote: > On 2022-6-9 03:12 , Daniel J. Luke wrote: >> is the origin server bandwidth constrained? > > The origin is nue.de.packages.macports.org, and fetching from there directly > is considerably faster (~5 MB/s for me, vs 948 kB/s going via the CDN when it > has to fetch from the origin). Presumably fastly is pulling from somewhere closer to it also. Looks like fastly doesn't have a push/preload/cdn file storage solution (they have support for a bunch of cloud storage providers) - but that's probably the next step if we needed it to be faster. and/or if we had other origin mirrors it could help (I'm not sure how fastly select which origin to pull from, but presumably if there was one in North America it would result in faster initial downloads to people in North America, for example). -- Daniel J. Luke
Re: Fastly Mirrors Throttled to 1 MB/sec?
FWIW on a first download I got 1.37MB/s over det-ix (packages.macports.org is .3ms away) and my home connection got 981KB/s (to a faslty server 6.8ms away, so probably in chicago - my home ISP breaks traceroute so it's a little harder to see what's happening). ... on a second download I got ~100MB/s (or just about the max of what my gige connection can do) from both locations.\ is the origin server bandwidth constrained? > On Jun 8, 2022, at 11:53 AM, Chris Jones wrote: > On 07/06/2022 3:09 pm, Joshua Root wrote: >> On 2022-6-7 21:43 , Christopher Nielsen wrote: >>>> On 2022-06-06-M, at 13:53, Joshua Root wrote: >>>> >>>> Try fetching the same file twice in a row. In my experience, the first >>>> fetch from a cold cache is quite slow, but once the local node has the >>>> file, it will saturate my connection. >>> >>> I’ve tried that numerous times over the past few months, but the behavior >>> is extremely consistent: The download speed is tightly throttled at exactly >>> 1 MB/sec, even after two or three back-to-back fetches. >> Well, that's clearly not the case for all ISPs and all Fastly POPs. More >> data is needed to know where the throttling is happening. > > Indeed, I for one see no evidence of any throttling > > > wget > > https://packages.macports.org/llvm-13/llvm-13-13.0.1_2.darwin_21.x86_64.tbz2 > > Gives me 39.3MB/s on my work network, and 8.5MB/s on my home ISP. > > Chris - I suspect the issue is more your end, or your ISP, than the servers > per se. > > cheers (another) Chris -- Daniel J. Luke
Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance
On May 24, 2022, at 3:56 PM, Ryan Schmidt wrote: > I wouldn't recommend anyone begin writing any code until it is discussed how > the feature should work. That should avoid spending time writing code that > won't work. sure, if someone were working on a feature it would be reasonable for them to discuss it here ... (but again, no on is). >> - but there are of course possibilities here. We could (ab)use epoch, > > epoch can't be used because epoch is not part of the archive filename, and > because it is within the portfile author's control when to change the epoch. then epoch can't ever be used for anything because it has the same 'fatal' problem (if I bump epoch in a port I maintain, and use a version + revision that there's already a package for ... I guess we tell people "don't do that" - but there's nothing preventing someone from doing it by mistake) >> just have portindex increment the revision for the ports that request to be >> rebuilt when a new version of something is added, > > How? The PortIndex file is generated by extracting certain information from > each port. Right now, an up-to-date PortIndex file contains the fact that > privoxy-pki-bundle has epoch 0, version 3.0.33, revision 3, because that's > what it said in the privoxy-pki-bundle Portfile when that PortIndex entry was > written. Suppose tomorrow I update curl-ca-bundle to a new version. By what > means is the portindex program supposed to know that now, it should record > revision 4 in the PortIndex file entry for privoxy-pki-bundle? If you are > suggesting that it should read the existing entry from the PortIndex file, > increment revision, and write it back, that won't work because it is valid to > delete the PortIndex file and regenerate it from scratch. Because it's impossible to change how portindex works? It's impossible to store any state other than state that's already stored? I'm purposely not writing up a comprehensive design here - since I've not volunteered to implement it and I don't think it's worthwhile to do an exhaustive feature design if no one is doing an implementation. (and also, if someone else decides to implement it, I don't want to constrain them since I haven't really dug into the details). I feel like the few times we've discussed this we talk past each other because I'm operating on the assumption that whoever implements a new feature isn't constrained in what parts of MacPorts they would modify while you appear to be focused on what would break with the smallest possible implementation (and by extension, why that feature isn't possible to implement). Fundamentally the current situation is that we have cases where this kind of dependency exists. We deal with it now by adding a comment + having a human do something. I'm just saying that software could be written to do the right thing here and I would welcome the automation. Implementation would, of course, take time and require consideration of all of the other pieces of MacPorts (and infra) that it touches. -- Daniel J. Luke
Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance
poch, version, revision) of deps that a port says it cares about [and countless others that would maybe take me more than 5 minutes to come up with ;-)] -- Daniel J. Luke
Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance
On May 23, 2022, at 4:59 PM, Steven Smith wrote: >> What has changed between the time that the buildbot built the package and >> the time that the user installs it? > > The certs in curl-ca-bundle are updated regularly to clear out expired certs. Does the existence of expired certs cause problems for privoxy (or does it just ignore them?) > Per the previous discussion, privoxy-pki-bundle uses these certs via a > depends_lib, and unless a port revision is added by hand, the port inevitably > will contain expired certs. > > The “solution” appears to be to bump the revision of privoxy-pki-bundle by > hand whenever curl-ca-bundle is updated. I’m trying to identify a more > automated and robust way of accomplishing that. There's not currently a more automated way of doing this in MacPorts, but there could be /or/ there might be another alternative. - MacPorts could grow a feature by which a port could specify that it needs to get rebuilt if something it depends on gets rebuilt (this would probably require another identifier along with epoch-version-revision or would require some magic behavior with one of the existing versioning numbers) - privoxy could be modified to be able to use the files as-installed by curl-ca-bundle - privoxy-pki-bundle could install a helper tool that can regen the files as needed when curl-ca-bundle files change - privoxy could be modified to use the MacOS Keychain and not need curl-ca-bundle ... there are probably other alternatives as well. So far, when people encounter this problem, there hasn't been enough motivation for anyone to build a MacPorts feature to support it (but I'd be happy to see one). -- Daniel J. Luke
Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance
On May 22, 2022, at 2:43 PM, Steven Smith wrote: > A standard install command grabs pre-built stuff from > https://packages.macports.org/privoxy-pki-bundle. This pre-built stuff is > inevitably stale because it inevitably contains expired certs. We want to > port to install stuff, just not pre-built expired stuff. We want the same epoch-version-revision of a port to always install the same things on everyone's system, though. > The desired behavior is to always install from “source,” i.e. the behavior > that goes with “port -s install” which always installs the latest up-to-date > PKI. The binary install should be the same as a locally built install. > How does one write a Portfile to prevent installs from being cached at > https://packages.macports.org/privoxy-pki-bundle ? I think you want to reconsider how this works / how you can get the end user behavior you want without having this port being a unique (and surprising) thing. -- Daniel J. Luke
Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance
On May 17, 2022, at 4:31 PM, Steven Smith wrote: >> Whenever the curl-ca-bundle port is updated to a new version, the >> privoxy-pki-bundle port's revision should be increased so that it rebuilds >> with the new bundle. > > Thank you. > > This is the part that I was hoping is automatic, without updating a revision: > the depends_lib would see that the “library” that the port depends upon has > been updated, and rebuilds itself because of the updated library dependency. > All without modification of the Portfile. > > I infer from your response that this isn’t how depends_lib works. Nope, there's no way (currently) to have a port declare that it needs to be rebuilt if a dependency is updated (it would be a really nice feature to add to base, though). -- Daniel J. Luke
revision control downloads (was Re: Codesigning everything and combatting malicious code)
On Mar 21, 2022, at 9:20 PM, Ryan Schmidt wrote: > Ports that fetch their sources from a revision control system do not enjoy > the protection of checksums. Although ports that fetch source from a revision > control system specify which tag or commit hash to fetch, it is conceivable > that a developer with sufficient access to that repository could delete an > old tag and replace it with a new tag of the same name that contains > different software. This is one of the reasons why we recommend ports fetch > using distfiles, and the vast majority do. We might consider recommending > that ports that fetch directly from a git repository (fetch.type git) never > use a tag, and always use the commit hash corresponding to that tag, since > replacing the contents of the repository while keeping the same sha1 hash is, > as far as I know, still impossible in the general case. (Yes, it is possible > to engineer a sha1 collision, but only if you can carefully control both the > old and new files. Generating a sha1 collision against some existing old file > is a very different matter.) I haven't reviewed the current literature but one thing is certain - attacks only get better. We should strongly discourage any use of revision control as the source. We could shorten the window where a person could get sources that don't match what the maintainer expected with a little infrastructure magic. Roughly in order of presumed level of effort: - provide a place for maintainers to manually upload distfiles that they can generate from a source checkout - provide some port command for maintainers to upload distfiles (as a convenience for the above upload process) - have a process that automatically generates distfiles from the checked out source and puts it on our mirrors (builder could probably do this since it's already going to check out the source), then have base look for the distfile on our mirrors first (even if the portfile specifies to check out from a revision control system) -- Daniel J. Luke
Re: python2.7 pip install fails with SSLError
On Mar 15, 2022, at 9:10 AM, Steven Smith wrote: > I haven’t been able to identify the correct incantation that will point pip > at a CA chain that avoids this issue, whether caused by an old LetsEncrypt > cert or some other old cert. > > For example, this command using --cert along with an up-to-date > curl-ca-bundle (that addresses the LetsEncrypt cert issue) fails with the > same error: > >> pip-2.7 install --cert /opt/local/etc/openssl/cert.pem -I --user setuptools IIRC pip will respect a CA bundle set in the REQUESTS_CA_BUNDLE environment variable. -- Daniel J. Luke
Re: OpenSSH 8.9p1 deprecated variants cleanup feedback request
On Mar 14, 2022, at 6:14 PM, grey wrote: > Thank you in advance for any wisdom you may be able to share on this issue! My suggestion previously was that the openssh port should just build upstream openssh + any patches that a maintainer wants to keep updated - since interest in forward-porting the gsskex and hpn patches always lags (significantly) new openssh releases. If people want slowly-updated versions of openssh with one (or both) of those patches, they can go in a different port so that the vast majority of users can get the current version of openssh and it can be maintained by someone who doesn't want/need/use those patches. -- Daniel J. Luke
Re: fetch phase: sourceforge with 302 redirects?
On Dec 16, 2021, at 4:24 PM, Jason Liu wrote: > I'm working on a new portfile that has its source stored on sourceforge. > MacPorts is having trouble obtaining the tarball, because apparently the > mirrors are pointing to the wrong file, and if I put the full URL into > `master_sites`, it's unable to find the tarball at all. It seems that > sourceforge is using 301 redirects to point to the actual file. If I use the > URL with a `curl -L`, the correct file downloads just fine. Is there any way > to get MacPorts to follow redirects during the fetch phase? If at all > possible, I'd like to avoid manually using curl through a `system` call, but > I suppose it could work as a last resort. Does this sourceforge example help? https://trac.macports.org/wiki/howto/AvoidRedirects -- Daniel J. Luke
Re: Question about `platforms` and `${os.platform}`
On Dec 11, 2021, at 7:42 PM, Jason Liu wrote:
> Actually, I find myself needing to use them more and more. For example, I now
> often have to check for macOS < 10.12, due to the large overhaul that
> happened in AppKit between 10.11 and 10.12. My workarounds for older versions
> of macOS are contained inside those `if {${os.major} <= 15}` conditionals.
Ideally you wouldn't have to use any (and the portfiles would all be
declarative) - that's not really possible now, but I think needing them is a
good indication of areas where we should enhance MacPorts base to make it
(eventually) possible to not need them.
For os.major stuff, I think there have been some proposals for range syntax,
just none have been implemented yet.
--
Daniel J. Luke
Re: incr revision / portindex
On Nov 5, 2021, at 3:42 AM, Ryan Schmidt wrote: > The bug is that MacPorts base does not recognize that a portindex was built > on a different OS version than the one that is currently running; that should > be fixed. Until we fix that base bug, I'd suggest we do the simple workaround of avoiding the behavior that triggers it. > Any number of other port differences can be OS version or arch specific. For > example, some ports may offer different port versions on different OS > versions or different OS archs as needed. Such ports would also be affected > by this problem. Specifically the version/revision being changed interacts poorly with 'port outdated' (causing these ports to always appear as if they are outdated) - other differences do not. -- Daniel J. Luke
Re: Warning: The macOS 12 SDK does not appear to be installed. Ports may not build correctly.
On Oct 30, 2021, at 5:25 PM, Nils Breunese wrote: > But I indeed don’t seem to have an SDK for macOS 12: > > So far I haven’t had any ports not building correctly. Is this a known issue? > Does it have a known solution? Yes - you can fix it by re-installing the command line tools: https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt (this happened to me on upgrade to macOS 12 as well). -- Daniel J. Luke
incr revision / portindex
Hi macports-dev, Looks like the change in 10aaad9b10e7350e76676ebdb5acfc950b800273 caused behavior I didn't expect on my Monterey system. Since I'm using a git checkout for my portfiles on that host and I was running darwin 20 when I did `port sync` after that change hit, my portindex had, for example 1.5.0_1 for zstd. After upgrading to Monterey, that means 'port outdated' thinks zstd is outdated, but trying to install it installs 1.5.0_0. (so `port outdated` still thinks it's outdated). Easy fix for me is to blow out my PortIndex and create a new one - but this is the first time I think I've ever had to do that when upgrading macOS. I'd suggest that we should avoid having platform (or variant) blocks change any of epoc,version,revision even in a case like this (when presumably that was done to avoid unnecessary rebuilds for some people). In any event - I thought I'd post, if for no other reason than to save someone some time if they also see this behavior. -- Daniel J. Luke
Re: upgrade to openssl 3.0.0
On Oct 4, 2021, at 12: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. I haven't chimed in here, but I think Ken's approach is the right one (and also matches what we've previously done pretty closely). I suspect if we wait, we'll just end up doing this same thing later - so might as well get it over with now. The sooner we get to a state where (mostly) things all work with the latest openssl, the better. -- Daniel J. Luke
Re: changing 'configure' options for testing
On Sep 20, 2021, at 10:20 AM, Daniel J. Luke wrote: > On Sep 20, 2021, at 8:15 AM, Frank Dean wrote: >> Daniel J. Luke writes: >>> The newest version of clamav uses cmake for builds. In the 'configure' >>> stage, I have it disabling tests because otherwise it won't build without >>> the test dependencies installed (check and pytest). >>> >>> Do we have a template or example of a canonical way to handle this? I don't >>> see an obvious hook for when someone is running `port test` to change >>> configure.args (I could, of course, add a post-extract/pre-configure and do >>> some non-declaritive test to see if `port test` is being run and use that >>> to branch - but that feels like a bad design choice). >> >> The rapidjson port implements a 'tests' variant to handle a similar >> situation. I used the same pattern for the libosmium port. The tests >> can then be run with `sudo port -d test current +tests`. > > That works, I guess. > > Is there interest in having base auto-add +tests if `port test` is called? (I > haven't looked at base/ code in a while, but it seems possible). I like to > imagine a future where we have enough infrastructure that we would run `port > test` for any ports that have test.run set. On this same train of thought - clamav tests run against the installed libraries (like some other ports tend to do) - in long-ago times I'd solve this by setting DYLD_LIBRARY_PATH - but since SIP started removing these that no longer works normally. I think trace mode has a(n elaborate) workaround where it copies binaries and executes the copies, but that doesn't seem like something I should implement in a portfile ;-) [This is another instance where if trace mode were the default, things would 'just work'] Has anyone else already solved this? -- Daniel J. Luke
Re: changing 'configure' options for testing
On Sep 20, 2021, at 8:15 AM, Frank Dean wrote: > Daniel J. Luke writes: >> The newest version of clamav uses cmake for builds. In the 'configure' >> stage, I have it disabling tests because otherwise it won't build without >> the test dependencies installed (check and pytest). >> >> Do we have a template or example of a canonical way to handle this? I don't >> see an obvious hook for when someone is running `port test` to change >> configure.args (I could, of course, add a post-extract/pre-configure and do >> some non-declaritive test to see if `port test` is being run and use that to >> branch - but that feels like a bad design choice). > > The rapidjson port implements a 'tests' variant to handle a similar > situation. I used the same pattern for the libosmium port. The tests > can then be run with `sudo port -d test current +tests`. That works, I guess. Is there interest in having base auto-add +tests if `port test` is called? (I haven't looked at base/ code in a while, but it seems possible). I like to imagine a future where we have enough infrastructure that we would run `port test` for any ports that have test.run set. -- Daniel J. Luke
changing 'configure' options for testing
The newest version of clamav uses cmake for builds. In the 'configure' stage, I have it disabling tests because otherwise it won't build without the test dependencies installed (check and pytest). Do we have a template or example of a canonical way to handle this? I don't see an obvious hook for when someone is running `port test` to change configure.args (I could, of course, add a post-extract/pre-configure and do some non-declaritive test to see if `port test` is being run and use that to branch - but that feels like a bad design choice). -- Daniel J. Luke
Re: perl and python version update
On Jun 2, 2021, at 3:29 AM, Ken Cunningham wrote: > Seems like a fine idea to me. Thing is, you actually don't want to be that > current anyway. In actual practice I don't think there's real benefit in waiting before upgrading to the newest released perl (I don't have as much practical experience with python, so maybe it's different for newly released python version). > The priority is on everything working, not newest/coolest -- so if the > designated perl or python is several years old, that is most likely perfect. > Nothing we need it for needs this week's versions, or this year's. Sure - but when things break because of a new version release, it's often easier to fix it right away rather than having to fix the last year's worth of changes in one batch (ie, do lots of small integrations rather than one big one). I agree that the priority should be on just having one working version, though. -- Daniel J. Luke
Re: perl and python version update
On Jun 1, 2021, at 4:25 PM, Ken Cunningham wrote: >> is there any overall strategy regarding the update of perl and python >> version as dependencies? >> > The basic idea was to be rational about things, so that end-users don’t need > many different perls and pythons installed just because, for example, someone > noticed a new perl came out last Tuesday and so changed their ports to that. > > The admins would set the “recommended” perl and python based on updates and > software conformance, and all ports would try to use that (unless some given > version would be the only version that would work). > > And then, en-masse, at the right moment the “recommended” version would > change, all the ports would more-or-less move to the new default at once, if > we could. > > How well this is working, whether it is working at all, and how well it is or > is not generally supported by the group I could not say. > > But it seemed like a good idea, when for example one needed to build and > install two or three perls and two or three pythons just to install git. For perl, we should just ship one perl as 'perl5' and have everything depend on it (and revbump the world of perl when we upgrade it). It takes us too long to migrate everything 'nicely' I suspect we could do this for python as well, but I've not looked recently at how disruptive newer python versions are. ... but I've said it before and people don't really like that idea, I guess :) -- Daniel J. Luke
Re: Protobuf3-cpp update woes; strategy to avoid broken dependent ports?
On May 21, 2021, at 8:38 AM, Joshua Root wrote: > If it's not actually doing anything that should break binary compatibility > (removing symbols or changing their semantics), the fix is to stop increasing > the library major version for binary compatible updates. If it is, there's no > getting around rev bumping all dependents. This is something that would be nice to expand macports base to handle more easily (although the details of the implementation might be annoying to deal with) - but we've managed for a /long/ time with rev-bumping all dependent ports. -- Daniel J. Luke
Re: Buildbot Performance
On May 17, 2021, at 2:03 AM, Ryan Schmidt wrote: > On May 16, 2021, at 17:57, Daniel J. Luke wrote: >> On May 16, 2021, at 10:48 AM, Christopher Nielsen wrote: >>> I’d bet the hypervisor is spending more time on scheduling and pre-emption, >>> than actual processing time. >> >> This is something we could actually measure, though, right? Then we don't >> have to just speculate (and if we do determine that a config change needs to >> happen, we can use the actual measurements to help us optimize the >> configuration). > > What would be your suggested methodology? I'm not an ESXi expert but after a quick look through some of their documentation it looks like there's an `esxtop` command that can show some information. More info here: https://kb.vmware.com/s/article/1005362 (some google searches seem to indicate that when the oversubscription is a problem, it's usually because ESXi is waiting for 'enough' cores to be available to start all of the vCPUs - and that this used to be much worse in older ESXi versions, but can still be a problem). This post also has information that looks useful: https://www.heroix.com/blog/vmware-vcpu-over-allocation/ -- Daniel J. Luke
Re: Buildbot Performance
On May 16, 2021, at 10:48 AM, Christopher Nielsen wrote: > I’d bet the hypervisor is spending more time on scheduling and pre-emption, > than actual processing time. This is something we could actually measure, though, right? Then we don't have to just speculate (and if we do determine that a config change needs to happen, we can use the actual measurements to help us optimize the configuration). -- Daniel J. Luke
Re: Ports updated without maintainer notification?
On May 8, 2021, at 3:48 PM, Jason Liu wrote: > As I said in the last message that I just sent, the risk of updating the > particular ports I mentioned are that they are dependencies for the blender > port, and might cause blender to fail. Every time I have updated those > libraries in the past, I have always made sure that the updated version > compiles against the blender port. Not only that, but I did run into one > instance where blender was compiling successfully against a newer version of > one of the libraries, but the Blender app was crashing during runtime > whenever I tried to render a project. Whether or not you decide to keep openmaintainer on the ports in question, it would be a good idea to make a note about this in a comment in the portfiles for those libraries so that anyone who decides to commit a change (openmaintainer/maintainer timeout/security update/mistake) is more likely to be aware of this. -- Daniel J. Luke
Re: What in MacPorts decides that files are 'broken'?
> On May 3, 2021, at 6:33 PM, Nils Breunese wrote: > I maintain the openjdk* ports. These ports install prebuilt x86_64 binaries > from AdoptOpenJDK. A MacPorts user with an M1 created > https://trac.macports.org/ticket/62802 to report that installing the > openjdk11 port on his machine makes rev-upgrade reports a couple of files in > this port as ‘broken’. I’ve asked the reporter to manually download the > prebuilt x86_64 tarball, and that seems to work fine on his M1 machine. > > I am not sure what MacPorts runs that decides these files are broken. Can > anyone tell me more about this? That's rev-upgrade, from the manpage (man 1 port-rev-upgrade): port rev-upgrade will check all binaries (i.e., executables and libraries) installed by MacPorts for consistency. If any linking problems such as missing or incompatible libraries are found, rev-upgrade will rebuild broken ports in an attempt to fix the problems. By default, rev-upgrade is run automatically after each installation or upgrade, unless you pass the --no-rev-upgrade option or disable this beahvior in macports.conf(5) using the revupgrade_autorun switch. -- Daniel J. Luke
Re: Updating OpenSSH port to 8.4p1
On Sep 30, 2020, at 1:55 PM, Blake Garner wrote: > I see that the port for OpenSSH has no maintainer and hasn't been updated in > a while. Reviewing the docs it looks reasonable for me to try and update the > port and submit it. Is anybody else already working on it? Advice for a > updating a port the first time beyond what's on the site? Updating the openssh port is easy if you only use the 'default' variants (I do that locally because I want to update sooner than MacPorts usually updates). Historically making the +hpn and +gsskex variants work has required effort. If you've got time+interest in making it work - please do so! -- Daniel J. Luke
Re: port "cask" -- installing prebuilt binaries
On Jul 29, 2020, at 9:30 PM, Fred Wright wrote: > 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. How is it stingy? We have binary archives for everything that the buildbots can build that the licenses allow us to distribute, right? port, by default, will use the binary archives unless you tell it to build from source instead. -- Daniel J. Luke
Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...
On Jun 22, 2020, at 11:20 PM, Ryan Schmidt wrote: > On Jun 22, 2020, at 14:34, Daniel J. Luke wrote: >> We should just have one perl5 port that tracks the current release. > > You say this every year (or at least often). I say this every time we run into the set of problems that we would solve by moving to this method (that we continually avoid solving just kicking the can down the road with the current solution - which is a huge amount of work that we just have to repeat every time there's a perl release). > Are you volunteering to be the one to ensure that every port that uses perl > is compatible with the new perl release when it comes out? Without someone to > do that, blindly upgrading everything from say perl 5.28 to 5.30 will likely > break ports. Every time we upgrade a library we 'blindly break ports' since we don't (and can't) comprehensively test every combination of things. It sounds like your argument against doing this is "we want the ports tree to be stable" which I don't think has been the case in the past (and if we /do/ want it to be a stable tree, we shouldn't be doing may of the updates that we do now). > Do you remember perl 5.26? It broke a lot of ports, requiring a lot of fixes > like this to be added: > https://github.com/macports/macports-ports/commit/454eb2b0608266ab7bdf51a82d690be0f97610fe I do, part of the pain with perl5.26 was that we waited a long time to update things because everyone was afraid of fixing the things that were broken. I'll note that upstream already does test CPAN modules with new versions of perl (and notifies their version of maintainers) - so the things that remain broken are things that aren't actively maintained upstream (and if they remain broken in our ports tree, aren't being actively maintained by us either). > The strategy currently being employed by those volunteers who are maintaining > the perl ports is to keep everything defaulted to 5.28 for now, add 5.30 > ports and fix problems in them as they're found, and once everything is > building then switch the default to 5.30. This seems sensible to me. Things get fixed faster when they're broken, I'd bet perl 7 (which is what perl5.32 is going to be) will be out before we're moved to perl5.30 (of course, perl 7 is going to break some backwards compatibility). I suspect the fundamental disagreement here is that I'm more comfortable with breaking things in the ports tree (and then fixing them) than you are. -- Daniel J. Luke
Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...
On Jun 22, 2020, at 10:59 AM, Ken Cunningham wrote: > Perhaps unavoidable in some cases, but if you look around the web, this is in > fact the #1 complaint about MacPorts: bloat. It's somewhat ironic given the current trend of everything being containerized (and bringing in all of their duplicate dependencies inside their containers)> > It might be an idea for the admins to "set" the perl version all ports will > use (barring some actual real need for another), and then --- all-at-once -- > change it to some new version to avoid this. > > And ideally we could look at changing it once every few years. We should just have one perl5 port that tracks the current release. We'd just need to either revbump everything that needs a rebuild when a new minor perl version comes out (all the p5- ports to start) OR some enhancement to base to make it so the revbump is unnecessary. We could keep the 'old' perl5s around - but I would suggest that it's not worthwhile. People who really need multiple versions of perl are better served by using perlbrew than any of the packagers. -- Daniel J. Luke
Re: Perl5 portgroup: 'make pure_install'
On Jun 16, 2020, at 4:18 PM, Ryan Schmidt wrote: > On Jun 15, 2020, at 08:36, Craig Treleaven wrote: >> Could someone help me understand the “pure_install” target used in the perl5 >> portgroup? In my new xmltv port, I noticed that some sample configuration >> files are excluded from pure_install that would otherwise be installed if >> the normal “install” target was used. Upstream has essentially said >> ‘everybody uses “install”, why aren’t you?’ >> >> I can’t seem to find any reference material on the intended difference >> between pure_install and install. Links welcome. >> >> Why does the perl5 portgroup default to pure_install over install? > > Looks like it's been that way ever since Toby added the portgroup in 2004. > > https://trac.macports.org/browser/trunk/base/src/port1.0/resources/group/perl5-1.0.tcl?rev=6127 > > Toby, do you remember why it uses pure_install and not install? presumably it was to avoid writing to perllocal.pod and then having to do something (like remove it from the destroot) before installing where they may already be a perllocal.pod file. -- Daniel J. Luke
Re: Call for designers for our ports website
Presumably we actually have more complete stats already if we were to aggregate the mirror logs for the distfiles + the binary archives. If we think having more data is valuable, we could add something to port (maybe display on selfupdate) asking people to opt-in. > On Jun 13, 2020, at 11:56 AM, Ken Cunningham > wrote: > No doubt it caused some tempest. > > I was wrong, homebrew’s published stats say they have 5 million openssl > installs this year <https://formulae.brew.sh/analytics/install/365d/> > > and our analytics say we have 547 > <https://ports.macports.org/port/openssl/stats?days=30_ago=0> > > And if you think that doesn’t drive everyone’s decision-making extremely > powerfully, I would say we are missing the marketing train. > > Here’s their blurb <https://docs.brew.sh/Analytics> about justifying it. > > Again, I know MacPorts is not going to change that (no point now). But from a > ‘business’ point of view, it was masterful. -- Daniel J. Luke
Re: How to handle ports that are still broken because of the icu upgrade
On Oct 23, 2019, at 9:58 AM, Ryan Schmidt wrote: > On Oct 23, 2019, at 08:56, Daniel J. Luke wrote: >> On Oct 22, 2019, at 9:49 PM, Ryan Schmidt wrote: >>> Or does the port use libxml2? If so, it may be using a bad method of >>> finding libxml2. One bad method of finding libxml2 is using the xml2-config >>> script. >> >> Should we just patch the xml2-config we distribute (and attempt to push >> those changes upstream) instead? http://www.xmlsoft.org/FAQ.html tells >> people to use xml2-config (so I suspect other upstream projects will be >> reluctant to include patches that switch from using xml2-config to >> pkg-config). > > That would break anything trying to build static libraries with it. :( It's probably less work to fix the (rare) use case of building static libraries than the (common) case of dynamic linking with libxml2 > We should push upstream to change the documentation to recommend pkg-config > and to explain the problems for dynamic linking when using xml2-config. Unfortunately, the libxml2 port doesn't have a maintainer - do we need a volunteer to contact them about this to try to get it updated? -- Daniel J. Luke
Re: How to handle ports that are still broken because of the icu upgrade
On Oct 22, 2019, at 9:49 PM, Ryan Schmidt wrote: > Or does the port use libxml2? If so, it may be using a bad method of finding > libxml2. One bad method of finding libxml2 is using the xml2-config script. Should we just patch the xml2-config we distribute (and attempt to push those changes upstream) instead? http://www.xmlsoft.org/FAQ.html tells people to use xml2-config (so I suspect other upstream projects will be reluctant to include patches that switch from using xml2-config to pkg-config). -- Daniel J. Luke
Re: Setting a build dependency for the JDK
On Sep 4, 2018, at 10:50 AM, m...@macports.org wrote: >> On Aug 31, 2018, at 8:32 PM, Guenael Strutt wrote: >> To build lang/processing, one needs a specific version of the JDK (as >> specified in >> https://github.com/processing/processing/blob/master/build/build.xml). >> Question: how does one create a dependency in the Portfile to determine >> whether this version is present? The purpose is to 1) provide a better error >> message to the user and 2) prevent builds from failing >> https://travis-ci.org/macports/macports-ports/builds/423195489 at every >> update. I tried checking for the existence of this folder: >> `/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/` but didn't get >> anywhere. Thanks! > > Have you looked at the java-1.0 portgroup? > > It is pretty simple and determines if the user has java installed and can set > the JAVA_HOME directory in the environment variables. > > It probably could be enhanced to determine the actual version and type (JRE > vs. JDK) of java installed. +1 It would be nice if it also installed a 'good' JRE/JDK or at least gave the user instructions on how/where to get it. > Otherwise, since Java is 3rd party, we cannot have a dependency on it and > expect that it will be installed by Macports. We can only check if it is > installed or not. I haven't looked at the oracle license recently, but if it allows it, we should be providing install via port so that the normal dependency resolution stuff can work. -- Daniel J. Luke
Re: Homebrew hacked
On Aug 8, 2018, at 5:12 PM, Dave Horsfall wrote: > On Wed, 8 Aug 2018, Perry E. Metzger wrote: >> BTW, in addition to these sorts of infrastructure issues, it might be a good >> idea if we were more expeditious and systematic about updating ports with >> known security holes. We might want a security officer role, too. > > Which FreeBSD has had for years (several peoole have been in that role), as > has OpenBSD (don't know about NetBSD; I have an image, but never used it in > anger as such). > > Good heavens, but is the Mac the only system that people use here? Volunteer project ... I don't think anyone has volunteered to wear that hat. (a long time ago, I was on a bunch of security-announce mailing lists and made sure to follow-up on any ports that looked like they needed patching, but I don't have free time to do that no - and the number of ports we have is /much/ larger). -- Daniel J. Luke
Re: Agility
On Apr 26, 2018, at 2:21 AM, Jan Stary <h...@stare.cz> wrote: > What are the top three Trac features > that Github issues don't have? This has been discussed on the mailing list several times already - you should probably search through the archives before demanding that someone take time and rehash this for you. (Then you can propose solutions / ask for clarification if things aren't clear). One very simple google search turns up the initial announcement (https://lists.macports.org/pipermail/macports-dev/2016-August/033405.html) where Ryan says: "We've given much thought to the way we use our Trac ticket system, and after extensive discussion on how we might be able to use GitHub Issues, and even performing a trial conversion of our tickets, we came to the realization that moving to GitHub Issues would be a step back for us. (GitHub Issues doesn't have custom fields, which we use to indicate the name of the port(s) affected by the ticket, and the available workarounds are unsatisfactory. And the original author of the ticket or comment cannot be preserved when importing to GitHub Issues. In short, converting to GitHub Issues would be lossy.) We also considered converting to Jira or BugZilla, but in the end, we decided that staying with Trac is the best and least disruptive choice for now. We will migrate the data from our Trac installation to a new server, taking the opportunity to upgrade to the latest version of Trac and make some other improvements." -- Daniel J. Luke
Re: MacPorts from behind proxy servers & fetching the file directly
On Mar 16, 2018, at 11:28 AM, db <iams...@gmail.com> wrote: > On 16 Mar 2018, at 16:03, "Daniel J. Luke" <dl...@geeklair.net> wrote: >> portfiles could in theory attempt to connect to any port, so a comprehensive >> list like you're asking for is probably not possible to create. > > But there could be one in practice, as there is infrastructure building all > ports. Ever upgraded outdated overnight to find in the morning that it > couldn't fetch a file? nope, but I'm not behind a firewall with stupid policy ;-) Most distfiles are available via http/s (there used to be a small number that only had ftp mirrors - but I stopped keeping track of that when we moved off of MacOS Forge and stopped using my proxy server for the distfiles mirror). There are some ports that (unwisely) also use various scm's to pull sources directly. This should be discouraged. -- Daniel J. Luke
Re: MacPorts from behind proxy servers & fetching the file directly
On Mar 16, 2018, at 8:45 AM, db <iams...@gmail.com> wrote: > Is there any list of ports used for installing base and **any other** port? portfiles could in theory attempt to connect to any port, so a comprehensive list like you're asking for is probably not possible to create. It might be worthwhile to look at switching our default port syncing to http (or run our rsync server on tcp/80). -- Daniel J. Luke
Re: elegant deps for a gtk theme?
On Feb 27, 2018, at 2:48 PM, Ken Cunningham <ken.cunningham.web...@gmail.com> wrote: > I could registry check for gtk2, and install gtk2-murrine if someone already > has gtk2 installed, I guess. Don't do this. You want an install invocation to do the same thing everywhere. > Or - perhaps best? - just list gtk2, gtk3, ang gtk2-murrine all as lib deps, > and install them all. Then nothing can go wrong. That's one option. Another would be to use variants for this (maybe a default gtk3 variant and an optional gtk2 one?) -- Daniel J. Luke
Re: Allowing PortGroups to bump port revision
On Jan 12, 2018, at 6:30 PM, Jeremy Huddleston Sequoia <jerem...@macports.org> wrote: > In https://trac.macports.org/ticket/54744, we've been pondering adding a > PortGroup to allow concurrent installation of multiple providers of the > OpenSSL API (eg: openssl, libressl, libressl-devel) and allow ports to > specify which they are compatible with. > > It occurred to me that it would be nice if we could update the PortGroup when > one of the dependencies changed their dylib id rather than revbumping all > ports. Is this something anyone else has considered? I've suggested this in the past (for p5 ports, specifically) that we could (ab)use revision to avoid having to rev-bump many ports. (I suggested we use a date-string so that individual ports that used the port-group could still set a higher revision if they needed to - but we'd still probably have to work out something to handle the case where a port wanted to set a revision and then later we wanted to update the revision in the portgroup). IIRC Ryan /hated/ that idea. Alternatively, we could add something to base to let us specify this kind of dependency (which would be useful). -- Daniel J. Luke
Re: poppler, security updates in general...
On Jan 9, 2018, at 12:27 PM, Perry E. Metzger <pe...@piermont.com> wrote: > Am I correct in assuming that as things stand, we mostly depend on > port owners to track security updates on behalf of the project and > that there isn't a security officer or any such thing? (Not > complaining, just seeking clarification.) Yes. Unless/until someone volunteers as security officer. Way back when we first instituted the regular vs. openmaintainer policy we decided that security updates fall in the 'anyone with commit access can push them' category - so in theory any committer can/should update any port that has a security update. -- Daniel J. Luke
Re: State of the GnuPG ports
On Oct 9, 2017, at 8:11 AM, Rainer Müller <rai...@macports.org> wrote: > I would just move 1.4 to gnupg1 and let gnupg provide version 2.2, as > only few users will be looking for GnuPG 1.4.x these days. If there is > enough interested, create gnupg-devel for the 2.3 development branch. +1 -- Daniel J. Luke
10.13 ntp build failure (undefined symbols)
Currently ntp builds on 10.13 fail with: % make /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am CCLD ntptime Undefined symbols for architecture x86_64: "_lib_nextbuf", referenced from: _common_prettydate in libntp.a(prettydate.o) "_lib_stringbuf", referenced from: _common_prettydate in libntp.a(prettydate.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [ntptime] Error 1 make: *** [all] Error 2 The libtool invocation is actually: ../libtool --silent --tag=CC --mode=link cc -Wall -Wcast-align -Wcast-qual -Wmissing-prototypes -Wpointer-arith -Wshadow -Winit-self -Wstrict-overflow -D_P1003_1B_VISIBLE -Wstrict-prototypes -g -O2 -L/opt/local/lib -o ntptime ntptime.o ../libntp/libntp.a -lresolv-intl What's confusing to me is that libntp.a includes those symbols: % nm -AU ../libntp/libntp.a | grep _lib_nextbuf ../libntp/libntp.a:lib_strbuf.o: 0004 C _lib_nextbuf % nm -AU ../libntp/libntp.a | grep _lib_stringbuf ../libntp/libntp.a:lib_strbuf.o: 0800 C _lib_stringbuf I'm clearly missing something - but I'm not sure what it is. Any thoughts? -- Daniel J. Luke
Re: Restoring from Time Machine backup relocates home directories
On Sep 14, 2017, at 10:32 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > I had numerous ports installed that create their own user accounts with > add_users or add_user, and of course MacPorts has its macports user. For each > of these users, I could select if I wanted the user to be restored, but if > so, it indicated that it would relocate that user's home directory to /Users; > if a user is to be restored, there is no option presented not to move its > home directory. I chose to accept the defaults and restore all users. Do we know what happens (or anyone want to try) if you don't choose to 'restore' the user? Might be good to include instructions for both outcomes and/or include both in any plans for how we make MacPorts deal with this automatically. -- Daniel J. Luke
Re: Server issues?
On Sep 8, 2017, at 1:26 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > On Sep 8, 2017, at 11:48, Daniel J. Luke wrote: >> One solution might be to separate the build/distfile mirroring from the >> portfile mirroring. You could probably even do that by running separate >> rsync's for those on your home connection and doing some QoS setup to depref >> the build uploads (so they wouldn't block portfile updates). > > I wouldn't know how to set up such QoS. Most home routers have the ability to set traffic to a lower-priority queue (per application, per MAC address, per IP address, and sometimes other options). I know you can do this with OpenWRT, DD-WRT, and Netgear's router software. Alternatively, if you have a router that supports fq_codel queuing, enabling that will probably fix it for you. > We did originally have FAU pulling multiple rsync modules at once. This > resulted in a complete clogging of my upstream bandwidth, which resulted in > downstream traffic stalling as well, which resulted in builds on the buildbot > failing as they could not download the needed distfiles. To prevent this, FAU > now does not attempt to pull multiple modules simultaneously, and my rsync > server is configured to limit its upstream bandwidth to slightly below my > upstream internet speed. If we allowed 2 concurrent rsync pulls, I would have > to cut the rsync bandwidth limit in half, to prevent saturating the upstream, > which would make uploading binaries to the public server twice as slow as it > already is. putting the rsync traffic in a lower priority queue, or using fq_codel (which would de-pref these 'elephant' tcp streams) would fix this without having to set specific speed limits on your rsync. >>> The buildbot setup currently consists of four Xserves and a Power Mac G5. >> >> so ~ 1/4 cabinet? > > I don't know. 1U for each Xserve (needs 4-post rack), plus a Power Mac G5 > that is not designed to go in a rack. it will probably be harder to find (cheap) space for non-rack-mount machine(s). >>>>> My Internet connection is not consumer-class. If it were a consumer >>>>> connection, it would be much faster and much cheaper, but ISPs does not >>>>> allow running servers on consumer connections, so it is an expensive and >>>>> slow business-class connection. >>>> >>>> If we don't care about having static IP addresses for these machines, I >>>> have a 2 post rack in my basement that's mostly empty and a 1gig consumer >>>> connection that I'd be happy to share with the project. >>> >>> Does your consumer Internet connection allow running a publicly-accessible >>> server >> >> yes, although running something like this would maybe require upgrading to a >> 'business' account (which they don't publish pricing for). I can ask. > > Well, honestly, I'm not excited about sending my servers to someone else. And > it would cost some money to ship, and there would be significant downtime > while figuring out how to get everything back online at the new location. I > might consider moving them to affordable colocation within driving distance > of me, but I don't know where that would be. When I looked into it last year > before deciding to host the servers at home, the cost to colocate was several > times what I pay to have them at home. ok, so you don't want to move the machines. Can we move some of the work off of them? It's fine (to me) to have delays in uploading the binary archives - but it would be best if there weren't delays in getting the updated ports tree out to our end-users. >>> We do currently have a single static IP with ports 80, 443, and 873 open >>> for the buildbot web site and the rsync server. Although it is not entirely >>> working at the moment, the server is also supposed to be sending emails on >>> failed builds; my understanding is that sending mail from a dynamic address >>> makes other servers more likely to classify the message as spam. >> >> it shouldn't if it's set up correctly (ie. to relay through a smarthost). > > I don't believe I currently have it set up that way. I know I experimented > with it but don't think I ever got it to actually work. But if I can save the > monthly cost of a static IP that would be good. http://www.postfix.org/postconf.5.html#relayhost it will even do smtp auth with username/password if you want/need it to. Something like this: relayhost = [remote_mail_hostname]:587 smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/password smtp_sasl_security_options = smtp_use_tls = yes tls_random_source = dev:/dev/urandom -- Daniel J. Luke
Re: Server issues?
On Sep 8, 2017, at 12:32 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > On Sep 8, 2017, at 11:08, Daniel J. Luke wrote: >> On Sep 8, 2017, at 11:55 AM, Ryan Schmidt wrote: >>> On Sep 8, 2017, at 10:51, Daniel J. Luke wrote: >>>> On Sep 7, 2017, at 9:37 AM, Ryan Schmidt wrote: >>>>> That'll happen when a huge port gets built and the resulting packages >>>>> must be transferred between my private rsync server and the public one. >>>>> In this case, it was probably that clang-devel, llvm-devel, and >>>>> lldb-devel were updated, and this produced many large binaries (six 900MB >>>>> binaries for clang-devel; seven 750MB binaries for llvm-devel; two 275MB >>>>> binaries for lldb-devel). >>>>> >>>>> I do intend to increase the speed of the internet connection soon so that >>>>> this will be less of a problem. >>>> >>>> Would it be reasonable to move things around so we're not dependent on >>>> your (presumably consumer-class) internet connection? >>> >>> What would you suggest move, where? >> >> I don't know how the current infrastructure is set up - so I can't make >> concrete suggestions. >> >> MacPorts is used pretty widely - I would be surprised if there was no one at >> an ISP or University who could offer us some space/power/bandwidth. [I may >> be able to help find some place like that, if it were desired]. > > We asked all of our existing mirror providers last year and were not able to > find such an arrangement. What we found was that > Friedrich-Alexander-Universität was willing to become our master public rsync > server and the origin server for distfiles and packages that feeds our CDN. > So that is the arrangement we currently have, with them pulling the files > from my private rsync server every half hour. The problem arises when several > gigabytes of new files have been created in a short time, since the current > rsync run must complete before a new one will start. One solution might be to separate the build/distfile mirroring from the portfile mirroring. You could probably even do that by running separate rsync's for those on your home connection and doing some QoS setup to depref the build uploads (so they wouldn't block portfile updates). >>> Last I looked into moving the Xserves to a data center, colocation was >>> extremely expensive. >> >> MacStadium seems to have pretty reasonable pricing (mini with gigE for >> $54/month), but again I don't know what our infrastructure requires. > > The buildbot setup currently consists of four Xserves and a Power Mac G5. so ~ 1/4 cabinet? >>> My Internet connection is not consumer-class. If it were a consumer >>> connection, it would be much faster and much cheaper, but ISPs does not >>> allow running servers on consumer connections, so it is an expensive and >>> slow business-class connection. >> >> If we don't care about having static IP addresses for these machines, I have >> a 2 post rack in my basement that's mostly empty and a 1gig consumer >> connection that I'd be happy to share with the project. > > Does your consumer Internet connection allow running a publicly-accessible > server yes, although running something like this would maybe require upgrading to a 'business' account (which they don't publish pricing for). I can ask. > We do currently have a single static IP with ports 80, 443, and 873 open for > the buildbot web site and the rsync server. Although it is not entirely > working at the moment, the server is also supposed to be sending emails on > failed builds; my understanding is that sending mail from a dynamic address > makes other servers more likely to classify the message as spam. it shouldn't if it's set up correctly (ie. to relay through a smarthost). -- Daniel J. Luke
Re: Server issues?
On Sep 7, 2017, at 9:37 AM, Ryan Schmidt <ryandes...@macports.org> wrote: > That'll happen when a huge port gets built and the resulting packages must be > transferred between my private rsync server and the public one. In this case, > it was probably that clang-devel, llvm-devel, and lldb-devel were updated, > and this produced many large binaries (six 900MB binaries for clang-devel; > seven 750MB binaries for llvm-devel; two 275MB binaries for lldb-devel). > > I do intend to increase the speed of the internet connection soon so that > this will be less of a problem. Would it be reasonable to move things around so we're not dependent on your (presumably consumer-class) internet connection? -- Daniel J. Luke
Re: Are macports builds prevented from accessing /dev/random ?
On Jun 13, 2017, at 4:57 PM, Christopher Jones <jon...@hep.phy.cam.ac.uk> wrote:
> :info:build open('/dev/random'): Operation not permitted
>
> Now, this works outside. So I suspect the build is in some way prevent the
> build process from accessing this. Is this possible ? If so, more to the
> point, is there a way I can get this to work… ?
I suspect the sandbox doesn't include access to /dev/random (Macports started
using sandbox-exec with version 2.2.0)
As a temporary workaround (or to test this theory) you can add "sandbox_enable
no" to your macports.conf
--
Daniel J. Luke
Re: how to install a subport rather than the main port from a local Portfile not in a repository
On Jun 11, 2017, at 10:27 AM, Ken Cunningham <ken.cunningham.web...@gmail.com> wrote: > Is there a way to work with a subport contained in that Portfile in a similar > fashion? Specifically, they want to access the -devel version subported in > the Portfile. https://marc.info/?l=macports-dev=145150625426958=1 (add subport=foo to the end of your command to get subport foo). I always forget this and end up needing to look it up - it should probably go on our wiki or FAQ somewhere. -- Daniel J. Luke
Re: streamline github dev process
On May 31, 2017, at 4:40 AM, Mojca Miklavec <mo...@macports.org> wrote: > What I believe could help a bit would be to get some > "mentors" assigned to new maintainers. Then those mentors would be > kind of obliged to review submissions from them and keep track of > their progress and vouch for commit rights once applicable. But this > would need a bit more thought. we used to do this (but maybe just for when someone was granted commit access, fkr was my mentor). If there are experienced contributors who are willing to do this, then some focus on this would likely help us get the number of regular contributors up (which would help fix these kinds of issues). > In theory GitHub's pull requests should allow to have *much less* > committers. In theory doing the reviews and merging pull requests > should be much easier that doing the same thing on Trac where the > patches get outdated, cannot be reviewed on line-by-line basis etc. In > practice I need to have a cheatsheet for merging pull requests and do > some not-anywhere-easy-to-remember steps to be able to merge trivial > PRs when some modifications are desired. Streamlining the PR workflow is still maybe a good idea (I don't know enough to recommend any changes here, though). One other (more radical) idea would be to split the ports tree into two - one where changes are auto-committed if they pass certain tests (lint ok, buildbot ok, test suite ok), and the 'curated' tree where someone has done a review and merged from the auto-committed one. I don't know if a universe where that exists is better, though (it would be pretty trivial to create a Portfile that could pass automated checks but do something bad if run on an end-user's machine). -- Daniel J. Luke
Re: 2.4.0 upgrade issue
On Jan 27, 2017, at 4:51 PM, Clemens Lang <c...@macports.org> wrote: > I'd recommend to take a look at your $prefix/etc/macports/macports.conf > and ensure that rsync_dir ends with tarballs/base.tar (or just comment > the setting, which automatically triggers the default, which contains > base.tar). > > The advantage of using the base.tar is that the tarball is signed and > the signature is checked during updates. I stronly discourage any use of > the old release/base URLs. I can confirm that this fixes the issue. (On a host that has been upgraded from way back in early darwinports days until now - it's probably overdue for general macports.conf cleanup) -- Daniel J. Luke
Re: 2.4.0 upgrade issue
On Jan 27, 2017, at 3:58 PM, John Patrick <nhoj.patr...@gmail.com> wrote: > how do I get the pkg installer from the website as all the links are > for 2.3.5, or do i need to guess the url? it's in the release announcement: https://lists.macports.org/pipermail/macports-announce/2017-January/40.html -- Daniel J. Luke
Re: Postfix, CAfile and Macports
On Jan 26, 2017, at 2:11 AM, Johannes Kastl <m...@ojkastl.de> wrote: > On 25.01.17 22:28 Daniel J. Luke wrote: >> What does `openssl s_client -connect 78.46.5.205:25 -starttls >> smtp` > say? > > "verify return: 1" sounds like problems, but "Verify return code: 0 > (ok)" at the end sounds ok. The next step I would take would be to turn up postfix debug logging and see if you get a hint on what is going wrong. -- Daniel J. Luke
Re: Postfix and the system.log
On Jan 25, 2017, at 1:39 PM, Johannes Kastl <m...@ojkastl.de> wrote: > > I just tried to get the macports postfix running on my macos Sierra > machine. But I could not get useful logs out of it. you're looking in the wrong place. For stuff built on Sierra, logging goes through apple's new logging system. see the 'log' manpage. To replicate tail -f /var/log/mail.log you'd do something like: log stream --style syslog --type log --predicate '(processImagePath contains "postfix")' -- Daniel J. Luke
Re: mpkg/mdmg and scripts
On Jan 13, 2017, at 3:01 PM, Craig Treleaven <ctrelea...@macports.org> wrote: > Suppose I create an mpkg installer just for mariadb-server. The scripts are > included for the mariadb-server component, as expected. However, when ‘port > mpkg’ builds the installer component for the mariadb (client) software is > ALSO includes the Pre/Postinstall scripts—it doesn’t know that they’re only > intended for the server side. Why does it do that? To me, it seems like the simple solution would be for the scripts that pertain to mariadb-server to only be included with the mariadb-server port and not with the mariadb (client) port. -- Daniel J. Luke
Re: xonsh-devel broken
On Dec 21, 2016, at 3:47 PM, Marko Käning <mk-macpo...@posteo.net> wrote: > I just saw this when running portindex on my El Capitan VM: > > Failed to parse file shells/xonsh/Portfile with subport 'xonsh-devel': > invalid command name "BASHwards-looking” yep, I just pushed a fix for the missing \ in the description in the subport. -- Daniel J. Luke
Re: SSL Issues and PortGroup GitHub
On Dec 21, 2016, at 8:18 AM, John Patrick <nhoj.patr...@gmail.com> wrote: > I commented out a line from /opt/local/etc/macports/macports.conf; > macportsuser root That should never be set that way. > And it works, no idea why that line is in that file as I don't believe > I would have ever put it in their myself. That's not the default. If you can figure out where you may have read instructions telling you to set that, it would be helpful (so we could create a real fix for whatever people were trying to work-around and not have people setting things that way). -- Daniel J. Luke
Re: Apache 24 woes
On Nov 19, 2016, at 5:34 AM, Vincent Habchi <vi...@macports.org> wrote:
> 1. Why is apache24 still called “apache24-devel”?
because the maintainer(s) of the apache ports decided to combine version
upgrade to 2.4 with apache layout changes (and because of fears of apache
modules that work with 2.2.x not working with 2.4.x).
It's ultimately up to the maintainers, but I agree that we should update the
'apache' port to ship 2.4.x
> 2. APR-UTIL should:
> a. Be dependant on whatever db version is installed and not db46. I
> wrote this:
> —
> # DB dependency
> set db_list [lsort [glob ${prefix}/lib/db??]]
> set db_most_recent [lindex [split [lindex $db_list 0] /] end]
> if {$db_most_recent == ""} { set db_most_recent "db60" }
>
> depends_lib port:apr port:expat port:libiconv port:$db_most_recent
> port:sqlite3
> —
no, we strive for reproducible builds - having the port install something
different depending on what's already on the person's system is not something
we want to do.
Changing the bdb dependency to something more recent is possible (IIRC it got
stuck on db46 because when oracle purchased, the db4 license changed - but I
think Oracle made another change that made it OK, I just haven't gone to look /
no one has offered to investigate or submitted a patch).
> b. Have a mariadb10 variant
As I don't use any of the mysql-descendent DBs, I rely on people who do to
submit patches for them :)
--
Daniel J. Luke
