Created attachment 537526 [details] dev-python/pivy-9999.ebuild This is one of the missing dependencies for the qt5 version of freecad. It depends on a new SoQt verision build against qt5. It works only with the >media-libs/coin-4.0.0a_pre20180416 from tree Note that bugs #507844 and #631048 are related to the deprected an to be removed qt4 dependent version (maybe close them with wontfix after pivy-1.5 is gone from tree)
To be tested with SoQt-9999.ebuild from bug #644362 (fails currently because of missing media-libs/coin-9999, but works after changing to media-libs/coin-4.0.0a_pre20180416::gentoo)
Created attachment 542094 [details] dev-python/pivy-9999.ebuild Fix build like https://forum.freecadweb.org/viewtopic.php?t=8097
Unassign unresponsive maintainer.
I was just looking for bugs on any missing ebuilds still needed for freecad. As I have an ebuild for pivy in my overlay, I can take proxy maintainership for the package.
Please update the URL for this package. The repo on the freecad space is a freecad internal developing repository. They regulary backport their developments to the actual repository at https://bitbucket.org/Coin3D/pivy
Created attachment 626992 [details] pivy-0.6.5.ebuild I'm going to open a PR with the attached ebuild soon
BTW the coin repository has moved from bitbucket to github, and as such the pivy repo too. It's now at https://github.com/coin3d/pivy
Created attachment 663910 [details] pivy-0.6.6a_pre0.ebuild I could appreciate if someone could investigate attached ebuild. Specifically, why compilation fails when executed via portage: /var/tmp/portage/dev-python/pivy-0.6.6a_pre0/work/pivy-0.6.6a_pre0_build/pivy/coinPYTHON_wrap.cxx: In function 'PyObject* _wrap_SbString_vsprintf(PyObject*, PyObject*)': /var/tmp/portage/dev-python/pivy-0.6.6a_pre0/work/pivy-0.6.6a_pre0_build/pivy/coinPYTHON_wrap.cxx:9587:15: error: invalid array assignment but works when manually compiling (even when invoking cmake with the same params as within portage. I compared .cxx files generated by SWIG and they are somewhat different - as if order of generated code was different or sth, I have no idea whether it has any influence but for sure prevents me from doing reliable comparison.
[ 33%] Building CXX object interfaces/CMakeFiles/coin.dir/__/pivy/coinPYTHON_wrap.cxx.o cd /var/tmp/portage/dev-python/pivy-0.6.6a_pre0/work/pivy-0.6.6a_pre0_build/interfaces && /usr/bin/x86_64-pc-linux-gnu-g++ -Dcoin_EXPORTS -I/usr/include/python3.7m -I/var/tmp/portage/dev-python/pivy-0.6.6a_pre0/work/pivy-0.6.6.a0/interfaces -march=znver2 -O2 -pipe -ftree-vectorize -fPIC -o CMakeFiles/coin.dir/__/pivy/coinPYTHON_wrap.cxx.o -c /var/tmp/portage/dev-python/pivy-0.6.6a_pre0/work/pivy-0.6.6a_pre0_build/pivy/coinPYTHON_wrap.cxx /var/tmp/portage/dev-python/pivy-0.6.6a_pre0/work/pivy-0.6.6a_pre0_build/pivy/coinPYTHON_wrap.cxx: In function 'PyObject* _wrap_SbString_vsprintf(PyObject*, PyObject*)': /var/tmp/portage/dev-python/pivy-0.6.6a_pre0/work/pivy-0.6.6a_pre0_build/pivy/coinPYTHON_wrap.cxx:9587:15: error: invalid array assignment 9587 | arg3 = *temp; | ^~~~
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1f3c1e8991bbf3484b1d7fd4df7d84b7899befdd commit 1f3c1e8991bbf3484b1d7fd4df7d84b7899befdd Author: Miroslav Šulc <fordfrog@gentoo.org> AuthorDate: 2020-12-30 20:34:05 +0000 Commit: Miroslav Šulc <fordfrog@gentoo.org> CommitDate: 2020-12-30 20:35:05 +0000 dev-python/pivy: new ebuild Bug: https://bugs.gentoo.org/659478 Package-Manager: Portage-3.0.12, Repoman-3.0.2 Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org> dev-python/pivy/Manifest | 1 + dev-python/pivy/files/pivy-0.6.4-find-SoQt.patch | 31 ++++++++++++++++++ dev-python/pivy/metadata.xml | 23 +++++++++++++ dev-python/pivy/pivy-0.6.5.ebuild | 41 ++++++++++++++++++++++++ 4 files changed, 96 insertions(+)
we already have for a few days dev-python/pivy-0.6.5 in the tree which is sufficient for all freecad ebuilds in waebbl's overlay afaik. is there still any need for the pre-release of pivy or even for the live ebuild, or we can close this bug as resolved?
Do we still need this bug? The only revdep we have for now is freecad, which works well with the 0.6.5 release and has no need for a live ebuild. Version 0.6.5 has been in the tree for a few months, and I add a 0.6.6 PR later this day and also a stabilization request for 0.6.5. Gonna closing this, feel free to re-open if you think a live ebuild is still needed.
