Re: Factors determining binary archivability

In this particular case, Blender's add-ons are truly "add-ons"... it's actually fairly easy in the CMake scripts to exclude the add-ons from being copied into Blender's final application bundle; and even if the add-ons are excluded from the distribution, it doesn't affect Blender's core

Re: Factors determining binary archivability

Yes, that's why I said that the python scripts that make up the add-ons aren't actually part of Blender's compiled binaries. They get copied over into the application bundle as plain text files during the build process, and get invoked (i.e. interpreted) when they are selected from within

Re: Factors determining binary archivability

Bear in mind also that a program being written in an interpreted language doesn't change the requirements of the GPL. What's less clear is when a combined work is considered to be created in that case: At runtime? When byte-compilation occurs? As soon as the import statement is typed in the source

Re: Factors determining binary archivability --> OpenSSL 3.0 is coming along with a new license

OpenSSL 3.0 has a new, more compatible license. It is coming along. Alpha5 released July 16. https://www.mail-archive.com/openssl-users@openssl.org/msg88452.html

Re: Factors determining binary archivability

Just in case it wasn't considered: Python modules can also be compiled. Matching on "ext_modules" in either setup.py or build.py should be a good indicator of this situation. https://docs.python.org/3/distutils/setupscript.html#describing-extension-modules On 9/8/20 10:29 PM, Jason Liu

Re: Factors determining binary archivability

On 2020-9-9 12:29 , Jason Liu wrote: > I dug through Blender's source code, and AFAICT, Blender doesn't > directly use any part of OpenSSL. There are no references to any of > OpenSSL's header files, nor any references to libcrypto, libssl, etc. > Blender also doesn't directly do anything

Re: Factors determining binary archivability (GPL-compatible alternative?)

On 2020-9-9 12:22 , Christopher Chavez wrote: > Joshua Root (2020-09-09 00:34): >> On 2020-9-9 05:08 , Jason Liu wrote: >>> Does this mean that the Blender port is yet another victim of The Curse >>> of the OpenSSL License? > >> Yes (though you could equally call it the Curse of the GPL, as both

Re: Factors determining binary archivability

I dug through Blender's source code, and AFAICT, Blender doesn't directly use any part of OpenSSL. There are no references to any of OpenSSL's header files, nor any references to libcrypto, libssl, etc. Blender also doesn't directly do anything involving HTTPS or hashes. All of Blender's add-ons

Re: Factors determining binary archivability (GPL-compatible alternative?)

Joshua Root (2020-09-09 00:34): > On 2020-9-9 05:08 , Jason Liu wrote: >> Does this mean that the Blender port is yet another victim of The Curse >> of the OpenSSL License? > Yes (though you could equally call it the Curse of the GPL, as both are responsible). An idea I haven't seen mentioned

Re: Factors determining binary archivability

On 2020-9-9 05:08 , Jason Liu wrote: > At this point, it looks like the vast majority of builds for Blender > have either succeeded or failed, according to the status at > https://ports.macports.org/port/blender/builds. Digging through the logs > of the builders, I encountered this message in the

where to find darwintest.h and the rest of the Apple darwin testing infrastructure?

I’m trying to upgrade the testing for legacy-support, and I thought I might try to bring in some of Apple’s existing testing files, eg > for the new futimens

Re: Travis CI timeouts for MacPorts builds

On Tue, 8 Sep 2020 at 19:25, Ralph Seichter wrote: > > * Mojca Miklavec: > > >> If I can assist, let me know, but I don't think it likely at this > >> point. > > > > Because you lack time or for some other reason? > > I would make the time for MacPorts. My assumption is just that I still > know to

Re: Travis CI timeouts for MacPorts builds

On Tue, 8 Sep 2020 at 22:43, Clemens Lang wrote: > On Tue, Sep 08, 2020 at 06:48:58PM +, Zero King wrote: > > On Tue, Sep 08, 2020 at 06:39:41PM +0200, Mojca Miklavec wrote: > > > After a while Azure came around with 6 hours of timeout which was a > > > lot more useful, and the same solution

Re: Travis CI timeouts for MacPorts builds

Hi, On Tue, Sep 08, 2020 at 06:48:58PM +, Zero King wrote: > On Tue, Sep 08, 2020 at 06:39:41PM +0200, Mojca Miklavec wrote: > > After a while Azure came around with 6 hours of timeout which was a > > lot more useful, and the same solution was ported from Travis to > > Azure. I forgot why we

Re: Travis CI timeouts for MacPorts builds

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, thank you very much! I'm just confused about one thing.

Re: Travis CI timeouts for MacPorts builds

On Tue, 8 Sep 2020 at 19:11, Ralph Seichter wrote: > > * Ryan Schmidt: > > >> Tries being the operative word here. ;-) > > > > What are you trying to say? > > Did I step on somebody's toes? I'm not aware why you would step on anyone's toes, but I also didn't understand what you tried to say in

Re: Factors determining binary archivability

At this point, it looks like the vast majority of builds for Blender have either succeeded or failed, according to the status at https://ports.macports.org/port/blender/builds. Digging through the logs of the builders, I encountered this message in the "gather-archives" step: "blender" is not

Re: Travis CI timeouts for MacPorts builds

Hello, On Tue, Sep 08, 2020 at 06:39:41PM +0200, Mojca Miklavec wrote: On Mon, 7 Sep 2020 at 20:25, Ralph Seichter wrote: If you ignore Travis results, why run Travis CI in the first place? Travis was the first CI that we supported for pull requests. @l2dy wrote the initial support as a GSOC

Re: Travis CI timeouts for MacPorts builds

* Mojca Miklavec: >> If I can assist, let me know, but I don't think it likely at this >> point. > > Because you lack time or for some other reason? I would make the time for MacPorts. My assumption is just that I still know to little about how the MacPorts builds work to be of assistance, and

Re: Travis CI timeouts for MacPorts builds

* Ryan Schmidt: >> Tries being the operative word here. ;-) > > What are you trying to say? Did I step on somebody's toes? I am saying that the build that concerns me timed out setting up the dependencies. That, from my understanding, means the dependencies were either unavailable in binary

Re: Travis CI timeouts for MacPorts builds

On Sep 8, 2020, at 11:39, Mojca Miklavec wrote: > On Tue, 8 Sep 2020 at 18:28, Ryan Schmidt wrote: >> On Sep 7, 2020, at 11:24, Ruben Di Battista wrote: >> >>> Would à Linux machine with some virtualization method (libvirt?) be >>> acceptable as CI runner? >> >> I can't see how, since we're

Re: Travis CI timeouts for MacPorts builds

On Sep 7, 2020, at 13:25, Ralph Seichter wrote: > * Mojca Miklavec: > >> It tries to install dependencies as binaries, provided the binaries >> are available. > > Tries being the operative word here. ;-) What are you trying to say? It uses binary archives if available, and they should be

Re: Travis CI timeouts for MacPorts builds

On Mon, 7 Sep 2020 at 20:25, Ralph Seichter wrote: > * Mojca Miklavec: > > > We should figure out: > > - which dependencies time out > > - why they are not installed from (the private) binary package repository > > I'm guessing that "we" means the devs who maintain the build config. Oh, no,

Re: Travis CI timeouts for MacPorts builds

On Sep 7, 2020, at 11:24, Ruben Di Battista wrote: > Would à Linux machine with some virtualization method (libvirt?) be > acceptable as CI runner? I can't see how, since we're trying to verify builds of ports, and there is no general expectation that port builds would work on non-Mac