dev-python/pypy3 depends on sys-libs/ncurses-5 which was recently replaced with sys-libs/ncurses-6. Reproducible: Always Steps to Reproduce: emerge pypy3
*** Bug 568846 has been marked as a duplicate of this bug. ***
As you have tested this already, it's because pypy3 (and pypy-2.4.0 as well) is bound to this particular ncurses ABI. Sadly, pypy3 release seems nowhere close and the upstream fix was pretty much a huge redesign of the whole thing that's too hard to backport. One alternative possibility is doing a snapshot of the upstream hg branch but it's marked 'alpha' there and I don't know if it's suitable for any real-world use. If you happen to know something more about pypy3, I'd really appreciate some help getting it back on track.
Thanks Michał, I thought there was probably an important reason for the strict RDEPENDS :). I would definitely agree with you, alpha quality probably isn't usable for a stable build. I can't speak for everybody else, but I really only use pypy and pypy3 for personal python projects though. I would actually be okay with an experimental build. I'm not sure why more people haven't run into the ABI issue. Maybe other distros haven't upgraded to ncurses-6 yet? Maybe there's a way to just extract the ncurses-6 API changes into a Gentoo patch? I'm honestly not too familiar with the slot mechanism, but maybe there's a way to depend on ncurses-5 in another slot? None of these seems ideal, but masking would be the only other idea I could think of at least. Hopefully a friendly heads up, I ran into a couple other compile issues with pypy (https://bugs.funtoo.org/browse/FL-3058). I'm going to try to reproduce them, report upstream, and possibly try to submit a patch.
(In reply to Jason Schulz from comment #3) > I would definitely agree with you, alpha quality probably isn't usable for a > stable build. I can't speak for everybody else, but I really only use pypy > and pypy3 for personal python projects though. I would actually be okay > with an experimental build. I think so too. I was working on live ebuild for pypy3 at some point but didn't have enough time to finish it. The long build time doesn't help. Nevertheless, I'll try to wrap up something when I'll have time. > I'm not sure why more people haven't run into the ABI issue. Maybe other > distros haven't upgraded to ncurses-6 yet? Maybe there's a way to just > extract the ncurses-6 API changes into a Gentoo patch? I'm honestly not too > familiar with the slot mechanism, but maybe there's a way to depend on > ncurses-5 in another slot? None of these seems ideal, but masking would be > the only other idea I could think of at least. Either that or they simply don't use pypy3. It's a pretty early project after all, compared to the regular pypy branch. Yes, probably fixing it up to have updated ncurses API would work. If you can come up with a patch or find one, I'd be happy to apply it. But myself, I'm quite unlikely to be able to do one anytime soon. As for slots, I'm not aware that much how cffi in pypy works. Maybe it would be possible to force it to use libncurses.so.5, assuming it doesn't require headers.
FYI: I've committed pypy3-9999 which seems to install fine.
Thanks, the live build compiles okay for me (echoes errors, but seems to run okay though). Just FYI, in regard to the compile issues, I filed a couple bugs upstream (https://bitbucket.org/pypy/pypy/issues/2215/gcc-translation-error-march-ivybridge, https://bitbucket.org/pypy/pypy/issues/2216/translation-error-w-clang). According to developers, and the documentation, it looks like the build is fairly sensitive to CFLAGS (with asmgcroot). I added a pull request for the compile issues via github (https://github.com/gentoo/gentoo/pull/534). Hopefully it saves some people trouble going forward.
Created attachment 423304 [details, diff] pypy3-2.4.0-ncurses6.patch Hi there. It seems, I've made a fix (inspired by Arch-distro team) to fix compilation against ncurses6. Here is the patch to put in filesdir (ebuild change will be trivial after that). Although, Arch guys monkeypatching this via sed, I dislike their method, because, in my opinion it will not support crosscompilation (while mine does). So, please review and apply the patch ASAP, if it is ok.
I'm sorry for not handling this earlier. I'll try to do it in the next 24hrs, I will also incorporate the path fixes from pypy.
Well, it went smoother than expected. Fixed in 2.4.0-r1 (-r2 in case of pypy-bin).
