Re: BLENDER 2.79

[Tomasz CEDRO]

On Sat, Apr 25, 2020 at 11:24 AM Shane Ambler wrote:
> I have updated my redports copy of blender279 to use python 3.6. The
> change is only making it find the new version, this builds and passes
> limited testing. I will rely on you testing it to suit your needs to see
> if I need to make any other patches for py36.
>
> The question now is whether we want to submit blender279/oiio18 as
> official ports for some time or whether you keep it as a private port.

Shane you are the best! Thank you!! I guess it should work with Python
3.6 with no problem. I usually add numpy and stuff like that locally
and work on top of that :-)

For me (and maybe other blender users) it would be best to have
Blender 2.79 in ports tree and in PKG repository. Thus my question if
we can include it. But if that is a big problem I can build it on my
own as I did so far.

If possible we could include it in the official ports tree and with
first bigger maintenance problem we can remove it. I will respect any
of your decisions :-)


> Have you looked at devel/godot-tools?
> The GDScript it uses internally is very similar to python, so is a quick
> learning curve. There is also a visual node-based scripting. While there
> is C# support, I don't have that working in FreeBSD yet, the mono port
> update in bugs.freebsd comes close.
>
> It is common for godot developers to use blender for 3d assets.

Yes I got a glance at this new approach and none of them compares to
workflow of BGE that was included with Blender - I could run only
Blender on a base X server with absolutely no other applications and I
got everything bundled inside a file explorer, 3D object and scene
modeller, image and animation exporter / editor, text editor, python
shell, and game engine that would run my application by simply
pressing 'P' key, then by pressing 'Esc' I got back into editor in the
same window. Everything was done with Python in the same window that I
could split into planes, including programming, debugging, modelling,
even visual block setup. This project was stared in 1994  and I was
always amazed on how well architected it was in every detail. Even
*.blend files included "DNA" header with data structures definitions
that allowed project import/export between different versions of the
software. It could even export your project bundle with a
blender-player into a fully standalone one file binary for a given
system. Blender also could very easily (one click or cli parameter)
run such application with a stereoscopy picture using different
techniques.

I am sure it could (and still can) run on a bare Wayland as it has its
own GUI components rendered at once in whole screen. That was
initially a goal for network transparency optimization, but they
predicted what will happen with display methods in 20 years quite
well.

This was really perfect all-in-one swiss-army-knife environment for VR
development. But it had this 80/90's coherent design approach which
seems to be gone now thanks to all of those UX/UI
artistic-engineering-change-is-good-think-later kids. They have no
principal understanding of the core concepts of engineering but they
do already change our world. Blender its just another 3D application
castrated of its core functionality that made it unique. Also it
follows modern approach of workflow distraction and complication. Thus
my mixed feelings. Maybe one day I will adapt it to my needs again.

I know there are different 3D engines, far better than BGE in many
ways could ever be (it was old, slow, ugly, and buggy as hell I know),
but yet nothing compares to integrated all-in-one-place workflow that
I had with Blender 2.79- described above. Now I need to have whole set
of external tools, exporters, formats, and they use different
programming languages, then I need to export it again. Not to mention
missing features, bugs, etc. I don't really need and have no time for
all of this. If I wanted a workflow like this I would long time ago
switch to Unity. I also daily work on electronics design and
prototyping, firmware development, os stuff, web development,
sometimes mobiles. I just need things that work and offload tons of
crap from my head. Blender was doing its job sufficiently well for my
needs even with this nasty BGE :-)


Long story short: Thank you Shane for keeping and providing the old
port for Blender in your red-pots. It will be great to try out Blender
2.79 with currently supported Python 3.6 in place of older 3.5. If we
could bundle Blender 2.79 into FreeBSD's Ports and PKG with no big
trouble, until first bigger issues arise, that would be great, but I
will respect any of the team decision :-)

Best regards :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BLENDER 2.79

[Shane Ambler]

