в чем подвох, сам же пишешь ебилды и не знаешь про

>=dev-libs/boost-1.56.0 python_targets_python3_5

А, собственно, в чём проблема?

попробуйте.

в логи конфигурации пишет

b2 --user-config=/var/tmp/portage/dev-libs/boost-1.61.0/work/boost_1_61_0-abi_x86_32.x86/user-config.jam gentoorelease -j1 -q -d+2 -sICU_PATH=/usr --without-mpi --without-context --without-coroutine --without-coroutine2 pch=off --boost-build=«»/usr/share/boost-build --prefix=«/var/tmp/portage/dev-libs/boost-1.61.0/image/usr» --layout=system threading=multi link=shared --without-python

не в курсе, у меня собран, но как проверить не знаю.

Флаг python включен?

попробуйте установить dev-libs/boost-numpy, для него то все это и нужно

конечно

не ставится ни за 2013 год, ни 9999, в общем пили багу в багзилу, может в течение года пофиксят.

это долго

Ветка какая? На unstable поддержка python 3.5 есть в boost начиная с версии 1.58

ты прикалываешься резать скор человеку, у которого его 48, да еще и таким подлым способом? Держи свои эмоции при себе, не оттягивайся на мне, пожалуйста.

Я в данном случае прав, потому что пишу баги и знаю как никто другой как тормозят не то, что с фиксами, а даже подтверждениями, так что информация у меня как раз вызывающе верная. Если будешь спорить, то сразу можешь пройти в баготред блендера с последней версией в дереве за ноябрь 2014 года.

commit 0b0f9f37d0995be0bb173025f37e7e34bc45a5dc
Author: Sergey Popov <pinkbyte@gentoo.org>
Date:   Wed Jun 1 21:51:22 2016 +0300

    dev-libs/boost-numpy: update live ebuild
    
    Bump EAPI to 6, use git-r3 and python-single-r1 eclasses.
    Add compatibility with new Python ABI naming.
    
    Package-Manager: portage-2.3.0_rc1

Ну как, год уже прошел? ;-)

Может для разнообразия займешься чем-нибудь кроме нытья?

сразу можешь пройти в баготред блендера с последней версией в дереве за ноябрь 2014 года.

И ты конечно же готов предоставить проходящий все QA-тесты ебилд для новой версии?

Накинь 3 скора мне и я тебя буду кастовать на __каждую__ багу.

Я в данном случае прав, потому что пишу баги и знаю как никто другой как тормозят не то, что с фиксами, а даже подтверждениями, так что информация у меня как раз вызывающе верная

Знаешь что сделал я, когда меня не устраивала скорость обработки багов компиза в Gentoo в 2012 году? Пошел ныть на форум? Пошел рассказывать всем, как всё плохо?

А может я перестал присылать патчи и бросил затею становиться разработчиком?

Его уже предоставляли пока один лапоть при моем бампе версии не смержил баги, тот ебилд больше не рабочий, о чем и кричит человек в ветке, что так делать не нужно, на смарку его время ушло.

Не надо меня кастовать на каждую багу - я не резиновый. Учитесь взаимодействовать с разработчиками непосредственно - они няшки и не кусаются(если их не злить, да). IRC для более живого общения, если скорость реакции на баги в багзилле не устраивает. Каждый затянутый в решении баг обычно имеет под собой какую-то проблему.

пока один лапоть при моем бампе версии не смержил баги
не смержил баги
смержил баги

Шта? Гхрм... всмысле что ты имеешь ввиду под «смержил баги»?

я сбампил до 2.77, а он написал для 2.76, два бампа (его с ебилдом 2.76) и мой 2.77 смержили, и теперь 2.76 уже просто ушло в прошлое, естественно. Такая гречка где-то декабря 2014, когда вышел фикс на последнюю в дереве 2.72 за ноябрь 2014)

Цитата из бага, о котором ты говоришь:

There are still several blockers and new features are being added. Still a bit of work to do. You can download it here and put it in an overlay.

И этот же человек рекомендует пока такое не мерджить в главное дерево

Пойми, налабать ебилд который будет работать на твоей конкретной системе - дело нехитрое. А вот сделать такой ебилд, на который потом не посыпется гора багрепортов из-за напиханных в него костылей или неучтенных проблем - непросто.

И чем сложнее софт, тем это сложнее.

В этом плане я даже удивлен как boost-numpy удалось пофиксить так быстро. Эх, если бы САМ boost был таким же легким >_<

ясно, в общем по-прежнему юзаем из /opt скачанный с сайта, на удивление хорошо работает с бандленными либами.

на удивление хорошо работает с бандленными либами

Я бы удивился, если бы это было не так - за этих их и бандлят

спасибо!

boost-numpy установлен.

Можете разказать на пальцах, -e 's/PythonLibsNew/PythonLibs/' -e 's/python3/python/' - это и есть решение? Т.е. в boost и не нужно было --with-python. Спрашиваю, потому что теперь у меня новый квест - не собирается media-libs/pyilmbase, да, версия не портажная.

Ошибка подобного характера - checking for boost::python... no

https://bpaste.net/show/fdfc216b1f00

не поделитесь подобным бинарным ебилдом?

и еще

media-gfx/openvdb

https://bpaste.net/show/b5c0bff2274b

это и есть решение?

это часть решения конкретно для boost-numpy

Основное решение - использование екласса из семейства python-r1(в данном случае python-single-r1)

Т.е. в boost и не нужно было --with-python

Посмотри внимательнее на зависимости - он и так тянется и устанавливается с --with-python

Спрашиваю, потому что теперь у меня новый квест - не собирается media-libs/pyilmbase, да, версия не портажная.

Кури билдсистему данного пакета. Судя по фразе «checking for boost::python... no» - похоже на autotools. Кури Makefile.am и configure.ac, если они присутствуют в тарболле пакета.

cannot find -lboost_python-3

А теперь сделай equery f boost и посмотри внимательно какие там существуют файлы с расширение .so.

Подсказка: -lboost_python-3 ожидает что где-то в системе(/lib или /usr/lib обычно, для 64-битных систем еще /usr/lib64) будет файл libboost_python-3.so

В Gentoo, благодаря возможности установки библиотек под несколько реализаций python-а, эта библиотека будет называться по-другому

Ебилда нет, просто кладу в /opt/blender/ http://ftp.halifax.rwth-aachen.de/blender/release/Blender2.77/blender-2.77a-l... .

у меня он собирается с --without-python

http://paste.org.ru/?0x8mkk

покажи emerge -Opv boost

Далее, что это за срань в твоём логе:

awk: fatal: cannot open file `/usr/portage/eclass/eutils.eclass' for reading (No such file or directory)
/etc/portage/bashrc: line 7: epatch_user: command not found                                                            

У тебя точно всё нормально с файловой системой и portage?

[ebuild   R    ] dev-libs/boost-1.61.0:0/1.61.0::gentoo  USE="icu nls python threads -context -debug -doc -mpi -static-libs -tools" ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 python3_5 (-python3_4)" 0 KiB

awk: fatal: cannot open file `/usr/portage/eclass/eutils.eclass' for reading (No such file or directory)

у меня портаж не там, и это записано

PORTDIR="/var/portage"
DISTDIR="/var/portage/distfiles"
PKGDIR="/var/portage/packages"
#PORTAGE_TMPDIR=/var/tmp

/etc/portage/bashrc - старый скрипт - удалил его)

media-gfx/openvdb - решил, оказалось просто в ебилде указана была старая версия.

почему оно недовольно?

покажи содержимое /etc/portage/repos.conf(если это файл) или содержимое файлов внутри(если это директория)

wgetpaste /etc/portage/repos.conf/layman.conf

https://bpaste.net/show/f96c80386672

теперь boost найден, но вот проблема посерьезнее

https://bpaste.net/show/63ec45132eb1

А где секция для главного репозитария?

Вот моя:

[DEFAULT]
main-repo = gentoo

[gentoo]
location = /usr/portage
sync-type = rsync
sync-uri = rsync://mini-router/gentoo-portage

Python version 2.7 boost::python libname boost_python-3.5

Неправильно выставленные переменные окружения для поиска Python - либа используется от Python 3.5, а сам Python - 2.7

странно, ничего не делал, попробовал еще раз вызвать ошибку - а ее нет!???

... ну и хорошо

но все равно добавил main-repo...

Python version                                  2.7
boost::python libname                           boost_python-2.7

та же петрушка

https://bpaste.net/show/a929ac82073f

причем Python version выбирается из активной версии питон, независимо от PYTHON_COMPAT

и c активным python-3.5 - выдает старое

checking for boost::python... no

