Re: Macports baresip very out of date
Ryan With many thanks to (I assume) the maintainer the package has already been updated to the latest version. > On 2 Oct 2021, at 09:41, Ryan Schmidt wrote: > > On Sep 8, 2021, at 08:37, Mark Lucas wrote: > >> The version of baresip on MacPorts appears to be *very* out of date (v >> 0.6.0_3) The MacPorts package info Homepage URL for baresip is dead. >> The project appears to have moved to GitHub - >> https://github.com/baresip/baresip and seems to under active development >> currently standing at version 1.1.0 >> Any chance of updating the MacPorts version? > > You can file a ticket in the issue tracker requesting a port update, or you > can perform the update yourself and submit it to us as a pull request. > >
Re: Does MacPorts need ALL of Xcode?
On Oct 3, 2021, at 00:08, Ian Wadham wrote: > OK, thanks Ryan, but how about https://guide.macports.org/#installing.xcode ? > > It explicitly says to install Xcode first, as a dependency of MacPorts, and > then do xcode-select —install, which is what I have been doing for 10 years > or more as a MacPorts user. And I suppose almost all other MacPorts users > have too. > > But in that time Xcode has grown from a gigabyte or two to 20 Gb on my > current MacOS, Catalina 10.15.7. That is a significant slice of the SSD > storage in a shop-standard MacBook Pro. So if a user does not need Xcode as a > prerequisite of MacPorts, he/she should not have to carry the time and space > overheads of downloading, installing and storing it. > > My question then is please can https://guide.macports.org/#installing.xcode > be re-written to help users who do not need Xcode for any other reason? Yes, it can. Anyone can contribute updates to the documentation by submitting a pull request. Much of the Guide has not been updated in over a decade and is in dire need of rewrites or replacement. >>> Couldn’t those ports list Xcode as a build dependency? >> >> They do, by using this keyword: >> >> use_xcode yes > > Chris Jones raised the point on 26/27 September on this thread that some > ports require Xcode and gave this as the reason for MacPorts requiring Xcode. > > But how many ports are involved here? What percentage of users are likely to > need them? And what is the worst that can happen to a user if he/she happens > to run into one and does not have Xcode installed? MacPorts will print a message saying Xcode is required to install that port. > I tried port search use_xcode to try and shed some light on these questions, > but it gave "no match … found”. "port search" does not do a search of the entire literal contents of portfiles, but you can use grep to do that. Ports that include the xcode portgroup also most probably require Xcode. I would have thought that the xcode 1.0 portgroup would declare "use_xcode yes" somewhere in it, but it doesn't seem to. Maybe that is an oversight. According to this: port file all | sort -u | xargs grep -El '^[[:space:]]*(use_xcode[[:space:]]yes|PortGroup[[:space:]]+xcode[[:space:]])' | wc -l there are around 180 ports that require Xcode. There may be others that require Xcode but that do not so indicate yet.
Re: ImportError: Couldn't locate OpenSlide dylib. Is OpenSlide installed?
On Sat, Oct 2, 2021 at 11:56 PM Ryan Schmidt wrote: > [...] > Hi Ryan, I believe David's issue was addressed in https://trac.macports.org/ticket/63492. --Benjamin Gilbert
Re: Does MacPorts need ALL of Xcode?
> On 2 Oct 2021, at 6:20 pm, Ryan Schmidt wrote: > > On Sep 27, 2021, at 16:36, Ian Wadham wrote: > >> So what is the “recipe” to install just the CLT with no version of Xcode >> present? And can that recipe be included in the MacPorts Guide? > > Run > > xcode-select --install > > and click the button to install the command line tools. > > Or download the command line tools installer from the Apple Developer > Downloads web site. OK, thanks Ryan, but how about https://guide.macports.org/#installing.xcode ? It explicitly says to install Xcode first, as a dependency of MacPorts, and then do xcode-select —install, which is what I have been doing for 10 years or more as a MacPorts user. And I suppose almost all other MacPorts users have too. But in that time Xcode has grown from a gigabyte or two to 20 Gb on my current MacOS, Catalina 10.15.7. That is a significant slice of the SSD storage in a shop-standard MacBook Pro. So if a user does not need Xcode as a prerequisite of MacPorts, he/she should not have to carry the time and space overheads of downloading, installing and storing it. My question then is please can https://guide.macports.org/#installing.xcode be re-written to help users who do not need Xcode for any other reason? >> Couldn’t those ports list Xcode as a build dependency? > > They do, by using this keyword: > > use_xcode yes Chris Jones raised the point on 26/27 September on this thread that some ports require Xcode and gave this as the reason for MacPorts requiring Xcode. But how many ports are involved here? What percentage of users are likely to need them? And what is the worst that can happen to a user if he/she happens to run into one and does not have Xcode installed? I tried port search use_xcode to try and shed some light on these questions, but it gave "no match … found”. Cheers, Ian Waham.
Re: ImportError: Couldn't locate OpenSlide dylib. Is OpenSlide installed?
Please write to list addresses at lists.macports.org, not at the old hostname that we discontinued using in late 2016. On Sep 13, 2021, at 15:40, Epstein, David wrote: > > MacPorts base version 2.7.1 installed > MacOs 11.5.2 > MacBook Pro (Retina, 15-inch, Mid 2015) > > I get the error message in the Subject Line. So I looked at the discussion at > https://github.com/openslide/openslide-python/issues/27 > and carefully followed all the advice given there, but the error persists. > > bgilbert locked the topic on github in December 2019, saying that the problem > was resolved. He also said: > "This is likely to be a problem with your installation, so I'll close. If > you're still seeing this with OpenSlide installed in your library search > path, please reopen.” I don’t know how one can reopen a locked topic on > Github. Perhaps this will do the trick. I would guess you cannot reopen someone else's issue unless you are a member of the project. > Here is the command I gave to macports, and the response from macports.This > seems to mean that openslide file(s) are installed, > $ port search openslide > openslide @3.4.1_1 (graphics) > A C library for reading virtual slides. > > py-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py27-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py34-openslide @1.1.2_1 (python, graphics) > Obsolete port, replaced by py35-openslide > > py35-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py36-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py37-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py38-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > py39-openslide @1.1.2_1 (python, graphics) > Python binding for the OpenSlide library. > > Found 9 ports. "port search" shows you what ports are available. It does not say anything about whether they are installed. "port installed" tells you what ports are installed. > but is there a way of checking further, "port contents" tells you the files MacPorts believes it has installed for a port. You can verify that the list contains the right files. You can then actually check the filesystem and see if the listed files do exist. (Something other than MacPorts could have removed the files after MacPorts installed them. If so, a "sudo port deactivate" followed by "sudo port activate" should bring them back.) > in particular checking that there is nothing wrong with the files? How would you define "wrong"? How should MacPorts know if the files are wrong? MacPorts does include a feature called rev-upgrade which checks one specific way in which files could be wrong, specifically whether they are linked with libraries that don't exist. This could happen for example when a library provided by a dependency is upgraded to a new major version. Port maintainers should notice and fix this problem, but sometimes it is overlooked. If this situation is discovered, MacPorts automatically rebuilds the ports to fix them. rev-upgrade runs automatically after every port installation or upgrade. If things are still broken after rebuilding, it tells you that. > From the discussion on Github, it seems that the problem may be with > Macports. I could (very reluctantly) delete my Macports installation and > reinstate it. Does anyone have some wise advice? I don't see any reason why you should uninstall MacPorts for this. I don't think that will bring you any closer to solving the problem. The error message you showed didn't tell us the exact path and name of the library it is looking for. Discover that first. Then check if the library exists at that path. If yes, why can't it be used? Does it have the wrong install_name or is it the wrong version or broken due to linking with a nonexistent library? If no, why not? What should be providing that library? Why isn't it? Or is the issue perhaps that it is not looking for the library in a specific path, expecting you instead to be setting DYLD_LIBRARY_PATH to tell it where the library is? If so, don't do that; report the problem to the author of the software so that they can fix it so that it does not require setting DYLD_LIBRARY_PATH. No program should require a user to set DYLD_LIBRARY_PATH. Setting DYLD_LIBRARY_PATH will cause other problems.
Re: Let's Encrypt DST Root CA X3 Expiration
ugh. Well, doing a search shows a LOT of articles about this very issue -- this was apparently a known "this is going to affect a lot of people" deal, and "just update your software, or ... sorry." was the only answer. But, I at least did find out why certs expire. Seriously though: A cert identifies a domain. If you sell/buy a domain, you want to be able to invalidate all existing certs for that domain. And as I see that, I'm immediately struck by two things: 1. SSL, and a cert's job, is to validate the connection, not the person on the other end. It's to prevent MitM attacks. (Putting the domain name in -- when multiple names can go to the same server? Why?) 2. The DNS is the obvious place to put "Here's our fingerprint" or something to validate a cert -- that would prevent old owner certs from working. (So why isn't this done?) And I cannot find any good reason for expiring root certs. They explicitly have much longer lifespans than anything else, and this isn't the first time that root certs have gone poof. Off the list topic now. Thanks for your help. On 2021-10-02, at 8:32 PM, Ryan Schmidt wrote: > On Oct 2, 2021, at 22:06, Michael wrote: >> >> So, first, I want to say "Thank you" for this bit: >> >>> • From View menu select "Show Expired Certificates" >> >> In keychain access, I could not see the expired certs, and was thinking that >> they were just deleted for being old. Once I could find the old ones, I >> could turn them back on. >> >> The second thing is that for whatever reason, I could not download and >> install the new cert into keychain access. But ... oddly, Firefox 52 ESR had >> that cert installed (even that old ...???). I could export from firefox, and >> import THAT into keychain access, and at least enable that for my account. >> >> So, ... well, not perfect. These certs are marked as trusted for *my >> account*. Not for the system. So predictably, some things done by the system >> in the background will fail, but at least Chrome and Firefox both now work >> fine. (Safari isn't tested, but ... well, Safari isn't tested :=-). >> >> >> >> I have a much better question, that's outside of the scope of this list or >> even the site(s) in question. >> >> Why does a signature expire? >> >> If I have something that was signed by a cert, and it was signed in a valid >> time time stamp, why does that signature ever expire? >> >> I've come across programs that have an expired signature, and I can't see a >> good reason for it. >> >> And if there's no good way to tell when something was actually signed >> (because a timestamp can be forged), then the question becomes, why does a >> cert expire as a function of time? Why not allow a cert to be "until >> revoked"? >> >> For that matter, why is "valid/not valid" not under the control of the >> system? Why is someone else allowed to say that my system is no longer valid? >> >> I figure that there's a good answer to these questions somewhere, but I have >> no clue where to even begin looking. And yes, I know that quantum factoring >> will eventually permit all of these certs to be forged, but until then, why >> not allow them, and even after that point, why not allow me to allow them? > > I'm not an expert on this stuff, just sharing what I learned about the issue > yesterday, but you can ask your search engine questions like "why do > certificates expire" or more specifically in this case "why do root ca > certificates expire". > > My understanding is that the reason why Let's Encrypt recommends sites > continue to serve the ISRG Root X1 certificate that is signed by the expired > DST Root CA X3 certificate is that at least old browsers like those on old > Android phones should consider a web site's certificate to be valid, as long > as we are within its validity dates, even if the root certificate it's signed > by is expired. Like I said, I'm not an expert, I don't know why it would be > that way, and evidently it's not that way on some Apple devices, so server > administrators now have to choose between Let's Encrypt's default which > supports old Android devices or the other way which supports old Apple > devices. > > --- Entertaining minecraft videos http://YouTube.com/keybounce
Re: Home brew recipes for MacPorts
On Oct 2, 2021, at 20:11, André-John Mas wrote: > Given a number of projects are only available for Homebrew, or only up to > date for Homebrew, has any looked at a process for adapting a Homebrew recipe > to a MacPorts one? Something like ‘port brew ’? I haven’t thought of > all the implications, but I am throwing this out there to see what the > thoughts are? Probably not worth pursuing. Both are package managers but they go about things in fundamentally different ways. If something was trivial to add to Homebrew, it will probably be trivial to add to MacPorts so an automated conversion would not save much time. If it was complex to add to Homebrew, it will probably be complex to add to MacPorts and will require manual intervention anyway. It is certainly worth pursuing adding software to MacPorts that users would find useful, whether or not it is in another package manager. Contributions are welcome.
Re: Let's Encrypt DST Root CA X3 Expiration
On Oct 2, 2021, at 22:06, Michael wrote: > > So, first, I want to say "Thank you" for this bit: > >> • From View menu select "Show Expired Certificates" > > In keychain access, I could not see the expired certs, and was thinking that > they were just deleted for being old. Once I could find the old ones, I could > turn them back on. > > The second thing is that for whatever reason, I could not download and > install the new cert into keychain access. But ... oddly, Firefox 52 ESR had > that cert installed (even that old ...???). I could export from firefox, and > import THAT into keychain access, and at least enable that for my account. > > So, ... well, not perfect. These certs are marked as trusted for *my > account*. Not for the system. So predictably, some things done by the system > in the background will fail, but at least Chrome and Firefox both now work > fine. (Safari isn't tested, but ... well, Safari isn't tested :=-). > > > > I have a much better question, that's outside of the scope of this list or > even the site(s) in question. > > Why does a signature expire? > > If I have something that was signed by a cert, and it was signed in a valid > time time stamp, why does that signature ever expire? > > I've come across programs that have an expired signature, and I can't see a > good reason for it. > > And if there's no good way to tell when something was actually signed > (because a timestamp can be forged), then the question becomes, why does a > cert expire as a function of time? Why not allow a cert to be "until > revoked"? > > For that matter, why is "valid/not valid" not under the control of the > system? Why is someone else allowed to say that my system is no longer valid? > > I figure that there's a good answer to these questions somewhere, but I have > no clue where to even begin looking. And yes, I know that quantum factoring > will eventually permit all of these certs to be forged, but until then, why > not allow them, and even after that point, why not allow me to allow them? I'm not an expert on this stuff, just sharing what I learned about the issue yesterday, but you can ask your search engine questions like "why do certificates expire" or more specifically in this case "why do root ca certificates expire". My understanding is that the reason why Let's Encrypt recommends sites continue to serve the ISRG Root X1 certificate that is signed by the expired DST Root CA X3 certificate is that at least old browsers like those on old Android phones should consider a web site's certificate to be valid, as long as we are within its validity dates, even if the root certificate it's signed by is expired. Like I said, I'm not an expert, I don't know why it would be that way, and evidently it's not that way on some Apple devices, so server administrators now have to choose between Let's Encrypt's default which supports old Android devices or the other way which supports old Apple devices.
Re: Let's Encrypt DST Root CA X3 Expiration
On Sat, Oct 02, 2021 at 08:06:27PM -0700, Michael wrote: > So, first, I want to say "Thank you" for this bit: > > > • From View menu select "Show Expired Certificates" > > In keychain access, I could not see the expired certs, and was > thinking that they were just deleted for being old. Once I could find > the old ones, I could turn them back on. Ah, that explains why I couldn't see it. :-) > The second thing is that for whatever reason, I could not download > and install the new cert into keychain access. But ... oddly, Firefox > 52 ESR had that cert installed (even that old ...???). I could export > from firefox, and import THAT into keychain access, and at least > enable that for my account. > > So, ... well, not perfect. These certs are marked as trusted for *my > account*. Not for the system. So predictably, some things done by the > system in the background will fail, but at least Chrome and Firefox > both now work fine. (Safari isn't tested, but ... well, Safari isn't > tested :=-). On 10.6.8, I wasn't able to add to the system keychain via the Keychain Access GUI (even after unlocking it), but I was able to do it using the "security" command following these instructions: How do I update my root certificates on an older version of Mac OS (e.g. El Capitan)? https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi If you have ISRG Root X1 as a .pem file, something like this should import it into the "System" keychain: sudo security -v add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain isrgrootx1.pem For the "System Roots" keychain, instead of the "System" keychain: sudo security -v add-trusted-cert -d -r trustRoot -k /System/Library/Keychains/SystemRootCertificates.keychain isrgrootx1.pem I don't know if it matters which of these keychains it goes into. cheers, raf
Re: Let's Encrypt DST Root CA X3 Expiration
So, first, I want to say "Thank you" for this bit: > • From View menu select "Show Expired Certificates" In keychain access, I could not see the expired certs, and was thinking that they were just deleted for being old. Once I could find the old ones, I could turn them back on. The second thing is that for whatever reason, I could not download and install the new cert into keychain access. But ... oddly, Firefox 52 ESR had that cert installed (even that old ...???). I could export from firefox, and import THAT into keychain access, and at least enable that for my account. So, ... well, not perfect. These certs are marked as trusted for *my account*. Not for the system. So predictably, some things done by the system in the background will fail, but at least Chrome and Firefox both now work fine. (Safari isn't tested, but ... well, Safari isn't tested :=-). I have a much better question, that's outside of the scope of this list or even the site(s) in question. Why does a signature expire? If I have something that was signed by a cert, and it was signed in a valid time time stamp, why does that signature ever expire? I've come across programs that have an expired signature, and I can't see a good reason for it. And if there's no good way to tell when something was actually signed (because a timestamp can be forged), then the question becomes, why does a cert expire as a function of time? Why not allow a cert to be "until revoked"? For that matter, why is "valid/not valid" not under the control of the system? Why is someone else allowed to say that my system is no longer valid? I figure that there's a good answer to these questions somewhere, but I have no clue where to even begin looking. And yes, I know that quantum factoring will eventually permit all of these certs to be forged, but until then, why not allow them, and even after that point, why not allow me to allow them? On 2021-10-02, at 7:52 PM, Ryan Schmidt wrote: > On Oct 2, 2021, at 10:57, Michael wrote: >> >> Well, thank you for this, and it explains something else. >> >> I've got an older OS (10.9.5), and suddenly Chrome (67 is latest here) has >> been complaining left right and center about LOTS of unsafe sites, refusing >> to let me connect, etc. Meanwhile, firefox (52 esr) is happy to connect, but >> is too old to display a lot of them correctly. >> >> Is there any way for older OS's to declare extended trust for certificates? > > I've added instructions for doing that here: > > https://trac.macports.org/wiki/ProblemHotlist#letsencrypt > > It helped Safari and /usr/bin/curl. I didn't test Chrome; you can let us know > if it helps. --- This message was composed with the aid of a laptop cat, and no mouse
Re: Let's Encrypt DST Root CA X3 Expiration
I've added info about this to the problem hotlist including instructions for how to add the new ISRG Root X1 certificate to your older Mac manually: https://trac.macports.org/wiki/ProblemHotlist#letsencrypt I've done this on our Buildbot machines running OS X 10.11 and earlier which should allow them to continue to fetch packages and distfiles. On Oct 2, 2021, at 04:14, Ryan Schmidt wrote: > On the web servers we control, we can apparently remove the expired DST Root > CA X3 certificate from the chain that we send. That will help those systems > that already trust ISRG Root X1. I'm not sure how far back that is. I have made this change on the buildbot web server. It seems to help OS X 10.11 and earlier. We should make the same changes to our other servers. Maybe Rainer or Clemens can take care of the hosts on Braeburn. I'll have to see what we need to do to get the change onto the distfiles and packages servers and mirrors.
Re: Let's Encrypt DST Root CA X3 Expiration
On Sat, Oct 02, 2021 at 04:14:05AM -0500, Ryan Schmidt wrote: > macports.org and other secure web sites that use Let's Encrypt may > no longer be accessible to you if you use older versions of macOS > or older browsers or user agents. For example, the libcurl in macOS > 10.14 can't talk to many Let's Encrypt web sites now, including > distfiles.macports.org and packages.macports.org, and MacPorts uses > macOS libcurl to download things. Safari and many browsers don't use > libcurl so they may be affected differently. > > Let's Encrypt is a free certificate provider used by macports.org > and many other web sites to provide https encryption. Certificates > they issue depend on their "ISRG Root X1" certificate which was > cross-signed by the "DST Root CA X3" certificate, because DST Root > CA X3 was more widely accepted by browsers when Let's Encrypt got > started years ago. Both of these root certificates are included in the > certificate chain served by web sites that use Let's Encrypt. > > ISRG Root X1 itself has been trusted by browsers for some time > now and DST Root CA X3 expired a couple days ago on September 30, > 2021. Apparently in order to provide the widest compatibility, > certificate chains continue to list the old expired root certificate > after the new one. The idea as I understand it is that browsers should > see the ISRG Root X1 certificate, realize that it itself is already > trusted by the OS or browser, and not even look at the next expired > DST Root CA X3 certificate in the chain. > > They advertised this root certificate expiration as being a very minor > situation, but unfortunately it seems that a large portion of Apple > devices cannot deal with this change. On many Macs, it seems that the > entire certificate chain is being validated, and the expired extra > root certificate is causing the connection to be disallowed. What > alerted me to the problem in the first place was seeing many failed > builds on our Buildbot system due to fetch failures. > > I'm not certain what to do to address this. On the web servers > we control, we can apparently remove the expired DST Root CA X3 > certificate from the chain that we send. That will help those > systems that already trust ISRG Root X1. I'm not sure how far back > that is. For older systems, we can modify master_sites.tcl and > archive_sites.tcl to change which OS versions try to access our mirror > servers via https. None of this necessarily helps our build server be > able to mirror distfiles in the first place. If you have ideas, let me > know. > > https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ There is a discussion on the LetsEncrypt community site with instructions for installing the ISRG Root X1 certificate on older versions of macOS: https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/16 Here are instructions for 10.10 and 10.11: https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/25 Here's another approach that worked on 10.9.5 and 10.11.6 (i.e., override the expiry by always trusting DST Root CA X3: https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/28 Here's my approach for 10.6.8 because the above didn't work (i.e., export root certificates from a later macOS and import them): https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/36 But these are all client-side fixes. The only server-side fix seems to be to change to a different certificate authority. I didn't see any mention of removing the DST Root CA X3 certificate from the chain. That would probably only work from macOS 10.12 onwards. ISRG Root X1 is only trusted by macOS since 10.12. Earlier than that, it needs to be added. The rest is a bit rambly. It might be best to just consult the LetsEncrypt community forum above. I should mention that I didn't notice any problems with macports on 10.6.8. curl has its own root certificates and they are fine. And I was able to do an upgrade. But I might have already installed the ISRG Root X1 certificate at least into my "local" keychain before trying it (or maybe into the "System" and "System Roots" keychains). However, I still don't think that it's entirely OK. Firefox on 10.6.8 can access macports.org with no problem (but it certainly wasn't accessing my LetsEncrypt-certified sites beforehand), but Sarafi tells me that it can't verify macports.org's identity, but it still lets me access it. If I quit and restart Safari, and visit macports.org, it does the same thing. Firefox uses its own root certificates. Safari uses the system ones. But I definitely have ISRG Root X1 in both the "System" and "System Roots" keychains. So I don't know why Safari has a problem. In Keychain Access, it's marked as "Always Trust" but it also says "trusted for macports.org" (I don't know why it says that). That's confusing. But in Safari, when viewing the certificate, there was a checkbox
Home brew recipes for MacPorts
Hi, I have been hesitant in asking this question, but here goes: Given a number of projects are only available for Homebrew, or only up to date for Homebrew, has any looked at a process for adapting a Homebrew recipe to a MacPorts one? Something like ‘port brew ’? I haven’t thought of all the implications, but I am throwing this out there to see what the thoughts are? André-John Sent from my phone. Envoyé depuis mon téléphone.
Re: MacPorts Only Has ImageMagick 6 not 7?
> On Oct 02, 2021, at 16:58, Bill Cole > wrote: > On 2021-10-02 at 17:02:20 UTC-0400 (Sat, 2 Oct 2021 16:02:20 -0500) > Christopher Stone is rumored to have said: >> I'm only seeing ImageMagick @6.9.11-60_1 from MacPorts with `port info`. > ... > It is correct, and is entirely unrelated to the LE cert issue. > > There's an open ticket for getting v7 into ports > (https://trac.macports.org/ticket/51310) that provides insight to the issues > behind the delay. Hey Bill, Got it! Many thanks. -- Best Regards, Chris
Re: MacPorts Only Has ImageMagick 6 not 7?
On 2021-10-02 at 17:02:20 UTC-0400 (Sat, 2 Oct 2021 16:02:20 -0500) Christopher Stone is rumored to have said: Hey Folks, I'm only seeing ImageMagick @6.9.11-60_1 from MacPorts with `port info`. It looks like the most current version is ImageMagick 7.1.0-8. https://imagemagick.org/ Is this correct, or does this have something to do with the Let's Encrypt DST Root CA X3 Expiration issue Ryan reported this morning? It is correct, and is entirely unrelated to the LE cert issue. There's an open ticket for getting v7 into ports (https://trac.macports.org/ticket/51310) that provides insight to the issues behind the delay. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
MacPorts Only Has ImageMagick 6 not 7?
Hey Folks, I'm only seeing ImageMagick @6.9.11-60_1 from MacPorts with `port info`. It looks like the most current version is ImageMagick 7.1.0-8. https://imagemagick.org/ Is this correct, or does this have something to do with the Let's Encrypt DST Root CA X3 Expiration issue Ryan reported this morning? MacPorts 2.7.1 macOS 10.14.6 MacBookAir5,2 · 2 GHz Intel Core i7 · 8GB RAM TIA. -- Best Regards, Chris
Let's Encrypt DST Root CA X3 Expiration
macports.org and other secure web sites that use Let's Encrypt may no longer be accessible to you if you use older versions of macOS or older browsers or user agents. For example, the libcurl in macOS 10.14 can't talk to many Let's Encrypt web sites now, including distfiles.macports.org and packages.macports.org, and MacPorts uses macOS libcurl to download things. Safari and many browsers don't use libcurl so they may be affected differently. Let's Encrypt is a free certificate provider used by macports.org and many other web sites to provide https encryption. Certificates they issue depend on their "ISRG Root X1" certificate which was cross-signed by the "DST Root CA X3" certificate, because DST Root CA X3 was more widely accepted by browsers when Let's Encrypt got started years ago. Both of these root certificates are included in the certificate chain served by web sites that use Let's Encrypt. ISRG Root X1 itself has been trusted by browsers for some time now and DST Root CA X3 expired a couple days ago on September 30, 2021. Apparently in order to provide the widest compatibility, certificate chains continue to list the old expired root certificate after the new one. The idea as I understand it is that browsers should see the ISRG Root X1 certificate, realize that it itself is already trusted by the OS or browser, and not even look at the next expired DST Root CA X3 certificate in the chain. They advertised this root certificate expiration as being a very minor situation, but unfortunately it seems that a large portion of Apple devices cannot deal with this change. On many Macs, it seems that the entire certificate chain is being validated, and the expired extra root certificate is causing the connection to be disallowed. What alerted me to the problem in the first place was seeing many failed builds on our Buildbot system due to fetch failures. I'm not certain what to do to address this. On the web servers we control, we can apparently remove the expired DST Root CA X3 certificate from the chain that we send. That will help those systems that already trust ISRG Root X1. I'm not sure how far back that is. For older systems, we can modify master_sites.tcl and archive_sites.tcl to change which OS versions try to access our mirror servers via https. None of this necessarily helps our build server be able to mirror distfiles in the first place. If you have ideas, let me know. https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
Re: Macports baresip very out of date
On Sep 8, 2021, at 08:37, Mark Lucas wrote: > The version of baresip on MacPorts appears to be *very* out of date (v > 0.6.0_3) The MacPorts package info Homepage URL for baresip is dead. > The project appears to have moved to GitHub - > https://github.com/baresip/baresip and seems to under active development > currently standing at version 1.1.0 > Any chance of updating the MacPorts version? You can file a ticket in the issue tracker requesting a port update, or you can perform the update yourself and submit it to us as a pull request.
Re: How to get a developers' package for Ruby
On Sep 21, 2021, at 23:49, Ian Wadham wrote: > I wish to download from the Web a package called CocoaPods, however it needs > a developers’ package of Ruby to build it. > > I am using MacOS Catalina 10.15.7. Apple provides Ruby in this MacOSversion, > but will not allow it to be used for building non-Apple apps. They say they > are phasing out the use of Ruby in MacOS and Apple Mac apps. > > Googling around about this problem, all the solutions I have found recommend > getting a "ruby-dev" package from Homebrew, but MacPorts, which I use a lot, > recommends against mixing MacPorts and Homebrew. Some other package managers observe a distinction between "runtime" and "development" packages, with the latter having a "-dev" suffix. MacPorts does not observe such a distinction. All packages in MacPorts contain both the runtime and development parts, to the extent that each software package has those parts. MacPorts does have port names with a "-devel" suffix, but they embody a completely unrelated concept. Ports with names not ending with "-devel" are typically for stable versions of software while ports with the "-devel" name suffix are for newer unstable versions. > Failing that, would it be safe to install Homebrew and its ruby-dev, just for > building CocoaPods? Please choose one package manager and uninstall the other. We do not want to spend time diagnosing problems that were caused by installing software with multiple conflicting package managers.
Re: ruby_select is broken
On Sep 25, 2021, at 23:14, Ian Wadham wrote: > MacPorts contains packages of many versions of Ruby, similarly to the Python > and Perl groups, but the corresponding “ruby_select” port does not > automatically create the links needed to access commands “ruby”, “gem” etc. I > was able to get around this by using “sudo port select” manually, but would > it be possible for someone to fix “ruby_select” so that the ports “ruby$n” > work properly “out of the box". I don't understand what you mean. ruby_select (and all _select ports) are helper infrastructure so that "port select" works. Using "port select" is not a workaround; it is *the* way to select a particular version of a set of ports. > Also, the port actually called “ruby” is very old (version 1.8.7) and “port > notes ruby” deprecates it. Should it be removed from MacPorts? If nobody needs it, I suppose it could be removed. Do you know that nobody needs it? I don't know that. > Or reincarnated as “ruby18”, dropping “ruby186” as well? If it ain't broke, don't fix it?
Re: Does MacPorts need ALL of Xcode?
On Sep 27, 2021, at 11:49, Filipp Gunbin wrote: > On 26/09/2021 23:42 +0100, Chris Jones wrote: > >> The majority of ports will indeed build fine with just the CLT >> installed. There are a number though where the build does indeed >> require a complete Xcode installation, which is why the baseline >> recommendation is to install Xcode. However if you are ok with perhaps >> running into the occasional port failure (the likelihood for which >> depends on which ports you use) you likely can get by just fine with >> just the CLT. > > How can one check if a given port requires full XCode? You can check if its portfile contains the line: use_xcode yes If it does, it requires Xcode to build. However, if it is distributable, then it may already have been built by our build servers, which have both Xcode and the command line tools installed, in which case MacPorts can obtain and install that pre-built archive for you without you needing to have Xcode installed on your computer. In fact, if a port is distributable, you don't even need the command line tools installed to install it.
Re: Does MacPorts need ALL of Xcode?
On Sep 27, 2021, at 16:36, Ian Wadham wrote: > So what is the “recipe” to install just the CLT with no version of Xcode > present? And can that recipe be included in the MacPorts Guide? Run xcode-select --install and click the button to install the command line tools. Or download the command line tools installer from the Apple Developer Downloads web site. > Couldn’t those ports list Xcode as a build dependency? They do, by using this keyword: use_xcode yes
Re: geant4 and/or geant4.10.0
On Sep 29, 2021, at 04:01, Михаил Коротков wrote: > Dear Mojka, > Could you please to explain what I have to do for using Geant4. > I have installed Geant4.10.6 by > sudo port install geant4 > And seems everything is ok. > Then I run geant4.sh in the /opt/local/libexec/Geant4/geant4.10.6/ > But when I tried to make .. I got the > > CMake Error at CMakeLists.txt:24 (find_package): > By not providing "FindGeant4.cmake" in CMAKE_MODULE_PATH this project has > asked CMake to find a package configuration file provided by "Geant4", but > CMake did not find one. > > Could not find a package configuration file provided by "Geant4" with any > of the following names: > > Geant4Config.cmake > geant4-config.cmake > > Add the installation prefix of "Geant4" to CMAKE_PREFIX_PATH or set > "Geant4_DIR" to a directory containing one of the above files. If "Geant4" > provides a separate development package or SDK, be sure it has been > installed. > > And the second question is - can I work with the Geant4 in python? > If yes what I have to do? > It seems to me that in any case I need to add something in PATHS. > > I work on Mac OS BIG SUR with M1. > > Thank you very much, > Mikhail In the future please write to macports-users@lists.macports.org, not at the old hostname that we stopped using in late 2016.
