Hi! On Sat, Aug 29, 2015 at 9:31 PM, Sofus Rose <so...@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 _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
