The blender Package

[Matteo F. Vescovi]

Hi!

On Sat, Sep 5, 2015 at 8:30 PM, Sofus Rose <sofus at sofusrose.com> wrote:
> Hello!
>
> So I've been fiddling with the package quite a bit, as well as taking a look
> at your working repository, and expanding my git/gbp knowledge. Though, at
> the moment, actually building the unreleased version isn't much of an option
> (gcc/g++ 5 seems to want to rip out little things like GNOME right now :)
> )...
>
> In terms of the packaging workflow, I have found
> https://wiki.debian.org/DebianMultimedia/DevelopPackaging, which combined
> with your comments seems to help a lot in terms of clarifying the
> tag/branch/patch/upstream relationships that the team uses. Looking at the
> workflow specs, the long diff of upstream/my CMakeLists.txt is most likely
> my fault :).
>
> In terms of the .desktop patch, I suppose it makes sense to look at upstream
> first! I modified the .desktop patch, attached, which contains these added
> lines:
>
> GenericName[da]=3D Modelbygger
> Comment[da]=3D modellering, animation, gengivelse, og efterbehandling

Something similar was already pushed to the upstream git
repository[1], so I don't think it's worth sending this version.
But if the translation that was made by the author/committer is wrong,
then feel free to contact them and ask to update.

> Also, if you have a moment, I have some questions about what precisely is
> wrong with blender right now, in hopes of gaining some clarity about how to
> fix it!
>
> It seems that a user 'jcristau' made a removal request; what is the reason?
> It looks quite scary to a newbie!

It was necessary to allow the gcc-5/g++-5 transition to complete. I'm
sure you don't really want to know more at thi stage of your
involvement in Debian packaging ;-)

> On the PTS, blender is part of 5 auto-* migrations. The information on these
> is a bit sparse; what exactly are these, and do they impact blender's
> ability to build/run?

Tough question; long story short, many libraries involved in blender
building process are actually under a massive update/rename due to
"The Transition".
Renaming affects the shared libraries, not the development ones; so,
once all these shared libraries are back in the archives, building
blender should be possible again, since the -dev lib packages that
blender depends upon are again pointing to the right shared libraries.

> So, regarding the gcc/g++ versions: You mentioned that the dependencies
> didn't agree, but what about blender itself? How much work, and/or time, is
> usually required when gcc updates?

Everything is on its way, at this point. Blender in unstable/sid
should migrate to testing soon.
Is this a good answer? ;-P

> Your repository lists many master.<release> branches. May I assume that you
> rebase these into each other when releasing, and then into 'master' for an
> upload to [0]?

Almost. They're master branches for specific releases.
There is a 'master.jessie' where simple updates are made to fix
minimal (or security) issues.
Same for the others.
For the sake of consistency, I usually try to keep track of all the
uploads in the master branch's debian/changelog.

> The day I do manage to land a working, updated blender .deb, how would you
> prefer I give it to you for review/eventual upload?

Via a source package ready to be built on our beloved Deb-o-Matic
building infrastructure.

> Finally, I actually have two suggestions, as well as what each entails! I'll
> try to include them when I build the .deb.
>
> Blender supports Open Shading Language, which is often vital for production
> purposes.
>
> It's not currently in the build, it compiles alongside blender, requiring
> the cmake flag CYCLES_OSL=ON (and/or the compile flag -DWITH_CYCLES_OSL=ON).

This is something I wasn't aware of, since I use Blender rarely :-(
I'll see if the package as it is in its shape now allows me to enable
that feature; in that case, I would make a test build of the sid
version and provide a new upload asap.

> I read a bug report citing a request for OpenCollada, which at the time was
> not packaged. That has since changed, however (as you probably know seeing
> as you made the upload ;) ).
>
> The process for compiling blender with OpenCollada is described here;
> briefly, it involves the compile flag -DWITH_OPENCOLLADA=ON and the CMake
> option OPENCOLLADA_ROOT_DIR=<location of debian install>.

Eh, not that simple! I made some tests in the past on the 2.75a
release and it was failing on a lot of things, and most of them were
OpenCOLLADA-related.

> I'm not entirely sure, as I have no experience with the package, but the
> released opencollada version at 1.2.2
> (https://www.khronos.org/collada/wiki/OpenCOLLADA) is a little different
> than the package at 0.1.0
> (https://packages.qa.debian.org/o/opencollada.html). I would assume that the
> versioning would have to be verified for correct integration?

v1.2.2 is a "almost commercial" version, blunding lot of plugins of
various 3D modellers.
v0.1.0 is the real open source core of the program.

> With a working branch setup (master, upstream, pristine-tar, and
> patch-queue/master) that does everything but git-buildpackage, because of
> gcc5, I hope to provide something more helpful soon!

Hope so.

Have fun!

Cheers.


[1] https://developer.blender.org/rB8d1f9b9f511859e

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A