On 19/4/20 10:12 pm, Adam Weinberger wrote:
> On Sat, Apr 18, 2020 at 10:45 PM Shane Ambler  wrote:
>>
>> On 19/4/20 6:15 am, Adam Weinberger wrote:
>>> On Sat, Apr 18, 2020 at 2:31 PM Tomasz CEDRO  wrote:
>>>>
>>>> Hello world :-)
>>>>
>>>> I have been using Blender-2.79 from Shane's Red Ports repository on
>>>> GitHub because Blender since version 2.80 (current port is 2.82)
>>>> unfortunately removed the Blender Game Engine (BGE) which I am using
>>>> for work.
>>
>> Also note that 2.79 uses python 3.5 which is EOL 9/2020 - ~5 months
>> https://devguide.python.org/#status-of-python-branches
>>
> Shane, if you are able to provide and support a 2.79 port, I'd be
> thrilled to see it in the tree.
>>
>>> back unsupported and unmaintained older versions of software isn't a
>>> path we go down very often. If Blender were a trivial build, it'd be
>>> more feasible, but the complexity of the maintenance burden is
>>> difficult to overcome.
>>
>> I personally maintain several blender versions, mostly to allow testing.
>> Usually there is little effort, I stop updating older versions as
>> dependent ports get dropped and patching gets too much, now at 2.77+.
>> I make these publicly available on github not as official ports.
>>
>> The main concern with having a second blender port for 2.79 is the
>> python35 EOL in five months.
> 
> Is py35 a hard dep for 2.79 or can that be adjusted to 3.5+?

Each blender version is only tested with and officially only supports
one python version. There are no conditionals to build with what's
available.

I have updated my redports copy of blender279 to use python 3.6. The
change is only making it find the new version, this builds and passes
limited testing. I will rely on you testing it to suit your needs to see
if I need to make any other patches for py36.

The question now is whether we want to submit blender279/oiio18 as
official ports for some time or whether you keep it as a private port.

-- Tomasz,
Have you looked at devel/godot-tools?
The GDScript it uses internally is very similar to python, so is a quick
learning curve. There is also a visual node-based scripting. While there
is C# support, I don't have that working in FreeBSD yet, the mono port
update in bugs.freebsd comes close.

It is common for godot developers to use blender for 3d assets.


-- 
FreeBSD - the place to B...Software Developing

Shane Ambler

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BLENDER 2.79

[Tomasz CEDRO]

On Sun, Apr 19, 2020 at 2:43 PM Adam Weinberger wrote:
> On Sat, Apr 18, 2020 at 10:45 PM Shane Ambler wrote:
> > > On Sat, Apr 18, 2020 at 2:31 PM Tomasz CEDRO wrote:
> > >> My question is can we include both Blender-2.79 and UPBGE in the
> > >> official ports tree next to official Blender release? All dependencies
> > >> are provided,
> >
> > Actually you also need the older openimageio18 port.
> > (..)
> > The need to support an older blender version only relies on the use of
> > the game engine, having started a project using the 2.79 BGE it is not
> > nice to have to start from scratch. This would be the reason to support
> > 2.79 in ports. Unfortunately only one person has shown interest in the
> > nine months since 2.80 was released.
>
> No, I certainly get it. As awesome as Eevee is, it's a completely
> different paradigm from the internal renderer, and BGE has no analogue
> at all in 2.8x. There's really only three solutions here: (1) We have
> a way for Tomasz to install 2.79, (2) Tomasz starts over using a
> different toolkit, or (3) Tomasz moves to a platform where running
> 2.79 is trivial. Clearly, (1) is the best possible option.
>
> Shane, if you are able to provide and support a 2.79 port, I'd be
> thrilled to see it in the tree.

Thank you guys! The port and dependencies are already out there ready
for use - once again thank you Shane - yesterday it took ma around
hour to build it all. It would be nice however to have it installed
with just `pkg install blender279` just as on the other platforms.
When maintenance become a problem I will abandon Blender until then I
should have things sorted out.. for instance when we cannot replace
Python 3.5 with 3.6+ and that would mess other ports :-)

> > If you are planning to release your project, you also need to consider
> > support for 2.79 on other systems as well.

On the other platforms I can simply install older version. But I
prefer to have everything on my FreeBSD box and keep myfocus here
rather than having multiple machines for various tasks. This way we
can push forward the functionality and versality of the FreeBSD. I had
my lefts and rights but I always come back to FreeBSD at the end.. so
why not focus here?

Also I can show that all my work is Open-Source BSD based co it can be
closed source safely (at least some parts) :-) I planned to put that
setup on an embedded system and use that as standalone application.
Thus my recent interest in Wayland as faster and smaller replacement
for Xorg.

I know about EEVIE in Blender 2.80+. If there is a way to control it
with Python in Real-Time then I could switch to that way of
operations, but first I need to finish core of my work, then I can
think of moving into different render method or external engine. I am
using it for engineering and simulation purposes, not really gaming.
That was the only Open-Source utility that allowed me to put a Python
code and connect real world sensors with a virtual reality with a
single key stroke. Not to mention modelling and 3D conversions.
Everything changes and eventually I will move forward and invento some
other solution but first things first needs to be finished :-)

