The blender Package

[Matteo F. Vescovi]

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