Hi! On Sat, Sep 5, 2015 at 8:30 PM, Sofus Rose <so...@sofusrose.com> wrote: > 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
Something similar was already pushed to the upstream git repository[1], so I don't think it's worth sending this version. But if the translation that was made by the author/committer is wrong, then feel free to contact them and ask to update. > 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! It was necessary to allow the gcc-5/g++-5 transition to complete. I'm sure you don't really want to know more at thi stage of your involvement in Debian packaging ;-) > 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? Tough question; long story short, many libraries involved in blender building process are actually under a massive update/rename due to "The Transition". Renaming affects the shared libraries, not the development ones; so, once all these shared libraries are back in the archives, building blender should be possible again, since the -dev lib packages that blender depends upon are again pointing to the right shared libraries. > 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? Everything is on its way, at this point. Blender in unstable/sid should migrate to testing soon. Is this a good answer? ;-P > 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]? Almost. They're master branches for specific releases. There is a 'master.jessie' where simple updates are made to fix minimal (or security) issues. Same for the others. For the sake of consistency, I usually try to keep track of all the uploads in the master branch's debian/changelog. > 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? Via a source package ready to be built on our beloved Deb-o-Matic building infrastructure. > 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). This is something I wasn't aware of, since I use Blender rarely :-( I'll see if the package as it is in its shape now allows me to enable that feature; in that case, I would make a test build of the sid version and provide a new upload asap. > 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; > briefly, it involves the compile flag -DWITH_OPENCOLLADA=ON and the CMake > option OPENCOLLADA_ROOT_DIR=<location of debian install>. Eh, not that simple! I made some tests in the past on the 2.75a release and it was failing on a lot of things, and most of them were OpenCOLLADA-related. > 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? v1.2.2 is a "almost commercial" version, blunding lot of plugins of various 3D modellers. v0.1.0 is the real open source core of the program. > 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! Hope so. Have fun! Cheers. [1] https://developer.blender.org/rB8d1f9b9f511859e -- 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
