| Summary: | media-gfx/blender-2.69-r1 stable request | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Stephan Litterst <stephan.litterst> |
| Component: | [OLD] Keywording and Stabilization | Assignee: | Julian Ospald <hasufell> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | chain, graphics+disabled, jaak, lu_zero, O01eg |
| Priority: | Normal | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 507706, 511390, 511392 | ||
| Bug Blocks: | |||
|
Description
Stephan Litterst
2013-11-30 18:16:58 UTC
not enough people commenting here random timeframes are not enough to stabilize a package of this kind. I'd expect a few users to comment here, but no one did How many comments do you need to mark it as stable and which information do you expect in such a comment? Any progress? Well, since 2.64 is hard-masked and everything else needs PYTHON_SINGLE_TARGET="3.3" (from which I assume massive system breakage) this is going to be tough one. I really would like seeing blender to work, but right now it really seems unusable under Gentoo. I sure hope this gets fixed somehow (or maybe 3.3 will be used for SINGLE_TARGET some day by default?) (In reply to Richard H. from comment #4) > (from which I assume massive system breakage) no. You can set that per-package. media-gfx/blender python_single_target_python3_3 however... USE_PYTHON should be set globally in make.conf only (add 3.3 there), because that is what will cause blockers (not breakage) (In reply to Stephan Litterst from comment #3) > Any progress? I'm not convinced yet. You didn't even comment on it. (In reply to Julian Ospald (hasufell) from comment #5) > (In reply to Richard H. from comment #4) > > (from which I assume massive system breakage) > > no. You can set that per-package. > > media-gfx/blender python_single_target_python3_3 > > however... USE_PYTHON should be set globally in make.conf only (add 3.3 > there), because that is what will cause blockers (not breakage) Thanks I did this, and it works like a charm now. Compiles and runs without any problems. I am just a casual user, but if you need me to test anything, I would be gladly of any help. This is amd64 with most packages at stable. Doesn't compile for me. [ 77%] Building CXX object intern/locale/CMakeFiles/bf_intern_locale.dir/boost_locale_wrapper.cpp.o cd /var/tmp/portage/media-gfx/blender-2.69/work/blender-2.69_build/intern/locale && /usr/bin/x86_64-pc-linux-gnu-g++ -DBOOST_ALL_NO_LIB -DHAVE_STDBOOL_H -DWITH_ BOOL_COMPAT -DWITH_INTERNATIONAL -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D__LITTLE_ENDIAN__ -D__MMX__ -D__SSE2__ -D__SSE__ -D_FILE_OFF SET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNDEBUG -Wredundant-decls -Wall -Wno-invalid-offsetof -Wno-sign-compare -Wlogical-op -Winit-self -Wmissing -include-dirs -Wno-div-by-zero -Wtype-limits -Wuninitialized -Wundef -Wmissing-declarations -O2 -pipe -march=native -ggdb -funsigned-char -D__STDC_CONSTANT_MACR OS -fopenmp -msse2 -msse -pipe -fPIC -funsigned-char -fno-strict-aliasing -I/var/tmp/portage/media-gfx/blender-2.69/work/blender-2.69/intern/locale -o CMake Files/bf_intern_locale.dir/boost_locale_wrapper.cpp.o -c /var/tmp/portage/media-gfx/blender-2.69/work/blender-2.69/intern/locale/boost_locale_wrapper.cpp In file included from /var/tmp/portage/media-gfx/blender-2.69/work/blender-2.69/intern/locale/boost_locale_wrapper.cpp:30:0: /usr/include/boost/locale.hpp:11:37: fatal error: boost/locale/boundary.hpp: No such file or directory compilation terminated. make[2]: *** [intern/locale/CMakeFiles/bf_intern_locale.dir/boost_locale_wrapper.cpp.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/media-gfx/blender-2.69/work/blender-2.69_build' make[1]: *** [intern/locale/CMakeFiles/bf_intern_locale.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... [ebuild U ~] media-gfx/blender-2.69 [2.64a] USE="boost%* bullet%* colorio%* dds doc elbeem ffmpeg fftw game-engine jack nls openal openexr openmp player sdl sndfile sse sse2%* tiff%* -collada -cycles -debug -jpeg2k -ndof% -redcode (-3dmouse%) (-iconv%) (-tweak-mode%)" LINGUAS="(-ar%) (-bg%) (-ca%) (-cs%) (-de%) (-el%) (-en%*) (-es%) (-es_ES%) (-fa%) (-fi%) (-fr%) (-he%) (-hr%) (-hu%) (-id%) (-it%) (-ja%) (-ky%) (-ne%) (-nl%) (-pl%) (-pt%) (-pt_BR%) (-ru%) (-sr%) (-sr@latin%) (-sv%) (-tr%) (-uk%) (-zh_CN%) (-zh_TW%)" PYTHON_SINGLE_TARGET="python3_3%*" PYTHON_TARGETS="python3_3%*" 0 kB [ebuild R ] dev-libs/boost-1.52.0-r6:0/1.52 USE="doc icu python threads -debug -mpi -nls -static-libs -tools" PYTHON_TARGETS="python2_7 python3_2 python3_3 -python2_6" 0 kB Maybe it needs to depend on dev-libs/boost[nls]? It appears that boost has installed boost/locale/boundary.hpp, but not the files included by boost/locale/boundary.hpp. + 22 Jan 2014; Julian Ospald <hasufell@gentoo.org> blender-2.69.ebuild: + fix build with nls enabled next time file a new bug we still have some bundled deps, but I guess we can make this happen I'm going to stabilize this myself after some testing. halted, until I have invesitagted bug 515266 all blender versions are affected by the lzo vulnerability, but since it's pretty low severity in linuxkernel and 64bit machines I kept 2.69 in the tree for now 2.71 and 2.72 have a fix (minilzo unbundled) and 2.71 will probably be the next stable candidate after I know how well my lzo hack works so closing for now |