Thank you! :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BLENDER 2.79

[Adam Weinberger]

On Sat, Apr 18, 2020 at 10:45 PM Shane Ambler  wrote:
>
> On 19/4/20 6:15 am, Adam Weinberger wrote:
> > On Sat, Apr 18, 2020 at 2:31 PM Tomasz CEDRO  wrote:
> >>
> >> Hello world :-)
> >>
> >> I have been using Blender-2.79 from Shane's Red Ports repository on
> >> GitHub because Blender since version 2.80 (current port is 2.82)
> >> unfortunately removed the Blender Game Engine (BGE) which I am using
> >> for work.
> >>
> >> The only solution so far is to use older Blender2.79 that still has
> >> the BGE. Blender developers just removed something with no alternative
> >> and no plan for alternative. Luckily I found Shane's repository that
> >> provides port for older version.
> >>
> >> Another solution is to have UPBGE Blender 2.80 fork with experimental
> >> and refreshed BGE included, unfortunately the BGE API has changed and
> >> it is not backward-compatible.
> >>
> >> My question is can we include both Blender-2.79 and UPBGE in the
> >> official ports tree next to official Blender release? All dependencies
> >> are provided,
>
> Actually you also need the older openimageio18 port.
>
> Also note that 2.79 uses python 3.5 which is EOL 9/2020 - ~5 months
> https://devguide.python.org/#status-of-python-branches
>
> >> all of them works fine next to each other. It would be
> >> really handy to have at least Blender-2.79 from PKG.
> >>
> >> https://github.com/sambler/sambler-redports/tree/master/graphics/blender279
> >> https://github.com/sambler/sambler-redports/tree/master/graphics/upbge
> >
> > BGE is gone and done, and in most cases FreeBSD does not keep old
> > versions of ports around, and that's especially true for massive and
> > complex projects like Blender.
>
> The need to support an older blender version only relies on the use of
> the game engine, having started a project using the 2.79 BGE it is not
> nice to have to start from scratch. This would be the reason to support
> 2.79 in ports. Unfortunately only one person has shown interest in the
> nine months since 2.80 was released.

No, I certainly get it. As awesome as Eevee is, it's a completely
different paradigm from the internal renderer, and BGE has no analogue
at all in 2.8x. There's really only three solutions here: (1) We have
a way for Tomasz to install 2.79, (2) Tomasz starts over using a
different toolkit, or (3) Tomasz moves to a platform where running
2.79 is trivial. Clearly, (1) is the best possible option.

Shane, if you are able to provide and support a 2.79 port, I'd be
thrilled to see it in the tree.

> If you are planning to release your project, you also need to consider
> support for 2.79 on other systems as well.
>
> > When UPBGE matures it'd be great to have it in the tree, but bringing
>
> I have submitted a port for upbge, following the blender 2.8x branch,
> while it is considered pre-release, it is only the game engine that is
> under development, the remainder should match the relevant blender
> release. The master branch is still based on 2.79 and would need the
> older openimageio as well.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244535
>
> > back unsupported and unmaintained older versions of software isn't a
> > path we go down very often. If Blender were a trivial build, it'd be
> > more feasible, but the complexity of the maintenance burden is
> > difficult to overcome.
>
> I personally maintain several blender versions, mostly to allow testing.
> Usually there is little effort, I stop updating older versions as
> dependent ports get dropped and patching gets too much, now at 2.77+.
> I make these publicly available on github not as official ports.
>
> The main concern with having a second blender port for 2.79 is the
> python35 EOL in five months.

Is py35 a hard dep for 2.79 or can that be adjusted to 3.5+?

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BLENDER 2.79

[Shane Ambler]

On 19/4/20 6:15 am, Adam Weinberger wrote:
> On Sat, Apr 18, 2020 at 2:31 PM Tomasz CEDRO  wrote:
>>
>> Hello world :-)
>>
>> I have been using Blender-2.79 from Shane's Red Ports repository on
>> GitHub because Blender since version 2.80 (current port is 2.82)
>> unfortunately removed the Blender Game Engine (BGE) which I am using
>> for work.
>>
>> The only solution so far is to use older Blender2.79 that still has
>> the BGE. Blender developers just removed something with no alternative
>> and no plan for alternative. Luckily I found Shane's repository that
>> provides port for older version.
>>
>> Another solution is to have UPBGE Blender 2.80 fork with experimental
>> and refreshed BGE included, unfortunately the BGE API has changed and
>> it is not backward-compatible.
>>
>> My question is can we include both Blender-2.79 and UPBGE in the
>> official ports tree next to official Blender release? All dependencies
>> are provided, 

