glib2 +x11/+quartz
Why is it that one of those variants is required? Is there any problem with having glib2 without both? Jan
Re: Search for a MacPorts Mascot: looking for talented artists
https://en.wikipedia.org/wiki/Port_of_Oakland#/media/File:USA-Oakland-Port-View_from_Alameda-4.jpg On 21/02/18 21:56, Dave Horsfall wrote: On Wed, 21 Feb 2018, Arno Hautala wrote: https://www.tripadvisor.com/LocationPhotoDirectLink-g32810-i36315229-Oakland_California.html I nominate "Portia McCrane - the MacPorts Port Crane". She'll be on shelves in time for the holidays and the hit plush toy craze of the season! Please take careful note of the copyright notice for that image.
Re: glib2 +x11/+quartz
On 2018-02-22 11:33, Jan Stary wrote: > Why is it that one of those variants is required? > Is there any problem with having glib2 without both? The glib2 port uses a MacPorts-specific patch [1] to either use .desktop files (+x11) or macOS app bundles (+quartz) for the GAppInfo API. This has to be selected at build time. One of these has to be used; there is no way to build without this module. The glib2 upstream source without this patch would always use the equivalent of +quartz on macOS, which is not what we want as our ports are not building app bundles. Rainer [1] https://bugzilla.gnome.org/show_bug.cgi?id=781548
Re: distfile downloads failing on https
On 2018-02-21 20:14, Jan Stary wrote: > If I am reading https://guide.macports.org/chunked/reference.phases.html > right, there is are no "fetch dependencies". Would it make sense > to introduce fetch dependencies just like we have build dependencies > and run dependencies, so that the affected ports could specify e.g. curl, > and MP vuld use _that_ for those ports? depends_fetch exists, but apparently is not documented in the guide. However, there should not be individual workarounds in ports, as it is a general problem. Sorry, but your system has become too old to communicate with servers on the internet. You will experience the same problem with more and more servers over time as they begin to require TLS 1.2. The best workaround would be distfile mirroring, as everyone would benefit from that. Most mirrors are still accessible with no TLS or less strict cipher requirements. Rainer
WolfSSL
One of the libraries in MP providing SSL functionality is WolfSSL. Only two other ports mention it: sysutils/gearmand explicitly disables it net/curl has a +wolfssl variant (beside +ssl, +darwinssl, etc). Is anyone using it? Would there be any objections to removing it? While here, curl also knows (and disables) cyassl and polarssl for which we don't have a port. Jan
Re: distfile downloads failing on https
On Feb 22 17:09:22, rai...@macports.org wrote: > On 2018-02-21 20:14, Jan Stary wrote: > > If I am reading https://guide.macports.org/chunked/reference.phases.html > > right, there is are no "fetch dependencies". Would it make sense > > to introduce fetch dependencies just like we have build dependencies > > and run dependencies, so that the affected ports could specify e.g. curl, > > and MP vuld use _that_ for those ports? > > depends_fetch exists, but apparently is not documented in the guide. Thanks for the insight. Currently, nothing is using it, except: these explicitly clear it (why?) ./editors/HexFiend/Portfile:depends_fetch ./editors/textmate2/Portfile:depends_fetch ./python/py-pyobjc-cocoa/Portfile:depends_fetch ./python/py-pyobjc-fsevents/Portfile:depends_fetch and this one declares 'git' as its fetch dependency: ./multimedia/mplayer-devel/Portfile:depends_fetch-append bin:git:git (why don't other git-downloading ports declare it too?) If it is this much unused, wuld it be better to remove it, as opposed to document it and keep it for this one port? > However, there should not be individual workarounds in ports, > as it is a general problem. Understood. But isn't the whole premise of depends_fetch to allow for individual workarounds for ports that need to fetch in a certain way / with a certain tool? > Sorry, but your system has become too old to communicate > with servers on the internet. You will experience the same > problem with more and more servers over time as they begin > to require TLS 1.2. Yes. For now, I am using MP that is rebuilt against a standalone curl that can download from anywhere, as a workaround on these systems. > The best workaround would be distfile mirroring, as everyone would > benefit from that. Most mirrors are still accessible with no TLS or less > strict cipher requirements. I can't wait :-) Thanks again, Jan
Re: distfile downloads failing on https
On Feb 22 19:04:41, h...@stare.cz wrote: > > depends_fetch exists, but apparently is not documented in the guide. > > Thanks for the insight. Currently, nothing is using it, > except: these explicitly clear it (why?) Is there a default nonempty value for depends_fetch that makes these ports want to explicitly clear it? > ./editors/HexFiend/Portfile:depends_fetch > ./editors/textmate2/Portfile:depends_fetch > ./python/py-pyobjc-cocoa/Portfile:depends_fetch > ./python/py-pyobjc-fsevents/Portfile:depends_fetch
Re: WolfSSL
On Feb 22 18:54:18, h...@stare.cz wrote: > One of the libraries in MP providing SSL functionality is WolfSSL. > Only two other ports mention it: > > sysutils/gearmand explicitly disables it > net/curl has a +wolfssl variant (beside +ssl, +darwinssl, etc). > > Is anyone using it? Would there be any objections to removing it? > > While here, curl also knows (and disables) cyassl and polarssl > for which we don't have a port. Very similar story for devel/fbopenssl: ./net/curl/Portfile:depends_lib-append port:fbopenssl ./net/kerberos5/Portfile:conflicts fbopenssl That's it.
Re: Search for a MacPorts Mascot: looking for talented artists
I second. A single port crane, done as a line drawing in the O'Reilly book cover style (possibly anthropomorphized) would work well as a logo and could probably be made into a plush toy if someone really wanted to take it that far. Wouldn't work very well as a halloween/cosplay constume though. I don't know anyone that skinny. On Wed, Feb 21, 2018 at 3:42 PM, Arno Hautala wrote: > On Wed, Feb 21, 2018 at 3:50 PM, David Strubbe > wrote: > > I suggest a port crane (to fit with our name), e.g. > > https://www.tripadvisor.com/LocationPhotoDirectLink- > g32810-i36315229-Oakland_California.html > > I nominate "Portia McCrane - the MacPorts Port Crane". She'll be on > shelves in time for the holidays and the hit plush toy craze of the > season! >
Re: distfile downloads failing on https
On Feb 21, 2018, at 13:14, Jan Stary wrote: > > Would it make sense > to introduce fetch dependencies just like we have build dependencies > and run dependencies, so that the affected ports could specify e.g. curl, > and MP vuld use _that_ for those ports? As was mentioned, depends_fetch exists. There is usually no need for ports to specify it since MacPorys base does so automatically based on fetch.type. MacPorts fetches from ftp/http/https servers using the libcurl it was configured and compiled with. No amount of changing the fetch dependencies will change that. MacPorts base contains no code for using the curl *program*, only for using the curl *library*, and it will always use the library it was compiled with.
Re: Search for a MacPorts Mascot: looking for talented artists
On Feb 22 12:31:24, billc_li...@greenbuilder.com wrote: > A single port crane, done as a line drawing in the O'Reilly book cover > style (possibly anthropomorphized) would work well as a logo and could > probably be made into a plush toy if someone really wanted to take it that > far. A plush toy of a port crane is what MP is missing.
Re: WolfSSL
On Feb 22 18:54:18, Jan Stary wrote: > One of the libraries in MP providing SSL functionality is WolfSSL. > Only two other ports mention it: > > sysutils/gearmand explicitly disables it > net/curl has a +wolfssl variant (beside +ssl, +darwinssl, etc). > > Is anyone using it? Would there be any objections to removing it? > > While here, curl also knows (and disables) cyassl and polarssl > for which we don't have a port. cyassl was added in 2012 after its developer submitted a portfile to us: https://trac.macports.org/ticket/35663 The cyassl port was renamed to wolfssl in 2016: https://trac.macports.org/ticket/50214 woflssl support was added to the curl port at a user's request: https://trac.macports.org/ticket/52615 A port for polarssl was requested in 2016: https://trac.macports.org/ticket/51059 A user specifically requested polarssl support for curl: https://trac.macports.org/ticket/52681 The polarssl project has since changed its name to mbedtls. On Feb 22, 2018, at 12:20, Jan Stary wrote: > Very similar story for devel/fbopenssl: > > ./net/curl/Portfile:depends_lib-append port:fbopenssl > ./net/kerberos5/Portfile:conflicts fbopenssl > > That's it. fbopenssl has been with us for a long time already; it was added in 2005: https://github.com/macports/macports-ports/commit/38f644ca3e621b1cf1a50f658c05beea71f5ed64 No ticket number or other explanation was given in the commit message, but the port's description says it is a library of extensions to openssl to support spnego. It is not a replacement for openssl; in fact, it depends on openssl. It looks like it was specifically added to MacPorts in order to allow curl to use it, since the curl spnego variant was added in the next commit: https://github.com/macports/macports-ports/commit/6dce150016eab8a9b9c606a7d62421571eed979a
Re: lowdown not helped by snowleopardfixes
The fix: https://trac.macports.org/ticket/55878
Re: distfile downloads failing on https
On 2018-02-21, at 11:14 AM, Jan Stary wrote: >> You are done. No more circular dependency. > > Yes. One installation of MP depends on another installation. > That's not circular. CIrcular is when an installation of MacPorts depends on itself, and is therefore fragile. The installation of libcurl in /opt/bootstrap is fully independent of the one in /opt/local, and is not fragile. I say this so as not to dissuade all those out there with broken MacPorts installations from using this method. I believe it is presently the only reliable method of getting a generally working MacPorts installation that can download all distfiles on older systems until either distfile mirroring is fixed, or until we bundle in libcurl. Ken
Re: distfile downloads failing on https
On Feb 22, 2018, at 20:04, Ken Cunningham wrote: > or until we bundle in libcurl. Note that bundling libcurl is insufficient to fix the issue; we would have to bundle an ssl library too, and there was an objection that we don't want to be in the business of needing to quickly release a new version of MacPorts when a new vulnerability in that ssl library is found. https://trac.macports.org/ticket/51516#comment:23
