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 <m...@debian.org> wrote: > 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 > >
blender.desktop
Description: application/desktop
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers