search

g2p / bedup

Btrfs deduplication
http://pypi.python.org/pypi/bedup
GNU General Public License v2.0
323 stars 50 forks source link

No longer working with pypy #62

Open sjnewbury opened 9 years ago

sjnewbury commented 9 years ago

I've been using bedup with pypy for the last couple of years, it's much faster than with CPython for bedup. Dropping of python2 support has made this impossible. Unfortunately, it's not possible to simply use Py3k instead, since it currently only implements Python 3.2.5 which you've also just dropped support for!

g2p commented 9 years ago

I dropped Python 3.2 when I noticed this, but also because there were extra complications with testing (I have a Python3 tool to launch kernels on Travis, and I didn't want to backport it). I don't know how far it's diverged. If I'm to develop this in the future I don't want to be tied to an old Python release (3.2 is five months away from its security EOL).

I've kept PyPy3 in the CI (while ignoring failures), I like the project but I was rather hoping they'd update their stdlib port.

g2p commented 9 years ago

Though I found this: http://buildbot.pypy.org/nightly/py3.3/, if you're feeling courageous.

sjnewbury commented 9 years ago

I actually just tried building PyPy from the py3.3 branch build succeeded but the resultant pypy didn't work right now. Such is life on the bleeding edge.

sjnewbury commented 9 years ago

Got py3.3 branch to compile with "shadowstack". No idea why it's not working with asmgcroot with the same gcc version as pypy(2). I'll give it a go with bedup once I have all the dependencies emerged with pypy3/py3.3 and let you know if it works.

sjnewbury commented 9 years ago

No idea why, but I can't build pypy3 (from py3.3 branch) without it hard coding the build tree for its run-time resources! I'm on Gentoo as you probably gathered, so I modified the official ebuild to pull the source from the mercurial py3.3 branch. Confused.