The blender Package

Sofus Rose sofus at sofusrose.com
Sat Sep 5 18:30:22 UTC 2015 

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



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!
   - 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 [0]?
   - 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
   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).
      - 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
      <http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/Troubleshooting#OpenCOLLADA>;
      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!

With Regards,
Sofus Rose

[0] https://anonscm.debian.org/cgit/pkg-multimedia/blender.git

On Mon, Aug 31, 2015 at 6:20 AM, Matteo F. Vescovi <mfv at debian.org> wrote:

> Hi!
>
> 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
> to
> > 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
> regarding
> > 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'
> seems
> > to read debian/watch fine, but demands an 'upstream' branch, which should
> > obviously be an upstream/<version> tag as per the structure at the
> moment.
> > 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
> still
> > 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
> an
> > alias to quilt, except it points to ./debian/patches); all the patches
> seem
> > to have (I don't actually know) applied correctly from what I can see
> with
> > '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',
> I
> > 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
> correctly
> >> 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
> error
> >> exit status 1
> >> dpkg-buildpackage: error: dpkg-source -b blender gave error exit status
> 2
> >
> > ...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 [1] and spend a minute on 'master.jessie-bpo'
> branch).
>
> At [2] you can find my actual working copy of Blender packaging,
> including the up-mentioned 2.75a version (on the master.experimental
> branch).
> 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
> stuff.
> 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
> Debian
> > 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
> of
> > 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
> tool
> > 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 :)
>
> Cheers.
>
>
> [1] https://anonscm.debian.org/cgit/pkg-multimedia/blender.git
> [2] git.studiovescovi.eu/gitweb/?p=mfv/blender.git
>
> --
> Matteo F. Vescovi || Debian Developer
> GnuPG KeyID: 4096R/0x8062398983B2CF7A
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150905/5f18ada6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blender.desktop
Type: application/x-desktop
Size: 789 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150905/5f18ada6/attachment-0001.bin>

More information about the pkg-multimedia-maintainers mailing list