Getting mercurial 5.2rc0 in portage will facilitate testing py3 support that's purportedly available in 5.2: https://www.mercurial-scm.org/wiki/Python3 Reproducible: Always
Is anyone working on this? I have a local ebuild that's working fine except for the following: * dev-python/zstandard needs a version bump to 0.13.0 (not yet released) for python3.8 support. * The bugzilla integration provided by the bugzilla useflag depends on dev-python/mysql-python which only has python2.7 support. Does this still work? Is this still needed?
mercurial-9999.ebuild needs python3 changes too. (In reply to Aidan Harris from comment #1) > Is anyone working on this? I have a local ebuild that's working fine except > for the following: > > * dev-python/zstandard needs a version bump to 0.13.0 (not yet released) for > python3.8 support. > * The bugzilla integration provided by the bugzilla useflag depends on > dev-python/mysql-python which only has python2.7 support. Does this still > work? Is this still needed? Please attach your ebuild. media-libs/x265-9999 is the only package installed on my system which needs mercurial for the repo.
Created attachment 602178 [details, diff] dev-vcs/mercurial: bump to v5.2.1
Created attachment 602180 [details, diff] dev-vcs/mercurial: bump to v5.2.1 I just noticed zstandard 0.13.0 has been released now so python3.8 support can be enabled. That's the only change between this patch and the other one (changing the PYTHON_COMPAT line).
(In reply to Aidan Harris from comment #4) > Created attachment 602180 [details, diff] [details, diff] > dev-vcs/mercurial: bump to v5.2.1 > > I just noticed zstandard 0.13.0 has been released now so python3.8 support > can be enabled. That's the only change between this patch and the other one > (changing the PYTHON_COMPAT line). Suggested improvements: Missing python_setup in src_compile before emake calls Missing dev-python/docutils in BDEPEND Remove unused eutils inherit
Oh, and this patch is not usable in the ::gentoo repository as you've created a symlink to 9999 instead of a real copy of 5.2.1. Symlinks are banned there
Also change dev-python/mysql-python to dev-python/mysqlclient for python3 support
Created attachment 602538 [details, diff] dev-vcs/mercurial: bump to v5.2.1 Thanks for the feedback. This patch should be suitable for inclusion in ::gentoo. A summary of the changes made is as follows: * Addressed repoman warnings (updated the year in the header from 2019 to 2020). The only remaining issue repoman complains about is the dropped keywords which is deliberate as I've only tested on ~amd64 and ~x86. * Removed python3.8 from PYTHON_COMPAT as dev-python/mysqlclient does not support it yet. This is probably for the best since mercurial still has a few issues with python3.8 and support can easily be added again in the future. * Removed unused eutils from inherited eclasses * Added dev-python/docutils to BDEPEND. I hope I've done that correctly using `python_gen_any_dep` (we don't care which version of docutils is used or what python_targets are used as long as we take care to use the same python when building the docs.) * Replaced dev-python/mysql-python with dev-python/mysqlclient * Removed the mercurial-9999.ebuild symlink which is now replaced with a copy of mercurial-5.2.1.ebuild
There's another issue I noticed but forgot to mention above. There's a note in the ebuild that `append-flags -fno-strict-aliasing` should be made conditional if python3 is supported. I don't know when this was added though, or why it was added so I'm not going to be the one to remove it and potentially break things...
(In reply to Aidan Harris from comment #9) > There's another issue I noticed but forgot to mention above. There's a note > in the ebuild that `append-flags -fno-strict-aliasing` should be made > conditional if python3 is supported. I don't know when this was added > though, or why it was added so I'm not going to be the one to remove it and > potentially break things... Python 2 C API is known to be incompatible with strict aliasing rules. Python 3 C API is fixed, so -fno-strict-aliasing is usually no longer needed.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=000e00ed25578d81ab907a5723d072a12c0e0220 commit 000e00ed25578d81ab907a5723d072a12c0e0220 Author: Cédric Krier <cedk@gentoo.org> AuthorDate: 2020-01-25 17:32:24 +0000 Commit: Cédric Krier <cedk@gentoo.org> CommitDate: 2020-01-25 17:34:35 +0000 dev-vcs/mercurial: Version bumps to 5.2.2 Update also 9999 Closes: https://bugs.gentoo.org/701920 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Cédric Krier <cedk@gentoo.org> dev-vcs/mercurial/Manifest | 1 + dev-vcs/mercurial/files/zstd.py | 2 + dev-vcs/mercurial/mercurial-5.1.2.ebuild | 5 +- dev-vcs/mercurial/mercurial-5.2.2.ebuild | 168 +++++++++++++++++++++++++++++++ dev-vcs/mercurial/mercurial-9999.ebuild | 104 ++++++++++--------- dev-vcs/mercurial/metadata.xml | 16 +-- 6 files changed, 238 insertions(+), 58 deletions(-)
'python_is_python3 || append-flags -fno-strict-aliasing' would affect building for Python 3 when both Python 2 and 3 are enabled by PYTHON_TARGETS. To avoid it, CFLAGS / CXXFLAGS need to be made local: + local CFLAGS=${CFLAGS} CXXFLAGS=${CXXFLAGS} python_is_python3 || append-flags -fno-strict-aliasing
Fixed by https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ac27e57792ba26e4ff4c924c2202a0b180e7d384 Thanks.
Hi Cédric, Any reason why you didn't include 3.7 and 3.8 in PYTHON_TARGETS? pygments and zstandard already support it.
(In reply to Louis Sautier (sbraz) from comment #14) > Hi Cédric, > Any reason why you didn't include 3.7 and 3.8 in PYTHON_TARGETS? pygments > and zstandard already support it. Because zstandard has not supported implementation for arm64.
