The blender Package
sofus at sofusrose.com
Sat Sep 5 18:30:22 UTC 2015
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
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
- It seems that a user 'jcristau' made a removal request; what is the
reason? It looks quite scary to a newbie!
- 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?
- 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?
- 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 ?
- 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?
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
- It's not currently in the build, it compiles alongside blender,
requiring the cmake flag CYCLES_OSL=ON (and/or the compile flag
- 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>.
- 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?
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!
On Mon, Aug 31, 2015 at 6:20 AM, Matteo F. Vescovi <mfv at debian.org> wrote:
> On Sat, Aug 29, 2015 at 9:31 PM, Sofus Rose <sofus at sofusrose.com> wrote:
> > Hello again,
> > After reading many documents, I think I'd like to start gaining practical
> > experience. So, naturally, I began trying to upgrade the blender package
> > the newest upstream version, 2.75a. It's proving a bit of a challenge,
> > however; If you don't mind taking a moment, I have some questions
> > this package specifically:
> > 'git tag' shows me that the various versions (upstream/<version> and
> > debian/<version>) are maintained by tag, as opposed to by branch (as the
> > git-buildpackage docs seem to be teaching me). 'gbp import-orig uscan'
> > to read debian/watch fine, but demands an 'upstream' branch, which should
> > obviously be an upstream/<version> tag as per the structure at the
> > So my question is this: What tools do I use/how do I maintain the current
> > package structure, with tagged upstream/debian versions, ideally while
> > utilizing time-savers like debian/watch?
> > I did manage to update using uscan normally (do I, perhaps, simply tag
> > this?), and ran 'while dquilt push; do dquilt refresh; done' (dquilt is
> > alias to quilt, except it points to ./debian/patches); all the patches
> > to have (I don't actually know) applied correctly from what I can see
> > 'dquilt diff'. Then, using a tar'ed version of blender's upstream git
> > repository (with v2.75a checked out), named 'blender_2.75a.orig.tar.gz',
> > tried to run 'dpkg-buildpackage -us -uc'. It ran fine, right until the
> > patches. The error is below:
> >> patching file blender.thumbnailer
> >> patching file release/bin/blender-thumbnailer.py
> >> patching file source/creator/CMakeLists.txt
> >> Hunk #1 FAILED at 484.
> >> 1 out of 1 hunk FAILED
> >> dpkg-source: info: the patch has fuzz which is not allowed, or is
> >> malformed
> >> dpkg-source: info: if patch '0001-blender_thumbnailer.patch' is
> >> applied by quilt, use 'quilt refresh' to update it
> >> dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B
> >> .pc/0001-blender_thumbnailer.patch/ --reject-file=- <
> >> blender.orig.HjNuiS/debian/patches/0001-blender_thumbnailer.patch gave
> >> exit status 1
> >> dpkg-buildpackage: error: dpkg-source -b blender gave error exit status
> > ...Which is strange, considering the dquilt refresh I ran on all the
> > packages. I have searched, and I have no idea what is going on. So my
> > question is this: What is going on, and how do I fix it?
> Mmhhh... are you packaging Blender from scratch or are you using the
> packaging stuff gathered from the official git repository?
> Debian packaging in git relays on tags more than branches; branches
> are used differently; for example, to handle changes for the stable
> suite or backports starting from the git tag of the revision in the
> archives (have a look at  and spend a minute on 'master.jessie-bpo'
> At  you can find my actual working copy of Blender packaging,
> including the up-mentioned 2.75a version (on the master.experimental
> I haven't uploaded it yet to experimental suite (the only suite I can
> upload it for now, given the strict dependencies on the code) because
> of the ongoing transition for gcc-5/g++-5 and its consequences on
> other packages involved in the build process.
> That said, it all depends on the workflow you're using to package the
> If you follow the git-buildpackage model (the one advised by the DMM
> team), you should always have a 'master' branch, a 'pristine-tar'
> branch and an 'upstream' branch.
> 'master' branch is the magic place where packaging takes place, in the
> end; it's almost a "copy" of 'upstream' branch + the debian/ directory
> with its scripts and stuff.
> To manage patches, gbp pq is the recommended tool to use (well, since
> I maintain Blender in Debian, it's surely the tool you *must* use if
> you want to help me here ;) ).
> dquilt is a good start for stuff outside git repositories or if
> playing with NMUs or whatever is not under your direct control. But
> here this is not the case.
> gbp pq allows you to manage the patches as commits to the special
> branch 'patch-queue/<branch>' where <branch> is the branch you start
> the work on.
> For example, you'll find a 'patch-queue/master.experimental' branch in
> my private git repository, holding the commits I then 'merged' back to
> the main branch for testing the code.
> Probably, dquilt wasn't really doing a great job with the patching
> here and even if it refreshed the stuff correctly, the patching didn't
> apply the same smooth way.
> > I noticed that a diff between CMakeLists.txt of the 'uscan' updated
> > version (before patches) and the original source was quite long... My
> > question holds!
> Could you provide me a diff of those differences? Thanks.
> > Finally, a bit of an etiquette question (which I couldn't locate in the
> > Debian Policy manual): Say I wanted to add a Danish (my second language)
> > translation to the package description in blender.desktop, which is part
> > the '0006-blender_desktop.patch' patch. How do I handle the patch
> header? Do
> > I treat it like a changelog, putting my changes over, or do I make an
> > entirely new header, inputting my changes? Most importantly, is there a
> > that takes care of it for me (I noticed that there's a list of changes,
> > insertions, and deletions in each header)?
> Well, the better solution here would be to contact directly Blender
> upstream developers and ask them to merge your new translation in the
> their code, so in next upstream official release you won't need
> patching that file anymore, given that anyone could benefit of your
> addition ;)
> If it's ok for you, send my the addition as a patch and I'll contact
> my couple of devs in the Blender Project to commit that asap.
> > Thanks for your time!
> I hope to have answered at least part of your questions.
> Happy hacking and hope to see you soon asking some more questions :)
>  https://anonscm.debian.org/cgit/pkg-multimedia/blender.git
>  git.studiovescovi.eu/gitweb/?p=mfv/blender.git
> Matteo F. Vescovi || Debian Developer
> GnuPG KeyID: 4096R/0x8062398983B2CF7A
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 789 bytes
Desc: not available
More information about the pkg-multimedia-maintainers