Hi, As we can see on the pyobject's FTP (http://ftp.gnome.org/pub/GNOME/sources/pygobject/3.7/) there's a 3.7 branch. Currently, portage and overlays are stuck with the 3.4 version. I need, at least, the 3.7.4 version as an ebuild to properly build sonata 1.7 (https://github.com/multani/sonata) which append many new features compared with the 1.6.2.1 version (which is dead, the 1.7 is now maintained by another team). Best regards
It's a development version, probably won't be added to the tree (but to overlay)
It would be awesome if that version could be put on an overlay... I tried myself to write an ebuild for pygobject-3.7.4 or 3.7.5 (3.7.90 and ulterior won't pass with sonata-1.7) but with no success. I'm not really used to advanced ebuilds.
(In reply to comment #2) > It would be awesome if that version could be put on an overlay... I tried > myself to write an ebuild for pygobject-3.7.4 or 3.7.5 (3.7.90 and ulterior > won't pass with sonata-1.7) but with no success. I'm not really used to > advanced ebuilds. Do NOT go experimenting on this 1. dev-python/pygobject $ PYTHON_TARGETS=python2_7 ebuild pygobject-3.4.2-r1.ebuild clean test yields ......................................... g-ir-compiler GIMarshallingTests-1.0.gir -o GIMarshallingTests-1.0.typelib g-ir-compiler Regress-1.0.gir -o Regress-1.0.typelib CHECK Pyflakes ../tests/runtests.py:11: redefinition of unused 'unittest' from line 9 ../tests/test_gi.py:10: redefinition of unused 'unittest' from line 8 make[2]: *** [check-local] Error 1 make[2]: Leaving directory `/mnt/gen2/TmpDir/portage/dev-python/pygobject-3.4.2-r1/work/pygobject-3.4.2-python2_7/tests' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/mnt/gen2/TmpDir/portage/dev-python/pygobject-3.4.2-r1/work/pygobject-3.4.2-python2_7/tests' make: *** [check-recursive] Error 1 * ERROR: dev-python/pygobject-3.4.2-r1 failed (test phase): * emake failed It fell over before it even STARTED. /dev-python/pygobject $ PYTHON_TARGETS=python2_7 ebuild pygobject-3.4.2.ebuild clean test yields --------------------------------------------------------------- test_utf8_none_return (test_gi.TestUtf8) ... ok test_concurrency (test_mainloop.TestMainLoop) ... ok test_exception_handling (test_mainloop.TestMainLoop) ... ok testChildWatch (test_subprocess.TestProcess) ... ok ---------------------------------------------------------------------- Ran 639 tests in 5.835s Now perhaps the former actually worked @ some time past around when it was committed, subject to bread & butter testing?? dev-python/pygobject $ PYTHON_TARGETS=python2_7 ebuild pygobject-3.7.4.ebuild clean install yields --------------------------------------------------------------------- make[2]: Leaving directory `/mnt/gen2/TmpDir/portage/dev-python/pygobject-3.7.4/work/pygobject-3.7.4-python2_7' make[1]: Leaving directory `/mnt/gen2/TmpDir/portage/dev-python/pygobject-3.7.4/work/pygobject-3.7.4-python2_7' * Removing unnecessary /usr/lib64/python2.7/site-packages/gi/_glib/_glib.la (module) * Removing unnecessary /usr/lib64/python2.7/site-packages/gi/_gobject/_gobject.la (module) * Removing unnecessary /usr/lib64/python2.7/site-packages/gi/_gi.la (module) * Removing unnecessary /usr/lib64/python2.7/site-packages/gi/_gi_cairo.la (module) * Removing unnecessary /usr/lib64/libpyglib-gi-2.0-python2.7.la (no static archive) >>> Completed installing pygobject-3.7.4 into /mnt/gen2/TmpDir/portage/dev-python/pygobject-3.7.4/image/ And IF you're wondering, this bumped pygobject-3.7.4.ebuild does in fact use python-r1 The moral(s) of this story; Point 1. I suspect the new python-r1 eclass(es) are figuritively shifting the goal posts after the game was started, evident in the decimated test phase. This may not be the case. The alternative best guess is equally unsavoury. Point 2. It's more than a co-incidence that pygobject-3.4.2.ebuild does fine on the 'old' python eclass that stood on its own for, well, a long time. Point 3. Decimated test phase spells trouble. Point 4. Completing an install happily under python-r1, at least under py2.7, says it's broken, not shattered. Point 5. What's the rush? If there is one, select between the lesser of the 2 (or so) compromised choices; a) build on python-r1 eclass on an ebuild that buckled under normal stress, b) build on the mature python eclass that everyone is frantically attempting to deprecate, c) Hold your horses, and and at least let someone tender to the current latest pygobject-3.4.2-r1.ebuild so as to see it pass all.
3.8.1 in the tree
