<div dir="ltr"><div><div>Hello!<br><br></div>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 :) )...<br><br></div><div>In terms of the packaging workflow, I have found <a href="https://wiki.debian.org/DebianMultimedia/DevelopPackaging">https://wiki.debian.org/DebianMultimedia/DevelopPackaging</a>, 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 :).<br><br></div><div>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:<br><ul><li>GenericName[da]=3D Modelbygger<br></li><li>Comment[da]=3D modellering, animation, gengivelse, og efterbehandling</li></ul></div><div><br><br></div>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!<br><ul><li>It seems that a user 'jcristau' made a removal request; what is the reason? It looks quite scary to a newbie!<br></li><li>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?</li><li>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?</li><li>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]?</li><li>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?<br></li></ul><p><br></p><p>Finally, I actually have two suggestions, as well as what each entails! I'll try to include them when I build the .deb.<br></p><ul><li>Blender supports Open Shading Language, which is often vital for production purposes.<br></li><ul><li>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).<br></li></ul><li>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 ;) ).</li><ul><li>The process for compiling blender with OpenCollada is described <a href="http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Linux/Troubleshooting#OpenCOLLADA">here</a>; briefly, it involves the compile flag -DWITH_OPENCOLLADA=ON and the CMake option OPENCOLLADA_ROOT_DIR=<location of debian install>.</li><li>I'm not entirely sure, as I have no experience with the package, but the released opencollada version at 1.2.2 (<a href="https://www.khronos.org/collada/wiki/OpenCOLLADA">https://www.khronos.org/collada/wiki/OpenCOLLADA</a>) is a little different than the package at 0.1.0 (<a href="https://packages.qa.debian.org/o/opencollada.html">https://packages.qa.debian.org/o/opencollada.html</a>). I would assume that the versioning would have to be verified for correct integration?<br></li></ul></ul><p><br></p><p>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!</p><p>With Regards,<br>Sofus Rose<br><br>[0] <a href="https://anonscm.debian.org/cgit/pkg-multimedia/blender.git" rel="noreferrer" target="_blank">https://anonscm.debian.org/cgit/pkg-multimedia/blender.git</a></p><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 6:20 AM, Matteo F. Vescovi <span dir="ltr"><<a href="mailto:mfv@debian.org" target="_blank">mfv@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<div><div class="h5"><br>
On Sat, Aug 29, 2015 at 9:31 PM, Sofus Rose <<a href="mailto:sofus@sofusrose.com">sofus@sofusrose.com</a>> wrote:<br>
> Hello again,<br>
><br>
> After reading many documents, I think I'd like to start gaining practical<br>
> experience. So, naturally, I began trying to upgrade the blender package to<br>
> the newest upstream version, 2.75a. It's proving a bit of a challenge,<br>
> however; If you don't mind taking a moment, I have some questions regarding<br>
> this package specifically:<br>
><br>
> 'git tag' shows me that the various versions (upstream/<version> and<br>
> debian/<version>) are maintained by tag, as opposed to by branch (as the<br>
> git-buildpackage docs seem to be teaching me). 'gbp import-orig uscan' seems<br>
> to read debian/watch fine, but demands an 'upstream' branch, which should<br>
> obviously be an upstream/<version> tag as per the structure at the moment.<br>
> So my question is this: What tools do I use/how do I maintain the current<br>
> package structure, with tagged upstream/debian versions, ideally while still<br>
> utilizing time-savers like debian/watch?<br>
> I did manage to update using uscan normally (do I, perhaps, simply tag<br>
> this?), and ran 'while dquilt push; do dquilt refresh; done' (dquilt is an<br>
> alias to quilt, except it points to ./debian/patches); all the patches seem<br>
> to have (I don't actually know) applied correctly from what I can see with<br>
> 'dquilt diff'. Then, using a tar'ed version of blender's upstream git<br>
> repository (with v2.75a checked out), named 'blender_2.75a.orig.tar.gz', I<br>
> tried to run 'dpkg-buildpackage -us -uc'. It ran fine, right until the<br>
> patches. The error is below:<br>
>><br>
>> patching file blender.thumbnailer<br>
>> patching file release/bin/blender-thumbnailer.py<br>
>> patching file source/creator/CMakeLists.txt<br>
>> Hunk #1 FAILED at 484.<br>
>> 1 out of 1 hunk FAILED<br>
>> dpkg-source: info: the patch has fuzz which is not allowed, or is<br>
>> malformed<br>
>> dpkg-source: info: if patch '0001-blender_thumbnailer.patch' is correctly<br>
>> applied by quilt, use 'quilt refresh' to update it<br>
>> dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B<br>
>> .pc/0001-blender_thumbnailer.patch/ --reject-file=- <<br>
>> blender.orig.HjNuiS/debian/patches/0001-blender_thumbnailer.patch gave error<br>
>> exit status 1<br>
>> dpkg-buildpackage: error: dpkg-source -b blender gave error exit status 2<br>
><br>
> ...Which is strange, considering the dquilt refresh I ran on all the<br>
> packages. I have searched, and I have no idea what is going on. So my<br>
> question is this: What is going on, and how do I fix it?<br>
<br>
</div></div>Mmhhh... are you packaging Blender from scratch or are you using the<br>
packaging stuff gathered from the official git repository?<br>
Debian packaging in git relays on tags more than branches; branches<br>
are used differently; for example, to handle changes for the stable<br>
suite or backports starting from the git tag of the revision in the<br>
archives (have a look at [1] and spend a minute on 'master.jessie-bpo'<br>
branch).<br>
<br>
At [2] you can find my actual working copy of Blender packaging,<br>
including the up-mentioned 2.75a version (on the master.experimental<br>
branch).<br>
I haven't uploaded it yet to experimental suite (the only suite I can<br>
upload it for now, given the strict dependencies on the code) because<br>
of the ongoing transition for gcc-5/g++-5 and its consequences on<br>
other packages involved in the build process.<br>
<br>
That said, it all depends on the workflow you're using to package the stuff.<br>
If you follow the git-buildpackage model (the one advised by the DMM<br>
team), you should always have a 'master' branch, a 'pristine-tar'<br>
branch and an 'upstream' branch.<br>
'master' branch is the magic place where packaging takes place, in the<br>
end; it's almost a "copy" of 'upstream' branch + the debian/ directory<br>
with its scripts and stuff.<br>
<br>
To manage patches, gbp pq is the recommended tool to use (well, since<br>
I maintain Blender in Debian, it's surely the tool you *must* use if<br>
you want to help me here ;) ).<br>
dquilt is a good start for stuff outside git repositories or if<br>
playing with NMUs or whatever is not under your direct control. But<br>
here this is not the case.<br>
<br>
gbp pq allows you to manage the patches as commits to the special<br>
branch 'patch-queue/<branch>' where <branch> is the branch you start<br>
the work on.<br>
For example, you'll find a 'patch-queue/master.experimental' branch in<br>
my private git repository, holding the commits I then 'merged' back to<br>
the main branch for testing the code.<br>
Probably, dquilt wasn't really doing a great job with the patching<br>
here and even if it refreshed the stuff correctly, the patching didn't<br>
apply the same smooth way.<br>
<span class=""><br>
> I noticed that a diff between CMakeLists.txt of the 'uscan' updated Debian<br>
> version (before patches) and the original source was quite long... My<br>
> question holds!<br>
<br>
</span>Could you provide me a diff of those differences? Thanks.<br>
<span class=""><br>
> Finally, a bit of an etiquette question (which I couldn't locate in the<br>
> Debian Policy manual): Say I wanted to add a Danish (my second language)<br>
> translation to the package description in blender.desktop, which is part of<br>
> the '0006-blender_desktop.patch' patch. How do I handle the patch header? Do<br>
> I treat it like a changelog, putting my changes over, or do I make an<br>
> entirely new header, inputting my changes? Most importantly, is there a tool<br>
> that takes care of it for me (I noticed that there's a list of changes,<br>
> insertions, and deletions in each header)?<br>
<br>
</span>Well, the better solution here would be to contact directly Blender<br>
upstream developers and ask them to merge your new translation in the<br>
their code, so in next upstream official release you won't need<br>
patching that file anymore, given that anyone could benefit of your<br>
addition ;)<br>
If it's ok for you, send my the addition as a patch and I'll contact<br>
my couple of devs in the Blender Project to commit that asap.<br>
<br>
> Thanks for your time!<br>
<br>
I hope to have answered at least part of your questions.<br>
Happy hacking and hope to see you soon asking some more questions :)<br>
<br>
Cheers.<br>
<br>
<br>
[1] <a href="https://anonscm.debian.org/cgit/pkg-multimedia/blender.git" rel="noreferrer" target="_blank">https://anonscm.debian.org/cgit/pkg-multimedia/blender.git</a><br>
[2] <a href="http://git.studiovescovi.eu/gitweb/?p=mfv/blender.git" rel="noreferrer" target="_blank">git.studiovescovi.eu/gitweb/?p=mfv/blender.git</a><br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Matteo F. Vescovi || Debian Developer<br>
GnuPG KeyID: 4096R/0x8062398983B2CF7A<br>
<br>
</div></div></blockquote></div><br></div></div>