Re: New bali-phy version

Hi Ben, Thank you for your message to alert me to a newer version of BAli-Phy. Generally we only package stable releases as the “main” port, as such the “bali-phy” port install version 3.6.1. Having said that, there is certainly an option to add a “-devel” port that follows upstream's (i.e.,

Re: Python updates, news, and policy

Thanks Josh - sounds good to me. I am just wondering whether it would be worthwhile to add one more variable to the python PG, perhaps “python.pep517_backend” that would support the commonly used backends you mentioned (perhaps defaulting to setuptools) and add its required dependencies?

Re: [10.6.8] MySQL 5.7.36_1 compile hell

Please don’t use the mailing list for this stuff - Trac is the appropriate medium for this IMHO… > On Dec 20, 2021, at 9:17 AM, Bjarne D Mathiesen > wrote: > > I've got the main.log files for the following attempts > > root@MiniWeb 14:56:09 ~ > #=> ls -l MySQL57/ > total 3728 > -rw-r--r--

Re: perl 5.34 branch

There is an open PR for that: https://github.com/macports/macports-ports/pull/11534 . I am not sure if there are unresolved issues (it needs to be rebased for sure) or if we’re just waiting for the backlog of the buildbots after to change

Re: upgrade to openssl 3.0.0

mode was somehow missed; > it has to be specifically turned on in openssl3, but it does allow more > things to work with openssl3 I believe. > > Ken > > > > >> On Nov 6, 2021, at 6:34 AM, Renee Otten > <mailto:ottenr.w...@gmail.com>> wrote: >> &

Re: upgrade to openssl 3.0.0

Dear all, Chris has done the work to add the openssl3 port and openssl-1.0 PortGroup to ease the transition towards openssl v3. There is now an open PR (https://github.com/macports/macports-ports/pull/12807 ) to switch en masse the

Re: upgrade to openssl 3.0.0

I guess it would be helpful if the maintainers of openssl would chime in and let us know what they plan to do regarding the update. It’s unfortunate that Ken his attempts to get this moving are being shut down so quickly and he doesn’t feel motivated anymore to work on this… The main goal

Re: Packaging py-keyring

The versioning caps that poetry has seem very strict and at least in the case of keyring unnecessarily strict. I would definitely not want to create a “py-keyring20” (sub)port, because that effectively will mean you’ll have to create a new subport ever time upstream decides that they want to

msgpack port

dear all, a while ago I submitted a PR to consolidate the different versions of “msgpack” into one port (https://github.com/macports/macports-ports/pull/5986 ). Currently, we provide version 0.5.9 as “msgpack” and version 1.4.2 as

Re: AWS SAM CLI - Looking for help

In addition to “pypi2port”, there is also this years GSoC project that implemented an MacPorts backend for UPT (the Universal Packaging Tool). It should do at minimum the same as “pypi2port” and hopefully more ;) The same tool can be used to package perl and ruby packages as well, and supports

Re: error: thread-local storage is not supported

ild, something weird must be > going on to make this build ignore base. > > That's what I'll have to help sort out, using a VM or real system running > those OS versions. > > Ken > > > > On 2019-11-21, at 9:35 AM, Renee Otten wrote: > >> hi Ken, >>

Re: error: thread-local storage is not supported

. For now I think I’ll just switch the option off for older OS X versions or try to blacklist Clang < 7 and see it that helps. Thanks, Renee > On Nov 20, 2019, at 10:22 PM, Joshua Root wrote: > > On 2019-11-21 13:38 , Renee Otten wrote: >> dear all, >> >> &

error: thread-local storage is not supported

dear all, one of the PRs I just merged (https://github.com/macports/macports-ports/pull/5848 ) fails on OS X 10.8, 10.9, and 10.10 with the error "error: thread-local storage is not supported for the current target” (with AppleClang

Re: CI pipilene has a "sudo" problem

I think having a working Travis CI and/or Azure pipelines is important. As a temporary workaround for the current issues [1], I suggest to commit the change in PR 5767 [2]. I intend to merge that PR tomorrow morning (i.e., in 10 hours or so), unless someone has a better solution or if any

Re: *-graveyard ports retired

If the conclusion is that replacements from, for example, py34- to py35- are not useful (as it appears from https://trac.macports.org/ticket/59051 ) then this change seems fine to me. In that case we should recommend maintainers (likely in the guide or

Re: GSoC Proposal

on/py-upt/Portfile > [2] > https://github.com/Korusuke/macports-ports/blob/9d7f1995dfb44f693f90a79f91d8695b9dd7feac/python/py-spdx-lookup/Portfile > [3] > https://github.com/Korusuke/macports-ports/blob/9d7f1995dfb44f693f90a79f91d8695b9dd7feac/python/py-spdx/Portfile > > On Tue,

Re: GSoC Proposal

> I generated a portfile for py-upt and tried installing that after a few > manual edits, which will actually be automated in the future. > It did install properly without any errors but I guess there's some issue > with the path and because of which it was unuseable, once I figure this out >

Re: GSoC Proposal

hi Karan, Mojca, Cyril, I am happy to help with testing and provide feedback. I quickly glanced over the proposal draft and agree with what Cyril said; in addition, there is a figure showing a WebUI that is not described (personally I am not sure if that would be needed anyway). I agree

Re: GSoC Proposal

Thank Cyril! I have looked at your repository of upt and Mojca’s initial backend already; however, it would be helpful to be able to see the repository/commits of the GSoC student. > On Mar 31, 2019, at 2:50 PM, Cyril Roelandt > wrote: > > Hello, > > On 2019-03-31 13:26,

Re: GSoC Proposal

hi Karan, where is your repository for this project? I wanted to take a look and possibly provide some feedback specifically for the Python ports, but have a hard time finding it… Thanks, Renee > Date: Sat, 30 Mar 2019 15:46:28 +0530 > From: KARAN SHETH > To: Cyril Roelandt > Cc:

how to deal with large data files

I am looking for some advice on how to deal with a port that will only download a large data set (~5GB), see https://github.com/macports/macports-ports/pull/3904 . I assume we do not necessarily want to have that stored on the MacPorts

Re: [macports-ports] 01/02: py-alabaster: obsolete py26 and py33 subports

dear Ryan, thank you for keeping a close eye on things, especially useful for newbies like me who try to do the correct thing but not always succeed... > On May 25, 2018, at 3:48 PM, Ryan Schmidt wrote: > > Replacement doesn't work (doesn't show up in "port

port versus path dependency declaration

I am trying to understand why in some Python ports the run dependencies are declared using path instead of port statements - is there an advantage/preference for one over the other? For example, in the py-spyder-devel Portfile (but also the py-autopep8, which I recently updated) it uses:

Re: Python port best-practice?

> On Apr 26, 2018, at 11:41 AM, Joshua Root wrote: > > On 2018-4-27 01:34 , Ryan Schmidt wrote: >> >> At this time, I probably wouldn't use older versions than 2.7 or 3.5. We >> have been phasing 3.3 and 3.4 modules out. > > Both 3.4 and 3.5 are in security fixes only

Python port best-practice?

I am looking at updating some (nonmaintained) python ports and have two questions for now: 1. if a project releases both on GitHub and PyPI is there a preference for using one over the other in Portfiles? 2. is there a MacPorts policy regarding subports (e.g., add subports for all Python