Re: Factors determining binary archivability

Yes, I'm aware. I specifically use the "-DWITH_PYTHON_INSTALL=OFF" flag in my portfile, because with that option set to ON, Blender will copy the entire system python distribution into its application bundle, including the ssl and hashlib python modules, which as you said would be problematic, sinc

Re: Factors determining binary archivability

On 2020-9-9 16:49 , Joshua Root wrote: > On 2020-9-9 15:37 , Jason Liu wrote: >> By the way, Blender Foundation itself, as well as most Linux distros, >> don't seem to have an issue distributing Blender (or other software >> apps, for that matter) as a pre-compiled binary package. Why does the >> M

Re: Travis CI timeouts for MacPorts builds

On Sep 9, 2020, at 06:31, Zero King wrote: > However, GitHub Actions does not provide a list of IP addresses > AFAIK, so integration with paste.macports.org would be difficult. Maybe > I should just use the other pastebin and hardcode the URL into mpbot-ci > to avoid it being inherited in macpo

Re: Factors determining binary archivability

> > The automated check naturally errs on the side of caution. If you can > show that there is in fact no use of openssl from this GPL'd code, it > can be marked as non-conflicting. > I'm fairly certain that this is the case for Blender. In fact, in Blender's CMake scripts, there are references to

Re: Travis CI timeouts for MacPorts builds

On Tue, Sep 08, 2020 at 10:12:08PM +0200, Mojca Miklavec wrote: On Tue, 8 Sep 2020 at 20:49, Zero King wrote: > I forgot why we never switched from Azure to GitHub Actions. Done in commit db7b40d8691e1fcd8b6be5e3c2a2a00a7ce0bdf4. We should remove Travis CI and Azure Pipelines soon. Awesome,

Re: "publishing" Tcl support functions used in Portfiles?

On Monday September 07 2020 22:39:50 Joshua Root wrote: Hi, >You do it like this: > > >In that proc, $mport is an identifier that was returned from mportopen, >and the code being executed in the port's