Actually you also need the older openimageio18 port.

Also note that 2.79 uses python 3.5 which is EOL 9/2020 - ~5 months
https://devguide.python.org/#status-of-python-branches

>> all of them works fine next to each other. It would be
>> really handy to have at least Blender-2.79 from PKG.
>>
>> https://github.com/sambler/sambler-redports/tree/master/graphics/blender279
>> https://github.com/sambler/sambler-redports/tree/master/graphics/upbge
> 
> BGE is gone and done, and in most cases FreeBSD does not keep old
> versions of ports around, and that's especially true for massive and
> complex projects like Blender.

The need to support an older blender version only relies on the use of
the game engine, having started a project using the 2.79 BGE it is not
nice to have to start from scratch. This would be the reason to support
2.79 in ports. Unfortunately only one person has shown interest in the
nine months since 2.80 was released.

If you are planning to release your project, you also need to consider
support for 2.79 on other systems as well.

> When UPBGE matures it'd be great to have it in the tree, but bringing

I have submitted a port for upbge, following the blender 2.8x branch,
while it is considered pre-release, it is only the game engine that is
under development, the remainder should match the relevant blender
release. The master branch is still based on 2.79 and would need the
older openimageio as well.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244535

> back unsupported and unmaintained older versions of software isn't a
> path we go down very often. If Blender were a trivial build, it'd be
> more feasible, but the complexity of the maintenance burden is
> difficult to overcome.

I personally maintain several blender versions, mostly to allow testing.
Usually there is little effort, I stop updating older versions as
dependent ports get dropped and patching gets too much, now at 2.77+.
I make these publicly available on github not as official ports.

The main concern with having a second blender port for 2.79 is the
python35 EOL in five months.

-- 
FreeBSD - the place to B...Software Developing

Shane Ambler

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BLENDER 2.79

[Kevin Oberman]

On Sat, Apr 18, 2020 at 1:57 PM Marcin Cieslak  wrote:

> On Sat, 18 Apr 2020, Adam Weinberger wrote:
>
> > On Sat, Apr 18, 2020 at 2:31 PM Tomasz CEDRO  wrote:
> >>
> >
> > BGE is gone and done, and in most cases FreeBSD does not keep old
> > versions of ports around, and that's especially true for massive and
> > complex projects like Blender.
>
> But I think we keep different port version around on major API changes
> for a while. Not to mention things like node that can have up to 4 versions
> in the ports tree.
>
> Whatever is the future of BGE, one should simply not lose the functionality
> by doing "pkg upgrade". Not sure this even made into UPDATING
>
> Marcin


While a packaged blender-2.79 is unlikely, the port is still available from
subversion. Just be sure you keep a copy of the distribution.

Yes, it's a huge build, but you really only need to package it once. Unless
it is forked, it's likely abandoned so bitrot will get it some day. At
least it's unlikely to change a lot, so you would not have to package it
often other than after major releases or when a shareable dependency is
updated.

Note, I don't use blender, though I find it impressive!
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BLENDER 2.79

[Marcin Cieslak]

On Sat, 18 Apr 2020, Adam Weinberger wrote:


On Sat, Apr 18, 2020 at 2:31 PM Tomasz CEDRO  wrote:




BGE is gone and done, and in most cases FreeBSD does not keep old
versions of ports around, and that's especially true for massive and
complex projects like Blender.


But I think we keep different port version around on major API changes
for a while. Not to mention things like node that can have up to 4 versions
in the ports tree.

Whatever is the future of BGE, one should simply not lose the functionality
by doing "pkg upgrade". Not sure this even made into UPDATING

Marcin

smime.p7s
Description: S/MIME Cryptographic Signature

Re: BLENDER 2.79

[Tomasz CEDRO]

On Sat, Apr 18, 2020 at 10:45 PM Adam Weinberger  wrote:
> BGE is gone and done, and in most cases FreeBSD does not keep old
> versions of ports around, and that's especially true for massive and
> complex projects like Blender.
>
> When UPBGE matures it'd be great to have it in the tree, but bringing
> back unsupported and unmaintained older versions of software isn't a
> path we go down very often. If Blender were a trivial build, it'd be
> more feasible, but the complexity of the maintenance burden is
> difficult to overcome.
> # Adam

Hello Adam and thank you for quick response :-)