не смотря на то что эта либа указана в конфигурации явно

--with-boost-python-libname=boost_python-3.5

Надо курить билдсистему, возможно отдельного указания опции недостаточно

Python version выбирается из активной версии питон, независимо от PYTHON_COMPAT

python-single-r1 eclass используется?

python-single-r1 eclass используется?

нет)))

USE=python emerge -1 --buildpkgonly boost
-----------------------------------------------
>>> Compiling source in /tmp/portage/dev-libs/boost-1.61.0/work/boost_1_61_0 ...
 * abi_x86_64.amd64: running multilib-minimal_abi_src_compile
 * python3_5: running building
b2 --user-config=/tmp/portage/dev-libs/boost-1.61.0/work/boost_1_61_0-abi_x86_64.amd64/user-config.jam gentoorelease -j25 -q -d+2 -sICU_PATH=/usr --without-mpi --without-context --without-coroutine --without-coroutine2 pch=off --boost-build=""/usr/share/boost-build --prefix="/tmp/portage/dev-libs/boost-1.61.0/image/usr" --layout=system threading=multi link=shared --python-buildid=3.5
-----------------------------------------
    - program_options          : building
    - python                   : building
    - random                   : building

ты умудрился засрать систему, похоже

очень странно

почему, у меня та же команда выдает противоположное?

[ebuild   R    ] dev-libs/boost-1.61.0:0/1.61.0::gentoo  USE="icu nls python threads -context -debug -doc -mpi -static-libs -tools" ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python2_7 python3_5 (-python3_4)" 0 KiB
......................
b2 --user-config=/var/tmp/portage/dev-libs/boost-1.61.0/work/boost_1_61_0-abi_x86_32.x86/user-config.jam gentoorelease -j1 -q -d+2 -sICU_PATH=/usr --without-mpi --without-context --without-coroutine --without-coroutine2 pch=off --boost-build=""/usr/share/boost-build --prefix="/var/tmp/portage/dev-libs/boost-1.61.0/image/usr" --layout=system threading=multi link=shared --without-python
......................
- python                   : not building

Покажите юзы? откуда в конфигурации --python-buildid=3.5

~ $ USE="python" emerge -avtp boost

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild   R    ] dev-libs/boost-1.61.0:0/1.61.0::gentoo  USE="icu nls python* threads -context -debug -doc -mpi -static-libs -tools" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_5 -python2_7 -python3_4" 0 KiB

похоже, что дело в том, что у тебя два питона в юзах обозначено: 2.7 и 3.5

Попробовал собрать кустарно - та же ошибка.

$ patch -p0 < configure_ac_python3.patch
$ patch -p0 < imathnumpymodule_cpp.patch
$ patch -p0 < PyImath_python3.patch
$ patch -p0 < python-pyilmbase-link.patch
$ ./bootstrap
$ ./configure --prefix=/usr --with-boost-python-libname=boost_python-3.5
............................
checking for boost::python... no
*** Could not run the boost::python test program, checking why...
*** The boost::python test program could be compiled, but could not be dynamically.
*** or statically linked.

Баг?

отлично! спасибо.

проблема в abi_x86_32

если собирать без него то вот как

b2 --user-config=/var/tmp/portage/dev-libs/boost-1.61.0/work/boost_1_61_0-abi_x86_64.amd64/user-config.jam gentoorelease -j1 -q -d+2 -sICU_PATH=/usr --without-mpi --without-context --without-coroutine --without-coroutine2 pch=off --boost-build=""/usr/share/boost-build --prefix="/var/tmp/portage/dev-libs/boost-1.61.0/image/usr" --layout=system threading=multi link=shared --python-buildid=2.7
..................
- python                   : building

но тут 2.7, его тоже придется отключить, пока не знаю что мне это будет стоить....

у тебя вообще не собирает при указании USE=python c abi_x86_32? а то, что для abi_x86_32 он собирает без питона, это ж логично, т.к. нет для питона abi_x86_32.

ты выхлоп не с того abi смотрел? В ебилде же указано:

python_bindings_needed() {
        multilib_is_native_abi && use python
}

Это значит что на биндинги будут собираться только для того основного ABI системы

у него собирается сам boost, но без биндингов к питону в abi_x86_32 и не собирается какая-то другая, сторонняя, либа, которая тянет зависимость от этих биндингов

ну тогда надо хачить ебилды.