Well I don't like the situation either as this destroys core of my
work that I have created for years. I never suspected anything like
this from Open-Source (except the work is sponsored by competitor).
The alternative is not to use Blender anymore. And I have been using
it since 2000 :-(

Even Blender Development Team suggests using 2.79 to have BGE working.

UPBGE is not really mandatory as it is incompatible with BGE.

All dependencies have their own dedicated separate ports. I have been
using it for months now and it seems to be in align with other ports
with no conflicts.

But if this is a problem and risk I can understand and will stick to
build it on my own..

Best regards,
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: BLENDER 2.79

[Adam Weinberger]

On Sat, Apr 18, 2020 at 2:31 PM Tomasz CEDRO  wrote:
>
> Hello world :-)
>
> I have been using Blender-2.79 from Shane's Red Ports repository on
> GitHub because Blender since version 2.80 (current port is 2.82)
> unfortunately removed the Blender Game Engine (BGE) which I am using
> for work.
>
> The only solution so far is to use older Blender2.79 that still has
> the BGE. Blender developers just removed something with no alternative
> and no plan for alternative. Luckily I found Shane's repository that
> provides port for older version.
>
> Another solution is to have UPBGE Blender 2.80 fork with experimental
> and refreshed BGE included, unfortunately the BGE API has changed and
> it is not backward-compatible.
>
> My question is can we include both Blender-2.79 and UPBGE in the
> official ports tree next to official Blender release? All dependencies
> are provided, all of them works fine next to each other. It would be
> really handy to have at least Blender-2.79 from PKG.
>
> https://github.com/sambler/sambler-redports/tree/master/graphics/blender279
> https://github.com/sambler/sambler-redports/tree/master/graphics/upbge

BGE is gone and done, and in most cases FreeBSD does not keep old
versions of ports around, and that's especially true for massive and
complex projects like Blender.

When UPBGE matures it'd be great to have it in the tree, but bringing
back unsupported and unmaintained older versions of software isn't a
path we go down very often. If Blender were a trivial build, it'd be
more feasible, but the complexity of the maintenance burden is
difficult to overcome.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

BLENDER 2.79

[Tomasz CEDRO]

Hello world :-)

I have been using Blender-2.79 from Shane's Red Ports repository on
GitHub because Blender since version 2.80 (current port is 2.82)
unfortunately removed the Blender Game Engine (BGE) which I am using
for work.

The only solution so far is to use older Blender2.79 that still has
the BGE. Blender developers just removed something with no alternative
and no plan for alternative. Luckily I found Shane's repository that
provides port for older version.

Another solution is to have UPBGE Blender 2.80 fork with experimental
and refreshed BGE included, unfortunately the BGE API has changed and
it is not backward-compatible.

My question is can we include both Blender-2.79 and UPBGE in the
official ports tree next to official Blender release? All dependencies
are provided, all of them works fine next to each other. It would be
really handy to have at least Blender-2.79 from PKG.

https://github.com/sambler/sambler-redports/tree/master/graphics/blender279
https://github.com/sambler/sambler-redports/tree/master/graphics/upbge

Best regards,
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: building blender 2.79 fails because of python dependencies

[blubee blubeeme]

I do not have anything related to python in my make.conf only ccache.
WITH_CCACHE_BUILD=yes

.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif

.if ${CC:T} == "clang"
CFLAGS+= -Qunused-arguments
.endif


I am a bit weary of updating my /usr/src and or /usr/ports until this
python flavors thing calm down a bit before I update.


On Sun, Dec 3, 2017 at 9:16 AM, Shane Ambler  wrote:

> On 30/11/2017 21:05, blubee blubeeme wrote:
> > On Wed, Nov 29, 2017 at 9:25 PM, blubee blubeeme 
> > wrote:
> >
> >> Here's a build log:
> >>
> >> running install_scripts
> ...
> >> ===>   blender-2.79_2 depends on shared library: libOpenColorIO.so - not
> >> found
> >> ===>  opencolorio-1.0.9_3 needs Python 2.7 at most, but 3.5 was
> specified.
> >> *** Error code 1
> >>
> >> Stop.
> >> make[1]: stopped in /usr/ports/graphics/opencolorio
> >> *** Error code 1
> >>
> >> Stop.
> >>
> >>
> > I solved this problem by deselecting the opencolorio, openimageio and
> > cycles options.
> >
> > But this error does bring up an error that I'm currently dealing with
> > somewhere else.
> >
> > A project that uses multiple versions of python often fail to build with
> an
> > error similar to this one above:
> > ===>  opencolorio-1.0.9_3 needs Python 2.7 at most, but 3.5 was
> specified.
> > *** Error code 1
> >
> > How do you porters work with projects that needs multiple versions of
> > python to build?
>
> blender should build with cycles openimageio and opencolorio enabled.
> Can you build and install openimageio and then build blender?
>
> A recent change added python flavors, we can now use make FLAVOR=py35 to
> build a python module for python 3.5 instead of the default 2.7
>
> https://wiki.freebsd.org/Ports/FlavorsTools
>
> My guess is it is related to the python flavors change, either it is a
> glitch that has since been fixed or a config you have is effecting it as
> I can't find a way to get the error.
>
> Check your make.conf
> Do you have PYTHON_VERSION set? it shouldn't be used any more
> Do you have DEFAULT_VERSIONS= python=3.5
>
>
> --
> FreeBSD - the place to B...Software Developing
>
> Shane Ambler
>
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: building blender 2.79 fails because of python dependencies

[Shane Ambler]

On 30/11/2017 21:05, blubee blubeeme wrote:
> On Wed, Nov 29, 2017 at 9:25 PM, blubee blubeeme 
> wrote:
> 
>> Here's a build log:
>>
>> running install_scripts
...
>> ===>   blender-2.79_2 depends on shared library: libOpenColorIO.so - not
>> found
>> ===>  opencolorio-1.0.9_3 needs Python 2.7 at most, but 3.5 was specified.
>> *** Error code 1
>>
>> Stop.
>> make[1]: stopped in /usr/ports/graphics/opencolorio
>> *** Error code 1
>>
>> Stop.
>>
>>
> I solved this problem by deselecting the opencolorio, openimageio and
> cycles options.
> 
> But this error does bring up an error that I'm currently dealing with
> somewhere else.
> 
> A project that uses multiple versions of python often fail to build with an
> error similar to this one above:
> ===>  opencolorio-1.0.9_3 needs Python 2.7 at most, but 3.5 was specified.
> *** Error code 1
> 
> How do you porters work with projects that needs multiple versions of
> python to build?

blender should build with cycles openimageio and opencolorio enabled.
Can you build and install openimageio and then build blender?

A recent change added python flavors, we can now use make FLAVOR=py35 to
build a python module for python 3.5 instead of the default 2.7

https://wiki.freebsd.org/Ports/FlavorsTools

My guess is it is related to the python flavors change, either it is a
glitch that has since been fixed or a config you have is effecting it as
I can't find a way to get the error.

Check your make.conf
Do you have PYTHON_VERSION set? it shouldn't be used any more
Do you have DEFAULT_VERSIONS= python=3.5


-- 
FreeBSD - the place to B...Software Developing

Shane Ambler

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: building blender 2.79 fails because of python dependencies

[blubee blubeeme]

On Wed, Nov 29, 2017 at 9:25 PM, blubee blubeeme 
wrote:

> Here's a build log:
>
> running install_scripts
> copying build/scripts-3.5/pydoc3.5 -> /usr/ports/lang/python35/work/
> stage/usr/local/bin
> copying build/scripts-3.5/pyvenv-3.5 -> /usr/ports/lang/python35/work/
> stage/usr/local/bin
> copying build/scripts-3.5/idle3.5 -> /usr/ports/lang/python35/work/
> stage/usr/local/bin
> copying build/scripts-3.5/2to3-3.5 -> /usr/ports/lang/python35/work/
> stage/usr/local/bin
> changing mode of /usr/ports/lang/python35/work/stage/usr/local/bin/pydoc3.5
> to 755
> changing mode of /usr/ports/lang/python35/work/stage/usr/local/bin/pyvenv-3.5
> to 755
> changing mode of /usr/ports/lang/python35/work/stage/usr/local/bin/idle3.5
> to 755
> changing mode of /usr/ports/lang/python35/work/stage/usr/local/bin/2to3-3.5
> to 755
> rm /usr/ports/lang/python35/work/stage/usr/local/lib/python3.5/
> lib-dynload/_sysconfigdata.py
> rm -r /usr/ports/lang/python35/work/stage/usr/local/lib/python3.5/
> lib-dynload/__pycache__
> install  -m 0644 ./Misc/python.man  /usr/ports/lang/python35/work/
> stage/usr/local/man/man1/python3.5.1
> if test "xno" != "xno"  ; then  case no in  upgrade)
> ensurepip="--altinstall --upgrade" ;;  install|*) ensurepip="--altinstall"
> ;;  esac;  LD_LIBRARY_PATH=/usr/ports/lang/python35/work/Python-3.5.4
> ./python -E -m ensurepip  $ensurepip 
> --root=/usr/ports/lang/python35/work/stage/
> ;  fi
> /bin/rm -f /usr/ports/lang/python35/work/stage/usr/local/lib/libpython3.so #
> Upstream Issue: http://bugs.python.org/issue17975
> for i in 
> /usr/ports/lang/python35/work/stage/usr/local/lib/python3.5/lib-dynload/*.so;
> do  /usr/bin/strip $i; done # Strip shared extensions
> install  -m 0644 
> /usr/ports/lang/python35/work/Python-3.5.4/Tools/gdb/libpython.py
> /usr/ports/lang/python35/work/stage/usr/local/lib/libpython3
> .5m.so.1.0-gdb.py
> > Compressing man pages (compress-man)
> ===>  Installing for python35-3.5.4
> ===>  Checking if python35 already installed
> ===>   Registering installation for python35-3.5.4 as automatic
> Installing python35-3.5.4...
> 
> ===
>
> Note that some standard Python modules are provided as separate ports
> as they require additional dependencies. They are available as:
>
> py35-gdbm   databases/py35-gdbm
> py35-sqlite3databases/py35-sqlite3
> py35-tkinterx11-toolkits/py35-tkinter
>
> 
> ===
>
> ===> SECURITY REPORT:
>   This port has installed the following files which may act as network
>   servers and may therefore pose a remote security risk to the system.
> /usr/local/lib/python3.5/lib-dynload/_socket.so
>
>   If there are vulnerabilities in these programs there may be a
> security
>   risk to the system. FreeBSD makes no guarantee about the security of
>   ports included in the Ports Collection. Please type 'make deinstall'
>   to deinstall the port if this is a concern.
>
>   For more information, and contact details about the security
>   status of this software, see the following webpage:
> https://www.python.org/
> ===>   blender-2.79_2 depends on file: /usr/local/bin/python3.5 - found
> ===>   Returning to build of blender-2.79_2
> ===>   blender-2.79_2 depends on executable: msgfmt - found
> ===>   blender-2.79_2 depends on executable: gtk-update-icon-cache - found
> ===>   blender-2.79_2 depends on file: /usr/local/lib/libGL.so - found
> ===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/glproto.pc
> - found
> ===>   blender-2.79_2 depends on file: 
> /usr/local/libdata/pkgconfig/dri2proto.pc
> - found
> ===>   blender-2.79_2 depends on file: 
> /usr/local/libdata/pkgconfig/dri3proto.pc
> - found
> ===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/glproto.pc
> - found
> ===>   blender-2.79_2 depends on file: 
> /usr/local/libdata/pkgconfig/dri2proto.pc
> - found
> ===>   blender-2.79_2 depends on file: 
> /usr/local/libdata/pkgconfig/dri3proto.pc
> - found
> ===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/x11.pc
> - found
> ===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/xext.pc
> - found
> ===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/xmu.pc
> - found
> ===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/xrender.pc
> - found
> ===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/xi.pc
> - found
> ===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/xxf86vm.pc
> - found
> ===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/xi.pc
> - found
> ===>   blender-2.79_2 depends on file: /usr/local/bin/ccache - found
> ===>   blender-2.79_2 depends on shared library: libpng.so - found
> (/usr/local/lib/libpng.so)
> ===>   blender-2.79_2 depends on shared library: libfreetype.so - found
> 

building blender 2.79 fails because of python dependencies

[blubee blubeeme]

Here's a build log:

running install_scripts
copying build/scripts-3.5/pydoc3.5 ->
/usr/ports/lang/python35/work/stage/usr/local/bin
copying build/scripts-3.5/pyvenv-3.5 ->
/usr/ports/lang/python35/work/stage/usr/local/bin
copying build/scripts-3.5/idle3.5 ->
/usr/ports/lang/python35/work/stage/usr/local/bin
copying build/scripts-3.5/2to3-3.5 ->
/usr/ports/lang/python35/work/stage/usr/local/bin
changing mode of /usr/ports/lang/python35/work/stage/usr/local/bin/pydoc3.5
to 755
changing mode of
/usr/ports/lang/python35/work/stage/usr/local/bin/pyvenv-3.5 to 755
changing mode of /usr/ports/lang/python35/work/stage/usr/local/bin/idle3.5
to 755
changing mode of /usr/ports/lang/python35/work/stage/usr/local/bin/2to3-3.5
to 755
rm
/usr/ports/lang/python35/work/stage/usr/local/lib/python3.5/lib-dynload/_sysconfigdata.py
rm -r
/usr/ports/lang/python35/work/stage/usr/local/lib/python3.5/lib-dynload/__pycache__
install  -m 0644 ./Misc/python.man
/usr/ports/lang/python35/work/stage/usr/local/man/man1/python3.5.1
if test "xno" != "xno"  ; then  case no in  upgrade)
ensurepip="--altinstall --upgrade" ;;  install|*) ensurepip="--altinstall"
;;  esac;  LD_LIBRARY_PATH=/usr/ports/lang/python35/work/Python-3.5.4
./python -E -m ensurepip  $ensurepip
--root=/usr/ports/lang/python35/work/stage/ ;  fi
/bin/rm -f /usr/ports/lang/python35/work/stage/usr/local/lib/libpython3.so #
Upstream Issue: http://bugs.python.org/issue17975
for i in
/usr/ports/lang/python35/work/stage/usr/local/lib/python3.5/lib-dynload/*.so;
do  /usr/bin/strip $i; done # Strip shared extensions
install  -m 0644
/usr/ports/lang/python35/work/Python-3.5.4/Tools/gdb/libpython.py
/usr/ports/lang/python35/work/stage/usr/local/lib/
libpython3.5m.so.1.0-gdb.py
> Compressing man pages (compress-man)
===>  Installing for python35-3.5.4
===>  Checking if python35 already installed
===>   Registering installation for python35-3.5.4 as automatic
Installing python35-3.5.4...
===

Note that some standard Python modules are provided as separate ports
as they require additional dependencies. They are available as:

py35-gdbm   databases/py35-gdbm
py35-sqlite3databases/py35-sqlite3
py35-tkinterx11-toolkits/py35-tkinter

===

===> SECURITY REPORT:
  This port has installed the following files which may act as network
  servers and may therefore pose a remote security risk to the system.
/usr/local/lib/python3.5/lib-dynload/_socket.so

  If there are vulnerabilities in these programs there may be a security
  risk to the system. FreeBSD makes no guarantee about the security of
  ports included in the Ports Collection. Please type 'make deinstall'
  to deinstall the port if this is a concern.

  For more information, and contact details about the security
  status of this software, see the following webpage:
https://www.python.org/
===>   blender-2.79_2 depends on file: /usr/local/bin/python3.5 - found
===>   Returning to build of blender-2.79_2
===>   blender-2.79_2 depends on executable: msgfmt - found
===>   blender-2.79_2 depends on executable: gtk-update-icon-cache - found
===>   blender-2.79_2 depends on file: /usr/local/lib/libGL.so - found
===>   blender-2.79_2 depends on file:
/usr/local/libdata/pkgconfig/glproto.pc - found
===>   blender-2.79_2 depends on file:
/usr/local/libdata/pkgconfig/dri2proto.pc - found
===>   blender-2.79_2 depends on file:
/usr/local/libdata/pkgconfig/dri3proto.pc - found
===>   blender-2.79_2 depends on file:
/usr/local/libdata/pkgconfig/glproto.pc - found
===>   blender-2.79_2 depends on file:
/usr/local/libdata/pkgconfig/dri2proto.pc - found
===>   blender-2.79_2 depends on file:
/usr/local/libdata/pkgconfig/dri3proto.pc - found
===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/x11.pc
- found
===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/xext.pc
- found
===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/xmu.pc
- found
===>   blender-2.79_2 depends on file:
/usr/local/libdata/pkgconfig/xrender.pc - found
===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/xi.pc -
found
===>   blender-2.79_2 depends on file:
/usr/local/libdata/pkgconfig/xxf86vm.pc - found
===>   blender-2.79_2 depends on file: /usr/local/libdata/pkgconfig/xi.pc -
found
===>   blender-2.79_2 depends on file: /usr/local/bin/ccache - found
===>   blender-2.79_2 depends on shared library: libpng.so - found
(/usr/local/lib/libpng.so)
===>   blender-2.79_2 depends on shared library: libfreetype.so - found
(/usr/local/lib/libfreetype.so)
===>   blender-2.79_2 depends on shared library: libboost_regex.so - found
(/usr/local/lib/libboost_regex.so)
===>   blender-2.79_2 depends on shared library: libunwind.so - found
(/usr/local/lib/libunwind.so)
===>   blender-2.79_2 depends on shared library: libavutil.so - found